Microcontrollers and embedded electronics

Hörmann UAP 1 controlled from KNX

12. March 2020 12:13 by Jens Willy Johannsen
Categories: Home Automation, Uncategorized | Tags: ,
The final interface board (click for full size)

In our new house, we're installing KNX as the primary infrastructure for home automation.
And obviously, I want to connect the garage door to the home automation system. Both to be able to run automations whenever the door opens or closes and to be able to control it from other devices than the standard remote control.

My solution comprises the following components:

KNX bus → KNX I/O unit → interface board → UAP 1 → garage door opener → scary outside world

Read the entire post »
Kommentarer 1 comment »

KNX components with LPC11U68 MCU

25. November 2019 13:34 by Jens Willy Johannsen
Categories: Home Automation | Tags:

We're building a new house at the moment so I'm looking into various flavors of home automation right now. And even though many people seem to go with Philips HUE-based solutions, I've decided on using KNX instead. There are both advantages and disadvantages but that's an entirely different post.

Obviously I want to be able to add my own components to the setup – both as actuators (i.e. things that are controlled by automation/switches, like lights, relays, motors) and as sensors (i.e. inputs that can trigger stuff, like switches, light sensors, motion sensors, …).

Since my weapon of choice at the moment is NXP's 32 bit ARM LPC11U00 series, the job at hand is as follows:

Connect an LPC11U68 to a KNX bus and observe and send data objects.

Read the entire post »
Comments 2 comments »

Blue Maestro sensor, openHAB or Home Assistant and HomeKit

28. June 2019 21:27 by Jens Willy Johannsen
Categories: BLE, Home Automation | Tags: ,

Since I’m already working on a device for showing the temperature reported from a Bluetooth sensor (read more) and I’ve also been doing some home automation stuff using openHAB and Home Assistant, I thought it ought to be possible to get the openHAB server to report the temperature as well. It is. This is how it works:

  1. The BLE device reports the current temperature in BLE advertisement packages.
  2. The Raspberry Pi server runs a Python script as a service that performs BLE scanning and looks at the advertisement packages, identifying and parsing packages from the BLE device.
  3. Whenever a matching BLE advertisement package is found, the current temperature is extracted (along with humidity and dewpoint) and posted to an MQTT server.

For openHAB:

  1. The openHAB server running on the same Raspberry Pi uses the MQTT Binding to connect to the MQTT server and things and items are configured to subscribe to the appropriate topics and expose the temperature and timestamp.
  2. The openHAB server also uses the HomeKit Add-on to publish the temperature as a HomeKit compatible temperature sensor so it's available on all my iOS/watchOS/macOS devices.

For Home Assistant:

  1. The Home Assistant running on another Raspberry Pi using uses an MQTT connection to expose the values as sensor readings.
  2. … and also uses the HomeKit integration to publish the temperature to Apple HomeKit. Which works perfectly out of the box.

Awesome. But there were several steps along the path. Read on for the details and code...

Read the entire post »
Comments 8 comments »

Project: Pebble Display

6. November 2018 11:36 by Jens Willy Johannsen
Categories: Bluetooth, Projects

My current project is an external display for the Pebble™ Environment Monitor.

The Pebble is a Bluetooth-based outdoor temperature/pressure/humidity sensor and the idea is that you can see the current values on an iOS or Android app.

Pebble™ Environment Monitor

Unfortunately, the device/app comminication is a bit too slow and it's really annoying to wait 10 or 20 seconds before the app gets a new reading from the device.

So I'm building a small device that comprises a Bluetooth SoC and a display. I'm using a Nordic Semiconductor nRF51822 as MCU and Bluetooth interface and some kind of e-paper display (because a) it looks cool, b) I haven't worked with e-paper displays before). This way I can have a nice wall-mounted display that always shows the last received temperature.

I'll be using Keil µVision 5 (free version) with Nordic nRF5 SDK 12 as development platform.

Further bulletins as events warrant…

Kommentarer 1 comment »

Antenna design and matching

17. October 2018 21:25 by Jens Willy Johannsen
Categories: BLE | Tags: ,

At the moment, I'm working with Bluetooth Low-Energy devices and it very quickly became apparent that designing a PCB with a BLE antenna (no matter which type) is nowhere near as simple as designing the kind of boards I usually work with (MCU, digital circuitry and senors and a couple of actuators).

Starting to read up on the topic of antenna design only served to confuse me even further. So while this blog post is not a comprehensive guide to antenna design, but more of a brief recap of what I have learned so far, I hope it can help others about to learn antenna design.


The basic premise is that we want to build a device consisting of a transmitter and receiver (since BLE is two-way communication) that can communicate as efficiently as possible with another transmitter/receiver device. A higher degree of efficiency means a longer range for the same power usage (sure, you could just pump several megawatts of power into a poorly designed antenna and get a good range out of it but we don't want to do that for many reasons).

Within very few minutes of starting to read about antenna design you will encounter the term "impedance matching". And that is basically what this entire post is about. In a system where impedances are perfectly matched, all of the power leaving the transmitter IC (in our case a Nordic Semiconductor nRF51822 BLE SoC) will be delivered to the antenna. In a system where impedances a not matched at all, none of the power leaving the IC will be converted to RF energy and the resulting range of the device will be zero. The more power that reaches the antenna, the better efficiency we achieve and the better range we get. A perfect match is simply not possible so we're just trying for "as good as possible given the constraints of power, space, time, money and level of ambition".

Read the entire post »

Comments 5 comments »

Flashing a Minew D15 iBeacon using nRF51 Development Kit

3. June 2018 21:34 by Jens Willy Johannsen
Categories: BLE | Tags:

I've been looking a various replacements for the Bluegiga BLE112 and BLE113 modules I've been using so far for all projects involving BLE. Not that there is anything wrong with them, but they are a bit expensive.

So right now, I'm looking at the Nordic Semiconductor nRF51822 chip. It's got a couple of things going for it:

  • It is pretty cheap
  • It only requires relatively few support components
  • The free version of the Keil IDE can be used for most projects. And this is important since the Keil µVision IDE costs about $4000
  • The free, online IDE can be used
  • There's lots of documentation and many people are using it

I bought the nRF51 Development Kit (which has an onboard programmer) then I remembered I had a bunch of Minew D15 iBeacons lying around (From Alibaba). And since they are populated with nRF51822's, I figured I'd try to see if I could them flashed with my own firmware. (Spoiler alert: I could.)
Here's a short writeup of what I did.

Read the entire post »

No comments No comments »

Fixing Evernote and Spotlight indexing

7. October 2015 9:43 by Jens Willy Johannsen
Categories: General

For the longest time I have been wanting to use Evernote to store my notes. But one major issue has been preventing me from doing that every time I tried to switch from a bundle of markdown files to Evernote: the fact that Spotlight search in Evernote notes didn't work.

There are many comments and suggestions out there but I finally found a solution that worked for me:

Read the entire post »

Comments 6 comments »

Fixed PIN pairing on Bluegiga BLE112 Bluetooth module

31. August 2015 11:30 by Jens Willy Johannsen
Categories: General | Tags: ,

I needed to make a Bluetooth LE device that required a more secure pairing with the companion iOS app than just "Click Pair to connect…".

This can easily be implemented in BTLE using a bonded, encrypted connection with man-in-the-middle protection enabled. But the device needs either a display to show the code which should be entered on the iOS device, or a keypad to enter the code shown on the iOS device. If the device has neither, then only the "Just works" method can be used. And this will not prompt for a passkey/PIN code.

"But can't I just hardcode a PIN code in the firmware," I asked Google. And Google said, "No, fixed-passkey authentication is not supported in Bluetooth LE."

But it turns out that there is a solution: pretend the BTLE device has a display and specify a hardcoded passkey in the config.xml file. That way, instead of generating a random key to display to the user, the hardcoded passkey will be generated instead.

Read the entire post »

Kommentarer 1 comment »

Pixhawk CHDK trigger

18. August 2015 22:02 by Jens Willy Johannsen
Categories: Drones, Projects | Tags: ,


The Pixhawk-CHDK trigger will let you use Pixhawk-based drones (like the IRIS+) with a CHDK compatible camera for aerial photography without using a whole mess of duct taped-together UBECs and LED switches and whatnot.

The Pixhawk-CHDK trigger has three input connections in a 0.1" locking header which is compatible with standard servo lead connectors. Power and ground is taken directly from the flight battery (3S or 4S) and the input signal directly from an auxillary output on the Pixhawk. No need for BEC/UBECs or for powering the servo rail on the Pixhawk.

Output to the camera goes directly to the camera's USB port. (Using a locking 2-pin 0.1" header.)


There is also a mini-USB connector for configuring the Pixhawk-CHDK trigger. Configuration is done by connecting the Pixhawk-CHDK trigger to a Mac OS X, Windows or Linux computer and opening a terminal connection (using screen or PuTTY or your terminal application of choice) to the device.

Using a simple command-line interface, a number of intervals (up to 20) can be configured. An interval is simply a definition of an input PWM range and corresponding output pulse length. This will allow the Pixhawk-CHDK to work with all CHDK scripts that use the USB remote control input for control, regardless of how many different commands the script supports.

So if we want the CHDK to receive a 50 ms pulse when the RC signal is between 1800 and 2000 µs, the command would be add 1800,2000,50.

Everything is stored in non-volatile RAM (flash) and the interface currently supports the following commands:

  • help – shows available commands
  • list – shows all defined ranges
  • delete – removes a range
  • add – adds a range
  • show – shows all or a specific settings parameter
  • set – modifies a settings parameter
  • pulse – sends an output pulse of the specified length for testing CHDK scripts
  • isp – enters ISP mode for flashing new firmware

Want one?

Everything is open source and open hardware; all schematics, board files and firmware will be made available shortly along with BOM and assembly instructions.

Comments 4 comments »

Pixhawk-CHDK trigger progress

10. June 2015 11:07 by Jens Willy Johannsen
Categories: Drones, PCB, Projects | Tags: ,

The Pixhawk-CHDK trigger is coming along nicely. The prototype is done and the firmware is almost done.

The firmware is actually very simple. I'm using 32 bit timers for both measuring incoming RC PWM signal for for outputting 5 V pulses of specific lengths and all the USB CDC functionality is copied-and-pasted from a previous project. The most complex part is actually for command-line interface (or "CLI") parser.

To configure the device you plug into your computer using a mini-USB cable and then connect using Telnet, screen or other terminal application.

The command set is pretty simple and supports the following commands:

list                    -- shows all defined intervals
add 1000,1200,85        -- adds a new interval
delete 1                -- removes entry 1
change 1=1000,1300,85   -- changes entry 1
pulse 50                -- sends an output pulse of 50 ms
show                    -- shows all settings parameters
show <setting>          -- shows the value of a single parameter
set <settings>=<value>  -- changes the specified settings parameter
help                    -- shows available commands
?                       -- same as "help"

No need to "save" or similar. Everything is stored in EEPROM as soon as it is entered.


The PCB design is also almost done. I just need to check it a couple of times (time well spent, trust me) and verify footprints (likewise time well spent). The size is 5 x 2 cm and even though I probably could squeeze it down some more, I think I'll keep the current size seeing as how I'll be hand-soldering some of the parts and applying solder paste and components all by hand.

Here's a rendering (from the excellent 3D Gerber Viewer from Mayhew Labs:

Pixhawk-CHDK PCB. 5 x 2 cm.

Pixhawk-CHDK PCB. 5 x 2 cm.

No comments No comments »

CHDK trigger for Pixhawk and IRIS+

5. June 2015 9:56 by Jens Willy Johannsen
Categories: Drones | Tags: ,

I have begun creating a CHDK trigger cable for the Pixhawk autopilot in my IRIS+ drone.

It will allow me to control a Canon compact camera (IXUS 60 in my case since I had one of those laying around) from the autopilot.

CHDK is the Canon Hack Development Kit which will allow you to do a whole lot more with a Canon compact camera than what the basic knobs and dials will let you do. It also allows for scripts to be run on the camera – LUA (nice) and Basic (yuck) – and enables remote control through the USB port.

The purpose of this trigger cable is to convert the 3.3 V RC PWM signals from the Pixhawk (PWM with pulses from approximately 1000 µs to 2000 µs; read more here if you want) to 5 V pulses (from about 10 to a couple of hundred milliseconds) for the camera.

With the trigger cable complete and the camera mounted on the IRIS+, I can trigger shots from either the RC transmitter or by using pre-programmed actions in auto-missions. Those images can later be stiched together in Photoshop or Microsoft ICE or similar to create a nice high-resolution aerial photo.

While I'm sure this project could be implemented using less sophisticated hardware, I'm using an LPC11U24 microprocessor since that is my weapon of choice for pretty much anything.

I'm trying to make the device as small as possible so I will be using a 7 x 7 mm HVQFN package which will require the PCB to be reflow soldered (we've come a long way since all ICs had to be 0.1" DIL packages). I will also be using a 1 mm pitch JST-SH connector for MCU programming instead of big 0.1" pin headers. Both power and signal input as well as output signal will use Molex SL connectors with locking tabs (which I use everywhere else on my IRIS+).

The resulting images will look this one from a thread on DIY Drones ( A successful APM aerial survey mission):

Click to see higher resolution

Click to see higher resolution

No comments No comments »

IRIS+ front light

29. April 2015 13:26 by Jens Willy Johannsen
Categories: Drones | Tags: ,

I’ve gotten myself an IRIS+ quadcopter and it is awesome!
It also offers limitless possibilities for creating add-ons – both software and hardware-based.

My first project is a 1W LED front light in order to help with orientation (and look cool).

I’m using a CREE XR-E on a “star PCB” (this one) with a Carclo lens and lens holder.

The light will be mounted to the IRIS+’s front GoPro mount with a 3D printed mount. I’ll print the prototype myself and then order it on Shapeways as a higher quality SLS printed version (here it is).

Power will be supplied from the flight battery through a ZXLD1350 switching regulator-based circuit I designed a while back for another project.

Remote control

Since the LED driver supports turning output on/off I though I could control the LED from one of the Pixhawk’s relay pins.

Small issue though: the ADJ pin on the ZXLD1350 interprets a voltage of 0 as off (which is fine) and 1.25 V as 100% on. Which is not entirely fine since the relay pins on the Pixhawk toggle between 0 and 3.3 V. So I’ll use a standard NPN transistor so the ADJ pin will toggle between 0 V and floating which will use the internal resistor as pull-up. The schematic looks like this:


And it works like this:

Pixhawk relay Pin voltage ZXLD1350 ADJ pin voltage result
on 3.3 V 0 V LED off
off 0 V internally pulled up to 1.25 V LED on

In other words, relay off means LED on and vice versa.

The transistor is a bog standard BC547 NPN. And since I can’t be bothered to modify the PCB for the LED driver and send off for fabrication and so on, I’ll just solder it on, glue it to the back of the PCB and shrinkwrap the entire mess. Not perfect, but good enough for jazz.


The control pin is attached to the Pixhawk’s AUX OUT 5 signal pin (physical pin no. 54) and power and ground is spliced into the power lead going to the gimbal.

Since the PCB is open to the environment on the backside of the mount and since the pins for VIN and GND are attached directly to the flight battery and are only 0.1" from each other, the entire PCB will be potted using either just hot glue or proper potting compound (e.g. QSil–216) so the battery will not get shorted by a stray drop of water.

APM Parameters

In Config/tuning -> Standard parameters, the First Relay Pin (RELAY_PIN) is set to Pixhawk FMU AUX5 (this is default).

On the Extended Tuning page, Ch8 Opt is set to Relay On/Off.
(If this option is not available, go to Full Parameter List and set CH8_OPT to "28" for "Relay On/Off" (on APM:Copter 3.3.3; the value might be different on other versions))

This will allow the light to be turned on/off by toggling relay 0 in auto missions (DO_SET_RELAY) and toggling channel 8 from the transmitter.

Transmitter setup

Since channel 8 is currently unassigned, I’ll use that to control the relay. I’m using a Taranis TX so setup is as easy as can be:

CH8             MAX Weight(-100%)   Switch (!SG↑)
            R   MAX Weight(+100%)   Switch (SG↑)

In other words: for channel 8, set value to –100% when switch G is not in the up position. And set value to +100% when switch G is in the up position.
Remember that due to the transistor, relay on means LED off, so a channel 8 value of –100% will turn the LED on. So if switch G is in the up position, the LED is off; otherwise it is on.


Here is how the prototype looks:

And yes: it is bright:

And here is the backside with the regulator PCB (with a couple of globs of hot glue in the corners to hold it in place):

No comments No comments »

EAGLEView app now open source

27. January 2015 22:16 by Jens Willy Johannsen
Categories: Uncategorized | Tags:

Now open source. Collaborators welcome.

I have come to the conclusion that I simply do not have enough time to finish the EAGLEView app by myself. So I have decided to release the app as open source so everyone can download the source and build it.

Also, people are welcome (more than welcome, in fact) to contribute to the project.

The app is not finished but lots of functionality is already in place. These features already work:

  • Display schematic and board files. EAGLE version 6 or higher.
  • Open .sch or .brd file from Dropbox
  • Open files by clicking links to .sch, .brd or .zip files (the zip file will be extracted and scanned for .sch and .brd files)
  • Pan and zoom
  • Click component to see details
  • Search for specific components by name or value
  • Show/hide individual layers
  • Support for multiple modules

There is also some stuff that is not yet implemented. Among these are:

  • Ploygon pours. (At the moment, the entire polygon will be filled completely.)
  • Need to speed up drawing routines to avoid flickering when redrawing.
  • Support for multiple sheets
  • Different shapes for SMD pads
  • Get the zoom-to-fit working properly
  • And other stuff – refer to the todo.txt file

The GitHub repo is here:

EAGLEView app

Kommentarer 1 comment »

EAGLE Viewer for iOS

1. February 2014 12:32 by Jens Willy Johannsen
Categories: Uncategorized | Tags:

I've made quite a lot of progress on my EAGLE Viewer for iOS. Firstly, it's not just iPad anymore – now all functionality is on iPhone too.

Secondly, it now displays both schematic and board files.

And a lot of other improvements:

  1. Layers
  2. Popup showing component info when tapping an object
  3. Auto-diameter for pads

Here's a couple of screenshots:

EAGLE Viewer for iOS – click for larger image

EAGLE Viewer for iOS – click for larger image

EAGLE Viewer of iOS: iPhone – click for large image

EAGLE Viewer of iOS: iPhone – click for large image

There is still a lot of stuff remaining. I'm not looking forward to the "polygon pour" drawing routine. I can parse the draw the polygons fine, but I need to not fill the polygon where there are other signals, holes and keepouts. Tricky stuff...

Comments 13 comments »

EAGLE viewer for iPad

24. January 2014 14:50 by Jens Willy Johannsen
Categories: Uncategorized | Tags: ,

EAGLE Viewer – coming soon to an iPad near you…

Many a time I have found myself sitting at my workbench and desperately wished for a way of viewing the latest revision of an EAGLE schematic or board file on my iPad. But, alas, no such app exists in the App Store.

So I'm making my own. And it will be free on the App Store when it is finished, or course.

So far I can:

  1. Open schematic files from Dropbox
  2. Open schematic files directly or when they are contained in a zip archive from another app – Mail or Safari, for example
  3. Display the schematic (kinda the core feature, you might say). There is still some work to be done here before all shapes can be displayed properly.
  4. Pan and zoom using standard iOS gestures (pan, pinch)

The next features on the list are:

  • Show/hide layers
  • Component info popup on tap
  • Displaying board files

If you guys have any wishes, feel free to post them in the comments.

Here's a screenshot of how it looks now:

EAGLE Viewer screenshot – click for larger version

EAGLE Viewer screenshot – click for larger version

EAGLE Viewer screenshot (Dropbox) – click for larger version

EAGLE Viewer screenshot (Dropbox) – click for larger version

Comments 11 comments »

Electronic to/from gift card

23. January 2014 0:19 by Jens Willy Johannsen
Categories: Uncategorized

My most recent project is an electronic to/from card for presents. A small device you can attach to presents showing "To" and "From" on a backlit 16 x 2 LCD display.

In order to save battery power, an accelerometer is used to detect motion and the LCD backlight is turned off after a couple of seconds with no motion and the MCU is put to sleep ("deep power-down", actually). When motion is detected, an interrupt is signalled by the accelerometer which wakes up the MCU which in turn turns on the LCD backlight.

The text shown on the LCD can be programmed using a USB connection and a Mac OS X application. The texts are stored in EEPROM.

There are two main design goals for this project:

  1. Make it cheap. These devices are meant to be attached to presents and then they are gone. Unless the recipient wants to use them, of course.
  2. Low power. The device should be able to run for a couple of days off two series-connected CR2032 batteries.

The low power consumption appears to be fairly easy to achieve: the LCD with backlight off, the accelerometer and the MCU in power-down mode all use very, very little power.
The low price, however, is more tricky. We'll see how it goes…


These are the main parts:

The PCBs are designed in EAGLE and I will get them made at ITead. The top side will be hot-plate reflow soldered (mainly due to the 0.5 mm pitch QFN accelerometer) and the bottom side will then be hand-soldered.

Here's a rendering of the PCB courtesy of Mayhew Labs:

To/from PCB – click for larger version

To/from PCB – click for larger version

No comments No comments »

Hot plate reflow soldering

2. January 2014 12:33 by Jens Willy Johannsen
Categories: Uncategorized | Tags: , ,

Until now I've been soldering SMD components by hand only (here's an image of my first hand-soldered SMD board). However, for my next project I will need to solder an MMA8452 accelerometer (datasheet) which is a 3 x 3 mm QFN package (0.5 mm pitch).
And while it is possible to hand-solder QFN packages (I've successfully hand-soldered an ADXL335 accelerometer in a 4 x 4 mm LFCSP package – which is a 0.65 mm pitch QFN), it is simply too difficult and too much bother (I'm sure people with better dexterity and eyesight than me can do it easily).

So: no way around it, time to start doing some reflow soldering.

For a hobbyist like me there seems to be three ways of doing it:

  1. Toaster oven
  2. Hot air rework thingie
  3. Hot plate

Originally I planned on using a toaster oven and this nice reflow controller from Beta LAYOUT. But after reading SparkFun's tutorial and the comments I decided on trying the simpler way first – which is getting a hot plate or electrical skillet.

They didn't have a skillet in the store and I couldn't be bothered to check other stores so I bought a simple and cheap hot plate.

And it works perfectly!

I got some (leaded) solder paste (like this one from Farnell) and applied the solder paste straight from the syringe needle (for the TQFP, SOIC and QFN packages I dragged a thin line across the pads), placed the assembled PCB on the hot plate and dialed it to the second-lowest setting and kept an eye on it to see when the solder paste started reflowing. After a minute or two, everything had reflowed and I took the PCB off the hot plate. This is what it looked like:

Click for larger version

Click for larger version

A lot of tutorials warn against using too much solder paste. If anything I should have used a bit more on the "big" components like the 1206 resistors and some of the 0805 capacitors. But both the SOIC and TQFP packages look nice and not a single solder bridge to clean up.
Of course, the real test is the QFN device. The pads are all nicely aligned with the PCB traces leading straight to the pads so it looks good, but we'll see when the board has been fully assembled (battery holder hand-soldered on to the bottom side of the PCB, for example) and the MCU has been programmed…


Even though it worked well enough, I will need to make two improvements:

  1. A thinner needle for the solder paste syringe. I will order these 25 gauge (0.25 mm) needles from Farnell to be able to apply the correct amount of solder paste to the pads.
  2. I will need an aluminum slab (about 15 cm square and 1 cm thick) to more evenly distribute the heat. Because the hot plate heats up pretty unevenly. According to this IR camera image, there is a difference of about 80 °C between the hottest and coldest spot on the hot plate:

Thermograph image of the hotplate

Thermograph image of the hotplate


A special thanks to the authors of the following articles – they were a great help:

Kommentarer 1 comment »

DIY Carbon Fiber

17. October 2013 10:14 by Jens Willy Johannsen
Categories: Uncategorized | Tags:

Everybody knows that anything made out of carbon fiber is automatically cool (well, almost).

I just found out you can make your own carbon fiber parts. Or cover existing parts in carbon fiber. (I'm sure it's nothing new but I just found out.)

I've ordered this kit from Easy Composites in the UK and I'm planning on covering some 3D printed parts in carbon fiber. I'll let you know how it works out…

No comments No comments »

Self-shutdown and any-key power-up

1. October 2013 16:27 by Jens Willy Johannsen
Categories: ARM

I need the Thermometer's MCU to be able to switch itself off to save battery power. And I also need to be able to power up the device by pressing any of the buttons. At the same time, of course, I need to be able to distinguish which button has been pressed.

I am using a MAX1796 PMIC which has a SHDN pin that turns off the device when high. Note that many PMIC's have a shutdown feature that doesn't disconnect the output pin from the input pin when shut down, but which simply disables the voltage regulation. I need a PMIC with what in the datasheets is called "true disconnect" (the MAX1796 has that. An example of a PMIC that doesn't is the MAX1724 which I first planned on using but rejected for this reason.)


Inspired by this post on, I designed this basic circuit to switch off the PMIC from the MCU and to switch it on from a push button. (I have not taken into account the delay from the user pressing the button to the MCU starting up and taking over control of the PMIC so if the user lets go of the button before the MCU is ready, power will turn off again):

Basic circuit

Basic circuit

  • Normally, the SHDN pin is pulled up and the PMIC is off.
  • When pressing the push button, SHDN gets grounded and the PMIC turns on.
  • The MCU will on start-up configure a GPIO pin as low and thus the SHDN pin is grounded to allow the PMIC to remain on.
  • When switching itself off, the MCU sets the GPIO pin high and the PMIC turns off.

NOTE: many PMIC's has a #SHDN pin which shuts down the PMIC when low and not high like the MAX1796.

Any-key power-up

I would like the device to turn on when the user presses any button (as opposed to a dedicated "power-on" button).

The buttons work as inputs that are pulled high so a HIGH value means the button is not pressed and a LOW value means the button is pressed.

But, of course, I can't just connect the switches like this:

Push buttons tied together

Push buttons tied together

Because the MCU would then be unable to distinguish which button has been pressed since they are all tied together.

Diodes to the rescue! Adding diodes like this will fix it:

With diodes

With diodes

This way, pressing switch doesn't affect the voltage at the other GPIO pins. But: a normal diode has a voltage drop of about 0.7 V. This means that the voltage at the SHDN pin will be 0.7 V when pressing a switch. To check if this is low enough to be considered "low" some perusing of the datasheet is necessary and reveals the following:

Parameter Symbol Min Max Units
SHDN Input Voltage VIL 0.2 ✕ VBATT V

And is we assume that VBATT is at max. 3.3 V, we get 0.66 V for the maximum allowed LOW voltage. In other words: a voltage of 0.7 V will not be interpreted as LOW.

But if we use a Schottky diode (like the trusty ZLLS1000) with a voltage drop of about 0.4 V, everything will be fine.

At least that's the theory. We'll see how it works out in real life…

No comments No comments »

LPC11U24/LPC1347 JTAG/SWD debugging with LPC-Link

23. September 2013 21:41 by Jens Willy Johannsen
Categories: ARM | Tags: , , ,

I had some problems getting my ROV on-board controller (which uses a LPC1347) programmed from LPCXpresso.

After doing the research I should have done before I had the PCBs made (doh), I found out I had messed up the SWD programming/debugging connections.

And so, in order to spare anyone else the same trouble, here is a small recap of which wires to connect to what.

Connections from LPC11U24/LPC1347

These are the minimal connections from the MCU to the LPC-Link:

Pin name LQFP48 pin no. Connect to
#RESET/PIO0_0 3 SWD pin 10 (#RST)
SWDIO/PIO0_15/AD4/ 25 CT32B1_MAT2 39 SWD pin 2
SWCLK/PIO0_10/SCK0/CT16B0_MAT2 29 SWD pin 4

Note: It is not necessary to have pull-up resistor on #RESET (or any other pin) unless other parts of the circuit might affect the levels since it is internally pulled up to VDD.

Connections from JTAG/SWD

These are the minimal connections from the LPC-Link to the MCU board.

Pin number Connect to LQFP48 pin no. Comment
1 3.3V on MCU 8, 44
2 SWDIO 39
3 n/c Optional GND (see note 1)
4 SWCLK 29
5 n/c Optional GND (see note 1)
6 n/c Optional SWO (see note 2)
7 n/c
8 n/c
9 GND 5, 41
10 #RESET 3

Note 1: It is sufficient to connect one of the GND pins (e.g. SWD pin 9) as pins 3, 5 and 9 are all connected on the LPC-Link.

Note 2: SWD pin 6 can be connected to PIO0_9/MOSI0/CT16B0_MAT1/SWO (LQFP pin 28) but this is not required.

Pin numbering

This image shows the pin numbering on the LPC-Link. Pin 1 has been marked in red.

Do yourself a favor and perform a continuity check from the LPC-Link side to your MCU board to make sure which pins go where.

LPC-Link pinout

LPC-Link pinout

(Image composited from images from and

Be aware that the 0.1" pins on the right edge of the board do not follow the JTAG pin numbering but have these connections:

  1. VCC
  2. SWDIO
  3. SWCLK
  4. SWO
  5. TDI
  6. #RESET
  7. EXT. PWR
  8. GND

The required pins are 1, 2, 3, 6 and 8.

Connection procedure

Sometimes LPCXpresso can't initialize the LPC-Link even though it is connected. I have found that following the following procedure works every time:

  1. Launch LPCXpresso IDE
  2. Power up device
  3. Attach to LPC-Link
  4. Connect LPC-Link to computer by USB
  5. Debug firmware from LPCXpresso
No comments No comments »

iBeacons ready

3. September 2013 11:42 by Jens Willy Johannsen
Categories: General | Tags: , ,

UPDATE: BLE112 firmware source code can be downloaded here: BLE112 iBeacon firmware. It should be pretty well documented so please try to figure it out yourself before asking :)

Here's a snap of the first two "production" iBeacons (not really production models but a lot prettier than the previous mess-o-wires prototype). They are based on BLE112 Bluetooth modules and contains nothing more than a coin cell battery, a tiny DIP switch for configuring the device identifier without re-flashing the firmware, a capacitor and a diode for reverse polarity protection when external power is used instead of the coin cell battery. And a BLE112 module, of course.

Click for larger image

Click for larger image


Here are the Eagle files for schematic and board:



The firmware source code can be downloaded here: BLE112 iBeacon firmware.

Comments 81 comments »

iBeacon working!

12. August 2013 0:05 by Jens Willy Johannsen
Categories: General | Tags: , ,

Yea and verily! I've successfully flashed a BLE112 with firmware that makes it behave as an iBeacon that can be used for iOS 7's Bluetooth LE location services.

By using a CC2540 USB Dongle and TI's SmartRF Packet Sniffer application and an iPhone running a sample app provided by Apple on the Development site, I reverse engineered the iBeacon protocol and made a firmware project for a BLE112 using a minimal GATT profile and a BGScript to set the custom advertising data required for a iBeacon.

I guess I'd better design a PCB for a minimal circuit containing a BLE112, a 3 V coin cell and a programming header.

The iBeacon in all its glory. And a bunch of unused wires.

The iBeacon in all its glory. And a bunch of unused wires.

Comments 8 comments »

Schematic component naming

9. August 2013 10:45 by Jens Willy Johannsen
Categories: General, PCB

Looking at some of my old schematics, I can see that I haven't been entirely consistent when naming components. Nowhere near consistent, actually.

Sometimes I have used "T" as prefix for transistors and sometimes "Q". And especially IC's that are prefixed either with "U" or "IC" – often I have used both in a single schematic. And also connectors that are named "CON" or "J" or "JP". Sloppy…

Well, no more! This page on Wikipedia has a nice table with designators for various component types (even though it does not comply with with IEEE- or ANSI-whatever standard).

So this is what I will use henceforth:

Designator Component type
R Resistors
C Capacitors
L Inductors, coils
D Diodes – all types including Zener, Schottky and LEDs
U IC's of all kinds. Technically it is used for "Inseparable Assemblies".
J Connectors. The more fixed part of a connector pair (often the part soldered to the PCB).
P Plugs. The less fixed part of a connector pair (i.e. the one on the wire).
K Relays
M Motors
Q Transistors – all types including MOSFETs, IGBTs, BJTs etc.
S Switches
Y Crystals and oscillators
X Transducers/sensors (no, X is not for crystals anymore).
FB Ferrite beads
BT Batteries
JP Jumpers. Not connectors but only actual jumpers that are linked or unlinked.
TP Test point (pad or pin for measuring)
MP Mechanical parts (standoffs, screws, mounting hardware etc.)
No comments No comments »

iBeacons: iOS 7 and Bluetooth LE positioning

9. August 2013 9:14 by Jens Willy Johannsen
Categories: General | Tags: , ,

Apple has announced the introduction of Bluetooth LE-based positioning in their iOS 7 framework. Apps can now get notified when entering a region which basically is defined as being close enough to a BTLE beacon with a specific identifier.

The iOS framework already supports the concept of regions and notifications when entering regions, but until now the system has relied on GPS and WiFi positioning. Which will not be able to provide very accurate positioning data when used indoors.

Bluetooth LE-based positioning, however, will work just fine. And will be able to provide very accurate positioning data. Right down to "you are standing in front of this particular sculpture in the museum" or "you are standing at check-in counter number 18". Nice.

In keeping with the classic Apple way of doing things, Apple has decided not to use the existing Bluetooth Proximity Profile but do things their own way.

Since Apple has not published the specifications for the iBeacon protocol yet, I had to snif the Bluetooth packets from an iBeacon device (using a TI CC2540 USB Dongle and their SmartRF Packet Sniffer –

Apple puts all the required information into the advertising packets in a "Manufacturer Specific Data" field of connectable undirected advertising events.

Apple's iOS 7 pre-release documentation shows what properties are available for iBeacons (but I'm not going to tell you since that information is still under NDA) so they are fairly easy to spot in the advertising data and so it should be easy to copy – and if necessary modify – that data and put it into a BLE112 of my own.

I'll keep you posted as to how it works…

No comments No comments »

ROV power board

24. May 2013 15:12 by Jens Willy Johannsen
Categories: Projects | Tags:

Here are Eagle schematic and board files as well as BOM for the ROV power board.
I moved all the high voltage/current stuff to a separate PCB and separated the control connections by using optocouplers.

That should help avoiding the electrical noise from the power MOSFETs switching at 20 kHz for the thruster motors.


Amount Item Spec RS no. Comment
1 TE Micro-MaTch 12 pos female 6804978 Or just solder wires directly to the board
1 TE Micro-MaTch 12 pos male 6804993
1 12 lead ribbon cable 2899852 This is actually 14 leads. Peel off two or use separate wires.
6 IRLS3034-7 MOSFET 6887257
6 FOD3180 optocoupler DIP-SMD 6712706
7 Screw terminals BLK 4813989
7 Screw terminals RED 4813973
6 SMD diode S5BC 7514821
6 SMD capacitor 100 µF 7472871
6 Ceramic bypass cap. 0805 0.1 µF 6480979 Or any other 0.1 µF 0805 ceramic cap.


Eagle schematic and board files

Comments 2 comments »

Great reply to the “3D printed gun” media frenzy

7. May 2013 15:03 by Jens Willy Johannsen
Categories: 3D printing

The past few days, the media have been having a field day with the "now you can 3D print you own gun" story. (Here on BBC for example).

Do yourself a favour and read this comment on Hackaday before you join the choir…

No comments No comments »

3D printed camera holder

9. March 2013 19:43 by Jens Willy Johannsen
Categories: 3D printing | Tags:

Here's another 3D printed component: a tiltable camera holder. It consists of two parts: the base and the front plate. The front plate has four standoffs with 2 mm holes for mounting the camera PCB with M2 machine screws. It also has a small bracket with a 1 mm hole for the rod that connects to the servo.

The front plate is attached to the base by M2 machine screws. The holes in the base are larger than the screws so they can rotate freely and a washer between the screw head prevents the screw head from digging into the plastic.

Here is a model of the front plate (modelled in ViaCAD 2D/3D) and the front plate and base assembled and checked for clearance when rotating in Autodesk Inventor Fusion (click for full-size):


And there is the finished and assembled piece:

3D printed camera holder (click for full-size image)

3D printed camera holder (click for full-size image)

CAD files

Comments 2 comments »

Repetitive Interrupt Timer on LPC1347

9. March 2013 19:30 by Jens Willy Johannsen
Categories: ARM | Tags: ,

For my ROV project I need to control an RC servo to tilt the camera up and down. I've gotten that working nicely using a 16-bit timer to generate an appropriate PWM waveform.

But when I change the the position by a lot – for example, going from one endpoint to the middle position – the servo moves too fast. (Which, incidentally, draws a huge current which makes my 5 V rail drop enough to reset the MAX7456 – but that is fixable.) So I need to slow the movement down by gradually changing the position instead of jumping straight from one position to another.

The full servo movement corresponds to a change in timer match value by 1000 (the PWM timer is set up so the match values correspond to PWM pulse on-time in microseconds so minimum is 1000 and maximum is 2000). I would like the full range of movement to take one second so I thought that changing the position in increments of 10 at a frequency of 100 sounds about right.

Unfortunately, I'm fresh out of timers: CT32B0 and -1 are used for motor control PWM, CT16B0 is used for periodic analog-to-digital conversions (for the pressure sensor used as depth gauge) and CT16B1 is used for servo PWM. Yeah, sure, I guess I could use a timer for more than one purpose but since the LPC1347 actually has one more timer, I might as well use that: the Repetitive Interrupt Timer.

The Repetitive Interrupt Timer (RIT for short) generates interrupts every X clock cycles and if I configure the timer to fire an interrupt every 720,000 clock cycles I get a 100 Hz interrupt (on a 72 HMz PCLK) in which I can move the servo if necessary. Nice.

This is the code I came up with: Repetitive Interrupt Timer on LPC1347

// MIN and MAX macros 
#ifndef MIN 
#define MAX(a,b) (((a)>(b))?(a):(b)) 
#define MIN(a,b) (((a)<(b))?(a):(b)) 

// Servo position variables 
volatile uint16_t servo_position; 
volatile uint16_t servo_target; 

// Stop RI timer – otherwise we can't reset the counter 

// Init RI timer (we don't need to enable timer – it is always running as per the updated User Manual UM10524) 

// Reset counter (otherwise it might already be above the compare value and then it would take a loong time to overflow to zero) 

// Set RITENCLR (clear on match), RITENBR (halt timer on debug) and RITEN (start timer) 
LPC_RITIMER->CTRL = (1<< 1) | (1<< 2) | (1<< 3); 

// Enable RIT interrupt
NVIC_EnableIRQ( RIT_IRQn ); 

// Interrupt routine 
// (Yes, it's a little weird that the interrupt routine is called OSTIMER but the NVIC interrupt is called RIT_IRQn) 
void OSTIMER_IRQHandler() 
	// Clear interrupt 
	LPC_RITIMER->CTRL |= (1<< 0);	// Write RITINT to clear 

	// If we're at target, do nothing 
	if( servo_position == servo_target ) 

	if( servo_target > servo_position ) 
		servo_position += MIN( servo_target - servo_position, 10 );
		// Not equal and not greater than, so it's less than – we don't need to check 
		servo_position -= MIN( servo_position - servo_target, 10 ); 
Comments 4 comments »

SPI on LPC1347 vs capacitance, part II

6. February 2013 22:35 by Jens Willy Johannsen
Categories: ARM | Tags:

Aha! Gotcha!

(This is a follow-up to my last post about GPIO delay and capacitance.)

Looking again at the scope captures, I thought that the stray capacitance from boards and wires couldn't possibly account for the huge 18 microsecond delay. And my colleague, who has an actual education in these things, agreed. Thanks, Niels :)

Then we took a look at the base board schematic. And lo and behold:

The culprit: C42

The culprit: C42

A 100 nF capacitor right on the PIO1.13 line. Yes, it's called GPIO_21 in the schematic – it is slightly confusing but it is, in fact, PIO1.13. Removing the J33 jumper (thereby disconnecting PIO1.13 from the capacitor) and removing the 48 cycles delay it looked like this on the scope:

Nice steep transitions on the CS line

Nice steep transitions on the CS line

and like this on the logic analyzer.

And no unnecessary delays

And no unnecessary delays

Everyone is happy. Now off to cobble together some RS-485 code.

No comments No comments »

SPI on LPC1347 vs capacitance

5. February 2013 22:07 by Jens Willy Johannsen
Categories: ARM | Tags: , ,

Or "Capacitance matters – who'd've thunk it"

I am using SPI to talk to a MAX7456 video overlay IC from an LPC1347 MCU in my ROV project.

That should be easy enough since the LPC1347 contains twp SPI compatible synchronous serial ports ("SSP" for short). Perusing the manual and some code examples I came up with code to initialize the SSP for SPI comms and to send SPI data.

But, alas, it didn't work :(

Connecting my trusty Saleae Logic analyzer I saw that the CS line was toggled low and then high again for every byte. Which the MAX7456 apparently doesn't like – it wants the CS line to be low for the entire command (which consists of several bytes) – just as described in the datasheet.

So I switched to manually toggling a GPIO line low before transmitting SPI data and then high again when transmission is done. Like this:

#define MAX7456_CS_ON LPC_GPIO->CLR[ 1 ] = (1<< 13)
#define MAX7456_CS_OFF LPC_GPIO->SET[ 1 ] = (1<< 13)




And, for reference, the spi_transfer() function looks like this:

void spi_transfer( uint8_t data )
    // Wait until SSP is not busy and TX FIFO is not full
    while ( (LPC_SSP0->SR & (SSPSR_TNF|SSPSR_BSY)) != SSPSR_TNF )

    // Send data
    LPC_SSP0->DR = data;

But that didn't work either. Looking at the logic analyzer it turned out that CS came low several microseconds after the SPI transmission started. Weird, since the the GPIO pin is set low before I start the SPI. I also tried using the byte pin and word pin registers but the result was the same.

So it just looks like the GPIO is just really, really slow. What I finally came up with that works was this:

#define MAX7456_CS_ON { uint8_t i; LPC_GPIO->CLR[ 1 ] = (1<< 13); for( i=0; i<48; i++ ) __NOP(); }
#define MAX7456_CS_OFF LPC_GPIO->SET[ 1 ] = (1<< 13)

In other words: let the CPU wait for 48 clock cycles after setting the pin low before trying to do something else.

On the logic analyzer, it looks like this:

Logic analyzer capture. With delay.

Logic analyzer capture. With delay.

Still weird though. Until I connected a scope instead of a logic analyzer. Then it looked like this without the delay:

Scope capture. Without delay.

Scope capture. Without delay.

And this with the delay:

Scope capture. With delay.

Scope capture. With delay.

So it looks like the delay is, in fact, not the MCU's GPIO that is slow but rather capacitance. So even though the pin was toggled low the capacitance caused the voltage to decay slowly (relatively speaking) instead of instantly. So without the delay, the voltage never dropped low enough for the MAX7456 to consider the CS low. Now bear in mind that the pin is connected to the MAX7456 though the LPCXpresso board, the LPCXpresso Base Board, a jumper wire and then the MAX7456 breakout board. All of which have non-zero capacitance.

In other words: when working with high-speed (in this case 4 MHz) signals, make sure you design the board with that in mind and minimize capacitance (and inductance).

Unfortunately, I have no experience with that kind of semi-advanced PCB layout. Fortunately I can fix it in software and the delay I introduce will not pose a problem in this case.

Comments 2 comments »