I'm working on a bidirectional radio system based on RadioHead/RFM9x for a rocket/ground control pair.
Rocket and ground control are equipped with RFM9x radios. I am using RadioHead on the rocket ATMEGA2560 telemetry computer and a CircuitPython Adafruit library on the ground station.
The issue
Both rocket and ground must be able for information and transmit information. For example, the rocket sends sensor updates every second, and ground might send commands such as "abort mission". This bidirectional aspect is critical.
I had been using this naive approach on both sides:
loop:
[send any messages we want to send...]
[send ACKs if not ACKed, +- 200 ms]
[turn the receiver on and poll for messages for 2000 ms...]
done.
The issue is that transition events, especially things like user commands, happen randomly and sometimes do not align with the "listening window". For example, a user may press "ABORT MISSION", but the message may be sent while the rocket is actively transmitting. Since the rocket is transmitting and the ground is not listening, it does not ACK the rocket's message and so communication is completely stalled.
I am stumped from a systems design perspective. How do I work around this in a system where the radio may only be listening or transmitting at any one point?
I have thought of a "master/slave" system where a node is designated to only ever listen and reply when specifically asked for information (then, the requesting node knows to listen right after requesting). However, this seems to reduce data rate. Is there a better way?
You need full duplex instead of half duplex. Two radios, one listens, one talks. You'll need antenna isolation and 2x of most everything. Your parasitic load just doubled along with your power budget.
Hmm. Full duplex is a nightmare as making sure that your local transmitter doesn't deafen the receiver needs very good filtering. The more obvious approach is TDD where the two ends transmit alternately. One end could ping and the other responds back with a ping, and if either end has data to send the ping contains a request to send and the ack includes permission to send. Or one end can be the master and define time slots where the other end can respond ("slotted Aloha"). Don't try and invent the wheel, try to find something off the shelf. Wi-Fi might be a good start.
Its IRIG (telemetry) data. Its coming NOW like a firehose. You gotta gulp. But the control side can be slower as it should only have to send an abort signal (OP: are you wanting steering? or just "abort"?) You put the radios on widely spaced frequencies and a metal shield between tx and rx.
I don't need to control the rocket directly, as in steer it, if that is what you mean. I only need to send basic packetised commands such as "abort mission".
Full-duplex and half-duplex is exactly the terminology I was seeking. We are launching at a scheduled competition in a month so full-duplex is definitely impossible to implement on the PCBs hardware-wise at this point and your point about power budget/etc is definitely absolutely correct.
I'm not really trying to re-invent the wheel. Wi-Fi doesn't work because we're talking long range (9km LoS) and very high velocity. Not prime Wi-Fi conditions.
The master time slot idea sounds great, I will look into it further
No, they are not two seconds—this was just to illustrate the concept of the main loop. And no, abort is not the only command. I had given it as an example of the short, discrete commands that must be sent from ground as opposed to continuous steering, for example.
