WLToys V912/V915/? protocols

Are you using the latest repo from:
bitbucket.org/deviationtx/deviation

what version of gcc do you have?

there is a '#pragma weak' which can cause issues with older gcc. It should happen at link time not compile time though. I crosscompile the emu in Linux typically, which builds properly.

I just ran a emulator build on my Windows machine (make TARGET=emu_devo10 WINDOWS=1) and it went through fine.
gcc --version
gcc.exe (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks, I guess there's a problem on my side then, I remember I've already built it before.

gcc 4.7.2, but this is a compile time error complaining about different return types (int vs void)... I thought my sources were up to date, but I'll check that.

Ok, I can build it but not from the sources on my repo although I thought I merged like 2 or 3 days ago...
Now this means I've no idea of which version of the source I'm working on....
I got lost with all those repos and branches

You can see it here:
bitbucket.org/goebish/deviation/history-...u/radio.c?at=default

you have the wrong A7105_Reset in radio.c. This code seems to have come from the 4.0 branch rather than trunk. This doesn't look like a general issue with your repo though. Not sure how you got it into this state.

PhracturedBlue wrote: Not sure how you got it into this state.

Me, when playing with Mercurial/SourceTree:

(I'm more of a git guy, I should learn hg...)

I compared channel hopping sequence from capture file with the one I have with the same tx id in deviation (emu) and there's a slight difference:

capture : 4C, 92, 42, 88, 38, 7E, 2E, 74, 24, 6A, 2A, 60, 10, 56, 06, 9C
dev emu: 4C, 92, 42, 88, 38, 7E, 2E, 74, 24, 6A, 1A, 60, 10, 56, 06, 9C

Maybe this can explain this copter (V912) does not work well with my latest firmware ? To confirm that I can build a dfu with this fixed id and hardcoded hops sequence to check if this fix the problem (after some sleep ).
But this is only 1/16 packets... probably not enough to even notice.

Deal57, can you make a capture on the RX side ?(edit: maybe we can check a few other things before having do to that).
I've a problem with the 4 files you posted earlier, saleae logic software does not show anything when I open them. Which version are you using ?

My version is older, I'll update, but going to bed now

yeah, works better with updated version...

I wanted those files mostly to check timings, and there's no problem with that, time between start of packets is fine (a bit less than 1.5 ms).

Attached is a dfu in which I've set an hardcoded TX id (same as your stock TX) and an altered FlySky tx_channels table. Can you tell if it works better ?

Then... there's one more thing I've not checked that could be the cause to your problem: chip init, maybe there's a difference in VCO calibration or something like that... I'll check later.

keep in mind that is just crap code for testing V912, which is different from V911, no idea for V913 ...
gist.github.com/goebish/cd68d0928d37f81df027

Regarding my repo... I'll keep it for reference but I'll now work on a new fork, that'll be simpler:
bitbucket.org/goebish/deviationtx

Ok, that's cool but we're not done

Now we've to make it work with any tx id... I think I need to replace all the 0x1e with 0x2e in tx_channels[ ][ ] for this particular protocol (I wonder if this is intentional or if they made a typo when they coded their firmware , because that's stupid to change only 1 byte in the sequence)... or maybe that's more complicated than that in which case I'll need a few RX captures, to check which rf channels it listens on.

I'll build a few more firmwares you'll have to test

Deal57 wrote: I haven't flight tested so let me know when it's ready for that.

If you think there's a solid link you can try, just don't try another flysky aircraft with this firmware.

if you can get rx captures, it will make it clear what channels it listens on, but for each row in the table, the numbers are the same. I don't think it would be too helpful though.
If you look at the table, you can see the rows come in pairs, with the 2nd being the 1st reversed (so there are really only 8 unique rows)
the 2nd number is always the 1st plus 0x50, so there are really only 8 unique bytes in a row.
in the 1st row, the bytes are in ascending order, and grow by 0x0a for each pair.

So it would be trivial to take the 16x16 table and turn it into an 8x8 table if we ever need more space. Based on the above, I would guess there is probably also an algorithm to determine the row scrambling, but I was never able to figure that part out. If we asume the 1e->2e is a typo (very likely), that strengthens the argument that there is an algorithm to determine the row scrambling, since it is unlikely they would make the same typo in each row (or more precisely that they don't use a table like ours when computing the channel)

Yup, I noticed the +0x50 (I'm new to the FlySky protocol, I don't even have an aircraft that uses it...)

Now maybe they made the mistake only in this row (0x01), I'll write something to check that. And yes in last resort a few RX captures with different tx IDs would help.

Deal57 can you try this firmware with a few different fixed tx ids and report if it works please ?

edit: oops, made a mistake, reuploaded ...