BU353 and CF

[BillyGalbreath]

I can verify that the BU-353 GPS receiver works in CF v2.1 on Windows 7 Beta with the help of xPort3.

I first tried without xPort and it would not work at all. After hours of tinkering I realized that my pc hasn't been reset in over 2 months, due to always going into hibernate when I kill the ignition. So, upon resetting the computer the device worked in CF. After testing a hibernate the device failed to work in CF again.

The device worked perfectly in StreetDeck on a fresh boot and after hibernate and after S3 sleep. So this was quite frustrating for my newly purchased CF to not work.

I installed xPort and ran as administrator (Windows 7 is pretty much like Vista) and split my com8 (bu-353) to com2, com3, & com4 @ 4800. Device Manager lists the device on com8 @ 9600. CF is setup to use the device on com2 @ 4800. All works fine now. There is a slight lag that seems to put my position about 1 second behind where i actually am on the map and there is about a 5 second delay before the device "kicks in" after resuming from hibernate, but nothing too painful. I'm just happy it works after spending so much money on software.

My only complaint is the fact we have to use a 3rd party software to get this to work right with CF when other frontends (StreetDeck, being the one i've tested) works perfectly fine on its own. Perhaps the CF devs should look a little deeper into the issue rather than using these 3rd party softwares as a crutch?

Hope this helps someone else!

[Scott]

Just as an FYI, it's an issue with Destinator (the navigation engines COM object to be exact), not Centrafuse...

[BillyGalbreath]

Originally Posted by Scott

Just as an FYI, it's an issue with Destinator (the navigation engines COM object to be exact), not Centrafuse...

Obviously.. But the fact still remains that the CF devs can do something about it. If a 3rd party app can fix the issue, what stops the CF devs from creating a similar approach inside CF itself eliminating the need for 3rd party softwares? I'm just sayin'...

[HiJack]

Originally Posted by BillyGalbreath

Obviously.. But the fact still remains that the CF devs can do something about it. If a 3rd party app can fix the issue, what stops the CF devs from creating a similar approach inside CF itself eliminating the need for 3rd party softwares? I'm just sayin'...

At this point it doesnt matter. Flux is already researching a new NAV engine, so this issue will most likely go away.

[Scott]

Originally Posted by BillyGalbreath

Obviously.. But the fact still remains that the CF devs can do something about it. If a 3rd party app can fix the issue, what stops the CF devs from creating a similar approach inside CF itself eliminating the need for 3rd party softwares? I'm just sayin'...

As I already said, there is nothing we can do. I am a CF dev. XPort does not open the com port through the destinator com object as CF does, there is something in the com object that gets out of whack when trying to open serial port after hibernation. Using xport, destinator isn't trying to open the real serial port, it's opening a virtual port, and it has no problem with that. XPort performs the magic that the destinaotr object cannot.
Now that that's cleared up, .

[rgballard]

Originally Posted by ted

hi i had the same problem i now use xport. had no problem since

Where do you download this xport? I can only see versions for backing up an ipod, mentions nothing about com ports... Please help, seems to be shareware, but would be willing to purchase for the right price.

Thanks, Fustrated.

[nisarg86]

Originally Posted by rgballard

Where do you download this xport? I can only see versions for backing up an ipod, mentions nothing about com ports... Please help, seems to be shareware, but would be willing to purchase for the right price.

Thanks, Fustrated.

Search lil bit on forums.
here is the xport link.
XPort