Page 1 of 1

DGPS reference station

Posted: Fri Mar 25, 2005 9:14 am
by gambrose
I would like to make a DGPS reference station using a Lassen® iQ gps receiver so I can run DPGS but I can't find any info on the RTCM protocol and what info I need to produce to make the system work.

Dose anyone know anything that could help me or is this idea not practical.

Posted: Mon Mar 28, 2005 8:50 am
by gambrose
Does anyone know if and when the data sheet for this receiver (Lassen® iQ) is coming out?

Posted: Mon Mar 28, 2005 9:05 am
by sparky
Hey Graham,

Just got the datasheet up : http://www.sparkfun.com/datasheets/GPS/ ... Manual.pdf

I really don't know anything about making a DGPS station - sorry.

-Nathan

Posted: Mon Mar 28, 2005 10:02 am
by gambrose
Thanks!!!

I was hoping that they would have had an appendix explaining the RTCM-SC104 protocol like they do for the NMEA one.

Perhaps you could ask your contact at Trimble if they have any info on the RTCM-SC104 protocol as I do not want to pay for a copy from the Radio Technical Commission for Maritime Services and can't find anything on the internet.

Posted: Fri Apr 01, 2005 3:52 am
by coyotebush
Reading the Lassen IQ manual, RTCM protocol is supported as input only. This allows the IQ to receive RTCM corrections, but not generate them. At least according to my reading of the manual.

You can still create RTCM corrections if you figure out how to get into raw mode. According to the manual, packet 0x35 "I/O options" has a bit to enable raw mode, and you should receive pseudorange data in packet 0x5a. Alas, I haven't been able to make it work.

Has anybody had success with raw mode on the Lassen IQ?

I'm still struggling. If I succeed, I intend to double difference the data using a second receiver or a nearby CORS station. It should be reasonable to get submeter measurements that way.

- John Morris
Menlo Park, CA

Posted: Fri Apr 01, 2005 9:23 am
by coyotebush
Update: I am receiving raw mode data. It was a simple case of PBD - "Programmer Brain Dead". The protocol works as described. I haven't deciphered the 0x5a messages yet, but there appears to one sent for every satellite being tracked.

- John

Posted: Fri Apr 01, 2005 11:14 am
by gambrose
I was aware that the receiver didn't output RTCM corrections but I was hoping by studying the RTCM protocol I would be able to learn more about applying corrections, as I am new to this gps stuff.

I would be interested to hear how you get on with studying the raw data.
submeter measurements is what i'm after. :)

Posted: Mon Apr 04, 2005 4:38 pm
by coyotebush
I should have a "Lassen IQ to Rinex" program running soon. This would supply the basic data needed for producing DGPS corrections and for double differencing. (Rinex is a standardized text file for exchanging raw gps measurements.)

One way to get submeter positions is to use static differencing. You take two receivers and set them in fixed locations for 15 minutes or so. One is at a known spot, the other is at the place you're measuring. With postprocessing and a clear sky, you can get down to 20-30 cm this way.

I've heard of an inexpensive shareware package that will take a single Rinex file and difference it with the nearest CORS station. It will take you submeter if there is a station within 10-20 miles. Unfortunately, I don't remember the name. You might try asking sci.geo.satellite-nav.

Good luck, and keep me posted on your progress. I'll let you know when I'm producing Rinex.

Posted: Wed Apr 06, 2005 12:45 pm
by gambrose
I live in the UK so I think that counts as being more than 20 miles from a CORS station.

what I’m trying to do is have one receiver at a fixed location (exact location not know) and on receiver on a moving object (race car) then use post processing to get accurate trail of the moving object.
I will also use accelerometers as well as that should help things.

Posted: Thu Apr 07, 2005 11:49 am
by coyotebush
Ahh. The static positioning is definitely NOT going to work, unless you can persuade the drivers to take a short stop while you make your measurements.

Do you need realtime positioning? Are you doing this as the cars are racing, or are you doing after-the-race analysis?

Sounds like a very fun project. My own project is similar, but at a snail's pace in comparison. I want to walk around my property and figure out where I am. After a lot of back and forth wandering, I hope to produce an engineering quality topographic map. No accellerometers, though.

I'll bet the software I'm writing will work for you. In addition, I've seen a number of papers about integrating GPS with inertial navigation. Haven't read them though.

If your goal is realtime, then I assume you've worked out the radio link. I would start with transmitting pseudo-range data to a central location and do the processing there. To refine position even more, you can add carrier phase and inertial data to the model. But that's probably going overboard.

Are you tracking a single car, or the entire race? The more I think about it, the more fun it sounds.

- John

Posted: Fri Apr 08, 2005 3:11 am
by gambrose
I was going for post processing to start I was going to log the data to a flash card using a pic and have the base station connected to a laptop. I’ll use this mostly for testing.

Although some real time monitoring would be good as it would allow me to get lap times and spilt times with virtual timing beacons to give the drive qualifying time info.

For radio link I was thinking of one of the gsm phone links kits that sparkfun use. But not point getting that until I can get the gps working first.

Posted: Fri Apr 08, 2005 12:44 pm
by coyotebush
If you configure the Lassen chip to automatically produce smoothed pseudoranges, then all you need is a dump of the output stream. You can do all the processing at the laptop.

I'll bet single-differencing on the smoothed data will give you the precision you need. It should be better than DGPS corrections without getting overly complicated.

If you're programming a PIC, I'd avoid doing any GPS processing locally. Just get the raw bytes to the laptop and go from there. (sounds like that is what you're planning.) That way you only need 1-way communication. When you decide to go realtime, DGPS corrections would require 2-way.

GPS measurements come in every second, so you must be planning to interpolate to get lap times.

--------------

My own efforts have been delayed a bit. Apparently the Lassen chip puts out "CoarseAcquisition Phase", not pseudorange. The result is, I have to do extra work to figure out where the satellites are located. Then, I can convert C/A phase to psuedorange. Not a big problem, but a nuisance all the same.