1
\$\begingroup\$

I have a project that involves multiple (5+) remote sensor units (custom PCB with a MCU, WiFi Radio, and sensor), that record data for a short test (<60 seconds). Each sensor records data internally onto flash memory. That data is then sent over WiFi back to a control unit at the completion of the test. At the start of the test, I have access wirelessly from the control unit to each of the sensors. Once the test is running, assume the sensors go into a faraday cage, and have no wireless connectivity. Once the test is completed, they are removed from the cage, and have wireless connectivity again. Over the entire 60 second test, the goal is to have the data in sync with each other by no worse than 100us. They can not be connected via wires at any point in the test.

The current plan is to have each sensor units MCU use a 20ppm oscillator. If we can give each sensor unit a accurate start and stop time, we can compare the test time of a reference, vs its internal recorded time. Then, assuming a linear oscillator frequency drift (likely a safe assumption in a short test, controlled temperature), we just shift each sensor unit's data linearly, based on the reference time.

The issue I am having, is how to send it an accurate start and stop time from the control unit. WiFi of course won't work, as its latency is much too unpredictable. Some sub-GHz units might be better, but I feel as if RF just isn't going to be consistent enough.

Another option I have considered, is to use a remote control with an IR transmitter. Each sensor unit has a IR receiver. To sync the units (I'll just use two sensors for the example):

  1. When the remote turns on, it starts its own internal counter, based on its clock.
  2. Remote is pointed at first sensor unit. It sends its internal timestamp as encoded data. Lets say this is 00023435. That sensor unit stores this value, and starts its own internal counter, based on its clock. It starts recording data, using its own internal counter for each data point.
  3. This is repeated for the second sensor unit, lets say the timestamp sent is now 00025525 (it is higher, as the remote's clock has been running).
  4. At the end of the test, the remote is pointed at each of the sensor units, and it sends its internal timestamp once again. The sensor unit records this time, as well as the stop time of its internal counter that has been running.
  5. Now, since we have the time spent as referenced by the sensor unit, and by the remote, we can adjust the recorded data to be referenced to the remote's time. This makes all sensor units data be in sync

This assumes that the oscillator's frequency does not change a meaningful amount during the test, which again, I think is an OK assumption.

The issue is, most (all) IR receivers list a pretty nasty delay for the decoded data. We don't care about true latency, it just needs to be consistent (td as shown below):

Image of receiver

I have been looking into other modulation ideas for the IR to have a consistent pulse, but haven't had a ton of luck. Hopefully there is a solution short of completely coming up with a protocol to give us an accurate reference point in the pulse.

So, any suggestions on the IR approach, or another approach all together that I may be overlooking would be appreciated.

\$\endgroup\$
12
  • \$\begingroup\$ Cant you use an IR (or even visible light) "flash" to sync a "Zero" timestamp? The same could be done with RF but I guess for 5 units (in a controlled environment) light would be easier to implement. \$\endgroup\$
    – Wesley Lee
    Commented Oct 26, 2021 at 21:42
  • \$\begingroup\$ @WesleyLee We can't hit all sensor units at the same time, it needs to be separate, as they will be physically apart. Also, what type of receiver would grab the flash? All that I've found have too much error. \$\endgroup\$ Commented Oct 26, 2021 at 21:44
  • \$\begingroup\$ Can you think of any synchronous event? \$\endgroup\$ Commented Oct 26, 2021 at 21:58
  • \$\begingroup\$ There are too many missing links and assumptions that question your need for synchronized commands. The latency is due to Q of optical Rx being 10 and the std. duration of the preamble which I assume you can extended and therefore reduce the variance of \$t_d\$ We don't know which Rx you are using nor the path loss. Pls fill in the blanks with links and specs and what test is being performed. I probably have done the same before without the problem you have. The IR emitter has a rise time of 15 ns \$\endgroup\$ Commented Oct 26, 2021 at 22:17
  • \$\begingroup\$ @TonyStewartEE75 I don't think there's too many missing links.. The need for synchronization is due to recording a specific event within the chamber. Each sensor is of a different kind, so they can't easily be aligned in post. As for the specific receiver, none has been chosen, as the delay variance is too severe. (See any Vishay IR receiver for that plot.) \$\endgroup\$ Commented Oct 26, 2021 at 22:21

2 Answers 2

2
\$\begingroup\$

+/-20 ppm XO is not adequate error limit as a 40 ppm differential can exist.

Just considering the drift in 60s of a 100 us tolerance max,you have ; \$100e^{-6}s/60s=1.67 ppm\$

I would suggest 1 ppm XO's or VCXO's tuned to 0.1 ppm as a minimum.

Then use some global message to sync all devices to start the test. (Whatever it is)

You can choose IrDA 1 with 100ns rise time max and 115 kbps data rate over 1m line of sight or better with stronger emitter flux (narrow angle) or use IrDA 2 with > 1Mbps .

They are pricey but for testing no matter. These Vishay parts are super reliable and were original designed by Sharp. I have used the IrDA 2 to detect a thin 1/4W wire crossing across a 1m path with recessed emitter detectors for multiple detector isolation in an array.

Here is D-K's stock https://www.digikey.ca/en/products/filter/irda-transceiver-modules/538?s=N4IgjCBcpgnAHLKoDGUBmBDANgZwKYA0IA9lANogAMIAusQA4AuUIAykwE4CWAdgOYgAvkOIAmCiG6cAJpjpCgA

but Mouser carries some Vishay IR parts that D-K no longer stocks.

\$\endgroup\$
7
  • \$\begingroup\$ Yes, but what you are not considering, is the drift, will be consistent (or mostly) through the test. If using a 16MHz oscillator, it's not like the speed is going to shift from 15.99998MHz then to 16.00001MHz, then back down. The frequency offset will stay roughly the same throughout the test (e.g. 16.00001MHz). That's why having a known start/end reference time can correct this. \$\endgroup\$ Commented Oct 26, 2021 at 21:59
  • \$\begingroup\$ Also, "Then use some global message to sync all devices to start the test. (Whatever it is)", that is currently the main issue I am trying to solve. Which protocol to use. \$\endgroup\$ Commented Oct 26, 2021 at 22:03
  • \$\begingroup\$ I was considering the case where you don't need to correct this error. \$\endgroup\$ Commented Oct 26, 2021 at 22:03
  • \$\begingroup\$ 1ppm XO's only cost the same as 20 ppm Xtals in high volume $0.25 at any frequency digikey.ca/en/products/detail/njr-corporation-njrc/… so the problem is easily solved and implemented \$\endgroup\$ Commented Oct 26, 2021 at 22:06
  • \$\begingroup\$ Ah OK. Yes, I think that is a good idea. But, since all sensors will have to be tuned right before the test, and they will still drift, it doesn't fully solve it. We also still have the issue of the accurate start / end time \$\endgroup\$ Commented Oct 26, 2021 at 22:08
2
\$\begingroup\$

Wifi has a timing synchronization feature that it uses for its internal time division multiplexing.

Perhaps you could use that ? If you use ESP32, the API function esp_wifi_get_tsf_time() looks like what you're looking for. If you use another chip, there's probably an API for it.

\$\endgroup\$
4
  • \$\begingroup\$ That results in several ms error. Using NTP isn't nearly accurate enough \$\endgroup\$ Commented Oct 27, 2021 at 1:45
  • \$\begingroup\$ Wifi TSF (timing synchronization feature) is not NTP. \$\endgroup\$
    – bobflux
    Commented Oct 27, 2021 at 6:52
  • \$\begingroup\$ Woah, you're right. I'm going to dig into that more. That may be the solution! Will report back \$\endgroup\$ Commented Oct 27, 2021 at 14:02
  • \$\begingroup\$ I've never used this, I'm just passing the hot potato. I think it's worth investigating since after all it's supposed to do exactly what you want. If this works, then accuracy should depend on whatever clock feeds the chip with the wifi. Will it work is another question, after all it's computers and computers never work. I'd be interested in knowing what you will find after digging... \$\endgroup\$
    – bobflux
    Commented Oct 27, 2021 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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