PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Manchester Codierung decodieren



bobo
16.11.2004, 08:59
Hallo liebe Forumuser.

Hiermit möchte ich mich erst einmal kurz vorstellen. Ich bin fast 30 Jahre alt und komme aus Coburg. Beruflich bin ich seit ca. 13 Jahren als Instandhaltungselektriker beschäftigt. In meiner Freizeit beschäftige ich mich mit Laser, Modellbau, Bau von Ortungsgeräten für die Schatzsuche und natürlich die Schatzsuche.

Momentan baue ich gerade ein Gradiometer. Wer wissen will, um was es sich dabei genau handelt, kann hier (http://www.garaschn.de/derschatzsucher/forum/index.php?showtopic=120&hl=gradiometer) genaueres dazu nachlesen.

Dabei kam auch eine C-Control-Unit 2.0 zum Einsatz. Diese hat die Aufgabe die Messdaten, welche vom PIC geliefert werden per RS232 an den PC zu übertragen. Hinzu kommt dann noch das bekannte billige Funkmodul von Conrad.

Nun habe ich über das Funkmodul und der Manchester-Codierung schon viel gelesen, aber keine Antwort auf meine Frage gefunden.

Das Problem ist, das bei o.g. Funkmodul die seriellen Daten am Empfänger in Manchester-Codierung ankommen. Nun meine diesbezügliche Frage.

Welche elektronische Möglichkeit gibt es, die Manchester-Codierung zu decodieren? Vielleicht sehe ich nur den Wald vor lauter Bäumen nicht.

Leider greift die geophysikalische Software nur auf den COM-Port zu und deshalb brauche ich nach dem Empfänger wieder ein reines RS232-Signal.

Über zahlreiche Hilfevorschläge möchte ich mich jetzt schon bedanken.

Wenn das Gradiometer läuft, ist als nächstes der Bau eines Erkundungsfahrzeuges für Hohlräume und Stollen geplant - also ein C-Control-Robi.

mfg

BOBO
www.derschatzsucher.de

x-ryder
17.11.2004, 15:39
hiermit kannste de und encodieren:

$regfile = "m8def.dat"
$crystal = 7372800

Declare Function M2b(byval Minput As Word) As Byte
Declare Function B2m(byval Binput As Byte) As Word

Dim W As Byte
Dim W2 As Word
Dim I As Byte
Dim I2 As Byte
Dim S As String * 16

W = M2b(&B0110011001100110)
W2 = B2m(&B01010101)

Function M2b(byval Minput As Word) As Byte

For I = 0 To 15 Step 2
I2 = I / 2
Select Case Minput.i
Case 1 : M2b.i2 = 0
Case 0 : M2b.i2 = 1
End Select
Next

End Function

Function B2m(byval Binput As Byte ) As Word

For I = 7 To 0 Step -1
Select Case Binput.i
Case 0 : S = S + "01"
Case 1 : S = S + "10"
End Select
Next

B2m = Binval(s)

End Function

End

18.11.2004, 10:26
Äh - vielleicht habe ich mich nicht richtig ausgedrückt. Was muß ich machen, damit der Laptop es wieder versteht?

Ich möchte mit dem Laptop empfangen. Sprich - das Hyperterminal versteht keinen Manchester-Code.

x-ryder
18.11.2004, 10:31
man könnte zwischen den RS232-Port und den Empfänger noch einen billigeren µc machen wie z.b. nen AT90S2313 und den darauf abrichten einen Manchestercode zu decodieren...

Martin

Kurt
20.11.2004, 19:54
Hallo bobo,



Welche elektronische Möglichkeit gibt es, die Manchester-Codierung zu decodieren?

Mir ist keine elektronische Schaltung bekannt, die das machen könnte. Vom Ansatz stelle ich mir so eine Schaltung aus Flip-Flops und Monostabile Kippstufen (als Timer) vor. Mit Software läßt sich das Problem leichter erschlagen (aus der Sicht eines Programmierers natürlich gesehen).

Wenn Du die C-Control-Unit 2.0 als Übermittler der Messdaten vom PIC zu RS232 verwendest, kannst Du mit der C-Control-Unit 2.0 die im Manchestercode vorliegenden Daten dekodieren.

Wenn ich richtig verstanden habe, ist Dein Gradiometer wie folgt aufgebaut:
PIC --> Sendemodul - - - -> Empfangsmodul --> C-Control-Unit 2.0 --> RS232 --> PC



Leider greift die geophysikalische Software nur auf den COM-Port zu und deshalb brauche ich nach dem Empfänger wieder ein reines RS232-Signal.


Was für ein reines RS232-Signal? Wie sieht das Datenprotokoll aus? Wie muß man der geophysikalische Software die Messdaten übergeben?


MfG

Wolfram Hubert

x-ryder
20.11.2004, 21:11
was habt ihr immer mit eurer überteuerten c-control 2.0???
die kostet 100€ mann kann da doch echt nen atmega8 nehmen das board ist suberbillig aufzubauen und auch im preis superbillig (wenns hochkommt dann nen 4-tel voncer c-control)...

Martin

bobo
22.11.2004, 00:48
@kurt:
Nein, da hast Du mich falsch verstanden.

Gradiometer-Sensor 1 und Sensor 2 gehen auf einen PIC, welcher den kompletten Abgleich der Sensoren vornimmt und die Differenz beider Sensoren errechnet. Der PIC gibt dann ein 8bit-Byte und ein weiteres Bit (zeigt an, welcher Sensor eine Veränderung erfährt) an die C-Control weiter. Diese gibt den Messwert auf dem seriellen Port an das Sendemodul aus. Das Empfangsmodul gibt das serielle Signal an den MAX232 weiter, welcher am COM-Port vom Laptop sich befindet.

Problem, am Laptop kommen die Daten im Manchester-Code an.

x-ryder
22.11.2004, 12:53
was war jetzt mit der idee nen atmel (maximal 8€) controller zwischen empfänger und lappy zu hängen?

stegr
22.11.2004, 19:00
Wenn er schon nen PIC verwendet, wird er wohl eher auch zum Konvertieren der Daten nen PIC verwenden und keinen Atmel, aber prinzipiell denke ich auch, dass da ein einfacher uC rein sollte und der dann den Manchester-Code nach RS-232 wandelt.

Mobius
22.11.2004, 19:40
Also, ich würde eh den C-Controller ganz herausnehmen und einen größeren PIC als Sensor/Motorsteuerungs/Sende-Empfangs-einheit einbauen (z.B.: 18F452, hat sage und schreibe 33 I/O-Ports :D kostet aber auch >7€ :-b ), der dann die ganze Arbeit übernimmt. Kommt immer noch billiger, als ein C-Controller...

Und wie alle schon gesagt haben, sollest du einen weiteren PIC nehmen, der die Daten dekodiert und sie dann an den RS323 Port schickt. Dann würde die Kommunikation so aussehen:

Motor <-
Sensor -> PIC <-> Sender <-----------------------> Empfänger <-> PIC <-> RS323 <-> Laptop

Wobei im Abschnitt RS323 noch ein 5V -> 12V Pegelwandler eingesetzt werden sollte (auf anhieb fällt mir nur der MAX232/MAX233 ein)...

Naja, ich hoffe, alle Klarheiten beseitigt :D (<-- Dieses Smiley schaut irgendwie fies aus... sollte aber nicht sein :D)
MfG
Mobius

22.11.2004, 22:06
Leider kann ich keine PIC´s programmieren. Der PIC war schon vom Hersteller beschrieben. Deshalb auch die C-Control. Wer könnte mir denn einen PIC programmieren, der für mich decodiert? Zahle auch dafür - kein Problem. Einfach Angebote an: stefan.powalla(a)brose.net

27.11.2004, 16:29
Habe leider keine Zeit. Ich würde dir raten es selbst zu probieren. Es gibt sehr viele Informationen bezüglich des PIC COntrollers. :-s

Mobius
27.11.2004, 16:54
naja, eine Seite, die ich wärmstens für PIC-Anfänger (ich zähl mich auch noch untere diesen namen) empfehle ist http://www.sprut.de . Da kann man alles über die µC erfahren und es werden auch einige billige Brenner vorgestellt, inklusive Brennsoftware...

MfG
Mobius

P.S.: Der Brenner 5 (bin grad von "Quick'n Dirty" umgestiegen) kostet alles in allem 20€ + Zeit zum Ätzen und zusammenbauen... wie ich finde eine gute Alternative zu dem von Microchip vertriebenen Geräten...

stegr
27.11.2004, 17:21
Selbiges kann ich auch nur empfehlen...
Lerne wie du nen PIC programmierst und du wirst nach ner Weile deine C-Control vergessen...

Und wegen dem Brenner, den Mobius vorgeschlagen hat, würde ich dir für den Anfang zu einem anderen raten...
Ich zitier mich mal selber aus nem anderen Beitrag:
d) Ich bin vor ner Weile auf nen anderen Brenner umgestiegen, der noch einfacher ist und mit deutlich weniger Bauteilen auskommt: JDM.kompatible Brenner
(z.B. http://automatisierungstechnik.fh-pforzheim.de/projekte/wwwpicevaluation/programmer/iicprog/iicprog.htm)
Der kostet inkl. Platine ca. 75 Cent. [...]
Software dafür ist zum einen das Programm ICProg
(auf http://automatisierungstechnik.fh-pforzheim.de/projekte/wwwpicevaluation/software/iicprog/iicprog.htm sowie http://www.ic-prog.com)
zum anderen gibt es auch eine schöne Entwicklungsumgebungen (leider nur) für Linux (http://pikdev.free.fr/).

Für Lernbeispiele empfehle ich dir auch www.sprut.de, da ist alles am einfachsten erklärt.
Brennsoftware: IC-Prog (Freeware).
Programmierumgebung: MPLAB von Microchip (auch Freeware)
Wenn du ne Hochsprache suchst, dann kannst du entweder ne abgespeckte Version von nem C-Compiler verwenden, oder du nimmst JAL. Jal ist Freeware und ähnelt mehr Pascal als C.

Ich selber benutze mitlerweile das ICD2 von Microchip und programmiere fast alles in C (CCS-Compiler).
Der Vorteil vond em Gerät ist, dass es nicht nur ein Programmiergerät ist, sondern auch ein In-Circuit-Debugger und bei größeren Projekten ist das deutlich angenehemer... für den Anfang braucht man das aber wirklich nicht.

MfG
Stefan

pebisoft
27.11.2004, 21:57
lass die finger vom c-conntrolII. nimm einen avr16 oder avr32 .
mfg pebisoft

bobo
29.11.2004, 03:06
@pebisoft:
Was ist das genau und wo finde ich es? Ist der auch in Basic zu programmieren? Außerdem, was ist an der C-CII so schlecht?

stegr
29.11.2004, 06:58
1.) C-Controll: langsam und teuer
2.) AVR sind genauso wie die PIC kleine Microcontroller. Geben sich preislich und leistungsmäßig nix und man muss sich nur entscheiden, welchen man lieber will. AVR's lassen sich in Basic programmieren (BASCOM), für PIC's hab ich das zwar auch schon gesehn, aber da ist das weit nicht so populär, wie bei den AVR's. Schau dir bei PIC's mal JAL an, das ist eine Mischung aus Basic, Pascal und C.
Ansonsten wirst du die PIC's eher im industriellen Umfeld sehen (vor allem Automotive) und die AVR's im Heimbereich sowie im Consumer-Bereich (Microchip hat früher seine Entwicklungstools sehr teuer verkauft, hatte aber schon damals den besseren Support; mittlerweile sind beide kostenlos). Die Einsatzgebiete wirst du auch direkt am Innenleben der uC's merken: PIC's haben sind sehr viel mehr auf Feldbusunterstützung (CAN, LIN, I2C) getrimmt als die AVR's.
Was du nimmst, ist für deine Aufgabe egal, aber du musst dich einfach entscheiden. Da du schon PIC's verwendest, wirst du wahrscheinlich eher zu denen tendieren, aber du da du bisher noch nichts mit gemacht hast und der PIC schon fertig war, kannst du ihn natürlich genauso als fertigen Chip ansehen und dir sagen: Ich hab mit beidem noch nix gemacht, also ist es egal.
Egal wie deine Entscheidung aussieht, wirst du für beide entsprechend Hilfe und Einsteigertutorials bekommen (man merkt vielleicht, dass ich mehr bei den PIC's zuhause bin).

Aber ich denke nicht, dass du um den Einsatz von einem uC herum kommen wirst.

MfG
Stefan

x-ryder
29.11.2004, 13:26
Da ich mit den AVR's nen bisschen besser bin kann ich da mal was zu erzählen:

Nehmen wir mal an du hast einen ATMEGA8:

- 8kB Speicher für Programme (Zahl hinter dem ATMEGA)
- 512 byte EEPROM für langzeitspeicherung von Variablen (Voreinstellungen z.B.)
- 1kB Speicher für Variablen
- 6 Analog-Digial Wandler mit 10 Bit genauigkeit
- 3 Timer
- bis zu 16 MHz

AVR's sind zwar auch gut geignet für Bussysteme wie z.B. den 1-Wirebus aber man kann an AVR's ab dem ATMEGA16 aufwärts auch einen Speicher anhängen für Variablen über 64 kB was das Arbeiten mit Tabellen oder ähnlichem leicht macht. An den gleichen Pins kann man auch eine Festplatte anhängen (bis 512MB)

Bascom ist sehr gut für sehr spezielle Funktionen.
Damit kann man z.B. über TCP/IP den Controller Netzwerkfähig machen, ein Grafisches Display ansteuern, eine Maus/Tastatur emulieren oder eine Tastatur auslesen, 16 Servos ansteuern, eine Fernbedienung amulieren,...............

Natürlich gibt es für AVR's auch C-Compiler

Martin

Mobius
29.11.2004, 16:03
Also, nun zu dem PIC:

Also Bsp. nehme ich mal einen, der grad vor mir liegt :D

PIC18F452:
-) 32K Programm-Speicher
-) 256 byte EEPROM
-) 1,5K RAM
-) 8 A/D-Wandler, 1 USART (=RS323), 1 I²C, 2 PWM (Für Servos etc.)
-) 4 Timer + 1. Watchdog
-) max 40MHz

Man muss aber dazusagen, dass dieses Monstrum in einem 40 Pin DIP ausgeliefert wird und sich nur für wirklich GROßE Projekte lohnt... Bei mir ist er in einem selbst gebastelten RN-Board verbaut und übenimmt von dort die Steuerung meiner Bots (ich sag jetzt mehrere, weil er fast täglich seinen "Körper" wechselt). Und den Programmspeicher habe ich bisher nicht einmal halbvoll bekommen. Aber was nicht ist, kann noch werden... Für sowas lohnt sich so ein Ding, aber es müsste bei dir schon einer vom Typ PIC16F8XX genügen...

Naja, jedem das seine, es ist eine Gewöhnungssache, welchen µC man bevorzugt :D
MfG
Mobius

P.S.: Als Entwicklerumgebung nutzte ich grad BoostC und MPLAB...