RTCM over IP?
Robert Reimiller
as a new IP packet or inside a UDP packet?
Does anyone have any links that shows the general format of
a RTCM message? Don't need specifics right now, just a
general idea of how big the message is.
Bob
The return address is invalid. DO NOT email to this address.
David Wright
Wolfgang Rupprecht
David Wright <da...@n8it.org> writes:
> This might be of some help:
>
> http://www.wsrcc.com/wolfgang/gps/dgps-ip.html
>
> dave
>
> Robert Reimiller wrote:
> >
> > Is there a standard in place or proposed for sending RTCM
> > as a new IP packet or inside a UDP packet?
> >
> > Does anyone have any links that shows the general format of
> > a RTCM message? Don't need specifics right now, just a
> > general idea of how big the message is.
David, thanks for fielding this one. I didn't initially see the
original article. It was crossposted to a group I am in the habit of
hitting the catch-up key in. I guess I nuked it without ever
realizing.
There is an experimental RTCM-SC104 server running on machine
dgps.wsrcc.com that has been assigned tcp/udp ports 2101 by IANA.
Currently the server is very general purpose and will take an input
stream from anything tcp, udp (unicast), udp mcast, files, serial
lines and will send an output stream out to tcp, udp (unicast), udp
mcast, files, and serial lines.
The current "protocol" is very lightweight. ;-) It simply grabs bytes
from the input and sends them to the output. This "protocol" was
chosen to encourage other freeware authors and other folks working on
a budget to try out DGPS over IP. The code for running the gps is as
simple as:
while (read(network_fd,,) >= 0){
write(gps_fd,,);
}
I do believe that there is also a need for a differential stream that
is encoded with something more sane than rtcm-sc104. I'm very
interested in feedback and ideas.
I think there will always be a need for simpler to use rtcm-sc104
feeds. For consumer gps users a more traditional protocol on the wire
would push the responsibility of generating rtcm-sc104 into the client
software. That code is not going to be fun to write.
Check the page http://www.wsrcc.com/wolfgang/gps/dgps-ip.html for
pointers to the reference code, tips for authors etc.
-wolfgang
--
Wolfgang Rupprecht <wolfga...@dailyplanet.wsrcc.com>
http://www.wsrcc.com/wolfgang/
DGPS signals via the Internet http://www.wsrcc.com/wolfgang/gps/dgps-ip.html
Robert Reimiller
>This might be of some help:
>http://www.wsrcc.com/wolfgang/gps/dgps-ip.html
>
Robert Reimiller
>There is an experimental RTCM-SC104 server running on machine
>dgps.wsrcc.com that has been assigned tcp/udp ports 2101 by IANA.
>Currently the server is very general purpose and will take an input
>stream from anything tcp, udp (unicast), udp mcast, files, serial
>lines and will send an output stream out to tcp, udp (unicast), udp
>mcast, files, and serial lines.
>
is anyone planning on writing one?
We are interested in having a central receiver send out UDP packets
(multicast I guess, could also be broadcast if it didn't escape past
the local network I suppose). to a number of units. From your
documentation it appears that each packet has 32 bytes of data
once per second, is this right?
At each unit we would take the packet and send it out the serial
port to the RTCM input on the GPS receiver (we're looking at
the future Motorola M12 at this point).
Do you see any problems with this?
Bob
Wolfgang Rupprecht
nos...@lobo.net (Robert Reimiller) writes:
> This seems like something there should be a RFC for :) Is there one,
> is anyone planning on writing one?
I was holding off on the RFC until more experience was gained with the
protocol. So far the RFC would be really short.
> We are interested in having a central receiver send out UDP packets
> (multicast I guess, could also be broadcast if it didn't escape past
> the local network I suppose). to a number of units. From your
> documentation it appears that each packet has 32 bytes of data
> once per second, is this right?
The 32bytes of data is just an implementation detail. I needed to
pick a number that balanced delay against data efficiency. If someone
really wanted very low delay they could send 1 byte data packets.
> At each unit we would take the packet and send it out the serial
> port to the RTCM input on the GPS receiver (we're looking at
> the future Motorola M12 at this point).
Thats exactly how the reference dgpsip works. (The only difference is
that the currently released client runs over tcp not udp.)
> Do you see any problems with this?
No. None at all. The rtcm-sc104 stream is well armored against
corruption. Running a simple udp re-broadcaster works just fine,
especially over a local net where the normal udp packet
corruption/loss rate is very low.
Dave Martindale
>No. None at all. The rtcm-sc104 stream is well armored against
>corruption. Running a simple udp re-broadcaster works just fine,
>especially over a local net where the normal udp packet
>corruption/loss rate is very low.
I've read that at least some DGPS receivers are very stupid. They just
collect bits coming out of the demodulator at 50, 100, or 200 bps.
When they have collected a total of 6 bits, they pack those bits in a byte
with two extra upper bits (always the same) and transmit the byte to
the GPS. The GPS has all the responsibility for turning that back
into a simple bit stream, finding the real word boundaries in the
stream (which could be anywhere within the 6 bits in a byte), and
checking for parity errors.
So adding an IP connection between DGPS receiver and GPS shouldn't
make much difference, as long as the rate of packets dropped and
mangled is low compared to the rate that data is mangled coming
out of the DGPS receiver. In both cases, the GPS should catch
the error and ignore the bad data.
Dave
Wolfgang Rupprecht
da...@groucho.cs.ubc.ca (Dave Martindale) writes:
> I've read that at least some DGPS receivers are very stupid. They just
> collect bits coming out of the demodulator at 50, 100, or 200 bps.
> When they have collected a total of 6 bits, they pack those bits in a byte
> with two extra upper bits (always the same) and transmit the byte to
> the GPS. The GPS has all the responsibility for turning that back
> into a simple bit stream, finding the real word boundaries in the
> stream (which could be anywhere within the 6 bits in a byte), and
> checking for parity errors.
Exactly. There isn't even any other way to do it if the dgps-radio to
gps link speaks rtcm-sc104. The gps always gets stuck doing all the
hard work.
> So adding an IP connection between DGPS receiver and GPS shouldn't
> make much difference, as long as the rate of packets dropped and
> mangled is low compared to the rate that data is mangled coming
> out of the DGPS receiver. In both cases, the GPS should catch
> the error and ignore the bad data.
Yup, in addition the data repeats every second or two, so a missed or
mangled packet won't really be the end of the world.