WLToys V912/V915/? protocols

Before grabbing data from the Tx, we can just try testing the various possible bits to see if any of them do "the right thing". If not, then we need to look at the data to see what they're doing.

I got the V686G using a variant of the FlySky protocol integrating some new channel. I will try to capture SPI data asap ...

You can upload the data, it will not hurt. To have something to compare is always good.

It's more like introducing a 9-th channel:
case PROTOCMD_NUMCHAN: return (void *)9L;
case PROTOCMD_DEFAULT_NUMCHAN: return (void *)9L;

and

if (Channel[8] >= 0) { // 9-th channel
// Map TX value -100..100 to internal value -100..100
int scaled_value = Channel[8] * 100 / CHAN_MAX_VALUE;
int channel_of_the_bit_to_set = scaled_value / 4;
packet[6+channel_of_the_bit_to_set*2] |= 0x10 << (scaled_value % 4);
}

Here is 10 seconds from power-on of the V912 (new) TX.

I did not move anything except to press the buttons, so I presume changes to data will show up when those are pressed (of course in addition to inits, channels, etc.). I'm purely guessing, but it looks like it binds about 3.5 seconds into the file (packet 4790?) with my V912. There are several changes in the data packets that may be helpful. Beginning packet 6304, byte 16 was 00, goes to 80, and then 40 at 7924, back to 00 at 8682. At 8506, byte 13 was DC goes to DA for about 10 packets, back to DC, then at 9826 goes to DD for the rest.

I hope this is helpful.

Your ninth channel as outlined isn't sufficient. It can only set one bit, and we have at least two new bits to handle. I also don't like the idea of 4 channels that set 4 specific bits and then another one that can be used to set any bit.

I was thinking about replacing the existing WLToys mechanism with a more general one. I.e. - you either used the current WLToys V9x9 extension, which gives you the current behavior. Or you turn on the WLToys Bits (or some such name) extension, and get one where each channel sets four bits in a lower channel number. Might not be able to just mask them out, but that's the general idea.

@mwm - I did not mean it as a permanent modification, only as a way to figure out bits by experimentation. But we can add not one, but say, four channels like this and it will provide us with 4 more binary bits to set. A channel per bit simplifies mixer setup.

By the way, the code as it is written is either buggy or strange. If PROTOOPTS_WLTOYS is on, it fills out that 4 bits for channels 4-7 (zero based), BUT it already used the value of these channels to fill out corresponding bytes in the package. It is probably harmless, but weird.

For the sake of preserving compatibility you can either introduce a new option which turns on new behavior for binary channels, or keep 4 old channels fixed and make only new ones flexible.

@Deal57 - byte 16 with values 80 and 40 are these buttons. Byte 13 change is a LSB fluctuation of ADC, in particular because it's an odd byte with value higher than 0x0f.

The current code really is a hack. But it's no worse than the hack that WLToys did in the first place. It transmits 8 channels to a 4-channel Rx. So the upper four channels may be filled into the packet, but they're ignored by the Rx. So the values get used to set bits in the lower channels. I might look into changing the packet to only transmit the first four channels, but I suspect doing so will perturb lots of code, or PBR would have already done it.

I've already tweaked the code to add a second option, but it currently does nothing. I'm investigating different ways to specify the bits to set. I think I like the idea of specifying which channel to apply the bit (or maybe bits) to. That way, you only need as many extra channels as you need to set bits in, not however many it takes to get to the channel you want to set the bit it. That my V915 has channels 5, 6 and 7 in the mixer but doing nothing (and actually dangerous to turn on!) is really annoying.

Assuming that they haven't extended the values even further, so that we only have those 4 extra bits per channel, then we need 16 bits. With 8 extra channels to use, that's two bits per channel to get them all. I don't think the mixer programming will be that much worse: you need a mixer for each bit, and just use the mux type add to add them up. But trying to squeeze in 4 bits could be a problem.

Judging from @Deal57 SPI trace and interpretation (I did not look into the data myself), they add bits to high nibble of all 8 channels - byte 16 (zero-based) is a high byte of channel 5 (again, zero-based). So we have really 32 extra bits.

I doubt very much that you need more than 4, at most 8 such bits for a WLToys helicopter. May be my imagination fails me, but it is really really hard to control such a beast reasonably.

So what if when WLToys option is on there would be 4 "analog" channels and 8 single bit channels which can map to any of the possible 32 bits.
It is flexible and powerful enough, and does not require too much mixer/mux programming, which you need to explain to people all the time. You would need to explain it to me, even

If they're really using channels beyond 4, then we've got a completely different beast to deal with. For instance, we now need more than 4 "analog" channels. Seems like the FlySky code always sends 8 channels, but it zeros them out after the number of channels configured. If you configure a mix on a channel then lower the number of channels so that one isn't sent, the mix is still active. So you can use channels 5-8 but still send 0s.

I can easily seem them going past 4 extra functions - the v912/915 Tx has six buttons, their stock v9x9 tx has eight. My v323 has five extra functions (video, photo, led, flip, and headless mode*). But ... the V912 and V915 felt dated on release (4-channel FP helis with a flybar? In 2014? Really?), and it wouldn't surprise me if they are the last of the FlySky protocol 'copters from WLtoys.

So I'm looking at three possible options:

First, after figuring out what bits turn on the extra functions, and just add three channels to the WLToys options for them. With GREAT BIG WARNINGS that turning on the V9x9 options on a V91x can be dangerous.

Once you get beyond "channel X turns on/off feature Y", explaining it becomes an issue. Telling someone "turn on bit 2 in channel 3" doesn't really help someone who wants to turn off the lights!

The easiest second is the one I first proposed. Channel 5 sets bits in channel 1. We just grab the bits directly, with values of 0-15 corresponding to the nibble being 0-15, and so on. So the current system would have mixers that set So for the V959, we'd have two mixers on channel 6 with fixed values of 4 & 8, the first of which was the video control, and the second of which took a photo. But we'd need to keep a document somewhere of what all the bits in the WLToys models did.

The last option is basically the code you presented on any channels beyond 4, except that instead of treating the channel value as a channel number & bit offset, you treat it as a channel number & the bits above.

Hmm. I think I just decided to go with option 2, at least for now, as that requires the least perturbation to the existing code. Option 1 may still be preferable. Or maybe both, by adding the bits discovered with the new value for the WLToys option to the old code as well.

Ok, I've got a build that can be used to experiment with. The devo7e zip is attached. I've also attached a v959 model file for a devo6s that uses these features. Source can be found in ssh://hg@bitbucket.org/mwm/deviation-team, on the wltoys-bits branch.

Note 1: this is a build based on the latest team nightly build. Please install the file system as well as the DFU. If you've been running 4.0.1, you'll have to edit hardware.ini, not tx.ini, to enable your extra modules.

Note 2: This will turn the WLToys options OFF on all existing FlySky protocol models. Set it to V9x9 to get the old behavior.

The new feature is that the WLToys option now has two settings, "v9x9" which has the old code in it, and "Bits", which is the new behavior. The new code takes the value of channels 5-8, divides by 10, throws out the high order bits, and then ors those into the appropriate parts of channels 1-4, respectively.

The v959 model works properly for lights and camera control. I can't test flip, as my v959 hasn't been flight-worthy in quite a while (it's actually in pieces for another project). Camera control uses mix0 and mix2 to toggle video & photo modes. Lights are on GEAR1, and flip is on FMOD1. Note that these may need to be toggled on/off to trigger the device they control.

Here's my channel 8, done as three mixes so it's clear what's going on:

All the curves are fixed. We set the output to 0 in the first mixer, so everything is off by default. The second mixer, enabled by FMOD1, sets the output value to 10, which is flip mode. The third mixer uses an add mux to add the value of 20, for the lights.

The V915 uses the same two values in channel 8 for it's lights and "turbo" mode, except they are backwards: turbo uses 20, and the lights use 10. I managed to not notice that turbo was being enabled before, so we only need to find the camera control buttons on the V912.

I would be very surprised if they are set via channel 7. Don't test it until after you've exhausted 5, 6 and the other two values (40 and 80) for 8. And before you do, take the blades off your propeller.

As follows from @Deal57 SPI traces these new bits go into protocol's channel 6 (1-based). The bitmask values are 0x40 and 0x80. How is it expressed in your notation?

victzh wrote: As follows from @Deal57 SPI traces these new bits go into protocol's channel 6 (1-based). The bitmask values are 0x40 and 0x80. How is it expressed in your notation?

Not possible with the current code. I've attached a dfu that extends the "extra" channels from 8 to 10. With it, you set channel 10 to 40 or 80 to get either bit, and make sure that channel 6 has a mix type of None.

It looks like they just moved the camera from channel 3 to channel 6. But both variations on the WLToys extension already use channel 6 to carry bits that get sent to other channels.

Arrgh. Forum ate the attachment.

I think your solution can allow for more bits simultaneously covered but the price is not very intuitive programming of mixers. To cover all 32 bits you need 8 extra channels, 12 total.

True, but the alternate takes 36 channels (one per bit plus four analog) to cover all 32 bits. The other alternative only needs 1 channel for every channel you're going to be setting bits on, but it's even less intuitive.

Of course, we have no evidence that we need to cover more than 24 bits, as we haven't seen them set bits in channels 7 and 8 yet. Unless you've got an intuitive solution, I'm in favor of just adding channels 9 & 10 to the existing set of four, and document that turning on channels 6 and 7 on the V912/V915 is bad for the health of your model and you.

I found a camera from an older WLToys heli that works with my V912, so I can check that. I will also rig a voltmeter onto the other ports for testing. I started out the testing, but it's family night, so it will have to continue in the morning! Thanks for all the work on this...

I have no model to test on, so my considerations about intuitiveness are purely theoretical. Experience shows that people call familiar things intuitive, so both my approach (channel per bit you want to manipulate, 8 at most) and yours are probably equally unintuitive.

RC people are familiar with the one channel per control model. Also with having multiple settings for one thing on a channel (flaps, flight modes, etc.). Controlling multiple things with one channel is unusual, and hence less intuitive for them.

The mode I set up isn't that painful. The bits for a channel are in the channel 4 above it, which should be unused. To add 0x10 to the channels control bits, you add 10 to the channel above it. I think it's worthwhile if it means we can get all the bits without any oddities.

But if they're using channel 6, that an oddity - you wind up adding control bits to a channel used for adding control bits! So lets just add channels for the two new controls so users don't have to worry about bits and which channel goes where, etc.