As can be seen by the video, when one of the command keys is pressed the corresponding led lights up and the TX packet sequence changes to the new command. This is the same with changing receivers where only the receiver number in the sequence changes.
The sequence output is usually much faster, but for the sake of the demo it was slowed down.
** Explanation Below **
USART by itself would not be enough to send
reliable data transmissions via 433 MHz modules. Especially to 2
The solution is to send multiple bytes via USART. One byte for syncing, one
for the receiver serial number (in this case 1 or 2) and the
command (front, back, left or right).
The TX and RX AVRs both have data buffers that are used to
store the multiple bytes. When a command is chosen on the TX side,
the buffer is filled with the sync byte, serial byte and command
byte. Then sent incrementally via TX interrupt.
This is the same with the RX AVR, with the RX data buffer being
filled up incrementally with received bytes.
Initially I did have some trouble using this method, especially with
making sure the AVR on the RX would read the data in the proper
To ensure that the data received would be put in the data
buffer in the right sequence (sync, RX serial number, command), I
made it so that the RX will only fill up the data buffer if the
first thing it receives is a sync byte, else reset the RX data
buffer index to 0 and keep on waiting for the right sequence.
While debugging the RX via serial terminal, I have noticed that the
bytes being received appear in the wrong indexes. This is due to the
fact that sometimes bytes are sometimes received out of order
(i.e. command byte read first then stored or serial byte).
However, I noticed that whenever a sync byte is the first byte to be received,
every other byte is in the correct sequence. Therefore that is the
condition to ensuring a proper data transmission.
This may not be the best practice especially if I am planning on
sending more and more bytes as a packet. Receiving the sync byte
first may not guarantee that everything else will fall into sequence
however it is the best solution I have for now. Will develop it more
Also, I am planning on changing the data type sent from char to
bytes. Char was used purely for debugging purposes.
For a char data packet, s represents sync, 1 or 2 represents the
receiver number and n,f,b,l,r represents neutral, front, back,
left, and right respectively. This can be seen in the video of the initial test.
For interfacing the AVR with serial, an FTDI232 board module was used.
To manage sending commands to TX AVR via keyboard I initially tried
to use the serial terminal directly by inputting characters
in it. However, I have trouble with continuous input, when I hold
down the button, this does not register in the serial term and treats it
as 1 press, instead of a continuous press.
Therefore I decided to use python and the pyserial and pynput
modules. This allows me to not only send multiple bytes to serial
while holding a down button, but also it allows me to input keys
without having to be in the serial term window due to pynput.
Using python also allowed me to later change the input keys from f,
b, l, r (corresponding to front, back, left, right), to w, a, s and