Hi, Sorry for the 'threading' confusion. Ron pointed out to me off-list that it is BAD to [Reply] to 'old' messages, just changing the topic, when creating a _NEW_ topic. Shall avoid that in future ;=))
Ok, I have taken this a step further, and modified
Network/atlas.cxx to add the magnetic variation,
and found the flaw in the code snippet given ;=))
a missing '%' char!
And have tested this with Atlas. It is fully backward
compatible in that Atlas was totally ignoring this
field in the message, and was thus writing the same
dummy '000.0,E' when saving the track.
After correcting both parts of Atlas, the decode, and
the save, I now get a 'track' file that includes the
magnetic variation. I also have to check when Atlas
reads in an existing track file...
But attached is a FG source patch for this. I would
add it as a git merge request if I knew how ;=)) Maybe
someone can point me to some documentation on how
to do this, and I will try that next time...
But if thought fit, I hope this patch can make it
into git, to augment the atlas protocol output...
Regards,
Geoff.
attached: 0005-add-magvar.patch
Original Message :
> Hi,
>
> Is there any particular reason why the $GPRMC message
> generated for Atlas protocol only has a 'dummy'
> magnetic variation, '0.000,E' - in atlas.cxx,
> about line 139
>
> For example, the garmin message correctly gets the -
> /environment/magnetic-variation-deg
> when generating its $GPRMC message - in garmen.cxx,
> lines 127-135.
>
> I am trying to add some 'features' to Atlas, to further
> aid in 'navigation', and the magnetic variation will
> assist in these calculations...
>
> The message heading given is magnetic -
> /orientation/heading-deg
> and the addition of the magnetic variation to the
> Atlas $GPRMC message would allow the true heading
> to be calculated and be used in SG geod distance
> calculations, etc...
>
> It would be as simple as duplicating the code from
> the garmin.cxx, something like :-
> char dir = 'E'; char magvar[10];
> float magdeg = fgGetDouble("/environment/magnetic-variation-deg");
> if (magdeg < 0.0) {
> magdeg = -magdeg;
> dir = 'W';
> }
> sprintf( magvar, "05.1f,%c", magdeg, dir );
> then add 'magvar' to the Atlas $GPRMC message...
>
> Of course, Atlas could have code to 'calculate' its own
> magnetic variation, like that in coremag.cxx, or use the
> functions from that SG library, but hope not to have to
> do that... especially since I think it 'should' be part
> of the $GPRMC message...
>
> Was this just an oversight, or was there a specific reason
> why it was decided that the Atlas message should only
> have a 'dummy' value?
>
> If just oversight, then the above code could serve as a
> patch to atlas.cxx... when someone has the time... and that
> would be very much appreciated ;=))
>
> Regards,
> Geoff.
0005-add-magvar.patch
Description: application/mbox
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
