LoRa channel activity detection #141
Replies: 1 comment
-
I'll Look into this. The other potential issue would be the requirement for the additional pin to be connected to the microcontroller as not all hardware has all of the DIO pins connected and then I believe the DIO pins can be general purpose pins so can be configured for different uses. So there may be some configuration of the different LoRa chips needed.
We can take the base send interval and add a small amount of randomness to the time to lesson this possibility.
Yeah, excellent thinking. Pings would want to send right away without using CAD in order to report accurate response times.
Yep, another excellent point. |
Beta Was this translation helpful? Give feedback.
-
@aviateur17
Since this is another topic on the after-release to-do list, I figure I'll get my thoughts down.
The SX127x uses an interrupt to signal the channel is clear, which seems like the way to go. This would involve passing another pin in config and wouldn't be a huge deal. Gateways release all of their LoRa buffers at an unchanging interval, which could be bad if two gateways' intervals synced up. Delaying transmissions until the channel is clear should help alleviate this.
With nodes, we could really get away with the non-interrupt (blocking) CAD function.
CAD will throw off things like pings a bit too. Would a ping wait for channel clear, then send? When does the timer start? Should a ping time reflect the duration it spent waiting to transmit? I could argue both ways :)
There may be ways to subtly give nodes a slight advantage/priority in the "fight" for airtime too, since they are in a hurry to get back to sleep.
I just trust in ESP-NOW's error handling. It has its own retry system, albeit a bit mysterious.
Beta Was this translation helpful? Give feedback.
All reactions