Skip to content

Conversation

quartzjer
Copy link
Contributor

This is the start of a module to support the Semtech SX1276 based radios. It's a work-in-progress!

@quartzjer
Copy link
Contributor Author

@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 :)

@matthijskooijman
Copy link
Collaborator

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.

@quartzjer
Copy link
Contributor Author

👍 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants