My new 600mm Hexacopter build log Part 1

I'm building a new Hexa frame for my APM2 board and I'm trying to log the building process. Bellow are the list of components use on my Hexacopter:

  1. Fiberglass 600mm Hexacopter Frame $90 from
  2. C2826-1000Kv EMP motors. $15 each from
  3. 30A ESC flashed with SimonK Firmware. $20 each from
  4. Roll & Pitch Camera Gymbal. $60 from
  5. Ardupilot APM2 flight controller. On promotion in for S$250
Parts that comes with the Frame:


Left & right legs attached to the bottom center plate.


All legs attached to the bottom center plate.


View from the bottom after attaching the bottom support bar.

30A ESCs stripped the cover and ready for flashing after replacing the cable to motor with longer ones.


Flashed ESC and wrapped again.


Put 4 escs on top of the bottom plate.


Another 2 escs on the bottom of the hexa.




Arducopter PID Tuning Guide.

Taken from

Real life conspiring against me, so in brief..


Tuning method one.

1. Set all stab params to ZERO

2. Set all rate params to ZERO

3. Get your gloves and eye protection etc on. Hold copter in hand - go to hover throttle and above

4. Increase rate_P by 0.1 increments, dipping one leg down to 90 degrees and back again. As rate_p increases you will feel increased resistance to your movement.

5. Keep going till the arm you are dipping down starts to bounce (oscillate) as it tries to fight against you. Then back off 0.1 or 0.2. Also try full throttle with copter leant right over (90degrees), this often shows up oscillations that aren't apparent whilst the airframe is horizontal or at less than full beans.

6. Add in rate_d in 0.001 increments. As you hit max level for this you will see the quad sort of twitch, every second or so it will move very slightly and return quickly. When you see this behaviour, don't reduce it yet, but instead add in a bit of rate_I (ensuring you don't go above 50% of your rate_P value) Does this rate_I get rid of the twitches? if so, great try to add a bit more rate_P, again until it starts to oscillate. If it doesn't you will have to back off on rate_D - the level of rate_D seems to depends alot on vibrations. Again tip it right over on full throttle, make sure its all still ok.

NOTE: Possibly a safer first attempt at this would be not to use any rate_I at all, just increase D till you get the twitches and back off a bit then do rate_P.

7. Put in some fairly low values for stab, eg p=3.0, I=0, d=0.001, do another hand test, does it look like it will fly?

8. Set channel 6 to tune stab_P, take off and up stab_p to your liking - (higher values equal better response until you've gone too far then you get the overcompensation oscillations) lower values will give a softer flight, but less locked in.

I've never had any benefit, so far, with stab_I, always ended up at ZERO with this

Stab-d i do last - just small increments (0.001) until there seems to be a detrimental effect on stability


Tuning method 2 - i call this the IGOR method :)

Same as above start with all rate and stab params at ZERO, but then firstly add in rate_D till you see the twitches, use rate_I to try and get rid of them if possible (at the level of rate_d that just causes the twitches to start) Then do your rate_P (remembering that rate_I should always be less than 50% of rate_P - Ive seen erratic behaviour if I is too high, you may have to back both I and D off if you find your I value is more than 50% of P).

Then do your stab as described above. If you do both methods you should end up with fairly similar values, if they differ plumb for somewhere in the middle. Always test every setting you arrive at with full throttle, leant right over.

Then fine tune in flight using channel 6 to mess with firstly rate_P and then stab_P.


Don't forget the setting i posted are for my small frame, may well be a bit out for yours. I'll try on the 3dr when it arrives. Let me know if this method works for you, if so, I'll be happier releasing part one of the guide, working in isolation here so some confirmation would be nice :)

Information about DSM2 protocol

  5. Inside scoop on a vendors modulation scheme
  6. Snapshot of information taken from :  
Hi there,
I am a new member of RCGroups but have been reading various posts for a long time time now. I have gleaned some good information from this forum at times and I would like to offer a thanks to all those members who took the time to write about what they knew. I guess this post will be my way of thanking them. I have been active in RC for a number of years and own a variety of electric and glow aircraft. Up until 3 years ago, I always flew on 72Mhz but I was introduced to the 2.4Ghz movement when I bought a Blade CX2 heli with the LP5DSM radio. That radio sparked my curiosity and I spent some time probing it with a digital storage scope to learn its secrets. Needless to say, my efforts produced limited results as my scope could not give me the detail I wanted of what was going on the tiny RF board. I wanted to know more. In the meantime, I expanded my stable of Spektrum products with the DX5e and a DM9 module with which I Spektrumized my JR XP7202 radio. Worked very nicely, by the way. But I was soon faced with the dilemma of whether to fully update my hangar to 2.4Ghz or not. I find that Spektrums equipment works well and I have never had any issue with it. I have several of their receivers, 6100's and a few AR7000. But, like anybody, I do not like paying too much for anything and, given the fact that most RC hobby related things are over-priced anyways, I especially did not like paying $80 for a 6 channel receiver or $90 for the AR7000, retail. The fact that there are now clone RX's available for <$15.00 proves my point, I think. I have opened these things up and there nothing about them, IMHO, that justifies these prices. Spektrum has recovered their R&D costs long ago and if they really wanted to gain market share and brand loyalty, they should adopt a little 'good product at a good price' attitude. Besides, from the various recall/service bulletins released by about their products over the past couple of years, there is no reason believe that their quality is any better. So, I wanted to see if I could gin up a Spektrum receiver clone myslef and I think I am very close to doing just that. I am in the process of writing firmware for a PIC16F87 that will control a UNIGEN LETO-LPA module and generate a Spektrum compatible transmitter module of my own. Yes, I admit to having a serious DIY streak. I don't see any problem of creating a DSM2 RX using a PIC or ATMEL chip either. In fact, the RX firmware will probably be easier but that will come later.

1) This post is about what is going on inside the Spektrum DSM2 protocol. You are advised to obtain the datasheet of the Cypress CYRF6936 WirelessUSB transceiver chip as well as the Cypress WirelessUSB technical reference manual if you want follow along.
2) I do not believe that anything I will be posting here about the DSM2 protocol can be covered by any patent as Spektrum has elected to use a third party 2.4Ghz transceiver, i.e. the Cypress WirelessUSB line of 2.4Ghz chips. Spektrum cannot claim ownership of any mode of operation of these chips anymore than Microsoft can claim ownership of a mode of operation of a serial port in a PC. Everything about the DSM protocol is based on the capabilities/features/internal working of the CYRF6936 chip, something they did not create.
3) The DSM2 protocol does use PN codes that Spektrum very likely created on their own and so I will, for now, hesitate from posting them because they may be covered by patent/copyright law. I am not sure if a PN code can be copyrighted or patented as they are used throughout the world in spread spectrum systems. I will say that the PN codes used by Spektrum are 72 bytes long and there are 5 of them.
4) The information here was coaxed out of a Spektrum DM9 module and an AR6100 using a Saleae Logix USB logic analyzer. Great product. 
5) The information here was produced in a moderately busy 2.4Ghz environment (3 2.4Ghz wireless routers on channels 1, 6 and 11, in the area).
6) Since I don't have 40 Spectrum TX's to fill the 2,4Ghz band and completely probe the DSM2 protocol, some of my assumptions may be wrong. 

On to the show....

What makes DM2 so special? The fact there are 5 levels of 'uniqueness' that keep multiple transmitters from interfering with each other. The first level is the RF channels over which the stick position information is transmitted. Spektrum DSM2 TX's automatically select a pair of open 2.4Ghz channels to start broadcasting on. No argument there. The allowed channels here in the US are channels 0 thru 79. Logically, only 40 Spektrum transmitters can be in use at the same time (80 channels/2 channels per TX = 40). But I have seen the marketing material from Spektrum that shows 40 Spektrum TX's active and a plane being flown (I assume using TX #41) right above them with no problem. I have also seen the reports of 72 ParkZone Trojans being flown at the same time at one of the major flying events. I have not been able to delve into the protocol deep enough to figure this out with any certainty but my hypothesis is that 2 transmitters can share the same 2 channels as long as they do not transmit at the same time. There may be a scheme in the TX that, if it finds all channels in use, it may locate 2 of the least used channels and synchronize its transmissions to the quiet periods between transmissions of other TX's using the 2 channels. Just don't know right now. By the way, data is transmitted using 8DR mode.

The Spektrum feature called 'Duallink' is actually frequency hopping. The transmitter switches between 2 channels in the 2.4Ghz band for each frame of information. Each 'frame' is transmitted twice, once on channel A and again on channel B a few milliseconds apart. It does not transmit on 2 channels simultaneously. The CYRF6936 just can't do that. The higher end TX's (more than 7 channels) actually transmit 2 packets of information per channel per 'frame'. The receiver (doesn't matter if it is a single CYRF6936 chip AR6100 or an AR7000/AR9000 with satellites) also jumps between channels to receive packets. When it receives a packet on channel A it then switches to channel B and back again.... 

The next 2 levels of uniqueness are the Start-of-Packet (SOP) pseudo-random noise (PN) code and the DATA PN code used for each channel. The CYRF6936 will only receive a packet of data if the SOP code matches that of the TX. No match, no reception of data; RX acts like it didn't hear a thing. If the DATA PN code does not match, then data is not decoded correctly, you get garbage. The PN codes used in DSM2 are actually 5 different 72 byte long codes from which an 8 byte SOP code and a 16 byte DATA code are selected and used to transmit data to the RX. Once again, read up on the Cypress documentation. The 5 distinctive SOP/DATA codes are distributed across the band in the following pattern:
channel 0 = PN code A
channel 1 = PN code B
channel 2 = PN code C
channel 3 = PN code D
channel 4 = PN code E
channel 5 = PN code A
channel 6 = PN code B
... etc....
this repeats up to channel 79. This means that a single SOP/DATA code can be used by 8 different transmitters simultaneously without interference because, following Spektrum's channel selection algorithm, they would be transmitting on channels 5 Mhz apart.

The next level of 'uniqueness' is the CRC seeds used to generate the CRC checksum transmitted with every data packet. There are actually 2 CRC codes; one for each channel selected by the TX, and they are derived from the Cypress CYRF6936 unique manufacturing code/serial number embedded in each chip. The second CRC code is generated by XOR'ing the first CRC code with 0xFFFF.

Lastly, there is the GUID. This is a 16 bit value, again derived from the manufacturing code that is transmitted as the first 2 bytes of every data packet.

So, the Spektrum system actually has a boatload of features that serve to protect each transmitters 'uniqueness' and reduce/eliminate interference from other 2.4Ghz sources. So why, you may ask, was there a number of Spektrum 'crashes' at the SEFF and other large flying events? My theory is this: I turn on my Spektrum TX and it is unaware of a whole bunch of other Spektrum TX's in the area due to distance/ geography etc... My transmitter selects channels X and Y and begins to transmit happily. Other TX's are on the same 2 channels as me but because my TX is unaware of them, our transmissions are not synchronized. Remember that Spektrum's PN code assignment scheme requires the use of a particular PN code for a particular channel. That means that there are now multiple TX's transmitting the same SOP and DATA PN codes on the same channels. We have lost the uniqueness of channel, SOP and DATA code. The only thing that now differentiates my TX from the others on the same channels is the CRC code and the GUID. My plane is flying nicely as long as it is close to me in my strong TX signal. But as I get closer to the other transmitters, the RX in my plane starts picking up packets from them. The data sheet of the CYRF6936 chip says that the receiver state machine will run to completion once a SOP symbol has been received. That means that the chip will not respond to anything else while it is busy trying to receive the rest of a packet. It doesn't matter if the SOP came from my TX or someone else's, the RX is going to finish receiving the packet and only after reception is complete can it determine if the CRC and GUID of the packet match the TX to which it is bound. If my theory about synchronizing transmissions is correct, lets say my TX begins a packet transmission slightly after the other TX, then our signals will overlap and my RX will receive the other TX's packet, not mine. This may go on for quite a number packets, perhaps long enough for plane to meet Earth. 

On Binding: RX's do not send anything back to the TX during binding. The TX provides the main CRC code, the GUID, and several bytes about the characteristics of the TX during binding. Number of channels, number of frames, resolution, etc... possibly a check sum. Binding is done using the slowest communications speed of the CYRF6936; SDR mode. I understand that there is now a CYRF7936 chip out but finding a comprehensive datasheet on it is difficult. One source says it does not support SDR mode and so it may not be possible to make a RX built around this chip bind with a DSM2 TX. Another source says it does. Don't know right now. 

Didn't mean to write a book here. I am willing post more detailed information if there is a demand. My time is limited so it may come in dribs and drabs.

The begining of my journey into RC world

How did I start this hobby? As a man, RC is kind a childhoold dream. I've start looking into this hobby for about 1 month ago.
But considering the price, I kept canceling my plan to hop into this hobby. Until about 2 months ago I saw the advertisment from Hobbyking about the bellow transmitter.

It's Turnigy 9x, a 9 channels computerized transmitter, the price was so tempting, less than $40. I knew that branded Tx like Futaba, Spectrum, JR, etc priced more than $100.
Well Turnigy 9x is unknown brand, made in china, of course the price is so cheap.

But the price is so tempting, so I do seach on google about this Radio. It was a surprise for me that many people in Australia, US and Europe are talking about this Radio.

I also read a review from Bruce Simpson about this Radio, he was veteran in RC hobby with more than 40 years experience in the hobby, and he gave good feedback on this Radio.

Here is the radio with lots of modification:

1. Move the built in 2.4 Ghz Antenna to the module so, this radio become pure modular radio.
2. A cable use for FrSky telemetry data when using FrSky telemetry module, the telemetry information will be shown in the built in LCD.
3. Programming cable hid inside battery compartment, and using 1500mah Life battery (upto 1 week baterry life). The programming cable use to upgrade the firmware or backup / restore model settings.

3. The splash screen during start-up, is that my name? You can even change the logo.

 And more about the Radio later.....