|
| From: | sauclair |
| Subject: | [gpsd-dev] Urgent: Need a fix for this weird GPSD behaviour... |
| Date: | Tue, 21 Jul 2015 14:55:42 -0400 |
Didn’t get any response to my last email… IMPORTANT: We need to find some fix for this problem as our software to be used for a business presentation that should occur tomorrow! … If we cannot solve this issue we will not be able to demonstrate our RF product prototype and we will lose a major business opportunity. Here’s an update on our situation. We conducted a field test and my fears are now confirmed… The coordinates are very precise… We just don’t get the current ones ! We took a car and went from point A to point B. The two points being separated by approx. 20 Km. As we drove along, we compared the values of our C++ code which uses libgpsmm.h with the values displayed using both CGPS and XGPS on Raspbian Raspberry Pi B+. (All three applications were running at the same time on the same unit using the same GPS receiver.) Both CGPS and XGPS reported the correct locations. In the case of our application, each value produced by gpsmm::read() was the one the other two applications reported 1 to 2 minutes prior. At the end of the exercise, all the coordinates are being correctly produced but we needed them in real time... With a 1 to 3 minutes offset the whole thing becomes useless for our application and makes us look very bad ! It’s as if “read()” takes the values out of a FIFO that our code would not “unstack” fast enough. Again, I need to remind you that I installed GPSD following this tutorial and that following the step of editing the file “/lib/udev/gpsd.hotplug”, the dates that the GPS outputs through CGPS, XGPS and our own application is no longer 2015…. But 1995… !!! Don’t know if this could be connected to our issue. We had to make this editing of the file “/lib/udev/gpsd.hotplug” because without this, gpsd was starting as a service but it was failing at connecting to the socket... We were forced to killall the gpsd process and restart it manually. Only then were the XGPS and CGPS applications able to work properly and the dates were the current 2015 ones. Now gpsd starts as a service at boot time but the date is 1995. See previous email below for a clear description of our code. (Note that we do not use the wait function provided by libgpsmm.h… we rather use a QTimer instance which is part of the QT UI lib we need to use for our application.) Thanks for any help ! Sébastien Auclair Retia Technologies (581) 305-2574 From: address@hidden [mailto:address@hidden Thanks for replying ! I am looking at the “fix” member. After my initial post to the mailing list yesterday I discovered gps_rec.clear_fix(); I decided to give it a try but it doesn’t really make a different. (As if my receiver was absolutely precise and consistent all the time… which I doubt !) I still need to do some tests outside but I didn’t have the time. Here is the code I use. (Qt based)… The following function gets called every 5 seconds. ================================================ void MainWindow::pollGps(){ QString latlong ; struct gps_data_t* newdata = NULL; if ((newdata = gps_rec.read()) == NULL) { qDebug() << "GPSD Read error.\n"; } else { if (newdata->set & LATLON_SET){ latlong = QString("%1,%2").arg(QString::number(newdata->fix.latitude, 'f',6)).arg( QString::number(newdata->fix.longitude, 'f',6)); if (latlong.length() > 0 && !latlong.contains("nan")){ qDebug() << latlong; latlong.clear() ; gps_rec.clear_fix(); //This doesn’t really help getting more realistic coordinates ! (July 15, 2015… That line was added yesterday to try to get normal variation between each GPS readings. } else{ qDebug() << "latlong == 0 or contains 'NAN,NAN'"; } } else{ qDebug() << "FAILED at LATLON_SET test"; } } } The code above will systematically output: FAILED at LATLON_SET test FAILED at LATLON_SET test FAILED at LATLON_SET test FAILED at LATLON_SET test -71.23345,56.3333 -71.23345,56.3333 -71.23345,56.3333 latlong == 0 or contains 'NAN,NAN' -71.23345,56.3333 -71.23345,56.3333 -71.23345,56.3333 latlong == 0 or contains 'NAN,NAN' -71.23345,56.3333 -71.23345,56.3333 -71.23345,56.3333 latlong == 0 or contains 'NAN,NAN' -71.23345,56.3333 -71.23345,56.3333 -71.23345,56.3333 latlong == 0 or contains 'NAN,NAN' So as you can see, in addition to always getting the exact same coordinates all the time, I also get “Not A Number” systematically every 4 read !... That too bugs me. And I always get between 3 to 5 “FAILED at LATLON_SET test” when this code starts to run… which happens at the very beginning of my program. Thanks for any help ! Sébastien Auclair Retia Technologies (581) 305-2574 From: Sanjeev Gupta [mailto:address@hidden] On Wed, Jul 15, 2015 at 3:03 AM, <address@hidden> wrote:
In the: PROCESS(newdata); part of the sample loop, what structure elements are you looking at? -- |
| [Prev in Thread] | Current Thread | [Next in Thread] |