Category Archives: Firmware

Split – Arduino based RFM22B 433/868/915 MHz wireless module

Top side of Split RF module
Bottom side of Split RF module. Notice the counter sunk LEDs in the upper left corner.

UPDATE May 15 2013: Split is now available for sale on our website

We’ve been slowly working away on an Arduino based wireless module called “Split” and just got the first real prototypes assembled and working over the last week. The module is based around a Atmega328P and a RFM22B wireless module, so it is kind of like a cross between a Arduino Pro Mini and a RFM22B breadout board.

Specs and Features:

  • Operating voltage: 3.3V
  • Processor: Atmega328P with Arduino bootloader
  • RF Frequency Range: 433MHz, 868MHz, or 915MHz ISM band (depending on version)
  • RF data rate: adjustable from 0.123 to 256kbps
  • RF output power: adjustable from 1 dBm to 20 dBm
  • RF receive sensitivity: -121 dBm
  • Long range up to several Km with proper antennas
  • On board 3.3V regulator
  • PCB Size: 20mm x 38mm
  • All processor IO pins are brought out to header pins
  • Breadboard compatible
  • Programmed with FTDI Pro
  • A user LED and button connected to IO pins
  • Slide switch to allow the DTR signal from the FTDI Pro to be directed to an IO pin to allow programming of a remote Arduino processor

Split RF module connected to a FTDI Pro

There are three main ways we envisioned Split being used:

  1. As a standalone processor with wireless capability.
  2. As a generic wireless UART link with remote DTR control to allow communicating with and programming of a Arduino processor attached to the remote Split module.
  3. As a wireless IO link. Input pins on one end are mapped to output pins on the other end and vice versa.

We’ve done some initial testing with the RF22 library from open.com.au and it seems to work so that covers #1, and we are in the process of writing firmware for #2 and #3.

We are pretty excited about the long range wireless capabilities Split will give to a lot of projects.

Split RF module connected to the Mongoose IMU

User switch and LED at top.

If you are interested in this project, leave some feedback or a comment. Once we know how much interest there is, we can make some better plans for a release date.

Mongoose 9 DOF almost ready to launch!

Mongoose – the 9 DOF IMU with barometric sensor, and lots of other cool features – is almost ready for launch!!

We based our design on the popular Sparkfun Razor, updated the magnetometer, added a barometric pressure sensor, and improved utility and usability with a few other design features.

We’ve also taken the AHRS firmware written by Jordi Munoz and updated it to support the new gyro, magnetometer and the addition of the barometric pressure sensor. Also, we have a Windows GUI for showing all the sensor data as well as attitude and heading in real time.

Sensors:

  • ADXL345 – triple axis accelerometer (I2C)
  • ITG-3200 – triple axis gyro (I2C)
  • HMC5883L – triple axis magnetometer (I2C)
  • BMP085 – barometric pressure sensor/temp sensor (I2C)

Some of the features:

  • Complete inertial measurement system measures linear acceleration, angular velocity, and magnetic heading
  • Calculate altitude using the barometer
  • Temperature sensors built into the barometer and gyro
  • All sensor data is processed by the onboard Atmega328P and output to your computer or micro over the serial port
  • Preloaded with Arduino bootloader (select “Arduino Pro or Pro mini (3.3V, 8MHz) w/ Atmega328”)
  • All headers and mounting holes are on a 0.1″ grid to allow mounting to a protoshield or standard perf board
  • 9 user IO pins brought out to header. Add buttons, LEDs, servos, GPS…
  • I2C header for debugging or adding additional I2C sensors
  • On board power and status LEDs
  • On board 3.3v regulator allows powering from a single Lipo battery
  • small 1.6″ x 1.1″

We have the first batch assembled and tested. I’ll post a link when we get the store turned on.

Keeping the USB connected – LPC2148

So I just spent about a week debugging a USB problem on a project using a LPC2148.  I was finding that the USB would randomly connect and disconnect when plugged into the PC.  Sometimes it would stay connected for 10 seconds before disconnecting, sometimes it would stay connected for hours with no problem. I spent several days looking for firmware bugs and checking the USB signal quality, but everything looked good. With the disconnect time being random I assumed it had to be a hardware problem. It turned out to be a problem with both hardware and software. Apart from the D+ and D- pins, the LPC2148 has two other IO pins associated with the USB peripheral:  Connect (PO.31) and Vbus (P0.23). Connect is an output that is used to turn on the pullup to start enumeration. Vbus in an input to detect if USB power is present. On my PCB, the Vbus pin was not connected to anything (that was the hardware problem), but was configured as Vbus instead of P0.23 (that was the firmware problem). It looks like the chip is hardwired so that if you have the “Vbus” pin enabled, the logic level on that pin controls the “Connect” pin. So in my case the floating Vbus pin was randomly going high and low causing the USB to connect and disconnect. Configuring the Vbus pin as a GPIO pin instead fixed the problem.

What kind of bugs me about this is that this behavour isn’t really documented in the user manual. Oh well. It is fixed and the solution was simple. I just wish it didn’t take me so long to find.

LPC2148 RTC bug?

I’ve been having a problem with the RTC and power down mode on a project using the LPC2148.  I am using EINT3/INTWAKE and the RTC alarm as sources to wake the processor from power down and I find that occasionally, when I’m in power down mode,  the RTC peripheral seems to lock up and neither the alarm or EINT3 are able to wake the processor .  The only way to recover is to do a hard reset.
Searching for a solution, I found this post
http://www.embeddedrelated.com/groups/lpc2000/show/20665.php
that said to setup the PREINT and PREFRAC even if you are using an external RTC crystal.

PREINT = ( int )( ( 60000000UL / 32768UL ) – 1 ) & ( ( 1 << 14 ) – 1 );
PREFRAC = ( int )( 60000000UL – ( ( ( unsigned long )PREINT + 1UL ) * 32768UL ) );

I’ve just tried this on a few pieces of hardware that were consistently locking up in power down and it seems to be working so far. When I switch back and forth between firmware with and without those two lines it seems to follow that if I don’t set up PREINT and PREFRAC it locks up. If this is in fact the solution I would really like to know why this works since it makes no sense.