jenswilly.dk

Microcontrollers and embedded electronics

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 2 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: ,

pixhawk-chdk

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.)

Configuration

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.

PCB

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:

iris_light_schematic

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.

Wiring

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.

Prototype

Here is how the prototype looks:
light_proto

And yes: it is bright:
light_proto_on

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):
iris_light_pcb

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: https://github.com/jenswilly/ios-eagleview

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 12 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 9 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…

Parts

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…

Improvements

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

Links

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.)

Self-shutdown

Inspired by this post on electronics.stackexchange.com, 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 http://www.keil.com and http://www.embeddedartists.com.)

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

Schematics

Here are the Eagle files for schematic and board:

iBeacon_schematic

Firmware

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 – http://processors.wiki.ti.com/index.php/BLE_sniffer_guide).

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.

BOM

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.

Files

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):

cam_holder_model
cam_assembly

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)

Kommentarer 1 comment »

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))
#endif

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

// Stop RI timer – otherwise we can't reset the counter
LPC_RITIMER->CTRL = 0;

// Init RI timer (we don't need to enable timer – it is always running as per the updated User Manual UM10524)
LPC_RITIMER->COMPVAL = 720000;
LPC_RITIMER->COMPVAL_H = 0;

// Reset counter (otherwise it might already be above the compare value and then it would take a loong time to overflow to zero)
LPC_RITIMER->COUNTER = 0;
LPC_RITIMER->COUNTER_H = 0;

// 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 )
        return;

    if( servo_target > servo_position )
        servo_position += MIN( servo_target - servo_position, 10 );
    else // 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)

MAX7456_CS_ON;

spi_transfer(VM0_reg);
spi_transfer(MAX7456_reset);

MAX7456_CS_OFF;

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 »

Calculating stress for an acrylic disk at depth

2. February 2013 16:20 by Jens Willy Johannsen
Categories: Projects | Tags:

For my ROV project, I am considering using a flat acrylic disk instead of a dome for the front "window".
So I needed to calculate if a disk of a certain diameter and thickness would hold up to the pressure exterted at a specific depth.

A couple of hours of Googling led me to these calculations and constants:

The maximum stress a uniformly supported disk is subjected to (of a given material and of a given thickness and radius) is calculated as follows (from here):

σ = 3(3 + ν)pr²
——————
8t²

Where

σ   is the maximum stress in Pa
ν   is Poisson's ratio for the material (0.37 for acrylic from here)
p   is the pressure the disk is subjected to in Pa
r   is the disk's radius in meters
t   is the thickness in meters

If the maximum stress exceeds the material's flexural strength, the disk will break.
For acrylic the flexural strength is 100 MPa (from here).

I entered the values for a 6 mm thick 110 mm diameter disk at a pressure equal to 25 meters depth and the result is that the max stress on the disk is 37 MPa. So it will hold.

You can enter your own values in the InstaCalc formula I made here: http://instacalc.com/9335.

No comments No comments »

Soft UART on LPC13xx

23. January 2013 11:32 by Jens Willy Johannsen
Categories: ARM, Projects | Tags: , , ,

For the ROV project I need two UART connections (one for RS485 to the onboard controller and one for receiving input from the VNC2 USB host controller).

And since the LPC1347 only has one UART I needed a soft UART for one of the connections. Fortunately for me, NXP provides an implementation in AN10955. There was only one problem with it: it doesn't work. Or rather, it works for a while and then stops receiving anything (scoping the UART line confirmed that the VNC2 chip continued to send data so the problem had to be in the soft UART code).

Yea, intermittent errors – what's not to like… (Read on for the problem and the solution.)

Read the entire post »

Comments 2 comments »

New power supply

20. January 2013 12:50 by Jens Willy Johannsen
Categories: General | Tags:

How, oh how did I ever live without it?
Just before Christmas I finally caved in (to myself) and got myself a decent bench-top power supply. A TTi PL303-QMD (datasheet/brochure here).

Yes sure, there are more advanced units out there but this one suits my needs just fine: dual 3 ampere outputs (which can be paralleled together for a total of 6 amps), voltage span setting (so the voltage dial only adjusts voltage from e.g. 3.0 to 3.4), 500 mA mode (allowing much finer control over the current setting up to 500 mA).

And now I can't imagine how I ever got by without it. So if you are considering splurging on a decent PSU, consider no more and get this one right now!

PL303QMD (click for larger image)

Kommentarer 1 comment »

DC motor drive from 3.3 V MCU

29. November 2012 22:24 by Jens Willy Johannsen
Categories: Projects | Tags: , , ,

For the ROV project I need to drive six DC motors (waterproof motors from bilge pumps). They are 12 V DC brushed motors running a 6 amps at full speed and I want to control them using PWM (for variable speed) from an LPC1347 MCU.

A popular way of controlling DC motors is by using an H bridge. However, since I only need to drive the motor in one direction I can use a simpler configuration: a single N-channel MOSFET as a low-side switch.

First I need to find a MOSFET that can handle the 6 amps continously and not get too hot. And since I will switching the MOSFET on and off using PWM at a frequency of 20 kHz I also need to consider switching power loss.
Here are a couple of useful links: choosing a MOSFET, MOSFETs and drivers, MOSFET power dissipation.

Gate current and MOSFET driver

Even though the MOSFET doesn't require a high voltage to fully switch on, the MOSFET gate does have a quite high capacitance (typically, the higher current a MOSFET can handle the higher gate capacitance it has) and in order to switch the MOSFET on and off quickly enough we need a high current (of the order of a few amps).
If the gate current is low it takes longer to switch the MOSFET and the resistance through the MOSFET is much higher when the MOSFET is switching. And higher resistance means higher power loss and higher temperatures.

Since the MCU cannot provide or sink more than 4 mA we'll use a MOSFET gate driver to boost the current from the MCU and to handle the higher sink current.

Flywheel diode and capacitor

I won't go into details since you can read about it in great detail elsewhere (Wikipedia for example) but you do need a diode and a capacitor on the motor circuit. I tried without diode and capacitor with a scope attached. With no flywheel diode there were some really large voltage spikes every time the motor stopped (about 130 V). And without the capacitor (but with diode) there was a nasty "ringing" (starting out a about 20 V) every time the motor stopped.

So the final circuit is:

Motor drive circuit

Comments 4 comments »

Reading USB joystick data from Vinculum-II

30. October 2012 10:52 by Jens Willy Johannsen
Categories: General | Tags: , , ,

Success! I have managed to write and compile firmware for the FTDI Vinculum-II (VNC2) USB host IC so I can read HID reports from a Saitek Cyborg EVO joystick, parse the data into values for the X, Y, rotation and throttle axes and button states and transmit any change in values by UART which can be received by an MCU.

This is what I did:

First, I got a V2DIP1-32 development module. This is basically a VNC2 (the 32-pin version) on a PCB along with a 12 MHz crystal, a USB A socket, a 3.3 V voltage regulator, an LED and a couple of capacitors and resistors. In other words, only basic support components.

Next, I installed the Vinculum-II Toolchain (the development IDE) version 2.0.0 and then updated to SP1.
The IDE works ok. Especially the application wizard works well and gives you a good starting point for your own firmware by adding the necessary libraries, headers and scaffolding code based on your selection of IC, USB ports in use and required drivers.
But the IDE is Windows-only software… *sigh* I hate that. Fortunately I have my old MacBook Pro with Windows 7 on a Bootcamp partition.

To flash the compiled firmware onto the chip I used FT-Prog
and a FTDI TTL-232R-3V3 cable connected to the VNC2 as described in this application note.

Note: you don't need the VNC2 Debugger/Programmer Module to flash the VNC2 – the USB-to-UART cable is sufficient – even though the FTDI website states that the Debugger/Programmer module is required for initial programming.

On to the firmware itself. I did start by wasting a couple of hours by not reading the VNC2 dev board's datasheet closely enough to notice that the USB socket on the board is connected to USB port 2 and not – as I figured – port 1. After tweaking the supplied example project 'USBHostHID' and reading the documentation I pretty quickly had some firmware that did what I wanted: wait for a HID device with the specified VID/PID to be connected, read HID data, parse the data into corresponding X, Y, Rz, Z and button values and, if any values change, send the new values over the UART connection.

Here's the complete firmware project (including compiled .rom file).
And here is a sample dump of the UART output. If a line starts with a "S" it is a status message, if it starts with "E" it is an error message and otherwise it is a value update.

If you want to use this project to read data from your own joystick (and it's not a Saitek Cyborg EVO), you'll have to change:

  1. The VID/PID for the joystick:
    // find VID/PID of Saitek Cyborg EVO device
    hc_ioctVidPid.vid = 0x06a3;
    hc_ioctVidPid.pid = 0x0464;
  2. The parse_hid method to match your own joystick's HID descriptor.
Comments 2 comments »

Parsing USB joystick HID data

25. October 2012 23:02 by Jens Willy Johannsen
Categories: General | Tags: , ,

As part of using a USB joystick as input device to an MCU I needed to parse the raw HID data of the joystick into values on the various axes and button states.

This is the first time I have had to manually get from a HID descriptor and some raw data to something that makes sense.

Read the entire post »

No comments No comments »