Tag Archives: OdroidW


Vacation is almost over and I made lots of progress over the past 2 weeks.

A small recap here:

  1. ADC is working together with the camera and mpu9250. This was quite an adventure and resulted in a bit of hardware and kernel hacking. Details here.
  2. Changed from access point to Ad-Hoc mode. As soon as I did this, the rt2800 driver I’m using for the Alfa 036H card started crashing. It looks like a known problem and it happens on the desktop as well. So I switched to a TL-WN722 card.
  3. The new wifi card works ok, no more disconnects or driver issues. BUT the usb interrupt is killing all my CPU. I started optimizing both the usb driver and my network usage to avoid flooding the interface with many packets. This resulted in 1 week of kernel/driver debugging and a fixed 30Hz packet rate for the inputs.
  4. Once the wifi/usb driver started working reliably, I got another kernel freeze when the i2c driver timed out. A few days of debugging revealed nothing so I ended up increasing the timeout value from 150ms to 500ms. Seems ok for now.
  5. In some rare cases the wifi disconnects mysteriously. After a few days of work I figured out it was the combination of high CPU usage + high thread priority of the brain. This caused the USB driver to have big latency when serving interrupts (probably) and the wifi card to drop the connection. I fixed this by optimizing the PIGPIO library (10% less CPU), using the libpigpio.a instead if libpigpiod_if.a (the socket interface) and optimizing my code a bit more. Overall CPU usage dropped from 60-70% to 30-40% now.
  6. I recompiled the kernel to remove everything I don’t need and also optimized my pipaOS image to remove all cron jobs and services. I have a very clean image now that seems to be very reliable and boots in 20-22 seconds.
  7. The FIFO inside the mpu9250 seems to fail sometimes if it gets full. It’s 4096 bytes big and my sample is only 12 bytes big. So when it gets full some samples get split in half. For this reason I was resetting the fifo when it had more than 4000 samples but even this failed sometimes. It seems that the samples are not written to the fifo atomically by the mpu so when asking for the fifo size I would get any number – even odd number of bytes sometimes. I fixed this one by resetting in a different way – shutting down the fifo and reconfiguring it. Seems to work for now.
  8. I finished my UBLOX protocol implementation and tested with my RCTimer Neo6 gps but it kept loosing the fix. Seems like a hardware problem that I caused some months ago after a hardcore crash of my previous quad so I ordered a new GPS module. Note to self – finish editing the footage of the crash and post it here.


That’s it.

The end results of these weeks are:

  1. A very stable raspbian image with a very small kernel (2.1Mb vs 3Mb) and only 1-2 user processes after boot.
  2. Very stable i2c transactions with the MPU, the ADC, the Barometer and sonar.
  3. UBLOX GPS code with protocol detection is done.
  4. Ad-hoc wifi works very nicely now with stable connection.
  5. Lowered CPU usage and started using RT scheduling for the main thread. This results in a rock stable 100Hz main loop.
  6. Some optimizations for the USB fiq driver and the ath9k driver that I’ll submit soon.
  7. Input stream uses a non-reliable channel now with a fixed 30Hz frequency instead of the previous reliable channel. Works better in low-connectivity situations.
  8. I started to be familiar a bit with kernel and driver code. This will probably prove useful in the future.
  9. All the hardware that I’m interested in is now working and connected. This includes:
  • raspi camera
  • accelerometer / gyroscope / compass
  • barometer / thermometer
  • sonar
  • adc
  • gps
  • camera servo
  • motors


Now I’m working on creating a test rig for the quadcopter to check my pids. It involves a clothes hanger, zip ties, a chair, a wood stick and some strings. I’ll make a youtube video of this one in action but here’s a photo in the mean time:


Happy new year!


OdroidW ADC Fix

I finally found a way to use the 5T619 and the camera at the same time. It involves some hacking but it’s relatively simple and non-intrusive.

As you can see in my previous post the problem is that the PMC chip is connected to GPIO 0/1 – same as the camera. So we cannot use them at the same time.

The fix involves the following steps:
1. Redirecting the i2c pins from the camera connector towards i2c-1 on GPIO 2/3 (the user i2c bus)
2. Telling the GPU to use the i2c-1 bus on the new pins
3. Moving all my other i2c stuff from bus 1 which is now being used by the camera to bus 0 where the PMC is
4. Kernel config
5. Usage

There is one small complication though: i2c-0 will become the new user bus and it’s shared with the PMC. The PMC is on  GPIO 0/1 and the user-accessible pins are GPIO 28/29. To use each pair, it has to be first switched to ALT0 mode. There are some simple solutions to this and some more complicated ones.

So on with the changes.

Disclaimer: Do this at your own risk.


1. First expose the i2c pins from the camera ribbon cable. These are pins 2 & 3, and since pin 1 (3v3) would be very difficult to insert in the connector on its own – I redirect it as well. You can find the pinout here.


There are 3 wires from the camera cable – 3v3, SDA, SCL – going to 3v3, GPIO 2 and GPIO 3 on the odroid.

You need to solder some wires to these, long enough to reach the 3v3 and GPIOs on the odroid. To do that first carefully cut with scissors the 3 leftmost wires for about 1.5 cm. Then with a sharp blade scratch until you get to the metal part – but carefully not to cut it. Then simply apply some tin with the soldering iron and the rest of the plastic will shrink nicely – exposing more of metal bits. Use shrinkwrap to properly insulate the connection and apply some tape on the whole ribbon cable to strengthen it:

Connect the 3 wires to 3v3, SDA to GPIO2 and SCL to GPIO3:


2. Download the dt-blob.dts file from here and in the pins_rev2/pin_config/pin_defines section, do the following changes:

pin_define@CAMERA_0_I2C_PORT {
type = "internal";
number = <1>; //was 0 before
pin_define@CAMERA_0_SDA_PIN {
type = "internal";
number = <2>;//was 0 before
pin_define@CAMERA_0_SCL_PIN {
type = "internal";
number = <3>;//was 1 before

You can download my modified  file from pastebin if you are lazy in a hurry.
Follow this guide to compile this file into a binary blob on the odroid.


3. If you had something connected to i2c-1, connected it to i2c-0 on GPIO 28/29 pins. These are on the opposite side of the odroid as you can see here:




4. Kernel config

By default raspbian only shows i2c-1 in /dev/. Since now we’ll use i2c-0 as the user buss we need to expose it.
To do that, add the bcm2708.vc_i2c_override=1 parameter to /boot/cmdline.txt but _not as the last parameter_.
Reboot and you should have both i2c-0 and i2c-1 available.


5. Reboot and try raspivid -t 0 to check if the camera works. If it says that the camera is not found, there’s something wrong with your i2c connection or the dts. Check both.
If there is no error but you get no image there is something wrong with the ribbon cable. Reattach it, make sure it is properly in.

The tricky part is using the ADC.

For using the odroid 5t619 modules:
 If you use the odroid drivers make sure you change GPIO0/1 to ALT0 either from the dts or manually with wirringPi:

gpio mode 17 ALT0
gpio mode 18 ALT0

You could also fix them to change their mode for every access and recompile and redeploy on the odroid. The code is there already – just call the bcm2708_i2c_init_pinmode defined in the i2c-bcm2708 module (after you make it non-static) before accessing the bus. This is pretty involved though and requires a lot of testing so I would go for the dts/manual solution.


From C/C++:
You can do this using the excellent PIGPIO library :

set_mode(0, PI_ALT0);
set_mode(1, PI_ALT0);

If you want to use some other i2c device attached to the GPIO28/29 pins you have to make sure to first change their mode to ALT0:

//put 0/1 back to input to avoid having 2 sets of pins attached to the same bus (not sure if needed!)
set_mode(0, PI_INPUT);
set_mode(1, PI_INPUT);
//redirect i2c-0 to GPIO 28/29
set_mode(28, PI_ALT0);
set_mode(29, PI_ALT0);

In my case I use a stock raspbian kernel and use both the PMC and the IMU (and soon the SRF02) from C++. So I manually redirect i2c between the 0/1 and 28/29 GPIOs as I need to.

So far this works ok.


Good luck and let me know in the comments if you have any issues.

Odroid W ADC Fail!

2 days and 5 forum posts later and the picture is clearer. Let’s start from the beginning. To simplify I’ll refer to the Raspberry pi rev. 2 board and ignore rev. 1 and the A+/B+ (** check the notes for details).

The Raspberry pi has the i2c-0 and i2c-1 busses. The former** is used by the GPU to talk to the camera while the latter can be used by the user however she/he wants. Each of the 2 busses can be redirected to several physical pins by changing the mode of these pins:

GPIO 0/1  – ALT0 mode
GPIO 28/29  – ALT0 mode
GPIO 44/45 – ALT1 mode

GPIO 2/3 – ALT0 mode
GPIO 44/45 – ALT2 mode

Only one of these pairs can be activated at any moment per bus.

The camera is physically connected to GPIO 0/1 **. These pins are setup as inputs by default and the GPU will change them to ALT0 whenever it needs to talk to the camera but _switches them back_ to INPUT immediately after. If you monitor the mode of GPIO 0/1 you’ll see that most of the time they are INPUT with random switching to ALT0 0-30 times per second. It seems that the more movement the camera sees the more it talks to the GPU. It seems to be related to AWB and shutter speed.

So far – no problem. It’s pretty clear from the design of the Raspberry pi that i2c-0 is off limits and there is no way to synchronize the GPU access with the CPU – so i2c-0 cannot be shared between the camera and any other device. If one attempted to use i2c-0 and started ‘raspivid -t 0’ he would see weird things ranging from i2c errors, the image freezing for seconds, random noise on the screen or even the board completely freezing.


The OdroidW has a nice PMC 5t619 chip that provides 2 free ADC pins that I intended to use to monitor voltage and current of silkopter. The PMC uses i2c-0 to talk to the CPU so care must be taken to synchronize somehow with the GPU. This is what I’ve been trying to achieve the whole weekend…

– 1st  try: After every use of mmal I switched GPIO 1/2 mode from IN back to ALT0 so I can talk to the PMC. Didn’t work as it seems the GPU uses the bus even between calls to mmal (in hindsight it makes sense as the camera has to inform the GPU about starting and finishing transfers and the GPU has to set awb, gains and shutter speeds).

– 2nd try: Use a semaphore to trigger the ADC measurement in the mmal callbacks – hoping that after the callback I get a period of silence from the GPU. No such luck

– 3rd try: Give up using the hw i2c-0 bus and try bitbanging on GPIO 0/1. This was such a nice idea – let the GPU use the hardware i2c-0 bus and I’ll use bitbanging… Didn’t work as both the GPU and the PMC are connected to GPIO 0/1 pins – so they share the same physical pins….

So basically it looks like the OdroidW is not capable of using both the camera and the PMC at the same time because they share the i2c-0 bus but _also the pins_!!!. This could have been easily avoided by putting the PMC on some other GPIO and bit banging, or at the very lease putting it on i2c-1.

So now I’m back to the drawing board and started considering an Arduino mini board as ADC + PWM generator. Connected through i2c-1 probably..



** Rev.1 boards have i2c-0 and i2c-1 reversed. So i2c-0 is free while i2c-1 is the camera one. ** A+ and B+ have the camera using GPIO 28/29 pins to access i2c-0.

Odroid W ADC

One of the advantages of the Odroid W is that is has 2 onboard ADCs that are perfect for the current/voltage sensor. They support up to 2.5v max while the AttoPilot 90A/50V goes to 3.3v max. This reduces the range to 67A and 37V which is more than enough for the 50A silkopter will use at max throttle.

Hardkernel provided a Raspbian image with the modules needed to get the 5T619 chip functional – including the adc – but when I tried it a few weeks ago the mpu9250 was getting regular bus errors and even kernel panics.

A few days ago I decided to test some more on a raspberry pi model A, to eliminate any unknowns from the odroid w board. So I connected a SRF02 sonar to i2c-0 to simulate the 5T619 and the mpu9250 to i2c-1. Simply trying to talk to both of them resulted in kernel panics. After 2 evenings of debugging it turns out that the hardkernel raspbian kernel had combined transactions turned on and the i2c-bcm2708.c kernel module has an issue with combined transactions if one or both of the busses has heavy traffic. I managed to find the bug – a small one actually – and the kernel panic was gone.

So I could talk to the mpu and I could talk to the sonar and also the adc chip on the odroid board.

However, as soon as I started raspivid or raspistill – or anything using the camera – i2c-0 stopped working even after killing the process. Turns out that the GPU makes use of the i2c-0 to talk to the camera and it changes the SCL.0 and SDA.0 pins from ALT0 to IN. And it leaves them like that until a reboot or I manually change them back…

So now I have the ADC working, the camera working as well but not both together. My only chance is to change the i2c-0 pin mode back to IN after every call to mmal and hope the camera doesn’t use the bus between mmal calls. Hopefully this will fix the issue but it’s a very ugly hack.

At least I have ADC working, the battery module committed in the brain and integrating the battery capacity from the current readings.

Next I want to autodetect the number of cells in the battery and estimate the capacity at startup.

Also it would be nice if the ground station detected when the battery was replaced and ask for the capacity of the new one.

New Case

I’ve been working on the new case for the past 4 days and I have the first results.

The old case was too big, too crammed and it didn’t properly address vibration. The new case is smaller and lighter – thanks to the odroid w and includes better vibration damping. Also I will include damping at each motor mount.

Last night I printed the top and bottom plates and they are indeed small – the size of my palm. On top there will be a protective case and on the bottom a power box – with the battery + ESC.

Screenshot_2014-12-07-14-02-54 20141207_132901

The wifi card will be under the odroid, antenna pointing back. I have both whip and cloverleaf antenna mounts printed. The cloverleaf ruins the nice shape of the case as it is huge @8cm diameter.

The whole setup weights at around 600g, battery included. I should be able to get 25min of flight time with a 3S 2200mAh battery.

I also figured out a nice way to mount the blue wonder motors. I’ll go over the details in a future post.