POCSAG Analyser ANTON

[dg3awe]

Ich musste gerade feststellen, dass ich hier schon lange nicht mehr im Forum aktiv geschrieben habe. Aber da heute Nikolaus ist und ich mein letztes Projekt (BOSL) hier auch zum Nikolaus veröffentlicht hatte, möchte ich an dieser Tradition anknüpfen.

Ich habe da einen kleinen ANTON gebaut. ANTON ist ein POCSAG-Analyser. Er kann Funktelegramme empfangen, auswerten und verarbeiten. Und wer etwas tiefer in die POCSAG-Materie, quasi auf Bit-Ebene oder direkt an der Funkschnittstelle einsteigen möchte, hat mit diesem Gerät die Möglichkeit dazu.

Eine detailliertere Auflistung der Funktionen gibt es auf meiner Homepage. Und sobald es meine Zeit erlaubt, gibt es dort oder hier im Forum nähere Beschreibungen und Vorstellungen der einzelnen Funktionen.

Einen schönen Restnikolaus...

ahoi dg3awe

[DG7GJ]

Hallo!

Ich habe da einen kleinen ANTON gebaut. ANTON ist ein POCSAG-Analyser. Er kann Funktelegramme empfangen, auswerten und verarbeiten. Und wer etwas tiefer in die POCSAG-Materie, quasi auf Bit-Ebene oder direkt an der Funkschnittstelle einsteigen möchte, hat mit diesem Gerät die Möglichkeit dazu.

Sieht soweit schonmal ganz interessant aus.
Anhand der beschreibung auf deiner Seite scheint das Teil angefangen vom DME-Tester bis hin zum DAU- und Master-Tester zu taugen.

Eine detailliertere Auflistung der Funktionen gibt es auf meiner Homepage. Und sobald es meine Zeit erlaubt, gibt es dort oder hier im Forum nähere Beschreibungen und Vorstellungen der einzelnen Funktionen.

Nunja, wie du dir vorstellen kannst umschwirren mich da diverse Detailfragen.
Was nutzt du als HF-Teil? Irgendwelche Fertigtransceiver-Chips (35cm sieht mir nach einem GSM-Modul aus), oder richtig von Grund auf selbst entwickelte PLL+Superhet+Zweipunktmodulation+usw.?
Sind die Frequenzbänder bestückungsabängig oder beliebig umschaltbar?
Wie genau ist die Referenzfrequenz? OCXO oder sowas...lese da "Feinabgleich 5-30Hz" was schon deftig wäre. Bei sowas würde ich eher zum Rb-Frequenznormal greifen und den ein paar Stunden vorlaufen lassen für solche Anforderungen..:-)

Ist das Teil schaltungstechnisch auf DFSK festgenagelt, oder wäre da noch "Platz" für andere Modulationsarten, beispielsweise QPSK, nPSK, nFSK (also DMR/pDMR/Apco/P25 usw.)?

Grüße aus Dortmund

Jürgen Hüser

[dg3awe]

Hallo Jürgen,

das Hautaugenmerk von Anton liegt bei der Auswertung von Funktelegrammen. Er ist quasi ein gewöhnlicher Kontrollempfänger. Und da diese Funktionalität in Form von Software sehr kompakt ausgefallen ist, konnte ich noch ein paar Zusatzfunktionen in den MCU-Speicher bringen. So z.B. auch die Sendemöglichkeit.

Anton kann beliebige alphanumerische und numerische Nachrichten sowie Bytestreams an beliebige RIC's auf beliebigen Frequenzen senden. Damit ist er nicht nur in der Lage, DME's auszulösen, sondern auch Meldungen gezielt in ein Aussendenetz einzuschleusen. Die Funktion als DAU-Tester setzt natürlich eine gewisse Fachkenntnis von der Materie voraus und geht nicht out-of-the-box.

Anton besteht im Grunde aus zwei Modulen. Dem HF-Modul und dem MCU-Modul. Das HF-Modul besteht im wesentlichen aus einem TRX-Chip und der zugehörigen externen Beschaltung. Der TRX-Chip ist normalerweise für Wireless-M-Bus geacht. Sowohl Frequenzen und auch Modulationsart werden aber für POCASAG unterstützt.

Das MCU-Modul besteht aus der Stromversorgung und der MCU selbst. Ich habe bei der MCU auf einen ATmega168 zurückgegriffen. Also nichts besonderes mit viel Leistung oder Speicher und der gleichen. Die Kommunikation erfolgt über USB, wobei ich hierzu ein spezielles Kabel von FTDI verwende um seriell TTL sprechen zu können.

Die Frequenzbänder sind bestückungsabhängig. Die beschriebene Empfangs- oder Sendeleistung wird nur im entsprechend bestückten Frequenzband erreicht. Auf den anderen Bändern ist trotzdem Betrieb möglich, allerdings mit eingeschränkten Eigenschaften. Bei meinen Messungen konnte ich allerdings feststellen, dass die Einschränkungen gar nicht so gravierend sind. Die externe Beschaltung des TRX-Chips sind lediglich ein paar Vorfilter und Anpassglieder. Die restlichen Filter sind im Chip realisiert und werden nachgeführt. Es gibt also nur wenige Stufen die das Signal dämpfen. In der Praxis sind ca. 20dB zwischen 2m und 70cm Unterschied.

Anton hat keine genaue Referenzfrequenz. Der Takt wird aus einem normalen Quarz erzeugt. Da ist auch nichts temperaturkompensiert oder der gleichen. Anton ist so abgestimmt, dass er bei Raumtemperatur (20°C) ziemlich exakt die Frequenz trifft. Bei anderen Temperaturen muss wegen des Quarzes nachjustiert werden. Das ist aber kein Problem, denn das Nachjustieren ist per Software möglich und zusätzlich rastet der Chip von selbst sehr gut aus dem Signal ein.

Wenn man einen Träger gefunden hat, von dem man ausgehen kann, dass er sehr stabil und sehr genau ist. dann kann man sich diesem Träger auch aufsynchronisieren. Per Befehl spuckt Anton den Frequenzunterschied vom Träger zum eigenen Arbeitspunkt aus. Für den Feinabgleich gehe ich aber umgekehrte Richtung. Ich bringe Anton zum Dauersenden und kontrolliere mit einem Frequenzzähler die Frequenz. Am einfachsten geht das mit einem günstigen DVBT-Stick und SDR. Damit kann man sich auch gleich das Spektrum der Aussendung ansehen.

Zu deiner letzten Frage: Anton, oder letztenendes der TRX-Chip ist nicht auf FSK festgenagelt. Er unterstützt 2- und 4-FSK, 2- und 4-GFSK, ASK, OOK, MSK und FM. PSK oder QPSK kann er nicht.

Viele Grüße und ahoi

Nico

[DG7GJ]

Hallo Nico!

das Hautaugenmerk von Anton liegt bei der Auswertung von Funktelegrammen. Er ist quasi ein gewöhnlicher Kontrollempfänger. Und da diese Funktionalität in Form von Software sehr kompakt ausgefallen ist, konnte ich noch ein paar Zusatzfunktionen in den MCU-Speicher bringen. So z.B. auch die Sendemöglichkeit.

Bietet sich ja auch an. Als MCU nur zur PLL-Steuerung und Auswertung hätte warscheinlich sogar ein ATMega8 gereicht.

Anton kann beliebige alphanumerische und numerische Nachrichten sowie Bytestreams an beliebige RIC's auf beliebigen Frequenzen senden. Damit ist er nicht nur in der Lage, DME's auszulösen, sondern auch Meldungen gezielt in ein Aussendenetz einzuschleusen. Die Funktion als DAU-Tester setzt natürlich eine gewisse Fachkenntnis von der Materie voraus und geht nicht out-of-the-box.

Jo, also schon mehr als der RCA4922/4923 kann, sauber!
Fehlt nur noch eine schaltbare Eichleitung vor der Antenne, um auch Empfindlichkeitstests nachvollziehbar zu tätigen.

Anton besteht im Grunde aus zwei Modulen. Dem HF-Modul und dem MCU-Modul. Das HF-Modul besteht im wesentlichen aus einem TRX-Chip und der zugehörigen externen Beschaltung. Der TRX-Chip ist normalerweise für Wireless-M-Bus geacht. Sowohl Frequenzen und auch Modulationsart werden aber für POCASAG unterstützt.

Aha, irgendein top moderner Chip, oder etwas bereits betagteres?
Ich habe da meinen Fokus nicht immer so drauf, aber irgendwie habe ich das Gefühl das die nagelneuen TRX-Chips da immer weiter in richtung Breitband gehen...WLAN, Bluetooth, wirelessUSB und UWB-Zeugs usw. :-(

Das MCU-Modul besteht aus der Stromversorgung und der MCU selbst. Ich habe bei der MCU auf einen ATmega168 zurückgegriffen. Also nichts besonderes mit viel Leistung oder Speicher und der gleichen. Die Kommunikation erfolgt über USB, wobei ich hierzu ein spezielles Kabel von FTDI verwende um seriell TTL sprechen zu können.

Für den Einsatz als mobiles Test- und Meßgerät ist USB schon OK.
Als stationärer Monitorempfänger hingegen denke ich automatisch an den abgesetzten (antennennahen) Betrieb. Und da ist das einzig senkrechte was auf Ethernet-Basis.
Selbst nur ne total veraltete 10Mbit Lösung ist bis heute noch mit allem kompatibel was RJ45 benutzt. Optional sogar Speisung via PoE 12-48V über das äusserste Adernpaar.

Die Frequenzbänder sind bestückungsabhängig. Die beschriebene Empfangs- oder Sendeleistung wird nur im entsprechend bestückten Frequenzband erreicht. Auf den anderen Bändern ist trotzdem Betrieb möglich, allerdings mit eingeschränkten Eigenschaften. Bei meinen Messungen konnte ich allerdings feststellen, dass die Einschränkungen gar nicht so gravierend sind. Die externe Beschaltung des TRX-Chips sind lediglich ein paar Vorfilter und Anpassglieder. Die restlichen Filter sind im Chip realisiert und werden nachgeführt. Es gibt also nur wenige Stufen die das Signal dämpfen. In der Praxis sind ca. 20dB zwischen 2m und 70cm Unterschied.

OK, dann schätze ich mal das die Selektivität auch in Punkto Blocking und spektrale Reinheit zuzüglich Sender-Intermodulation nicht wirklich rosig aussieht, oder?
Aber gut, ich sehe das Teil eh eher als eine Art "Pocsag-Multimeter" für den Werkzeugkoffer.
Da ist das dann nicht so schlimm.

Anton hat keine genaue Referenzfrequenz. Der Takt wird aus einem normalen Quarz erzeugt. Da ist auch nichts temperaturkompensiert oder der gleichen. Anton ist so abgestimmt, dass er bei Raumtemperatur (20°C) ziemlich exakt die Frequenz trifft. Bei anderen Temperaturen muss wegen des Quarzes nachjustiert werden. Das ist aber kein Problem, denn das Nachjustieren ist per Software möglich und zusätzlich rastet der Chip von selbst sehr gut aus dem Signal ein.

Wenn man einen Träger gefunden hat, von dem man ausgehen kann, dass er sehr stabil und sehr genau ist. dann kann man sich diesem Träger auch aufsynchronisieren. Per Befehl spuckt Anton den Frequenzunterschied vom Träger zum eigenen Arbeitspunkt aus. Für den Feinabgleich gehe ich aber umgekehrte Richtung. Ich bringe Anton zum Dauersenden und kontrolliere mit einem Frequenzzähler die Frequenz. Am einfachsten geht das mit einem günstigen DVBT-Stick und SDR. Damit kann man sich auch gleich das Spektrum der Aussendung ansehen.

Gut, da währe theoretisch also noch ein bisschen Aufrüstpotential.
Denn wenn man im Kundendienst eben einen Frequenzabgleich macht, ist es nicht so praktisch erstmal irgendwo einen frequenzstabilen Träger zu zaubern um sein Testgerät ab zu gleichen..:-)
Mindestens TXCO, besser noch gleich eine Schnittstelle für GPS oder Rb-Referenz.

Zu deiner letzten Frage: Anton, oder letztenendes der TRX-Chip ist nicht auf FSK festgenagelt. Er unterstützt 2- und 4-FSK, 2- und 4-GFSK, ASK, OOK, MSK und FM. PSK oder QPSK kann er nicht.

Hübsch! Und das alles on Chip? Es handelt sich dabei nicht etwa um den sündhaften CMX71xx? Ne, glaube kaum...der hat ja nix mit wireless M-Bus zu tun.

Danke für deine Infos, schön zu sehen das sich heute noch einzelne Menschen richtig in die Hardware knien für solche Projekte.

BTW: Hast du schonmal in richtung SAMS überlegt?
Ein anständiges Frontend, sowie auf nem zweiten MCU und massig RAM oder Flash einen Master/DAU/Papagei, so richtig mit Zeitschlitzkonfiguration und sortierung der Dringlichkeit verschiedener Nachrichtentypen.
Im Amateurfunk gibt es sowas seid Jahren nicht mehr.
Das letzte Projekt von dem ich weis, eine Art RPC-Nachbau, basierte leider auf einem im sterben liegenden Phillips-µC. Gab nur wenige hundert Platinen bis es den µC nirgendwo mehr gab. Und seid heute will da niemand die Firmware für auf einen ATMega portieren..:-(

Du hingegen scheinst dich ja in das Pocsag-Protokoll hinreichend reingehängt zu haben, so das es für dich wohl ein eher kleineres Problem wäre da was zu entwickeln.
Eben ein All-in-One Pocsag-Prozessor der je nach Konfiguration wahlweise als Master, als DAU oder nur als intelligenter Papagei arbeiten kann.
Könnte das SAMS-Projekt eventuell richtig pushen.

Grüße aus Dortmund

Jürgen Hüser