Convert RTCM 3 to SBP

[Jack Viers]

Hey guys!

I want to convert SBP to RTCM 3 and RTCM3 to SBP to allow for using CORS. Beyond waiting for v1.0 firmware, I'm certain we can do this.

Problems: SBP is documented well enough that I can use it and read it and understand it. I am sure RTCM 3 is as well, however, I can't seem to find the specification online for free... Any tips on where I can get my hands on the document, or do I have to pony up the money to read the spec (not against this, just want to not spend money if I don't have to)?

Also, does libswiftnav-python or libswiftnav have anything for converting between sbp and rtcm3?

[Sam Thomas]

I'm keen for this!

Happy to help where I can.

Have a look at the source for BNC ntrip if you want a head start.

Sam

[Mathias Karlsson]

I'm trying to do the same with .net. I have found a pdf with the RTCM standard just need a way to hand it over if you want it.

[Jack Viers]

Email is fine?

[Jack Viers]

It's jackc...@gmail.com

[Sam Thomas]

Had any luck Jack?

[Clemens Arth]

Hey, was also keen to know more about this. Did you have any luck in implementing some conversion routine?

[Clemens Arth]

BUMP... any updates on this?

[Michael Oborne]

What do people want?

rtcm3 to sbp? to feed into a piksi?

from what source? (raw tcp/raw udp/ntrip/serial/file)

to what destination? (raw tcp/raw udp/ntrip/serial/file)

[Jesus Alvarez]

Hi Michael

I was looking at this too. But I do not have a Piksi yet.
I think what people want/need is a method to take RTCM from regional positioning services that are retrieved using GPRS on the field and inject that to piksi.
I was planing to use a Raspi with 3G USB Dongle to get those corrections and send them to piksi.

This way there is no need for a piksi base station.

The thing is that in order to be portable, that library should be able to run in linux (like Raspi) and other OSes.

I would say that the library could be separated into two parts. One that is just a converting tool back and forth RTCM<->SBP
And the other part that could be the In/Out sink. In that part the most interesting for the aplication I have described is NTRIP, but raw UDP and raw TCP should be great too.

[Michael Oborne]

Ok I have a working rtcm to sbp, and sbp to rtcm.

currently the piksi must be connected via usb, and the rtcm output/input is via a tcp socket listerning on port 989

Michael

On Sunday, 17 August 2014 11:59:27 UTC+8, Jack Viers wrote:

[Mathias Karlsson]

Do you have any code that you are willing to share?

[Michael Oborne]

once I can confirm its working and functional by someone other than myself I will yes.

[Michael Oborne]

current version can be downloaded from here
http://vps.oborne.me/piksi.7z

Usage: program.exe outputformat port baud
outputformat = rtcm,sbp
port = [comport of piksi]
baud = [baudrate of piksi]
rtcm: read sbp from comport and write to tcp port 989
sbp: read rtcm from tcp port 989 and write sbp to comport (either piksi or 3dr radio)

On Sunday, 17 August 2014 11:59:27 UTC+8, Jack Viers wrote:

[Michael Oborne]

one more thing, outputs rtcm 1002 messages, ie the same as what the piksi natively supports.

can read input as 1002 and 1004 messages, and dumps the l2 data from 1004 messages.

Michael

On Sunday, 17 August 2014 11:59:27 UTC+8, Jack Viers wrote:

[Michael Oborne]

this is my current problem.

if I send a sbp_base_pos, I get the piksi to crash.

this is for sending rtcm 1005 and 1006 message to the piksi in sbp.

[Mathias Karlsson]

I'm sorry but i can only help if can have a look at the code, in my current setup there i no way i can debug or anything. I'm implementing everything

in C# so i need to convert it to C# first.

[Michael Oborne]

do you plan on sharing your code?

[Michael Oborne]

this bug is related to this

https://groups.google.com/forum/#!topic/swiftnav-discuss/r3CvFt-pemc

[Michael Oborne]

piksi baseline working

using a ublox 4t converting to rtcm, feeding into my piksi.exe (rtcm in, sbp out), and sending via 3dr radio the the remote piksi.

[Mathias Karlsson]

Yes

[Michael Oborne]

my code can be found here

https://github.com/meee1/piksi

its been updated to support v0.12

its still a WIP.

it has modification for reading a modified ephemeris (adds the prn), which is not in the normal release, and also for reading some internal piksi structs.

Thanks

Michael

On Sunday, 17 August 2014 11:59:27 UTC+8, Jack Viers wrote:

[Mathias Karlsson]

My code is here, not as far as you michael, got stuck on lock time but it seems like the observation message has this information now.

https://github.com/mathias13

[Mathias Karlsson]

I see that you are also coding C# and that we are doing similar work, do you want to merge the code?

[Michael Oborne]

my code and your code seem to use different methods, ie you use classes, where as im using raw structs. so I don't think they would merge well.

[Clemens Arth]

Hi Michael,

thanks for sharing the code. I did some testing and it seems that the conversion from SBP delivered by the piksi to RTCM and vice versa works well - at least from what I can tell comparing terminal output with the Piksi console output.

To achieve my goal, I went ahead and connected to a 3rd-party provider to retrieve an RTCM-3 correction stream, which I again pushed into your RTCM3 module, to convert it to SBP and send it back to the piksi. From the terminal output and the Piksi Console output, the values are again transmitted correctly, however, the values itself are a bit strange. The PRN is fine, so seems to be the pseudorange, and also the SNR ratio which is converted through a step factor of 0.25 (so 52 becomes 13 etc.). The carrier phase however is huge for all observed satellites (in the the range of 1e11 something for ALL), and while always positive on the terminal side, it becomes exactly the same value but negative on the piksi side.

Since I have only one Piksi module, I can't do any further testing, but here's some decoded output from GNSSurfer and the output from the terminal of your program:

TM Rtcm3.1 1838.0 Tue Dec 30 15:30:22.341 2014
MT1004 Stat 4095 Status 1 Sec 1838 Seq 1000 Frame 1368
MT1004 ToW 225038.0000 SyncGnssMF 0 NGpsSvSiProc 10 GpsDivFrSmInd 1 GpsSmInt 7_Unlimited_smoothing_interval
MT1004 SV 9 CI-L1 0_C/A-Code PR-L1 266611.340m PhR-PR-L1-L1 12.58400m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 20086094.686m CNRL1 54.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 5.640m PhR-PR-L2-L1 17.11050m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 48.00db-Hz
MT1004 SV 10 CI-L1 0_C/A-Code PR-L1 56517.380m PhR-PR-L1-L1 11.58550m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 20385887.144m CNRL1 52.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 4.140m PhR-PR-L2-L1 13.65400m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 44.00db-Hz
MT1004 SV 7 CI-L1 0_C/A-Code PR-L1 291385.620m PhR-PR-L1-L1 23.50550m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 20685679.602m CNRL1 51.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 3.640m PhR-PR-L2-L1 27.12850m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 43.00db-Hz
MT1004 SV 23 CI-L1 0_C/A-Code PR-L1 127492.400m PhR-PR-L1-L1 14.22900m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 21585056.976m CNRL1 50.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 1.680m PhR-PR-L2-L1 19.24500m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 38.00db-Hz
MT1004 SV 6 CI-L1 0_C/A-Code PR-L1 157550.280m PhR-PR-L1-L1 9.05700m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 21585056.976m CNRL1 49.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 7.580m PhR-PR-L2-L1 8.79450m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 40.00db-Hz
MT1004 SV 2 CI-L1 0_C/A-Code PR-L1 142538.840m PhR-PR-L1-L1 9.04000m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 22184641.892m CNRL1 48.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 1.880m PhR-PR-L2-L1 8.59000m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 36.00db-Hz
MT1004 SV 20 CI-L1 0_C/A-Code PR-L1 691.400m PhR-PR-L1-L1 13.32600m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 22484434.350m CNRL1 45.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 4.620m PhR-PR-L2-L1 16.58750m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 32.00db-Hz
MT1004 SV 30 CI-L1 0_C/A-Code PR-L1 193170.800m PhR-PR-L1-L1 20.27750m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 22784226.808m CNRL1 45.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 8.080m PhR-PR-L2-L1 27.18050m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 32.00db-Hz
MT1004 SV 16 CI-L1 0_C/A-Code PR-L1 219026.380m PhR-PR-L1-L1 11.08700m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 23383811.724m CNRL1 41.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 4.360m PhR-PR-L2-L1 11.64450m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 23.00db-Hz
MT1004 SV 3 CI-L1 0_C/A-Code PR-L1 265423.660m PhR-PR-L1-L1 6.59650m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 23983396.640m CNRL1 39.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 9.340m PhR-PR-L2-L1 5.03600m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 21.00db-Hz

> 2014 12 30 14 36 12 0 10
G10  20369837,146   107044278,9923                         50,000
G 9  20395334,984   107178275,3103                         54,000
G 7  20862831,342   109635044,0438                         50,000
G23  21840361,116   114771947,2346                         50,000
G 6  21882695,196   114994385,6682                         48,000
G 2  22274352,052   117052558,6607                         46,000
G20  22684874,930   119209891,5661                         46,000
G30  22766091,350   119636729,7699                         43,000
G16  23570269,644   123862663,2425                         42,000
G 3  24465837,938   128568877,3238                         38,000

I guess there is some piksi-specific forward/backward conversion, that does not fit a standard RTCM-3 stream?

Clemens

[Michael Oborne]

the second row in my output is in l1 cycles. ie (number / 0.19)

the ambiguity still exists, and its the delta between samples that is used.

[Michael Oborne]

I don't have access to GNSSurfer either, but would be interested comparing the same samples between each.

On Wednesday, 31 December 2014 17:58:00 UTC+8, Michael Oborne wrote:

the second row in my output is in l1 cycles. ie (number / 0.19)

the ambiguity still exists, and its the delta between samples that is used.

On Tuesday, 30 December 2014 22:39:45 UTC+8, Clemens Arth wrote:

Hi Michael,

thanks for sharing the code. I did some testing and it seems that the conversion from SBP delivered by the piksi to RTCM and vice versa works well - at least from what I can tell comparing terminal output with the Piksi console output.

To achieve my goal, I went ahead and connected to a 3rd-party provider to retrieve an RTCM-3 correction stream, which I again pushed into your RTCM3 module, to convert it to SBP and send it back to the piksi. From the terminal output and the Piksi Console output, the values are again transmitted correctly, however, the values itself are a bit strange. The PRN is fine, so seems to be the pseudorange, and also the SNR ratio which is converted through a step factor of 0.25 (so 52 becomes 13 etc.). The carrier phase however is huge for all observed satellites (in the the range of 1e11 something for ALL), and while always positive on the terminal side, it becomes exactly the same value but negative on the piksi side.

Since I have only one Piksi module, I can't do any further testing, but here's some decoded output from GNSSurfer and the output from the terminal of your program:

TM Rtcm3.1 1838.0 Tue Dec 30 15:30:22.341 2014
MT1004 Stat 4095 Status 1 Sec 1838 Seq 1000 Frame 1368
MT1004 ToW 225038.0000 SyncGnssMF 0 NGpsSvSiProc 10 GpsDivFrSmInd 1 GpsSmInt 7_Unlimited_smoothing_interval
MT1004 SV 9 CI-L1 0_C/A-Code PR-L1 266611.340m PhR-PR-L1-L1 12.58400m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 20086094.686m CNRL1 54.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 5.640m PhR-PR-L2-L1 17.11050m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 48.00db-Hz
MT1004 SV 10 CI-L1 0_C/A-Code PR-L1 56517.380m PhR-PR-L1-L1 11.58550m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 20385887.144m CNRL1 52.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 4.140m PhR-PR-L2-L1 13.65400m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 44.00db-Hz
MT1004 SV 7 CI-L1 0_C/A-Code PR-L1 291385.620m PhR-PR-L1-L1 23.50550m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 20685679.602m CNRL1 51.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 3.640m PhR-PR-L2-L1 27.12850m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 43.00db-Hz
MT1004 SV 23 CI-L1 0_C/A-Code PR-L1 127492.400m PhR-PR-L1-L1 14.22900m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 21585056.976m CNRL1 50.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 1.680m PhR-PR-L2-L1 19.24500m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 38.00db-Hz
MT1004 SV 6 CI-L1 0_C/A-Code PR-L1 157550.280m PhR-PR-L1-L1 9.05700m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 21585056.976m CNRL1 49.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 7.580m PhR-PR-L2-L1 8.79450m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 40.00db-Hz
MT1004 SV 2 CI-L1 0_C/A-Code PR-L1 142538.840m PhR-PR-L1-L1 9.04000m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 22184641.892m CNRL1 48.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 1.880m PhR-PR-L2-L1 8.59000m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 36.00db-Hz
MT1004 SV 20 CI-L1 0_C/A-Code PR-L1 691.400m PhR-PR-L1-L1 13.32600m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 22484434.350m CNRL1 45.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 4.620m PhR-PR-L2-L1 16.58750m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 32.00db-Hz
MT1004 SV 30 CI-L1 0_C/A-Code PR-L1 193170.800m PhR-PR-L1-L1 20.27750m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 22784226.808m CNRL1 45.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 8.080m PhR-PR-L2-L1 27.18050m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 32.00db-Hz
MT1004 SV 16 CI-L1 0_C/A-Code PR-L1 219026.380m PhR-PR-L1-L1 11.08700m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 23383811.724m CNRL1 41.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 4.360m PhR-PR-L2-L1 11.64450m LTI-L2 24_24_<=_lock_time_<_72 CNRL2 23.00db-Hz
MT1004 SV 3 CI-L1 0_C/A-Code PR-L1 265423.660m PhR-PR-L1-L1 6.59650m LTI-L1 24_24_<=_lock_time_<_72 PRModAmbiL1 23983396.640m CNRL1 39.00db-Hz CI-L2 1_P(Y)-Code_direct PR-L2-L1 9.340m

...

[Clemens Arth]

The data I posted was not in sync because I had to switch between SBP and NMEA output on the UARTs to get it to work. The GNSSurfer can be downloaded here:

http://igs.bkg.bund.de/root_ftp/NTRIP/software/GnssSurferV108b2.zip

I guess the best way to compare it was to use their decoder and save it to a file as I did, and to concurrently connect and pass the same data to your module at the same time...

[Clemens Arth]

As suggested I recorded (a) the output of the GNSSurfer Decoder, (b) the text output of your piksi code (type1004 read function) and (c) the raw binary buffer of the same function from the same time span. I uploaded the data to my Dropbox, if you want to compare it:

https://dl.dropboxusercontent.com/u/17656518/rtcmstream.zip

[Michael Oborne]

ive just uploaded a new version that has ntrip support built in, and changed the way the comand line works, you must specify a source and destination now.

[Clemens Arth]

Thanks for the update.

I wonder - since I have no second piksi, what should happen once you pass the correction data to the receiver? Should it simply incorporate it into the new solution automatically? As far as I can see, it is still randomly jumping around - especially when it comes to the height, which is not well defined anyway. It does not incorporate L2 changes yet, as far as I can see...

What should happen to the baseline graph? Assuming that the reference station is static and also the receiver is, shouldn't the baseline graph simply become a single point in the noise-free case?

...

[Sam Thomas]

I'm really hoping for rtcm support on the piksi soon. Anybody know where it's at?

Failing that.. Michael do you think your code could be compiled for linux using mono?

May have to tweak some of the serial stuff I imagine.

Cheers!

Sam

[Clemens Arth]

Looking at the latest version of the firmware that is available through GIT, an RTCM decoder is still completely missing. It seems that also the output in RTCM is only rudimentary implemented, just up to them minimum message types required. May I ask which kind of application you have in mind?

I have no idea if it is possible to compile the sources with Mono, but as you already suspect, in the end it shouldn't be too difficult to change the required parts - for me a as a C# noob it was not so hard to find my way into it...
There are just some minor conceptual things about Michael's code, especially the definition of what should go in or out on which port, which might need some further tuning in the future to make it work reliably for all cases, especially when NTRIP is used. However, for me it worked almost out of the box.

My main concern right now is that I can't verify if the data passed into the piksi does really do something useful to the solution generated, as I only have one piksi. Probably I will acquire another one, just to enlarge my debugging possibilities - right now the data which goes into the piksi comes from a third party provider, and although the conversion to SBP seems to be correct, I can't really make any difference out of it when it comes to the solution... any suggestions how to further debug and test it are welcome.

[Michael Oborne]

the code should run on mono fine, you don't even have to compile, just run the exe included.

[Sam Thomas]

Nice one. Thanks Michael. Thanks for sharing all of your work.

Clemens I have a CORS where I work and was planning on using the Piski with a Raspberry Pi to pass the corrections. Would have been a piece of cake if the Piksi would accept RTCM. I will try Michael's code and see if I can get RTK fixed on the console and go from there.

Cheers!

Sam

[Clemens Arth]

Yes, Michael did an awesome job.

Michael, from what you wrote you pass the RTCM from an UBLOX to the piksi via RTCM->SBP to align a rover piksi to the ublox base station, right? Could you have a look at the timestamps that are transmitted?

Looking at the raw data I posted earlier it seems that the GNSSurfer and your conversion give different esults based on different time bases (separated by 15-16 secs, which is likely the leap seconds period). Probably the piksi does not do any reasonable correction because the NTRIP data must also be corrected by the same amount if retrieved over NTRIP? I suspect you tried to estimate the piksi baseline with an NTRIP stream as well - did that work for you?

[Michael Oborne]

I have a feeling gnssurer will be using utc, whereas my program will be using gps time, which for rinex, it needs to be gps time.

[Michael Oborne]

ive been doing some testing, using a rtcm source as the base, and I can get the solution to converge, but never get a fix, however the float values do get close.

[Michael Oborne]

here is a sample data set of 3 gps recording all at the same time

https://drive.google.com/folderview?id=0B7NMEqrTbGz9OXp5eVdrY1c1Zjg&usp=sharing

I can use TBC to create postprocessed baseline between the ubx and trim data, the piksi data though never gets that far.

[Clemens Arth]

Thanks for doing all these tests. This is really unfortunate... I don't understand why one piksi can be used with another one to get a fix, but can't be easily used with some other receiver?

Some time ago you wrote that you converted the data of a ublox4t to sbp and sent it to a remote piksi - I guess you also got stuck with a floating solution there?

[Clive Turvey]

Well having more joy with the Fixed RTK solutions here using non-Piksi generated SBP (two different receivers,completely different code linage).

Would have been more successful if not for the Piksi's insistence on searching for birds not in view, if I send you measurements for 11 satellites don't be looking for others that aren't in the sky.

Here the Piksi is feed from an attic mounted choke ring antenna, and should have a significantly better sky view than the residential canyon (N and S facing vertical walls, 2 story) location for the base station's antenna. I'll have to post process the data from the base as it was rather arbitrarily placed given the length of cable to hand, and a flush metal suffice.

Had other occasions where it's had 7-8 satellite fixed solutions, but a lot of floating ones. I need to work on a better placement for the bases.

[Andreas Ottendorfer]

Hi!

Your program works fine but I've got one question.

I tried your Converter to Calculate RTK position with RTKLib (not post processing).
I used the converted stream for the RTCM v3 Input as Rover/Base. This works fine but there is no solution calculated.
This error is shown in the log :"point pos error lack of invalid sats ns=0"
Is there may a bug in the converter or are there rtcm messages missing for calculationg?!?

Best regards

Andreas Ottendorfer

Am Montag, 27. Oktober 2014 00:45:49 UTC+1 schrieb Michael Oborne:

[Adam Coates]

Hi Michael,

Thanks for creating this program.

Sorry if this is obvious, but i cannot seem to get it working. I can open piksi.exe, but when i type in any commands it closes. I'm using windows 7 64bit.

Could you explain briefly how to setup for rtcm to sbp?

Thanks,

Adam 

[Michael Oborne]

Adam,

the app is a console app, you need to start it from the command prompt, and it will show you the usage params.

Michael

[Mathieu Peyréga]

Hello,

I can successfully use your software in several flavours :

- feeding piksi from real time network corrections
- feeding RTKLIB RTKNAVI engine with piksi measurements

I'm using firmware 0.15, I'm using the piksi with a roof mounted Trimble Zephyr 2 Antenna.

however, I'm wondering if there could be an issue with snr / CN0

The values reported in RTKLIB (for piksi measurements when fed though you tool) are really high... So high that it seems that they sometimes get eliminated...
I'm wondering if there could be a mismatch between snr and CN0 as explained here :

http://www.insidegnss.com/auto/novdec10-Solutions.pdf

regards

Mathieu

[dzo...@swift-nav.com]

Mathieu,

Unfortunately, the v0.15 firmware provides somewhat arbitrary values for the CN0 right now.  We have an issue against the firmware for this problem and hope to correct it soon!

Best,

Dennis

[Mathieu Peyréga]

Great... I mean... great to know that the reason

as for this RTCM / SBP, I saw in the piksi console that there is a mode for each UART (SBP or RTCM)

Is it for input or output setting of UART ? (In an ideal world, I would love 2 settings, one for each way)... meaning that piksi is natively able to emit its raw data in RTCM. Is that going to happen ?

Being able to test / operate a single piksi in an environnment where the real time RTCM network is really dense (it's the case in France : rgp.ign.fr to see a map of CORS stations) is really a nice opportunity and a unit able to digest / diffuse RTCM would really be a usefull feature.

Regards

[Clemens Arth]

Hi,

so you are able to get an rtk fix for your piksi using cors data from the french network using rtcm2sbp conversion from Michael? Did you change the raw ntrip stream somehow or did it work out of the box?

Clemens

[Mathieu Peyréga]

Hello, I was able to get fixed position but the computation where made by RTKNAVI, not by the piksi which was only providing raw data.

I've been modifying sbp to rtcm a little to (artificially) clamp snr values to a decent interval as I believe that rtknavi was doing some filtering on "stupid" values, and some values were obviously stupid (swiftnav team confirmed that this is an issue in v0.15)

regards,

Mathieu

[Stanislaw Nanek]

it appears that the conversion of RTCM> sbp works fine (C / N0 is stable), using a base-vrs, CORS network, received a fix solution using one pixie in piksi_console.

while in the other side, sbp> RTCM something wrong conversion work in RTKNAVI admittedly receives the results of fix - but this solution is false "jumps" about 100m,

 this is probably associated with non-continuous (not stable) conversion C / N0> S1, S1 jumps from 0 to max. values and breaks constantly,

 despite the fact that the C / N0 in Consoli is constantly max. value.

However, it seems that something in the code may be wrong.

[Clemens Arth]

You mean in Michael's code or in the 0.15 firmware?

[Stanislaw Nanek]

I mean in Michael's code  when convert sbp to rtcm

[Michael Oborne]

try converting to rinex. so you can check it that way

[Stanislaw Nanek]

a link to the post clarifying the conversion problem sbp> RTCM and results in RTKLIB (I posted in the wrong place)

https://groups.google.com/d/msg/swiftnav-discuss/YKK6LgIptnc/5DaPHaAQ_SMJ

[Stanislaw Nanek]

for now I have to test in the field, because this test was in very poor conditions, the antenna close to the wall of a tall building, half the sky obscured.

and on the "pixie STM Firmware Version: v0.15.1-85-gee3dfff" observations S1, in RTKLIB no longer jump to 0

On Tuesday, April 28, 2015 at 2:19:13 AM UTC+2, Michael Oborne wrote:

[Stanislaw Nanek]

I put a video of a captured desktop screen, in which they participate 1 "pixie" converter sbp> RTCM by Michael Oborne "piksi.exe" and RTKLIB ;)

 may in some way closer conversion problem sbp> RTCM, in any case, at least demonstrate how it works "pixie" of RTKLIB.

observations made external antenna in poor conditions (half the sky obscured) connection: pixie> 3DRadio, 3DRadio> Computer

Input streams in RTKLIB:

Rover: Michael Oborne converter sbp> RTCM

Base: vrs base from local CORS network

Corrections: Broadcast Ephemeris Streams in RTCM3 from www.euref-ip.net mount: RTCM3EPH

a link to the video below ( approx. 45MB - 8 min.)

https://drive.google.com/file/d/0B3jouDgGL_gHeVUxQW0taWoyTjA/view?usp=sharing

[Stanislaw Nanek]

I know why some observations are rejected by RTKLIB - large residual on L1 

the errors / warnings show such messages:

outlier rejected (sat= 21- 16 L1 v=289.981)

large residual (sat=21-31 L1 v= 6.631 sig=0.014)

whether to adopt the method of alignment (they L1 is constants) can make a difference?

[Stanislaw Nanek]

the reason for this is not compatible with rtklib, it is probably that there is something wrong with the observation "Carrier Phase" in pixie.

[Clive Turvey]

Compared to the normal RINEX representation, the phase is negated and moving in the wrong direction wrt the doppler/range.

The pseudo-range has been reset epoch-to-epoch, there's a whole load to work to get it back to an actual time-of-flight/travel as perceived by the receiver. Right now it's relative arrival times, and differences between satellites

The time stamp is not entirely representative of the sample time, and does not step with a consistent clock bias and drift. ie you've got to figure out what the time really was, and then get the measurements shifted to a common time to compare with your other source of measurements.

The clock offset/error for the receiver must be recomputed at each epoch, and consists of the receiver's clocking and the motion of the ordinal satellite

So there's a lot of clean up work in the data as provided to get it into the same kind of frame as your average survey receiver.

[Stanislaw Nanek]

Yes, a lot of work, now in piksi P1 Residual is +- a couple meters and L1 Residual is +- a couple of hundred meters,

in the survey receiver P1 Residual is +- a few decimeter and  L1 Residual is +-  a few millimeters.

[Michael Oborne]

I know ive been playing with deriving p1 to make it an absolute measurement vs a relative one

https://github.com/meee1/libswiftnav/commit/e6f01072db6162f0d8e342d248253f3655fb5a44

https://github.com/meee1/piksi_firmware/commit/bcf439dad5f269903bb2985c74d87c6d0f9b3b8e

my normal test is using rtklib in ppp mode, as you can look at the l1, in a standalone enviroment

On Saturday, 2 May 2015 02:19:09 UTC+8, Stanislaw Nanek wrote:

[Michael Oborne]

on a related note

in rtknavi, if you goto that expanded data view you can see the current rx clock error under "states" x_4

looks to me its not an even drift, and seems to be reset every second

[Clemens Arth]

Hi, can anyone check if the 0.16 version fixes some of the issues raised previously? Don't have access to the pixie right now.
Cheers

[Steve]

Hi Michael

I'm trying to use your code to convert SBP to RINEX but I'm having some trouble as I'm a bit of a beginner when it comes to coding (just started learning).

I'm using windows and running your code via the cmd prompt when the piksi is connected via usb and the Piksi console is running. I'm getting confused as what to input once the program is running do I need to include the quotation marks? and which option is the source if the piksi is connected via USB? do I just need spaces between the file type input, source and destination or a new line?

Also will the rinex produced via this code have similar issues to the one produced by the Piksi console?

Sorry for the beginner level questions.

[Stanislaw Nanek]

for example:

piksi.exe rtcm COM5 1000000 tcp://0.0.0.0:898

but you cant run console in the same time, only one program can get acces to COM

[Rafael Zamarion]

I was trying to do the same thing, it seems like the rinex function only accepts a sbp file on the source and a rinex file on the destination,not a serial port. So, what is need to be done is to put the files directory address on the program.

However, i've tried this with a json sbp file and it doesn't seem to work. The program console writes the following message:

"sbp crc fail"

And the rinex output is a blank file.

[Michael Oborne]

the rinex option currently only supports from a raw sbp dump file.

what where you guys after, i may be able to add it?

[Michael Oborne]

i would normaly connect console to usb,

then put the 3dr radio comport into my program, that way you can see everything thats going on.

[Rafael Zamarion]

Thanks for the information! 

What i was after is a way of taking the .json data generated by the piksi console via command line or even the recorded sbp messages stream and converting it to a rinex format data.

[Michael Oborne]

i just added json to rinex support in the latest version.

[ryanp...@gmail.com]

Hi Michael,

I am trying to test the RTCM3->SBP functionality of your program. I have a similar setup to a baseline test you ran before with a Ublox and a Piksi where you converted to RTCM using the Ublox (4t) which you converted to SBP using your program and output it to a 3DR radio which sent the SBP data to a Piksi.

That is something that I want to test, but I am unsure as to how to convert the Ublox (in my case I am using a 6t) data to RTCM using UCenter or something else. I know how to do this with STRSVR in RTKLIB, but that isn't of much use since I would be transmitting RTCM if I did it that way. How can I do this?

Thanks for your work on this.

[ryanp...@gmail.com]

I just tried a workaround to my issue, with no success. What I tried to do was use 4 radios instead of 2. So I had a Ublox convert UBX data to RTCM through one 3DR using STRSVR. This radio sent that data to another 3DR which I used as the input to your program and output to a third 3DR which was paired with the Piksi's 3DR.

I ended up getting an error saying that the input string was of an incorrect format. Did you use RTCM 2 instead of RTCM 3 or something? Or is there something wrong with my test setup?

No need to answer this if you answered my previous question but I thought I would post this in case anyone else tried this.

[Clive Turvey]

>>I am unsure as to how to convert the Ublox (in my case I am using a 6t) data to RTCM using UCenter or something else.

I took the "something else" route with the 6T, as there seems to be no point in transcoding through RTCM, and the method you employed, while creative, seems unduly circuitous.

[Michael Oborne]

can you tell me more info about the format exception? it could be a bug.

[Michael Oborne]

in strsrv, I normally output messages "1002,1005,1006,1019"

On Thursday, 30 July 2015 02:53:52 UTC+8, ryanp...@gmail.com wrote:

[ryanp...@gmail.com]

Here is the error message:

Unhandled Exception: System.FormatException: Input string was not in a correct format.

   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)

   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)

   at System.Int32.Parse(String s)

   at piksi.Program.main(String[] args)

The command I used:

piksi.exe sbp 'COM26 115200' 'COM16 115200'

In the command I used above, both of the COM ports are 3DR radios. I also tried going from a Ublox to a 3DR but I quickly realized that wasn't useful since Ublox can not output RTCM to my knowledge at least.

I am looking to just use one Piksi as a rover and pull in rtcm corrections in real time, so I'm really hoping that this will do the trick!

[Michael Oborne]

remove the ' from your command line.

it should be

piksi.exe sbp COM26 115200 COM16 115200

[ryanp...@gmail.com]

Using that syntax the program seems to be running, although there is no output indicating that it is, just a lack of output indicating that it hasn't crashed.

Looking at the Piksi console I am not picking up the SBP signal from the 3DR radios I setup with the Ublox. I tried setting the duty cycle of the 3DR radio attached to the Piksi to 0 so it would just listen, however it seems like the Piksi just reconfigures it automatically on startup. Did you make any configuration changes somewhere to get this to work?

[Clive Turvey]

And the 3DR's are on different frequencies, or different network id's? ie suitably paired, but not stomping on the other pair(s).

[ryanp...@gmail.com]

Yeah they are on different net ID's.

[Michael Oborne]

I think you are going to need to test at each step.

ie setup strsvr, and connect rtklib direct to that.

then plugin a radio, and plug in the second radio to the pc, and test in rtklib again, on the receiver radio.

also plugin to a piksi, and use the usb to monitor.

etc

etc

[ryanp...@gmail.com]

Just ran it again this morning and it appears to now be working even though I have changed nothing. I am now seeing an output from the converter and baseline information from both the Piksi and the Ublox in Piksi console. I'll try and test it outside today to see if I can get a fix this way.

[ryanp...@gmail.com]

I may have found a bug in the converter. After taking in RTCM data from a radio for awhile (~20-30 messages), I get an IndexOutOfRangeException. The full message is given below with some of the output leading up to it.

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

> 2015 7 24 13 26 58.001 0 13

G19  22157618.134   116438196.4501                         45.000

G 9  21563086.518   113313955.8815                         44.000

G27  20876689.802   109707223.9371                         46.000

G58  38937216.242   204615526.6589                         43.000

G30  25821904.188   135694454.3808                         32.000

G53  38365617.186   201611456.6991                         39.000

G 7  22935975.768   120529173.3520                         42.000

G 8  21659483.876   113820699.7557                         37.000

G26  23379899.986   122861937.5421                         42.000

G23  21772992.496   114416748.4490                         45.000

G21  25613916.170   134601875.6685                         36.000

G10  25447360.492   133725708.9886                         36.000

G16  21383212.778   112369067.8836                         46.000

480418001 0.005 2402090.005 2402090 > 0.001

> 2015 7 24 13 26 59.001 0 13

G19  22156989.434   116434890.8515                         46.000

G 9  21563102.338   113314036.9798                         47.000

G27  20876514.042   109706298.6882                         48.000

G58  38937199.482   204615436.1515                         45.000

G30  25821250.508   135691020.3334                         31.000

G53  38365589.846   201611312.3722                         40.000

G 7  22935396.028   120526125.4787                         44.000

G 8  21659024.656   113818288.0360                         37.000

G26  23380439.186   122864769.9405                         43.000

G23  21773422.576   114419009.5015                         48.000

G21  25613931.950   134601956.0968                         34.000

G10  25447709.052   133727538.4267                         38.000

G16  21383594.718   112371072.9555                         48.000

480419001 0.005 2402095.005 2402095 > 0.001

> 2015 7 24 13 27 0.001 0 13

G19  22156360.094   116431586.5377                         45.000

G 9  21563117.278   113314119.5916                         45.000

G27  20876338.362   109705374.9555                         46.000

G58  38937182.562   204615346.5295                         43.000

G30  25820597.228   135687587.0269                         31.000

G53  38365562.806   201611168.9386                         38.000

G 7  22934816.028   120523078.5855                         42.000

G 8  21658565.936   113815877.6406                         38.000

G26  23380978.906   122867603.2927                         43.000

G23  21773852.636   114421271.9309                         46.000

G21  25613947.690   134602037.8520                         35.000

G10  25448057.532   133729369.1181                         36.000

G16  21383976.038   112373079.1573                         47.000

480420001 0.005 2402100.005 2402100 > 0.001

> 2015 7 24 13 27 1.001 0 13

G19  22155731.574   116428282.4788                         44.000

G 9  21563132.718   113314202.7052                         44.000

G27  20876162.162   109704451.7193                         45.000

G58  38937164.722   204615256.6683                         42.000

G30  25819943.268   135684153.5759                         30.000

G53  38365535.526   201611025.2659                         38.000

G 7  22934236.188   120520031.6476                         41.000

G 8  21658107.356   113813467.5946                         36.000

G26  23381517.266   122870436.5530                         41.000

G23  21774283.096   114423534.7046                         45.000

G21  25613963.150   134602119.8936                         34.000

G10  25448405.932   133731200.0618                         35.000

G16  21384357.858   112375085.4668                         45.000

480421001 0.005 2402105.005 2402105 > 0.001

> 2015 7 24 13 27 2.001 0 13

G19  22155103.134   116424978.2623                         45.000

G 9  21563148.838   113314285.9135                         46.000

G27  20875986.662   109703528.5515                         47.000

G58  38937147.562   204615166.2371                         44.000

G30  25819290.048   135680719.4129                         31.000

G53  38365507.706   201610881.0520                         40.000

G 7  22933656.068   120516984.2420                         43.000

G 8  21657648.676   113811057.4383                         37.000

G26  23382056.426   122873269.3692                         43.000

G23  21774713.736   114425797.4151                         47.000

G21  25613978.630   134602201.8906                         34.000

G10  25448754.292   133733030.7717                         35.000

G16  21384739.578   112377091.4793                         47.000

480422001 0.005 2402110.005 2402110 > 0.001

Unhandled Exception: System.IndexOutOfRangeException: Index was outside the boun

ds of the array.

   at piksi.RTCM3.Read(Byte data)

   at piksi.Program.Main(String[] args)

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

[Michael Oborne]

try disabling the tracking of sbas satalites

[Clive Turvey]

Definitely looks that way the G53 and G58 are not GPS birds. SBAS birds should have an S designator, and GLONASS ones an R

[ryanp...@gmail.com]

Disabling SBAS seemed to do the trick. I'm about to head out and do a test to see if I can get a fix with this implementation. I'll let you know the results of that soon.

Thanks for your help!

[ryanp...@gmail.com]

Actually nevermind, disabling SBAS was not the issue...immediately after I sent the last message it crashed again giving the same error. It took a lot longer to crash (around 10 minutes or so), but it crashed again with the same error. Here is some of the log and error message again:

498239000 0.000 2491195.000 2491195 > 0.001

> 2015  7 24 18 24          0  0 10

G 1  21321225.678   112042438.3820                         40.000

G28  20563350.664   108060745.5997                         40.000

G17  21625156.836   113640099.0689                         40.000

G 4  23164477.986   121729262.0919                         37.000

G 6  24640591.876   129486413.4769                         36.000

G30  23326745.566   122582364.3607                         41.000

G32  23431743.664   123134002.9252                         31.000

G24  25146312.174   132144107.7137                         33.000

G11  22112914.414   116203886.5498                         29.000

G 3  23338715.806   122645352.2668                         39.000

498240000 0.000 2491200.000 2491200 > 0.001

> 2015  7 24 18 24          1  0 10

G 1  21321588.018   112044340.3528                         37.000

G28  20563317.884   108060573.0585                         37.000

G17  21624831.316   113638391.2061                         36.000

G 4  23165100.546   121732533.7640                         36.000

G 6  24639866.276   129482600.1735                         35.000

G30  23327395.206   122585782.0571                         39.000

G32  23431635.844   123133439.5565                         30.000

G24  25145792.254   132141369.4881                         32.000

G11  22113454.514   116206726.5286                         29.000

G 3  23338231.826   122642810.9106                         36.000

498241000 0.000 2491205.000 2491205 > 0.001

> 2015  7 24 18 24          3  0 10

G 1  21322313.038   112048147.4000                         37.000

G28  20563252.424   108060230.9110                         36.000

G17  21624181.496   113634977.5560                         37.000

G 4  23166345.486   121739079.3573                         35.000

G 6  24638414.616   129474975.2826                         34.000

G30  23328695.646   122592619.6071                         39.000

G32  23431421.604   123132316.3478                         29.000

G24  25144750.974   132135895.6671                         31.000

G11  22114535.774   116212408.9167                         28.000

G 3  23337265.246   122637730.8468                         37.000

498243000 0.000 2491215.000 2491215 > 0.001

> 2015  7 24 18 24          4  0 10

G 1  21322675.798   112050052.1454                         37.000

G28  20563220.264   108060060.9159                         36.000

G17  21623856.956   113633271.5981                         37.000

G 4  23166969.006   121742353.0684                         35.000

G 6  24637689.236   129471163.4506                         34.000

G30  23329346.206   122596039.1164                         39.000

G32  23431313.024   123131756.1216                         29.000

G24  25144230.754   132133159.8326                         31.000

G11  22115078.474   116215251.2208                         29.000

G 3  23336783.266   122635191.7529                         36.000

498244000 0.000 2491220.000 2491220 > 0.001

> 2015  7 24 18 24          5  0 11

G 1  21323037.638   112051956.3522                         40.000

G28  20563187.804   108059890.3952                         38.000

G17  21623531.736   113631564.8309                         37.000

G 4  23167591.546   121745626.0070                         36.000

G 6  24636963.456   129467350.7306                         34.000

G30  23329997.046   122599457.8271                         41.000

G32  23431204.524   123131195.5723                         29.000

G 7  25354154.632   133236871.7790                         12.000

G24  25143709.874   132130423.4542                         32.000

G11  22115619.194   116218092.7315                         29.000

G 3  23336300.606   122632652.0442                         38.000

498245000 0.000 2491225.000 2491225 > 0.001

> 2015  7 24 18 24          7  0 11

G 1  21323762.818   112055765.5172                         36.000

G28  20563123.864   108059549.7586                         34.000

G17  21622882.776   113628151.3070                         35.000

G 4  23168836.606   121752171.9366                         34.000

G 6  24635512.656   129459724.7860                         32.000

G30  23331297.846   122606294.9277                         37.000

G32  23430992.824   123130075.3800                         28.000

G 7  25355586.252   133244363.3471                          8.000

G24  25142668.094   132124950.8839                         30.000

G11  22116705.034   116223775.8343                         27.000

G 3  23335333.506   122627572.8291                         34.000

498247000 0.000 2491235.000 2491235 > 0.001

> 2015  7 24 18 24          8  0 11

G 1  21324125.558   112057671.0509                         36.000

G28  20563091.904   108059380.3336                         35.000

G17  21622558.336   113626445.0942                         35.000

G 4  23169459.146   121755445.5137                         34.000

G 6  24634787.416   129455912.0949                         33.000

G30  23331948.226   122609713.9931                         39.000

G32  23430888.164   123129516.4754                         28.000

G 7  25356301.992   133248124.4390                          7.000

G24  25142147.294   132122215.4488                         31.000

G11  22117246.274   116226618.0859                         27.000

G 3  23334849.206   122625034.1110                         34.000

498248000 0.000 2491240.000 2491240 > 0.001

> 2015  7 24 18 24         10  0 10

G 1  21324850.118   112061481.5507                         38.000

G28  20563026.724   108059040.6113                         35.000

G17  21621907.916   113623031.2892                         35.000

G 4  23170704.966   121761991.4013                         34.000

G 6  24633335.476   129448285.0783                         34.000

G30  23333249.206   122616550.5866                         39.000

G32  23430673.684   123128398.3721                         28.000

G24  25141106.374   132116743.5958                         30.000

G11  22118325.574   116232302.0347                         29.000

G 3  23333882.666   122619955.4266                         35.000

498250000 0.000 2491250.000 2491250 > 0.001

> 2015  7 24 18 24         11  0 10

G 1  21325213.398   112063387.0686                         35.000

G28  20562995.064   108058870.9368                         35.000

G17  21621583.496   113621324.2224                         35.000

G 4  23171327.666   121765264.2558                         31.000

G 6  24632609.776   129444471.2022                         33.000

G30  23333899.686   122619968.6089                         37.000

G32  23430566.644   123127839.7776                         28.000

G24  25140586.214   132114007.6824                         30.000

G11  22118866.294   116235143.6663                         29.000

G 3  23333399.426   122617416.1225                         34.000

498251000 0.000 2491255.000 2491255 > 0.001

> 2015  7 24 18 24         13  0 10

G 1  21325938.478   112067195.5057                         36.000

G28  20562930.304   108058528.8261                         35.000

G17  21620934.076   113617906.8072                         35.000

G 4  23172572.346   121771806.7040                         34.000

G 6  24631155.456   129436839.6846                         34.000

G30  23335199.266   122626801.2979                         39.000

G32  23430353.944   123126720.4130                         29.000

G24  25139544.134   132108533.1993                         30.000

G11  22119948.334   116240823.9602                         28.000

G 3  23332431.486   122612334.5610                         34.000

498253000 0.000 2491265.000 2491265 > 0.001

> 2015  7 24 18 24         14  0 10

G 1  21326301.338   112069100.7845                         37.000

G28  20562898.484   108058358.7390                         35.000

G17  21620608.936   113616198.7788                         36.000

G 4  23173195.106   121775078.6651                         34.000

G 6  24630429.056   129433024.3633                         34.000

G30  23335849.706   122630218.2035                         39.000

G32  23430249.044   123126161.8316                         29.000

G24  25139023.194   132105796.8498                         30.000

G11  22120490.754   116243664.7457                         28.000

G 3  23331948.526   122609794.6579                         34.000

498254000 0.000 2491270.000 2491270 > 0.001

> 2015  7 24 18 24         16  0 10

G 1  21327029.018   112072920.3388                         35.000

G28  20562836.444   108058027.2907                         35.000

G17  21619960.576   113612790.8935                         36.000

G 4  23174442.826   121781630.8220                         33.000

G 6  24628978.036   129425401.5639                         34.000

G30  23337152.406   122637060.0783                         36.000

G32  23430040.464   123125054.2540                         29.000

G24  25137982.994   132100332.7664                         30.000

G11  22121573.274   116249355.0216                         28.000

G 3  23330983.966   122604723.3936                         34.000

498256000 0.000 2491280.000 2491280 > 0.001

> 2015  7 24 18 24         17  0 10

G 1  21327392.818   112074832.6672                         39.000

G28  20562805.684   108057864.0746                         36.000

G17  21619637.456   113611088.9399                         37.000

G 4  23175066.246   121784909.1155                         36.000

G 6  24628253.036   129421592.0494                         34.000

G30  23337804.226   122640483.1611                         40.000

G32  23429936.564   123124503.2531                         31.000

G24  25137463.854   132097603.0986                         32.000

G11  22122114.714   116252202.3785                         29.000

G 3  23330501.526   122602190.1591                         35.000

498257000 0.000 2491285.000 2491285 > 0.001

> 2015  7 24 18 24         18  0 10

G 1  21327757.598   112076746.9768                         40.000

G28  20562774.864   108057702.6399                         38.000

G17  21619313.556   113609389.0279                         39.000

G 4  23175689.986   121788189.0827                         36.000

G 6  24627528.416   129417784.0878                         35.000

G30  23338455.646   122643907.7311                         42.000

G32  23429832.544   123123954.2937                         31.000

G24  25136944.474   132094875.2465                         32.000

G11  22122657.834   116255051.5431                         29.000

G 3  23330019.226   122599658.5983                         37.000

498258000 0.000 2491290.000 2491290 > 0.001

> 2015  7 24 18 24         19  0 10

G 1  21328121.258   112078660.5979                         40.000

G28  20562743.944   108057540.5483                         37.000

G17  21618990.116   113607688.0885                         37.000

G 4  23176313.866   121791468.2116                         36.000

G 6  24626803.336   129413975.1751                         35.000

G30  23339107.766   122647331.4314                         41.000

G32  23429729.584   123123404.9743                         31.000

G24  25136425.474   132092146.7060                         32.000

G11  22123201.494   116257900.0508                         30.000

G 3  23329538.086   122597126.3675                         36.000

498259000 0.000 2491295.000 2491295 > 0.001

> 2015  7 24 18 24         20  0 10

G 1  21328485.618   112080573.1681                         41.000

G28  20562713.104   108057377.3190                         39.000

G17  21618664.876   113605985.7566                         39.000

G 4  23176937.426   121794746.0532                         37.000

G 6  24626078.736   129410164.6884                         37.000

G30  23339760.226   122650753.7128                         42.000

G32  23429628.844   123122854.4962                         34.000

G24  25135906.994   132089416.9331                         33.000

G11  22123742.974   116260747.0767                         31.000

G 3  23329056.306   122594592.8676                         38.000

498260000 0.000 2491300.000 2491300 > 0.001

> 2015  7 24 18 24         22  0 10

G 1  21329213.438   112084397.9563                         39.000

G28  20562651.404   108057050.3376                         37.000

G17  21618016.536   113602580.0075                         38.000

G 4  23178184.566   121801300.7088                         36.000

G 6  24624628.316   129402542.2411                         35.000

G30  23341062.186   122657597.0328                         40.000

G32  23429424.584   123121753.3718                         32.000

G24  25134869.134   132083956.7332                         33.000

G11  22124825.794   116266440.0878                         31.000

G 3  23328091.666   122589525.1637                         36.000

498262000 0.000 2491310.000 2491310 > 0.001

> 2015  7 24 18 24         24  0 10

G 1  21329942.258   112088228.1099                         38.000

G28  20562590.584   108056728.4273                         35.000

G17  21617369.836   113599178.6569                         37.000

G 4  23179433.006   121807859.8339                         35.000

G 6  24623179.776   129394923.0046                         35.000

G30  23342364.806   122664444.4544                         40.000

G32  23429215.444   123120658.6192                         32.000

G24  25133831.294   132078501.5098                         31.000

G11  22125914.034   116272138.2331                         30.000

G 3  23327130.286   122584462.3574                         36.000

498264000 0.000 2491320.000 2491320 > 0.001

> 2015  7 24 18 24         25  0 10

G 1  21330306.538   112090143.2840                         38.000

G28  20562558.864   108056567.4734                         36.000

G17  21617046.836   113597477.5520                         37.000

G 4  23180057.026   121811139.1153                         35.000

G 6  24622454.096   129391113.1984                         35.000

G30  23343015.826   122667867.7789                         40.000

G32  23429104.284   123120111.1759                         31.000

G24  25133312.354   132075773.7838                         31.000

G11  22126449.294   116274986.7487                         29.000

G 3  23326648.286   122581930.6994                         36.000

498265000 0.000 2491325.000 2491325 > 0.001

Unhandled Exception: System.IndexOutOfRangeException: Index was outside the boun

ds of the array.

   at piksi.RTCM3.Read(Byte data)

   at piksi.Program.Main(String[] args)

[Clive Turvey]

May be it's in the size of the packet, and how much it's buffering. There are a couple of RTCM packet buffers of 300 bytes, and then sanity checks that might allow it to span ~1024 bytes.

Doesn't look to be PRN related, you have 1 and 32 listed, the arrays have indexes of 33 and 255, so should accommodate.

Falls over before the time stamp is emitted, so probably processing input data packet.

On Friday, July 31, 2015 at 1:27:23 PM UTC-5, ryanp...@gmail.com wrote:

Actually nevermind, disabling SBAS was not the issue...immediately after I sent the last message it crashed again giving the same error. It took a lot longer to crash (around 10 minutes or so), but it crashed again with the same error. Here is some of the log and error message again:

 ..

[Michael Oborne]

ive just updated the program to increase the buffer size, and added a buffer size check.

this should resolve those issues

michael

[ryanp...@gmail.com]

That seems to have done the trick Michael. I ran a test this morning for about 40 minutes and I didn't have any issues. I will try and see if I can get a fix with this setup sometime soon.

Thanks again for your work on this converter!

[ryanp...@gmail.com]

I did a test today and I was getting 45-50 dB with 7-8 satellites in common, but I did not even get a float solution using this converter. I noticed a couple of things that are not the same between the way the converter and the way that the Piksi deals with SBP data with respect to the Piksi console.

Firstly, all of the values are truncated (51.0 instead of 51.25, 48.0 instead of 48.5, etc). Secondly, and what I would think is more important is that there is no selectivity in the converter. The Piksi will not show anything below 33dB-Hz in the Piksi Console, however the converter shows everything that it sees and that data goes to the Piksi Console.

While I can not say for sure if it matters or not, I would suspect that including satellites with low signal strength in the Piksi Console may be mucking things up. This may be something to look into.

Michael, have you had any luck getting a fix or float solution using a Ublox to generate RTCM data and a Piksi?

[ryanp...@gmail.com]

Have you had a chance to take a look at this yet Michael? Did you get a fix or float solution when you were doing your tests before using your converter?

[Clive Turvey]

Should be possible to get Float and Fixed solutions, while the performance doesn't excite me, it's better than DGPS, and it's significantly better than post-processed Piksi data.

[ryanp...@gmail.com]

I would think that we could get a float or fixed solution, but I didn't have any luck with it when I ran my test (I may run it again in the next week or so). Were those results from the current version of the converter? Just wondering because it could be possible that something broke in a recent change.

[Clive Turvey]

Are you not getting any kind of baseline solution at all? Is the console complaining about the observations (timing, missing, whatever)? When I feed it bad observations it still tried to develop a float solutions through it would often explode or verve around is a crazy fashion.

Do you get a blinking RED LED? The Observation format changed in the last firmware iteration, now SBP MSG # 0x43 vs 0x45, with a 32-bit PRN/SV field