Archiv verlassen und diese Seite im Standarddesign anzeigen : POCSAG-Decoder mit µC
DME-Murxer
05.05.2005, 18:01
Ich werde mich demnächst mit der Decodierung von POCSAG Signalen durch einen Mikrocontroller beschäftigen.
Um das Rad nicht neu erfinden zu müssen: Hat hier schon ein Experte hierfür Programme geschrieben. Das POCSAG Protokoll ist mir noch nicht ganz geläufig.
Z.Zt. gehe ich davon aus, dass ein Controller der 8051 Serie (Atmel ISP) ausreichend ist, wenn er direkt in Assembler programmiert ist.
Buebchen
06.05.2005, 09:58
Ich habe zwar keinen Link zur Hand aber im WWW findet man einige Hinweise und ach Beispiele zur POCSAG dekodierung. Ich meine sogar hier sind welche zu finden.
Was die Verschlüsselung angeht: Wenn der Key bekannt ist sollte es zu schaffen sein. Ansonsten brauchst Du da keine Mühen zu investieren. Selbst wenn du den Algorithms zu 100% richtig nachgebildet hast fehlt dir der Key.
"Pocsag decodierung mittels µC" lautet die Überschrift eines der Themen, in denen rx-pager.zip mit Funktion und Downloadadresse genannt wurde.
MfG
Frank
Buebchen
06.05.2005, 17:36
Beim IDEA den Schlüssel erraten ? Ich glaube dann könnte MediaCrypt wohl den Laden zumachen, wenn es so einfach wäre.
Falls Du an die Attacken auf WEP Schlüssel denkst:
Mich würde mal interessieren, ob SP immer den gleichen IV bei der Verschlüsselung benutzt. Wenn ja wäre das schon mal ein Anfang. Aber viel weniger als Brute-Force auf den 128 Bit Adressraum wird es wohl nicht geben.
Aber für einen guten Ansatz wäre ich immer zu haben. Auch wenn in meinem Umkreis (noch) nix verschlüsselt wird.
MiThoTyN
06.05.2005, 17:36
Original geschrieben von DME-Murxer
Betreffs Entschlüsselung: Selbstverständlich geht der von Swissphone gedachte Weg nur über den Key und den anschließenden Algorythmus, wobei die Daten mehrfach mit dem Key verschlüsselt werden.
Aber wie schon geschrieben, habe ich eine Idee, dies anders zu entschlüsseln. Ähnlich wie beim analogen Premiere-Hack, wo ebenfalls kein Key erforderlich war, kann ein Schlüssel auch "erraten" werden.
Hat sich hier vielleicht auch schon jemand Gedanken dazu gemacht?
Das musst du mir mal erklären. Bei Premiere war das durch nen Fehler im System möglich.
Bei Swissphone ist das soweit Wasserdicht. Es würde ja auch wenig Sinn machen eine dicke Verschlüsselung einzurichten, wenn sie umgehbar wäre. Du kannst die IDEA Verschlüsselung nicht umgehen. Schon mal gar nicht mit nem µC.
Such mal nach IDEA hier im Forum, da findest du einige Beiträge darüber.
Gruß Joachim
Hallo,
mich beschäftigt diese Sache mit dem Pocsag Decoder auch.
Hat da jemand schonmal irgendwie was gemacht mit einem µC?
Möchte gerne einen Dekoder bauen, an den ich das Signal vom Diskausgang anlegen kann, dieses dekodiert und in eine Log Datei schreibt.
Ich weiss der Thread ist alt, ich wollte aber keinen neuen auf machen :)
funkwart
09.02.2010, 07:32
http://pg.w-edv.de/
...oder bei OBI. ;-)
Gruß,
Funkwart
Bist du derjenige der das Teil gebaut hat?
Naja also das ist ja ne Fertig Lösung, ich würde gerne selber ein paar Sachen ausprobieren.
Die Source davon ist ja nicht veröffentlicht.
Angriffstrupp
09.02.2010, 09:58
Blöde Frage eines Unwissenden: Was kan man mit dem Teil anfangen???
http://pg.w-edv.de/
Das Teil kann POCSAG Signale dekodieren, ist also ein stand-alone Gerät und ersetzt FMS32-Pro. Man kann einen Scanner o.ä. anschließen und das Teil übernimmt die Funktion der Dekodierung.
Man braucht also keinen PC dazu, das finde ich gut.
Man könnte die Alarme beispielsweise auf dem µC loggen.
funkwart
09.02.2010, 10:05
Nein, ich bin nicht derjenige, der das Teil gebaut hat. Sollte auch keine Werbung sein.
Es gibt aber ein paar Aufschlüsse über die POCSAG-Dekodierung mittels Atmel.
Zur Frage, was das Ganze kann bzw. macht, zitiere ich die von mir genannte Seite, da Ihr es wohl überlesen habt:
Das Projekt enthält Schaltplan / Layout und Software eines Atmel ATmega32 AVR basierten Pocsag Decoders der die decodierten Daten seriell und optional über Netzwerk ausgeben kann.
Im Netzwerkbetrieb kann sowohl eine einfache "telnet" Session aufgebaut werden als auch eine Datenübertragung per HTTP GET Request ausgeführt werden.
Die Decodersoftware berücksichtigt die im Pocsag Standard enthaltene BCH Fehlerkorrektur und das Paritätsbit zur Erkennung fehlerhafter Datenframes.
Damit ist der Empfang von fehlerhaften Daten sehr unwahrscheinlich.
Stöbert doch einfach mal ein wenig auf der Seite, bis auf die Software selbst ist wenig geheim gehalten.
Gruß,
Funkwart
PS: Ich frage mich, ob man für ein solches Projekt nicht auch das AVR-NET-IO von Pollin einsetzen könnte, weil es a) einen Atmel beinhaltet und b) eine Netzwerkschnittstelle onboard hat.
Angriffstrupp
09.02.2010, 10:13
Aha...und das kommplette Fertige Gerät ist dann wie Teuer? Kann mir das auch jemand sagen?
@funkwart
Okay, dann werde ich da nochmal durcgucken.
Und zu dem Avr von Pollin, stimmt eigentlich sollte das ja auch gehen.
Mal sehen was da fürn Atmel verbaut ist.
edit:
Also die Schaltung ist ja dargestellt aber wie das alles Softwaremäßig umgesetzt ist kann man ja daraus nicht ersehen, ich hab auch noch keine Vorstellung davon wie aufwendig sowas ist.
funkwart
09.02.2010, 10:49
@ Angriffstrupp: http://pg.w-edv.de/23.html
@ Krümel: Im AVR-NET-IO ist auch ein Atmega32 verbaut, ebenso wie in der genannten Schaltung. Zum Dekodieren hilft evtl. http://www.qsl.net/n9zia/wireless/pager/rx-pager.zip
Das ist zwar für PIC, aber die Software des AVR-Dekoders soll auch daraus entstanden sein. Alternativ einfach den PIC mit der genannten Software laufen lassen und den Output in den AVR-NET-IO einspeisen zur Weiterverarbeitung.
Gruß,
Funkwart
ja okay, wäre mal ein versuch wert.
Wenn jemand noch an sowas dran ist oder aufgebaut hat, kann er sich gerne melden ;)
EIB-Freak
09.02.2010, 19:10
Ich habe diesen Pocsag-Dekoder aufgebaut, und auch mal testweise in Betrieb gehabt.
Abgesehen davon, das Onboard auch ein FM-Receiver aufgelötet werden kann und die Platine wahlweise mit LAN-Anschluss oder Seriell kommunizieren kann, sitzen auf der Platine noch 3 Relais, die kleine Lasten oder weitere Relais schalten können.
Mein Testgerät wertet derzeit eine Handvoll Test-RIC`s aus, schreibt die in ne mySQL-Datenbank per PHP und je nach Test-RIC würde dann eine entsprechende SMS über sms77.de verschickt werden.
Mein Dank hierbei noch an den Entwickler, der mich sehr, sehr gut unterstützt hat.
Demnächst geht das ding in den Wirkbetrieb (würde man bei Tetra sagen...).
Ja das mit dem FM receiver ist eine tolle Sache.
Hast du dir den Atmega also programmieren lassen oder wie hast du das gemacht?
Mit den Daten in eine Datenbank schreiben, finde ich auch sehr gut.
Kannst du noch ein bisschen mehr dazu schreiben?
EIB-Freak
09.02.2010, 19:25
Vieles kann der der schon von haus aus, der könnte sogar von haus aus SMS verschicken, bei mir allerdings ging das nicht ohne weiteres.
Mehr schreiben - nun ja, was wäre interessant?
Platine hat Europakartengröße, reichlich platz und Lötaugen für Erweiterungen,
Backup-Batterie, IC`s gesockelt, ....
Im zweifelsfall einfach mal kontakt mit dem entwickler aufnehmen, Link zur Homepage wurde nun ja schon mehrere male gepostet.
funkwart
10.02.2010, 09:17
Mich schreckt vor allem der Preis für die Netzwerkkomponente ab. Daher würde mich unbedingt die Möglichkeit interessieren, das Ganze auf einem AVR-NET-IO von Pollin zu realisieren. Das geht aber nicht, wenn der Sourcecode nicht offenliegt. Ich hatte diesbezüglich schonmal Kontakt zum Entwickler aufgenommen, aber er hat nicht "angebissen". Schade drum.
Hat schon jemand hier Erfahrungen mit dem "rx-pager.zip"-Dekoder?
Gruß,
Funkwart
Ja finde ich auch ein bisschen happig.
Hab die rx sache noch nicht ausprobiert, dazu müsst ich mir dann ja erstmal den PIC besorgen und ne Schaltung zum "brennen" aufbauen.
Mit PICs hab ich noch weniger Erfahrung als mit µC's :)
Stimmt der Sourcecode wäre schon ein Schritt in die richtige Richtung.
Schade drum.
Ich hab aber auch noch ne Mail geschrieben ;)
DME-Murxer
10.02.2010, 18:45
....
Hat schon jemand hier Erfahrungen mit dem "rx-pager.zip"-Dekoder?
Gruß,
Funkwart
Ja. Ich habe das Ding mal spaßeshalber gebrannt / gelötet und ausgetestet. Es funktioniert einwandfrei, bin aber nicht an die Grenzen der Auswertemöglichkeit gegangen.
Wie kann man son PIC brennen? Und wie kommt man an den PIC, hab mal bei ein paar Dsitributoren wie Reichelt nachgeguckt, finde den aber nicht.
DME-Murxer
11.02.2010, 14:37
Wie kann man son PIC brennen? Und wie kommt man an den PIC, hab mal bei ein paar Dsitributoren wie Reichelt nachgeguckt, finde den aber nicht.
Brennen bedeutet bei einem PIC natürlich Programmieren. Dazu benötigt man ein PIC-Programmiergerät. Als PIC habe ich den 16F84 von Reichelt besorgt.
funkwart
11.02.2010, 14:38
Ich habe da mal recherchiert.
Du findest ne Menge Informationen zur PIC16x8x-Prozessorfamilie unter: http://www.pictutorials.com/index.htm
Dort steht auch, dass der 16F84 eigentlich identisch zum "c" ist, aber mit Flash-basiertem Speicher arbeitet. Sollte also auch gehen.
Unter http://www.sprut.de/electronic/pic/brenner/index.htm findest Du viele Dinge rund um PIC-µCs. Unter anderem auch 8 verschiedene Programmer!
Wenn Du dabei gehst, sag mal Bescheid. Ich würde ebenfalls einen (oder zwei) davon brennen wollen.
Gruß,
Funkwart
ja ich muss mir die porgrammierung mal genau anschauen.
wie das mit dem proggen funktioniert.
Schade, hab mir gerade as STK500 von Atmel besorgt und kann da ja jetzt bei dem thema nicht so viel mit anfangen...
funkwart
11.02.2010, 15:42
Ich bin da jetzt auch nicht so wirklich sattelfest, aber normalerweise sollte es doch eigentlich möglich sein, einen Assembler-Code von einem PIC auf einen Atmel zu übertragen.
Man müsste zunächst einen Vergleich der Befehle anstellen.
Dann müsste man das Timing neu berechnen.
Anschließend kann man sich dann daran machen und die Programmroutinen "umbauen".
Vielleicht haben wir ja ein paar µC-Spezis hier im Forum?!
Aber für den Anfang sollte erst einmal ein gebrannter PIC her, mit dem man dann den Atmel "füttern" kann.
Gruß,
Funkwart
... und erstmal verstehen was der assemblierte Code genau macht.
funkwart
12.02.2010, 11:37
Ich habe zum "Verstehen" des Prinzips eine Erklärung zum Dejan-Programm gefunden unter:
http://www.mikrocontroller.net/topic/149365
Ich blicks noch nicht ganz, aber das kommt bestimmt noch...
Gruß,
Funkwart
PS: Ist hier einer, der mir das Dejan-Programm mal auf einen PIC16F84 machen kann? Bitte per PM melden!
Ja, ich hab da ja auch nachgefragt, das mir das jemand mal erklärt :-)
Ich war derjenige, der das nachgefragt hat :-)
Wenn jemand da is der Pics brennen kann, ich würde auch einen nehmen. :)
Hi,
also einfach mal ein paar Bemerkungen von mir in den Raum geworfen...
1.) Zu dem Portieren von Assembler Coder Pic <-> Atmel!
Das Portieren von Assembler Code zwischen zwei Systemen ist eine Wahnsinnig schwierige Sache. Um welten Komplizierter als z.B. bei C!
Es sind nicht nur ein paar Befehle anders...
Bei Assembler ist ja gerade die Besonderheit das dieser Extrem Hardwarenah ist und auf dei jeweiligen Möglichkeiten der CPU für die er gedacht ist 100% abgestimmt. Man arbeitet ja direkt mit Speicheradressen, Bankumschaltungen, SFRs usw. Zudem haben die verschiedenen Assembler oft auch einen völlig anderen Befehlsvorrat!
Der Sinvollere Weg zum Portieren währe hier den vorhandenen Code zu analysieren und verstehen was der überhaupt wie macht. Und dann nimmt man dieses Prinzip und programmiert das komplett neu für das neue Zielsystem.!
2.) Zum Pic Proggen: Das ist Kinderleicht - gerade beim 16F84, es gibt massig Programmierschaltungen im Netz. Die einfachste kommt mit drei oder vier Bauteilen aus. Kommerzielle Programmer kosten so ab 30 Eur.
3.) Zum Pic 16F84 selber... Der Pic16F84 ist der direkte Nachfolgetyp des 16C84. Für den Anwender gibt es keinen Unterschied. Nur der interne Programmspeicherzugriff läuft anders. Die ersten 16F84 wurden sogar als 16C verkauft...
ABER: Der 16F84 ist asbach Uralt und total überholt. Dazu noch viel zu teuer...
Es gibt schnellere CPUS dieser Serie die noch mehr Möglichkeiten haben und deutlich weniger kosten. Und das beste ist: Mit minimalsten änderungen läuft auch der 16F84 Code...
Will man nur etwas nachbauen ohne selbst am Programm etwas zu machen, klar, da nimmt man den alten F84, die zwei Euro Mehrkosten sind ja auch nicht die Welt und mehr Funktionen als das Programm verwendet braucht man nicht.
Wenn jemand aber wirklich mit PICs anfangen möchte -> zu einem anderen Greifen!
(Für Assembler: 16F628, 16F88, 16F78x usw, für C 18F, oder wenn es ganz was besonderes sein soll 24F oder 32...)
Gruß
Carsten
Edit: ICh kann übrigends alle gängigen PIC und fast alle Atmel µC programmieren!
Wenn sich also jemand den Programmer Selbstbau nicht zutraut...
Der einfachste Weg wäre also einen neuen Code auf Basis eines AVR's zu programmieren.
Ich habe schonmal Assembler für nen Motorola AVR programmiert bzw. da bin ich im Studium mit eingestigen, C noch nicht wirklich für einen Avr
Was ist besser?
In C programmieren, oder in Assembler?
Hi,
Was ist besser?
In C programmieren, oder in Assembler?
Das kommt darauf an wie du den Dekoder aufbauen möchtest...
Hast du einen richtigen Modem Chip drauf der dir direkt aus dem Signal ein Datentelegramm erzeugt, das du mit dem µC nur noch interpretieren möchtest, dann ist C auf jeden Fall das mittel der Wahl. ISt viel schneller und einfacher...
Assembler funktioniert hier aber auch!
Arbeitest du OHNE Modemchip, also der µC ist selber, ggf. unter Zuhilfenahme von ergänzungshardware, der Demodulator, dann ist ohne Assembler nichts zu machen. Im reinen C wird das verdammt schwierig wenn nicht gar unmöglich!
(Wg. dem Timing!) Was natürlich geht ist C mit eingebetteten Assembler Code!
Gruß
Carsten
Nein also ich möchte direkt an den µC dann das Dsikriminator Signal anlegen.
also wenn du direkt mit dem Disk Signal auf den µC gehen willst, (wobei ich doch annehme das Direkt nicht wirklich direkt heist und du noch ein wenig Zusatzhardware spendierst) dann geht es nicht ohne zumindest etwas assembler!
Der reine "Erkennungsteil" muss ganz exakt getimt sein. Und das geht NUR mit Assembler.
Btw. Wie möchtest du denn Auswerten? Flanken über ST und dann auf den Timmer Eingang um die Pulslänge zu zählen?
GRuß
Carsten
Ja, im Prinzip muss ich ja mit einem Timer arbeiten und meinen Datenstrom dann nach Präamble und richtigen Daten absuchen.
Assembler scheint am sinnvollsten.
Ich denke auch das ich da noch etwas zusatzhardware brauche und nicht direkt auf den µC kann. Aber das guck ich mir einfach bei dem Pic ab oder dem anderen Projekt, das weiter oben m Thread steht, da gibts einen Schaltplan zu.
DME-Murxer
12.02.2010, 19:19
Ja, im Prinzip muss ich ja mit einem Timer arbeiten und meinen Datenstrom dann nach Präamble und richtigen Daten absuchen.
Assembler scheint am sinnvollsten.
Ich denke auch das ich da noch etwas zusatzhardware brauche und nicht direkt auf den µC kann. Aber das guck ich mir einfach bei dem Pic ab oder dem anderen Projekt, das weiter oben m Thread steht, da gibts einen Schaltplan zu.
Ich kann dir da nur einen Schmitt-Trigger mit einem LM741 o.ä. OP mit einem Elko zur Gleichstromentkopplung am Eingang empfehlen.
Hallo,
ich kram das hier nochmal aus.
Hat sich jemand mit dem Thema noch näher auseinander gesetzt, bzw. ist da gerade vielleicht jemand dabei so einen Dekoder aufzubauen?
Mir fehlt leider ein wenig Know-How das ganze so alleine durchzuziehen. Würde da aber gerne was lernen in punkto Dekodierung.
Auch wenn der Thread eigentlich schon sehr lange her ist, hat es denn mal jemand geschafft Meldungen zu entschlüsseln ? Oder arbeitet da noch jemand dran ?
Tendenziell hatte ich das auch mal verfolgt, bin aber zwischenzeitlich zu ner Lösung mit dem Raspberry Pi gewechselt
Gesendet von meinem D5803 mit Tapatalk
Kannst Du Mir das mal genauer erläutern ?
Du brauchst "nur" einen Raspberry Pi mit einem DVB-T-Stick, dazu das Tool boswatch (https://github.com/Schrolli91/BOSWatch) und schon hast du alles was du brauchst.
Powered by vBulletin® Version 4.2.3 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.