Hacking the I2C interface of Spektrum DX and AR ?

[Arthur P. 0]

In this thread http://www.rc-cam.com/forum/index.php?showtopic=1239 Mr.RC-Cam wrote:

The Spektrum transmitter has a small daughter board in it that contains the Unigen RF module, a voltage regulator, and a host microntroller. The microcontroller is used to measure the PPM signal from the transmitter's encoder and convert it to a three-wire (I2C) communication signal so that it can talk to the Unigen module. ....

This is a great thread !!! And I believe it confirms something I already considered looking at the transmitter chip: I2C communication. That brings me to my two questions:

1) On the transmitter side, could you actually put microcontroler between the PPM front end part of the transmitter, and the transmitter chip, bypassing the current PPM to I2C conversion step, or between the current PPM to I2C conversion step and the transmitter chip. I could see possibilities of actually adding some channels on the digital side of things which normally would not be possible on the PPM side. E.g a 4x 4-position switches packed into a single byte value, and two 128 step sliders with a yes/no switch packed into two single byte value, bringing the total for a DX7 to 10 "byte value channels" but 15 true channels ;=)) Would be very nice to have some additional controls for e.g. camera tilt, zoom and mode, and for choosing from a series of automated flight modes in a GPS and IMU capable VTOL camera platform (i.e. a quadrocoptor).

2) On the receiver side could you actually export the I2C signal from the receiver chip. If I understand it correctly there are two receivers, both of which will be generating an I2C stream which the current processor in the receiver most likely compares, rejecting streams with an incorrect checksum or some other check? Exporting the I2C would greatly simplify interfacing the Spektrum Rx into a microcontroled flight system. And it would of course be unavoidable if you wanted to decode the extra channels inserted into the transmission as per question 1).

Edited June 30, 2007 by Arthur P.

[Daniel Wee 0]

Definitely a potentially interesting idea - and it should not be too hard to hack since it's I2C. It's a simple matter to capture the data stream for analysis. The question is if the actual transmission layer protocol will support the proposed additions. The other point of interest for me would be to inject data directly into the I2C stream - for example, to expand on JR's limited slaved channels to facilitate head tracker usage.

Daniel

[Mr.RC-Cam 127]

If you change the Tx firmware to expand the channels, then the Rx firmware (and hardware) would need to be modified too. It might be easiest to skip reverse engineering the existing protocol. Instead, just define your own from the ground up.

[Arthur P. 0]

Is the microprossessor defining the protocol, including the binding, or does the transeiver just accept the data stream and package it? If the latter, then I would assume inserting more bytes into the stream before it gets packaged shouldn't be anything the transeiver really cares about as it is infact operating very much like a modem.

I guess the answer form this would have to come from someone capturing the I2C stream going to the transeiver both during the bind process and during normal transmission and figuring out how many bytes are currently being sent over the I2C link to the transeiver.

I-ve recently ordered a USB to I2C converter. Will be interesting to see what can be done with that.

Of course if all you use from the Spektrum RX and TX are in fact the transeivers, you could wonder whether you might not go all the way on the TX side and replace the current analog/PPM components by direct A/D conversion to a new microcontroler.... Of one you couldn't just order those transeivers separately, buy a cheap TX housing, and modify that to be completely digital, including with a nice little colour LCD from Sparkfun or maybe a touchscreen to handle some of the additional controls. Digikey seems to have them for USD 8.40 to 10.00 a piece (http://www.digikey.com/scripts/DkSearch/dksus.dll?Criteria?Ref=67214&Site=US&Cat=34407381) and the opamp for the TX, type SiGe SE2526A for USD ?? (haven't immediately identified a source for this component).

[Mr.RC-Cam 127]

Is the microprossessor defining the protocol, including the binding, or does the transeiver just accept the data stream and package it?

The Juno RF module does the DSSS encoding, but the high level R/C protocol is handled by the Spektrum microcontoller. Attached is the Cypress data sheet to the DSSS RF encoder that is used in the Juno Module. The Juno Module data sheet is on the Unigen site.

JR_Spektrum_Juno_data_sheet1.pdf

[Kilrah 2]

I'd say the same, instead of hacking into the existing stuff, having to figure out how it works and how to modifiy it to do what you want will be more complicated that getting a pair of radio transceivers and directly design your own protocol in a microcontroller on each end.

[Arthur P. 0]

I actually came accross a Zigbee transeiver (http://elmicro.com/en/zebra.html) which is claimed to have a 2 km range in the open (spec sheet actually says 500m) with the same range in each direction for a reasonable price (Euro 59.00). Wonder whether that might be an interesting alternative. Haven't really looked into Zigbee at all yet.

Coming back to the Spektrum, I haven't really looked at their processor, but it is rather logical that they are using that for their part of the protocol. I think I will try to figure out what goes on between that processor and the transeiver. I could see some value in either sticking with their protocol for e.g. binding-- as that could still allow using their receivers, or mixing their recievers with your own. I.e. if you're going to replace their front end and processor with your own and if you have sufficient processing power and memory why not create a Tx which can talk multiple languages ;=)

A completely different alternative for "doing your own protocol" could be this: http://members.aol.com/hprinzler/433rcs.htm or this http://webx.dk/rc/uhf-link2/uhf-link2.htm

[Arthur P. 0]

Checked out the RX board of the AR7000 with a Parallax USB Oscilloscope today. It is connected to the mainboard in the AR7000 main unit with three pens. The first two (counting from the side) are PWR/GND. The third is definitely a digital signal line with a burst of signals which is roughly 20ms long and close to the PWM output on servo connector 1. Probably just a single serial line, not I2C or SPI.

Most likely the larger chip on the bottom board compares the bytetrains from both RXs and then transforms the correct bytes to PWM signals for the servos.

Most interesting is however the output on the power connector of the receiver which shows a very short burst of 7 spikes within about 700 microsecond, each spike being about 15 microseconds long. This is not a burst of bytes. And it shorter than a normal PPM signal would be. It is again closely in sync with the first PWM output. Here's a poor quality pic (sorry). Any suggestions?

[Kilrah 2]

I'd say it's some serial line they've implemented for configuration, flashing or whatever at the factory.

[Mr.RC-Cam 127]

Can you do anything to make the pulse train change? Such as move sticks, turn off Tx, move Tx further from Rx, etc.

BTW, you only show a short sequence from the output. Are they all identical, or are there others after it that are different?

[Arthur P. 0]

All identical and all with the same time relationship to the PWM signal. The USB oscilloscope doesn't have enough resolution to see whether there are any significant changes in any of the spikes on moving the sticks. In view of the time relationship I would assume it is some PPM type of signal, but much shorter than normal. And due to the limited resoultion of my scope I just can't tell for sure. If it is some form of PPM signal, no clue why you would want to shorten it so much as that will not make it easier to decode.

[Arthur P. 0]

Just an update. Someone pointed me to part of the UAVP schematic where separate PWM outputs of a receiver are multiplexed back to a PPM signal. In the UAVP this is done for uneven channels only, and the even channels are then calculated. But simply icreasing the number of diodes was all that was needed to multiplex all PWM outputs from the AR7000 to a single PPM signal ;=)) Here's the adapted diagram (showing only 4 diodes, so increase to 8 for an 8ch receiver), and the rather sloppy looking but finished product. Of course the real test will be whether the mikrokopter controler will be able to correctly read the signal.

[Arthur P. 0]

The finished PWM to PPM multiplexer .....

Edited July 23, 2007 by Arthur P.

[tazdevil3000 0]

AR7000 not working with UAVP , check serial ppm signal with a scope and you will anderstand why

[Kilrah 2]

I wonder if that will work.

With uneven channels only, there are times (when even ones are active) when the signal will be left high. However with all channels connected each time one will go low the next one will go high at the "same time", driving the output low again leaving no time for a decent high level state. The uC might not be able to see a few ns long pulse, at least it's not standard PPM where the high pulse is about 200us...

I'd simply grab the PPM signal before the decoder in the RX personally.

It of course won't work with more advanced receivers (PCM and some 2.4GHz ones) that output all channels simultaneously.

Edited July 23, 2007 by Kilrah

[Arthur P. 0]

I wonder if that will work.

I'd simply grab the PPM signal before the decoder in the RX personally.

It of course won't work with more advanced receivers (PCM and some 2.4GHz ones) that output all channels simultaneously.

Point with the Spektrum 2.4GHz system is that there is NO PPM signal anywhere in the receiver. There is in the Transmitter but that doesn't help. We'll see if this will work. On the scope I have a nice PPM train.

I never did understood why the UAVP wouldn't be able to work with the AR7000 bu does work with the AR6000. The receivers themselves are identical. There are only minor differences in the microprocessor's programming after the receiver. Only thing I could imagine was an unusual sequence of the channels causing problems.

We should know by the end of this week. My MikroKopter controler is alive. The jaw gyro or amplifier isn't working properly, so that's a first point of attention. But after that the next test will be to see whether I can get it to read this "remuxed PPM" signal properly. And I believe the MK software allows me to assign channels to functions at will, independent of the Tx.

[Daniel Wee 0]

I'll hazard a guess as to why it doesn't work with the AR7000. It is possible that the AR7000 outputs the PWM pulses simultaneously on all channels, whereas the AR6000 outputs them on their original PPM timeslots. This allows the AR6000 output to be multiplexed easily, whereas on the AR7000, that simple OR-ing scheme will cause all the different channels to step over each other, product basically garbage.

To get it working would requre re-sequencing the outputs of the AR7000, or better yet, have a small controller capture the simultaneous outputs and multiplex it together to output a PPM signal.

Daniel

[tazdevil3000 0]

This is a solution to resynchronise pulse to do a valide ppm trame , but it better to use Xtrempower system or dx6 with Uavp

[Kilrah 2]

Point with the Spektrum 2.4GHz system is that there is NO PPM signal anywhere in the receiver.

Of course not. I meant doing that with a classic PPM RX, not with a 2.4GHz device.

I guess Daniel is on about the 7000 being more high-end and thus having the simultaneous outputs (they wanted to advertise it for pro heli pilots too, and that's pretty much a must for them nowadays)

[Arthur P. 0]

I-m not sure how they tested the AR7000 with the UAVP, but the PWM outputs are definitely sequential with proper interspacing to remux with this simple circuit. As said before, on the USB scope my little circuit shows a nice little PPM pulsetrain. Connected the circuit to the mikrokopter controler today and that seems reasonably happy with it. I couldn't find the aeleron channel when connected but when testing later with the USB scope I found that one connector to the RX wasn't seated properly. But it does mean I still have to sort the channel sequence properly with the Rx connected to the MK controler to be able to definitely say it works on all channels. But I-m reasonably confident now that it does on all channels.

I think the problem with the UAVP is that the physical sequence of channels (simply counting from left to right) on the AR7000 may be a bit wierd. It seems to be:

1 throttle = ch 6

2 aele = ch 1

3 elev = cha 4

4 rudd = ch 7

5 gear = ch 3

6 aux1 = ?

7 aux2 = ?

[Arthur P. 0]

Although superficially the PWM2PPM multiplexer seems to work I kept having problems getting the MK to see all 7 channels. Ik kept either not seeing the roll (1) or jaw (7) channel. I even used an additional resistor and transistor to reverse the signal, assuming it might be due to the signal being inverted. However, that didn't help. Then I did some further research.

Here is the scope image of my signal. 7 nice channels, don't you think ???

But here is wat a real PPM signal should look like. Notice the difference ??

My signal misses the opening 0.3msec spike. And seemingly the MK wants to see a full 0-5-0V transition to trigger the timer. So with the signal straight out of the converter it sees channels 2 through 7 but thinks these are channels 1 through 6. And with the inverted signal it sees channels 1 through 6 as 1 through 6, but doesn't see 7.

Now here's the xxx USD question: how to get that extra little spike into the signal (or get the MK folks to solve this in software). It would be ideal to be able to use the 2.4GHz system as it is highly probable --if not certain-- that MK's will often be flying in urban environments.

[Mr.RC-Cam 127]

Of course the ideal fix would be for the MK host controller to accommodate your trickery. The second best fix would be a external MCU to do that. As a last resort, some additional logic on top of what you have already have done would be needed. Hint: Use a non-retriggerable monostable on-shot to recreate the missing pulse separators.

[Mr.RC-Cam 127]

Did you solve your PPM problem? Do you still need help with it?

[Arthur P. 0]

Not yet. And not being a real electronics guy (user YES, programmer to some degree, designer NO), I really have no clue when I read "Hint: Use a non-retriggerable monostable on-shot to recreate the missing pulse separators."

I did send an email to Spektrum asking them whether they can conjure up a solution. As I tend to fly in urban environments --I live in one of the most densely populated areas of the world, and saturated with RF-- I would really prefer to stick with the Spektrum system and not have to revert back to 35MHz. So any help, such as a quick and dirty drawing of what the above would look like and some typical part numbers/names/types, would be greatly appreciated.

Edited August 1, 2007 by Arthur P.

[Mr.RC-Cam 127]

If you run out of obvious solutions, and don't mind rolling up your sleeves, then here is what I was thinking: Just use a 74HC221 one-shot IC to insert the missing separator pulses. The circuit below shows a proposed solution.

I have not tested this. Plus, I am flying a bit blind and would be more comfortable if I had spent some time with your system on a o-scope. So, there is risk that this will need some tweaks (or worse yet, may not work well at all). But for the cost of a cheap IC and some time on the IC breadboard, you can easily find out.

You'll need to download the IC's data sheet. The schematic does not show the IC's power pins, so be sure to connect them. Don't forget a .1uF bypass cap directly across them too.

1/2 of the IC is used to create the 300uS pulse separators. Using the data sheet, choose a RC (resistor/cap) combo that will give you 250 to 300uS. The IC's other half is used to add a final separator to the PPM stream. Choose a RC combo that will give you 10-25uS. The pulse times are not critical and you can fudge them a tiny bit.