Add second GPS object to openCPN

[barnakiel]

Originally Posted by bdbcat

barnakiel...


What is your concern about seconday gps tracking?


Dave

Following the thread, listening to how things get done by various posters.


I think the virtual ais object method (to cast secondary gps objects) sounds very good. Zero risk of mistaking for own position.



My gut feeling is that multiple gps tracking is an awesome feature. It just needs to be kept absolutely clean off 'own gps' both visually and in case of data stream loss. I like the function especialy when I think of logging remote stations via the IP / Internet.



I am yet to test ride 5.0 so for the moment just reading on to stay up to with what there is.


Very best regards,
barnakiel

[lsk]

Originally Posted by rooiedirk

Something comingup my mind.
If you can configure your 'first' GPS not to send a GLL sentence, and your 'other' does, then the only incomming GLL sentence would be from the 'other'.
Then if you tell OpenCPN not to use the GLL sentence for the ownship position by adding "UseNMEA_GLL=0" to the config/ini file.
Then you can use the nmeaconverter plugin to convert the GLL to TLL. No external programs and servers needed anymore.

I presume this can be achieved simply by telling openCPN to filter out the GLL sentences on the connection tab of the "primary" GPS.
But then how to convert the sentences of the second one to TLL? I cannot figure out how to configure the Nmeaconverter plugin.

As for barnakiel concerns, if this function will ever be implemented, I presume it should be located in a well separated area(or even a plugin) so it will be very difficult to the aveage joe to activate it unwillingly

[lsk]

(sorry for the double post but is seems I cannot edit...)
I figured out how to translate the sentences using nmea converter. I post it here for future reference

$GPTLL,01,$GPGLL1,$GPGLL2,$GPGLL3,$GPGLL4,NAME,$GPGLL5,T,

I still have to try on the field, but I presume that setting the correct priority on the connection tab of OpenCPN and filtering out the GLL messages from the primary device will do the trick

The thing I still cannot understand is why the secondary target now flashes..

[rooiedirk]

Do you use the nmea-converter for sending every xx seconds or sending after udate data??
If you use every xx seconds the target might be jumping every now and then to 00N and 00E.(After transmiting a sentence all data is set to zero again. and if you transmit again before new data arrived, you will send a zero,zero position)
So make sure to use "send after update all data".

[lsk]

Originally Posted by rooiedirk

So make sure to use "send after update all data".

I's already configured this way, but still, every now and then disappears. It seems it happens when the "Course" field goes to a nonsense value (like -2147483648 as in attached image).
I looked at the NMEA stream for GPTLL and nothing seems strange (like jumps in positions): what can it be?

[rooiedirk]

This must be a bug in OpenCPN or a hardware (memory) problem of your computer.


OpenCPN does calculate the COG between the previous and the new position. And the outcome should always be in the 000 to 360 range.


Is it possible to make a record of your GPS data and post it here?

[lsk]

Here it is:

<GREEN>10:52:57 (Virtual:) $GPTLL,1,4423.48522,N,855.07656,E,FALCON,85256.00,T*04<0x0D><0x0A>
<GREEN>10:52:58 (Virtual:) $GPTLL,1,4423.48520,N,855.07664,E,FALCON,85257.00,T*06<0x0D><0x0A>
<GREEN>10:52:59 (Virtual:) $GPTLL,1,4423.48514,N,855.07680,E,FALCON,85258.00,T*04<0x0D><0x0A>
<GREEN>10:53:00 (Virtual:) $GPTLL,1,4423.48513,N,855.07681,E,FALCON,85259.00,T*03<0x0D><0x0A>
<GREEN>10:53:02 (Virtual:) $GPTLL,1,4423.48509,N,855.07687,E,FALCON,85300.00,T*03<0x0D><0x0A>
<GREEN>10:53:02 (Virtual:) $GPTLL,1,4423.48505,N,855.07694,E,FALCON,85301.00,T*0C<0x0D><0x0A>
<GREEN>10:53:04 (Virtual:) $GPTLL,1,4423.48503,N,855.07690,E,FALCON,85302.00,T*0D<0x0D><0x0A>
<GREEN>10:53:05 (Virtual:) $GPTLL,1,4423.48502,N,855.07688,E,FALCON,85303.00,T*04<0x0D><0x0A>
<GREEN>10:53:05 (Virtual:) $GPTLL,1,4423.48500,N,855.07690,E,FALCON,85304.00,T*08<0x0D><0x0A>
<GREEN>10:53:07 (Virtual:) $GPTLL,1,4423.48499,N,855.07686,E,FALCON,85305.00,T*0F<0x0D><0x0A>
<GREEN>10:53:08 (Virtual:) $GPTLL,1,4423.48497,N,855.07690,E,FALCON,85306.00,T*05<0x0D><0x0A>
<GREEN>10:53:09 (Virtual:) $GPTLL,1,4423.48498,N,855.07684,E,FALCON,85307.00,T*0E<0x0D><0x0A>
<GREEN>10:53:10 (Virtual:) $GPTLL,1,4423.48503,N,855.07632,E,FALCON,85308.00,T*0F<0x0D><0x0A>
<GREEN>10:53:10 (Virtual:) $GPTLL,1,4423.48503,N,855.07623,E,FALCON,85309.00,T*0E<0x0D><0x0A>
<GREEN>10:53:12 (Virtual:) $GPTLL,1,4423.48504,N,855.07613,E,FALCON,85310.00,T*02<0x0D><0x0A>
<GREEN>10:53:13 (Virtual:) $GPTLL,1,4423.48505,N,855.07602,E,FALCON,85311.00,T*02<0x0D><0x0A>
<GREEN>10:53:13 (Virtual:) $GPTLL,1,4423.48504,N,855.07602,E,FALCON,85312.00,T*00<0x0D><0x0A>
<GREEN>10:53:15 (Virtual:) $GPTLL,1,4423.48503,N,855.07603,E,FALCON,85313.00,T*07<0x0D><0x0A>
<GREEN>10:53:16 (Virtual:) $GPTLL,1,4423.48502,N,855.07601,E,FALCON,85314.00,T*03<0x0D><0x0A>
<GREEN>10:53:17 (Virtual:) $GPTLL,1,4423.48502,N,855.07594,E,FALCON,85315.00,T*0D<0x0D><0x0A>
<GREEN>10:53:18 (Virtual:) $GPTLL,1,4423.48505,N,855.07580,E,FALCON,85316.00,T*0C<0x0D><0x0A>
<GREEN>10:53:18 (Virtual:) $GPTLL,1,4423.48505,N,855.07570,E,FALCON,85317.00,T*02<0x0D><0x0A>
<GREEN>10:53:19 (Virtual:) $GPTLL,1,4423.48500,N,855.07566,E,FALCON,85318.00,T*0F<0x0D><0x0A>
<GREEN>10:53:21 (Virtual:) $GPTLL,1,4423.48500,N,855.07552,E,FALCON,85319.00,T*09<0x0D><0x0A>
<GREEN>10:53:22 (Virtual:) $GPTLL,1,4423.48504,N,855.07536,E,FALCON,85320.00,T*05<0x0D><0x0A>
<GREEN>10:53:23 (Virtual:) $GPTLL,1,4423.48507,N,855.07514,E,FALCON,85321.00,T*07<0x0D><0x0A>
<GREEN>10:53:24 (Virtual:) $GPTLL,1,4423.48511,N,855.07486,E,FALCON,85322.00,T*09<0x0D><0x0A>
<GREEN>10:53:25 (Virtual:) $GPTLL,1,4423.48517,N,855.07462,E,FALCON,85323.00,T*04<0x0D><0x0A>
<GREEN>10:53:26 (Virtual:) $GPTLL,1,4423.48523,N,855.07432,E,FALCON,85324.00,T*01<0x0D><0x0A>
<GREEN>10:53:27 (Virtual:) $GPTLL,1,4423.48529,N,855.07407,E,FALCON,85325.00,T*0C<0x0D><0x0A>
<GREEN>10:53:27 (Virtual:) $GPTLL,1,4423.48530,N,855.07394,E,FALCON,85326.00,T*0A<0x0D><0x0A>
<GREEN>10:53:28 (Virtual:) $GPTLL,1,4423.48527,N,855.07396,E,FALCON,85327.00,T*0F<0x0D><0x0A>
<GREEN>10:53:30 (Virtual:) $GPTLL,1,4423.48529,N,855.07387,E,FALCON,85328.00,T*0E<0x0D><0x0A>
<GREEN>10:53:31 (Virtual:) $GPTLL,1,4423.48528,N,855.07386,E,FALCON,85329.00,T*0F<0x0D><0x0A>
<GREEN>10:53:32 (Virtual:) $GPTLL,1,4423.48527,N,855.07382,E,FALCON,85330.00,T*0C<0x0D><0x0A>

The last 4-5 sentences are across an anomaly, but I can't see anything abnormal

[rooiedirk]

The good news is, it's not your computer. I see the same thing happening here.
Now trying to find the bug.

[rooiedirk]

@Isk,


I did found a problem in OpenCPN. A mistake in the calculation of course / speed from two positions.
For now I made a quick and dirty fix, that does work (At least for me on my computer)
Please try this one. https://ci.appveyor.com/api/buildjobs/wvx0t24ajakjs0mi/artifacts/build%2Fopencpn_5.0.0%2Bde78009_setup.exe

Please try to make an extra check on the calculated course and speed in the ARPA target properties window.
Dirk

[Hakan]

Dirk..
Interesting! Please what's the fix? I'd like to try if that affects the ARPA - TLL from radar_pi as well.
Håkan

[rooiedirk]

Hakan,
For the time being I made a quick and dirty fix. Rewrite the DistanceBearingMercator() function and use thatone instead of the ll_gc_ll_reverse (..)


See also https://github.com/RooieDirk/OpenCPN/tree/nmea_TLL


and as issue: https://github.com/OpenCPN/OpenCPN/issues/1447


for the moment my guess is that it is going wrong with small distances.
Dirk

[lsk]

I'm downloading it just now! I'll update you with the results
Thanks Dirk

EDIT
I tried and it doesn't seem to flash anymore.
The speed is getting strange values altough. It shouldn't be a great issue, as this is a limit case scenario (i'm in the office with the GPS receiver out of the window in a fixed position). I'll try on a moving vessel tomorrow to see if the situation is the same

[Hakan]

Dirk..
Thanks.
I've tested your patch and see no differences for my simulated TLL-ARPA targets. So far so good I suppose.
Håkan