MatCat's Devo 8 Expander

I am about to soon begin working on my Devo 8 Expander, which will use the trainer port of the radio which is actually a full uart, and communicate to the radio via serial instead of PPM. I have quite a few reasons for wanting to do this, firstly it will allow me to use a 433MHz digital radio instead of it's 2.4GHz radio (I will be using RFM22B for my first prototype, then I plan to move up to the RFM23BP.), secondly I want to be able to add-on inputs, I.E. more switches, knobs, whatever.

I will be maintaining my own repo of the Deviation project and will keep it up to codebase with the addition of my code. I plan to provide support here for those who wish to utilize the serial interface for themselves once it is up and working.

As far as the hardware goes my goal is to first prototype a working setup, then I plan to actually get a really small batch of 10 pcb's made once I am happy with the hardware and circuitry. If there is any interest from anyone else I will make them for sale, but my primary purpose is the piece of hardware I want to FPV how I want. The Deviation firmware offers a fantastic platform for FPV that is not yet really tapped into, and I want to take full advantage of it, and offer to the community the benifits of what I decide to make for myself.

A friend of mine also plans to implament APM serial protocol aswell which I will keep in my repo.

Hi Matcat,

Seems very interesting. I'd like to see what you can implement and do with such a mode, as it seems to open a lot of possibilities.

Indeed, one thing I noticed after following a few other threads is that a simple hardware mod will be needed for this to work properly. The trainer jack has both RX and TX of USART 1 going to it, but it's setup with a switch that turns RX line high when something is plugged in to act as a sense line, to do this one would have to snip a wire and re-solder it elsewhere to get it to work properly, which I will show pics of soon.

Here is a pic of the mod to get full RX/TX USART working on the trainer port, what I did was cut the RX line and solder it to one of the unused pins of the 3.5mm jack. This gives unobstructed RX/TX lines to the port.

I doubt the STM32 is 5v tollerant so I am waiting on some 74HC4050 buffers so I can use them as TTL level converters before I go hooking up any external MCU to do a full serial test.

Actually after doing some research it appears the STM32 is 5v tollerant on the USART, hooray!

Been a minute since I posted here, WOW I am surprised that no one really has shown any interest. At either rate I am still working on my goal. I did build the prototypes but I have not yet messed with any programming for them yet, one thing I think I will do is wait until I print some PCB's up which will probably happen in the next month or two. I have both boards designed and just need to buckle down on them to prepare for revision 1 to be made.

Hi MatCat,
I am definitely interested in your work, but I did not see much progress for a longer period (your repo seems also unchanged) so I thought you have dropped this project.
It's good to hear that I was wrong.

Yeah I haven't touched my repo in a minute, actually been busy building up my FPV Electronics company, and I am just about ready to start writing the firmware for my custom UHF RX/TX system, which will be the basis of the hardware to interface to the devo, once I have that working Devo code is next to come.

Just wanted to let whomever is watching know that I am finally ready to tackle some code for this project.

I plan to start off with by adding a new Protocol called Serial. This will turn the 3.5mm jack into a full UART1 Serial port. To get full bi-directional capability the hardware mod will have to be done as specified above, otherwise it will still function to output data.

The first goal is to get the channel data out, which my UHF TX will read and formulate into a proper packet for the RFM23BP.

The second goal is to get full bidirectional communication so that I can use external inputs and pull them into the Devo mixer as new channels.

The third goal is to implement a custom interface for configuring the UHF links, both TX and RX, and any other hardware peripheral support I want.

The fourth goal is to get telemetry input working on this link too (since my UHF system is fully capable of bidirectional communication, why not?)

Here is a quick sneak peak of the UHF RX/TX (RX is the bigger one wit no antenna ).

Made some good progress today, I got the Serial protocol added and most of the logic, all seems to be working fine in EMU, now to just give it some serial writing for hardware and test it.

I need to get my repo caught up, I will work on doing that tomorrow.

Even better progress today, got serial data flowing out. I did decide to do another mod to my radio, I don't really like the audio jack so I soldered on a servo connector directly and fed it out the back so I cam plug it in directly to the UHF Radio / Expander.

I got the actual USART code in and working, verification via FTDI on the PC. I created a new function called USART1_Packet that can be called to send data to USART1, for now it's a bit hardcoded but I plan to put together a little serial API to make it easy to develop serial protocol additions.

Got the code setup at bitbucket.org/MatCat/letsfpv-deviation

PhracturedBlue wrote: Just so you know, each tx has its own quirks with respect to the output trainer port. The Devo8 doesn't connect the Rx pin, but if I recall, the Devo10 and 7e do. The devo12 and x9d don't have the trainer connected to a UART at all and use GPIO/timer pins for it. With 2 wires, I'd probably recommend i2c instead. It is easier to implement on a GPIO pin, and can achieve much higher throughput (enough to overcome that it is half-duplex). You'd still need to modify the Devo8 of course. Or you could do it via SPI like every other module we have (though that probably involves mounting a port on the case since I don't think your 433MHz system will fit inside.

Is I2C broken out and easy to get to? The RX isn't hooked up to the trainer port but it's a dead easy mod, I have details posted above on that.

The default 115k baud setting of the USART is more then adequate, I currently am running packets every 30ms which is only so long because I needed enough time to do a lot of serial debugging from the UHF board. My initial protocol will probably run somewhere between 10 to 20ms giving 50 to 100 packets per second.

I chose the serial port mainly because it is the easiest to access as is. I don't even have any serial RX code on the radio yet but I do plan to.

My module is nor going to be inside the radio, externally mounted like most UHF radios.

Remember too there is more to this then just UHF, one of the biggest functions of this board is it's analog and digital inputs. I am going to do a full integration so that external channels can be brought into the mixer, it will also support on-board mixing too. This allows for an extremely flexible extended channel setup, of course one of the main advantages of this is to mix switches into single channels so remove as much packet bandwidth overhead as possible, also to allow channels to be extremely low bit rate to also compact packet size, I.E. you could make your main stick controls highest bit size, but your knob for flaps could only be 4 bit accuracy.

Of course computer software and through-radio interface will handle all of the UI aspect for on the board. I will probably design up some boards that are not UHF, but do connect to the radio to expand the analog and digital channels, as well as an RX expander that can use a few channels to demux out. That probably won't happen for a minute though, my primary goal is the UHF radio mainly since that is going to eventually get developed into a product in it's own right that will be able to work separately of Deviation (hence computer interface for settings as opposed to just Devo interface).

By the time I am ready to offer up a Deviation targeted hardware set I should have the code base in place to be able to take advantage of it. I dunno how much of the userbase would be interested in such a thing, but I imagine a handful of people would be interested.

I am not far from having this working actually, I had the concept working in Arduino but yuck that codebase is horrible, so for the last week I have been properly writing the firmware in standard AVR LIBC (The board uses Atmel ATMEGA1284p). I do have a basic packet protocol working, now I am in the middle of whipping up the library to drive the UHF radio module, which I should have a TX text working sometime tonight hehe.

Hi MatCat

Can I just chime in. I am very interested in what you are working on here. I have just deviation'ed my devo8s for the first time and I have a camera gimbal installed on the quad that I am controlling with it. To have a separate unit that can be commanded by a second operator or that can use input from another set of controls would be very interesting to me.
Presumably the dsc can take an input from the mic out of an iPhone or computer?

Having said that, I also like the idea of a unit that I as flyer can use to finesse the control of the camera gimbal (rather than using the trims).

Keep at it!!

cheers

Dom

It is coming along, I did do a test flight with the prototype hardware, but there is still plenty of work to be done, I am working on another revision of the hardware which I should have on order in a few weeks.