The TX/RX behaviour of OpenMesh?

RE: The TX/RX behaviour of OpenMesh?

stephen — Thu, 04 Aug 2016 02:18:54 GMT

okay, I would try them according to your advices later. By the way, I intend to "add a comment", but click to "edit convert to answer". Obviously, there is not UNDO or convert to comment function in this system. Sorry for that.

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Tue, 02 Aug 2016 15:09:36 GMT

That sounds weird. Can you post the hardfault as an issue to the github-repo? Are you able to get a backtrace from it? The handle pair should keep on broadcasting after the stop. Can you check whether its still in the cache with the debugger? Time "freezes" while the mesh is stopped, and will continue as if the next timeslot immediately followed the previous. We had some trouble with the timers not firing for the first 10 seconds after the stop before, could this issue have resurfaced?

RE: The TX/RX behaviour of OpenMesh?

stephen — Wed, 27 Jul 2016 14:53:49 GMT

Okay, got it, and thanks you again. In addition, I found two addtional problems. First, it needs to add extra 6 ms delay between bc_mesh_start() and rbc_mesh_value_set(), otherwise, it would fail and go into HardFault_Handler(). 6ms delay is reasonable? If not, how to reduce it. Second, the handle pair will not re-broadcast its value next cycle after executing bc_mesh_stop() and then executing bc_mesh_start(). I suspect that handle pair would not re-broadcast unless it get the latest version again in this situation. Do you have any suggestion about these two, my Master? thanks, Stephen

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Wed, 27 Jul 2016 08:59:18 GMT

That should be the case, yes. You could also try the __WFE(); intrinsic, which is what the sd_app_evt_wait() function really does inside. Still, try and gauge the frequency of the CPU wakeup (if you have a logic analyzer, it could be as easy as toggling a pin whenever your wait-function returns). It should provide a hint of whether it's the CPU or something else running.

RE: The TX/RX behaviour of OpenMesh?

stephen — Tue, 26 Jul 2016 12:16:42 GMT

Thanks for your quickly response very much! I use BLE_gateway as an example, implement a RTC1 to regular turn on/off mesh to save power and disable regular BLE task to simplify the whole behavior. when turning on mesh function, some message might be sent by application. So, I think SoftDevice will do nothing during turning mesh off. Am I right?

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Tue, 26 Jul 2016 11:21:07 GMT

The sd_app_evt_wait() function is going to return whenever a HW event is triggered. This will most likely happen every now and then, whether you're triggering it, or the SD. Therefore, it should be placed in a tight while-loop, to avoid too much processing each time. However, if the wait function keeps returning immediately (at <1ms intervals, for instance) something is misbehaving on your SoC, and you should start looking into what is waking up the CPU so regularly.

Also, is your Softdevice doing anything?

RE: The TX/RX behaviour of OpenMesh?

stephen — Tue, 26 Jul 2016 11:03:29 GMT

Sorry, I don't understand what you said "check whether the wait-function return a lot" ? could you explain more?

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Tue, 26 Jul 2016 10:53:06 GMT

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.

RE: The TX/RX behaviour of OpenMesh?

stephen — Tue, 26 Jul 2016 09:51:28 GMT

Thanks, Master! It works, but not perfect. Because the current still consumes 4 mA while disable the mesh, it seems the CPU never go to sleep even adding sd_app_evt_wait() manually, just disable radio tx/rx parts. So, is it possible to let CPU sleep during enable rbc_mesh_stop() in advance?

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Mon, 25 Jul 2016 13:30:37 GMT

I meant the mesh_start/stop calls, yup :) Radio disable won't help you, as the transport will just reschedule a new radio event.

RE: The TX/RX behaviour of OpenMesh?

stephen — Mon, 25 Jul 2016 13:27:43 GMT

Did you mean executing bc_mesh_start()/ bc_mesh_stop() to enable/disable the mesh after setting up a timer? or, directly execute radio_disable()?

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Mon, 25 Jul 2016 10:25:26 GMT

There's no built-in feature for this at this point. I guess the easiest way to acheive this is to set up a timer, and enable/disable the mesh at regular intervals, PWM-style. An interval of 1 second should be reasonable.

RE: The TX/RX behaviour of OpenMesh?

stephen — Wed, 20 Jul 2016 03:12:32 GMT

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

RE: The TX/RX behaviour of OpenMesh?

stephen — Tue, 12 Jul 2016 09:23:48 GMT

Got it, OpenMesh Master!

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Tue, 12 Jul 2016 09:19:50 GMT

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

RE: The TX/RX behaviour of OpenMesh?

stephen — Tue, 12 Jul 2016 09:11:39 GMT

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

RE: The TX/RX behaviour of OpenMesh?

Trond Einar Snekvik — Tue, 12 Jul 2016 07:15:21 GMT

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.