arduino-LoRa
arduino-LoRa copied to clipboard
sandeepmistry
Sync word issue
Sync word checking appears to be inconsistent. (I'm using a variation of the LoRaReceive sketch here, not the callback sketch). What follows is a set of collected findings and questions, but unfortunately not a solution (sorry).
Using two radios, I set the sync word of one to 0xAA and the other variable. I ran through all values from 0x01 to 0xFF. The following "matched" with 0xAA:
a8, a7, a6, a5, a4, a3, a2, a1, a0, 9d, a8, a9, aa, ab, ac, ad, ae, af, b0, b3, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af, b0, b3, b4, b5, b9, bc, c3, c5, c6, c9, ca, d3, d6, d7, d9, e3, e8, ea, f0, f7, 13, 1a, 2c, 2f, 33, 36, 39, 3a, 43, 44, 45, 46, 4f, 5d, 67, 69, 6f, 70, 7a, 7c, 7f, 88, 89, 8e, 94, 95, 9e, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af, b0
It seems like the device should be in sleep mode when you set the sync word, so perhaps it would make sense to wrap the writeRegister() in setSyncWord() in a call to sleep mode, then return the radio to its normal mode before the function is over. Also, "The bit synchronizer must also be activated in Continuous mode (automatically done in Packet mode)" (from the Semtech datasheet), which makes me wonder if sync word detection doesn't work in single receive mode? The HopeRF datasheet is unclear on this, and doesn't even detail the LoRa mode registers.
It is worth noting somewhere in the docs that single receive mode is intended for battery operation, and continuous receive mode consumes more power, and is intended for non-battery operation.
Will test more when I've got the hardware in hand again.
It seems like the device should be in sleep mode when you set the sync word, so perhaps it would make sense to wrap the writeRegister() in setSyncWord() in a call to sleep mode, then return the radio to its normal mode before the function is over.
Oops, I missed that during my testing, so it was probably not using the desired sync work value. I'll open a PR for the change.
Also, "The bit synchronizer must also be activated in Continuous mode (automatically done in Packet mode)" (from the Semtech datasheet), which makes me wonder if sync word detection doesn't work in single receive mode?
I think this is for FSK mode right?
It is worth noting somewhere in the docs that single receive mode is intended for battery operation, and continuous receive mode consumes more power, and is intended for non-battery operation.
Interesting, the library is setup in the opposite way then:
- Callback mode enables continuous receive mode. Originally, I was thinking you could put the MCU to sleep while it waits for the RX interrupt from the LoRa module
- Polling mode enables single receive mode. So this will use more power on the MCU ...
Also, "The bit synchronizer must also be activated in Continuous mode (automatically done in Packet mode)" (from the Semtech datasheet), which makes me wonder if sync word detection doesn't work in single receive mode?
I think this is for FSK mode right?
Yeah, I realized that after I wrote it, sorry about that.
It is worth noting somewhere in the docs that single receive mode is intended for battery operation, and continuous receive mode consumes more power, and is intended for non-battery operation.
Interesting, the library is setup in the opposite way then:
Callback mode enables continuous receive mode. Originally, I was thinking you could put the MCU to sleep while it waits for the RX interrupt from the LoRa module
Oh, that is a good way to do it. I hadn’t considered that option. I think either one could work. Do we have a cross-processor sleep() in the Arduino API yet?
Polling mode enables single receive mode. So this will use more power on the MCU …
More on the MCU, less on the radio. I’d say mention both approaches in the docs, maybe do a sleep example with the continuous mode.
t.
Do we have a cross-processor sleep() in the Arduino API yet?
There's ArduinoLowPower, currently SAMD only.
maybe do a sleep example with the continuous mode.
Yes, that would be nice. It would be SAMD only for now though.
I've been testing this again, with and without PR #18. It doesn't seem to make too much of a difference.
When sending a packet every second, occasionally packets with the wrong sync word will sneak in. I think it's a hardware issue and the code is very similar to: https://github.com/Lora-net/LoRaMac-node/blob/master/src/radio/sx1276/sx1276.c
For now let's leave this issue open, I don't think there is much we can do :(
Hi...
I'm also experiencing strange results with the sync-word... regardless if set while in sleep or in idle mode. Just as an example, my receiver (configured with syncword=0x12) decodes frames with sync 0x12 as well as 0x13... but not 0x34... strange...
Giampaolo
