Transmitter health flag for FAA MOC

[dusan19]

Document F3586-22 (attached) requires checking if Transmitter radio hardware and software are functioning properly.
That's in chapters: 7.2.3.2 and 7.3.2.2 that are further referenced in tests in chapter 8 (8.8.2 and 8.9.6).

I see in the code that there are no checks that transmitter is working properly.
There is a flag pfst_check_ok but it doesnt have any effect as its just set to true.
The radio has to be tested pre flight, but also in flight, as the mentioned chapters of F3586-22 require.

Is there a way of checking whether the transmitter is working properly? Is there a plan of implementing this feature?

F3586-22 Standard Practice for Remote ID Means of Compliance (1).pdf

[BluemarkInnovations]

Is there a way of checking whether the transmitter is working properly? Is there a plan of implementing this feature?

Yes there is a check and it has been implemented

The ArduRemoteID module streams the OPEN_DRONE_ID_ARM_STATUS to the GCS.

GCS software like QGC can display the transmitter status: QGC RID PR

[dusan19]

I am getting that one, but that only shows the health of the data source (as required in 7.2.3.1).

led.set_state(pfst_check_ok && arm_check_ok? Led::LedState::ARM_OK : Led::LedState::ARM_FAIL);

pfst_check_ok is always true so that flag is useless, and arm_check_ok only checks the input data validity.

The message you mentioned OPEN_DRONE_ID_ARM_STATUS:

void MAVLinkSerial::arm_status_send(void)
{
    const uint8_t status = parse_fail==nullptr?MAV_ODID_GOOD_TO_ARM:MAV_ODID_PRE_ARM_FAIL_GENERIC;
    const char *reason = parse_fail==nullptr?"":parse_fail;
    mavlink_msg_open_drone_id_arm_status_send(
        chan,
        status,
        reason);
}

also just checks for parsing errors.

Transmitter radio hardware and software are not checked (as required in 7.2.3.2). I might be missing something, can you point me to the code where transmitter radio health is checked for?

[BluemarkInnovations]

You are right that the pfst_check_ok is always true. Nevertheless the following checks are implemented:

• input data validity (check_parse in RemoteIDModule.ino)
• input data validity (arm_status_check in transport.cpp)
• if the GCS does not receive the OPEN_DRONE_ID_ARM_STATUS messages anymore, it will signal that the transmitter hardware or communication has issue.

What is not included and needs to be extended is to check whether the transmit functions are healthy. And potential other pfst checks. For instance check the output of the BLE start advertising command: https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLEAdvertising.cpp#L603

[dusan19]

What is not included and needs to be extended is to check whether the transmit functions are healthy. And potential other pfst checks. For instance check the output of the BLE start advertising command: https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLEAdvertising.cpp#L603

Exactly, those are the checks that I also found missing. I would need to implement them to comply with the FAA requirements, so I was looking for pointers and advice.
So, would you say that using the return value of the advertise start function would be a sufficient transmitter radio health check?

[BluemarkInnovations]

So, would you say that using the return value of the advertise start function would be a sufficient transmitter radio health check?

Jein. I think that if we check the error/return code of each BLE and WIFi function is a good way to extend/implement the transmitter health. If all those commands return OK, the transmitter hardware is functioning. Question would be how to proceed if an error has been detected.

I mean if you set for instance the BLE advertisements and that fails, the health check fails, but if setting the next BLE advertisement payload returns OK, this error can be cleared. I.e. the transmitter is healthy again. On the other hand if the init function would fail, the transmitter health/error should not be cleared.

[BluemarkInnovations]

For me no problem to implement a PR with this functionality. But will take some weeks as I'm fully occupied.

[dusan19]

Thanks for all the help! I think ill implement that earlier, Ill push it upstream and then we can iterate if you have some comments.