Fixed baseline is definitely not fixed.

[mi...@bfo.co.uk]

Hi all

I have solved my earlier problems and am now receiving baseline_ned messages marked as "fixed", which I believe means the IAR calcs have all been done and the computed values can be trusted. But I am seeing considerable variation in the baseline.

The two units are a fixed distance apart and are stationary. The baseline_ned message has the "fixed" flag set and states between about 5 and 7 satellites were used in the solution. But the baseline tends to stabilise on one baseline before jumping to another - the actual baseline is about 5500m,, but I'm presently seeing values oscillate about +/- 500mm around 6800mm. Both Piksi's have "solution mode" set to time-matched, and messages are being relayed over USB, so I'm confident they are arriving and arriving promptly. Firmware was updated about 3 weeks ago.

I realise 5 to 7 satellites is less than ideal, and I realise that the RTK solution will be sometimes lost.

My concern is I have no way to identify when the baseline is accurate or not - I thought the fixed flag would indicate this, but as it is now it's actually worse than no RTK solution at all, as I can't trust any of the output!

Any suggestions? Is there anything else I can check?

Cheers... Mike

[mi...@bfo.co.uk]

To follow up myself, I see Clive's reply to an earlier posting included:

> Having the Fixed RTK decamp to a couple of locations is quite common with the current firmware, and significantly better than older releases.

That sounds like what I'm seeing here, but it doesn't do me much good. Surely there must be some way to identify when this is happening and discard the message? I can verify the distance of the baseline is approximately correct, but that still leaves a window for incorrect baselines to be accepted.

[Clive Turvey]

If the firmware could figure it out, then presumably it wouldn't be doing this.... It seems to be sticking with solutions that don't fit, so probably some filters or thresholds that need to be tweaked.

The last firmware I tested this on was significantly better in this regard than prior ones, but still frustrating. I'd get a tight cluster of results, and then it would move to another spot and give a tight cluster there. I'll have to go look at what plots I have.

I have other L1 RTK receivers working more robustly now. ie 10-day CEP99 numbers under 3.5 cm

[Swift Navigation (Josh Kretzmer)]

Mike,

The current Piksi firmware experiences some issues at baselines above 3 or 4 km. You may be able to improve performance by using the elevation mask, but at the cost of availability.

Thanks,

-Josh

[mi...@bfo.co.uk]

Hi Josh

Ugh, sorry. An unfortunate typo in my original post - for "m" read "mm" - the units are about 5500mm, 5.5m apart. I imagine that changes things.

Cheers... Mike

[Clive Turvey]

One of My primary tests was a 7m baseline with a 1m elevation change. Looking at the plot indicated a 2cm CEP50 but a 30cm CEP95

[mi...@bfo.co.uk]

I have finally got my boat on the water with a clear sky-view and have (roughly) 24 hours or so of data to analyse. I posted my original grumble a month ago, but it's worth repeating because I haven't seen a response from Swiftnav and now have some hard numbers with a decent sky-view.

* I have two Piksis a fixed distance apart - 6080mm, just over 6 meters.

* I logged 82874 baseline_ned messages which were "fixed", with anywhere between 5 and 9 satellites in common. I have discarded "float" messages completely, and not analysed that data.

* Of the "fixed" messages:

  14% were +/- 2cm accuracy

  22% were +/- 5cm accuracy

  38% were +/- 20cm accuracy

  64% were +/- 50cm accuracy

  so 36% were over 50cm away.

I am trying to hit +/- 5cm. I understand this is a big ask and that although the FAQ states the Piksi is accurate to +/-2cm, that's a best case, and statistical variation is going to account for a fair bit of movement around this. However 36% of fixed messages were over half a meter away - that's unusable on a 6 meter baseline when you're trying to establish the bearing between the two units. On a shorter baseline (I think someone on this list is using this on a model trimaran) it would be much worse.

Maybe I am asking too much here, and no doubt over a 100m baseline I'd be happy with 0.5m. As I know my baseline I can just discard messages that don't meet the criteria, which is 80% of the traffic - this makes the Piksis no long useful for the purpose I bought them for (an electronic compass) - with a bit of work I can use them to calibrate a secondary magnetic compass, so it's not a complete flop. But I am definitely frustrated, and I'm sure for some use cases with an unknown baseline, this sort of variation would make the units next to useless.

I understand things are progressing at SwiftNav, but I'd really like to know if I - or rather we, as there are now several reports like this on the forum - are up against a short-term bug, a technical hitch which is being worked on, an inherent flaw in the design, or if I am just failing to understand the statistical variation that one would expect to see with an RTK system.

Once I know what to expect, I can figure out how to progress. Would really like to hear something from SwiftNav on this one.

Cheers... Mike

On Friday, August 26, 2016 at 1:49:28 AM UTC+1, SungTae Moon wrote:

Hi all,

When I use the piksi rtk, I found several problems about fixed rtk position.

1. often, the drift happens when changing mode (float <-> fixed).

    many times, when the mode is released and recovered again (fixed -> float -> fixed), the position is changed like this. Of course, I want to keep the fixed rtk. however always, the mode is released. :-(

2. some times, the rover (not base) does not receive observation data.

  actually, I think it will be bug. at this experiment, the rover did not receive observation data during 12,500 msec from gps. 

I hope the piksi rtk is improved. However, during about 2 month, any update does not happen from github !  Is there any problem? I hope to work again. 

Thanks in advance

Best Regards,

STMOON

P.S.

  I have used the newest firmware (v0.22-rc5)

[Josh Kretzmer]

Mike,

Sorry to hear you are having difficulties achieving the accuracy you need in your application. You should be seeing better results. I'm going to email you directly to gain some more understanding about your application and hope to find a solution for the issues you are experiencing.

Thanks,

-Josh

--
You received this message because you are subscribed to a topic in the Google Groups "swiftnav-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swiftnav-discuss/pre9fzhBtAw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swiftnav-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to swiftnav-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/swiftnav-discuss.
For more options, visit https://groups.google.com/d/optout.