Yo Kristoff!
On Thu, 10 Dec 2020 00:39:16 +0100
Kristoff <kristoff@skypro.be> wrote:
On 9/12/2020 2:19 a.m., Gary E. Miller wrote:
I am new to the mailing-list, with just a quick question.
Can somebody provide a quick overview of what gpsd expects RTCM
messages should look like?
gpsd does not care. gpsd just forwaards to the GNSS receiver. The
receivers are very picky.
Apparently, gpsd will only forward it if the format it receives
matches what it think it should receive.
That is a good thing.
As part of an exercise to learn Software Defined Radio and GNU
Radio, I "build" a receiver in GNU Radio for the marine DGPS
radio-stations in the mediumwave band, including some python-code
to decode the RTCM messages. (not yep posted online .. first
code-clean-up :-) )
gpsd can also decode them. Check out drivers/driver_rtcm[23].c
did that. However, driver_rtcm is the higher-layer code. The lower
layer is done by isgps.c.
If you look at the the data structures as found on rtcm2, they do not
match how the bits are transmitted on the air.
The structures are based on words (32 bit) with the 2 "pad" bits
being the 2 last bits of the previous word (which have to be
repeated).
That is very common. All the GNSS receivers I know do that. For
RTCM and for Subframe data.
So, this means that something is reordering the datastream -as
transmitted on air- to this structure: either the DGPS receiver, or
isgps.c.
Makes sense.
I did look at isgps.c, but -to be honest- it looks more like a CTF
challenge in a cybersecurity conference.
Yes, very ugly. Much easier for you to add the 2-bits of padding.
So the question remains, what is the format that gpsd expect from a
tcp-feed?
Same thing.
My plan is to write a small TCP-server in python and let dgps
connect to it.
You will find little improvement in the accuracy of a recent
receiver unless the RTCM bas is very close (<0.5 km)
I live about 2 km from the dgps station, so that should not be so bad.
I live 1 km from a base station. I see no improvement with RTCM2 or
RTCM3. YMMV.
Now, the question is, what is the format for RTCM messages should
look like?
They should look exactly like RTCM messages. The trick is what your
receiver wants.
At this point, the trick is to know that gpsd want. If that does not
match, it it will even think of relaying the message.
gpsd wants what every receiver I have seen wants.
gpsd has several samples:
test/daemon/*rtcm*.log
I had already looked at it. It's clearly not the bitformat as
transmitted on air.
Same thing for sample.rtcm2
Just plus the 2 padding bits?
If you run gpsdecode on the rtcm2 file, it are all type-9 messages.
As the message type-number comes just after the sync-pattern, you
should see 01100110 before or after 100100 (or with bits inverted or
reversed). Try looking for that!
RTCM makes my brain hurt. Maybe after I get the subframe working I'll
look at RTCM. It does what I want, works for me, and others so I have
no rush.
s it is, ain't broke, nothing to fix.
Also, if you look at the output of gpsdecode for that file, you have
44 type-9 messages with length 4 (6 words in total), and 87 message
with length 5 (7 words in total).
so, in total that is 873 words, or -if if you take a word being 32
bits instead of just 30-, that is equivalent to 3492 bytes.
The sample.rtcm2 file -if you strip of the comments in the beginning-
is 4690 octets.
This means there is all kind of other stuff in that file too.
Same thing for rtcm2.log
It is what it is. Those are raw captures from real sources, and they
work when passed on the test receivers. You need to figure out
how to duplicate them.
I do not know if this so for all RTCM messages. or if this is
something specific for the marine DGPS service.
Dunno. All gpsd does it take RTCM in and pass it on.
Is there still somebody on the list who actually wrote or maintains
that code?
Much of the RTCM code has been driver by submissions. Like most of gpsd.
No patches in a while. People have been using it, and no reported bugs.
Just stuff the bits as I receive them from the radio to gpsd?
Well, you wrote the radio part. So write your radio so that is
the case. Like everyone else did.
The radio just creates bits one by one, and -if you look at the specs
that are out there- that just matches how it is received.
Matches the wire format, not the de-factor GNSS reciver format. I have
asked several vendors to document the difference, but never got any
answers.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin