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
Uwe Gartmann
Comments
helping developing: How can I contact you?
@Leon: Very nice modification you made. But i use the plane outdoors. There is no bluetooth device having that range. The 9bit data is a very very clever idee to split commands from data without sending additional datamarkers or protocoll overhead. Once programmed you dont care about it.
@ionut: Bigger planes are smoother in motion than smaller ones. I choosed this plane because there are plenty of space installing the APM/IMU. And a saleplane flies itself stable without active control. Once the software gets close to the end, i will check again for a smaller plane.
That's exacly what I have done on my UAV. An indoor UAV with just 1 bluetooth connection for all usages. I just added a "checksum" for the safety. You can imagine your own protocol!
You can see the modification I made on my radio here:
http://heli.bot.free.fr/pages/image/imagepage10.html
Leon - French hobbyist
Thanks for sharing this!
I'm also working on it to use it how i want.
I think it's not a good idea to share this with public.
If you have read the post's in some forums, they always say
that they won't share there code's because they are frightend at JETI (the Company).
But if you want, I'll help you to implement this!
mfG