er9x is the best known firmware. It has a superb range of features and is well supported by the community. Well worth trying out.
I'm working on getting er9x to emulate the "Flip" button on the original transmitters that come with the Syma X1 and the WLToys v949. I think I'm almost there, but I need a bit of help.
A bit of background: These cheap toy-grade quadrotors are compatible with the 9x using the original FlySky module. They will bind to it, and with the right channel setup basically work great.
There is one thing that doesn't work: the original TX has a separate button that initiates a flip -- you hold down the button and push the collective stick, and it flips in whichever direction you push the stick. Bit of a gimmick, I know, but it's kinda fun.
Of course, this seems a lot like a 5th channel. The first thing I tried was binding the original Syma transmitter to the 8 channel receiver that came with my 9x, which told me that something really odd was going on. The "flip" button made the PWM pulses output from channel 4 on the receiver go from the usual 1-2ms to over 9ms.
My next trick was to put a logic analyzer on the pins that connect the RF module in the Syma TX to its mainboard. I was able to decode the SPI protocol driving the RF module, and I determined that what the button really does is set a bit in the high order nibble of the PCM pulse width (specified in microseconds) for channel 4 (i.e. does a logical OR with 0x2000). This fits with the pulse width I see when I bind this TX to the FlySky RX, so I think I'm on the right track. I did the same logic analyzer trick on the WLToys TX, and it seems to do something similar, but it sets two bits (0x3000). Since the rudder on the little quad (which is on channel 4) doesn't go wonky when I press the button, I can only assume that they're decoding the PWM pulse width and lopping off the high bits before they send it to their control loops, and using the high bits like a separate channel that's just on/off.
I've tried building a version of the er9x firmware with a hack that makes it emulate this behavior (specifically, I put some logic in pulses.cpp:setupPulsesPPM() so that if the protocol is set to 4 channel ppm and the mix for channel 5 is > 0, it sets the bit in the outgoing value for channel 4). I've tried a number of variations, including using 0x4000 (since the er9x code specifies PWM width in 0.5us units), but I haven't been able to get the receiver to recognize it as the "flip" button.
I'm not quite sure what to try next. I don't know the er9x code very well, so it's quite likely I've done something horrible to the PWM framing or something equally bone-headed that I just don't recognize. I'm hoping that someone with more experience than I in this code (which is probably most of you ) might have some suggestions on things to try, and/or debugging tips so I can determine that what I think the code is doing is really what it's doing.
I have been a professional software developer for over 20 years, but this is the first time I've tried doing any code for microcontrollers, so general tips would be most welcome.
As the communication between the 9x and the RF module is a PPM signal, I doubt there is a way to emulate that. A 9ms slot in the PPM signal that would recreate the kind of thing the WLtoys rasio is doing would likely be considered as invalid and discarded by the FlySky module.
I have the RC Perkins Twister, which I belive is just a rebadged 949. I have sucessfully bound it to my 9X and can get it to flip very easily. They key is to go to 100% travel on that channel. If you limit to o/p to 80% say then it will not flip. I would say have the o/p limited to 80-90% and then have a switch to set 100% on the channel. Then operating the switch will flip the quadcopter. Or set the switch to allow the channels to go to 100% and it will flip in whichever direction the stick is pushed.
As it is I have all my channels at 100% and just have to be careful not to got to full throw on the sticks unless I want it to flip. Expo helps.
Not you have to reverse one of the channels (airleron if I remember, but don't quote me.
Can't wait to get to the bottom of this. Two different manufacturer's transmitter are able to work with each other. It would be grey if we can get the er9x to invoke the functionality of that button.
On some v949, the flip requires holding down the top right button. That's the reason for this topic. On other v949 and v929, it invokes turning on and off the LED strip instead.
The WLToys transmitter I have actually came with a v929, which just flips when the collective goes above a certain value, as Crashanium describes. When I bind it to the 9x, I have to cut I the limits or I end up flipping it by accident all the time. I haven't personally seen a v949 that flips based on the button, but I've heard some work this way.
The Syma I have set up definitely requires the button to flip. I have all channels set to 125% limits (by turning on extended limits in er9x), and it won't flip no matter what I do.
I to have one of the Perkins Twister Quads, right enough it works fine on the original FlySky module, but as previously stated the extra function (LEDs in this case) will not work. Attached is a Saleae Logic session grabbed from the quads transmitter. You can view the file just by grabbing Saleae Logic's software for free, you don't need to buy the hardware to view files.
It appears to be using SPI at around 700Khz and sending a lot of data for 5 channels. I would agree with Kilrah it will be tricky to get a 9x to output data to fool the FlySky module into correctly re-creating this data. What might be possible is a microcontoller that converts PPM into this SPI stream. First problem I can see is some 4 bit SPI packets in the data stream, the well loved ATMega will only do 8bit SPI transfers. Any ideas ? Do the ATTinys allow 4 bit transfers ?
#TheObstacle Can you share the progress you made in decoding this mass of SPI data ?
I was interpreting it as 8 bit transfers (ignoring the initial 4-bit transfer of 0x5, which I'm sure is important to the actual RF module, but was irrelevant to me because it wasn't changing . I was basically ignoring everything that I couldn't map to a channel, so I haven't attempted to figure out the other bytes in the payload.
If you set the SPI interpreter in Logic to 8-bit transfers, you get something approximately like this with the sticks at neutral and the throttle down (this was from the samples I took from the Syma TX, which may not exactly match yours). I've broken it down into 2-byte words, since that's how it seems to line up. Each word has the low byte first, then the high byte:
0xD6,0x05: roll channel, decimal 1494
0xE9,0x05: pitch channel, decimal 1513
0xE8,0x03: throttle channel, decimal 1000
0xD8,0x05: rudder channel, decimal 1496
0xD8,0x05: copy of the rudder channel (always has the same value as the previous word)
When I took samples with the sticks in various positions, the channels varied from approximately 1000 to 2000 decimal, which matches up with the length of the PWM pulses you'd expect to see, in microseconds.
With the roll button pressed, I see this:
0xD6,0x05: roll, decimal 1494
0xE9,0x05: pitch, decimal 1513
0xE8,0x03: throttle, decimal 1000
0xD8,0x25: rudder, decimal 9688
0xD8,0x25: copy of rudder again
If you strip the high nibble of the rudder channel, you get 0x5d8 (decimal 1496), which would be roughly centered.
The samples I took from the WLToys TX had the fields in the same places, although some of the bytes I have no interpretation for were different. It didn't duplicate the rudder channel, and both transmitters seem to be able to completely control the Syma quad, so I'm interpreting that duplication as a benign bug in the Syma TX firmware. The WLToys also uses 0x3 instead of 0x2 in the high nibble of the rudder channel when the button is pressed.
That's about all I've got so far.
I believe the Syma and WLToys transmitters use the "a7105" transceiver chip (that's definitely what's on the receiver board in both quads). One of the developers on the "Deviation" TX firmware did some actual in-depth reverse engineering on another 9x-compatible TX that uses it (the WLToys v911), and talks about some of the details (including what the bits I didn't bother with actually mean) in this thread.
Awesome. Just what I was looking for. Looks like the ATTiny will do 4 bit transfers, however I suspect these 4bit transfers will be a red herring. The JPerkins Twister Quad uses the same transceiver so reading the A7105 datasheet will tell. Might have a go at it tomorrow if time allows.
Out of interest the processor in the Tx is a TG54528, and I can find absolutely nothing out about it Via Google. 24pin SOIC
EDIT: Very interesting ! PhracturedBlue has done a lot of the work with his Walkera Devo8 firmware. The A7105 does use 4bit transfers, but it can use 8 bit to issue the same commands. Initial analysis of the protocol looks like it's going to be possible.
Only possible problem is it looks like the Tx module also listens, i.e. telemetry. Although there is no indication of received data, so it maybe another read herring.
The RF module in the Syma X1 Tx is A7105 (and second number on mine is AMP27247).
Homer: Here's to alcohol, the cause of - and solution to - all life's problems.
Hmm... the Open9x firmware with ppmca, ppmus enabled let you change also something in screen 6 (OUTPUTS) - if you enable ppmca and ppmus you can modify f.e.. the ususal value 1500 to whatever.... maybe this could bring us the flip button on the 9x(r)?
ppmca allows a +/-125us adjustment, that won't get you anywhere near the 9000 or so that would be needed. And again as the communication between the radio and the Flysky module is PPM, and 9000us is totally invalid in a PPM signal there's no way to get the expected order to the module.
Ok, a little update. I have taken the FlySky code from https://bitbucket.org/PhracturedBlue/deviation/src and written a wrapper for it so it works on an AVR as a PPM to A7105 SPI convertor. I have more or less used the deviation code verbatim, this way it's easy to update any changes and deviation can benefit from any protocols we write, and vice versa.
Couple of problems I have yet to work round: The A7105 is 3.3v, at 8Mhz the AVR isn't fast enough to do all the that's required and keep up with the 1.5ms A7105 frame rate. Yes I could try dropping the frame rate but I don't want to. I could optimize the code but the big time gobbler is the deviation code and I don't want to change it for reasons already stated.
The AVR will run up to 12Mhz on 3.3v and it seems like this might be fast enough. However I think I'm just going to clock the AVR at 16Mhz, run it on 5V and find a SPI bi-directional level convertor. This will be the interesting bit..... But it will give more headroom for more complicated protocols like the Hubsan one.
Failing all this it's time to use deviation's native ARM processor, but I'm relatively unversed with ARMs so this make take a while longer.
Last edited by th9xer on Wed Feb 27, 2013 5:56 pm, edited 1 time in total.
I assume from what you've said so far that it will require some additional hardware beyond a 9x and the standard FlySky module. Approximately what hardware mods is it going to need?
By jove lads it works !!
Ditched the level converters they just made a nasty mess of my signals, used resistors and a dynamic floating/pull down resistor for the bi-directional pin. The solution uses an ATMega328 @ 16Mhz, 6 resistors, the RF module from my Twister Quad transmitter, 2 regulators (3.3v and 5v) and that's pretty much it.
Test flown on a Hubsan X4, my JP Twister Quad, (yes the lights work ! So I presume the flip button will work on the clones), and also tested on a bog standard FlySky receiver. TheObsticle you were spot on with the OR-ing of channel 4, thanks! Protocol files are very close to the original deviation ones, easy enough that anyone with a clue could port one over parrot fashion. (All thanks to, PhracturedBlue for them)
Need to do a PCB now, I'll fit the whole job inside one of these Spektrum module cases. But before that I want a look at the protocol of one of these: Nano Stik that's tomorrows job. Personal interest only.
I'll setup a Google code project for it once a schematic is done. Don't hold your breath though, I get married on the 15th of this month so as Bertrand would say "my plate is full" 2 Weeks ish maybe until I have something to show but don't hold me to it.
Cool, can't wait!
I started trying to port the Deviation code to an arduino + A7105 module but that was just before leaving for a month for work, and never got to get back to it since...
The module will control both the Hubsan x4, and the JP Twister Quad. I have test flown it with both. I can't say for sure on the WLToys quad as I don't have one, but from all accounts it and the JP Twister Quad are the same machine so I see no problems. It will also control the Nano Stik I mentioned earlier once I have done the protocol decoding. The possibility is there to support any model that uses the A7105 transceiver we just need the decode the various protocols used.
Sweet. Yes, I assume your quad is a rebranded WLToys model. Can't wait for you to share.
So, what exactly do we need to preorder? LOL
I'll get some PCB's made and distribute them to those who want one (once I have at least one working one). Not really planning on any ready made ones so brush up on those soldering skills ! It's gonna be SMT.
Soldering is not problem. Sourcing all the various resistor values and components so the project can begin is what I don't like.
Who is online
Users browsing this forum: Google [Bot], quadfather and 2 guests