Can't tell SD not to open GPS COM port

rburhum · 04-12-2007, 12:31 AM

What version of StreetDeck is this bug report for?

1.0.8.1

Please give a basic description of the issue here.

Can't tell SD not to open GPS COM port

Is the systemt that is listed in your CarPC specs under your user name the same system where you encountered this bug?

no

If no, please describe your system here.

winxp sp2 / SD / T3

Please provide any relevent information regarding the issue you have encountered.

Mappoint navigation kept crashing on me so I decided to use SD with iGuidance instead. I uninstalled mappoint and installed iguidance. For some reason, everytime SD starts up, it opens the COM port for the GPS, even though *I don't want that* because it gets in the way of iguidance. Clicking on navigation settings does nothing since mappoint is not there. Resetting SD settings does nothing. How can I tell SD *not* to open the COM port?

DarquePervert · 04-12-2007, 06:50 AM

Did you set the COM POrt for GPS in SD to DISABLED?
Another solution is to use a COM port splitter like XPOrt or GPSGate.

rburhum · 04-12-2007, 09:29 AM

Quote: Originally Posted by DarquePervert

Did you set the COM POrt for GPS in SD to DISABLED?

That's what I am trying to do. Keep in mind I already have Mappoint already uninstalled. I can't access the GPS settings in SD; clicking on "Navigation Settings" does nothing *once MapPoint is already uninstalled*.

Another thing I tried was to have another application be using that COM port before SD started so that SD would try to open the COM port and fail (since it was being used). I did get an SD error message dialog that said something along the lines of "check your GPS connection settings" (as expected) with 2 options: "Settings" and "OK". Clicking on either one does nothing and sends you back to SD. There *has* to be a registry setting or configuration file that SD reads at startup to figure which COM has been configured for the GPS device; since UI won't allow me to change that once MapPoint has been uninstalled, I should be able to modify that registry setting/file directly. it is not configuration.xml... do you happen to know which one it is?

Another thing I can try is reinstalling MapPoint, change the configuration to DISABLED using the SD UI (hopefully the UI will work once it detects MapPoint is there); this seems "silly" to me though (for lack of a better word).

Quote: Originally Posted by DarquePervert

Another solution is to use a COM port splitter like XPOrt or GPSGate.

Although it seems to me that these two software solutions should work (haven't tried it yet, but makes total sense), why whould I have to add virtual COM ports to circumvent the real problem; SD trying to open my COM port when MapPoint is not installed? I just need to know where that setting is stored.

By the way, thanks for the help DarquePervert.

god_of_cpu · 04-12-2007, 11:20 AM

Run with teh command line parameter -resetconfig and it will reset all the settings to the defaults.

rburhum · 04-13-2007, 12:41 AM

Quote: Originally Posted by god_of_cpu

Run with teh command line parameter -resetconfig and it will reset all the settings to the defaults.

That didn't do it.

I had already tried that before with the "Start->Programs->StreetDeck->Tools->Reset Configuration Data" which as you know pretty much does the same thing you suggested.

So I went ahead and reinstalled mappoint so that the settings were going to be reenabled; they were. I could then set it to disabled and the COM port was released *for that SD session*. I then closed SD again, and the next time I reopened it, SD tried to outsmart me and re-detected the GPS port and set it to COM 1 once again starting the problem all over.

It then ocurred to me that if I went ahead and changed the COM port settings, closed SD, uninstalled mappoint, that SD wouldn't try to autodetect the GPS again.

Nope, I was wrong.

To SD, it doesn't matter whether Mappoint is installed or not, it always goes through the autodetection sequence for the GPS. That seems like a bug to me.

I guess my only solution will be to go with the virtual COM ports... maybe I'll try that tomorrow ... *sigh*

RedGTiVR6 · 06-20-2007, 11:37 PM

please retest on 1.0.9.8 and report back with your findings.

RedGTiVR6 · 06-25-2007, 08:19 AM

please retest on 1.0.9.8 and report back with your findings.

RedGTiVR6 · 06-28-2007, 09:37 AM

Thread closed due to a lack of follow-up from the original poster. 8 days have passed without a response.

If the original poster would like to have this thread back opened, he/she may do so by going to the 'Thread Tools' drop down box at the top of the thread. If the Original Poster does so, the Original Poster must post information in response to requests for additional testing. Else, the bug report will be closed again.