gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] RTCM relaying problem


From: José Miguel Gonçalves
Subject: Re: [gpsd-dev] RTCM relaying problem
Date: Thu, 12 Apr 2012 15:56:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 12-04-2012 15:36, Eric S. Raymond wrote:
José Miguel Gonçalves<address@hidden>:
Working with a RTCM caster I've noticed that not all RTCM packets
that gpsd received were relayed to my GPS receiver, what caused DGPS
corrections to be intermittently applied or not applied at all. To
fix this I needed to apply the following patch to avoid RTCM packet
overlapping:


diff --git a/gpsd.c b/gpsd.c
index d8f229b..abdaca1 100644
--- a/gpsd.c
+++ b/gpsd.c
@@ -1422,7 +1422,7 @@ static void consume_packets(struct
gps_device_t *device)
      }
  #endif /* NETFEED_ENABLE */

-    for (fragments = 0; ; fragments++) {
+    for (fragments = 0; (changed&  (RTCM2_SET | RTCM3_SET)) == 0;
fragments++) {
         changed = gpsd_poll(device);

         if (changed == ERROR_SET) {
This code is not correct.  The variable 'changed' is auto and not initialized,
which means random garbage on the stack could cause the loop to fail before
it is ever set.

But simply patching in an initialization wouldn't be the right thing here.
We need to figure out what is actually going on, because if you look at line
1519 and following you'll see exactly where the RTCM2/RTCM3 case is handled
*inside the loop this test is terminating*.  Your patch should, accordingly
have made things worse.  We need to understand why it didn't and incorporate
that understanding in the eventual fix.

You are right about the initialization... my bad.

What I have observed is that the Ntrip caster sends a batch of packets in a row and some of these are overwritten in the gpsd buffering if I don't break the consume loop. In line 1519 you only store the RTCM packet, you don't relay it to the GPS receiver. The relay is done in line 2316, which is not reached for every RTCM packet received if we don't break the loop.
If you need I can send you additional logs of this problem.

Regards,
José Gonçalves




reply via email to

[Prev in Thread] Current Thread [Next in Thread]