-
Notifications
You must be signed in to change notification settings - Fork 432
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
Add FHSS support #441
Add FHSS support #441
Conversation
Verified to work using an RTL-SDR. SDRSharp_FHSS.mp4 |
@nseidle thanks for this! I'm not very concerned about changing behavior of I left some comments, mostly regarding the coding style and clarity. I assume this was tested with hardware?
Please add them if necessary, all of the SX127x support FHSS. This should also be added to SX1272/73, to keep all the SX127x modules consistent. |
I didn't realize FHSS was included in the SX1272/73. I've moved the functions into SX127x. I think I've got all the style changes in place. Let me know if there's something I missed. Everything is tested using the SparkFun BlackBoard C + LoRa SX1276 1W breakout, and a SparkFun ESP32 Thing Pluc C + SX1276 HopeRF 100mW shield. So different micros and different SX1276 module companies, but I have not tested on anything but the SX1276. |
This is the preferred method, same as Rx/Tx with interrupt.
I don't think that's needed at the moment, we can add it later. Thanks for the changes, everything looks OK to be merged now. |
The PR adds frequency hopping spread spectrum (FHSS) support.
My mild concern with this PR is the changing of setFrequencyRaw(). Originally the radio is put in standby before changing the frequency. FHSS requires the packet begin transmission then the freq is changed. This PR changes things a bit: if FHSS is enabled, the setFrequencyRaw skips putting the radio into standby mode.
I haven't added the helper functions to SX1277/1278/1279. I'll add those to the PR if you like what I've provided so far.
I exposed a clearFHSSInt() function so that users could do the channel hop from an ISR. An alternative approach would be to feed the library with a channel array and the library handles the hops. I don't like this as much but it would allow you to keep the clearing of interrupts internal.
I could add an additional helper called setFHSSPeriod() that accepts a user time in ms and does the hop frequency calculation based on Tsym but I thought I'd keep it simple. Let me know if that's wanted.