Replies: 3 comments 10 replies
-
|
As mentioned in #1691 (comment), converting to a discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Can you share a couple of logs from those devices, including the terminal timestamp from your PC? So using the DEBUG_PROTOCOL flag in BuildOptUser.h and enabling timestamps in your terminal program. Then we can check out most of the things that happen on your device. |
Beta Was this translation helpful? Give feedback.
-
|
Did you try to change scanGuard default value ? For a board having timing issues, I'd say the default 10 ms is probably not enough. The comment suggest to increase the value to at least 50 for debugging purpose. I'd try up to max value (see warning below) to see if it changes something. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
Board: CubeCell v1 and v2 dev board
LoRaWAN: 1.10 + 1.04, OTAA, ADR enabled
Dev: PlatformIO
RL: 7.6.0
Some CubeCell boards stop 'seeing' MAC downlinks sent by TTN after successfully receiving the first one.
Individual clock drift corrections are applied to each CubeCell.
Clock drift for the ones that are now failing is stable and similar to the clock drift of the good guys.
Any suggestions what I could try to come closer to what may be causing this?
(I did enable RL debugging (1st and 2nd option), but my app didn't like that causing hang-up during OTAA.)
With other timing/rollover issues out of the way now, having CubeCells running RLLoRaWAN seems within reach...
Beta Was this translation helpful? Give feedback.
All reactions