Mesh Latency - Revisited

I have scoured the community for latency related issues but could not find my scenario.

Basically, I have 2 Xenons in a time-critical application. When an incident occurs, the first Xenon does a mesh.publish to the second (48-byte message). When the second Xenon receives the message, it records the time.

When the incident that affected Xenon #1 reaches Xenon #2, the time is recorded and the difference is calculated.

Is it normal to sometimes have latency in this case of almost 40 ms?

Thanks in advance for your input.


How do you sync the clocks on your two devices?

40 milliseconds is not surprising in thread mesh.

The following numbers are not for Particle hardware. They’re from a Silicon Labs white paper about thread mesh performance, but it shows the average latency for their test network:

Average round trip
1 hop 34.29 milliseconds
2 hop 62.38
3 hop 81.61
4 hop 112.99
5 hop 127.87
6 hop 142.65

Also the FreeRTOS scheduler is pre-emptive. The task slice is 1 millisecond.

1 Like

I am not syncing them. I just record the time the message was received from the first Xenon.

Thank you @rickkas7, @ScruffR and @shanevanj. It does not look like I can use mesh networking then even though the two devices are centimeters apart.

Is there any other way to communicate between the devices without this much latency? I cannot use a hardwired solution because the second serial port is disabled by the Ethernet wing. Also, the SoftSerial library is not supported …

Would (for example) setting a pin high on the second Xenon by the first one and then and using an interrupt on the second Xenon to record the time work?

Yes but then why would you need two devices if they are that close - perhaps if we understood your use better …

Thank you @shanevanj.

In my application, I already have two devices. A moving object is sensed by the first device (always) first and then by the second device. My objective is to record the exact time the moving object is seen by the first device, then by the second device. Knowing the distance between the two Xenons, one can calculate the speed.

On average, the elapsed time is only about 70 ms so a latency of 50 ms obviously will not work …

Conceptually - Yes, then use a physical cable and set an interrupt on the rising edge of D2 (from Xenon1) and D3 (local sensor on Xenon2) (lets say) and only set or reset a flag in the relevant ISR, then in loop() set a variable to the current millis() when you see the flag = true, and when flag = false get current millis() into another variable and do the maths. There would be some calibration needed to cater for the time to execute the code …

1 Like

I guess there must be other factors to exclude a hardwired solution, since there are more than just SPI and serial - e.g. I2C.
But if hardwiring was an option, why would you need two independent controllers and not just have two sensors on one device?

If you had a synced time base, you could exchang timestamps and the latency would be irrelevant.

Thanks @ScruffR.

I have limited knowledge of I2C (only used libraries) so I will read more about it. SPI use may conflict with the Ethernet wing?

On time syncing, probably an NTP server would work but the problem is that there is no internet access allowed at that site. Local time syncing via a local server or GPS may work but adds complexity …

All good ideas. Thank you.

@Jimmie, looks like your application is trying to measure speed… in this case I would definitely go with @ScruffR and @shanevanj suggestion and have the two sensor wired to the same board, and have each sensor in a interrupt pin, with the interrupt handler recording the systick (CPU time) of each event.

In your loop code than you could calculate the time difference between both events.

1 Like

Thank you @Gildons

I cannot have two sensors wired to the same board because the Xenon’s second serial port is used by the Ethernet wing. Also, there is a need for parallel processing.

Would you care to share the sensor that you are using? Sound like it’s just a on/off kind of sensor that goes to HIGH when event occurs, and you may not need any kind of serial com

It is a generic serial laser sensor which outputs distance …

I see, so my guess it that your sensor ir RS232/UART.
In this case you would still be fine with having both connected to the same board.

The Ethernet Wing is mostly like using SPI (that uses pins 13, 12 and 11 (possibly another pin for Chip Select)

If your sensor is using RS232 you still able to use PINs 10 and 9 for UART-1 and PINs 5 and 4 for UART-2.

From a quick google you may have configurable triggers for your sensor, if you do, make sure to use it if possible.

The Ethernet wing also uses D4 & D5 and those cannot be changed …

Are both devices using an EtherWing?
If so (or the possibility exists) why not use UDP via Ethernet?
If not, you have two UARTs on the other Xenon free to use and send the result to the gateway which doesn’t take part on the measurement.

Have you considered BT to communicate between the two devices?

Lateral and outside-of-the-box thinking often help to come up with better solutions than clinging to an idea an forcefully making it (somewhat) work :wink:

and if that end’s up not working as well, and the distance is not important, only the object passing through both sensors, you can also consider a simple sensor like this one

1 Like

Lateral and outside-of-the-box thinking often help to come up with better solutions than clinging to an idea an forcefully making it (somewhat) work

Yes indeed :slight_smile:

Only one device is using an Ethernet wing and there is no Gateway. There is a lot of processing that is needed simultaneously from the two sensors hence the need for two Xenons.

Distance needs to be over 30 feet and is outdoors …