<_xml version="1.0" encoding="UTF-8"_> Software Defined GPS Receiver http://attackofthesam.com/SDGPSR A Bradley University Software Defined GPS Senior Project. Tue, 23 Jun 2009 07:43:34 +0000 en hourly 1 Fixed Subchip error http://attackofthesam.com/SDGPSR/_p=208 http://attackofthesam.com/SDGPSR/_p=208#comments Thu, 30 Apr 2009 06:49:33 +0000 admin http://attackofthesam.com/SDGPSR/_p=208 New result

]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=208
Sources of Position Error http://attackofthesam.com/SDGPSR/_p=161 http://attackofthesam.com/SDGPSR/_p=161#comments Sun, 26 Apr 2009 23:56:38 +0000 admin http://attackofthesam.com/SDGPSR/_p=161 Incorrect pseudoranges can be a source of caluclation errors.

A type 2 PLL should be used.

Integrations/correlations inside the PLL should be done over 10-20ms.
This integration time will be dependent upon the maximum amount of gforce your application will experience.
For a stationary receiver integrations needed to be done faster than 1 second.
For an object traveling at 1 g force integration time needs to done faster than 19 ms.
This is to track within 1Hz of the carrier frequency.

A least mean squares curve fitting should be done on the calculated locations of data.

Here is a plot of the current jumps in C/A Code length for integrations over 1ms, along with carrier frequency.

carrier-frequency-vs-ca-code-length

C/A code length is adjusted based off a remainder from the last code length.
Thus the correct C/A code length should be within half of a sample.
If the rounding is not included in the calculation an error will result.

\frac{1}{SamplingFrequency} * \frac{1}{2}* 3*10^8

If the sampling frequency used for calculations is not the same as the sampling device errors will be introduced in the receiver.

Pseudorange = (Datapoint - DataPointMin) * SamplingFreq +.068
All of the pseudoranges will be scalled incorrectly depending on how far off the sampling frequency is.
See Adjusting the sampling frequency.

]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=161
Adjusting the sampling frequency http://attackofthesam.com/SDGPSR/_p=167 http://attackofthesam.com/SDGPSR/_p=167#comments Wed, 22 Apr 2009 21:20:41 +0000 admin http://attackofthesam.com/SDGPSR/_p=167 Because the pseudoranges are calculated from the sampling frequency of the device, any error in this number could result in the numbers being scaled incorrectly.

At a sampling rate of 16Mhz every Hz away from this is about .16 meters of error for a satellite.  When sampling at lower frequencies the effect is more dramatic.

I made a short program that would continuously grab samples from the gn3s sampler and then calculate the sampling frequency by taking (total samples collected) / (seconds of run time).

The published sampling frequency for the device was 16.367667 MHz.
My calculated sampling frequency was 16.367407 MHz.

A difference of 260 Hz, or 42.9 Meters of average error per satellite.

.009 * 3e8 - \frac{16367407 * .009}{16367667}*3e8 =-42.9

Calculated Sampling Frequency

PC clock inaccuracies may cause a small amount of error.   Approximately 40 minutes of data was used to make a decision.  After other error sources have been removed a set of data position distances could be saved and different sampling frequencies could be tested to find one that cause the lowest SSE from the  users position.

Before

Before Frequency AdjustementAfter

After frequency adjustment

]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=167
Altitude fluctuaions http://attackofthesam.com/SDGPSR/_p=149 http://attackofthesam.com/SDGPSR/_p=149#comments Sun, 05 Apr 2009 06:11:52 +0000 admin http://attackofthesam.com/SDGPSR/_p=149 I collected a couple of data points to monitor how the altitude changes according to the pseudorange calculations.

If I take the average of the altitude I get 300 meters which is correct.

The pseudoranges do not appear to have a high degree of noise in them, so I am thinking about averaging the last 10 positions together to obtain the current one.

Pseudoranges vs Position

The overlay of this looks like follows.

Stationary location

Different location

]]> http://attackofthesam.com/SDGPSR/_feed=rss2_p=149 First working prototype. http://attackofthesam.com/SDGPSR/_p=145 http://attackofthesam.com/SDGPSR/_p=145#comments Fri, 03 Apr 2009 05:21:59 +0000 admin http://attackofthesam.com/SDGPSR/_p=145 I have completed the first prototype.

It is using gpstk for handling the subframes, and position calculation.

Now moving on to collecting more data sets.

Looks like the initial error is within 10-60 meters.

Ill try to clean up the prototype and post the binary.

Realtime Software GPS receiver on windows.

]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=145
Locating Preamble and Decoding data http://attackofthesam.com/SDGPSR/_p=142 http://attackofthesam.com/SDGPSR/_p=142#comments Fri, 03 Apr 2009 02:34:16 +0000 admin http://attackofthesam.com/SDGPSR/_p=142 Today I figured out why half of my data is being decoded correctly and the other half is not.

Turns out that the D30 bit of the previous word causes bits 1-24 of the next word to be inverted.

These bits need to be reinverted before they can be used.

Steps to locate and confirm the preamble are as follows.

  1. Locate preamble 1000101100.
  2. Locate the preamble again 10 words away.
  3. Check the 2nd word(HOW) and verify that it has a valid subframe ID, and how time.
  4. Check the next (HOW) word and verify that it has a valid subframe ID, HOW time, and that they increment or roll over accordingly.
  5. Perform parity checks.
  6. Check the d29 and d30 of the HOW word and ensure they are equal to zero.
]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=142
Selection of Epoch time. http://attackofthesam.com/SDGPSR/_p=134 http://attackofthesam.com/SDGPSR/_p=134#comments Sun, 22 Mar 2009 04:20:04 +0000 admin http://attackofthesam.com/SDGPSR/_p=134

Update

time

Alignment feature

Error between indexes

Minimum buffer size needed.

Units inside one subframe

1

ms

CA code repeated

18

54

6000

20

ms

Bit transmitted

1

3

300

600

ms

Word transmitted (30) Bits

1

3

10

6

S

Subframe (10 Words)

1

3

1

30

S

Frame (5 subframes)

1

3

12.5

Min

One navigation message

1

3

Began work on implementing the inital Pseudorange calculation.

Current implementation of the data is a buffered loop storage array.

Nice epocs could be calculated easiest if done on one of the following intervals.

If a buffer size of 30 is used and updated every 20ms then the index will be set to 0 at the beginning of every word.

Receiving delays can range from 65-83 ms a difference of 18 ms.

The error between indexes relates to the fact that bits are transmitted up to 18ms slower than other bits.

In example if a array size of 3 was used and there was a difference between indexes of the satellites the oldest of the two indexes should be used.

Example:

satellite A current index 0
satellite B current index 2

Chose to use index at 2, as satellite b has not yet rolled over to 0.

satellite A current index 1
satellite B current index 2

Use index 1 as Satellite A has not yet increased to 2.

Also stored should be # words from last subframe transmitted.

This becomes more complicated for 1ms epochs because of the larger error between indexes.

Also all of the indexes should line up to 0 at the start of every subframe.
This is because the current time is transmitted.
An array size of 10 will be used.  This will allow for direct calculation of the time. By taking the last TOW + Index*.6ms

]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=134
Decoding data. http://attackofthesam.com/SDGPSR/_p=130 http://attackofthesam.com/SDGPSR/_p=130#comments Sat, 21 Mar 2009 19:44:31 +0000 admin http://attackofthesam.com/SDGPSR/_p=130 I implemented data decoding routines.

I also started using the gpstk libraries.

After 5 subframes I was able to generate the following ephemeris information using the gpstk libraries.

****************************************************************************
Broadcast Ephemeris (Engineering Units)
PRN : 20
              Week(10bt)     SOW     DOW   UTD     SOD   MM/DD/YYYY   HH:MM:SS
Clock Epoch:   499( 499)  439200   Fri-5   216    7200   08/04/1989   02:00:00
Eph Epoch:     499( 499)  439200   Fri-5   216    7200   08/04/1989   02:00:00
Transmit Week: 499
Fit interval flag :  0
          SUBFRAME OVERHEAD
               SOW    DOW:HH:MM:SS     IOD    ALERT   A-S
SF1 HOW:    438996  Fri-5:01:56:36   0x044      0      on
SF2 HOW:    439002  Fri-5:01:56:42    0x44      0      on
SF3 HOW:    439008  Fri-5:01:56:48    0x44      0      on
           CLOCK
Bias T0:      8.76886770E-005 sec
Drift:        9.09494702E-013 sec/sec
Drift rate:  -2.77555756E-017 sec/(sec**2)
Group delay: -6.51925802E-009 sec
           ORBIT PARAMETERS
Semi-major axis:        3.03834575E+003 m**.5
Motion correction:      4.86377402E-009 rad/sec
Eccentricity:           4.95970747E-001
Arg of perigee:         1.34752371E+000 rad
Mean anomaly at epoch:  1.32153453E+000 rad
Right ascension:        1.87509305E+000 rad     8.24248619E-009 rad/sec
Inclination:           -9.42658741E-001 rad    -1.47148986E-010 rad/sec
           HARMONIC CORRECTIONS
Radial        Sine:  3.16250000E+001 m    Cosine:  2.24062500E+002 m
Inclination   Sine:  2.42143869E-008 rad  Cosine: -6.33299351E-008 rad
In-track      Sine: -7.47293234E-006 rad  Cosine: -1.65589154E-006 rad
           SV STATUS
Health bits:   0x00      URA index:    0
Code on L2:    P only      L2 P Nav data:          off
]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=130
Determining lost signal http://attackofthesam.com/SDGPSR/_p=114 http://attackofthesam.com/SDGPSR/_p=114#comments Wed, 18 Mar 2009 23:20:16 +0000 admin http://attackofthesam.com/SDGPSR/_p=114 Currently developing an algorithm to recognize that a signal was lost.

Current algorithm is as follows.

S = \sum_{x=1}^N |QP_x|

S denotes the signal strength

QP_N denotes the current value.

QP_1 denotes the value N-1 samples ago.

Using a value of N=20 the following graph was generated

Signal Strength

The top graph is the calculated signal strength while the bottom graph is the raw data stream.

A zoomed in photo is below.

Signal Strength zoomThe tracking loop (bottom graph)  started to loose the lock between 29 and 30 seconds.  The signal strength (top graph) started to oscillate because of this.

I then changed my N to 1000

Signal Sternght 1000 samples used.Signal strength using 1000 points, zoomed in.Again the tracking loop started losing the signal around 60 seconds.  At approximently 64 seconds I covered up the antenna.

This algorithm is implimented at an order of 1.

]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=114
Flashing the GN3S V1 in Windows http://attackofthesam.com/SDGPSR/_p=99 http://attackofthesam.com/SDGPSR/_p=99#comments Wed, 18 Mar 2009 05:46:00 +0000 admin http://attackofthesam.com/SDGPSR/_p=99 First step is to recompile fx2_programmer so it will work in windows.

Download the fx2_prorammer source code.

Download MinGW
Add its binary path to your system environments path

Download libusb-win32

Copy the usb.h to the fx2_programmer folder

Copy the libusb.a from the lib\gcc folder to the fx2_programmer folder

modify the make file to use libusb.a instead of -lusb

open fx2_programmer.c

change usb.h to use “” instead of <>

change sleep to Sleep

in the command prompt type make fx2_programmer

test out the fx2_programmer

fx2_programmer any any dump_busses

Dump of USB subsystem:
bus bus-0 device \\.\libusb0-0001–0×046d-0×08d9 vendor id=0×046d product id=0x
08d9
bus bus-0 device \\.\libusb0-0002–0×1781-0×0b38 vendor id=0×1781 product id=0x
0b38

Attached is the windows binary files, and slightly modified code.

I had to hard code in the set 0xE600 1 and 0 into the program loop.

Attached is the source code, and binary.

Hopefully someone finds it handy.

fx2_programmer

It should also be noted that a driver needs to be installed for a device before fx2_programmer can se it.

]]>
http://attackofthesam.com/SDGPSR/_feed=rss2_p=99