New Hubsan Upgraded Version on the way

That will require someone with one of the tx who also has a logic analyzer to snoop the protocol.

I'm not buying any more RC equipment at the moment though.

Does anyone know if the new tx will bind with the old hubsan? I assume so if the current Hubsan protocol will bind.

If so, someone could donate one of the new Tx to me (I only would need to the Tx) and I could work on it.

I would be glad to help, I've got a X4 v2 transmitter and a 24MHz logic analyzer.

I'll try to hack through it, but I may require some help :

Where should I place my probes ?
I guess it's near the screen, any notes from the v1 ?

Can the protocol be analyzed with Saleae logic, is it SPI or something similar ?

edit: OK, i see the trace from the mcu to the a7105, won't be easy to hook, have to do it at the SOIC level... will sck & sdio do for the analyze or do I require additional connection(s) ?

I found a better way to hook to the bus, it's located near the LCD screen, but not on the same side than on v1:

I'm craving to do the analyze but I can't do it now because a storm is approaching, not the best time to play with the soldering iron...

I'll probably do it tomorrow, then I'll send my results.

Ok, one flood later ...
Got the analyzer hooked up:


Seems promising:

*MOSI = SDIO, CLOCK = SCK
Is it normal that I have so much state transitions between what seems to be bytes ?
I'm using a SPI decoder with default settings, maybe I'm wrong ?
Note that it is the first time I use a logic analyzer, a new toy I got 2 days ago

Now I don't plan to reverse the entire protocol...
Can someone point me to the Hubsan X4 V1 protocol analyze so I can try to understand what happen when we send enable/disable leds or enable/disable flips command with the V2 ?

Thanks.

Reporting my progress:

I found a V1 protocol analysis on rcgroups and I think I have something interesting now:

See this 20 00 00 00 80 00 sequence ? This is the beginning of the data transmission

Now I've to write a small code to extract those packets, add probes to the throttle and throttle trim- switches to trigger the capture when required then understand the new commands ...

Once again, this is the first time I do this and this is FUN

I think I got it

quote from rcgroups (data transmission packet format):

Ex1: 20 00 00 00 80 00 7d 00 84 02 64 db 04 26 79 7b
Ex2: 20 00 00 00 80 00 7d 00 84 02 64 db 04 26 79 7b
aa bb cc dd ee ff gg hh ii jj kk ll mm nn oo pp
cc : throttle observed range: 0x00 - 0xff (smaller is down)
ee : rudder observed range: 0x34 - 0xcc (smaller is right)
gg : elevator observed range: 0x3e - 0xbc (smaller is up)
ii : aileron observed range: 0x45 - 0xc3 (smaller is right)
llmmnnoo: Transmiter ID(?)
pp : checksum
Checksums:
The checksum is calculated as 256 - ((sum of the 1st 15 bytes) modulo 256)

As you can see there's no definition for jj ... Looks like it is a 5th Channel
On the V1 protocol it seems to always be 02
On the V2 here's what I have:

leds enabled / flips enabled :
20 00 00 00 80 00 78 00 83 0e 19 00 00 00 00 3e --> jj = 0x0e

leds disabled / flips enabled:
20 00 00 00 80 00 78 00 83 0a 19 00 00 00 00 42 --> jj = 0x0a

leds enabled / flips disabled :
20 00 00 00 80 00 78 00 83 06 19 00 00 00 00 46 --> jj = 0x06

leds disabled / flips disabled :
20 00 00 00 80 00 78 00 83 02 19 00 00 00 00 4a --> jj = 0x02

That's weird, because the current deviation code sends 0x02 (packet[9] = 0x02;), which should disable leds and flips but it doesn't.
Maybe that's because kk is always 0x64 in v1 (well, that's what I assume from deviation's source code, I don't have a v1 myself), it is always 0x19 with the v2.
... Or maybe that's because what seemed to be the TxID in v1 is full of 00s in v2 ?
... Or maybe the TxID is in fact kkllmmnnoo so v2's ID is 19 00 00 00 00 ?

I hope this is enough information.
I'm new there (got a Devo TX yesterday only ), who can I get in touch with to get it implemented ?

Attached is a dump of a complete v2 session, from switching the radio on then changing leds/flips state.

Thanks.

edit: sent a PM to PhracturedBlue
edit2: I'll try to setup a smt32 dev environment to make a patch myself, I can't guaranty anything as I'm an AVRetard basically

Hi sbstnp,

Nice to see I'm not speaking in the void
I'll try to setup a smt32 dev environment and make the change...

The only issue is that I still have to actually learn how to use deviation, I only copied a few profiles to test a few copters and quads I have, but I'm still far from being able to make a profile by myself.
I Got the Devo 10 yesterday, had a DX6i before, deviation is a bitch to program by comparison

Well, Now that I know I'm not alone here I'll ask for help if required.

Thanks.

I installed a smt32 environment and built my own .dfu firmware with modified hubsan_a7105.c to send frames with altered jj and kkllmmnnoo but this doesn't work, LEDs are still on

I bet something else happen in the bind phase, I need some sleep now, I'll continue my quest tomorrow.

Got it to work


Actually there's only one thing to do: modify jj value (packet[9] in hubsan_build_packet()), but there's a trick:

The hubsan X4 v2 (H107-L) will always starts with leds on / flips on, whatever the value of jj is. (that's why although current Deviation code sends 0x02, x4 v2's LEDs are on)

So if we want to start with leds off & flips on for example we shouldn't send a packet[9]=0x0a on the first frames, but 0x0e (default) for the first 100 frames then 0x0a for subsequent frames... That's what it does in the video and it works
My hardcoded test:

Now I've to make it work with switches...

I've to setup a bitbucket account, learn HG Mercurial basics :-/, clone the source repository, make a patch (based on modification made by PB for Flysky) and submit a patch...

Oh and of course make a deviation profile (that may be the hardest part actually )

I see you ordered a PUMQ 1.1 to replace it.

I got one yesterday, I only flew it twice because I spent all my time hacking the hubsan protocol and modifying Deviation

The PUMQ is a nice hacking platform, but I think it's far less robust than the X4, it looks like its arms may break just by staring at them (they're slimmer on the 1.1)

Would be cool to be able to reflash the x4's firmware to add a angle rate flight mode... Walkera devices are firmware upgradeable, I wonder if any progress has been made on flashing a custom fw to a lady bird for example.

I made a patch for deviation and submitted a pull request:
bitbucket.org/PhracturedBlue/deviation/p...l-for-hubsan-x4/diff

Now I'm having a hard time modifying the model.ini (I use the .ini from the x4 model thread as a base)
A bit of help with that would be welcome.

it's OK for the leds (Gear switch):

Now I'd like to have:
FMODE 0: 70% throws
FMODE 1: 100% throws, no flips
FMODE 2: 100% throws, flips enabled

But I've no idea of how to achieve that.
Needs to have Channel 6 < 0 to disable flips, >=0 to enable (defaults).

PM me if you want the compiled firmware for your TX.
(I'd like someone with a X4 v1 to test it too, to make sure I didn't break anything)

Help please, with all this hacking I still haven't had time to RTFM

edit 2013/08/22: updated profile with proper throttle curve and rud/ail/ele expos

goebish wrote: Now I'd like to have:
FMODE 0: 70% throws
FMODE 1: 100% throws, no flips
FMODE 2: 100% throws, flips enabled

But I've no idea of how to achieve that.
Needs to have Channel 6 < 0 to disable flips, >=0 to enable (defaults).

You simply have to do the same with the Ch6 as you did with Ch5, only you should use FMODE2 as the switch instead of the GEAR.
Use the DR&Expo template on AIL end ELE channels. You only need one switchable state with !FMODE0 (i.e. inverted FMODE0, which you can change by clicking on it) and use the scale to slow down the 1-to-1 (or EXPO) function...

Thanks FDR,

I now have a working profile (attached)

GEAR 0 -> lights on
GEAR 1 -> lights off

Throttle curve: 0/40/65/80/100%

FMODE 0: 75% throws / 60% RUD, -10% expo AIL/ELE, +30% expo RUD
FMODE 1: 90% throws / 70% RUD, -10% expo AIL/ELE, +30% expo RUD flips disabled
FMODE 2: 90% throws / 70% RUD, -10% expo AIL/ELE, +30% expo RUD flips enabled

RUDD D/R 1 -> throttle cut

edit 2013-08-22: proper throttle curve and ail/ele/rud expos

Can you check if there is any packet code change in case Normal-Expert mode change. For my taste Hubsan is too lazy, seems it has some internal expo. I need to use quite large expo compensation in Tx. I wonder if internal expo can be swithed off.