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

Und mal wieder guten Morgen Bernd!

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...).

Quote from Mikrocontroller.net

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...

Quote from Bernd666

Moin Maskey,

du hast recht. Eigentlich werden die zu sendenden Bytes einfach so auf die Leitung gelegt.

Das grundlegende Problem ist bei so einem Byte: 0111 1111 sieben lange Bits kein Flankenwechsel statt findet. Da kann schon mal die Synchronität leiden, weil man ja keinen Takt regenerieren kann. Da kann man was gegen machen. Z.B.: nach 5 Highbit wird zwingend ein Lowbit eingefügt. Das muss man aber dem RX auch per Checksumme mitteilen. Aber das führt zuweit...

Aber du kann ja an dem anderen Pin einen Takt mitliefern. Dadurch wird es einfacher.

Du musst also einen Takt generieren der bei jeden Flankenwechsel ein Bit deines Bytes schickt.

Zu beachten ist auch noch, ob es Start und Stop-Bedingungen gibt.

Nur zur Erinnerung: Ich kann KEIN Python und habe nicht wirklich Zeit und Lust mich in diesen Baustein einzulesen.

Gruss Bernd

Display More

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.

Quote from Bernd666

Moin Maskey,

Noe, der RPi hat an den GPIO-Pins auch nur 3,3V!!! Und er darf da auch nicht mehr!!! Sonst isser putt

Du hast weder die Frequenz, die Betriebsart noch sonstwas an dem Modul angestellt.

Ich behaupte mal: Du hast dir das Datenblatt des Moduls nicht richtig angesehen.

Zumindest bist du dir über die Nutzung des Continuous-Modus nicht im klaren.

Vorschlag: Kläre erstmal die Theorie und dann programmiere.

Gruss Bernd

Display More

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.

#!/usr/bin/python
 
import os
from time import sleep
 
device='/dev/spidev0.0'
devaddr=0x40
 
def write(device,deviceaddress,register,byte_data):
    handle=open(device, 'w+')
    try:
        data=chr(deviceaddress)+chr(register)+chr(byte_data)
        handle.write(data)
        handle.close
        return True
    except:
        print("Unable to write to SPI Bus")
        return False
delay=0.1
#Sendeleistung
write(device,devaddr,0x11,0x8F)#10001111
sleep(delay)
#Continuous mode aktivieren 
write(device,devaddr,0x02,0x40)#01000000
sleep(delay)
#Transmitter Mode fuer 2 Sekunden aktivieren 
write(device,devaddr,0x01,0x0C)#00001100
sleep(2)
write(device,devaddr,0x01,0x04)#00000100
#Muesste theoretisch nur nullen senden, da der Pi noch keine Signale gibt

Für meine Anwendung benötige ich also den "Continuous Mode", wenn ich das Modul quasi mit vorgegebenen Bits "füttern" möchte.

Gut ich werde mal ein paar Versuche Starten und mich dann wieder melden.

Muss das Modul eigentlich bei jedem "Neustart" wieder neu programmiert werden oder bleiben die gesetzten Variablen erhalten?

Quote from hyle

Vielleicht hilft Dir das hier weiter: https://rpi-rfm69.readthedocs.io/en/latest/

In der Config.py Datei finden sich die angesprochenen Adressen die einprogrammiert werden. Da kann ich nachprüfen welche Adressen wichtig sind. Ist also schonmal hilfreich. Danke!

Aber wie genau ich den Sender Ansteuern muss habe ich noch nicht raus gefunden...

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-…griff-mit-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.

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