Actual transmission time of delayed transmit seems to be varying

I am using the One Shot Timebase Reset (OSTR) and the delayed transmit feature to try to precisely schedule a transmitted packet. I’m seeing variability in reception timing on the receive side and I was initially attributing this to the oscillator drift between the two boards. However, further examination seems to indicate that the same variability is happening on the transmit side. The variability I’m seeing is not jitter, where the rising edge is jumping around. Instead, it’s a consistent drift in one direction over a span of several hundred nanoseconds with each transmission occurring several 10’s of nanoseconds later than the previous transmission. Eventually the drift reaches a threshold, jumps the several hundred nanosecond span backwards, and begins its steady drift up again.

Here’s my test set-up:

  1. The transmit side DW1000 is configured with an external 38.4 MHz clock and receives a sync pulse in every second (provided by GPS PPS).
  2. The DW1000 is set up in One Shot Timebase Reset so when the sync pulse comes in the 40 bit internal counter should be reset to 0.
  3. A delayed transmission is configured after the timebase reset occurs with a delay value of 6 ms. The TX_Start bit is set and the transmission occurs approximately 6 ms later.
  4. A scope is connected to the sync pulse coming in, the TXLED on the transmit DW1000, and the SFDLED on the receive DW1000.

When triggering on the rising edge of the sync pulse coming into the transmit DW1000, I would expect the rising edges of TXLED and SFD to be relatively stable in time. I understand that these outputs can’t be used for sub-nanosecond timing and I’d expect some jitter but a steady and consistent drift of these rising edges over a several hundred nanosecond window seems to indicate that my transmission isn’t always happening at the time I expect it to be happening.

Has anyone seen similar behavior or used OSTR and delayed transmit to try to accurately schedule a transmission? Thanks.

Daniel Parsons

This is starting to look like a measurement issue on my part. I knew the TX and SFD LED outputs were low priority but I think I was still expecting a bit too much accuracy from them. I’ve started monitoring the transmit and receive interrupt outputs instead and they are much more stable.