💾 Archived View for benjaminja.com › log › 2018 › 02 › 22-rcprotocol_update captured on 2024-06-16 at 12:27:50. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-05-26)

🚧 View Differences

-=-=-=-=-=-=-

rcProtocol update

2018-02-22

#Wordpress

#Drone

It has been far too long since the last update, near the end of October.  Since then I have been able to make a bunch of improvements.  When I last posted, the remote could only pair and connect,  now constant communication works, telemetry works, the remote even reconnects after resets.

I have also been able to fly my quad with the remote.

There are several transmission types, dictated by the first byte in the packet. For example, 0xA0-0xAF are reserved for channel packets,  and 0xC0 is for disconnecting.  The receiver processes all of the packets in its update(), while the transmitter will send certain packets from different functions, such as the disconnect packet.

I haven’t yet merged this to master yet, but telemetry has its own container class now.  It manages all of the bytes in the telemetry object into the proper data.  There are a bunch of things that can be sent through telemetry, and each needs its own implementation so the remote can enable/disable specific telemetry channels it uses. This allows for more efficient telemetry packets.

The telemetry class so far as only implemented, Battery Voltage, Current, Temperature, rpm, GPS, and alarms.

I want to have the channels be more standard so that the receiver can request certain channels, and the transmitter will know what to do.  I think this can be done by recreating the Telemetry class.  The remote would tell the Channels class which channels it can provide, and the receiver settings will contain information about which channels it needs.  When the two pair, it will check if the transmitter has the channels the receiver asked for.  If it works, then they will pair as normal, if they don’t match, a warning will be sent to the transmitter’s firmware, and it can decide whether they can pair and if they do, which channels to send instead.

I think this is one of the big things that need to be done before the library can be considered finished, but there are still a few small things that I would like to implement, like signal strength, and other things that I can’t think of right now.

đź“­ Message me

đź“ťOr mention this post