0
\$\begingroup\$

I am working on a wireless telemetry project with a bit of a twist.

I have a CC3220 inside of a rotating shaft connected to an AMS board collecting pitch readings from a magnet mounted inside.

The data is being sampled at 20 MHz and stored locally on the MCU. After 5 seconds of collection, the data is wirelessly transmitted (over Wi-Fi) to my computer where some software crunches the results to display graphically.

Along with the pitch measurements being collected inside the shaft, I am also gathering other metrics with sensors connected directly to my computer. I would like to see how the pitch affects these other readings, so I need to stitch the data together after I send it over Wi-Fi.

The problem is with lining up the data. Because the MCU is separate from the rest of the sensors, it doesn’t start at the same time that I start the others because of the delay induced by using Wi-Fi, so I don’t know the initial time of the first pitch reading to line up with the rest of the data I collect.

I started looking into other RF solutions, including Bluetooth and Zigbee but had to rule those out because of the latency (3 seconds and 15 milliseconds respectively.) This got me wondering if there was ANY wireless protocol that has a latency of less than half a millisecond. The transmission would only have to be one-way. A simple pulse meaning “GO!” to start sampling; then using Wi-Fi to send the data back. If there is no RF solution then I will have to re-engineer the housing to allow a laser diode to have line of sight, but this will cause the cost of this project to skyrocket… which I would like to avoid!

Do you guys have any suggested reading on RF latency? Have any of you had to overcome a similar problem? If you need any more info let me know, I’m not very experienced yet, but that’s why I’m here trying to learn!

\$\endgroup\$
4
  • \$\begingroup\$ Synchronize the devices using a blip on an AM or FM modulated carrier? \$\endgroup\$
    – Jeroen3
    May 23 '17 at 13:32
  • \$\begingroup\$ So, how accurate (in seconds!!) do you need your synchronous sampling start to be? That makes a whole lot of a difference. Also, your transport latency is not the least related to the problem. \$\endgroup\$ May 23 '17 at 13:32
  • \$\begingroup\$ I use a laser and centre-of-shaft comms (up to 600 Mbps) for a stack of high speed sensors. I cannot rely on any radio transmission in most of our applications. I also use round-the-shaft data transmission but this is more complex than laser. Everything is synchronous and has a 5 us frame rate hence latency is not that great. Think big! \$\endgroup\$
    – Andy aka
    May 23 '17 at 13:50
  • \$\begingroup\$ Jeroen3 Thank you for your replies! FM sounds like a promising path, I'm reading into that now looking at the nRF2401A. @MarcusMüller Right now, I am aiming for +/- .001s difference between the angle reading and the other data collected. If I could just get an accurate starting time of the first pitch measurement then I could calculate where the rest fall along the timeline... maybe? Andyaka That sounds sexy! But alas, my budget is limited and there is no line of site into the shaft, re-designing for a laser is out of the question... for now. \$\endgroup\$ May 23 '17 at 14:49
1
\$\begingroup\$

Your problem isn't solvable by lower transport latency. That's simply unrelated to your problem; your transport latency might be arbitrarily low, but with a random offset between your controller initiating sampling and it sending the data, no direct conclusions on the start of sampling might be made.

Conversely, you could just as well have days of latency, if just all sensor data had precise timestamps, so that you could align the data in the PC.

Now, your 1ms synchronity is really not that much of a challenge with modern electronics. Your MCU will have no hard time at all triggering anything with a timing ambiguity far smaller than that.

A usual approach here is to share a common time source – there's a lot of options here; the established ones are

  • A shared trigger signal. For your bandwidths, a simple pulse over twisted pair or coax to all sensors so that they start converting synchronously. In measurement equipment, you'll often find PPS in- and outputs.
  • A shared, dedicated trigger RF signal. To achieve a 1ms accuracy, your pulse's bandwidth should be >> 2 kHz (which really is nearly nothing). There's plenty of GMSK / FSK modems that would achieve that, as a side effect of being able to receive packetized data. As Jeroen3 pointed out, you could also just build an FM modulator and a matching detector (in discrete electronics!).
  • Same goes for optical communication: Transmit a pseudorandom sequence of 0s and 1s with one microcontroller using a strong IR LED, and let all sensor nodes look for that sequence in their MCU code. Use cross-correlation to find the temporal "center" of the sequence. Synchronously start sampling a fixed interval later
  • GPS receivers often have a PPS (pulse per second) output. That's what is used to synchronize a lot more timing-sensitive systems (e.g. cellular base stations, which need way better synchronicity than +-1ms)
  • Abuse some easily receivable RF signal to find your timing – for example, let the sensor also record a bit of DVB-T spectrum for a short duration. On your PC, record the DVB-T spectrum continously. Then, cross-correlate sensor-observed and PC-observed RF signal, calculate exact start of sampling at sensor. Again, your observed bandwidth limits the accuracy; the higher the bandwidth, the lesser the timing ambiguity. For your 1ms case, however, as mentioned, a couple kHz would do, and FM Radio would also totally do (just that in this case all your devices only are receivers and you don't have to worry about not messing with FCC/BNetzA/OFCOM regulations).
\$\endgroup\$
3
  • \$\begingroup\$ Thank you so much for your reply! I'm going to take some time to go through these options and find out what I have access to in the lab before approaching my manager with ideas! I hope you don’t mind if I have follow up questions =D \$\endgroup\$ May 23 '17 at 15:16
  • \$\begingroup\$ I don't mind at all, but I recommend asking them as separate questions on this site (certainly, with a referral to this answer and your original question) – I'm not available 24/7 :D \$\endgroup\$ May 23 '17 at 15:17
  • \$\begingroup\$ Another approach would be to send two transmissions, with the second transmission including a time stamp that indicates when the first transmission was actually completed. On some of the radios I've seen, the precision available to measure the latter time may be finer than the precision available when trying to trigger a transmission. \$\endgroup\$
    – supercat
    May 23 '17 at 18:40
0
\$\begingroup\$

I recommend using a ISM band radio (900MHz or 2.4GHz) with a proprietary protocol. TI makes a bunch of these (CC1310 for 900MHz, CC26xx for 2.4GHz). That way you can make them go as fast as you want. Ask on the TI forums for more information; they may have some sample code for you. The datarates on these chips can get really high and without a stack you can have very deterministic timing.

\$\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.