Hi,
I have a couple of questions regarding the system timer
Regards,
Shijo Thomas
Anybody have some inputs to share?
Are you asking about the Trek code and/or the Decawave ranging implementations or more generically for any system using the DW1000?
For the more generic answer:
If the timer wraps around then what happens depends on the firmware, any non-trivial implementation can detect and correct for this rollover effect and so it has no impact to normal ranging applications.
The simple way to handle wrap around is to assume that any times with the most significant bit set in the time period is caused by a wrap around. Since the wrap around time is around 17 seconds (2^40 / (128*499.2)) this means that the maximum delay that can be used is about 8.6 seconds.
However longer periods could be handled if the wrap around is detected and corrected differently.
If however the firmware is aiming to be efficient you could assume that for any reasonable TWR implementation the final times will fit into a 32 bit variable. This gives a memory and processing time benefit for most embedded systems but means your maximum delay is around 67 ms.
Of course the longer the delay the greater the impact of clock rate differences and so the larger the ranging error. TWR tries to correct for this but it’s not going to be perfect.
The timer wraps in about 17 seconds and this is easily detected and adjusted for. I would be very surprised if the Trek code doesn’t handle it properly.
In simplest practical terms, a TWR that takes more than ~8.5 seconds (half a wrap time) introduces wrap ambiguity, so that defines a simple upper limit. However, there is no absolute maximum, even well beyond 17 seconds, as you can keep track of wrap times and figure it out. In our systems, we maintain a 64 bit “network time”, which is 24 bits beyond the 40 bits provided in the DW1000. This allows a wrap time of just over 9 years.
How practical it will be to have long duration TWR cycle times will depend on the stability of the clocks at each end of the ranging system.
The original EVB1000 system years ago had a 300 ms ranging cycle (150 ms between packets) and still produced good ranging data, which I thought was very impressive using ordinary crystals. A 10 cm error from clock drift meant the clocks didn’t split by more than about 100 parts per trillion (ppt), which is very stable.
If you had atomic clocks at each end of the ranging system, then you could potentially do a ranging over days. So the answer to how long you can go depends on your clock system.
As a sidebar, the most recent SpaceX Falcon Heavy launch, mission STP-2, included a payload called the Deep Space Atomic Clock, a very precise clock that will enable “one way” navigation in deep space. Present technology requires two way ranging (sound familiar?) which takes a long time (minutes or hours to compute ONE location). The DSAC will allow a space craft to locate itself without the round trip time, dramatically increasing the update rate on location.
A very interesting pre launch briefing on the DSAC (cued up to the 15 min related to DSAC):
The goal is 1 ns (30 cm of distance at the speed of light) of drift in 10 days. So, if you had one of these at each end, you could do UWB TWR over days and not see appreciable error. Indeed, you could also do one way ranging with such stable clocks as well, just like NASA is trying to do.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408
Thanks, Andy & Mike for the wonderful explanations
Hi,
When we do a soft reset, will the system timer get resetted?
Regards,
Shijo Thomas
Hi,
Yes it will.
I use soft reset to clear system time in my tags after recovering from sleep. My tags are dumb and to reduce processing needs, I use delayed TX with calculated time (relative to zero clock).
I’d be so happy to be able to reset sys_time 0x06 register only but I haven’t found any method for this. I believe this is not possible.
I’m using my own hardware and code.
Isn’t that the function of SYNC pin? I mean, page 86 of User Guide, when talking about sync clock reset event, states:
External Sync Clock Reset. This event status bit is set when the system counter is reset as a result of the reception of an external synchronisation clock reset signal on the SYNC pin. The ESYNCR flag bit is cleared by writing a 1 to it. Section 6.1 – External Synchronisation describes this feature.
Well, it is indeed the function of SYNC pin, according to the application note APS007, page 8:
The DW1000 has a SYNC input pin that can be used to reset the on-chip system clock’s counter
value to zero.
Thanks for this info.
I’d need a soft solution though otherwise I’d need to re-design my bord layout.
Has anyone been using this kind of clock reset?
Thanks,
Dez
I have just used and it works like a charm. I implemented the following sequence to test it:
So, I put this so you could have the reference to understand the following data (a chunk of the total data):
17,64419 µs
1,20553342825 s
17,70829 µs
201,48220856 ms
17,63617 µs
1,20535108096 s
17,66822 µs
201,51931584 ms
17,66822 µs
I couldn’t figure out everything properly because I was sick since friday, but I will play with the WAIT register to see if it changes the after-reset SYS_TIME a lot.
Thanks for confirming that.
I haven’t connected DW1000 sync pin to my controller so will change the design layout and test it myself, too.
Cheers,
Dez