Softwaredecoder für andere Verfahren?

[DG7GJ]

Hallo!

Hi Jürgen!

Auch ich arbeite noch aktiv an dem Thema. Allerdings auf der "Gegenseite", d.h. ich bastel gerade an einem universellen Geber, der möglichst viele Protokolle generieren kann.

Hört sich auch interessant an! Wie gehst du die Sache an?
Modulbauweise, so das jedes Protokoll quasi sein eigenes Plugin hat?

Von daher bin ich auch immer daran interessiert, wenn du neue Infos zu neuen Protokollen hast.

Kannst ja hier in dem Beitrag immer mal eine Meldung posten, wenn sich dein Dokument geändert hat.

Gruß Joachim

Hmm, kann ich machen.
Momentan stehen noch BIIS1200 und PRM8035 in Warteschleife, sowie einige Personenrufsysteme die nicht dem verbreiteten Bosch/Telenorma/ANT-Standard entsprechen.
Kann ich aber nur selten richtig dran arbeiten, weil ich meißt ganz andere Sachen um die Ohren habe..:-)

Grüße aus Dortmund

Jürgen Hüser

[MiThoTyN]

Kann ich aber nur selten richtig dran arbeiten, weil ich meißt ganz andere Sachen um die Ohren habe..:-)

Das ist schon in Ordnung so, da ich selbst genug um die Ohren habe und sonst nicht hinterherkommt. Das aktuelle Tempo ist genau richtig! ;-)

Das ganze wird in Java entwickelt. Die Protokolle sind entsprechend modular aufgebaut. D.h. es können jederzeit neue Protokolle eingefügt werden, allerdings nicht zur Laufzeit als Plugins. Unterstützt werden zum einen analoge und digitale Rufverfahren. Als "Generatoren" (darauf basieren die Protokolle) sind momentan implementiert ein Sinusgenerator, DFSK und FFSK. Ausgabe über die Soundkarte oder in eine WAV-Datei.

Als Protokolle sind aktuell folgende implementiert (und in Arbeit) :

- beliebige Tonfolge nach ZVEI, CCIR, etc.
- BOS 5-Ton Folge
- Motorola QuickCall 1
- Motorola QuickCall 2
- DTMF Töne (In unterschiedlichen Modi)
- Morsecode
- Plectron Codes
- Aviation Call
- BOS FMS
- Zvei Digital
- VDEW Digital
- Steuersignal für AEG GWU (Teleregent)
- Pocsag
- Personenruf nach Bosch/AEG/Telenorma
- Heedfield

Zusätzlich gibts noch 2-3 Sachen aus den USA, die ich noch einbauen will. (z.B. Motorola MDC-1200, wenn ich genug Infos finde)

Allerdings existiert vorerst nur das "Backend". Es gibt noch kein Frontend oder eine Anwendung dafür.

Gruß Joachim

[MiThoTyN]

Thema DFSK:

Normalerweise ist es ja nicht so einfach möglich ein DFSK-Signal aus dem PC in ein FuG einzuspeisen. Dazu braucht man ja entsprechende Digitalpegel auf PC-Seite und ein entsprechendes FuG mit einem entsprechenden digitalen Eingang zur Modulation.

Da das Timing auf USB und COM am PC sehr bescheiden zu beeinflussen ist, hatte ich mal die Idee, einen Schmitt-Trigger an die Soundkarte zu hängen, das aus dem Audiosignal ( im regelfall ja -1..1 Volt) ein digitales TTL-Signal erzeugt.

Wäre das eurer Meinung nach machbar und sinnvoll? Denn dann könnte man tatsächlich mal versuchen das POCSAG-Signal in irgend einen (Test-) Sender einzuspeisen.

Gruß Joachim

[Shinzon]

Salut..

Doch, ich hatte dir sogar ne PN dazu geschickt ;)

Allerdings bin ich mehr der Mikroprozessor-Freak, ich würde sowas nicht auf ner
PC-Plattform entwickeln. (Dadurch fehlen mir natürlich z.B. das eben geschriebene
FSK-Problem, da ich nen Digital-I/O nutzen kann ..

Bisher hatte ich aber keine nennenswerte Zeit, einfach selbst mal den Bitstrom des
hier örtlich ansässigen ÖPNV zu zerlegen, geschweige denn komplette Empfangs/Sende-
Routinen einzubauen.

Fertig habe ich nur FMS-Codec, ZVEI (theoretisch nach Änderung der Tontabellen auch
alle anderen) Tonruf (1-16 Töne) Codec und POCSAG-Codec. Teile davon sind ja im FMS-
Dekoder zu finden ^^ ..

Durch meinen aktuellen Arbeitgeber baue ich derzeit noch an einem anderen Verfahren,
dies jedoch nicht privat, somit wird es schwer, darüber was zu sagen. Im Endeffekt wird
es aber das abgeschaltete Bündelfunk-System (lokal) ersetzen..

Derzeit auf der Suche bin ich nach einem Abnehmer für meinen DAU, DAG und DSE bzw.
allgemeinem POCSAG-Steuerempfänger, verhandlungen mit einem namenhaften Produzenten
laufen leider sehr zäh ab.. will nicht jemand sein Label auf nen DSE kleben ? ;)

Ich werde mir dein Paket mal anschauen, Jürgen, vielleicht kann ich das ein oder andere
Protokoll ja auch in Hardware "giessen" - danach ist's ja egal, ob auf der Benutzerseite
dann nen Display, nen USB-PC oder Ethernet liegt...

Was mir dennoch fehlt, ist so ein wenig die Zielgruppe dafür ..

Gruss,
Tim

[Fernmeldedienst]

Ich habe hier noch ein unbekanntes Datensignal auf einer bestimmten Betriebsfunkfrequenz.

Auch mit der Hilfe von Jürgen konnten wir das Geheimnis nicht lüften, von der BNA hab ich auch noch nix gehört.

Kann das Signal gerne mal mailen, wenn sich das noch jemand anhören mag..


Ich hätte Interesse an so ner Software..

[Shinzon]

Das Datensignal würd ich gern mal hören ;) Ideal in höchstmöglicher Aufzeichnungsauflösung,
das überflüssige Material wird schon von den Filtern zunichte gemacht :-P

[DG7GJ]

Salut..

Doch, ich hatte dir sogar ne PN dazu geschickt ;)

Stimmt....da war was spezielles vonwegen EVAG.
Dazu hatte/habe ich auch noch keine Infos.

Allerdings bin ich mehr der Mikroprozessor-Freak, ich würde sowas nicht auf ner
PC-Plattform entwickeln. (Dadurch fehlen mir natürlich z.B. das eben geschriebene
FSK-Problem, da ich nen Digital-I/O nutzen kann ..

Jo, da gibt's für vieles kleine Helferchen von CML.
Und was es nicht gibt, baut man sich halt in TTL/CMOS auf.

Bisher hatte ich aber keine nennenswerte Zeit, einfach selbst mal den Bitstrom des
hier örtlich ansässigen ÖPNV zu zerlegen, geschweige denn komplette Empfangs/Sende-
Routinen einzubauen.

Nun, ich weis nicht was da bei euch im ÖPNV verwendet wird.
Wird wohl ähnlich wie in Dortmund sein:
Im Sprechfunk massiv ZVEI-Digital, und im Datenfunk (RBL-System) etwas hochgradig komplexes und spezielles.
Stimmt eigentlich...wollte ich eigentlich mal Sampeln und angucken.
Jedenfalls ist das dortmunder RBL-System schon so fett das es die zulässige Kanalbreite reichlich ausschöpft. Irgendwas jenseits der 9k6bps, QPSK oder irgend sowas.
Hab da auch noch keinerlei Informationsquellen zu gefunden.

Durch meinen aktuellen Arbeitgeber baue ich derzeit noch an einem anderen Verfahren,
dies jedoch nicht privat, somit wird es schwer, darüber was zu sagen. Im Endeffekt wird
es aber das abgeschaltete Bündelfunk-System (lokal) ersetzen..

Huch? Wenigstens halbwegs kompatibel zu einem Standard, wozu es die Geräte gibt?
Oder was komplett neues mit eigenen Endgeräten?
Im 70cm Band gibt's ja seit Jahren etliche Zuweisungen für zukünftige BüFu-Lösungen.

Derzeit auf der Suche bin ich nach einem Abnehmer für meinen DAU, DAG und DSE bzw.
allgemeinem POCSAG-Steuerempfänger, verhandlungen mit einem namenhaften Produzenten
laufen leider sehr zäh ab.. will nicht jemand sein Label auf nen DSE kleben ? ;)

Hmm, kannst du da mal mehr erzählen?
Gerne auch per eMail: info@funktechnik-hueser.de

Ich werde mir dein Paket mal anschauen, Jürgen, vielleicht kann ich das ein oder andere
Protokoll ja auch in Hardware "giessen" - danach ist's ja egal, ob auf der Benutzerseite
dann nen Display, nen USB-PC oder Ethernet liegt...

Was mir dennoch fehlt, ist so ein wenig die Zielgruppe dafür ..

Wenn ich eine Anregung loswerden dürfte: Ganz klar Ethernet.
Ist schlichtweg das beständigste und flexibelste.
Keiner weis ob es in 10 Jahren noch PC's gibt die USB1.1 oder 2.0 fähig sind.
RS-232 wird ja auch schon massiv seltener.
Ethernet hingegen...Gigabit, 100M/10M...alles downkompatibel.

Das scheint auch so langsam die Industrie zu begreifen. Professionelle Geräte haben immer häufiger einen Ethernet-Port.

Und was die Zielgruppe angeht:
Sehr schwer einzuschätzen. Vor einigen Jahren war die Zielgruppe noch gut im Usenet organisiert. Heute hingegen...keine Ahnung.
Und die, die interesse hätten an solchen Betriebsarten kennen sich so wenig aus, das sie nichtmal die richtigen Suchbegriffe kennen.

Taxifahrer z.B. beschreiben ihren Datenfunk häufig als "handvermittelte", "halbautomatische" und "Vollautomatische" Auftragsvergabe.
Dabei begreifen die wenigsten, das sich diese Bezeichnungen eigentlich nur auf das EDV-System in ihrer Zentrale bezieht, das Datenfunkprotokoll aber bei allen Verfahren ein und das selbe ist.
Solche Leute suchen bei Google dann nicht unter "FFSK-Decoder" + "Heedfeld", sondern eher unter "Programm" + "automatische Auftragsvergabe" + "download".

Sind halt Anwender und keine Funk-Spezialisten...
Aber genau da dürfte ein nicht unwesentlicher Teil der Zielgruppe sitzen.
Denn was für einen BOS'ler sein FMS und DME, das ist für den Taxifahrer halt seine "Auftragsvergabe".

Grüße aus Dortmund

Jürgen Hüser

[DG7GJ]

Hi Tim!

Bisher hatte ich aber keine nennenswerte Zeit, einfach selbst mal den Bitstrom des
hier örtlich ansässigen ÖPNV zu zerlegen, geschweige denn komplette Empfangs/Sende-
Routinen einzubauen.

Nundenn, ich weis nicht ob bei euch das selbe RBL-Verfahren benutzt wird wie hier in Dortmund. Könnte aber sein, da ja hin und wieder auch Fahrzeuge gegenseitig vermietet werden zwischen ÖPNV's verschiedener Städten.

Hab eben mal grob auf das dortmunder System geschaut.
Offensichtlich ist es kein FSK oder FFSK. Ich kann nur die Frequenz 2400Hz nachweisen, keinen anderen. Phasensprünge sehe ich auchnicht, womit PSK/DPSK auch flach fällt.

Offenbar bedeutet jede Periode 2400Hz eine logische 1.
Also sozusagen Highspeed-Morsen...:-)

Grüße aus Dortmund

Jürgen Hüser

[Shinzon]

Also die EVAG nutzt Siemens-Systeme (deutlich sichtbar im Leitstand *G*)..

Es wird mit 1200/1800 FFSK gearbeitet, klingt zunächst wie FMS.. hat aber mindestens
ne andere Präambel, wird also nicht ohne Änderung vom BOS-FMS-Dekoder erkannt (nur
DCD, aber keine Daten). Parallel dazu wird 5-Ton-ZVEI-1-Tabelle als Selektivruf bzw.
entweder Fahrzeugkennung oder "Leiststellen-Weckton" genutzt.. früher gab's da wohl
auch mal nen Doppelton ..

Mehr konnte ich durch Bus/Bahnfahren in Hörweite des Bahnfunkgeräts bisher nicht in
Erfahrung bringen..

Gruss,
Tim

[DG7GJ]

Hi!

Also die EVAG nutzt Siemens-Systeme (deutlich sichtbar im Leitstand *G*)..

Es wird mit 1200/1800 FFSK gearbeitet, klingt zunächst wie FMS.. hat aber mindestens
ne andere Präambel, wird also nicht ohne Änderung vom BOS-FMS-Dekoder erkannt (nur
DCD, aber keine Daten). Parallel dazu wird 5-Ton-ZVEI-1-Tabelle als Selektivruf bzw.
entweder Fahrzeugkennung oder "Leiststellen-Weckton" genutzt.. früher gab's da wohl
auch mal nen Doppelton ..

Mehr konnte ich durch Bus/Bahnfahren in Hörweite des Bahnfunkgeräts bisher nicht in
Erfahrung bringen..

Gruss,
Tim

Ahhhrg....
Du meinst garnicht das RBL-superkomplexe Nurdatenfunkzeugs.
Du meinst das FMS-ähnliche gequäcke mit auf dem Sprechfunkkanal!

Da kannst du die Suche nach Informationen abbrechen:
Das ist ZVEI-Digital. Zu 99%iger Wahrscheinlichkeit, der restliche 1% währe BIIS1200.
Würde mich aber wundern...Bosch hat damals mit seinem "Digi-S" (das selbe wie ZVEI-Digital) für eine feste Verbreitung im ÖPNV gesorgt.

Wenn ÖPNV's heute alte Bosch-Geräte ersetzen müssen, kommen die an Zusatzmodems wie von ATS in Verbindung mit Motorola-Geräten nich mehr vorbei.
Obwohl...auch wenn ich's nie gesehen habe...aber könnte gut sein das es auch ein paar Sondervarianten der AEG Teledux gibt, die ZVEI-Digital können.

Das letzte mal als ich in nem Bus war, hing da auf jeden Fall noch alte Bosch-Technik drinnen...:-)
Ist in der Übersicht mit allen Infos hier mit drinn:
http://www.funktechnik-hueser.de/TMP...-Datenfunk.rar

Grüße aus Dortmund

Jürgen Hüser

[DG7GJ]

Hi nochmal!

Thema DFSK:

Normalerweise ist es ja nicht so einfach möglich ein DFSK-Signal aus dem PC in ein FuG einzuspeisen. Dazu braucht man ja entsprechende Digitalpegel auf PC-Seite und ein entsprechendes FuG mit einem entsprechenden digitalen Eingang zur Modulation.

Exakt so sieht das im komerziellen Bereich aus.
Im Amateurfunk (Stichwort SAMS) wird das nicht ganz so eng gesehen.
Da nimmt man einfach irgendein Funkgerät, passt die Regelschleife der PLL an und bastelt sich einen direkten Zugang zum VCO, der dann mit dem DFSK-Signal moduliert wird.

Entwickelt man heute einen DFSK-Sender neu, dann umgeht man schlichtweg die PLL, indem man einen eigenen LO zur Modulation nimmt.
So ähnlich wie im alten Bosch Fug8b1-z. Fest abgestimmter Quarzgenerator welcher moduliert wird. Im Sendemischer wird das Signal dann mit einer PLL-gesteuerten Mischfrequenz auf die Sendefrequenz gemischt.

Da das Timing auf USB und COM am PC sehr bescheiden zu beeinflussen ist, hatte ich mal die Idee, einen Schmitt-Trigger an die Soundkarte zu hängen, das aus dem Audiosignal ( im regelfall ja -1..1 Volt) ein digitales TTL-Signal erzeugt.

Würde gehen, aber die Qualitäten der heute üblichen Soundkarten ist da dann fraglich.
Damals, so vor 15 Jahren...da brauchte man nur eine originale Soundblaster nehmen und war auf der sicheren seite. Was da heute so alles auf dem EDV-Markt verbaut wird, kennt aber keinen Dynamikumfang, Rauschabstand, exakte Pegel mehr. Und ob die heute in Sachen Timing besser da stehen als USB und RS-232 unter Windows wage ich zu bezweifeln.

Wäre das eurer Meinung nach machbar und sinnvoll? Denn dann könnte man tatsächlich mal versuchen das POCSAG-Signal in irgend einen (Test-) Sender einzuspeisen.

Nunja, für gewöhnlich nimmt man heute dennoch RS-232 oder USB/Firewire dafür.
Und wenn die Anforderungen vom Timing her nicht mehr erreicht werden, setzt man da halt Hardware drann. Denkbar währe ein kleiner Atmel/Pic mit USB-Interface, welcher die Daten mit unkritischem Timing vom Rechner entgegennimmt und puffert.
Die Ausgabe richtung Modulator läuft dann nach strengem Timing vom Controller gesteuert.

Grüße aus Dortmund

Jürgen Hüser

[DG7GJ]

Hi Joachim!

Als Protokolle sind aktuell folgende implementiert (und in Arbeit) :

- beliebige Tonfolge nach ZVEI, CCIR, etc.
- BOS 5-Ton Folge
- Motorola QuickCall 1
- Motorola QuickCall 2
- DTMF Töne (In unterschiedlichen Modi)
- Morsecode
- Plectron Codes
- Aviation Call
- BOS FMS
- Zvei Digital
- VDEW Digital
- Steuersignal für AEG GWU (Teleregent)
- Pocsag
- Personenruf nach Bosch/AEG/Telenorma
- Heedfield

Wow, welch Umfang. Da hast du dir aber einiges vorgenommen!
Coole Sache!

Zusätzlich gibts noch 2-3 Sachen aus den USA, die ich noch einbauen will. (z.B. Motorola MDC-1200, wenn ich genug Infos finde)

Ähm...da gibt's ein paar Baustellen im Internet.
Da hat vor einigen Jahren mal ein kleines OpenSource-Grüppchen sich drum gekümmert und nen Dekoder für programmiert.
Ich hab mir das ganze auch mal angesehen, aber nach einigen Stunden erstmal in die große Warteschleife ganz nach hinten gestellt.

Die Gründe:
Es gibt in Deutschland, ja nichtmal in Europa, Funkgeräte die alle MDC1200-Funktionen verwenden. Die paar Teile die hier erhältlich sind (Motorola Commercial-Serie sowie einige Funkgeräte von Vertex Standard) können in Erster Linie MDC1200 als PTT-Kennung, sowie wenn überhaupt grundlegende Selektivrufmöglichkeiten. Aber sehr mager ausgeführt.
Da gibt's nicht viel zum experimentieren.

Und wenn ich (VX-924E und/oder CP040) mit MDC1200-Kennung programmiere, kommen merkwürdige Sachen herraus:

Die OpenSource Decodersoftware dekodiert diese PTT-Kennungen zuverlässig und richtig.
Schaute ich mir die Pakete als Sample an, bemerkte ich das im Funkgerät die Pakete rein zufällig invertiert werden:
Von rund 10 Kennungen ist rund die Hälfte im Bitmuster Invertiert.
Weiterhin gibt es ein Datenfeld, welches sich bei jeder Kennung ändert.
Offenbar eine Art Paketzähler, PTT-Zähler, vielleicht irgendein Timer?
Das führt natürlich dazu, das auch die CRC mit jeder Kennung anders ist.

Naja, wie gesagt...MDC1200 hab ich erstmal zurückgestellt, weil es in DL schlichtweg nicht vermarktet wird.

Grüße aus Dortmund

Jürgen Hüser

[MiThoTyN]

Wow, welch Umfang. Da hast du dir aber einiges vorgenommen!
Coole Sache!

Alles bis auf die letzten beiden genannten funktioniert schon. Ist schon cool, wenn man sich mit QC1 die "Station-Tones" von Notruf California generieren kann, die bei einem Alarm immer aus dem Lautsprecher gequäkt haben. ;-)

Wenn das mit dem MDC1200 so problematisch ist, dann stell ich das auch hinten an. Ich hab mich noch nicht genauer mit befasst, las nur auch was von PTT und dachte mir, das kann dann ja nicht so schwer sein.

Gruß

[DG7GJ]

Hi nochmal!

Alles bis auf die letzten beiden genannten funktioniert schon. Ist schon cool, wenn man sich mit QC1 die "Station-Tones" von Notruf California generieren kann, die bei einem Alarm immer aus dem Lautsprecher gequäkt haben. ;-)

Hehe...:-)
Könnte ja auch vieles von im deutschen Betriebsfunk eingesetzt werden. Hat sich halt nur nicht so weit verbreitet. Was eigentlich schade ist.

Wenn das mit dem MDC1200 so problematisch ist, dann stell ich das auch hinten an. Ich hab mich noch nicht genauer mit befasst, las nur auch was von PTT und dachte mir, das kann dann ja nicht so schwer sein.

Nunja, meine ersten Versuche (abendliche 2h bisher) waren halt bissel verwirrend, ausserdem war das Interesse eh fraglich. Denn bisher kenne ich nicht eine Funkanwendung in Deutschland, welche MDC1200 benutzt.
Geht ja offiziell/professionell auch garnicht.
Denn die hier vermarkteten Funkgeräte können gerade mal die PTT-Kennung.
Aber weder Motorola (der Erfinder) noch irgendeine andere Firma bietet hier einen Auswerter dazu an. Selbst das AFM490 von ATS unterstützt dieses Verfahren von der Stange nicht. Ob eine problemlose, bezahlbare Kundenwunschapassung möglich ist, wage ich zu bezweifeln.

Will ein Anwender in Deutschland tatsächlich MDC1200 als PTT-Kennung in seinem Funknetz benutzen (also auch auswerten), gibt es bisher nur eine unprofessionelle Hobbylösung. Hab ich mal angehängt...ist der einzige Softwaredecoder bisher.

Also wirklich komplex kann das ja nicht sein. Inklusive GUI schlappe 400kb.

Grüße aus Dortmund

Jürgen Hüser

[MiThoTyN]

Auf der Seite des Autors des Tools (www.matthew.at) gibt es C-SourceCode für den Decoder und für einen Encoder. Ideal für ReverseEngineering! ;-) Ich komm leider auf die Seite net drauf. Kann das nochmal einer von euch probieren?

Gruß