Kann mir jemand sagen um welches Telegramm es sich hier handelt. FSM, ZVEI und POCSAG scheiden hier aus, da kein Decoder darauf reagiert.
Das hört sich nach AFSK an, es gibt 2 Frequenzen, die digital umgetastet werden, nämlich eine bei etwa 2kHz und eine bei etwa 1kHz. Auf welcher Frewuenz hast du das mitgehört?
Die Baudrate ist relativ niedrig, so wie ich das jetzt sehen kann. Es wird irgendwas um die 150 Baud sein. Ein Bit dauert etwa 7ms, kann mich aber auch irren, es ist relativ schwierig, das auszuzählen, wenn man die verwendeten Frequenzen nicht genau kennt. Es könnten auch 300 Baud sein. Vielleicht kann man ein altes Packet-Radio-Modem dazu bringen, das zu decodieren. Einfach mal so eine Schaltung bauen: http://service.alan-germany.de/CB/AE8000/Packet-Platine/Schaltbild.pdf und an den Oszi anschließen. Die ist zwar für 1200 Baud gedacht, der TCM 3105 ist ein FSK Modem von Texas Instruments, lässt sich aber auf andere Baudraten umkonfigurieren. Ich kann mir auch vorstellen, dass er niedrigere Baudraten, die ganzzahlige Teiler von 1200 Baud sind auch mit der 1200 Baud-Einstellung decodieret. Hier noch das Datenblatt: http://pdf1.alldatasheet.com/datasheet-pdf/view/28704/TI/TCM3105NL.html
Hallo Peter, ich versuche das gerade auf Softwarebasis per Soundmodem http://www.baycom.org/~tom/ham/soundmodem/ Das kann afsk, fsk, fskpsp pam psk newqpsk und p3d :) Bekomme aber nur Buchstabensalat heraus, kann aber auch daran liegen, dass das Signal nicht sauber ist. Kommt aus'm Kopfhörerausgang eines Scanners. Hilft hier ggf. solch ein Diskriminator? Frrequenz ist 150.250 MHz. Grüße und Danke Christian
Besonders viel Information steckt auch nicht drin in dem File. Hättest du vielleicht eine Sequenz, bei der länger gesendet wird, also nicht nur kurz irgendwelche Steuerzeichen?
Zur Info: Die Pakete werden von einem zivilen Movitalk 118 gesendet. Das Ding soll per G2D senden, aber Decoder gibts dafür nicht, da keine Standarts existieren... Wo setze ich am besten an, um aus dem Krach ASCII Zeichen zu bekommen?
@Peter es gibt auch größere Pakete, ich schau mal, ob ich eins einfangen kann.
Hier ist jetzt ein packet bei mit etwas mehr Daten. Viel größer werden die dann auch nicht.
Hab vielen lieben Dank Peter, bist wirklich eine große Hilfe für mich. Und das um die Uhrzeit... Ich werd mich heut noch 3h Schlaf gönnen und mich erstmal verabschieden.
Also, es handelt sich mit ziemlicher Sicherheit um AFSK, Frequenz0 = 1200Hz, Frequenz1 = 1800Hz und während der Datenübertragung 1200 Baud. Der Header bzw. das Acknowledge ist wohl langsamer (150 Baud). Laut Frequenzdatenbank ist das eine Taxifrequenz, ein Movitalk 118 hat ein eingebautes Modem für FMS, das spricht auch für die obigen Daten. Der Datenrahmen hält sich wohl an kein bekanntes AFU System, deswegen habe ich mit der Decodierung noch Probleme.
Wenn ich dem Binäroutput von dem Softwaresoundmodem glauben soll, handelt es sich nicht um ASCII Zeichen, denn jedes ASCII Zeichen beginnt binär mit einer 0. Es gibt im Telegramm mit keiner Startposition eine lange Folge von Zeichen, die für eine ASCII-Decodierung in Frage kommen. Ich gehe davon aus, dass das Binärdaten sind, die eventuell sogar verschlüsselt worden sind. Oder das Programm kann die Daten nicht sicher decodieren, weil sie zu viel Rauschen enthalten. Vielleicht finde ich noch eine bessere Möglichkeit, das audio zu decodieren, eventuell schreib ich schnell was für einen DSP. Ich wollte eh schon immer mal FSK auf einem DSP demodulieren. Viele Grüße, Peter
Hallo ihr beiden, ich habe mir das gerade mal angehört: seid ihr euch sicher das es sich nicht einfach um FMS handelt? Das lange ist dann ein Datentelegramm. Den genauen Aufbau gibt es bei Wikipedia (Funkmeldesystem). Martin
FMS ist es definitiv nicht, dafür sind die Telegramme zu lang. Auch die Frequenz spricht dagegen. Ich tippe auf Taxi-Funk. Das man nichts sinnvolles decodieren kann, bedeutet m. E. nur, dass die Daten in irgendeiner Form verschlüsselt sind. Das kann im einfachsten Fall eine simple Verschachtlung der Daten sein.
@Peter Guten Morgen, Du schläft wohl nie? Ja, ich gehe davon aus, dass ich hier die Taxidaten höre. Ein Blick ins Cockpit brachte das MT 118 zum Vorschein. Google meinte, dass nur 2 Systeme verschlüsseln, Heedfeld und irgendwas anderes. Die Übertragung hat sich eine Firma Namens Plettac vor zig Jahren ausgedacht, ist jedoch 2003 Pleite gegangen. Dokus gibts keine im Netz. Ich werd nochmal die AFSK Software-Modems mit deinen Parametern füttern, mal schaub ob sie geprächiger werden. Ggf. hast du auch mit dem Rauschen Recht. Da werd ich mal draussen eine Aufnahme machen und hoffe die Qualli ist besser. @Martin Das war emine erste Überlegung, da das MT 118 in bestimmten Modell ein FSM Modem besitzt. Es gibt auch selche die FFSK sprechen... Zumindest hat keiner der mir bekannten FSM Decoder etwas entschlüsseln können.
Die Data Carrier Detection funktioniert mit meinen Einstellungen - und
wohl nur mit diesen - korrekt. Dass es ein FMS ist, glaub ich auch
nicht, bei der Telegrammlänge, aber es würde sich anbieten das Modem mit
der gleichen Einstellung zu fahren, wenn es das bereits im Gerät gibt.
Und es spricht wohl alles dafür, dass es 1200Hz und 1800Hz sind, das
habe ich mittlerweile auch phasengenau nachgeprüft in Samplitude.
Jetzt ist noch die Frage, wie das mit den Start und Stop Bits ist. Ein
Startbit muss es geben, aber ist es 0 oder 1? Haben wir ein oder 2
Stopbits, sind sie 0 oder 1?
Handelt es sich überhaupt um 8 bit Übertragung? Wenn ja, was ist es für
eine Codierung?
Übrigens muss man bei der Software immer zwischen verschiedenen
Ansichten (Projektname und Channel) wechseln, bevor die eingegebenen
Daten auch richtig übernommen werden, ist wohl ein Bug. Im
commandline-Fenster sieht man beim Öffnen vom Modem dann, ob die
richtigen Einstellungen drin sind oder nicht.
>Du schläft wohl nie?
Bin erst 10 Std wach.
Kennt eigentlich jemand einen AFSK Demodulator mit Soundkarteneingang, der nur die Rohdaten auswirft? Bei dem Programm, mit dem ich jetzt arbeite, kann man die Daten nicht aus dem Fenster rauskopieren oder irgendwie abspeichern.
Hier könnt ihr mal anschauen, was ich aus dem langen Telegramm aus daten2.wav bisher gemacht habe. Ich hab es zunächst um einen Faktor 2500 saturiert verstärkt, dann die linke Spur auf 8 bit runtergesampled und im unsigned 8 bit PCM als Rohdaten in das File clipped.raw geschrieben. Mit einem Hexeditor (HxD) kann man jetzt die Waveform digital sehen. FF bedeutet, waveform ist high, 00 bedeutet, waveform ist low. Jetzt muss man die Anzahl der Samples, die high sind und die der Low-Samples abzählen und abschätzen, um welche Frequenz es sich jeweils handelt. Das ganze asynchron auf 1200 Baud aufsynchronisieren und dann die binären Rohdaten der FSK-Modulation erstellen. Bin noch ne Weile beschäftigt, bis es dann die Daten gibt, so wie sie vor dem Modem waren...
WOW, Peter ich bin echt froh Dich hier getroffen zu haben. Um solche Erkenntnisse zu erziehlen hätte ich Monate benötigt! Ich werde noch ein paar große möglichst rauschfreie Mitschnitte besorgen. Wir aber sicher erst heute Abend was werden, wenn die Familie genug von mir hat :)
So, jetzt gibts weitere Daten. Ich habe gerade ein Programm geschrieben, das aus den Audiorohdaten zunächst ein menschenlesbares Testfile erzeugt, in dem highSamples mit 1 und lowSamples mit 0 codiert werden. Diese Datei heißt dann binary.txt Aus der binary.txt wird anschließend bestimmt, wie lange die Halbwellen des Audiosignals gedauert haben, es wird für jede Halbwelle eine Zahl in eine Datei geschrieben. Die Zahlen werden mit Strichpunkten getrennt. Diese Lengencodedatei heißt lengthcodefile.txt Und hier ist das Programm. Ihr müsst es im gleichen Ordner ausführen, wo sich Clipped.raw befindet. Aus der Lauflängencodierung werde ich jetzt die FSK-Demodulation erzeugen. Dauert aber noch etwas...
Ich werde mal versuchen einen Diskriminatorausgang anden Scanner zu löten, nicht dass all deine Bemühungen dank eines undeutlichen Signals umsonst sind...
So, jetzt kann das Programm die Frequenz der Audiofunktion schätzen. Es wird eine Datei demodulation.txt erzeugt, dabei steht jede Ziffer für ein Sample, also eine 1/44100 Sekunde. Eine 1 bedeutet hohe Frequenz, also 1800Hz, eine 0 bedeutet niedrige Frequenz, also 1200Hz. Dieses File muss nun von einer Art Softwareuart synchronisiert und decodiert werden. Mal sehen, ob ich das auch hinbekomm...
@Peter, ich hoffe Du schläft nun endlich :) Ich bekomme am 31. einen Diskriminatorausgang und eine bessere Antenne. Damit werde ich mich dann nach draußen und näher zur Quelle begeben und dir dann ein sauberes Signal liefern.
Ok, ich versuch dann mal eine bessere Demodulation zu basteln, das was ich jetzt habe, liefert nämlich einfach nur Unsinn. Die Bits sind viel zu kurz, teilweise nur ein Drittel der Länge, die sie mit 1200 Baud haben sollten, außerdem sind lange Zeiten nur Einser drin, also über mehrere Zig Bit, das verwundert mich etwas. Es war eben wohl keine so gute Idee, die Frequenz nur durch Messen der Zeit der Halbwellen zu bestimmen... Also schreib ich eben doch einen richtigen, linearen Demodulator. Außerdem möchte ich, dass mein Programm direkt die Audiofiles verarbeiten kann, ohne, dass ich sie vorher mit samplitude bearbeiten muss. Das oben genannte soundmodem kann leider die Audiofiles nicht richtig einlesen, ich bekomme immer Fehler, dass nicht alle Chunks gelesen werden konnten. Viele Grüße, Peter
Ich habe hier einen schönen Thread gefunden, wo negaH ein paar konstuktive Ansätze liefert. Zwar für Delphi gedacht, aber sicher auch auf andere Sprachen anwendbar. http://www.delphipraxis.net/topic91803,0,asc,0.html
Ich werde parallel zu deiner Entwicklung das ganze versuchen in Delphi umzusetzen, hab zwar seit ein paar Jahren nichts mehr damit gemacht, aber ich komm da schon wieder rein. Im ersten Schritt werde ich mir die Samples aufarbeiten, die per wav oder Soundkarte reinkommen.
Das ist kein Problem, ich hab auch Delphi. Ich werds mir mal bei Gelegenheit ansehen, hab nur im Moment etwas wenig Zeit. Guten Rutsch in neue Jahr, Peter
Hallo Peter, ich hab mit viel googlen und copy&paste das Programm inzwischen soweit, dass mir die 44kHz Samples in'nem Buffer vorliegen. Verarbeiten kann ich den Soundkarteninput und wav Dateien. Nun müßen daraus Nullen und Einsen @ 1200 Baud werden. Da hoffe ich mal, dass mir obiger Link helfen wird. Der Code von negaH soll wesentlich efizienter sein als z.B. FFT. Dir wünsche ich ebenfalls einen guten Rutsch und nochmal vielen Dank für deine kompetente Hilfe! Christian
Manchester Halbbitformat? H/L=1 L/H=0 ?
Gesundes Neues euch allen! Angestimmte Antenne und einen Diskriminatorausgang hab ich jetzt rangebastelt. Das Ergebnis hier als wav File.
Angehängte Dateien:
-
1.JPG
34 KB
Hallo, ich habe mal diskdaten.wav mit FMS grafisch verglichen: oben diskdaten, unten FMS. Martin
Angehängte Dateien:
-
2.JPG
67 KB
und nochmals ein ganzes FMS Telegramm: oben diskdaten und unten FMS - komisch das die Länge gleich ist. diskdaten ist übrigens immer noch recht verrauscht. @Wiesel: aus welchem Bundesland kommst du bzw willst du auch die Stadt verraten wo du das aufgenommen hast? Martin
Hallo, eins muss noch gesagt sein: auch ich kann es nicht als FMS direkt dekodieren - das kann aber passieren wenn CRC und die Bit CRC nicht direkt stimmt - soll heissen wenn die Modulation und Telegrammlänge gleich ist aber ein anderer Inhalt/ Aufbau benutzt. Martin
Hallo Martin, deine Bilder bestätigen meinen Versacht, dass die Taxis das integrierte FMS-Modem in deren Geräten nurzen. Vielen Dank dafür. Komme aus Sachsen / Chemnitz. Woher hast du solch lange FMS-Telegramme? Das Telegramm in diskdaten geht doch knapp eine Sekunde, die FMS Nachrichten bei BOS hingegen nur einen Bruchteil. Die Modulation ist mit FSM identisch, jedoch hat der Zeichensatz / das Protokoll damit nichts zu tun. Ich versuche gerade einen FMS Decoder zu bauen, der mir die Rohdaten gibt. Leider spucht dieser bei jedem abspielen ein anderes Ergebnis aus, bleibe aber dran.
Hallo Wiesel, FMS kann auch sehr lang sein ;-) Es gibt einmal die kurzen Stati der Fahrzeuge bzw der Leitstelle (zB Einsatz übernommen). Die haben eine Länge von 55ms (18Bit + 48Bit = 66Bit/ 1200baud = 0,055s). Dann werden da noch richtige Texte übertragen: Dauer max ca 1.5s. Das deckt sich ziemlich mit dem was du dort unter diskdaten aufgenommen hast: erst ein kurzes Telegramm ca 55ms und dann ein längeres von 1.5s. Komisch nur das die "gängigen" Dekoder für FMS damit nichts anfangen können. Martin
Hallo Christian, wäre es möglich, dass du mir das abgeänderte, lauffähige Delphiprojekt mal schickst? Ich habe es bisher nur in C++ geschafft, audiosamples von einer Soundkarte einzulesen. Es würde mich interessieren, wie das in Delphi funktioniert. Mit der Decodierung der waves bin ich bisher nicht weitergekommen, ich bekomme einfach noch keinen sinnvollen Rohdatenstrom zusammen. Hauptproblem ist das Erkennen des ersten Bits (Startbit) von jedem Byte, dafür habe ich noch keinen vernünfitigen Algorithmus. Viele Grüße, Peter
Hallo Peter, klar, kann ich machen. Ich verwende die bass.dll um mit der Soundkarte zu kommunizieren, ein Tutorial findest du unter http://www.michaelgaedtke.de/SubMenu_Messen/BASS-Tutorial-I.htm Meine Sourcen kann ich dir per Mail schicken. Grüße Christian
Hallo Christian, wenn du dich anmeldest, hast du Zugang zu meiner Emailadresse. Aus Spamgründen möchte ich sie hier nicht direkt hinschreiben. Die BassDLL erscheint mir aber auch schon sehr hilfreich, ich brauche eventuell keinen zusätzlichen Code, außer du hast bei der Decodierung schon erhebliche Fortschritte erzielt. Viele Grüße, Peter
Hallo Peter, zur Decodierung kannst du dir mal die C++ Sourcen eines FMS-Decoders anschaun. http://monitord.de/?article=5 Die MonitorModuleFMS.cpp ist sehr interessant, jedoch ohne C-Kenntnisse schlecht zu interpretieren.
Hallo Jan, die Diskussion ist irgendwann eingeschlafen. Aber schau dir das mal an: http://sourceforge.net/projects/taxidecoder/ Martin
Da werden zwar Nullen und Einsen ausgegeben, aber ansonsten wüsste ich nicht, wie man damit die eigentlichen Nachrichten lesen kann. Hmmm ...
Hallo! Bin durch Zufall auf Eure Diskussion gestoßen. Hab hier zwei Datenfunkdisplays von Heedfeld; ein HE4000 und ein HE5000S. Aufgrund einer Beschreibung eines Funkamateurs eines anderen Forums habe ich mit einem Universaldemudolator das PTT-Telegramm in Einsen und Nullen datgestellt. Es ist der selbe Aufbau, wie ZVEI-Digital, welches in BOSCH Funkgeräten zu finden ist. Bis auf eine Telegrammart, die das HE5000S aussendet kann ich das gesendete leider nicht in den anderen Funkgeräten zur Anzeige bringen.
Hallo Christian, was für einen Universaldemudolator hast du denn benutzt? Martin
Hallo Martin! Die Software heisst HOKA GOLD. Hab noch etwas herumexperimentiert. Der Grund, warum meine BOSCH Geräte das Telegramm nicht anzeigen liegt daran, das die CRC anders berechnet wird.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.