WLToys V912/V915/? protocols

Ok, so that's not this simple... I think we need some RX captures (ah, you have the new version, it would have been easier with the older, I hope both are using the same protocol ), along with the fixed IDs used on the TX side.

Should be easy to figure out with that ... But don't attempt to solder wires here if you don't have the equipment or experience. I wouldn't want you to fry your RX.

I just understood that you already did it but those captures are kinda useless (or just more hard to exploit ) without knowing which TX ID you were using


edit: I'm stupid... tx id is in the capture (0x44871654).
Will have a look and crack that...

I checked your latest data, and it shows that data came from row0 but the last 2 values are swapped.
To figure out the proper table, you need to capture the Rx after binding for 16 txids. It doesn't matter what you do with the tx other than achieve binding with the rx and then start the capture.
These are the TxIDs to use. Theoretically we only need every other one (only eight of the 16) but as the table seems hosed up, it would be safest to grab captures for all 16.

256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271

EDIT: I read the table wrong, number should be sequential, not multiples of 16. the above table is now correct

PhracturedBlue wrote: it shows that data came from row0

there might be another trick then, because 0x44871654 % 16 = 4, not 0.

which data were you looking at? I used this:
V912 RX Bind move collective.logicdata

The data I see has an id of 0x46746841 % 16 = 1 and offset = 4
However, I was only at the binding data (which uses row 0)
For the data section though, I can see it using:
69, 19, 5f, 0f, 55, 05, 9b, 4b, 91, 41, 87, 37, 7d, 2d, 73, 23

There is something weird with the A7105 where the rx listens one channel down, so assume the offset is instead 5:
adjusting for 5 gives:
6e, 1e, 64, 14, 5a, 0a, a0, 50, 96, 46, 8c, 3c, 82, 32, 78, 28

and resetting the starting point:
a0, 50, 96, 46, 8c, 3c, 82, 32, 78, 28, 6e, 1e, 64, 14, 5a, 0a

which is what we expect (note the '1e', and it is consisteltly misisng data on 0x19 (which is 0x1e) which is expected since you changed it to 0x2e.

Anyhow, my above statement stands. please run captures at the 16 txids requested. also, I recommend using the firmware without goebish's hack because it is easy to then see which channels are missing data. It may well be that the 'bug' noticed previously is only in the tx, and there is something else going on

Hmmm I've been staring at too much hex numbers, you're right

Make 16 rx captures with the fixed tx ids PB stated (with your devo7e as tx), with the firmware attached which has the necessary bits for v912, but "standard" rf channels table:

Thanks, The data looks good
Here is the result:

The table matches the offiicial table so whatever is wrong doesn't seem to be the jump sequence.
I don't see any cases where more than one frame was missed in reception so far, so it looks like the 7e has a good connection and you shouldn't see any loss of signal. So I am not sure what is going on. I'll let goebish chime in if he sees anything odd here.

As you said, maybe this 1e->2e is just a TX bug, and that's not what makes the RX have an inconsistent link.

Deal57, just to try, here's a firmware with official table but with your stock tx id hardcoded.
www.dropbox.com/s/akluzw7i11rha51/deviat...0.1-fixedid.zip?dl=0
( gist.github.com/goebish/6bff17530af44dc1d698 )

SeByDocKy, maybe a capture from your V913 TX could help, looks like they're the same.

At least we know packet[17] & [18] ( what looked like a weird sequence of 10 words ) are not important because the RX reads only 17 bytes from the 21 bytes sent.

Soooo.... it's like if this RX works well only with particular tx ids ?

Sounds weird, I think we need captures from other TXs to better understand now...

Note that this firmware should be safe, you can use it, but it's using your stock TX id, not a good idea to push that to the repo

Out of curiosity, make a rx capture with this working firmware ...

Of course we should have asked that first

Are you just updating the dfu ? because only the .mod changes with my hacks...

So, you're saying that firmware from post #30013 is working well with fixed IDs ? Can you try it with "automatic" id ?