RFM69 OOK - ein Bit zuviel zwischen Transmissions

[Markus P. (teschi)]

Hallo beisammen,

ich will mit dem RFM69CW Nachrichten per OOK verschicken und habe den 
Effekt, dass nur der erste Frame "korrekt" verschickt wird,
für alle fortlaufenden Frames fügt der RFM69CW ein zusätzliches 
(Start?-)Bit ein.

Falls jemand eine Theorie hat, was dazu führt und wie man das 
abschaltet, wäre ich dankbar.
Ich hab zwar 'nen Workaround, würde aber doch gerne verstehen was da 
passiert. Beim Datenblatt-wühlen bin ich bisher nicht fündig geworden.

Hier ein paar Details:
* Der RFM69 ist im PACKET-Modus, Variable-länge, Präambel=aus, 
Sync-Bytes=aus, CRC=aus
* Der erste Frame wird immer korrekt "genau so" übertragen, wie ich das 
in die FIFO geschrieben habe
* Wenn das letzte Bit der ersten Übertragung == LOW, dann wird ein 
zusätzliches HIGH-Bit vor der zweiten Übertragung eingefügt.
* Scheinbar wird das Bit immer eingefügt, aber der Pegel ist abhängig 
von dem letzten Bit der letzten Übertragung.
* Ein wechsel nach STANDBY zwischen den Übertragungen ist KEINE Abhilfe 
gegen das senden des zusätzlichen Bits
* Ein wechsel nach SLEEP zwischen den Übertragungen behebt das Problem, 
und bei der nächsten Übertragung gibt es kein zusätzliches Bit.

Mein Workaround:
* Aktuell wechsle ich halt immer kurz nach SLEEP, danach passt alles 
wieder.


Sagt das jemanden was?
Ist das Standardverhalten, oder kann man das abschalten?

Vielen Dank schon mal
  Teschi

[Markus P. (teschi)]

P.S.:
Noch mehr Details (falls es jemanden interessiert):

Ich habe einen Testcase gebastelt, der 3x3 Frames (mit kurzen pausen) 
verschickt:
Die 3 Frames sind jeweils:
 a) 0x3C, 0xAA, 0x0C (endet mit 0)
 b) 0x3C, 0xAA, 0x0D (endet mit 1)
 c) 0x3C, 0xAA, 0x0C

Die Testcases sind:
 1) Schicke die 3 Frames ohne den TX-Modus zu verlassen
 2) Schicke die 3 Frames und wechsle dazwischen nach STANDBY
 3) Schicke die 3 Frames und wechsle dazwischen nach SLEEP

Ich hänge mal an:
 * Den Arduino Sketch
 * Pulseview Aufzeichnung (inkl. dem kompletten SPI-Traffic)
 * Oszi-Bilder (Gelb: separater 433Mhz Empfänger, Blau: DATA an 
Pin-DIO2, Rot: Random I/O für Debugging)

Im speziellen kann man sehen:
- scope07.png: Sieht so aus wie man sich [0x3C, 0xAA, 0x0C] vorstellt.
- scope08.png: Hier sieht man das zusätzliche HIGH-Bit vor 0x3C (von 
Cursor markiert), Zusätzlich ist das letzte Bit von 0x0C zu lang, und 
zeigt, dass OOK so lange das letzte Bit sendet, bis man TX abschaltet.
- scope09.png: Wenn man hier von STANDBY auf TX umgeschaltet, versucht 
der RFM69 scheinbar noch das letzte Bit vom letzten Paket weiter zu 
senden, und fügt gleich darauf ein zusätzliches LOW-Bit ein ... sehr 
merkwürdig

[Felix P. (fixxl)]

Wenn du in den Tx-Modus gehst, fängt das Modul, sobald es bereit ist 
("ModeReady" bzw. "TxReady", macht beim Transmitter keinen Unterschied) 
sofort an zu senden. Liegen zu diesem Zeitpunkt noch keine Daten im 
FIFO, werden abwechselnd 1er und 0er rausgeschickt. Das ist im 
Datenblatt auf Seite 36 beschrieben, allerdings ist nicht ganz klar, 
welcher Pegel zuerst kommt. Wenn der FIFO leer ist, der Sendevorgang 
also abgeschlossen, man den Tx-Modus aber nicht verlässt, werden weiter 
fröhlich Daten generiert.

Daher würde ich den Sendevorgang mal folgendermaßen gestalten:
- Gehe in den Standby-Mode
- Schreibe zu sendende Daten in den FIFO
- Wechsle in den Transmit-Mode (Befehl senden und auf "ModeReady" 
warten, kein Delay in der while-Schleife)
- Warte auf PacketSent, kein Delay in der while-Schleife
- Wechsle in den Standby-Mode

Die Delays in der while-Schleife sollten weggelassen werden, weil es ja 
theoretisch passieren kann, dass bei der Abfrage das Bit noch nicht 
gesetzt ist, aber direkt zu Beginn der 200us umspringt. Dann wartet man 
noch 199us, obwohl das Paket schon durch ist und das Modul sendet 
weiter.

Siehst du dann immer noch unerwünschte Bytes?

[Reiner O. (elux)]

Markus P. schrieb:

> ich will mit dem RFM69CW Nachrichten per OOK verschicken und habe den
> Effekt, dass nur der erste Frame "korrekt" verschickt wird,
> für alle fortlaufenden Frames fügt der RFM69CW ein zusätzliches
> (Start?-)Bit ein.

Kommt mir bekannt vor, jedoch beim RFM 12.

Hängt der RFM am Hardware SPI ?


MfG
Elux

[Markus P. (teschi)]

Danke schon mal für Eure Antworten.

@Elux:

Korrekt, Hardware-SPI an Arduino Uno (mit 500kBaud). Ist das das 
schlecht?
Mal gleich Richtung RFM12 googlen... falls Du da noch spezifischere 
Pointer hast, nehm ich die gerne :D


@fixxl:

Ich hab meinen Testcase entsprechend geändert
das unerwünschte Bit ist aber leider immer noch da.

sieht jetzt in etwa so aus:

void sendFunc2(int debugPulses, byte byte1, byte byte2, byte byte3)
{
  // send block of 3 bytes, pre-fill FIFO and change to TX Mode
  rfmWriteReg(0x00, byte1); // FILL FIFO
  rfmWriteReg(0x00, byte2); // FILL FIFO
  rfmWriteReg(0x00, byte3); // FILL FIFO
  debugPulse(debugPulses);
  setOperationMode(MODE_TX); // set Mode: TX, wait for mode_ready

  // wait for the transmission to finish and go to standby
  while ((rfmReadReg(0x28) & 0x08) == 0) 
    {}
  setOperationMode(MODE_STANDBY);
  delay(4);
}

Der Hinweis mit S. 36 war interessant, weil daraus hervorgeht, dass das 
zusätzliche Bit innerhalb des Blocks "Transmission of Packet" passiert.
Was aber genau dafür verantwortlich ist, und ob man's ausschalten kann, 
tappe ich noch im dunkeln

> Liegen zu diesem Zeitpunkt noch keine Daten im FIFO, werden abwechselnd 1er und 
0er rausgeschickt
Meinst du hier die Präambel? Diese habe ich ausgeschaltet (Länge=0). 
Hab's aber mal noch mit Präambel ausprobiert, auch hier kommt's zu dem 
zusätzlichen Bit.

Anbei noch:
* Code
* Pulsview Aufzeichnung
* Kommentierte PulseView Screenshots

[Felix P. (fixxl)]

Markus P. schrieb:
> Meinst du hier die Präambel? Diese habe ich ausgeschaltet (Länge=0).
So wie ich die S. 36 verstehe, fängt das Modul sofort mit dem Aussenden 
von Bytes an, sobald ModeReady eingetreten ist. Hierzu ist auch Seite 54 
im Datenblatt interessant:

"The transmission of packet data is initiated by the Packet Handler only 
if the module is in Tx mode and the transmission condition defined by 
TxStartCondition is fulfilled. If transmission condition is not 
fulfilled then the packet handler transmits a preamble sequence until 
the condition is met. This happens only if the preamble length /= 0 
[soll wohl ungleich 0 heißen], otherwise [also für den Fall == 0] it 
transmits a zero or one until the condition is met to transmit the 
packet data."

Dass "zufällig" 0 oder 1 geschickt wird, wenn man den Transmitter 
startet, scheint also normal zu sein. Die Frage bleibt, ob es irgendwie 
verhindert werden kann, nachdem ja eigentlich die TxStartCondition 
unmittelbar erfüllt ist.

Leider habe ich mit deinem Betriebsmodus keine praktische Erfahrung, ich 
arbeite bisher immer mit Präambel, Syncword und CRC, wo es nicht stört, 
wenn vor oder nach dem Paket noch irgendwelcher Quatsch geschickt wird, 
da sich der Packet-Handler drum kümmert.

[Markus P. (teschi)]

Du hast Recht.

Die Passage sagt im Grunde schon recht deutlich, dass es undefiniert 
ist, was vor dem Beginn der Transmission passiert. Jedoch schon etwas 
verwunderlich, dass das unerwünschte Bit direkt NACH dem eintreten von 
TxReady passiert.

Wie dem auch sei, vermutlich hab ich hier auch ein etwas esoterisches 
Problem. Ich probier vermutlich am Wochenende noch ein bisschen weiter, 
und Kommentiere, wenn ich doch noch den Grund für das Verhalten finde.

Jedenfalls nochmal vielen, herzlichen Dank für Deine Antworten.
  Teschi

P.S.:
Mit ist außerdem heute noch die Idee gekommen, dass ich anstatt des 
"SLEEP"-Workaround für die Pausen ja auch einfach Nullen in die FIFO 
schreiben könnte, und anstatt der wiederholten Pakete einfach ein 
einzelnes, langes schicken könnte.

[Reiner O. (elux)]

Ich habe mich mal umgesehen: genau das Problem mit einem Bit zuviel ab 
dem 2.Byte hatte ich seinerzeit (etwa 2012) auch. Damals bauten alle mit 
dem RFM12.
Ich hatte einen Mega8 und weil das HW-SPI frei war (und man das Geld für 
nicht genutzte HW ja nicht zurück bekommt ;-) ) hatte ich den RFM auch 
an das HW-SPI vom Atmel angeschlossen...
Seinerzeit hatten alle die Bibliothek von BenediktK verwendet und der 
hatte aus Kompatibilitätsgründen ein Software-SPI eingebaut. Ich habe 
seinerzeit sehr lange (und auch sehr erfolglos...) nach der Ursache 
gesucht.
Jedenfalls hat laut LA der Atmel alles richtig gemacht. Ich habe ja nun 
schon Einiges mit Atmels HW-SPI gemacht und nie Probleme damit gehabt, 
daher vermute ich das Problem im SPI Interface einiger RFMs. Nachdem ich 
dann (leise fluchend) auch auf SW-SPI (in Assembler) umgebaut hatte, 
ging es sofort perfekt.



Gruß aus Bestensee

Elux

[Markus P. (teschi)]

oookaaaayyy...

Ich kann mir den WTF-Moment recht gut vorstellen
(und mein Fluchen wäre da definitiv nicht leise gewesen ;) )

Klingt aber irgendwie schon ziemlich ähnlich zu meinen Effekten.

Ich bau das am Wochenende mal zu 'ner SW-SPI um und schau was dabei raus 
kommt. (vorher komm ich vermutlich nicht dazu)

Dankeschöön
  Teschi