This project has started with the arrival of the APM / IMU boards in June. Soon I realised, that APM will be more than just copy the software to the board and go flying. From my experiences with microcopter projects, I recognized sometimes the lack of monitoring status information and configuration capabilities at the airfield.
In Europe, most people in RC community are talking about telemetry. Today, there are a couple of manufacturer selling transmitter and receiver with this feature. One manufacturer is selling products with a public known protocol: JETI.
JETI does not sell the complete range of RC equipments. They sell modules or kits for a lot of transmitter used today, receivers and sensors. My transmitter, an older MPX 3010, has been modified with a JETI Duplex TMp transceiver module. This module can be expanded with the JETI-Box Display. Its just a dump display with 4 buttons that acts as a display/input device for a wide range of products from JETI.
Connected to the transceiver, the JET-Box can display data from the tranceiver or the receiver (over air link). If you connect a sensor to the receiver, his data can be displayed as well. With the JETI expander, you can connect more sensors. But the most advantage is, you can configure settings on all devices connected. No need to have a PC with USB cable with you.
Over a couple of weeks, I wrote a library for the communication between APM and the JETI-Box. It acts like a sensor connected to the JETI receiver. The JETI-protocol runs at a baudrate of 9600. It sends 34 bytes per frame to the receiver. Unfortunately, it uses a unusual frametype of 9O1 (9 databit, odd parity, 1 stopbit). Using the FastSerial lib was not possible, so i wrote my own code.
The concept is pretty straight forward. The JETI-Box sends every 180ms a byte containing the button status. When this byte is received, after a 10ms delay, the data for the display is send back. The JETI-Box will send the buttonstatus again, after 10ms - we send updated display data like before.
One of the most problem was the lack of free timers to implement a 10ms delay. A check on the Arduino library lead to a solution. Timer0 is used for the function millis(). It is configured as an overrun timer and therefor the timer0_overrun_interrupt routine is occcupied by Arduino. The other two interrupts (compareA, compareB) are still available. The solution is to set the compareA value to 128 and use this interrupt to run a routine handling the 10ms delay. Please look at the code
for more details.
Changing parameters inside APM is not implemented at the moment. This will take one or the other week.
Project documentations could be found here, pics are here