Venus 6 speed tracking inaccuracy and solution

GPS/GNSS Development Boards
1

I have been testing the Venus 6 GPS chip (GPS-09133). I have found that it suffers some gross speed measurement inaccuracies during acceleration. There is new firmware available from Skytraq to correct this.

Look at the following graph:

http://www.maxqdata.com/MTKVsSkyTraqSpeed.gif

[http://www.maxqdata.com/MTKVsSkyTraqSpeed.gif]

This test was done in an automobile. The car was accelerated rapidly to about 70 MPH, followed by a rapid deceleration down to about 35 MPH, and then slow acceleration up to 45 MPH.

The blue curve in the graph was captured from an MTK-based module sampling at 5 Hz. The MTK module accurately tracks the car’s speed.

The red curve was captured from the GPS-09133 (with embedded SMA antenna). The sample rate was 10 Hz. You can see that the Venus 6 reacts very slowly to changes in speed, so slowly in fact that it misses the top speed of the test by 17 MPH (!). Also, the reported speed lags the actual speed of the car by over 1000 milliseconds. The same lag shows up in the Latitude, Longitude, and Heading values, too (from GPRMC/GPGGA).

Both modules were tested simultaneously. They were mounted to the roof of the test vehicle and had excellent satellite visibility (8 or more satellites in view throughout the test). There is nothing special about the test vehicle - it’s quick, but it’s still just an unmodified street car on street tires. A minivan could achieve the same deceleration rate. The deceleration rate is only about 1.0 g, which is well within the 4 g rating of the GPS.

Skytraq have since provided SparkFun with new firmware which resolves this problem. The new firmware is version 1.4.33 with a date code of 11/19/2009 (or later). Both the “2PSE” and “4PSE” firmware versions have been fixed. In my testing, the new firmware brings the performance of the Venus 6 at 10 Hz up to the same level or even better than the MTK at 5 Hz, although there may be a new issue with erratic measurement of zero speed, especially under conditions of poor satellite visibility (so please be sure to do your own testing).

You can update the firmware in the GPS-09133 through its UART port. It’s a 3.3V UART, so use a BOB-00718 or PGM-00714. You need to use the “GPS Viewer Software” found under the Documents section of the GPS-09133 product page in order to download the firmware. SparkFun tells me they will make the latest firmware available for download once they have had an opportunity to test it themselves.

My thanks to SparkFun for helping to resolve this issue, and to Skytraq for their excellent support and quick resolution of the problem.

2

Thank you for posting this. I have been pulling my hair a little with this module and now I know why. :smiley:

3

Where can I get the new firmware from until Sparkfun post it?

DC REdD

4

Since Skytraq are the owners of the firmware, I would contact them.

5

What is the difference between the “2PSE” and “4PSE” versions? How do I know which one to use on the “Venus GPS with SMA Connector” (sku: GPS-09133).

Curt

6

2PSE is for power conservation. 4PSE is for pulling in weak satellite signals at the expense of somewhat higher power consumption. You can use either firmware version on the GPS-09133.

I don’t know how much power is actually saved with 2PSE - I haven’t noticed a significant difference, but I haven’t done detailed testing of this. I do know that, in my testing, using the “Configure Power Mode” system message (ID 0xC) does not appear to have any effect on power consumption. It is possible that I didn’t test under conditions where the power savings would be noticeable. What does have a noticeable effect is changing the position update rate (higher sampling rate → higher power consumption).

7

There are 4 “search” moduls on the chip, each uses 10-15ma. When coldstarting or otherwise when there isn’t a lock, the 4PSE will use 70ma, the 2PSE about 50ma. When there is a lock, or when it otherwise doesn’t need to search more than 2 (agps, clear sky, etc.), there won’t be much difference.

Does this new firmware have logging, AGPS, and/or WAAS?

8

MaxQ,

I have the Venus 6 hooked up to my car (Honda CR-V) and I’m also reading the speed off of a tire pickup. You interested in a comparison of how the two match up? I could collect some data.

I’m doing an experiment to see if I can use the Venus 6 in lieu of a hard-wired tire pickup for an odometer. I want to use this for my car rally computer that I’d like to make portable between vehicles. I’d like to get close to 0.001 mile correlation with my wheel pickup over 5 miles. I’m getting close to getting it to work. The problem I’m having now is that the reported position lags behind the car during acceleration (not really too big a problem). But the position sling-shots in front of the car upon stopping and then backtracks back to where I stop. I’m trying to figure out a way subtract that effect from the accumulated odometer calculations. Still working…

Curt

9

There is a “profile” which I forget which setting but is like automotive, walking, etc. which is designed to reduce noise, but in this case might be causing it.

Normally you should not have any slingshot effects (the positions should be actual if you have enough satellites in view) - perhaps the velocity is doing that, but the actual position shouldn’t be (nor have I noticed that).

The position will lag slightly due to the latency inherent in sending data over a serial link (I think the ublox/antaris claims the $ in the GPRMC is correlated, but Venus - from what I remember simply says the lat/lon/time is correct but delayed, but the PPS output occurs at the precise second boundary).

I have close to the same setup on my Harley (both a N pulses per mile count and computed velocity), and I log both my J1850 stream and the gps to KML files so it should be obvious, but I should check my data again.

Also, an email to skytraq might be in order.

10

I’ll try the automobile vs. pedestrian mode to see what I get. I asked Skytraq what the difference was and this is their response:

“Cutoff speed thresholds: pedestrian mode 1Km/hr, vehicle mode 1.5Km/hr. And Kalman filter setting is a little different.”

At the beginning of a test run, I synchronize my car’s time to the Venus 6 by synching with the NMEA response. The is probably good to better than +/- 10ms. When I do a run, it looks like to me that the GPS position is delayed by 180ms +/- 10ms. Since the error between my car odo and the GPS odo calculation seems pretty independent of car speed, I believe that this delay is constant. But when I accelerate, the position is delayed by more than 180ms. This is not really a problem for my rally computer as I don’t need to stay on time when I’m speed up.

Curt

11

I’m also curious as to how the odo sensor works (besides being a tire pickup - one pulse per rotation, or from a gear/reluctance sensor or something similar in the transmission?). How is that data processed.

Also note that GPS has to compensate for doppler shift, and though the amount might be tiny, it would change when accelerating or decelerating so there might be something from that. The effect would be small (and not affect position much).

12

For the wheel pickup, I tapped into a signal coming out of the Electronic Control Unit (ECU) for the Honda CR-V. This existing (12 V square wave) goes from the ECU to the Cruise Control Processor. I think it is picked up at the transmission and after the differential (so a combination of both front tires – not a single tire as would be ideal). I don’t know the sensor technology they are using so missing pulses at high speeds is a concern. I think I get a pulse about every five feet. I’m running this into an HCS08 experimenter board. I’m counting rising edges to generate the car odometer (via an interrupt). I’m using a timer in the HCS08 processor to measure the time between rising edges. I use this to calculate the speed. I have a calibration factor to convert counts from these wheel ticks to miles and MPH. I have an LCD to display the data and also output RS232 data for capture on a laptop.

I have run the same route of about 10 miles multiple times using a verity of speeds along the path (all paved roads, the same day (temperature), one run fast, the next slow). I get the same odo reading between runs down to about 10 feet. I wanted to verify that I wasn’t missing pulses at high speeds.

My goal is to not have the rally computer attached to the vehicle other than for power. This way I can use any car. I’ll probably need something to process the GPS data. The processing is getting pretty hairy so I’m thinking of using something like a BeagleBoard. I plan to eventually use one or more iPhones or iTouches as the driver’s readout and navigator’s entry terminal.

Curt

13

Curt

Here is a chart that shows the rubber-band effect when stopping:

http://i231.photobucket.com/albums/ee15 … /chart.jpg

This represents a run from east to west of about 0.7 miles. I started from a stop, accelerated to 20 mph, then accelerated to 30 mph, then to 40 mph, and then stopped. The right y-axis scale shows the speed. The left y=axis scale is the error between the GPS odometer and the car. In this analysis, I only used the longitude in the odo calculation to simplify it a bit. The “Error from start” data is the distance from the GPS position at the start minus the GPS position as reported from the Venus 6 minus the car odo through the run. I scaled this data so that the error was zero at the end of the run (applied an odo calibration factor). The “Error accumulated” data is where I accumulated the difference from one GPS position update to the next.

Note that the GPS – CAR error goes negative by about 0.001 miles at the start. It then levels out as I reach constant speed (I had to put in a 180ms time bias to get this). As I stop, the GPS position continues to advance westward, and then retreats to the position where I stop. If I accumulate the changes in position (without regard to direction) I end up with the error shown in “Error accumulated”.

Things I need to resolve:

  1. Accommodate the overshoot when I stop (rubber-band effect).

  2. Accommodate the case where the car goes around a hair-pin curve and I don’t want to treat this as the rubber-band effect.

  3. Fix the error I get using my accumulated method when going directly north/south or east west. This is because when the lat or long is changing only occasionally its contribution to the odo is exaggerated.

  4. Factor in the change in altitude.

I think I can eventually figure all these out.

Curt

14

Hello everyone,

see, on november 2009 I sent skytraq a test made with a MOTEC data acquisition ADL2. Comparing Wheel speed and GPS speed, I have the same bad results as yours.

Skytraq never recognize that. I have 500 pieces of VENUS 6 ROM version, so they can´t help me now.

I want to be clear: they robbed me. They are liers. They never answered my e-mails.

So, that´s my f experience to skytraq. BE CAREFUL.

Gustavo.

15

Ugh, sorry to hear that. :frowning: from speaking with them I have noticed they like to dance around that issue… even when discussing flash modules. Otherwise their support as been stellar.

What will you do with them now?

16

they are waiting for a non-accurate-speed application.

By the way, has any tryed to calculate speed over the ground fron LAT / LONG?

17

At the simplest level you could obtain it via timestamping one point’s lat/lon then the next and calculating it… but I don’t know how much it will help.

Right off the bat you would be faced with speed reading latency since the calculation is not the user’s current speed, but their average speed between the two recorded points.

The speed in gps receivers can be very accurate because the doppler shift can be taken into account too. You will not have that information for calculations. Furthermore, the lat/lon points points the device are passing you have probably been manipulated to take speed into account (likely why there is a car/pedestrian mode among other settings).

I’m pretty sure you can turn off a few speed-considering calculation related settings in the device so it does not do this, but then you will probably be faced with the issue of gps accuracy. i.e. without taking speed into consideration it is harder for the module to tell you if that recorded measurement that says you moved 10m in under a second is right, or should be thrown out.

At any rate it’s a pretty crappy situation you are in. :frowning: At least they should still be useful for positions where you need to know a static position within 3-5m with WAAS enabled.