Go Back

LPC1xxx 1GHZ Wireless Board Preview

Thursday, March 14, 2013
It feels like I've been working on these boards forever -- and to be fair there's literally years of effort and >20K EUR in expenses here -- but I finally ordered a first batch of the USB stick and wireless node PCBs this week.  There's always something to improve, but overall I'm very happy with the HW and the related code base, and I think the boards are a significant improvements over any other project that I've posted here.

Admittedly there's nothing whatsoever exciting about yet ANOTHER wireless sensor node or platform, and it's probably more expensive than it needs to be if you went with an integrated MCU + radio, etc., but my goal was never to create a commercially viable board but something that was useful to me and met my own goals of having a rapid wireless prototyping platform based on an MCU family that I liked, and using fully open source stacks and toolchains.



  • LPC1347 (72MHz ARM Cortex M3, 64 KB Flash, 12KB SRAM, 4KB EEPROM, 12-Bit ADC)
  • Supports USB CDC, HID, and MSC out of the box
  • Easy to use CLI to send and receive data via USB CDC
  • Optionally supports USB HID command set
  • USB Bootloader for easy firmware updates (no extra HW required)
  • 4 layer PCB to keep reasonably clean routing and a clean RF section
  • Designed to fit in an inexpensive USB enclosure if desired (~$3 in single quantities)
  • RF section designed to work equally well at 868MHz (EU) or 915MHz (US), with excellent range and performance
  • SMA connector to attach various types of antennas (directional, small quarter-wave, half-wave, etc.)

I designed this small USB stick to be able to co-ordinate other sensor nodes from anything with a USB slot.  The main goal was to use a Raspberry Pi (Beagle Bone, etc.) as a cheap always-on network co-ordinator, but I also designed them with USB Host in mind.  My thinking was that with a single well-design USB stick I could plug different radios into mid-range MCUs with USB Host (LPC4357, etc.) and support various frequencies, modulation schemes, etc., without having to go through the FCC approval process more than once, and without locking myself into one choice on expensive HW.



  • LPC11U37 (50MHz ARM Cortex M0, 128KB Flash, 10KB SRAM, 4KB EEPROM, 10-bit ADC)
  • On board SD card with FAT32 file system support (USB MSC can enumerate as a mass storage device pointing to the SD card on the PC)
  • Built in LIPO charger (just plug in a USB cable and the board switches to USB power and charges the LIPO at the same time)
  • Supports USB CDC, HID and MSC, including HID Keyboard and Mouse emulation and auto config for multiple USB profiles (CDC + HID, etc.)
  • Easy to use and extended CLI
  • Out of the box support for many sensors available from Adafruit, including a unified sensor system to make adding new sensors as painless as possible
  • USB Bootloader for easy firmware updates
  • Easy to use radio framework (Chibi) that works out of the box
  • 4 layer PCB with dedicated GND and power planes, and an isolated RF section
  • Designed to fit inside an inexpensive IP65 (water resistant) enclosure (Adafruit Product 903)
  • RF section designed to work equally well at 868MHz (EU) or 915MHz (US), with excellent range and performance
  • SMA connector to attach various types of antennas (directional, small quarter-wave, half-wave, etc.)
  • Switch between 3.3V and 2.2V supplies on the fly (saves power), and board can be run as low as 1.8V

These were intended to be the workhorse, battery-powered sensor nodes. I spent a LOT of time and effort trying to get the lowest current level possible in sleep mode (currently ~20µA with SW wakeup, but this should in theory be able to go lower with more time and effort).

What's the point?

Both of these boards are really just a labour of love.  I love ARM, I love wireless, and I've spent so many years and so much time and money on these boards -- and earlier boards that made these ones possible -- that it just seems a shame to me that no one else was benefitting from all that work and effort.  I designed these boards purely for personal use and as a platform to make rapid prototypes myself ... and I definately have no illusions that there's big money to be made in yet another wireless sensor node platform.  But I'm convinced it's a pretty good bouncing board to test out some ideas, and while these boards and the library are far from perfect, they're a lot better than many of the closed source systems that currently exist.

What about the firmware?

I've signed off on a new combined LPC11U24/LPC11U37/LPC1347 code base that allows you to switch between any of the three MCUs with just a small change in the config file.  I'm just waiting for the (I hope) final PCBs to come in in two weeks time, get a small batch assembled, and then get them into the hands of testers for some feedback.  Once I can work out the major bugs from the first batch, I'll release the board files and code base into the wild ... but I'm extremely happy with the code base as is, and I really think it's an excellent starting point for anyone interested in doing anything serious with ARM and 802.15.4 wireless connectivity.

When will it be ready?

I can't make any promises here.  Again, this is really just a labour of love not a commercial endeavour ... but I hope to assemble a first batch of 100 or so boards in a few weeks, and to send them to some friends and colleagues, then make some quick changes based on that feedback.  I also need to spend some time working on some SW on the Raspberry Pi, etc., to manage the sensor network, and haven't had 5 minutes to do that yet.  Hopefully in 6-8 weeks, though, I can have something ready for a wider audience.

Full story  | Comments (7)

LPC1347/LPC11U37 Board and CodeBase Update

Thursday, September 13, 2012

I was surprised by the interest in the RF board I posted about earlier, so I figured I'd post a small update on the progress. I've been dividing my time between the 1347 and 11U37, trying to spend equal amounts of time with both to make sure that the codebase easily works with either chip out of the box.

Initial Opinions

While the migration from the 1114 and 1343 has been generally pretty smooth, I did have to pull out the UM to understand the new (and more flexible) GPIO blocks, the 12-bit ADC (1347 only), get the EEPROM working, etc., but nothing too dramatic so far. SSP, I2C, etc., are the same as always since they're basically just licensed IP blocks from ARM.

Overall, I'm exceptionally happy with both chips and the 1347 is everything I wish the 1343 would have been ... though I'd be happier if the distributor pricing was a bit lower.

There were some hiccups creating a common LPC11U37 + LPC1347 codebase because of a few regrettable naming differences in the CMSIS libraries from NXP. The UART IRQ handler is defined as "USART_IRQHandler" for the 1347, for example, but "UART_IRQHandler" for the 11U37, so to have a single codebase for either chip I end up with horribly ugly cludges like this:

#if defined CFG_MCU_LPC11U37FBD48_401
void UART_IRQHandler(void)
#elif defined CFG_MCU_LPC1347FBD48
void USART_IRQHandler(void)
  #error "uart.c: No MCU defined"

Similar situation for "FLEX_INT0_IRQHandler" (11U37) versus "PIN_INT0_IRQHandler" (LPC1347), and in a number of other places, but these are relatively easy to locate and fix. The worst so far was with GPIO, though, where some of the register names in the core header file were different, as seen below (used to set up a GPIO interrupt):

        case CHANNEL1:
          if ( portNum )
            #if defined CFG_MCU_LPC11U37FBD48_401
                LPC_SYSCON->PINTSEL[1] = bitPosi + 24;
            #elif defined CFG_MCU_LPC1347FBD48
                LPC_SYSCON->PINSEL[1] = bitPosi + 24;
            #if defined CFG_MCU_LPC11U37FBD48_401
                LPC_SYSCON->PINTSEL[1] = bitPosi;
            #elif defined CFG_MCU_LPC1347FBD48
                LPC_SYSCON->PINSEL[1] = bitPosi;
          #if defined CFG_MCU_LPC11U37FBD48_401
          #elif defined CFG_MCU_LPC1347FBD48

LPC_SYSCON->PINTSEL (LPC11U37) is probably the better name because it better represents what this register is doing (GPIO Pin Interrupt Select), but curiously the LPC1347 user manual also lists this value as PINTSEL (not PINSEL), so it's likely just an unfortunate typo that people are stuck with now since they can't really change it. It's also a rather misleading name if you've ever done any ARM7 development with the older LPC2000 series since 'PINSEL' performed a very different and common function. But hey ... such is life, and at least they give you something to start with these days, and mistakes happen. It just struck me as unfortunate that for chips that are almost identical on a peripheral level, and that can be dropped in with 99% SW and HW compatability that the major obstacle would be something as trivial as inconsistent naming across families.

Low Power

The power numbers were higher in the sleep modes than I expected, and I'm still working on this and certain it's my fault. I trust the numbers in the datasheet, and I'm pretty confident in my HW after two revisions for power, but I just need to find the secret sauce in the firmware. This also took quite a while with the 1114. I'm currently at 30µA in power down running at 2.2V which is identical to what I got on some similar LPC1114 wireless boards ... but I should be able to go much lower than that (ideally under 10µA total). There were a lot of gotchas trying to isolate those microamps, though, including on less than obvious one.

The 1347 and 11U37 families now include a (welcome) QFP64 package option with more IO pins (great for large LCDs, etc.). Inside, though, all of these chips almost certainly use the same die, and they just selectively bond out the required pins for the package -- QFN33, QFP48, QFP64, etc. The 'gotcha' was that on a QFN33 or QFN48 package, those extra GPIO pins still exist on the die, and if you go into a low power/sleep mode without taking them into consideration you'll be drawing several hundred µA more than you should be due to the pullups and default pin state. You need to explicitly setup the unbonded pins to output and GND as well, and put the pullups in an appropriate state AND be sure to disable the analog mode on unbonded pins with an ADC option. I didn't think of that at first, but it got me from 400µA to around 30µA, using code similar to the following (I explicitly set every pin on startup now):

I caught that thanks to Embedded Artist's excellent Oryx board (thanks for the inadvertent heads-up Anders!).

CodeBase Improvements

Since I'm starting a new code base I took the opportunity to try to improve on previous efforts, and I think the current version has a better organisation, and I've improved some things I really didn't like in the previous 1343 and 1114 libraries.

  1. I've improved the CLI a bit (better organisation, etc.)
  2. I added a very preliminary mechanism to localise/translate text so that you can support multiple languages in one application (though this really needs more attention and testing), which is a must outside the US but not something I see done a lot in open source embedded projects
  3. I've start working on a global error handling mechanism, though at the moment it's just shared error codes and better error handling and checking in I2C
  4. I also added a board-specific init sequence and file in addition to the shared systemInit() function so that board specific code can be better seperated, though this still needs some thought.


Overall, I'm happier with this that the 1343 code base, but it still needs some thought and effort and isn't ready for the real world yet. The biggest change is that I've decided not to swim against the current and just use CMSIS from the start. When I start with the 1343 and 1114 codebase CMSIS was brand new, and nothing existed for these chips anyway, so I just did what I always did and pulled out the UM and started making my own flat header file. I still prefer this approach, but I just don't have the time to dedicate to doing this well these days -- there are weeks and weeks of effort in that approach -- so I'm using the default NXP peripheral drivers and CMSIS 3 code, making changes where appropriate so that the code works with both the 11U37 and 1347 just changing a single define in projectconfig.h. This isn't an ideal solution for me, and I may go back and rewrite all those peripheral drivers myself ... but for now this lets me get started quickly and developping the HW, etc.

When Will it be Available?

Not sure, and no promises. I don't want to publish it before it's in reasonably good shape and I'm happy with the basic organisation, and since this is just an unpaid weekend project I can't work on it much during the week ... but hopefully in a month or so I'll publish an initial version along with the HW files for a first wireless board and maybe put together a simple MCU-only board for people no interested in RF but who want to use the codebase.

The ToDo list is still pretty big. I haven't touched USB yet, the antenna on the current boards desperately needs to be properly measured and either revised or tuned, and I have to add in ADC support and a few key peripherals I haven't gotten to yet like the timers. I think the worst is done, though, and things are coming together nicely ... just never enough hours in the week to really wrap it up.

I'll definitely be moving to the 1347 and 11U37 combination in the future, though, and they're great little chips that should be much more flexible than the earlier 1343 and 1114. I'll probably move away from the 1343 entirely, but will maintain the 1114 code since it's still ridiculously cheap, there's a DIP version of it, and the new 1115 with 64KB flash breathes some extra life into it.

Full story  | Comments (2)

Converting RF signal strength values

Saturday, March 19, 2011

If you're new to RF and things like signal strength measurements (dB, dBm, RSSI, etc.), the following whitepaper may be helpful: Converting Signal Strength Percentage to dBm Values

Decibals (dB) are used to indicate the ratio of one power level to another. An increase of 3dB doubles the power, so 6dB is equal to 4x the power, 9dB is equal to 8x, etc.

The specific formula is: dB = 10 * log(P1/P2), meaning that for a 4 times difference in power we get:

dB = 10 * log(4/1)
dB = 10 * 0.602
dB = 6.02

The following table shows some key values comparing decibels (dB) and their equivalent increase/decrease factor:

dB Increase Factor Decrease Factor
0 dB 1x 1x
1 dB 1.25x 0.8x
3 dB 2x 0.5x
6 dB 4x 0.25x
10 dB 10x 0.10x
12 dB 16x 0.06x
20 dB 100x 0.01x

dBm is used to indicate transmit and receive sensitivity in milliwatts, and is the power ratio in decibels (dB) of the measured power referenced to one milliwatt (the m in dBm). 0dBm is equal to 1 milliwatt. The following two formulas govern the relationship between dBm and mW:

To convert dBm to mW: P(mW) = 10[P(dBm)/10]

To convert mW to dBm: P(dBm) = log[P(mW)] * 10

For example, if we start with 13dBm, we get the following equivalent value in milliwatts:

mw = 10^[13/10]
mw = 10^1.3
mw = 19.953 (or roughly 20mW)

We can also convert 20 mW back to dBm as follows:

dBm = log[20] * 10
dBm = 1.301 * 10
dBm = 13.01

Some common value can be seen in the table below:

dBm Increase mW dBm Decrease mW
0 dBm 1 mW 0 dBm 1 mW
1 dBm 1.25 mW 1 dBm 0.8 mW
3 dBm 2 mW 3 dBm 0.5 mW
6 dBm 4 mW 6 dBm 0.25 mW
7 dBm 5 mW 7 dBm 0.20 mW
10 dBm 10 mW 10 dBm 0.1 mW
12 dBm 16 mW 12 dBm 0.06 mW
20 dBm 100 mW 20 dBm 0.01 mW

For more information, feel free to look at the Wikipedia pages for decibels and dBm.

Full story  | Comments (18)

New Product: LPC1114 802.15.4 Wireless Transceiver

Thursday, February 10, 2011

LPC1114 802.15.4 Wireless NodeWhile it's been rather quiet on the website lately, we've been busy working on a number of projects behind the scenes.  One of the key projects we've been working on for a while now (much longer than anyone expected!) is a set of wireless transceivers and devices in the 868/915MHz ISM band.  868 MHz (Europe) and 915 MHz (North America) offers an excellent compromise between transfer speed, signal penetration in an urban environment, and power consumption.  Unfortunately, most commercially available devices tend to use 2.4GHz, so there seemed to be an obvious value in developping a few ARM-based boards in the 800/900MHz band.

The first of these wireless boards was published this week, the LPC1114 802.15.4 Wireless Transceiver. This small board is based on the ARM Cortex-M0 LPC1114, and uses the AT86RF212 802.15.4 transceiver.  The board is intended to be run from batteries (specifically rechargeable Lithium-Polymer cells, though you could also use 3xAA NiMH or Alkaline cells or any 3.6-5.5V supply), and uses Chibi ... a lightweight 802.15.4 stack from Freaklabs specifically designed for the AT86RF212 and AT86RF230 (2.4GHz).

The boards include a microSD connector to read and persist files using a FAT32 file system, a basic voltage divider to check the battery voltage, a temperature sensor to calibrate temperature-sensitive sensor readings, and a handful of useful pins broken out (3xADC, UART, and I2C).  For more information, feel free to look at the project page though.

One feature worth mentionning on these boards, though, is that thanks to the latest update to the Chibi wireless stack -- and if you're interested in wireless at all you'll definately want to spend some time looking at Freaklabs website -- these boards can be used as an 868 or 915MHz sniffer for 802.15.4 traffic (6LowPAN, Zigbee/XBEE, etc.).  The latest version of Chibi (v0.91) includes support for something called PROMISCUOUS mode than make the transceiver transparently read any packet it sees over the air.  By using wsbridge, you can feed the 802.15.4 frames directly into wireshark (using any UART to USB adapter to connect the LPC1114 to the PC).  The SW is available directly from Freaklabs, but is also included in the '/tools' folder of the LPC1114 Code Base for convenience sake.  For more information see: Feeding the Shark - Turning the Freakduino into a Realtime Wireless Protocol Analyzer with Wireshark.

In the coming months, you can expect to see more wireless boards and projects combining different MCUs and transceivers, but given the number of revisions the LPC1114 board took (more than 10!), we'd rather keep quiet about any future plans and just publish the details when things are a bit closer to being ready.  In the mean time, take a look at some of the great stuff Akiba over at Freaklabs is putting out.  He's the real enabled behind all the wireless fun we're having lately!

Full story  | Comments (23)

  1. 1
  2. 2
  3. Next page