0
\$\begingroup\$

I'm working on a robotics project that requires what is probably a somewhat strange data exchange requirement. I was hoping someone would have ideas on what technologies would be best to implement it. The problem is as follows:

I have many separate embedded systems (nodes) that need to maintain an extremely accurate, coordinated clock. Absolute accuracy doesn't matter, but they must agree with each other to at least 10us (hopefully better). They also need to send and receive data to/from a central computer. The data requirement is very small. Something like a couple of bytes at around 100Hz. So a total of ~1KB/s per node.

I was thinking I would be able to do this by using the laptop to send clock coordination packets, and a small WiFi microprocessor (like the esp8266) on each node to receive the packets. Lets say every 10ms, the laptop broadcasts a UDP packet. If I configure all the nodes to have the same IP address, they will receive the packet at essentially the same time. The only uncertainty in the clock coordination ping arriving at the nodes at the same time will be the uncertainty in the amount of time it takes for the esp8266 to process the packet. However, I also need the esp8266 to send data back to the laptop. But my understanding is that this is problematic if all the devices have the same IP address...

Other thoughts:

  • Ideally I would be able do this all directly from the nodes to the laptop (ad-hoc network). If I have to I can use a wireless AP connected to the laptop.

  • I know there are clock coordination schemes out there that use TCP/IP. I just don't think any of them are good enough to get the kind of clock accuracy I want. I could be wrong about this (ok technically there is something called Wi-Fi TimeSync but it doesn't seem to be commercially available yet).

  • Although it wouldn't be very elegant, I could live with having 2 esp8266 modules on each embedded system. 1 could share the same IP address with all other nodes and use the UDP packet coordination scheme discussed above. The 2nd would use TCP/IP with a unique address to communicate with the laptop.

  • There are 433mhz and 900mhz modules like this: http://wiki.seeed.cc/433Mhz_RF_Link_Kit/ that would be very simple and fast. Just put a clock on the data line of the transmitter and read the clock off the receiver on all nodes. However, I don't think this is legal under FCC regulations: http://www.edn.com/electronics-blogs/eye-on-iot-/4437311/Using-433-MHz-for-wireless-connectivity-in-the-Internet-of-Things

edit:

Thanks all for the comments. GPS is actually a great solution. I wasn't aware that they had PPS clocks that are so accurate. I think I will use that in addition to the esp8266. @analogsystemsrf, you are correct. This is for an ultrasonic positioning system.

\$\endgroup\$
  • 2
    \$\begingroup\$ Please write specific questions relating to the problems you want solved, instead of "any thoughts/ideas appreciated". Clear communication will get you better answers. \$\endgroup\$ – Voltage Spike Jun 21 '17 at 15:51
  • 1
    \$\begingroup\$ 10us is a pretty long time. But you better describe what you are trying to do to avoid XY-problems. \$\endgroup\$ – Eugene Sh. Jun 21 '17 at 15:54
  • \$\begingroup\$ Are you attempting ultra-sound positioning? \$\endgroup\$ – analogsystemsrf Jun 21 '17 at 16:04
  • 1
    \$\begingroup\$ A GPS module will give you sub us timing on 1PPS \$\endgroup\$ – sstobbe Jun 21 '17 at 16:06
  • 1
    \$\begingroup\$ Is your question essentially, "On a bi-directional link, I want to synchronize/coordinate data streams between several separate nodes on a wireless network and a central computer to at least 10 \$\mu s\$"? It's not entirely clear what you want in an answer. \$\endgroup\$ – Vladislav Martin Jun 21 '17 at 16:48
1
\$\begingroup\$

GPS may be an option outdoors (or with enough effort, repeated), but is fairly expensive and may have unreasonably long lock times.

Typical 433 MHz radios may not necessarily work. The problem is that they have a tendency to resample the data - the cheap ones as they are regenerative designs which self oscillate and quench, the better ones because they have data slicers. Typical bit rates (and quench rates for the regens) may simply not go high enough to give the desired time resolution. It may be possible over an extended period of time to see through this and gain information to discipline a local clock. But I suspect that with a low bandwidth radio one may need to get at things substantially earlier in the receive chain and do ones own detection / correlation.

In contrast, something like the 1 or 2 megabit/second modes available on an nRF24L01+ 2.4 GHz data radio could well give enough time resolution even after data resampling. I don't know for a fact how deterministic the receive path is with regard to time response, but it would probably be worth looking into. And they are inexpensive and easy to work with for the data aspects. Software interrupt latency can with care be within the timing requirement, but one could also wire the radio's packet IRQ signal to an MCU timer capture input. Some BLE MCU's (at least those from Nordic) have heritage to the nRF24 can could probably do this as well.

In terms of wifi, trying to assign multiple devices the same IP address is a non-starter. If trying to work through a formal protocol, UDP broadcasts would be a better choice. But with something like the ESP8266 or ESP32, it would be better still to investigate the raw modes which use the wifi radio at a lower level than a wifi network would.

\$\endgroup\$
0
\$\begingroup\$

As posted in the comments, there are several solutions to this problem:

  1. GPS - If it is an outdoor application, or if you can get a GPS signal indoors via a repeater, GPS receivers provide 1PPS signal with sub micro second accuracy.
  2. Clock synchronization scheme - There are several standard schemes to synchronize clocks over a network, Try looking into the IEEE 1588 standard. This will require at least one node with a very accurate clock on the network.
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.