Radio Board v2

Posted on March 15, 2013 by

After a too long break we finally got back to debugging the problems in the radio boards.

RF measurements

RF measurements

There was’t actually anything seriously wrong, mainly smaller issues that together made things look worse than they were. Version 1 did have some hardware design bugs but they were quite quickly spotted.

The first prototypes don’t work together with the ITead boards because there seems to be 50kHz offset in the radio frequency. That might be because the first prototypes are single sided while the reference design assumes double sided. We are not RF engineers so it might be anything else as well 😉

It also turned out that soldering 0.5mm pitch VQFN chips without proper tools or experience can easily leave some pads unconnected. Combining that with initial software and interoperability problems with the old boards, things were not looking good. After figuring out these deficiencies we started to make good progress again.

Radio board with a battery

Radio board with a battery

Now we have couple of reworked v1 boards with the TMP275 temperature sensor and they are working reliably. The software is measuring the battery voltage using ADC and getting the temperature over I2C from the TMP275 and sending both over the air.

We have done also some tests with the low power modes. The whole board consumes 7uA in a sleep mode:

Radio board power measurement

Radio board power measurement

The low consumption is in LPM3 with ACLK running so that the chip can wake up using a timer interrupt. It should be possible to get down to 1uA in LPM4 but it’s still a bit unclear to me if that needs an external signal to wake up. Even with 7uA we are quite confident that long operating times with small batteries are achievable 🙂

Now that the boards are working, we fixed the design bugs and ordered v2 boards from ITead. Hardware-wise next step is testing different antennas to achieve good range with small antennas and software-wise we’ll combine the low power modes with temperature measuring.

Posted in Hardware, Software | Tagged , , | 14 Comments

First radio waves

Posted on May 10, 2012 by

First prototypes of our Radio Board v1 have been implemented succesfully. The board is based on TI’s CC430 technology platform. The exact model of the chip is CC430F5137 with 32K of flash and 4k of RAM, although these prototypes are using samples with only 8K of flash.

The CC430 combines an MSP430 MCU and a CC1101 sub-1-GHz radio module.

The MSP430 is a cheap ultra-low power 16-bit microcontroller platform. You can get a LaunchPad development board with two MSPs and a USB cable for 4.30$. There was a one euro difference in the price of the CC430 and the plain CC1101 radio in Digikey so we didn’t really consider using the plain CC1101 directly with STM32 but went for CC430 where we can have the SW stack for radio running in a dedicated MSP430.

The CC1101 can use frequencies like 868 MHz (Europe) and 915 MHz (USA) but we are using 433 MHz (Worldwide) for better structure penetration. Internally the CC430 is using a cpu interface with memory mapped registers for communication between the MCU and radio core. The CC1101 is quite convenient to the application developer as it can send and receive CRC checked variable length messages sent to specified address.

 

Home-made Radio Board v1 prototype

First Radio Board v1 prototype

 

Our initial plan was to use Dash7 as the radio SW stack but it doesn’t fit to 8K and seems to be quite an overkill for our initial use cases. TI provides a free but proprietary stack called SimpliciTI but the license seems to restrict redistributing the source code (although I’m no lawyer) and we prefer open source solutions anyway. Luckily TI provides a nice set of RF examples for the CC430 and since the CC1101 provides a high level packet handling API, one can get quite far by using only this API.

The MSP430 is well supported in Linux and e.g. Ubuntu provides msp430-gcc and msp430-gdb. The CC430 RF examples do contain a couple of lines specific to TI’s proprietary Code Composer Studio IDE but they can be relatively easily ported to GCC. Connect the LaunchPad via USB to your Linux box and your CC430’s TEST and RST to the launchpad and you are ready to go. More about the exact instructions later.

 

CC430 prototyping

Mimicing TI's CC430 evaluation board with leds and a button

 

Currently we are implementing the CC430 firmware for better interoperability with the Control Board and finalizing the Radio Board v1 gerbers for PCB order from ITead Studio.

Posted in Hardware | Tagged , | 14 Comments

Wiki opened

Posted on March 8, 2012 by

We now have a wiki. Not much there yet but hopefully more and more in the future. There are some details, including a lengthy list of bugs in the Control Board v1. All of those will be handled in a way or another for the v2.

As a bit of a side track for the UAV stuff we are now looking into home monitoring systems. First goal is to collect temperature readings from several locations around the household. The monitoring network is wireless, perhaps Dash7 based and the readings are read by a PC using the v2 of the Control Board. The radio will be based on TI’s CC430 and there’s some initial info about that in the wiki’s Radio Board v1 page.

Posted in Tools | Tagged , , | Comments Off on Wiki opened

Control board PCBs arrived

Posted on January 24, 2012 by

We have now received our first control board PCBs from ITead Studio. It took two weeks from placing the order to receive the boards. ITead provides quite cheap services. You can get a 5cmx5cm 2-layer PCB at less than 2$ per piece and it includes the shipping costs. At those prices you can’t expect highest quality but we wanted to see if it would be good enough. The smalles used wire width in the design was 12mil and it looks good on the board. Also the drill holes are where they are supposed to be. The biggest quality problems are in the silk screen. In most boards we received it’s a bit off and quite smudged. Outline of the board is 96mmx48mm

As this was a completely new desing for us we were quite eager to see what works and what doesn’t. The board assembly is quite easy. Soldering the STM32 LQFP64 cased chip might require some skills or a microscope.

After assembly we could see that the board starts up and works. So far we have found one bigger issue when using the USB to power the board. The 5V from the USB is connected to PB13 for detecting the USB client mode. The problem is that the used PB13 pin works properly only after setting the pinmux correctly in the software. Before that the 5V leaks through the chip and 5V can be measured from the power rail. This is not nice. I tested that with the F4 discovery board and PB13 pin the same behaviour can be verified. The difference with F4 discovery design is that instead of PB13 the PA9 is used for detecting the USB 5V. Possibly the PA9 pinmux defaults internally differently so the problem can’t be seen on that pin.

Otherwise the issues we found where more SW related. ChibiOS got F4 support just recently and it runs on our board nicely despite some missing tweaks.

Posted in Hardware | Tagged , , | 2 Comments

IMU sensor comparison

Posted on January 4, 2012 by

Continuing the quest started earlier for a good IMU, I listed some popular accelerometers, gyroscopes, magnetometers, and pressure sensors with their most(?) important attributes.

I have to admit that I’m quite unexperienced with these so I could have easily left off something important or listed something irrelevant. And trying to figure out the exact behaviour for several sensors is too time consuming so at least the maximum sampling rate might not be what you actually get out from the sensor in all cases. All corrections are welcome.

Accelerometers

[table "4" seems to be empty /]

Judging from the numbers the MMA8451Q from Freescale has decent sensitivity and low noise. And it’s really cheap at Digikey unless I’ve missed something. MPU-60×0 is the most sensitive but with highest noise. It’s also the most expensive and it seems to be really hard to buy.

Gyroscopes

[table "3" seems to be empty /]

I’ve understood that the gyroscope is the most important sensor in an IMU as it provides the change in the orientation, the rest are used just to compensate the gyroscope drifting. Based on the numbers the MPU-60×0 is the best one. It’s also quite expensive but since it contains both the accelerometer and the gyroscope, it’s only 6 € each. The MPU-3050 is similar to MPU-60×0 but doesn’t have internal accelerometer and the noise is slightly larger.

LSM330DL from STMicroelectronics contains also both the accelerometer and the gyroscope. It doesn’t quite match up to MPU-60×0 but at least Digikey has plenty of LSM330DLTR in stock.

Magnetometers

[table "5" seems to be empty /]

There seems to be clearly less options in magnetometers and their maximum sampling rates seem to be less than with the other sensors. The LSM303 from STMicroelectronics is an exception which makes me wonder if I’ve read the datasheet correctly (EDIT: I guess I haven’t, read more from rcgroups.com in here).

The HMC5883L from Honeywell is one of the most popular magnetometers in quadrotor IMUs currently but its sampling rate is quite low.

Pressure sensors

[table "6" seems to be empty /]

MS5611 from Measurement Specialties is probably the best sensor at the moment but like the MPU-60×0 it’s hard to actually get one. BMP085 from Bosch is common even though its sampling rate is really low. The low sampling rate is not that big issue as the pressue sensor used to control the hight which is not changing as rapidly as the orientation of the device.

All in all, it’s more tricky to select the sensors for an IMU than I originally assumed. Magnetometers doesn’t have any obvious winner although the LSM303 could be a good solution for a high sampling rate IMU. For the rest the MPU-60×0 + MS5611 would be nice but since their availability is so poor something else could be a safer bet. LSM330 + LSM303 + BMP085 would enable fast orientation calculation (EDIT: or not) and decent altitude estimation for slow paced movement.

Posted in Hardware | Tagged | 3 Comments

Some IMUs and sensors

Posted on December 14, 2011 by

Everybody needs an IMU. We need one too. But why buy something ready when you can create your own and learn? 🙂

We’ve been following some IMU projects while trying to figure out what kind of IMU we would like to create for our control board. The next table lists some IMUs that are more or less related to quadrotors.

[table "1" seems to be empty /]

 

The next table lists the sensors used in the above mentioned IMUs. I didn’t list some of the sensors (namely LPR530AL, LPY530AL, LPS001DL, ISZ500, and IDG500) as they are not available anymore in small quantities or not recommended for new designs.

[table "2" seems to be empty /]

 

Some vendors have combo chips having two of the three needed sensors in one chip. It seems that the magnetometer is very sensitive and it’s good to have it as a separate chip while the accelerometer and the gyroscope can be in one chip.

MPU-60×0 is one of these combo chips but the firmware makes it a special one. It can do the sensor fusion calculations internally and provide the yaw, pitch and roll values for the host processor. This simplifies the software on the host processor and frees up some processor time. To provide good yaw values the MPU-60×0 includes an auxiliary i2c bus for the magnetometer. After the host processor has initialized the magnetometer the MPU-60×0 reads the values from the magnetometer providing nice data for the host.

OTOH, having the sensor fusion algorithm running on the MCU (maybe DSP optimized on STM32 F4?) gives the freedom to update the algorithm at any time, and changing a sensor is easier as it doesn’t mean changing the sensor fusion algorithm.

While the MPU-60×0 has both the datasheet and register map published, the register map seems to be missing the parts describing how to actually enable the 9 DoF instead of plain 6 DoF.

At the moment the hot sensor combo for an IMU seems to be MPU-60×0, HMC5883L and MS5611-01B. The downside, in addition to missing parts of the register map, is the availability. There aren’t many distributors selling the MPU-60×0 and even fewer selling the MS5611-01B. It’s risky to design a board with components that are difficult to acquire.

So, what do you think would be a good IMU? Maybe LSM330DLC + HMC5883L + BMP085?

Posted in Hardware | Tagged , | Comments Off on Some IMUs and sensors

Setting up a basic ChibiOS project

Posted on December 5, 2011 by

ChibiOS is a nifty little OS for a selection of microchips, most notably chips from the STM32 family.

There are plenty of examples how you can start working with ChibiOS in Eclipse and other IDE’s, and also how to compile the demos from command line with make but not a lot for working with an actual project without an IDE. Usually the guides say to copy a demo and hack away, which works for IDE’s quite well. While this is also the best way to get started when you use just command line tools it’s not really a clean way to work with a “real” project.

Fortunately, ChibiOS is really easy to set up so that you don’t need to muck about in the ChibiOS code tree at all which is nice when you eventually want to upgrade to a newer ChibiOS version. We have a skeleton project in github (also downloadable as zip for stable 2.2.7 and unstable/trunk versions of ChibiOS) which can be used to bootstrap a new make-based ChibiOS project, but do read on while downloading since it’s useful to know the project structure in case you want to tweak it.
Continue reading →

Posted in Software, Tools | Tagged | 1 Comment

Designing a robot control board

Posted on December 4, 2011 by

Basic idea behind starting to create this board was to create an open and easy to develop platform with the latest technology. We started from scratch so that we could learn cool things but also because it gives us the possibility to create and develop even cooler things in the future.

The board is created around the STM32 32bit ARM Cortex microcontroller technology. It’s designed as a robotics platform base that could be used also to various other purposes. The board is designed to be easily extendable with sensors, servos and ESCs for driving brushless motors. It can also be used together with others boards for creating more complex systems.

Before this board we have done some simpler HW designs but this is our first board with 0.5mm pitch soldering. For cheap and easy manufacturing we used only a two layer PCB for the design. As the HW design is completely new we decided to do the first prototype by doing ourselves the PCB etching with chemicals and UV light. DIY PCB etching is not always worth the effort with two sided boards but it’s a fast way to do prototypes compared to ordering the PCB from a distant place. Here is the end result with some soldered components and jump wires replacing the bottom layer wires.

As software platform we first took a look at the FreeRTOS but then decided to use the ChibiOS as it has better support for the STM32 family, it uses GPL license, it’s currently a very active project and also that in Linux development environment it is easier to setup and take in use than the FreeRTOS.

With the prototype board we could test what works in HW and SW side. Based on the testing we made only few changes to the schematic. The main features for the board are:

  • STM32 F4 168MHz Cortex-M4 microcontroller
  • 5V input voltage and 3.3V internal and logic level voltage
  • 8 PWM connectors for servos or Brushless ESCs
  • JTAG
  • USB OTG
  • XBee socket
  • Several IO interfaces:
    • I2C, SPI, UART, generic IO, analog inputs

The available IO pins are arranged so that extension boards can be stacked to the control board. There could be one big or 2-3 separate smaller extension boards providing eg. IMU, GPS and connection to a Linux board.

For the final PCB we still had to fine tune the silk screen, add a logo and do few other minor tweaks.
Here is the final PCB viewed with gerbv. Now the PCB design is ready to be sent to production.

 

Posted in Hardware | Tagged , , | Comments Off on Designing a robot control board

Compiling STM32 examples in Linux

Posted on November 27, 2011 by

ST has quite a lot of source code examples for their evaluation boards introducing about all features of the boards. The downside is they support only commercial compilation environments, like IAR EWARM, MDK-ARM, RIDE, TASKING and TrueSTUDIO.

The examples can also be compiled in Linux with relatively little effort: add a Makefile, C library stubs and fix the case sensitivity issues in the filenames. This blog post is about compiling STM32 USB device/host library for an STM32 F2 board although the instructions hopefully apply to other examples as well.

To get started, git clone the example Makefile and stubs file from our Github repository and unzip the STM32 USB device/host library under the cloned tree:

git clone git://github.com/snowcap-electronics/stm32-examples.git
cd stm32-examples
wget http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32_f105-07_f2xx_usb-host-device_lib.zip
unzip stm32_f105-07_f2xx_usb-host-device_lib.zip

Fixes needed to unbreak the ST code:

  • Remove one extra white space from an #include in STM32_F105-07_F2xx_USB-Host-Device_Lib_V2.0.0/Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F2xx/stm32f2xx.h line 6832.
  • Make a symbolic link from STM32_F105-07_F2xx_USB-Host-Device_Lib_V2.0.0/Utilities/STM32_EVAL/STM322xG_EVAL to stm322xg_eval to match some of the include paths.

One thing missing from the example is the stubs and implementations for certain C library functions not provided in the toolchain. I’ve taken them from The STM32 Discovery Scrapbook from Nano Age and it’s already included in the STM32-examples with the Makefile.

I’m using Mentor Graphics’ (formerly Code Sourcery) toolchain because of old habits. You can get the EABI toolchain from here. I’ve used the IA32 GNU/Linux TAR package since it’s easy to take into use, just untar it and you are done. I’ll probably start using upstream GNU GCC releases some day.

The Makefile in the cloned STM32-examples compiles the USB Host example for the STM3220G-EVAL evaluation board. See the comments in the Makefile to change them.

To compile the project, run make:

make CROSS_COMPILE=/path/to/arm-2011.03/bin/arm-none-eabi-

To program the software to the chip, see our last post about OpenOCD and GDB or use e.g. STM32flash to program the flash over serial.

Posted in Tools | Tagged , | Comments Off on Compiling STM32 examples in Linux

OpenOCD with SWD

Posted on November 21, 2011 by

It’s often tricky to know what’s happening inside a microcontroller when everything is not going as planned. This post is about enabling GDB with chips providing the SWD interface, e.g. STM32 chips.

For this you need an SWD dongle. If you are up to some DIY and want it cheap, check the previous post about modifying STM32 Discovery for the purpose.

You can get the patched (thanks Simon Qian!) OpenOCD from our Github repository: https://github.com/snowcap-electronics/OpenOCD-SWD

Fetch, compile and install it to /usr/local/openocd with:

git clone https://github.com/snowcap-electronics/OpenOCD-SWD.git
cd OpenOCD-SWD
./bootstrap
./configure --enable-maintainer-mode  --enable-vsllink --prefix=/usr/local/openocd
make -j4
make install

To program a new software to the F1 Discovery’s F100, connect CN3 pin 1&4 and 2&3. This allows SWD communication from the ST-Link’s F103 to the Discovery’s F100.

Start OpenOCD:

sudo /usr/local/openocd/bin/openocd -f interface/vsllink-swd.cfg -f target/stm32f1x.cfg

You should get something like this:

Open On-Chip Debugger 0.6.0-dev-00247-g1981fa8 (2011-11-20-16:55)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : must select a transport.
Info : OpenOCD runs in SWD mode
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x33)by Simon(compiled on Oct 25 2011)
Info : USB_TO_XXX abilities: 0x00000008:0x00000040:0xC0000006
Info : clock speed 1000 kHz
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: stm32.cpu -- clearing lockup after double fault
Polling target failed, GDB will be halted. Polling again in 100ms
Polling succeeded again

Then start GDB in another window:

arm-none-eabi-gdb -ex "target remote localhost:3333" firmware.elf

And program it to the F100’s flash:

(gdb) load

For more GDB instructions, check out the GDB and OpenOCD page under http://openocd.sourceforge.net.

Posted in Tools | Tagged , , , | Comments Off on OpenOCD with SWD

The cheapest SWD dongle: STM32 F1 discovery

Posted on November 21, 2011 by

There are two common big problems when playing with embedded software. How to get that to the chip and how to debug why nothing is happening.

Many modern chips include a bootloader embedded in the ROM code that can program the firmware to an empty flash. But not always, or maybe the pins used by the bootloader logic are used for something else. Still you need something else for the debugging.

JTAG solves these problems. Or SWD in this case. SWD is a 2-pin electrical alternative JTAG interface with the same JTAG protocol on top. To benefit from that you need SWD support from the target chip and you need a dongle that goes between the chip and you development PC.

The cheapest way to get an SWD dongle is to buy an STM32 F1 discovery (10€ from Digikey) and replace the ST-Link firmware in it with a modified Versaloon firmware. The downside is that you need Windows and an another Discovery for modifying the first one..

We started with the instructions in http://takenapart.com/?p=82 and here’s how we did it:

  1. Get the Versaloon firmware modified for STM32.
  2. Install the ST-Link utility for Windows and the USB driver.
  3. Make sure you have an F1 Discovery and Fx Discovery (for flashing the target. We tried first with F1 but eventually succeeded with F4.).
  4. Solder wires to SB6 and SB10. You can try just holding the wires in the vias just below the “A” in “DEFAULT” but the connection may not be sufficient for the programming. 

    Wires in pads SB6 and SB10

  5. Connect the SB6 to SWD pin 2 in the F4 Discovery.
  6. Connect the SB10 to SWD pin 4 in the F4 Discovery.
  7. Connect the GND and 5V from the F4 to F1.
  8. Remove CN3 jumpers from both Discovery boards.
  9. Connect an USB cable from Windows PC to F4 (you should see leds turning on on both Discovery boards).
  10. Start the ST-Link utility (HELPME: how to do this from Linux?)
  11. Choose Target -> Connect. This may connect and then disconnect if the connections to SB6 and SB10 pads are bad.
  12. Choose Target -> Program & Verify to program the firmware obtained in step one to the F1’s ST-Link F103. Disable the Read Out Protection when asked to. If the programming succeeds only partly, the connections to SB6 and SB10 pads are probably bad.

Now you have a Versaloon firmware running in the ST-Link part of the F1 Discovery. If you want to connect the SWD from ST-Link to the F100 on the same discovery, connect CN3 pin 1&4 and 2&3 but if you want to use the ST-Link as an SWD dongle with some other board, make sure to leave CN3 pins open.

Check the next post for using your new SWD dongle with OpenSWD for programming and debugging your STM32 chips.

Posted in Tools | Tagged , , , , | 5 Comments