-
Notifications
You must be signed in to change notification settings - Fork 24
LoRa Module (semtech-baed) #217
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
base: master
Are you sure you want to change the base?
Conversation
|
@matthijskooijman I think I'm doing the ping right here, can you take a look and see if you can reproduce, and if it doesn't work if the logic is even correct? I'm not sure I have a "clean room" setup here to trust my hardware :) |
|
The problem with this code is, I think, that calling the various receive functions in the SX1272 library will switch the LoRa module into RX mode, wait for a packet to be received within the given timeout period. I think it doesn't actually switch back to standby mode after reception (except when it succesfully received a packet that was for someone else?). However, I think that the next call to a receive function might mess up any pending reception. In other words, this library is really intended for one-off receives with longer timeouts, while we would need a more asynchronous polling type of approach instead. Given that I don't really like the library code itself (lots of similar functions, some magic constants, LGPL license), I'll have a look at the LMIC code instead. |
|
👍 it was just used as the fastest way to validate the hardware was hooked up right, you're the only analysis so far :) |
This doesn't just allow for more TX power - it also changes the TX antenna pin that is used from RFO to PA_BOOST, which is needed on the SX1272 eval boards.
This properly indicates to the module system wether the load was succesful. Additionally, if initialization was not succesful, don't expose the lora.ping function.
Since the SX1272 library only makes the hardware listen during these timeouts and the entire message must be received and processed in that time, having a tiny timeout doesn't work at all, or only sporadically. This approach means that the loop might block up to 1000ms, which will break other stuff, so the SX1272 library needs to be changed (or replaced) to allow for more asynchronous behaviour. For now, this longer timeout makes at least some things work, though.
We use the SS pin as the chip select, whose number is 9, so this does not change any behaviour.
This is the start of a module to support the Semtech SX1276 based radios. It's a work-in-progress!