💾 Archived View for benjaminja.info › log › 2018 › 02 › 23-rcprotocol_update captured on 2024-05-10 at 10:50:13. Gemini links have been rewritten to link to archived content
➡️ Next capture (2024-06-20)
-=-=-=-=-=-=-
2018-02-22
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.
As the name implies, Constant communication allows for communications to be sent constantly. In order for CC to work, both the receiver and transmitter call an update function during its program loop. The transmitter is restricted to run update() at a certain interval designated by the receiver’s settings. While the receiver can run update() as often as it is called.
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.
Telemetry is sent by the receiver through ack-payloads. At the moment, Telemetry is sent every time a packet is received. I plan to make the frequency of telemetry packets set by the receiver settings.
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.
For a normal receiver, if the receiver were to reset for whatever reason, there wouldn’t be much of a problem, since the transmitter will not care if it disconnected for a bit, but with this system, if that were to happen, it would have to go into connect mode, and do its handshake to make sure they can connect. This is not good, so if the remote, or receiver is to reset while connected, it will immediately consider itself to be connected with that device, and check if the other device is listening.
I think that the library is very close to being finished, but there are still things yet to do. One of the things I want to do is create a container class for the channels similar to the telemetry class.
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.