The mystery of the 12 second latency in the dynamic response of the EM406 GPS is solved.Recently, I stirred up a debate about whether or not the EM406 has a 12 second latency or not. A few of us were seeing a 12 second latency. The majority of EM406 users were not seeing it.It turns out that the dynamic performance of the EM406 depends on which interface you use, NMEA or binary. If you use binary, there is a 12 second latency, then a 3 second "smoothing" transient.If you use NMEA, there is a smoothing transient only. The NMEA interface to the EM406 provides dynamic performance as good as the LOCOSYS or the ET312.It is my speculation that "track smoothing" is turned on in the EM406 for the binary interface, and either it is always on, or I have not figured out how to turn it off. If anyone knows how to turn track smoothing off in the binary interface for the EM406, please let me know so that I do not have to scrap my binary interface and start over on a NMEA interface.
well, by "intermittent" i mean "for days at a time". and then it will be okay for days or weeks at a time. so, for instance, if i was running in binary mode, and somehow got switched to NMEA mode, and then some time later it got switched back, it could explain my symptoms. this conversation, and some other investigation, are teaching me what to check next time it's in high-latency mode.
Paul,
The latency problem that I was seeing was not intermittent, it was always there. So, if the latency that you are seeing comes and goes, you may have a different problem.
Bill
bill -- thanks. i'll certainly check the baud rate next time i get the symptom. (and i'll try a low rate, specifically to try and reproduce it.) in my case, either due to my particular receiver, or the set of s/w that i'm using to access it, the latency issue isn't easy to cause to happen. (at least, so far.)
Yes, I am saying the problem is with the sirf device itself. It is not with the "track smoothing" filter.
There appears to be a communications buffer in the GPS itself, that gets flushed in some conditions, but not in others. When it does not get flushed, that is when you get a large latency.
There seems to be two ways of flushing the buffer and eliminating the latency.
One way is to use the NMEA mode. It seems that the carriage return/line feeds in the NMEA messages flush the buffer.
In binary mode, I suspect that any of the GlobalSat devices will suffer the long latency at any of the lower baud rates. The simple fix is to run it at a higher baud rate. I am not sure how high you have to go, but 19,200 will certainly solve the problem. At 4,800 there will be a latency. I am not sure about 9,600, I never tried that one.
my research led me to the sirf "track smoothing" filter, and i was ready to play with that, until i came across the above posting. are you saying the sirf device itself has a large unflushed buffer? if so, how do you force it to flush? do you simply run in NMEA mode instead? alternatively, are you saying that your computer's serial input was balking, and that you had to fix the input configuration of the port?
(sorry for the reply to a somewhat old thread.)
paul
Well, Jack Crossfire was right. The issue with the latency was with the communications buffer inside the EM-406A. Apparently there is a large buffer. In NMEA mode it gets flushed by the carriage return/line feeds. However, in binary (SiRF) mode, it does not get flushed at the lower baud rates, apparently until it gets full. At 57,600 baud, apparently it runs with little or no buffering.
There was probably a memo on this issue that I missed.
Anyway, the issue is now resolved. I will revise MatrixNav as soon as I can, will probably have it out this weekend.
Special thanks to Jack Crossfire, automatik, Chris Anderson, Louis LeGrand, and Aaron Weiss. It would have taken me a lot longer to figure this out without you.
Thanks. I appreciate all the help I can get on this, its baffling. It is very surprising that the NMEA interface to the EM406 gives me better performance than the binary. Especially since the way I am using the EM406 is very simple: the only command I give it is to change from NMEA mode to binary mode. I leave the message rates and baud rate alone at the default values. I would have thought that I would have gotten the default mode of track-smoothing off, especially since that is what you get in NMEA mode.
The app that you pointed me to shows that the default option is track-smoothing off. From the way the the menus are organized the same way as the messages, it looks like the app will send the same message that I sent from my board to try to turn off track smoothing.
In any case, I will see if I have any better luck with the app, but first I will have to rig up a link between the EM406 and my computer.
I wrote a NMEA parser for my board today, and revised the demos and MatrixNav to use it, so if I cannot get the binary interface to work the way I want, I have a fall back plan.
Bill,
can you use this app (or something similar) to check or maybe even set up your GPS? Note: I haven't tried this so I can't vouche for it. Just an idea...
@Jack Crossfire,
Thank you very much for your suggestion about the serial port, and my issue with the 12 second latency in the binary mode of the EM406. I am rather sure that it is not the serial port, though I can certianly see why you would suspect it.
I am running all my firmware on interrupts, with no operating system. When the USART on the dsPIC30F gets a character, it generates an interrupt, which gets processed pretty quick. The USART treats all bytes alike, carriagle returns and line feeds get no special treatment, its all just ones and zeros. The USART has a 4 byte deep FIFO, but processing is never delayed long enough to get more than 1 byte in it.
I am going to follow up on Chris Anderson's suggestion that somehow my binary mode did not get set up right.
If you have any other suspects, please let me know.
We had 5 second latency specifically in binary mode because it didn't have carriage returns to flush the serial port. It was still a matter of serial port configuration.
Comments
thanks again!
The latency problem that I was seeing was not intermittent, it was always there. So, if the latency that you are seeing comes and goes, you may have a different problem.
Bill
paul
Yes, I am saying the problem is with the sirf device itself. It is not with the "track smoothing" filter.
There appears to be a communications buffer in the GPS itself, that gets flushed in some conditions, but not in others. When it does not get flushed, that is when you get a large latency.
There seems to be two ways of flushing the buffer and eliminating the latency.
One way is to use the NMEA mode. It seems that the carriage return/line feeds in the NMEA messages flush the buffer.
In binary mode, I suspect that any of the GlobalSat devices will suffer the long latency at any of the lower baud rates. The simple fix is to run it at a higher baud rate. I am not sure how high you have to go, but 19,200 will certainly solve the problem. At 4,800 there will be a latency. I am not sure about 9,600, I never tried that one.
Best regards,
Bill
my research led me to the sirf "track smoothing" filter, and i was ready to play with that, until i came across the above posting. are you saying the sirf device itself has a large unflushed buffer? if so, how do you force it to flush? do you simply run in NMEA mode instead? alternatively, are you saying that your computer's serial input was balking, and that you had to fix the input configuration of the port?
(sorry for the reply to a somewhat old thread.)
paul
There was probably a memo on this issue that I missed.
Anyway, the issue is now resolved. I will revise MatrixNav as soon as I can, will probably have it out this weekend.
Special thanks to Jack Crossfire, automatik, Chris Anderson, Louis LeGrand, and Aaron Weiss. It would have taken me a lot longer to figure this out without you.
best regards,
Bill Premerlani
Thanks. I appreciate all the help I can get on this, its baffling. It is very surprising that the NMEA interface to the EM406 gives me better performance than the binary. Especially since the way I am using the EM406 is very simple: the only command I give it is to change from NMEA mode to binary mode. I leave the message rates and baud rate alone at the default values. I would have thought that I would have gotten the default mode of track-smoothing off, especially since that is what you get in NMEA mode.
The app that you pointed me to shows that the default option is track-smoothing off. From the way the the menus are organized the same way as the messages, it looks like the app will send the same message that I sent from my board to try to turn off track smoothing.
In any case, I will see if I have any better luck with the app, but first I will have to rig up a link between the EM406 and my computer.
I wrote a NMEA parser for my board today, and revised the demos and MatrixNav to use it, so if I cannot get the binary interface to work the way I want, I have a fall back plan.
can you use this app (or something similar) to check or maybe even set up your GPS? Note: I haven't tried this so I can't vouche for it. Just an idea...
Thank you very much for your suggestion about the serial port, and my issue with the 12 second latency in the binary mode of the EM406. I am rather sure that it is not the serial port, though I can certianly see why you would suspect it.
I am running all my firmware on interrupts, with no operating system. When the USART on the dsPIC30F gets a character, it generates an interrupt, which gets processed pretty quick. The USART treats all bytes alike, carriagle returns and line feeds get no special treatment, its all just ones and zeros. The USART has a 4 byte deep FIFO, but processing is never delayed long enough to get more than 1 byte in it.
I am going to follow up on Chris Anderson's suggestion that somehow my binary mode did not get set up right.
If you have any other suspects, please let me know.
-
1
-
2
of 2 Next