Closed terrillmoore closed 5 years ago
Also curious, the value for MAP_DIO2_LORA_NOP
, if used in the proper location, is a sketchily documented value:
(SX1272 is similar.)
I've pushed the fix on a branch https://github.com/mcci-catena/arduino-lmic/tree/issue217 -- I don't have hardware with me to test. I'll test tomorrow NY time, but I welcome feedback from others as to whether this breaks anything. I haven't looked at the Semtech reference code to see what they do. This might solve some long-standing mysteries, because it appears from the datasheet that DIO0 would never be activated (and thus we'd be dependent on the DIO1 signal, as we know we are from Feather work). @svelmurugan92, if you can test and report results, I'd be interested.
Hi @terrillmoore,
Checked out this branch [https://github.com/mcci-catena/arduino-lmic/tree/issue217], build and verified in both SAMD (With Catena 4450) and STM32 (With Catena 4612) platforms. From the test results, Recent changes did not break anything. Tx and Rx works as expected.
Continue our development cycle with this branch changes. If any weird behavior, Will let you know
Thank you!
Thanks @svelmurugan92. @cstratton also found https://github.com/matthijskooijman/arduino-lmic/issues/13, seems to be same issue. I'm going to start a pull request because it's clear that this is a proper change.
From @cstratton (thanks Chris!)
https://github.com/mcci-catena/arduino-lmic/blob/a86a87ec9c131818172a21c6e52c080ee4917181/src/lmic/radio.c#L267
More context:
https://github.com/mcci-catena/arduino-lmic/blob/a86a87ec9c131818172a21c6e52c080ee4917181/src/lmic/radio.c#L261-L267
And per the Semtech datasheet:
Using 0xC0 causes the value controlling DIO0 to be set to an unspecified value, here and here:
https://github.com/mcci-catena/arduino-lmic/blob/a86a87ec9c131818172a21c6e52c080ee4917181/src/lmic/radio.c#L538
https://github.com/mcci-catena/arduino-lmic/blob/a86a87ec9c131818172a21c6e52c080ee4917181/src/lmic/radio.c#L654
I can't figure out how this ever worked; the only explanation is that 0xC0 happens to cause the right value to be output on DIO0 (TXDONE if TXing, and RXDONE if RXing). I will fix this and call for testers (and do some testing myself).