Open 3.2.2 Crashes on Ubuntu 12.04 64 bit

[redog]

Dave

nmea10 was live and at anchor, having dropped RMC from UDP supplied from comp2.
So rogue RMC looks like coming from comp2.

Your correct I could easily delete the lines too.
Sometimes the simplest of solutions is in our face and we fail to see them.
Thanks I forgot that the lump on my shoulders still has a purpose in this world.

Time to do some more testing

redog

[redog]

Dave

Set up as per screenshot ignore RMC.

Debug window showing RMC dropped.(Good)

VDR file (nmea20) showing RMC. ???

Is this what you would expect to see?

NB moored to pontoon.

redog

[bdbcat]

redog....

OK, that looks right. VDR records everything from all ports, and does not participate in the downstream multiplexer or priority scheme.

That way, a VDR recording may be played back, experimenting with various filters and priorities if desired.

Coming back to the original problem:
I think the original problem with jumping position was due to two conflicting position sentences, from two separate GPS sources.

If you play nmea2.pdf through VDR replay function with no filters, do you see jumping as in live run?

Do your multiple GPS receivers report the same positions (+/- 20 meters or so) always?

Dave

[redog]

Dave
Ok with a bit better understanding I revert to what was the start of all this.

I have GPS connected via GPSD priority 9.
UDP from comp2 priority 5.

Expectation that in the event of GPS failure (priority9) UDP supplies RMC position info.

However I think I am still seeing RMC via UDP even though priority is set to 5.(screenshot)

If I filter out RMC "O" acts as expected but I don't get the backup capability in the event of GPS failure as RMC is always filtered out.

I was hoping to use priorities as the filter for such an event.

My position does vary between these 2 sources.
But in the event of primary failure, having secondary backup without having to rejigger a computers sources while under navigation,
Well I think in this instance the variance is acceptable.

Until I prove either source to be correct!!!!

Thanks
redog

[bdbcat]

Redog....

The fallback priority scheme you want should work. The RMC from UDP stream will be ignored, as it is lower priority. This is not shown in the debug window, and perhaps it should be indicated somehow to clarify the action of priorities. I'll add this to the list of ttd.

You can test it by opening the NMEA debug window as in your screenshot. All should be green as shown. Then simply unplug the GPS on comp1, and watch to see in you get a priority switch message (in red) in the NMEA debug window. It should switch to UDP.

I'll try to simulate this config if you have trouble with the test procedure.

Meanwhile, there is another complication which I just noticed from your screenshot.

Your ownship position is also being reported by the AIS transponder in the AIVDO sentence. This could be the source of the jumping. You really only need one position source from UDP, but I see three (RMC, GGA, and AIVDO). RMC and GGA will be ignored due to higher priority duplicates from primary GPSD stream, so that's OK. But, if lat/lon from AIVDO does not match the lat/lon from primary GPSD RMC in normal operation, then you will get jumping.

Solution: on UDP stream, filter out AIVDO.

Dave

[redog]

Dave

It is as you say, pull the plug on comp1 and in red it switches to the UDP from comp2.
I had done this several times in the past but seeing UDP supplied sentences in the debug window prior to pulling the plug had always lead me to believe they we the cause of my troubles.
Your fix should solve this possible uncertainy for others as well.
Might I suggest the 3 colours of the debug window work well.
If possible just include this in the dropped sentence colour.(Works for me)

Now that I know and trust that the priority setup is working I can continue to eliminate / filter sentences as per you last post.(AIVDO)

Thanks
redog