Can't get RTK Fixed Consistently

[Kayla Wilson]

Hello, 

I am using the Piksi's with the RFD900+ Radios and cannot get RTK Fixed consistently. I can get RTK Fixed when I initialize with known base station, however when I start to move the 'rover' piksi away from the 'base' piksi it switched from RTK Fixed to float. They will not switch back to Fixed unless I initialize with known base station again. Can someone please help??

Thank you!!

[Kayla Wilson]

The errors in the console read:

Unaligned observation from base station ignored, tow = 317543.900, dt = 0.100

False phase lock detect PRN32: err=57.589882

Thanks again!

[Rai Gohalwar]

Hi Kayla,

Could you describe in a little more detail how the radios are set-up and configured ? What is the configuration string that you are sending through the console ? 

Best

Rai Gohalwar

r...@swift-nav.com 

[Jean-Marie Jaffré]

hello,

J'utilse également PILSKI avec RFD 868+, et je remarque que la portée est limitée à 150m, je vais faire des essais en terrain libre la semaine prochaine mais la plus part de mes relevés sont dans des endroits pas toujours dégagés.

Je pensais que j'augmenterais la portée de plusieurs kilomètres par rapport à l'équipement standard de Pilski.

Je donnerai les nouvelles distances entre les radios.

[Kayla Wilson]

Hello Rai,

We are using the piksi GPS with the RFD900+ radios instead of the included 3DR radios.

The configuration strings are as follows:

Rover: AT&F,ATS1=57,ATS2=64,ATS5=0,ATS15=1,ATS18=2,AT&W,ATZ

Ground: AT&F,ATS1=57,ATS2=64,ATS5=0,ATS15=0,ATS18=2,AT&W,ATZ

[Melanie Lee]

I'm having this same issue. Same setup. Is there any help that can be given?

Thank you!

Melanie Lee

[Rai Gohalwar]

Dear Kayla, 

The configuration string looks fine to me. If you are not pursuing a multi-base station set-up, I would prefer you update the firmware on your RFD module to 1.x single point SIK firmware. This way the RFD radio acts just like the 3DR radios. The same configuration string that is fed to the 3DR can be used here. 

I would recommend that you also reset your settings to default for Piksi. Lastly, ensure that you add your base-station coordinates to the base Piksi and broadcast them. 

Doing all these things should bring you success. 

Also, I recently made an announcement on this forum about some performance enhancements we discovered with the radios. You should also look at the forum post and incorporate those changes. https://groups.google.com/d/msg/swiftnav-discuss/YincB66Ja2Y/00j35bdjCQAJ 

Best

Rai Gohalwar 

PS : I would look for other modules around your set-up that may be running on the same frequency and Net-ID. This could also effect the performance significantly. 

[Pw Cloete]

Hi, I'm having precisely the same issue as these guys. When I start moving with the Rover, it falls back to float RTK (and maybe even all the way back to float).

I followed the setup procedure to the letter as stated in your quick start guide here. I use 3DR links, with my command setup on both sides as:  AT&F,ATS1=57,ATS2=64,ATS3=211,ATS4=20,ATS5=0,AT&W,ATZ

(which in my opinion should be fine?)

I also constantly get this warning message in the console 

I want this to be stable before taking the setup further.

Please advise?

Thank you.

Pw

[Rai Gohalwar]

Hi Pw,

Do you see this latency every time you power up the system or occasionally ? 

Best

Rai Gohalwar 

[Seth Kreitinger]

Hello,

I am also receiving this warning message constantly. The rover did converge to a fixed RTK solution and was able to hold it while in radio range. However, I have concerns about the reliability of the system if warning messages are being generated constantly and rapidly. I have as of yet been unable to find any information on what this message actually means or what may cause it. Any help as to the meaning or potential causes of this issue would be greatly appreciated.

I am currently using the 3DR radios and have followed the getting started guide to ensure the radio settings and message masks etc. are correct. 

Thanks!

Seth Kreitinger

[Seth Kreitinger]

I have solved the problem. I decided to search the source code for the message being generated and found this code section taken from the opensource firmware base_obs.c file

u32 obs_freq = soln_freq / obs_output_divisor;
double epoch_count = tor.tow * obs_freq;
double dt = fabs(epoch_count - round(epoch_count)) / obs_freq;
if (dt > TIME_MATCH_THRESHOLD) {
    log_warn("Unaligned observation from base station ignored, "
             "tow = %.3f, dt = %.3f", tor.tow, dt);
.
.
.

It turned out to be that one of my piksi's had the default obs_output_divisor of 2 while the other had an obs_output_divisor of 1 making every other observation packet out of sync. I hope this helps anyone else having this issue.