Heard location of station is changed to the location of an object created by that station

[VK2HFG]

The location of objects created by a station is presumably erroneously used to update the location in the heard table for the station, as seen when using the debug option -d m
This causes an incorrect distance calculation when determing whether packets received from the server for the station should be sent to RF, which can be significant when the object is 100 km away from the station.

Direwolf 1.7 release version.

Heard table entry preceding a packet for an object being heard:
VK2RBE-1 4 0 0 0:02 - -35.05 147.56 0

then a packet for one of the objects is heard:
VK2RBE-1 audio level = 56(10/11) ||||_____
[0.1 15:00:35] VK2RBE-1>APDW17,RFONLY:;438.025 *111111z3507.95S/14722.33ErT091 -500 Wagga linked rptr
mheard_save_rf: VK2RBE-1 0 - update time, was 0 hops 180 seconds ago.
callsign cnt chan hops RF IS lat long msp
VK2RBE-1 5 0 0 0:00 - -35.13 147.37 0

Graeme VK2HFG

[VK2HFG]

Having direwolf.c check for type = position seems to have solved the issue. Debug option -dm shows that objects no longer invoke a call to mheard_save_rf yet all packets already determined to be position packets are still added to or update the mhead table.

Original call:
mheard_save_rf (chan, &A, pp, alevel, retries);

my version:
if (A.g_packet_type == packet_type_position) {
mheard_save_rf (chan, &A, pp, alevel, retries);
}

Graeme VK2HFG

[VK2HFG]

The test has been changed to not an object so that other packet types update the table.
if (A.g_packet_type != packet_type_object) {

[wb2osz]

Thank you for pointing out this problem.
I think that putting this test in mheard.c seems to make more sense.
This is now in the "dev" branch which will become release 1.8.

73,
John WB2OSZ