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.

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.


MultiWii v3 and Flip EZ boards

Sat, 14 May 2016 (tags:diy, multirotors)

I'm working on one OSD firmware and I needed couple more flight controllers to test it with, so I decided to get few cheap and few not cheap FCs. Problem with the cheap ones is the lack of documentation, only few snippets here and there. I decided to identify all the pins I spend some time measuring things, looking at the board with microscope and looking at the datasheets and I identified all the pins and functions on the board. Concluded into one single high-res image, input and output ports are described in Atmel syntax and in Arduino syntax as well.

Quick facts (I wish they were condensed somewhere before I was buying this board):

  • MultiWii v3 board is actually Flip EZ clone and lot of information about Flip EZ will apply to this board (even it's easier to search for Flip EZ specs than for MWv3)
  • Front of the board is labeled with big white arrow with power LED inside it.
  • Uses Atmel Mega 328P chip, to flash it from Arduino IDE you need to select Arduino Duemilanove Atmel328P 5V 16Mhz
  • From above the board runs 5V and 16Mhz so other components connecting to it should run same voltage or use level shifters
  • Inside the MultiWii software in config.h you need to uncomment the #define FLYDUINO_MPU line as this FC is identified in MW as flyduino
  • For the USB comunication it uses SiLabs CP2102 chip and tested it on Windows / Linux (the CP210x driver works fine). Be careful: USB communication shares same pins as serial port, you will get into problems if you will have both of them plugged in at the same time.
  • For stabilization it uses 6 axis accelerometer + gyroscope sensor, but is lacking compass, baroscope and magnetometer.
  • 1x I2C port, you should be able to connect GPS and other sensors with it, should support multiple nodes on bus (for some GPS functionality you will need functional compass).
  • 1x Serial port, you should be able to connect Bluetooth but I personally tested only OSD (only 1 node on this bus is possible and it's even shared with USB do plug both of them at the same time)
  • The board has tiny ISP connector to flash firmware directly (in the image is described what pins mean what). It's much smaller than regular ISP connectors so you will need to make dedicated connector for it.
  • Input and output pins use standard servo pinout (signal, + voltage, ground). The + voltage in the image is called Vin and is separated from the rest of the board (more details about it below)
  • Input chanels are in this order: Throttle, Roll / Ailerons, Pitch / Elevator, Yaw, Aux1 and Aux2
  • For output channels easiest way is to flash it with MultiWii in desired configuration (tricopter quadrocopter etc...)  and then connect into MultiWii GUI to see what output channels are used. Have a look to reference image on the bottom.
  • There 4 more pins D8, A3, A6, A7 which are located on the corner of the board.
  • Board has two different voltages Vin and VCC. VCC is basically used by whole board and Vin is used with the servo connectors.
  • I seen other people struggle with this so it could be helpful to people. To power the board from the servo pins with Vin there is SOT 25 sized chip labeled LB50 which is MIC 5205 LDO low dropout 5V linear voltage regulator. Close to it are 3 pins, labeled them VLR, VCC and Vin. The voltage from Vin is feed into the 5V linear regulator and output is what I called VLR. This allows you to do following 3 things with the board:
    • Have separate voltages on board, do not connect pins and you can have separate voltage on servo connectors and separate voltage on USB, serial and I2C ports.
    • Bridge VCC and Vin with solder to power directly the board from voltage coming from input/output servo connectors. If you now have something like BEC connected on the output ports and power whole board with it, now you need to be careful not to connect USB at the same time (if you need to connect USB, just power down BEC first)
    • Bridge VCC and VLR to have the Vin stabilized down to 5V before powering the board, this is for cases where the input/output servo connectors have higher voltage than 5V. Again be careful not to connect any other power source like USB described above.