💾 Archived View for benjaminja.com › log › 2018 › 02 › 03-rcprotocol captured on 2024-05-26 at 14:47:34. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2024-06-16)

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

rcProtocol

2018-02-03

#Wordpress

#Drone

🔡 Github Repository

📕 Library Documentation

rcProtocol (working title) is a protocol for communications between transmitters and receivers.  It is not for receivers communicating with flight controllers.  I don’t intend this to become a standard, though that would be fun;  I intend this to be a niche system for hobbyists who want to make their own remote system without going through the effort of creating their own communications protocol.

Dependencies

There is only one dependency for the library, which is an [RF24L01(+)] chip with the [TMRh20 RF24] library.

RF24L01(+)

TMRh20 RF24

I have tried to keep my code system agnostic, so you could theoretically run rcProtocol anywhere RF24 can, but I can’t make any promises.

Capabilities

rcProtocol allows remotes to be paired with more than one receiver.  Each receiver has its own settings that are sent to the remote when paired.  There are only simple radio specific settings at the moment, but I plan to give the receiver control of which channels are sent.  You can read all of the settings in the documentation [here].

here

There is a max of 15 channels that can be sent, this is with full 32-byte packets.  I might add the ability to send up to 16 unique channel packets, upping the theoretical channel maximum to 240 channels, though I would not recommend that.

Telemetry is also possible, by populating ACK packets.  At the time of writing (V0.3.0), You have to manually parse telemetry.  I plan to have standard stuff: Battery, Current, Temperature, RPM, Location, Alarms, etc.

An emergency reconnect system is enabled, making it so that if a board gets reset, it will automatically reconnect to the last device it was connected to before it reset.  This is useful because of the way the transmitter/receiver connect, doing its special handshake would not work in a power failure as it would take too much time.

Usage

The protocol has two main classes: DeviceProtocol (rcDeviceProtocol.h), and RemoteProtocol (rcRemoteProtocol.h).  The two classes mirror each other in functionality as they are for the receiver, and transmitter respectively.  They both have the same functions but are implemented slightly differently.

To pair with each other, both need to call pair().  The remote broadcasts its ID onto a pairing channel.  The receiver will collect this, then start broadcasting its ID, as well as settings.

To connect, they both have to have paired with each other and call connect().  The receiver will broadcast its ID on the remote’s channel.  The remote will then check if the ID is correct, then send a confirmation/denial response.  They will both load the settings, and test if communication is still possible.

Once they are connected, the remote is free to send data to the receiver.  Though currently, update() and disconnect() are the only communications the remote can send.

There are two other classes: RCGlobal; an internal class used by DeviceProtocol and RemoteProtocol, and RCSettings; a class that holds the settings for communications

🔼 Log - 2018

đź“­ Message me

đź“ťOr mention this post