#1873

Hi Andrew,

The adsbdecode plugin has a bug where the computed ground track based on aircraft velocity is incorrect.  This results in the icon, bearing and track prediction being incorrect.

The issue is in AircraftState.java, line 496.  The variables ewVelocity and nsVelocity are swapped.  Another issue is the float variable is cast to (int) potentially making the heading up to 1 degree off.

I think the correct line 496 should be;

bearing = (int)Math.round(Math.toDegrees(Math.atan2(ewVelocity, nsVelocity)));

I have compiled and tested this locally and it produces the correct result.  I’ve also filled out a ticket at sourceforge.

Carl.
vk1kcm.

#1874

Actually, both the original code and your fix are incorrect, but might be showing almost-correct cases near the axis of reflection. That is because geographic bearing has 0 degrees at True North and goes clockwise, whereas geometric bearing (returned by java.lang.Math.atan2(y,x)) has 0 degrees at True East and goes counterclockwise.

The correct formula (which I will be putting in the next release of YAAC) is 

                bearing = 90 - (int)Math.toDegrees(Math.atan2(nsVelocity, ewVelocity));

This accounts for both the reversal in rotation direction and the different zero position (the following lines of code account for negative bearing angle, regardless of whether line 496 is correct or not). You will find this code pattern in other places in YAAC (such as where the bearing and speed of an APRS station that does not report course and speed is inferred).

Let me know if this fixes your problem. I hope it isn't that you folks Down Under use a different standard for ADSB than we Yankees do.

Andrew, KA2DDO
author of YAAC

P.S. Which direction is clockwise on a digital clock? :-)
________________________________________
From: [email protected] <[email protected]> on behalf of Carl Makin <carl@...>
Sent: Saturday, March 11, 2023 3:17 AM
To: [email protected]
Subject: [yaac-users] Aircraft bearing (Heading) in ADSB decoding. Yes again, but with fix this time!

Hi Andrew,

The adsbdecode plugin has a bug where the computed ground track based on aircraft velocity is incorrect.  This results in the icon, bearing and track prediction being incorrect.

The issue is in AircraftState.java, line 496.  The variables ewVelocity and nsVelocity are swapped.  Another issue is the float variable is cast to (int) potentially making the heading up to 1 degree off.

I think the correct line 496 should be;

bearing = (int)Math.round(Math.toDegrees(Math.atan2(ewVelocity, nsVelocity)));

I have compiled and tested this locally and it produces the correct result.  I’ve also filled out a ticket at sourceforge.

Carl.
vk1kcm.

#1875

开云体育

Actually, I just confirmed my error per my stated fix to your fix. I just realized that the only time I see ADSB traffic at a known altitude and bearing, it's because the wind is blowing in such a direction that the active instrument approach that goes almost over my house is in use, and that flight path is directly along the axis of reflection between the current code and my fix. And my QTH is shielded from closer-to-the-airport traffic by the terrain. And I do recall that the other higher altitude ADSB traffic did seem to be going in an odd direction (like perpendicular to the Atlantic Ocean coast that is a mere 75 airmiles from my home, when Port of Entry airports are between my home and the shore).

So please try my fix of 90 - old formula.

Re: the integer round-off: that is for compliance with APRS, which also uses only an integer course value. And, as a pilot, I can say that it's tough to hold a flight course to less than 1 degree of course bearing error. The magnetic and gyroscopic compass instruments don't report to less than a degree anyway.

Just my $.02.

Andrew, KA2DDO

author of YAAC

From: [email protected] <[email protected]> on behalf of Andrew P. <andrewemt@...>
Sent: Saturday, March 11, 2023, 10:04 AM

Actually, both the original code and your fix are incorrect, but might be showing almost-correct cases near the axis of reflection. That is because geographic bearing has 0 degrees at True North and goes clockwise, whereas geometric bearing (returned by java.lang.Math.atan2(y,x)) has 0 degrees at True East and goes counterclockwise.

The correct formula (which I will be putting in the next release of YAAC) is

??????????????? bearing = 90 - (int)Math.toDegrees(Math.atan2(nsVelocity, ewVelocity));

This accounts for both the reversal in rotation direction and the different zero position (the following lines of code account for negative bearing angle, regardless of whether line 496 is correct or not). You will find this code pattern in other places in YAAC (such as where the bearing and speed of an APRS station that does not report course and speed is inferred).

Let me know if this fixes your problem. I hope it isn't that you folks Down Under use a different standard for ADSB than we Yankees do.

Andrew, KA2DDO
author of YAAC

P.S. Which direction is clockwise on a digital clock? :-)
________________________________________

Show quoted text

From: [email protected] <[email protected]> on behalf of Carl Makin <carl@...>
Sent: Saturday, March 11, 2023 3:17 AM
To: [email protected]
Subject: [yaac-users] Aircraft bearing (Heading) in ADSB decoding. Yes again, but with fix this time!

Hi Andrew,

The adsbdecode plugin has a bug where the computed ground track based on aircraft velocity is incorrect.? This results in the icon, bearing and track prediction being incorrect.

The issue is in AircraftState.java, line 496.? The variables ewVelocity and nsVelocity are swapped.? Another issue is the float variable is cast to (int) potentially making the heading up to 1 degree off.

I think the correct line 496 should be;

bearing = (int)Math.round(Math.toDegrees(Math.atan2(ewVelocity, nsVelocity)));

I have compiled and tested this locally and it produces the correct result.? I’ve also filled out a ticket at sourceforge.

Carl.
vk1kcm.

#1876

Thank-you very much!!!  Was hoping for a fix.

Show quoted text

On 03/11/2023 3:17 AM Carl Makin <carl@...> wrote:

Hi Andrew,

The adsbdecode plugin has a bug where the computed ground track based on aircraft velocity is incorrect.  This results in the icon, bearing and track prediction being incorrect.

The issue is in AircraftState.java, line 496.  The variables ewVelocity and nsVelocity are swapped.  Another issue is the float variable is cast to (int) potentially making the heading up to 1 degree off.

I think the correct line 496 should be;

bearing = (int)Math.round(Math.toDegrees(Math.atan2(ewVelocity, nsVelocity)));

I have compiled and tested this locally and it produces the correct result.  I’ve also filled out a ticket at sourceforge.

Carl.
vk1kcm.

#1877

开云体育

Hi Andrew,

Thanks for looking at this!

On 12 Mar 2023, at 11:15 am, Andrew P. <andrewemt@...> wrote:

.

So please try my fix of 90 - old formula.

Yes, that looks good here. ?BTW I got my information from

which included the formulas.

Re: the integer round-off: that is for compliance with APRS, which also uses only an integer course value. And, as a pilot, I can say that it's tough to hold a flight course to less than 1 degree of course bearing error. The magnetic and gyroscopic compass instruments don't report to less than a degree anyway.

I was just thinking rounding the track would make the path prediction match a long track very slightly closer, but it’s almost certainly not visible on the UI. :)

Let me know if this fixes your problem. I hope it isn't that you folks Down Under use a different standard for ADSB than we Yankees do.

No, exactly the same using the same software. ?In this case I’m using the raw output port from a readsb-protobuf container ()?so I can share the data which is also feeding .

I’m also connecting yaac to a moxa ip->serial box to connect to the KISS TNC so both aprx and yaac can share it.?

Thanks!

Carl,

vk1kcm.

_._,_._,_

Screenshot 2023-03-12 at 11.20.39 am.png

#1878

Actually, thinking about your proposed fix, it would have worked too, because you effectively did the same "flip around the 45-degree axis of reflection" as the "90 - " change did, without the extra integer subtraction operation. On the other hand, considering the computational cost of a double-precision atan2() function, an integer subtract is lost in the noise, and this is slightly clearer (as in, no one will look at the code a year later and say "hey, this code is wrong because the X and Y arguments are reversed, let's _fix_ it!").

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Carl Makin <carl@...>
Sent: Saturday, March 11, 2023 7:32 PM
To: [email protected]
Subject: Re: [yaac-users] Aircraft bearing (Heading) in ADSB decoding. Yes again, but with fix this time!

Hi Andrew,
Thanks for looking at this!

On 12 Mar 2023, at 11:15 am, Andrew P. <andrewemt@...> wrote:
.
.
So please try my fix of 90 - old formula.

Yes, that looks good here.  BTW I got my information from

which included the formulas.

Re: the integer round-off: that is for compliance with APRS, which also uses only an integer course value. And, as a pilot, I can say that it's tough to hold a flight course to less than 1 degree of course bearing error. The magnetic and gyroscopic compass instruments don't report to less than a degree anyway.

I was just thinking rounding the track would make the path prediction match a long track very slightly closer, but it’s almost certainly not visible on the UI. :)

Let me know if this fixes your problem. I hope it isn't that you folks Down Under use a different standard for ADSB than we Yankees do.

No, exactly the same using the same software.  In this case I’m using the raw output port from a readsb-protobuf container () so I can share the data which is also feeding .
I’m also connecting yaac to a moxa ip->serial box to connect to the KISS TNC so both aprx and yaac can share it.

Thanks!

Carl,
vk1kcm.