Excellent work Aqualung and Avergottini.

I look forward to seeing what comes next.

Thanks for the Feedback!

Aqualung, yes, the processing program only sends data to the arduino when something changes.
if multiple things change at once, it updates one at a time, but it should happen fast enough to do so between pulses.

I know the ascii-code and the repeated lines are not the most optimized code, but I found that it's the best way to quick debugging of the code while running it.

In response to a request from someone trying to adapt my interrupt-driven packet transmitter, I've re-written the code to use only standard Arduino functions and be call-able on-demand with "sendPacket(yaw,pitch,throttle,trim)". The function returns the variable delay in milliseconds needed to send 10 packets per second (which can be ignored).

The code can be found at: http://sites.google.com/site/spirixcode/code/kodek.txt

The loop contains example code to drive the throttle from 0 to 127 and back down again.

PS: Although my helicopter seems happy with the pulse trains that I'm generating, I don't have an oscilloscope so I can't actually confirm that the output of my code is what it should be. If anyone has the time and inclination to sample the output and let me know the results, it would be greatly appreciated

i have been looking at this for a while. i got a s107 and the stock controller sucks. the response is terrible. been trying to get this to work on an AVR.
anybody else have this same idea?

Hey guys, could you pop by the iPhone IR controler thread, I'm not having much luck in trying to build hardware for the existing app.

Hey nemoskull, with the AVR remote idea, do you think it could take a PPM input rather than using the S107 Tx casing? reason being it could then be used with a real hobby Tx as a mdule or it could be used with the iPhly iPhone app.

oh hows you micro sub?

Hi guys

I have a couple of videos that may interest you.

In the first one I'm flying the IR Helicopter in AutoPilot mode (the auto pilot controls the altitude):

Flying IR Helicopter with Wiimote on Autopilot mode (8 min 20 sec)

The second one demonstrates how I decoded the IR protocol using the USB IR Toy v1:

Using IR HeliAutoPilot to decode Helicopter's IR Protocol (17 min 4 sec)

It also has a link to the program.

Any body know what the pot adjustments do on the controls inside the tx? Are they just trim adjustments or do they increase the range where you can get more control out of the heli?

It just changes the yaw trim....


On the S107 Tx there are two POTs for Yaw, one on the stick and one for the trim, the trim POT does not adjust the value of the stick centre. 



The Yaw output is basically a window set inside the min and max possible Yaw, the trim POT moves the window to one side or the other here is a an example as best as I can show it.......

Min-max is 0-127
Left 0-------------[Yaw widow is 64 wide]-------------127 Right



Full Left trim. 
Left 0[0-63 yaw is min 0 max 63]----------------------127 Right

Centre trim
Left 0----------[31-93 yaw is min 31 max 93]---------127 Right

Full Right trim
Left 0----------------[63-127 yaw is min 63 max 127]127 Right

If you take it thy the centre value will always be the same, when you shift the window to one side or another the value each side of centre changes and haves the effect of the centre value being changed

The DSM2ir device I've been beta testing modifies the protocol as it transcodes it, this gives the S107 FULL min-max Yaw control....

Left 0[0-127      yaw      is      min 0 max 127]127 Right

Flying the S107 with this is great, it can turn a lot faster, it's like having a 3rd hand tweaking the trim knob each time I change direction!

Interesting, so the pot only adjust the center and not the range of the control transmission?

Short answer... correct, the "trim" POT will only adjust the yaw trim and nothing else, unlike the Syma S032, S031 & S113, the GT5888, Xeida 9958 which all have begginer/expert modes, the S107 has no setting other trim.

Originally Posted by michaelstoops

FYI, we're discussing this table here:

http://www.rcgroups.com/forums/attac...mentid=3911583

Edit: here's a post about it complete with working code: http://www.abarry.org/likelytobeforgotten/?p=55

I was working on a S107 with the same protocol -- this one has 3 channels (A, B, C) and has a 30 bit protocol instead of the 32 bit one. It also did not come with a USB charger but came only with the controller charger.

There are a few things that are different about it:

1) It has a checksum. The bits labelled 21-24 in your table are a bitwise XOR of 4-bit words with the two zeros appended to the end of the bitstring. Thus you can compute the checksum for the first packet:

1000 0000 1000 1100 0000 1111 1111 11
with:
1000 ^ 0000 ^ 1000 ^ 1100 ^ 0000 ^ 1111 ^ 1100 = 1111

and for the second packet:

1000 0000 0011 1001 0000 0001 1111 11
with
1000 ^ 0000 ^ 0011 ^ 1001 ^ 0000 ^ 1111 ^ 1100 = 0001

2) The delays between packets are different for the different channels:

Channel A: 136500 us
Channel B: 105200 us
Channel C: 168700 us

These numbers are approximate but they are good enough for the helicopter to fly with (I've tested all 3 channels).

3) As you have said, the bits are as follows:

CC00 PPPP TTTT TTTT YYYY XXXX RRRR RR

C - channel
P - pitch
T - throttle
Y - yaw
X - checksum
R - trim

4) The bits in the throttle, pitch, and yaw are reversed, so for throttle bit 16 is the most significant bit with bit 9 being the least significant for throttle.

5) Bit 20 is the direction bit for yaw and then bits 19-17 (aka reversed) are the speed bits. So for full yaw in one direction you do 1111 and for full yaw in the other direction you do 1110

6) Bit 8 is the direction bit for pitch with the speed bits being just like yaw.

7) The trim bits are probably reversed or something like that too but I just set them to 0 and didn't worry.


Here's my relevant code for an Arduino. Note that my array starts at 0 so all my indexes are shifted down by one from your table:


// channel A B or C
// A is 10 with 136500us packet delay
// B is 01 with 105200us packet delay
// C is 11 with 168700us packet delay
if (channel == 0)
{
packetData[0] = 1;
packetData[1] = 0;
channelDelayValue = 136500;

} else if (channel == 1)
{
packetData[0] = 0;
packetData[1] = 1;
channelDelayValue = 105200;

} else {
packetData[0] = 1;
packetData[1] = 1;
channelDelayValue = 168700;

}
packetData[2] = 0;
packetData[3] = 0;

// pitch
packetData[7] = (pitch & 0b1000) >> 3; // direction bit

if (pitch < 8)
{
pitch = 8 - pitch;
}
packetData[6] = (pitch & 0b0100) >> 2; // others are speed bits
packetData[5] = (pitch & 0b0010) >> 1;
packetData[4] = (pitch & 0b0001);

// throttle
// bits are reversed in the throttle command
packetData[15] = (throttle & 0b10000000) >> 7;
packetData[14] = (throttle & 0b01000000) >> 6;
packetData[13] = (throttle & 0b00100000) >> 5;
packetData[12] = (throttle & 0b00010000) >> 4;

packetData[11] = (throttle & 0b00001000) >> 3;
packetData[10] = (throttle & 0b00000100) >> 2;
packetData[9] = (throttle & 0b00000010) >> 1;
packetData[8] = (throttle & 0b00000001);

// yaw
packetData[19] = (yaw & 0b1000) >> 3; // direction bit
if (yaw < 8)
{
yaw = 8 - yaw;
}
packetData[18] = (yaw & 0b0100) >> 2;
packetData[17] = (yaw & 0b0010) >> 1;
packetData[16] = (yaw & 0b0001);

// these 4 bits are the checksum, so make sure they
// are 0s so they don't change the XOR later on
packetData[20] = 0;
packetData[21] = 0;
packetData[22] = 0;
packetData[23] = 0;

// yaw trim / yaw adjust (the little dial on the controller)
// 6 bits
packetData[24] = 0;
packetData[25] = 0;
packetData[26] = 0;
packetData[27] = 0;

packetData[28] = 0;
packetData[29] = 0;

// these bits are never sent but we do the checksum
// computation in 4-bit chunks, with the trailing two
// bits set to zero, so we set them to zero here to make
// the checksum a bit easier to compute
packetData[30] = 0;
packetData[31] = 0;

int i;

int checksum[10];
checksum[0] = 0;
checksum[1] = 0;
checksum[2] = 0;
checksum[3] = 0;

// compute checksum -- bitwise XOR of 4-bit chuncks
// with two zeros padding the *end* of the last two bits
for (i=0; i<32; i+=4)
{
// XOR
checksum[0] = packetData[i + 0] ^ checksum[0];
checksum[1] = packetData[i + 1] ^ checksum[1];
checksum[2] = packetData[i + 2] ^ checksum[2];
checksum[3] = packetData[i + 3] ^ checksum[3];
}

// now set bits 21-24 (array values 20-23) to the checksum
packetData[20] = checksum[0];
packetData[21] = checksum[1];
packetData[22] = checksum[2];
packetData[23] = checksum[3];


int bitsum = 0;

for (i=0; i<30; i++)
{
if (packetData[i] == 1)
{
bitsum ++;
pulseNum = 32;
} else {
pulseNum = 16;
}

// flash pulseNum times
while(pulseNum--)
{
digitalWrite(LED,LOW);
delayMicroseconds(9);
digitalWrite(LED,HIGH);
delayMicroseconds(8);
}

delayMicroseconds(300);
}


// channel A B or C
// A is 10 with 136500us packet delay
// B is 01 with 105200us packet delay
// C is 11 with 168700us packet delay

// we compute the delay and return it to a function that will delay this amout
return((channelDelayValue - bitsum * 272)/1000); // in ms.

amieres, you used your software to read the USB Infrared Toy? Is there any other graphic software you indicate?

andybarry, this table is valid for this model sold in DX?
http://dx.com/p/usb-rechargeable-3-c...r-remote-32694

I'll start looking for that protocol and I'm doing some lifting.
I'll decode the protocol and compare it with that table.

Thank you.

--
MhagnumDw