Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync word issue #16

Open
tigoe opened this issue Apr 28, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@tigoe
Copy link
Collaborator

commented Apr 28, 2017

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.

@sandeepmistry

This comment has been minimized.

Copy link
Owner

commented Apr 29, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 29, 2017

@sandeepmistry

This comment has been minimized.

Copy link
Owner

commented May 15, 2017

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.

@sandeepmistry

This comment has been minimized.

Copy link
Owner

commented May 28, 2017

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 :(

@tigoe

This comment has been minimized.

Copy link
Collaborator Author

commented May 29, 2017

I agree, more testing is needed.

@sandeepmistry sandeepmistry referenced this issue Nov 13, 2017

Closed

Sync Word #58

@3Dtj 3Dtj referenced this issue Oct 25, 2018

Closed

Sync word utility #198

@iw2lsi

This comment has been minimized.

Copy link

commented Nov 30, 2018

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.