Moderator Comment by Chris Anderson on April 20, 2009 at 9:31am

I'm not sure about this. We did hit five waypoints in 32 seconds in binary mode in the Sparkfun competition, which wouldn't be possible with 12 second latency. I suspect it may have something to do with the way you're setting up binary mode in your code, maybe accidentally enabling that track smoothing function?

Moderator Comment by Jack Crossfire on April 20, 2009 at 10:14am

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.

Developer Comment by William Premerlani on April 20, 2009 at 1:56pm

@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.

Moderator Comment by automatik on April 20, 2009 at 5:46pm

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...

Developer Comment by William Premerlani on April 20, 2009 at 6:49pm

@automatik

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.

Developer Comment by William Premerlani on April 22, 2009 at 3:18am

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.

best regards,
Bill Premerlani

Comment by Paul Fox on August 12, 2009 at 8:47pm

Bill -- i've been hitting a similar 14-second latency issue with a different GlobalSat device (BU-353, i think). you can read about my problem here: https://lists.berlios.de/pipermail/gpsd-users/2009-August/003861.html

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

Developer Comment by William Premerlani on August 13, 2009 at 3:49am

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

Comment by Paul Fox on August 13, 2009 at 1:27pm

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.)

paul

Developer Comment by William Premerlani on August 13, 2009 at 1:36pm

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

Comment

• ‹ Previous
• 1
• 2
• Next ›
• Page