The TX/RX behaviour of OpenMesh?

[stephen]

I've studied the nRF OpenMesh for a couple of days, and could run the BLE_Gateway example among serval nRF51DK boards. But now, I still don't have any feeling/concept about the radio tx/rx switching behaviour. The following is my questions listed about the OpenMesh v.0.8.5,

1. Is there a simple sync mechanism existed among OpenMesh nodes?
2. Does radio or cpu ever go to sleep when running OpenMesh?
3. For radio tx, the adverting interval (mesh_interval) can be set, but how about radio rx? Is there a scan window setting, or rx alway keeps stand by for receiving data?
4. For one certain data handler, how to know the previous version data has been sent and prepare the next one immediately to get higher throughput?

Anyone can help me if you have an answer.

Thanks, Stephen

[Trond Einar Snekvik]

Hi again Stephen,

1: There's no sync behavior in OpenMesh at this point but we're looking into and discussing it in this github issue. While primary focused at large scale synchronization, I believe it can create a foundation for power consumption targetted time sync at a later stage.

2: Radio: Not really. There are short turnaround times, but the radio is on >99% of the time. CPU, on the other hand, sleeps most of the time (<10% utilization).

3: No. We'd like to do something with the time sync here, but for now, it's always on.

4: You can enable TX events for each handle, which will give you an event whenever it's transmitted. Note that transmitting the packet does not guarantee that it is received by others.

[stephen]

Hi again Trond, you always feedback me the useful information immediately. Thanks again! By the way, could I call you OpenMesh Master?

[Trond Einar Snekvik]

I think you'll be the only one, but sure, go ahead ^^

[stephen]

Got it, OpenMesh Master!

[stephen]

Hi Master, last time you answered the radio is on >99% of the time. I guess radio RX occupy most of the time. So, could we constrain 50% (or less) RX working time to save battery power? and how to do? Thanks, Stephen