Today I'd like to show what Ben, Luis, and me have been doing in our spare time and sometimes sacrifying our precious weekend hours.
Internal codename RETROFIX, it's a service running on one of our servers and processing small snapshots of data collected with PRIMO. At the moment uses about 200ms of signal and it's therefore limited in sensitivity. But surely it proofs the concept that with a coarse time tag and 128kBytes of digitized RF signal you can calculate the position and the time of a user.
FIG 1: http://www.retrofix.infoIf you have a PRIMO dongle just contact me and I'll send you the website address, the configuration files, and the application to grab a compatible signal: I'd love to have some feedback.
Come back soon for updates,
Mic
12 comments:
How to you know the 128k is 200ms data set?
I would like to know what is the smallest data set (how many ms data) you can get position through post process
Deep-R system using 2ms data can get position
Hi "MyGeoTracker",
I know because I designed the GPS data logger hardware, I physically assembled it, I wrote all its software, and finally I contributed to the retrofix service development as well. In prectice I configured the dongle to sample at about 5Mbps, so 200ms is about 128kByte.
Well, talking about GPS you need at least 1ms of data to be able to position. The 1ms is the PRN spreading code length used in the GPS SPS. In order to account for a possible (but unlikely) navigation data bit transition, 2ms is safer. So using 2 ms you can actually make sure you have those 30dB of integration gain necessary to bring the nominal signal power in open sky above the noise floor with a decent probability. Of course, the longer the snapshot of RF data the higher the sensitivity.
No wonder that Deep-R technology works with as low as 2ms but you can't get a fix with that, not even in light indoor environment as my office is. As an example, a SiRF Star III has an acquisition sensitivity of -142dBm, which (if my calculations are correct) needs about 30ms of data minimum.
Bests,
Michele
Thank! Michele.
My next question is why 200ms? Why not 310ms? (310ms is the gps-sdr weak signal acq case)
Hi,
200ms is just a number, as well as 310. I don't generally use gps-sdr as a reference.
Cheers,
Michele
Hi,
We are a small group of students from India who are working on building tracking devices for sea turtles.We plan to purchase a gps signal capturing device (snapshot of about 500ms of data) and develop the post processing software by ourselves.(similar to retrofix)
Firstly we like to know if it is possible for us to purchase your front end module ,PRIMO ?. If yes what is the procedure in doing so.(We have checked your website but dint find any link to signal capture devices).
Secondly we have a few doubts about the software end.Since we are talking about processing 200ms of data there is a very low probability that we receive the timestamps form the satellites .So we assume that transitions in the navigational data will be used to get the relative psedoranges between the satellites (Please correct us if we are wrong in making this assumption ).If this is the case we would require a minimum of 20 ms of data to get the psedoranges as the navigation data bit length is 20ms(assuming a transition occurs).But we read on one of your blog comments that its possible to do it with 5ms data also .Please clear our doubts regarding this.
Hello,
If you want to do it all by yourselves OK, but there is Robin from Cellguide that does precisely what you need and is unbeatable in terms of weight, size, power consumption, and price in volumes. Check it out here:
http://www.cell-guide.com/GPS-Logger-Solutions/robin.html
Otherwise of course there is SdrNav00 which is a cheaper version of Primo.. as well as a plethora of similar devices from other people.
In 200ms there are very little chances to solve for the nav. bit synchronisation, let go receive the TOW (time of transmission) which is impossible by ICD design.
You don't need the nav bit transition to determine the synchronisation between satellites. You simply use the C/A code. This will give you a 1-ms ambiguity (300km) which you should solve for by using approximate time and some Doppler positioning.
You can position with as little as 2ms of data (in order to have at least a full C/A code in each snapshot) but the sensitivity you can achieve will be very poor.
Good luck!
Cheers,
Michele
Michele,
How do you estimate the sensitivity vs ms data? I know at least 2ms data and 500ms for poor view. In order to get 10m accuracy how many ms data do I need?
Another question is sample frequency, a lower frequency has less raw data size. What is the lowest sample frequency? 2.046MHZ?
Thanks
Dan,
Processing gain depends on the bandwidth of your filter, which is proportional to the length of your coherent integration.
Assuming 44dBHz nominal C/N0, 2 ms will give you about 41dBHz (+3dB gain) sensitivity at best and 500ms (with a lot of complex math to remove navigation data bits) 17dBHz at best.
There is no obvious connection between accuracy and snapshot length.
2.046MHz is undesirable as it is commensurable with C/A code chip rate. I have seen people sampling GPS at an IF of about 1MHz with 2Msps (real only) and still get away with it. I would suggest to respect Nyquist at least.
Cheers,
Michele
Hello Michele,
First of all thanks for the reply.
We would like to build the module ourselves as we are doing it as a part of our course project.
The link you put looks very promising though.
Cheers
Shravan
Post a Comment