Hubsan Q4 support?

[kasbah]

Hey, thanks for sharing this!

Having some trouble using this to bind to a Hubsan Q4 though. Gets stuck at binding. The blue lights go from alternating to in-sync flashing (like they should) but then go back. I tried increasing the timeout at hubsan.py line 78 but that makes it worse.

Works fine with the controller that comes with the X4 -- it should be the same protocol. I'll try with an X4 soon but do you have any other ideas?

Output with loglevel set to DEBUG in test.py:

DEBUG:a7105:reset()
DEBUG:a7105:read_reg(MODE, 00)
DEBUG:a7105:read_reg(GIO1S, 19)
DEBUG:a7105:initializing registers
DEBUG:a7105:read_reg(MODE_CONTROL, 63)
DEBUG:a7105:read_reg(FIFO_1, 0f)
DEBUG:a7105:read_reg(CLOCK, 05)
DEBUG:a7105:read_reg(CLOCK) == 05
DEBUG:a7105:read_reg(DATA_RATE, 04)
DEBUG:a7105:read_reg(TX_II, 2b)
DEBUG:a7105:read_reg(RX, 62)
DEBUG:a7105:read_reg(RX_GAIN_I, 80)
DEBUG:a7105:read_reg(RX_GAIN_IV, 0a)
DEBUG:a7105:read_reg(CODE_I, 07)
DEBUG:a7105:read_reg(CODE_II, 17)
DEBUG:a7105:read_reg(RX_DEM_TEST, 47)
DEBUG:a7105:calibrating IF bank
DEBUG:a7105:read_reg(CALIBRATION, 01)
DEBUG:a7105:read_reg(CALIBRATION) == 00
DEBUG:a7105:read_reg(IF_CALIBRATION_I) == 06
DEBUG:a7105:calibration complete
DEBUG:a7105:calibrating VCO channel 00
DEBUG:a7105:read_reg(PLL_I, 00)
DEBUG:a7105:read_reg(CALIBRATION, 02)
DEBUG:a7105:read_reg(CALIBRATION) == 00
DEBUG:a7105:read_reg(VCO_CALIBRATION_I) == 14
DEBUG:a7105:calibration complete
DEBUG:a7105:calibrating VCO channel a0
DEBUG:a7105:read_reg(PLL_I, a0)
DEBUG:a7105:read_reg(CALIBRATION, 02)
DEBUG:a7105:read_reg(CALIBRATION) == 00
DEBUG:a7105:read_reg(VCO_CALIBRATION_I) == 11
DEBUG:a7105:calibration complete
DEBUG:a7105:strobe(STANDBY)
DEBUG:a7105:set_power(_30mW)
DEBUG:a7105:read_reg(TX_TEST, 17)
DEBUG:a7105:strobe(STANDBY)
INFO:hubsan:binding started
DEBUG:a7105:write_id(55 20 10 41)
DEBUG:a7105:read_reg(PLL_I, 14)
DEBUG:hubsan:bind stage 1
DEBUG:a7105:strobe(STANDBY)
DEBUG:a7105:write_data(01 14 5f f1 28 56 00 00 00 00 00 00 00 00 00 1d)
DEBUG:a7105:strobe(RESET_WRITE_POINTER)
DEBUG:a7105:strobe(TX)
DEBUG:a7105:read_reg(MODE) == 1a
DEBUG:a7105:strobe(RX)
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:hubsan:bind stage 1
DEBUG:a7105:strobe(STANDBY)
DEBUG:a7105:write_data(01 14 5f f1 28 56 00 00 00 00 00 00 00 00 00 1d)
DEBUG:a7105:strobe(RESET_WRITE_POINTER)
DEBUG:a7105:strobe(TX)
DEBUG:a7105:read_reg(MODE) == 1a
DEBUG:a7105:strobe(RX)
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:a7105:read_reg(MODE) == 19
DEBUG:hubsan:bind stage 1
... 

[chpatrick]

Unfortunately the timing of the code might be a bit "computer-specific" at the moment. :( It's also possible that the Q4 has different timing characteristics. I wouldn't recommend setting the a7105 loglevel to DEBUG as the overhead of logging will definitely throw it off. You could try running with chrt -f 40 python2 ..., which will give the process realtime priority and should make the timing more accurate.

[chpatrick]

Any luck?

[kasbah]

I tried with chrt but that didn't help. I also tried your (edited out) suggestion of trying to sniff what the remote is sending but I didn't have time to find out the differences and do thorough analysis. I have yet to try it with an X4 too.

[kasbah]

Tried with an X4 today and the issue is the same. For both quads it looks like it repeatedly manages to bind briefly (the lights starting blinking in sync) but then drops it again (the lights go back to alternate blinking).

[kasbah]

Got some more A7105 modules. Still the same problem.

[chpatrick]

If the quadcopter is changing its blinking pattern it's definitely receiving the messages. I'm pretty sure it's the timing - I had the same problem when I was developing the code. I think it's probably due to the computer not waiting long enough for the quadcopter's response, or something in that vein. Unfortunately I can't work on it right now as I don't have access to my quadcopter.

[kasbah]

Yeah, when I have some more time I will try and compare what the remote-control sends to what this code is sending or at least play with the timing a bit more.

[srikanthnv]

@kasbah were you ever able to get it to bind? I'm trying this with a Hubsan X4 and see the exact same problem - there's no response to the stage 1 bind. I see the blue LEDs blink together for a while and then lose synch again and blink alternatively, so the X4 is receiving something, but I can't make out why it's not binding.

[kasbah]

No, I never got this to work unfortunately.

[srikanthnv]

@chpatrick do you suspect this is caused by the scheduling jitter alone? If that's the case, I'd be happy to explore more accurate sleeps using RTC. I'm trying to understand if this is an avenue worth pursuing.

[chpatrick]

@srikanthnv When I was writing this I evaluated different forms of sleep (nanosleep, busy wait etc), and found that Python sleep was actually quite accurate. In the end it worked for me without real time scheduling too. I suspect it's more to do with a sleep missing somewhere, or not enough. Sorry for not having more info but I don't have much time to work on this any more, but if it helps I saw the behaviour you described when I was writing this and eventually got it to work by fiddling with the timings. Here's the original C version if you'd like to compare.

[srikanthnv]

Totally understand! Thanks for taking the time to respond @chpatrick and @kasbah!

[joihn]

Hello everybody !

I have the same problem, did anyone solved it ?
Here is my work (I have a H107L):
I have found that the problem is in the file hubsan.py line 79.

if self.a7105.read_reg(Reg.MODE) & 1 == 0:

this is an bitwise operation (documentation here http://stackoverflow.com/questions/29663428/strange-if-statement)

Basically, this line check if self.a7105.read_reg(Reg.MODE) is even. If it is, it execute the code, else it raise a BindError, and the stuff start again.

The problem is that self.a7105.read_reg(Reg.MODE) is always 25. (so not even, so doesn’t work)
This is always 25, even when there is no powered hubsan in my room.

I have tried to change the timing at line 78, but no result…

[chpatrick]

Can you try running sniff.py? Plug in the Hubsan, start the script, then power on the remote. It should start printing out the messages from the remote to the Hubsan.

[joihn]

thanks for the fast response :)

here's the output:

scanning channel 120
channel: 120
session_id: 08 d1 98 0c
0 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
16 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
16 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
stage 3 packet received, switching ID
9 ms 03 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 08
9 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
8 ms 09 78 00 d1 98 0c 00 00 00 00 00 00 00 00 00 0a
22 ms 09 78 01 d1 98 0c 00 00 00 00 00 00 00 00 00 09
22 ms 09 78 02 d1 98 0c 00 00 00 00 00 00 00 00 00 08
24 ms 09 78 03 d1 98 0c 00 00 00 00 00 00 00 00 00 07
23 ms 09 78 04 d1 98 0c 00 00 00 00 00 00 00 00 00 06
23 ms 09 78 05 d1 98 0c 00 00 00 00 00 00 00 00 00 05
22 ms 09 78 06 d1 98 0c 00 00 00 00 00 00 00 00 00 04
22 ms 09 78 07 d1 98 0c 00 00 00 00 00 00 00 00 00 03
22 ms 09 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 02
24 ms 09 78 09 d1 98 0c 00 00 00 00 00 00 00 00 00 01

at this point, it stop because my throttle isn't 0 (security)

if I put the throttle to 0, then it continue writing other things.