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?
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.
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?
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 …
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.
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 …
@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.
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
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
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
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
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.
