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.

[Trond Einar Snekvik]

Yes, this is definitely possible. Can you check whether the wait-function returns a lot? It's set up to wake on every single HW event, so it's not going to stay in there for long if you do anything else on the device.

There could be some other peripherals running as well, that you'd probably want to turn off. Chapter 8.3 in the nRF51 PS shows you the requirements table (power wise) for the various peripherals. Running the CPU requires the 1V2, 1V7 and HFCLK, which is the source of most of its drain. If you're running the timer with the HF timers (NRF_TIMER), you're also enabling the HFCLK (and potentially 1V2), which will drain 1-2mA. Also make sure that you're clearing the timer hardware registers properly in your timer interrupt, so that you're not spinning.