This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

The TX/RX behaviour of OpenMesh?

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

Parents
  • 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?

Reply
  • 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?

Children
Related