search

opendroneid / opendroneid-core-c

Open Drone ID Core C Library
Apache License 2.0
180 stars 64 forks source link

Curious on Broadcast Timestamp - opendroneid-core-c - static float decodeTimeStamp(uint16_t Seconds_enc) #85

Closed Greg-C10 closed 10 months ago

Greg-C10 commented 10 months ago

I was looking at the broadcast requirements (https://www.ecfr.gov/current/title-14/chapter-I/subchapter-F/part-89/subpart-D/section-89.305)

It states: A time mark identifying the Coordinated Universal Time (UTC) time of applicability of a position source output.

I was trying to find a UTC timestamp in the location type message. It appears they are providing seconds after the last full hour (opendroneid.c static float decodeTimeStamp(uint16_t Seconds_enc)). Not sure why its using seconds after the hour. Couldn't you get a UTC timestamp from the GPS sensor and broadcast it?

friissoren commented 10 months ago

You are correct about both. Originally, there was a strong desire to save bits for the transmitted data, since the Bluetooth 4 advertising messages only supports a limited amount of bytes (that is also the reason no message is longer than 25 bytes). Therefore, only limited time information is being sent in the Location information, since the receiver can reconstruct the full timestamp.

However, due to the specific FAA requirement you mention, it was later decided that a full timestamp is needed, and this was added to the System message.

In the "F3586 − 22" Means of Compliance document section 5.1.3.4 there is a requirement to make it mandatory to fill this System message field and some further info about this in 6.1.2 and 6.1.3.

My guess is that the majority of implementations (all?), will get the time information from the GNSS signal. Just remember that GNSS and UTC time are not exactly the same.

gabrielcox commented 10 months ago

For the full tracing of what's required for FAA Part 89, see this part (89.515):

§ 89.515 Production requirements for unmanned aircraft without design approval or production approval issued under part 21 of this chapter.

Except as provided in § 89.510, after September 16, 2022, no person may produce an unmanned aircraft for operation in the airspace of the United States unless—

(a) The unmanned aircraft is designed and produced to meet the minimum performance requirements for standard remote identification unmanned aircraft established in § 89.310 in accordance with an FAA-accepted means of compliance; and ...

I'm calling attention to the "accepted means of compliance". Unless you plan on proposing an alternate means of compliance, the FAA has published their Notice of Acceptance (NOA) of ASTM F3586-22 (which reference F3411-22a). These do cover the concerns you're bringing up as @friissoren explained. F3586 covers the details on how to apply F3411-22a and additional steps (like compliance testing, record keeping, self-testss, monitoiring, etc.) that must be performed in order to submit a Declaration of Compliance (DOC).

Here's the link to the published NOA along with a published update: https://www.regulations.gov/docket/FAA-2022-0859/document

This will tell you the other documents you need (ASTM F3586-22 & F3411-22a) to have the full instructions on making a compliant product.