...
Introduction
LOS Link is
...
A PPM driver has already been implemented
CrossFire: uses UART
...
There must be a method to know which protocol your using. Since ZP software should care about which protocol we are using, this should be handled within LOS.
There will be an accessible .h file that will have a bunch of defines letting us know which driver to use (all these drivers should output the exact same thing so they can be easily swapped in and out by LOS interface).
The defines can be used with ifdef preprocessor directives to determine which part of the code should be compiled to allow the use of the proper driver.
...
ZP software shouldn’t even care about which peripherals are being used or the pinout. That should all be handled by the interface/driver.
This will also be found in the same accessible .h file and will hold all the configuration data such as which pins and peripherals are being used for each driver.
Inputs:
Initialization of the LOS Link would require no inputs from AM. LOS link will look into the plane config file to determine the number of channels being used.
LOS Link would not require any inputs when using the interface
Outputs:
The channel percentages
...
the interface that provides RC channel data which is how we figure out the stick inputs from the RC controller. Traditionally, PPM (Pulse Position Modulation) is used to but there are other methods of communicating this data such as TBS CROSSFIRE or SBUS that we are looking into.
Data
The data coming through LOS Link is quite trivial, all one would want to know is the percentage of each RC channel and a signal strength. As of Nov 24, 2022, the data structure returned by LOS Link looks like the following:
| Code Block | ||
|---|---|---|
| ||
typedef struct LosLinkRx_t{
uint8_t rssi;
uint8_t rx_channels[NUM_RX_CHANNELS];
}; |
Where the rssi represents the signal strength and the rx_channels array holds the position of each input from the RC controller, both represented as a percentage form 0-100%. NUM_RX_CHANNELS is a const that holds the number of active channels.
Using the Interface
LOS Link is not too complex as it essentially directly calls the appropriate RcReceiver driver on each of the active channels, based on what was configured in the config.h files.
LOS Link, along with all the other LOS interfaces, is implemented as a singleton, meaning the only way to use the interface is to call the getInstance() function to retrieve the singleton instance then make the appropriate calls.
Currently, the only public function exposed from LOS Link is LosLinkRx_t getRx(uint8_t instance) where instance is the index of the RcReceiver in the array holding all RcReceiver instances in the config.h and it returns the data structure defined above. instance is an optional parameter as is defaulted to index 0 because for a long time, there was only ever 1 instance of the PPM driver, but that may change in the future when we want multiple stream of RC channel data from different sources.
Related Drivers
LOS Link only uses 1 set of drivers, RcReceiver.
RcReceiver is the base class that encompasses the related derived classes, currently only PPMChannel but possibly a CROSSFIRE and SBUS class in the future. The main virtual function that is to be implemented by all RcReceiver derived classes/drivers is the uint8_t GetResult(uint8_t channel) which should return the percentage of the RC channel index passed in.