GPS causes RR to lock up
Hello all, long time lurker here with a question I hope you can answer.
Set up RR (the mose recent version) with Digital FX4 in a 68 mustang with a liliput slide out screen. Have a USB GPS connected which works lovely in autoroute.
if I set the GPS port that RR uses, RR will lock up in a few mins (can't use any buttons, have to kill it in task manager), however the GPS works fine for MS autoroute, but I want the GPS for the gauges which do work for the few mins. So I thought it was the way xport handled the stream, so I tried it without xport, set up the port in RRConfig and the same story, works for a few mins and then locks up, but fine in autoroute
Any thoughts on where I can start to look to fix this, I'm not afraid to dive into config files/code and I have done a few searches here.
XPort is working fine and used by most people. What makes you think that it's GPS that lockups RideRunner ? You did set the gps port in RR to a different port than AutoRoute, did you ?
Yep, xport seems to be working fine, no problems there, I shall provide a bit more detailed information:
Originally Posted by Konrad
I believe that the GPS locks up RR because during my investigation:
I eliminated xport by uninstalling and reboting (no xport)
Found what port the GPS was on and verified it worked in a little GPS app that came with it.
Went to RRConfig set the GPS COMM port to same (think it was about 3 or 4)
In RRConfig removed the GPS Path
Started RR (not clicking on the GPS app, autoroute) which worked for a few mins, but after a few button presses failed to respond to any input, same as when I had poth ports going with xport.
I shutdown RR, set the GPS port to 0 in RRconfig and started up again, RR didn't lock up again.
I had the same issues until I realized that I had xPort picking up the GPS signal and spitting it out to 2 separate virtual COM ports like I'm supposed to. Unfortunately I wasn't paying attention when I assigned the ports because I assigned both Road Runner and iGuidance to use the same port and it caused immediate lockups and blue screens.
When you tried just RR and GPS (without xport or autoroute), you said after a few clicks it froze -- did you look in task manager to see what the CPU load looked like ? also, did you try just pulling off the USB plug to see if RR would come back by any chance ? lastly, are you using a USB hub for the GPS, if so, can you try plugging it straight into the machine (without the hub) ?
Thanks very much for your replies, I shall do that and report back my findings. :)
A rather late reply, but here is what I found,
CPU hits about 27% for RideRunner when it becomes unresponsive, the GPS is plugged straight into the computer, no hub. Removing the GPS still leaves things as they were. Is there any more details that you would like?
I used to have the same problem with GMPC, XPort and RR. My GPS was on real port com3, RR on virtual com7 and GMPC on virtual com8.
What would happen is when coming out of hibernation, GMPC would start before XPort was initialized. Problem is GMPC will start searching all your com ports if it doesn't see a GPS on the configured port so it would connect to com3. With both XPort and GMPC connected to com3 at the same time the system would practically lock up.
I don't think the issue had to do with any application in particular, just that two of them were connected to the same com port at the same time.
Following on from some other threads I believe that the issue is with the version of flash that I'm running, seems like the up to date version isn't playing nice with RR and Digital FX, I'll get a chance to play with some different versions and hopefully have a resolution on the thread (I really don't like it when a question thread fades out without a resolution)
Look for "zips.dll" in the RR folder, if it is there DELETE IT! I would do a search of the entire RR folder, and sub folders as well.
This has caused problems like this many times, for many people.
Also, you can check for the "Locate=xxx" in the rr and skin.ini's. If you find this line, delete it as well and test again.
I would be willing to bet it is one of those 2 things.