[4.1] Make use of precision packet timestamping (PTP)

Status
Not open for further replies.

Fiskusmati

Active member
Hello.

I'm working on fmcw radar system.
Radars are working on the same frequency, thus they need to be switched on and off so that only one radar transmits at any moment "time domain multiplexing".
I'm using teensy 4.1 boards to control each radar.
Each teensy board is connected to a ethernet switch or router (they are connected in one network).

I need a server board that will send "allow" signals to each slave. And after slave receives this signal, it turns high one of GPIO ports for fixed and hardcoded period of time "eg. 100uS".
I could use standard udp packets etc, but it turns out to be not very reliable way to achieve this because there is huge delay.
I need time "t" showed on scheme below to be 1us or less.


Scheme:

img.jpg

Please guide me if PTP is the way to go here? Does Native Ethernet library for teensy 4.1 works with PTP and how to use it?

Thanks
 
Please guide me if PTP is the way to go here? Does Native Ethernet library for teensy 4.1 works with PTP and how to use it?

Thanks

I'm not sure Ethernet is the way to go to get 1 us control of your slaves. Any way to have digital connections from master to each of the slaves?

T4.1 does support PTP, see
https://forum.pjrc.com/threads/61581-Teensy-4-1-NTP-server
ddrown's 1088 support in the NTP server is using lwIP lib. I don't believe NativeEthernet lib has provided support for PTP/1088.

You might be able to use ethernet multicast. Your master could send out a multicast packet to initiate a transmit sequence. each slave would receive the multicast at the "same time" and schedule their pulse based on their "slave number"

ddrown might be able to suggest how to use PTP to get the "time" on each slave closely sync'd,. then master could provide a pulse time to each slave, or?
 
A few observations.

One, Ethernet is not the right way to do this. It is not designed for timing this accurate. There is a lot of overhead with TCP/IP: packet fragmentation, checksumming, reliability, etc. The use case for it is more asynchronous communications where you "eventually" get a packet through, and it's "good enough" whether it takes two milliseconds or two hundred. For industrial control there are other options that have much less latency, like CAN and SPI. If the boards share a common ground, you could just run a single line from the master to each slave. (BTW, the industry is trying to get away from "master/slave" nomenclature. Not here to judge the merits of that, merely communicating it.)

My understanding of PTP is that it answers the question "what time is it, really" but is not intended to directly drive these kinds of communications. To do this over TCP is even slower than UDP because it's designed for reliability, whereas UDP is less reliable but faster.

Two, not sure you need this topology at all. I don't know how many I/O lines each radar uses, or how much heavy lifting each Teensy is doing. If one Teensy can run all three radars (enough I/O lines + CPU + RAM) then I would do away with the setup in the diagram entirely. Teensy is capable of multithreading using timers. If your accuracy is +- 0.5 uSec, it's probably accurate enough. You can test with an oscilloscope.

If the timers are not accurate enough, or if they take too much CPU, you can also set up three waveforms in RAM (a binary image with 0 for low and 1 for high, with each bit representing 1 microsecond, or however fine-grained you want it) and use the DMA controller to continuously send them to the right pins. If the DMA controller is doing that, your CPU consumption from this activity is zero, and it will keep transferring the waveforms that drive the pins until you tell it to stop. The speed of each DMA channel is set by a clock and divisor register, and the accuracy is extremely high. Each DMA channel can run at an independent speed.

Depending on how the radar is set up, DMA may be the right answer for reading data from the radars as well. If it wants to transfer the data at exactly 11.5KHz, or at exactly 11.5MHz, or whatever, DMA will do that. On the other hand, if it has clock + data lines, you have a few options.

The first option is to write a "forever loop" that polls the clock pin for the active radar, and when it reaches the desired state (high or low, depending on the radar specifications) it samples that radar's data pin. If you have to do post-processing on the signal, you can do it after this, but as the post-processing gets more sophisticated it can take longer. That puts you at risk of missing input pulses, having to worry about instruction cycle timing, etc.

The second option is to plumb each radar's clock signal into an IRQ line. When the clock signal is at the state meaning "read data now", the IRQ "steals" the CPU and sends the program counter to an interrupt service routine. The ISR reads the data line, appends the value to the input buffer, and then returns control. In this way, you can experiment with post-processing, while remaining confident that you will never miss an input pulse. You still have to do everything fast enough, of course, but this gives you more protection against accidentally missing a pulse. Some little logic in your main loop can check to see if it's starting to fall behind the input data, and raise an error so that you know your post-processing routines have to run faster.

The third option, and I'm not sure if the chip supports it (probably?) is still DMA, and it transfers from the data pin to RAM when the IRQ line reaches the desired state. This is very similar to the ISR, except that it consumes zero CPU.

If you are doing this on a Teensy 4.1, my assumption is you have "all the time in the world" to do post-processing, so you can pick whatever method is best. Polling and filtering should be easily possible from a main loop, but with DMA - whether you have a clock line or not - you know the data is ALWAYS going to get transferred, no matter what, with zero CPU consumption. It's also potentially more energy-efficient because you are not spending any CPU time on polling the clock signal in a forever-loop.
 
Last edited:
Thank you for your suggestions.

Two, not sure you need this topology at all. I don't know how many I/O lines each radar uses, or how much heavy lifting each Teensy is doing. If one Teensy can run all three radars (enough I/O lines + CPU + RAM) then I would do away with the setup in the diagram entirely. Teensy is capable of multithreading using timers. If your accuracy is +- 0.5 uSec, it's probably accurate enough. You can test with an oscilloscope.

Each radar is controlled by single teensy, almost all pins are used for that (28 pins are used for ADC 2x14bit, others are for clocks, spi, enabling tx, etc, etc...).
Each radar can be up to 50 meters (165ft) apart, without common ground.


If not ethernet, i thought about just using "non used" pairs of Ethernet cable (100Base-T is uses only 2 pairs), and place separate teensy near ethernet switch, just to control timing for each radar by dedicated lines. Altohugh this idea might seem okay, I think sending asymmetric 10khz 3,3v signal through 50m will be a disaster, so we need more circuitry to make this signal symmetrical and higher voltage. Maybe RS-485 is the way to go?
 
I would go with shielded RS-485. It's already engineered by supercool EE geniuses as a finished product, and it supports enormous runs (way bigger than you need.)

With some kind of twisted pair, you might do okay, but you would want it shielded so it doesn't pick up every AM radio station and doorbell. I don't know enough about the engineering, if you have to debounce it, etc. Cat-5 is rated for 100 meters, and you don't need huge frequency anyway, so it might be okay. On the plus side, the Ethernet connection for the Teensy 4.1 doesn't support PoE; but if you don't use it, you could run power over some unused pairs. (Seriously, PoE would be INCREDIBLE with these!)

Finally, you could keep the clocks in sync with the precision timestamp thing, but I don't know if the Ethernet implementation is buffering data for you. If it isn't, and you have to let it raise an IRQ any time it feels like it, it might step on your radar task. You might even have to shut down the antenna until it finishes, twice an hour or however often you want to sync it up.

To me, the Ethernet solution doesn't carry power, so you have to do that separately, so it's the same problem you have with RS485... and RS485 is already a finished product that will politely buffer some data for you. Someone has already done the engineering for you, and you don't have to worry about the Ethernet/TCP stack stepping on your main task.
 
A good implementation of PTP "should" be able to achieve sub-microsecond timing synchronization over a LAN. Agilent said in 2005 their experience with PTP / IEEE1588 is ~ 0.1 microsecond accuracy with a lightly loaded LAN and whatever hardware they think of as "inexpensive oscillators". BUT I am not aware of a full implementation of a PTP client for Teensy yet, although there's been recent work done on a PTP server. Also I do not think any LAN has microsecond latency, PTP only gives you local clocks that are aligned. So you have to map out and distribute a schedule ahead of time, about which microseconds at some point in the future each node is permitted to transmit. https://www.nist.gov/system/files/documents/el/isd/ieee/tutorial-basic.pdf
 
RS485 does sound like a pretty good approach. If using the CAT5 cables, you might have one pair for bidirectional data and perhaps dedicate a pair for a simple unidirection pulse from the server to the 3 radar sites. You could just use GPIO for the pulse, so something like attachInterrupt could give you a very rapid response at all 3 locations when it's received.
 
I am interested in using PTP as well, I believe its a key enabler for time-sensitive control systems. So far I am using the NativeEthernet library for UDP communication, which is working fine. I would like to add time stamps to each packet sent. Is there any implementation of the PTP client for Teensy 4.1 ?
 
Status
Not open for further replies.
Back
Top