Closed hbeni closed 2 years ago
Possible cause is the RDF input parser breaks at the nasal error; thus, not updating the input fields anymore.
Faking RadioID=4 in the rdfinput data field seems to move the needle. Maybe there is just a mismatch between the radios, because the VHF COM1 already picks up the signal?
It also looks like the protocol's <input>
section is not active anymore? We don't receive information on the RDF input node on latest FGFS next.
echo "RDF:CS_TX=Test,FRQ=123.45,DIR=180.5,VRT=12.5,QLY=0.98,ID_RX=4" | nc -u localhost 19991
moves the needle too.
Maybe two issues here: 1. ID mismatch, 2. no input data anymore
Generated data looks good from the code. ID should be 4
.
So it currently really looks like the data is either not digested by fgfs or not sent to the proper location.
The plugin debug log says, target port is set to:
[mumid=174; iid=0] D-EBHX: clientTgtPort=127.0.0.1:19991
Port seems to be open:
udp 0 0 0.0.0.0:19991 0.0.0.0:* 1000 85223 23380/./fgfs
Reason found: The UDP client startup invocation was not compiled into the binary, because the corresponding C annotation was the wrong way around. If reversed, all is working again...
The nasal errors above are very surely side effects of manual testing.
Fun fact: you can in FGFS tune the ADF to 112000kHz, and thus listen to VHF frequencies.
Describe the bug ADF is not working with VHF beacon. We have a VHF beacon and tried to tune the ADF to that value (121000 kHz = 121.00 MHz)
Additional context FGFS log:
Debug log: