Hi,
has anybody ever tried to analyse the IR protocol used by SanHuan? I hooked up my oscilloscope to the transmitter and as far as I found out it should not be too difficult to reprogram the IR protocol in a PC. What I found out so far:

carrier frequency: 38.17kHz
constant length, package-to-package 159ms
(all timings in µs)
header: 3360 pulse, 1040 space
one (or zero): 724 pulse, 320 space (=1044, ratio: 2/3 to 1/3)
zero (or one): 320 pulse, 724 space (=1044, ratio: 1/3 to 2/3)
length: 33 bits

It should be possible to create a configuration file for lirc and send commands to the helicopter via the serial port. Would be cool to fly with a joystick on a PC!

Darkstar.

I'll do it... one day.

Fly with a joystick and a wireless security camera attached to the helicopter. It would be like an army mini-coax UAV, but without guns

But I don't have tools like oscilloscope. But I know how to program. Actually i'm a Software Engineer Student.

If you're a software engineer student (like me), you have access to your campus labs, just ask the proper teacher

Lol. Ok i Should have said i dont have the tool like : time!
Anyway, first thing first, I don't have my first heli yet!

Well i guess that i just found my big final project!

Short Update:
It looks like there are 32 bit sent each package and the last pulse seems to be a stop code. First 8 bit are for throttle, but also the last 8 change, so not straight forward. Next 8 bit are for rudder and elevator straight forward: 4bits each most significant first. Middle position means all bits unset and direction is coded somewhere else. Surprise: the trim is coded in the stream! For the next bits I have to dig a little bit further.

Darkstar.

Nice. Keep on the work. Would be awesome fly control it via PC.

Ok, you software engineers. Here is something for you. I recorded the bits and attached three files:
1. Throttle moving, everything else constant
2. Full throttle and trim moving
3. Medium throttle and trim moving

As you can see byte one and four is changing when the throttle changes. But when the trim changes in byte three byte four is also changing! So find the connection.

Darkstar.

More news. Here is one example:

01110010 00000000 11000000 11000001

byte,bit explanation
1,1 fix (always zero)
1,2...8 throttle
2,1...4 rudder
2,5...8 elevator
3,1 1=left rudder, 0=right rudder
3,2 1=nose up, 0=nose down
3,3 1=trim left, 0=trim right
3,4...8 trim
4,1...2 channel: 11=A, 10=B, 01=C
4,3...8 checksum

Big question is now: how to calculate the checksum????? It's your turn software engineers!

Darkstar.

Keep this up!
Subbed, in a big way.

Well, I understand little of this but I find it fascinating; we move a stick and the model responds - but how many of us actually know why?

Yet another reason to appreciate the expertise and technology that goes into our models.

Originally Posted by Darkstar2000

Big question is now: how to calculate the checksum????? It's your turn software engineers!

Ahaha... I don't know!

He's a Navy Nuke, who worked at Microsoft. Eats code for breakfast.

Ok, from the first look into the data with some collegues it looks like the checksum is a simple addition: if one value raises 1 bit, the checksum does the same. So it should be not too complicated to find the right algorithm.

Darkstar.

Ok, I am coming nearer: it looks like the checksum is the addition of the first three bytes plus 15 (1111):

01110010 00000000 11000000 11000001

   01110010  (0x72)
   00000000  (0x00)
   11000000  (0xC0)
   00001111  (0x0F) +
--------------------------
 0101000001  (0x141)
last 6 bit: 000001

It seems to be correct, but I will have to confirm this.

Darkstar.

Hey darkstar, were are you from? What university?