On Mon, May 7, 2012 at 2:48 PM, Ed W
<address@hidden> wrote:
On 07/05/2012 19:04, tz wrote:
On Mon, May 7, 2012 at 1:41 PM, Ed W <address@hidden> wrote:
Hi
I think I might not be getting my point across. Assuming
more like 4,800 to 38,400 baud then there should be
variation of only one character arrival uncertainty to the
timestamp of the start of the ZDA sentence. However the end
of the sentence could have much larger jitter, up to 1ms (eg
consider we read only the very last character and the rest
of the buffer is empty)
So my jitter is currently 1ms ish, but I believe it should
be possible to reduce that to 0.5ms. Do you agree?
No, because USB "jitter" is random 0-1mS. It will set the
interrupt condition when it sees the character arrive, but it
has to poll and it only polls every 1mS. There is no way to
average it out
But my understanding is that we get the data (very quickly) after
the poll is done. Therefore we should get a decently accurate
timestamp of the end of the USB poll. So the poll event might be
quick random, but we should at least know when it took place. Is
this correct?
The actual time of the USB poll isn't accurate, so any timestamp would have a builtin error. Also you don't know when the character actually came in. It might be starting to come in but incomplete during the current poll, so it will appear (over) 1mS later at the next poll, or it could have just been completed and enough housekeeping was done so it came in a few microseconds before.
So in practice USB polls will take place at intervals from 0.5ms to
1.5ms, however, we should be able to timestamp *when* they take
place, even if we can't predict them in advance. Seems like this is
not a problem in practice and possibly beneficial
Timestamp with what and how? The polls are done internally on the "hub" chip and you don't really know one has occurred except that you see an interrupt indication for something. There isn't a "poll" bit accessible in the driver via ioctl or any other mechanism. All that is hidden and buried.
First question though -
did I correctly understand the current gpsd algorithm?
Yes, but it creates an offset, It remembers the time of
something early but it doesn't try to compensate for baud
rate, and may remember the end of sentence.
See I think if you measure the end of the sentence then you get a
different error than if you measure the start of the sentence. This
is because you have an unknown quantisation at the end which isn't
present at the start (or at least the size of the error is smaller)
I've done similar experiments. There is an OFFSET
because of the latency to the last sentence, but the
jitter is consistent with USB jitter. 115200 baud
is fast enough that it takes a 10 character
difference in the messages to add up to 1mS. You
might want to try 230400, though the Venus meters
the characters out at less than full speed.
2) *IF* not just the initial bit, but in fact if every bit
of the Venus 6 output were of low jitter, then because we
collect multiple observations of the serial output via
USB, then it should be possible to improve our estimate of
the arrival timestamp below the 0.5ms mark. ie we can
observe the number of characters read on each USB
timestamp, compare with our predicted number of characters
we should be able to get sub ms estimates of the arrival
time of a particular character - use that to work back and
get the arrival time of the first bit. Note that if
feasible, this technique would give better accuracy than
PPS over USB !
You cannot measure the error. It is random and not a normal
distribution.
Sorry, which error can't you measure? Also I don't see why you
can't so can you please explain why you think you can't?
You have an event correlated with the PPS, e.g. the first character of the first sentence. That can be visible on an oscilliscope.
In order to timestamp it, you must have something you can do at the far end to detect it. (I've toggled one of the other serial port pins in response in my tests when TIOCMWAIT came back).
On the scope, I can see multiple miliiseconds - variable - of jitter for any user program including one at nice -20 between either the PPS itself or the first character, and the line I toggle to indicate it came in. If the kernel is doing disk-io or something else intense, any user program won't get the message until it is unbusy. You need a time-slice.
If you can go into the kernel itself and timestamp within a hardware interrupt (on a multicore), you can do high accuracy. The USB poll is not an interrupt as such, and timestamping in userland is not going to work better than 1mS, but there will be outliers.
To recap, my expectation is that if you put it on a scope, the Venus
chipset will send the initial $ with PPS level precision, and even
subsequent bit will be delivered with very low jitter at 9,600 baud
until the end of the ZDA sentence. Can you please shoot down that
expectation if it's not true?
Yes, on the scope it is precise. But the USB is imprecise to over a mS (and isn't correlated), and then there is the kernel housekeeping, task switching, and whatever else between when the event occurs and the timestamp is obtained. You can get close to 1mS using USB on an non-busy system but not more.
The follow-on is that *if* the per character transmit time is
constant and low jitter, then it's not a problem that our
observation process of those characters is high jitter. As long as
we can observe "now" with decent accuracy then we can collect enough
samples to infer the exact arrival time, even though there is jitter
in the observation process.
We can't observe "now" with a decent accuracy from userland, and even in the kernel interrupts can be off for a millisecond in bad cases - though more often it will only be a few microseconds. But you need the event to be timestamped correlated to the PPS edge - either PPS signal or character in the first place. Over USB that doesn't and won't happen - USB 2.0 can go to 125uS if you set the bits so it polls at 8MHz.
Key question is whether a) initial bit is delivered with precision
(you confirmed yes) and b) subsequent bits are also delivered with
low jitter? Can you confirm/deny b)?
They OCCUR with that precision. They are delivered with a precision no greater than 1mS over USB to the kernel and worse if it is userland.
No, the USB "timing" is equivalent of white noise. The
timestamp of the USB will be 0-1mS from when the real
interrupt occurs with no way of calculating or predicting it.
What process causes this? Once the USB bus wakes up and polls the
device, where does the data go for the rest of the time before
delivering it to the operating system? Generally buffering things
is tricky and expensive so I would have expected a much simpler
algorithm where the USB bus wakes up occasionally and simply
delivers whatever is waiting at that point - as such we can measure
the wakeup event, it's "now".
USB doesn't "wake up". USB sends an interrupt pol packet over the wirel every 1 millisecond. The device responds with a packet indicating whether there is an interrupt condition or not. It then gets more info and possibly characters in response.
The USB Host controls everything and it only polls every 1mS (1.1) from the USB host chip. The host chip cannot see anything on the peripheral chip until it sends a packet to request it.
Thanks for your insight
Ed W