ATMEL vs. POCSAG ?!

[tower911]

wir hatten das schonmal nen thread da tauchten auch Atmel´s auf. Ob da auch der atmega dabei war kann ich dir auch nicht sagen. Benutz mal die board suche

[funkwart]

in diesem thread hattest Du, wenn ich mich recht entsinne, gesagt, Du wolltest das Ganze mal von PIC auf Atmel umstricken. Hast Du da was erreicht?

Gruß,
Funkwart

[pg-man]

Hallo funkwart,

ich habe einen Pocsag Gateway auf ATmega8 Basis entwickelt.
Layout / Software sind soweit funktionsfähig. Das Gerätchen decodiert zuverlässig POCSAG Messages mit 1200 Boud.

Diese können seriell ausgegeben werden. (RS232) oder mit einem onboard Netzwerk Port direkt per Telnet an einen Server gesendet werden. Alternativ sind auch HTTP GET Requests an einen Webserver möglich um z.B. mit einem dort aufgerufenen PHP Skript die Daten in eine MySQL Datenbank schreiben zu können.

Die Empfangenen Daten werden mit der BCH Prüfsumme und dem Pariätsbit geprüft. (keine Fehlerkorrektur). Es ist daher sehr unwahrscheinlich falsche Daten auszuwerten.
Pocsag Gateway auf Atmel ATmega8 Basis


Ich hänge mal Bilder davon an.

Aktuell arbeite ich noch weiter an der (Assembler) Software.

Da man die Software natürlich in viele Richtungen weiterentwickeln kann, möchte ich die Frage stellen, was ihr euch so für Funktionen wünschen würdet.

Beispiele noch nicht umgesetzter Funktionen:

- Filterung der eingehenden Messages (z.B. kein Netz/Zeit-Ric übertragen)

- Auslösen z.B. von Piep Alarm bei bestimmten RIC´s (wie Melder)

- SMS: (über HTTP Internet Gateway ... gibt da ein sehr günsiges und gutes)
das könnte direkt in den Atmel integriert werden oder über eine PHP Skript auf einem Webserver abgehandelt werden. (wie oben beschrieben)

a) Direkten versenden von SMS bei Alarmierung bestimmter RIC.
Versand an mehrere Empfänger bzw. Gruppen
b) SMS Versand bei bestimmten Stichworten

- Konfiguration des Gateway per serieller Schnittstelle mit Terminal oder Telnet session ... / Alternativen?

- 512 Boud Datenrate / Auto Erkennung bzw Umschaltung per Config oder Jumper

- Erkennung "invertiert" ankommender Signale / Umschaltung per Config oder Jumper

Demnächst bekomme ich noch einen sehr kleinen FM Receiver, der sich voraussichtlich auch noch in das Gehäuse einbauen lässt so daß dann noch eine kleine Antenne rausschaut und damit dann dann der Funk zu Netzwerk Gateway perfekt ist ...

Grunsätzlich habe ich vor bei Interesse Layout und Software zu veröffentlichen. Ein komplettes "Paket" mit allen benötigten Daten und Dateien gibt es aber noch nicht.

Ein angemessener "Unkostenbeitrag" währe allerdings wünschenswert, darüber muss ich mir aber noch Gedanken machen.

Jetzt bin ich mal auf Rückmeldungen gespannt!!

[Freakmaster]

*Interesseanmeld* ;)

[alarma]

durchaus interessanter ansatz !
aber für mich erst ab 512 Bd nutzbar :-)

eine sehr interessante sache wäre man vor bzw. hinter die seriellen daten noch eigene (individuelle) strings setzen könnte.
dann könnte man damit auch (groß)displays ansteuern.

in der form: Befehl an display
("gleich kommen daten")+(nutz text aus den meldungen)+(ende der daten erreicht)

Frage:
Sind beide Ports gleichzeitig nutzbar, oder muss man sich für eine variante entscheiden ?

[Freakmaster]

Momentan nur RS232 oder Netzwerk. Wird mit einem Jumper umgeschalten.

Obs anders geplant is - ka!?

[pg-man]

Wegen RS232 / Netzwerk .. stimmt nicht ganz.
Daten die vom Atmel ausgegeben werden, können gleichzeitig über Seriell und Netzwerk gesendet werden. Nur der umgekehrte Weg, also z.B. der Zugriff auf den Atmel zum Konfigurieren oder zukünftig evtl. auch Updaten geht nur über einen Anschluss und wird mit dem Jumper umgeschaltet.

Theoretisch könnte der XT-Nano Netzwerk Port auch über SPI oder I2C angebunden werden, damit könnte er völlig unabhängig vom seriellen Anschluss betrieben werden. Das würde aber einen erhöhten Programmieraufwand bedeuten daher habe ich in dieser Richtung noch nichts unternommen

Ich hänge mal einen aktuellen Schaltplan an, daraus dürfte das hervorgehen.

Die Definition von zusätzlichen Strings vor und nach dem eigentlichen Text bei der Ausgabe ist momentan nur direkt im Assembler Programmcode möglich. Das wäre aber ein Punkt den ich auch gerne über eine serielle Konfigurationsoberfläche einstellbar machen möchte.

Falls jemand unter euch ist, der in Assembler einigermaßen fit ist, würde ich gerne mal die Software mit demjenigen durchsprechen um vielleicht noch etwas Anregungen zu bekommen wie der Code optimal gestaltet werden könnte.

Die 512 Baud konnte ich bisher noch nicht testen. Wenn man im Program die Sample-Rate umstellt dürften sich 512 Baud aber auch ohne Probleme decodieren lassen.