Posts by Maskey

    Hallo nurazur,

    Bei meinem Projekt kommt das so genannte POCSAG-Protokoll zum Einsatz. Das ist ein Protokoll, das für die Übertragung von Texten an Funkmeldeempfänger (Pager, oder einfach nur "Piepser") genutzt wird.

    Ich habe also einen Klartext, der erstmal von einem selbst geschriebenen Script in folgende Stücke zerhackt wird:

    Präampel(576 Bit 10101010....), Synchronwort, 8x Batch, wieder Synchronwort, 8x Batch usw....

    So eine Nachricht ist schnell mal 3000 Bit lang oder wesentlich länger (kann beliebig lang sein).

    66 Byte reichen leider nicht aus für meinen Zweck. Allein die Präampel ist schon länger (!)…

    Deswegen der Continuous Mode... da komm ich nicht dran vorbei.

    Quote

    Wenn das Modul den Takt vorgibt, kann das ziemlich schnell nach hinten losgehen, da beim Raspberry ein Betriebssystem läuft das u.U. die Prioritäten ganz anders setzt, und moeglicheweise genau dann wenn es auf den Takt des RFM Moduls reagieren müsste gerade keine Zeit hat. Du hast allerdings die Moeglichkeit die Taktrate des RFM Moduls per Register einzustellen.

    Das könnte gerade so ausreichen, da das POCSAG Protokoll relativ langsam ist mit gerade einmal 1200 b/s.

    Ich nutze auch keine time.sleep Befehle, sondern einen Dummy-Befehl "Variable = 1" in einer While Schleife, die ständig wieder den Pin Status abgreift (man muss eben mindestens einen Befehl in einer while Schleife haben). Das sorgt für eine hohe CPU-Auslastung, aber man kann sich relativ sicher sein, das die Abfrage oft genug durchläuft.

    Quote

    Du musst dir also über Antennen genaue Gedanken machen, eigentlich kommen bei der kleinen Masse nur Dipol Antennen infrage. Die gekauften Stummel brauchen auch alle ordentlich Massefläche, sonst funktionieren die nicht richtig.

    Groundplane. Die bringt ihre Masse selber "mit" :)

    Quote

    Und so weiter, und so fort...ich koennte locker ein Buch darüber schreiben. Vielleicht tue ich das sogar einmal.

    Warum nicht?

    Ich könnte so ein Buch im Moment gebrauchen :P

    Und mal wieder guten Morgen Bernd! :D

    Also das Modul müsste über MISO auf jeden Fall ein ACK zurück geben, je nach dem was man eben geschrieben hat. Das wird aktuell einfach von Pi ignoriert, da ich ja im reinen Schreibzugriff auf die Rückmeldung verzichten kann.

    Ich teste das erstmal mit einem Script, das nur Pegelveränderungen registriert und die Nullen und Einsen notiert. Wenn garnix raus kommt kann ich gleich mit dieser Variante aufhören und brauche dann eine richtige API wie "WiringPi"(soweit ich weiß konnte die SPI...).

    Continuous Mode

    Für die Datenübertragung vom/zum Modul werden die beiden Pins "DIO1/DCLK" und "DIO2/DATA" verwendet. An DCLK gibt das Modul den Takt vor mit dem die Datenbits an DATA geschrieben oder gelesen werden müssen.

    Also es ist eindeutig beschrieben. Das Modul muss den Clock vorgeben.

    Ich habe jetzt mein Programm erweitert, so dass es mit einem vorgegebenen Clock bei fallender Flanke das nächste Bit nachschiebt.

    Das funktioniert auch. Habe mal von Hand einen Takt gegeben.

    Das Problem: Dieses Modul gibt einfach keinen Clock aus, obwohl es das eigentlich sollte.

    Ich verstehe das einfach aktuell nicht mehr... ^^

    Ich suche nochmal in den Beispiel-Bibliotheken wie das andere gemacht haben. Da kann doch nur irgend eine wichtige Einstellung fehlen...

    Vielleicht funktioniert auch einfach diese SPI-Kommunikation nicht, und es werden gar keine Befehle so richtig ans Modul weiter gegeben? Vielleicht sollte ich es mal mit einer richtigen SPI-Api versuchen...

    Hallo Bernd,

    ja, ich verstehe das Problem mit den "zu langen" Signalen. Das was Du ansprichst, scheint in dem Modul der so genannte "3.4.13. Bit Synchronizer" auf Seite 31 zu übernehmen. er benötigt eine Präampel von 12 Bit und lässt keine gleichen Bitfolgen zu, die länger als 16 Bit andauern.

    (Zumindest habe ich das so raus gelesen)

    Ich habe eigentlich gedacht, dass das Modul einen DCLK an DIO1 ausgibt, je nachdem welche Bitrate man ins Register schreibt.... Das muss ich mal noch klären. Falls das Modul einen externen Clock erwartet, kann natürlich nichts funktionieren...

    Danke erstmal für den Tipp!

    LG Maskey

    Guten Morgen Bernd,

    Jetzt ist natürlich die Frage ob der Pi so ein NRZ Signal (+- 3,3 V) generieren kann.

    Zum testen müsste es doch theoretisch ausreichen, ein HIGH Signal an den DIO2 anzulegen, das das Modul eben erstmal nur Nullen oder Einsen sendet.

    Das geht natürlich nur, wenn der DIO2 keine Präambel/ bzw. Keine Startbits erwartet...

    EDIT1:

    Hab mich nochmal belesen. NRZ heißt nicht zwingend, dass es sich um einen positiven/negativen Pegel handeln muss. NRZ ist einfach die Standard Übertragungsmethode für Bits, die einem bestimmten konstanten Spannungspegel zugeordnet werden. Es wird sich beim DIO2 also um einen "normalen" logischen Eingang handeln, der z.B. bei ca. 0V ein "LOW" definiert und bei ca. 3,3V ein "HIGH", oder eben anders herum.

    Es gibt aber auch Beispiele mit negativen Spannungen.

    Bei der seriellen RS 232 Schnittstelle werden z.B. 1en mit -3 bis -15V und 0en mit +3 bis +15V übertragen (relativ große Bereiche. Bereich zwischen -3 und 3 ist undefiniert).

    Hallo Bernd,

    so wie ich das verstanden habe passiert im Continuous Mode folgendes:

    DIO1 gibt ein Clock Signal aus. Das kann z.b. im Raspberry Pi als Trigger genutzt werden, um das nächste Bit auszugeben. Auf DIO2 wird dann mit einem GPIO Pin ein HIGH oder LOW gegeben. Das Modul sendet dann in jedem Clock das entsprechende Signal.

    Soweit die Theorie.

    Aus dem von dir zitierten Ausschnitt geht zusätzlich hervor, daß es sich bei DIO 2 um einen bidirektionalen Pin handelt (hier ist noch zu klären warum) und das natürlich das Fifo und der Packet Handler aus geschaltet sind, da diese ja nicht benötigt werden.

    Kann also sein das das Modul noch einen Befehl über den DIO2 erwartet (?)...

    Kurzes Update:

    Beim Testen bin ich auf etwas interessantes gestoßen:

    Beim Anlegen einer Spannung von 3,3V an den Pin DIO5 sendet das Modul ein Dauersignal auf der Frequenz 433,999MHz mit einem Frequenzhub von ca. 60 kHz.

    Wenn gleichzeitig ein weiteres 3,3V Signal an einen der anderen DIO-Pins angelegt wird, sendet das Modul auf der reinen Trägerfrequenz ohne Frequenzumtastung.

    bisher habe ich dazu noch nichts im Datenblatt gefunden.

    Jedenfalls ist das schon mal das erste Lebenszeichen vom Modul. Letztendlich auch nicht die Lösung meines Problems, aber schon mal nicht schlecht. ^^

    Hallo Bernd,

    dann kann ich die Spannungsteiler ja wieder entfernen. Habe selber nochmal recherchiert und es sind tatsächlich 3,3V.
    Beim Arduino waren es glaube ich 5V, da habe ich was durcheinander gehauen...

    Die Register haben doch aber Standardeinträge und das Modul sollte grundsätzlich auch ohne große Einrichtung funktionieren. oder?

    Die "Betriebsart" ist meines Erachtens nach die Unterscheidung zwischen den Modi Sleep, Standby, Senden, Empfangen, usw.

    Ich habe mir das Datenblatt jetzt schon ein gutes Dutzend mal angeschaut und finde keine Lösung. Mit meinen Kenntnissen und Ideen bin ich nach sehr langer Problem- und Ursachensuche am Ende angekommen.

    Den Thread habe ich ja nicht aus langer Weile eröffnet. ;)

    Ich bin in der Zwischenzeit schon folgende Lösungsansätze durchgegangen:

    - Das Funkmodul nutzt eine 3V Logik, der Pi aber 5V:

    -> Spannungsteiler an jeden GPIO Pin, vor allem bei den SPI-Pins MOSI, MISO usw... (180Ohm / 180Ohm -> ergibt ca. 2,5V bei maximal 13,5 mA pro Pin, müsste für das HIGH Signal ausreichen)

    - Das Funkmodul ist defekt oder hat bereits Schaden genommen, da ich erst mit 5V getestet habe:

    -> neues Modul besorgt, diesmal mit Spannungsteilern, aber gleiches Problem.

    - Das Modul zieht im Transmitter Mode zu viel Strom für den Pi und die Spannung bricht zusammen

    -> Das Modul hängt jetzt an einem Labornetzgerät mit 3.3V und kann genügend Strom ziehen.


    Momentan habe ich keine weiteren Ideen zur Lösung des Problems. Ich könnte höchstens noch einen anderen Pi verwenden um auszuschließen, dass die Logik in dem aktuellen Pi defekt ist.

    Es kann jetzt eigentlich nur noch der Fall sein, das ich einen oder mehrere wichtige Registereinträge über SPI vergessen oder überlesen habe. Oder reicht es möglicherweise nicht aus, lediglich den Transmitter Mode zu aktivieren? Vielleicht muss noch ein zusätzlicher Befehl zum Senden gegeben werden?

    Soo, nun habe ich das besagte Modul an den Pi angeschlossen (GND, 3,3V, MISO, MOSI, SC, CLK, Pins wurden am Pi angeschlossen wie im Link im ersten Beitrag beschrieben) und u.g. Code mehrmals durchlaufen lassen. Fazit: es tut sich nix. Kein Signal wird gesendet. Habe einen Funkscanner nebenbei laufen lassen mit einem sehr breiten Wasserfall Diagramm, aber da kann ich kein FSK Signal sehen.

    Theoretisch wird im Modul zunächst die Sendeleistung angepasst, danach der Continuous mode aktiviert, schließlich der Sendermodus angeschalten, 2 Sekunden gewartet und am Ende wird wieder in den StandBy gegangen. Leider funktioniert das aber nicht so wie geplant...

    Kann mit jemand bei der Sache irgendwie helfen?

    EDIT1: Ich habe eine PNG-Datei mit einem einfach dargestellten Schaltplan angehängt, der die aktuelle Belegung der Pins beschreibt.

    Mit dieser Schaltung und dem u.g. Programmcode funktioniert das Modul aktuell noch nicht wie gewünscht.

    Hallo allerseits :^^:

    Ich habe momentan folgendes Raspberry Pi-Projekt:

    Ein String soll mittels eines speziellen Funkprotokolls codiert werden. Der entstandene String aus Nullen und Einsen soll per Funk wie folgt übertragen werden:

    - Frequenz: 433,92 MHz

    - Modulationsart: Muss unbedingt FSK sein

    -> Mit einem Frequenzhub von 4,5kHz und einer Baudrate von 1,2 kb/s

    Bisher bin ich so weit, dass die Nachricht korrekt in den besagten String umgewandelt wird, mit Präampel, Synchronwörtern, etc... das wird alles von einem Python-Script übernommen.

    Der nächste Schritt besteht jetzt also darin, den Code mit einem Sende-Modul auszusenden. Dazu habe ich mir heute ein RFM69HW über Pollin bestellt.

    Nun kommt das eigentliche Problem (bzw. die Herausforderung):

    Ich muss das Modul Programmieren und korrekt ansteuern und weiß noch nicht so recht, wie ich das in Python umsetzen kann.

    Ich habe im Datenblatt des Modules nachgelesen, dass es gewisse Adressen gibt, die man über SCI, MOSI und MISO programmieren muss.

    Hier das Datenblatt (ziemlich weit unten stehen die Adressen und die möglichen Einstellungen in Tabellenform):

    https://www.pollin.de/productdownloads/D810800D.PDF

    Dazu habe ich einen Beitrag mit Python-Script gefunden, der beschreibt, wie man relativ einfach über die besagte SPI-Schnittstelle Schreibzugriffe auf Module erzielt:

    http://www.gsurf.de/raspberry-pi-e…spi-und-python/

    Wie genau muss ich die Variablen in die Register des Modules schreiben?

    Wie genau übergebe ich dem Modul den String aus Nullen und Einsen? Das Modul soll selber nichts Codieren, sondern einfach den Code abarbeiten. Habe auch schon überlegt, das mit einer einfachen for-Schleife zu machen.

    Ich hoffe jemand kann mir Helfen. :helpnew:

    Hallo!


    Ich habe das gleiche Problem wie behoj. Ich benötige den Pin 7 (BCM Pin 04), um eine einfache Clock-Frequenz zu erzeugen.

    Habe gelesen, das 500MHz damit möglich sein sollen.

    Leider bekomme ich an dem Punkt "GPIO.setup(4,GPIO.ALT0)" die besagte Fehlermeldung, dass das angegebene Attribut nicht existiert.

    Ich suche jetzt schon seit Tagen nach einer Lösung aber finde einfach nix. Es muss doch möglich sein, diese Funktion des Pins zu nutzen, die ja auch überall beschrieben steht (?!).

    Ich hoffe Ihr könnt da weiter helfen.

    LG

    Maskey