Home/Support/Support Forum/Horribly unreliable DIO Sampling in DigiMesh

Horribly unreliable DIO Sampling in DigiMesh

0 votes
Hello,

Product: XBP9B-DMUT-002

I'm disappointed in completely lacking information in the manual about certain features. My main problem I'm currently facing is missing and/or duplicate IO sample packets.

I'm developing an industrial sensor monitoring system using ONLY IO sampling. A typical layout would be as follows:

1 sleep support coordinator with 3-15 synchronous sleeping routers. Each router is sleeping for 7 second, and awake for only 70ms. I'm only monitoring 3 DIO. When devices wake, they send 1 DIO sample back to the sleep coordinator.

On my test bench I have a minimal setup. 1 sleep coordinator and 2 routers. I have a generous 10sec sleep and very generous 1 second wake time. I'm monitoring incoming API packs on my computer via sleep coordinator. My problem is that the routers seem to be transmitting at the exact same time. Even though both routers respond, I sometimes only get 1 received sample response. Sometimes I get FOUR responses from the SAME ROUTER. Only 1 out of 3 or 4 wake cycles I get a desired response of 1 DIO sample packet from each router. My settings are as follows:

Sleep preferred coordinator:

PL (tx power level) = Lowest 0
MT (broadcast multi-transmitts) 0
CE (router) 0
BH (broadcast hops) 0
NH (network hops) 1
MR (mesh unicast retries) 1
NN (network delay slots) 1
TO (TxOption) C0
No encryption
API mode without escapes
SM (sleep mode) sleep support 7
SO (sleep options) 1
SP (sleep time) 0x3E8 (10,000ms)
ST (wake time) 0x3E8 (1,000ms)

Router:

PL (tx power level) = Lowest 0
MT (broadcast multi-transmitts) 0
CE (router) 0
BH (broadcast hops) 0
NH (network hops) 1
MR (mesh unicast retries) 1
NN (network delay slots) 1
DH set to SH of coordinator
DL set to SL of coordinator
TO (TxOption) C0
No encryption
API mode without escapes
IR (sample rate) 60ms
SM (sleep mode) synchronous sleep 8
SO (sleep options) 2

Explanation for setups:

All devices except the sleep preferred coordinator are running on batteries; therefore, sleep/wake time ratios are critical. To meet target battery life, the device must not wake for longer than 70ms. I had to set NN, NH, AND MT to minimum values to get wake time low enough. All devices will be line of site, if a few aren't, 1 hop will be all that is needed. After devices are powdered, AG FFFF command is sent to DH, DL, and routes in the network. I tried to find a detailed description of radio/network functions with each CE setting and other settings, I couldn't find anything. Given my desired goal of simply receiving reliable IO sample packets, am I going down the right path?

Originally, I was testing using P2MP mode. Indirect msg coordinator for main coordinator and non-routing modules as end devices. End devices were asynch sleep with pin wake. I set wake time to 50ms, but with my oscilloscope, I measured the wake time at 7.3-8.1ms. This is concerning because it's not long enough to receive any responses from the coordinator. Additionally, it seems as if clock drift, eventually, would cause atleast 2 radios to wake and transmit close enough to cause data collision. Sorry for posting a whole book. Any suggestions? Thanks!
asked Jun 8 in DigiMesh Proprietary Mesh Networking by Jamespie New to the Community (0 points)

Please log in or register to answer this question.

1 Answer

0 votes
Jamespie,

The nodes will wake at the same time and try to send the data at the same time. That is because you are using the same values. In that kind of network, it is far better to send a poll request to each node within the network. This way you can control who is talking and who is just waiting or listening.

Digi Support
answered Jun 9 by mvut Veteran of the Digi Community (12,786 points)
Do you work for Digi? I ask because multiple guides have said that I can use a sensor network with all the same IO sample times without any polling. I found this guide after I posted this question and it seemed to work fine: https://www.digi.com/support/knowledge-base/sending-data-over-an-asynchronous-network-example

Is this still valid? I programmed a uC to turn on 4 nodes all at the same time. I monitored the sleep status pin on all 4 nodes with a scope. I was trying to check if the radios automatically detected multiple transmits happened at the same time. I appears they do. They turn on or an initial duration for about 50-100ms. Then they fire in 16ms pulses. When the pulses on the scope overlap, they seem to self adjust and stagger their transmit times so that they're not firing at the same time. Is this programmed behavior?
Jamespie,

Yes I do.
Yes, this is the expected behavior. However, as you scale up in the size of the network, you will need to adjust the WH command to allow a more staggered transmission pattern.
...