So it does....
Most nav software accepts only NMEA data, but it appears the CF engine is different in that regard.

You can certainly set the BU353 to Sirf mode and see if it makes a difference. I don't know if it will or not.

I recall at least one other user on these forums with a similar issue. If I remember correctly, they had a bad GPS receiver. They got it replaced and all was good.
That may or may not be your issue, but it's worth investigating.

BU-368 Solution

Hey Mate,

I had a similar problem to you, but i have the new Globalsat Bu-368, the bluetooth GPS one as my old BU-353 died on me.

Anyhow, i had the same problem, in Centrafuse (uses Destinator) when the gps was set to NMEA mode and 38400 (default for this device) Centrafuse was very laggy.. about a 3 second delay in updates so when your driving, and you need to take a turn, you pass the turn before you notice it!

I have found a solution to the problem though. Use SirfDemo (google it for a download) connect the GPS Device to the computer then open SirfDemo, select the com port the device is on and the baud rate. Once thats done, in sirfDemo go Action -> Open Data Source. If the device is in NMEA mode, the only window that will be showing data will be the Debug View - NMEA.

Now, From the Action -> Switch to Sirf Protocol. the program might look like it hangs for a few moments, but it is just setting the GPS device in Sirf mode. Once in this mode, all the other windows should now be displaying information. The Debug wont. So far the device is set in Sirf Mode.

Next, choose Navigation -> Mode Mask. Check the box which says Smooth Tracking and click Send. You can verifiy if the GPS has this enabled by looking at the Response View (pause the gps output by choosing Action -> Pause Display), Alterinativly choose Poll -> Nav Parameters and see that TrkSmoothMode = enabled.

Now thats done, go to Action -> Set Main Serial Port and choose the com port and set the device to 57600 (this should be the default in SirF mode anyway)

Finally, go back into centrafuse and go to the setup section, choose Protocol -> Sirf and Baud -> 57600.

Go out for a drive and test.

From what i have found, if i place my bluetooth GPS on the dash near the windscreen, the display GPS position is quite good, it updates my position on the map every 1 second or so, much better than the laggy version i had perviously! if i place the device near my cigi lighter near my gear shifter, then it still updates pretty well (~1 second) but is a little more laggy when i take corners, it initally sees me taking a corner, then goes around said corner, finally figures im about 75m from the corner and adjusts my position correctly. Once im on a straight though, it works pretty well.

Mind you these settings worked well with my Bluetooth GPS (new one) but it should be the same for the BU 353. My old setup was just as laggy, but maybe a little less than my Bluetooth before i sorted it out with SirfDemo, (2 second lag opposed to 3 second with Bluetooth).

I have a similar problem with my bu-353 and destinator (both 6 & 7). I'm starting to wonder if position in the car is part of it, and I'm not just talking about reception. Currently its located in the trunk. I wonder if I moved it to the very front of the car, almost a car length distance forward, whether this would be enough to correct the lag.

It's probably not related to NMEA or Sirf protocol (no matter what, they update @ 1Hz) but the TrkSmoothMode option. Isn't that use to filter out position so it doesn't report small moves (accuracy/hdop related, mostly) ?

cant seem to get this to work with my device. tried From the Action -> Switch to Sirf Protocol several times and it does nothing, even after waiting 2 or 3 minutes.... i have no idea what to do and am totally frustrated as... funny thing i was using same gps receiver on my older carputer without a problem.

Just wanted to let you guys know I fixed a BU-353 lag which showed up while on vacation. On my trip down south in the wife's car + asus netbook, everything worked great. I was on the beach for a week with the GPS unplugged and the netbook was doing other things. Well on the way back I plugged the GPS back in and noticed the lag in both iGO and iGuidance so I knew it was not the GPS software. I doubted it was the actual GPS hardware since it worked fine a week ago. Turned out to be the OS layer (stupid XP) The first time gps worked good it was using virtual com port "3" according to windows. On the return trip I noticed it configured itself to use virtual com port "6" and after that it worked like crap. Anyways I went to device manager, deleted the virtual com port "6" and unplugged the GPS puck. Plugged it back in and it reverted to com port "3" again and viola it works again.

So just wanted to share my solution, since we are using a weak OS (XP) I don't think it likes virtual ports over 3. So those with problems see what virtual port windows has assigned to your GPS. I'm going to try windows 7 on this little netbook to see if it makes a difference.