Reprogramming Turning 9x transmitter with custom firmware

Tue, 1 May 2018 (tags:diy, multirotors)

I was unhappy with limited options of my transmitter so I decided to re-flash it, for that I needed to "tap" ISP header to the pins of the MCU. So I opened the transmitter:

Then I used dremel to make hole for fit pin header, I wanted to use 2x5 but had only bigger variants available. I could use pin headers without the socket shell, but  I would be worried that after years I would forget which way to connect the ISP cable, so there goes 2x8 for better reason :-)

Probed the MCU pins with the PCB to find good test points or spots to solder mi ISP header:

Very easily available points were found so no precision soldering is required:

Presoldered the ribbon cable and gave it bit extra of flux (don't want to mess up the solder points on the PCB):

After soldering all of them, I hotglued most of the wires to make sure they will not get undone due to vibration or other abuse over the years:

Soldered the pin header with heat-shrink tubes for each connection:

The ISP pinout is as following (decide if you want 3x2 or 5x2 pin headers).

Epoxy glued everything to make it moisture and vibration/abuse proof:


After everything is done I used standard variant if Er9X firmware and I'm very happy with it, it can do SOOO much more and I can happily use the transmitter with different projects/profiles/robots. Used it in the past for few drones, crawler robots and testing lampbot as well. Even on the photos the glue doesn't look good, but I have to say it works very well. After 4 years of use didn't get a single problem with the connector, I'm going through a huge backlog of blog ideas so this mod is already matured/proven at the time of writing this blog entry.

Google Hashcode 2017

Wed, 1 Nov 2017 (tags:contest)

Google has its own contest called Hashcode which happens each year with thousands of attendees and hundreds of hubs all around the world. Yet it never happened in my college and in my city (WIT/Waterford), so I decided to change this.
After setting up the posters in our campus and with a dedicated online forum for people to socialize who are interested in the contest, I got a good few interested students to sign up. The contest was open to professionals as well so in the end some engineers from local companies joined as well. Not all interested followed through with registration and one whole team canceled in the very last minute, but still in the end I got 13 contestants and 4 teams. For small college and first time event it’s not that bad.
Have to say Google’s staff responsible for the contest was very helpful, outgoing and made the organization part easier on me.
Of course few things went wrong, original premises got canceled and I had to find replacement premises quickly, I think the main culprit is that it happened in very late hours, which meant that not just the hosting company, but owner/management of the building had to change few things with security to allows us stay there late. Because in these contests each minute can count, therefore I needed to be selective and find a place with a decent/stable internet connection so there will be no hiccups during the contest. Because I was intending to compete in the contest as well, having to resolve some issues during the contest would affect my performance as the contestant.

The big day

Few things went wrong and things were not perfect, but overall it was good. I had Google’s goodies package, prepared the balloons and  I designed and 3D printed keychains for everybody to give it some personal touch. 
The contest challange itself was not just a pure theoretical dry textbook problem, but it had YouTube theme, which was a nice touch. If anybody is interested I’m attaching here the spec and input files for the first round and for the final round as well.


What was cool was that our team won the local round in the WIT hub, placed 20th in Ireland, then placed 3rd in Ireland in the extended round, which put smile on my face for a good while.

VMware IO causing high cpu usage

Thu, 30 Mar 2017 (tags:vmware)

At one point I had to move some VMs to a NTFS partition and forgot that the ntfs driver can cause overhead. For regular use it's not noticeable as much, but for high IO it can create high CPU load.

The mount.ntfs was creating lot of load on the CPU. There are some workarounds, for example to change options in fstab which I didn't want to touch because they are tuned for some specific application which I don't want to break. Then there are ways where VMware can cause less IO, which can cause moving files to /tmp, or to keep them in memory with mixed experiences with different people. Or just to move it to ext partition, because I didn't like any other approach I just quickly resized the NTFS and EXT partitions and moved the VMs to the ext.

Flashing BLHeli on Turnigy Plush25A nfet ESC

Sun, 22 May 2016 (tags:diy, multirotors)

I wanted to upgrade firmware in my ESCs for very long time and only now I managed to do it, so I documented it as well (in case I will have to go back to it). There are plenty of alternative firmwares like SimonK, but BLHeli is now the most comprehensive actively developed firmware, it's mature in features, reliability (on old revisions enabling damping could burn down your ESC in mid flight) and convenience (it's really pleasure to use).

I was postponing this upgrade for very long time, worried that I will waste a lot of time (and always something goes wrong) for minimal gain and I was wrong, I experimented with GPS, optical flow tracking, sonars. But actually upgrading the ESC was very fast (everything worked as it should) and the improvement is extreme. So happy feelings from the new firmware, so smoother and quite and yet fast in response...

First I flashed the non-nfet version without damping just to see some improvement without any risk of burning and after 15min flight I was really impressed. Then I flashed the nfet firmware which allows damping and the result is awesome. People try to describe it in words, or in videos and there is nothing like to feel the difference yourself. Probably nobody regrets flashing the ESCs and I would recommend it to everybody.

I have couple ESCs spare, so I experimented with spare one first. Removed the heatshrink tubing, confirmed the pins with PDF of the F330 CPU, labeled even power pin in red (which we will not use, we will power device directly from multirotor, or from battery, not from the programing interface).

This board is nfet version and is slightly bigger, compared to older model of this board which used pfet transistors. Nfet transistors switch much faster which allows faster timings without a risk of destroying the transistors. This faster timing can be used for damping feature which will break the motors when lower RPM command is given. The motors do not free roll anymore and when I tested it without props the response is instant to any RPM change, very impressive. Sounds wasteful but it's not as bad as somebody would expect, the increased control over the multirotor is well worth it. This feature is so desired that some ESCs even support regenerative damping.

Instead of soldering the pins to some header and modifying each board I decided to do less destructive and faster approach, creating a connector for these pins. Found few wires (note: they do not match colors of the diagrams) and soldered them to spring contact probes I had laying around. Then took bottle cap and hot glued probes to it, till the hot glue was warm I tried to test fit the probes and adjust them as I needed to make correct contact on the board. I needed to be careful because 1mm aways from the ground pin is the power, if I would shorcircuit the power rails by slight movement I could damage lot of stuff. But thanks to the probes which had special head they bite a bit into the copper pads and they will not slip if I applied the correct pressure on them. Flashing takes under 10seconds so it can be done pretty quickly.

Instead of hard to obtain and expensive Silabs Toolstick board to flash the ESCs just a regular Arduino can be used. I had Duemilanove spare, but many others are supported (look at BLHeli documentation). Connected the probe wires to the Atmel ISP connector, specificly to the SPI MISO/MOSI pins.

Downloaded BLHeli, at the moment of writing this article v16. is most recent. On bottom of the page are PDF links to supported ESCs and on top menu is link to manuals where all other flashing boards are described as well. Description how the BLHeli firmware works is in the application under BLHeli Info -> Manuals.

Opening the app I first needed to flash the Arduino, choosen Duemilanove (tried higger baud but only 57600 worked for me) and then clicked Arduino 4way interface.

Then I choosen the PB3PB4 file, the MULTI is meant for configurations where you access multiple ESCs at the same time.

In "Select ATMEL / SILABS Interface" I selected option B.

Then powered the ESC and connected my probes to it, clicked on Flash BLHeli on the bottom and chosen the Nfet Plush 25A (the non Nfet woudn't allow dampening). The MULTI means that it's for multirotors, the other versions are for helicopter's tail and other applications.

After flashing was working I clicked Read Setup. And left values at default (to enable dampening the PWM frequency/damped has to be set to 3).

When the setup was working I went to flash the real ESCs and instead of taking them apart and removing the heatshrink tubing I decided to do less destructive approach. Through the tubing I can see/feel the ICs, with them I can orient myself and do precision cuts to expose only the programming probe pins. It can be covered with electrical tape and still quickly accessible for the future if I will decide to change settings or update to newer version.

Plus now each ESC can be upgraded while it's connected to FC and fixed to the airframe so the whole process is painless and fast.

As last I calibrated the throttle on the ESCs. I personally prefer to connect all ESCs together to the same channel 3 (throttle) on my RX, put throttle to the max, power TX, then power ESCs. Wait for the beeps to register calibration and the lower throttle to minimum and again wait for the beeps to confirm. Then I power down everything and connect ESCs back to FC. If it didn't work, I would repeat the process and be more careful about the order, it's very important.

NOTE: If you value your eyesight or hands then probably you should remove props before doing anything mentioned above :-) Probably it would be nicer to mention it on the top, but you should still have some common sense and self-preservation desire without any direct instructions to be careful :p 

Non-flyable drone

Mon, 16 May 2016 (tags:diy, multirotors)

I needed a separate craft to test my software I'm developing and wanted avoid any risks compared to real multirotor craft. With help of PpmPwm and 1pinDpad library to create RC controller emulator, this emulator can be connected directly into the flight controller. If this would be flyable drone you would have these following risks:

  • Danger from propellers (wasting time with removing/attaching them)
  • My drone is not meant to idle disarmed for hours (some components require some air circulation as cooling)
  • Requires elaborate setup, drone itself needs a power source, video receiver needs another power source, LCD display needs yet another power source, RC transmitter needs guess what, a power source. And either into hassle and maintain many LiPo batteries. So after experiments you need to go and discharge the residual charge, when you are using it you need be careful not to discharge them too much. If some features require multiple days you need to store LiPo safely because of the explosion hazards. Or you will make extension leads to power all components from single power source, but then you need to modify you RC transmitter to accept AUX power.
  • If you want to fly next day and you want to work on the firmware day before you need to spend extra time backing up eeprom settings and last stable firmware flash file.
  • You need a lot of desk space to fit laptop, drone, video reciever, power extension/harness and RC transmitter together on a desk. 

Because non-flyable drone was never meant to fly, some parts which are meant to transfer data wirelessly now can be connected directly (less components and less power sources needed). It's compact on a desk and to store away, it's safe to leave it powered for prolonged periods, even over the night (no risk of LiPos explosions and some components have extra heatsinks which would be too heavy for flyable drone). You can experiment with firmware without worry that it could affect next day flying. No hassle with propellers. It is fast to setup, requires only 1 power jack and 1 ISP connector to flash the device.