I sell on Tindie
Map
Grand Prize Winner
(Dec 2012)
Second Prize Winner
(July 2012)












Prototyping Enclosure in SolidWorks

This design activity was a bit more about test driving SolidWorks. We are not industrial designers and in fact didn’t have any previous experience with this CAD system. Well, strictly speaking, it was the second Dmitry’s creation in SolidWorks while the first one was really primitive, made of sheet metal which by its nature doesn’t allow to create anything but boxy shapes. This time there was a need for a conceptual design of an enclosure for a wearable data logger. The case had to be a little more sophisticated than just a round shape and it was meant to provide housing to a PCBA with CR2032 battery. Also the was a requirement to have a lid covering four pins for interfacing with an external sensor. This was the first prototype we came up with, bottom and top shells and a lid:

Bottom Shell

The two halves had internal supports to hold the PCBA tightly inside preventing it from shifting and twisting,

Top Shell

The lid had two lugs and was supposed to be attached to the top half with a pin playing a role of an improvised hinge. Also the lid had two flanges, one to lock it to the housing and one to simplify its opening with a finger:

Lid

This electronics design was done in Altium and the PCBA 3D model was exported to SolidWorks:

PCBA

These two pictures below were rendered in Altium:

PCBA Rendered in Altium, Bottom View

PCBA Rendered in Altium, Top View

The final virtual assembly was done in SolidWorks:

Downloads:

1.Design files in STEP format

PS:
1.The battery holder was actually modelled in FreeCAD;
2.Even though we also did the circuit diagram and PCB layout the designs don’t belong to us so we can’t publish them here;

An Internet Controlled RGB Night Light

There are moments when we step away from serious projects and experiment with new tools, materials and ideas. This project falls into a fun category however, we do hope that it could be of some interest for the DIY community. For quite some time we were thinking about making an original birthday present and finally chose the idea of a night light. The light was meant to be a silhouette of an animal or a person mounted on a wall and glowing in the dark. It would be also very nice to be able to control brightness and colour in easy manner, probably by a mobile phone rather than by a specialised remote control. After doing a quick research it has been established that there were a lot of dimmable RGB LED controllers with either Bluetooth or WiFi interfaces available. In case of WiFi a controller simply integrated into existing wireless infrastructure and became a truly IOT device controllable not only from local network but from outside, trough the Internet. However, the idea wasn’t novel and we still had to give to our night light original look. We went trough tons of pictures and finally found the one which most suited to the receiver of the present, it was a silhouette of a girl and a dog.

Having decided to use a laser cutting service we obviously couldn’t upload a raster picture to the service provider and first needed to convert the picture into a vector image format. This was easily achieved by an opensource software called Inkscape. The procedure turned out to be extremely simple, after loading a jpeg image all that needed to be done was ‘Path-Trace Bitmap’ dropdown menu and a vector image was ready for further manipulations as shown on the picture below:

Girl And Dog Composition, Raster Traced Into Vector

Next step was to prepare a template for Ponoko using their standards. Instead of ordering just one silhouette we decided to pick a bigger blank and make more than one night light. Of course, all of them had to be original so we repeated the previous search two more times and came up with different pictures. It took some significant effort to fit all of them without overlapping but it was ultimately achieved. The final result ready for laser cutting order is shown below:

Night Light Figures Template For Laser Cutting

As a controller we decided to use the one capable of driving RGB LEDs, dimmable and with WiFi interface. The unit has a good software support which covers both iOS and Android platforms. There are timers to switch the lights on and off at specific times, colour mixing and transitioning effects and even an option to flash the lights in rhythm with a soundtrack being played by a mobile phone. And most importantly, it is cheap, just 14 dollars with free shipment!

WiFi RGB LED Controller

Another aspect of the design was the way of mounting the lights on a wall. We did several design iterations starting from a bulky controller holder which had mounting holes in it but finally reduced the structure to just a few back supports which looked like dubmbbells. The back supports were designed in FreeCAD, converted into STL format and then 3D printed:

Back Support visualised by STLView

The first design actually exhibited a problem with plastic we chose – it was not totally opaque and the light was coming through. This is why we put a layer of self-adhesive foil mirror and fitted the LEDs and the controller with a double sided adhesive tape. However, it didn’t work for the back supports so we ended up gluing them with epoxy. The fully assembled night light is shown below:

Finished Girl And Doggy Night Light Reversed Side View`

The night light in action is shown below:

Girl And Doggy Night Light In Action

The bill of materials is rather expensive for this night light but we were focused on originality rather than on cost. There are many ways to bring the cost down by carefully choosing the right materials and laser cutting service.

Bill of materials
Item Price, Australian $
Lasercutting service including materials and shipping (sourced from Ponoko) 63.42*
Wireless Wifi RGB LED Strip Light Controller For IOS Android Phones DC 12V/24V, Ebay item 252902344423 17.99
60x100cm DIY Self Adhesive Foil Mirror Decals, Ebay item 222497290178 16.89
5050 SMD 3 RGB LED Module Waterproof IP65, Ebay item 252706573302 13.93
Switchmode Mains Adaptor 12VDC 2.5A (Source from Jaycar) 29.95
Back supports, 3D printed, design files are provided below, 4 or 6 items depending on the design N/A
Total 142.18
*the design actually contains three different night lights, this is why it is so expensive

Downloads:

1.Design of three night lights prepared specifically for Ponoko laser cutting service
2.3D model of a back support, STL format
3.3D model of a back support, FreeCAD format

A Handsoldered PCB Running Embedded Linux

A foreword

Homemade Linux boards have always been just a pipedream for many due to prohibitive complexity of both hardware and firmware. The situation hasn’t even changed with the arrival of Raspberry Pi and Beaglebone boards which still can’t be replicated in home labs either due to the absence of design files, proprietary components in small quantities or extreme difficulties with hardware manufacturing processes. Apart from the fact that third party hardware doesn’t give warm and fuzzy feeling of a personal achievement there is one substantial problem: a generic third party board can’t naturally fit a custom design. In fact, such board can’t organically fit any design. Just because it was created as a generic multipurpose board. Indeed, has anyone ever seen a goodlooking hardware solution made of an Arduino board and one or more shields? The answer is rather predictable: no. Same applies to the firmware implementation of such solutions, a quick and dirty approach with just one running thread, usage of bit bangs along with busy waits and absolute disregard towards sleep modes. So in pursuit of simplicity another very important characteristic – efficiency is often lost. Off-the-shelf Linux boards help to skip certain steps in development phase but create new problems in exchange. Take a Raspberry Pi, for instance. First version, model A didn’t even have such obvious things as mounting holes. It was designed as a desktop system without provision for powersafe considerations and the board was an inappropriate choice for autonomous robotic platforms. Later models offered more RAM, more performance and more peripherals such as USB ports. Meaning that even more power will be needed which is critical to battery powered systems. Besides, some hardware functionality is just redundant, say, for a mobile platform Ethernet and HDMI ports would be an overkill yet they exist and draw additional current. Raspberry Pi Zero came into play to address those issues but it has its own limitations, it also can’t efficiently cover the whole spectrum of possible applications just because the board was designed generic from the very beginning. Finally, modules and boards always have shorter lifetime than the components they are made of. It means that off-the-shelf boards will become obsolete faster than certain types of CPUs, memory chips etc so designing your own custom board specifically targeting your own user requirements will inevitably give more efficiency and better control in production.

The relevant Internet discussions and rumours have always claimed and still claim that it is extremely difficult if not impossible to build a working Linux board in home environment. To name just a few main challenges, these are: fine pin pitch (or even BGA) packages; necessity to route traces between CPU and memory with impedance and length matching; additional requirements for PCBs such as impedance control, multiple layers and better factory capabilities. The first challenge puts a limit to what can be handsoldered due to either extremely miniature dimensions or physical impossibility to access landing pads with a soldering iron. The impedance and length matching becomes important as SDRAM has high frequency interfaces at which PCB’s dielectric property, trace width and length begin significantly influential on signal propagation causing signal integrity issues in case of improper or sloppy design. The third challenge is higher quality requirements to PCBs and number of layers bigger than two which makes boards more expensive and gets really close to the limit of hobbist’s affordability. However, as it turns out, most if not all challenges can be properly addressed and a reasonable compromise may be found.

Recently we bumped into a very promising opensource minimalistic design of a board capable of running Linux. The project had a name Olinuxino and the simplest board was claimed to be a ‘DIY friendly’ as it didn’t have any BGA packages. We checked the design against the three abovementioned main challenges and to our surprise we found out that all of them were more or less addressed. Indeed, there were no BGA packages whatsoever and the most difficult components to solder were ICs in 66TSOP and 128TQPF packages, 0.7mm and 0.4mm pin pitch. The latter one sounded extreme, the smallest pitch that we had soldered before was 0.5mm. Still, it sounded eminently possible. For the second challenge the project had an elegant solution – it didn’t have impedance and length matching claiming for DDR1 running at 133MHz it wasn’t a must even though it was against SDRAM datasheet. Still, there was a small trick as the DDR IC was placed on the bottom side of the board, strictly under the CPU, minimising the length of high speed traces. Also, each critical trace had the same amount of vias, one, to be more precise. For the third challenge there was also an elegant solution – the board had a layout in just… two layers! And along with the absence of impedance matching requirement it put the board into a definitive DIY category as now it became possible to make it using one of the most popular and cheap service like the one provided by ITeadStudio! Well, in principle as the last statement we were going to prove. Or disprove.

We decided to try to build MX233-OLinuXino-MICRO, the least complicated board of the Olinuxino family and in case of success would get a platform with the following characteristics (pretty impressive if compare with conventional Arduino or mbed platforms):

IMX233 Olinuxino Micro
– iMX233 ARM926J processor running at 454MHz
– 64MB DDR1 running at 133MHz
– MicroSD card connector
– 1 USB High Speed Host
– TV PAL/NTSC output
– Three buttons (a hardware Reset and two software configurable buttons)
– 2×30 GPIOs for interfacing with external hardware

Making PCB

A truly DIY design should be eminently reproducible with a truly DIY friendly manufacturer and many would agree that ITead Studio with its PCB prototyping service is a leader here. That is why we found and downloaded ITead_rule.dru from ITead, opened the Olinuxino’s PCB layout and performed a design rule check. At first the outcome turned out to be shocking:

The number of DRC errors, 463 in total was overwhelming. But then we tried to group those errors by types and found out that there were only five types, most of them fell into a category Stop mask collides with either a via or a landing pad. Those kind of errors would be safe to ignore as they didn’t impact electrical characteristics of a board. The second type was a Power trace width error. The analysis revealed that there was a minimum trace width for power traces specified but several traces were breaking the rule. It was due to the fact that some segments physically couldn’t be made any wider as they were routed to SoC’s landing pads as shown on the picture below. No fix for this DRC error was needed:

iMX233-OLinuXino Power Trace Width Error

The third type of DRC errors reported about traces overlapping each other as show on the picture below. This was because some jumpers were in ‘closed’ state by default, in other words, they were shorted by a trace causing DRC error. No fix for this errors was needed:

iMX233-OLinuXino Trace Overlap Error

The fourth type of error was about minimum drill distance. Indeed, it makes little sense when looking at the picture below. However, in most cases it will be understood by the PCB manufacturing houses. The thing is that Eagle CAD doesn’t have any means to define slots, not round holes! Yes, that ironic, the product is mature enough, it doesn’t come for free and requires a commercial license, it has became a de-facto standard for thousands of hobbysts and small companies around the globe but still it lacks that very important feature! So by defining multiple overlapping drill holes it becomes possible to specify slot outlines and most factories do interpret this correctly. It is obviously a workaround but it is perfectly legitimate . No fix for this DRC error was needed:

iMX233-OLinuXino Drill Distance Error

The fifth and the last DRC error was about excessively small clearances between several tracks and annular rings. In other words, the tracks were too dense. There were only three problematic areas of that type and they definitely needed a fix. To our surprise, it didn’t take too much effort to add a bit of spacing between them, there was enough of real estate on the PCB. That fact left us a bit puzzled, it was not quite clear why whoever did the initial design made those tracks dense:

iMX233 OLinuXino PCB Layout – Errors to be corrected to comply with iTeadStudio Manufacturing Capabilities

In the end, the design successfully passed the DRC check with warnings which we were happy to accept. The board seemed to match ITead’s capabilities so we submitted our order in no time and making our first big mistake without even realising it. The problem lurked in electronic components and their actual availability. It turned out that not all of them were available on Digikey and we had to hunt on Ebay to get some. Even if there was functional replacement on Digikey it didn’t have either pin-to-pin compatibility or simply had slightly different footprint which would be an easy fix if our PCB design had’t been already in production. As a rule of thumb, it is always a good idea to compile a bill of materials and check component availability before ordering PCB production and this time we didn’t stick to the rule thinking that the proven design shouldn’t suffer from those issues. It was another common mistake though – never make assumptions, always double check.

iMX233-OLinuXino-Micro iTead friendly PCB layout

The original design files didn’t have bill of materials (BOM). Not only that, the circuit diagram didn’t contain enough information to generate BOM. None of the components had a supplier or part number. Many components had values but didn’t have specific requirements such as ESR or ESL values for decoupling capacitors, their tolerances, preferred technology (either ceramic or electrolytic), inductors were also lacking specific parameters which are so important in high frequency circuits. So we had to study the original i.MX233 reference design, search for original manufacturer numbers, find missing parameters and in case of their unavailability look for appropriate replacement. Some components gave us really hard times as we couldn’t even find any useful information about parts like the mircoSD card. It had many names and was designed by a noname Chinese company making it very hard to identify and obtain. Eventually the BOM had been compiled but several parts had to be purchased from Ebay, these were the microSD memory card (refnum SD/MMC), 512MB DDR (refnum U2, later we discovered that there was a direct substitution available on Digikey), and a USB power switch (refnum U3). Also, we didn’t find a crystal (refnum Q1) with the required stability (it was defined as 20ppm yet we managed to find only 30ppm, it was 24MHz instead of 24.000MHz and its capacitance wasn’t specified anywhere so we used 20pF). Knowing that the i.MX233 was very sensitive to the crystal parameters we were not so sure if our part would work and were emotionally prepared for instabilities). For each part a 3D model has been created and we had an opportunity to check the fitment of each component even before the actual boards were manufactured. The 3D model of the whole assembly is available at 3D Warehouse so it becomes really easy to design extension boards or enclosures.

The rendered top and bottom views of the PCB’s 3D model are given below:

iMX233-OLinuXino-Micro iTead Friendly PCBA, 3D Top View

iMX233-OLinuXino-Micro iTead Friendly PCBA, 3D Bottom View

Soldering components

The manufactured boards arrived from ITeadStudio. We picked one of them and gave it a careful look using an inexpensive USB microscope. It became obvious that our design was really close to the factory’s capabilities: many via drills were slightly off-centre of their annular rings, straight lines of the silkscreen and the copper traces were visibly wobbly. It wasn’t perfect but it didn’t look bad either. With all components being already in our stock it was the time to start actual soldering. We didn’t have in our possession any reflow oven nor pick-and-place machine. Instead, a soldering station for amateurs, TS1390 from Duratech was used. The most difficult two components to solder were obviously U1 and U2, the latter one was a bit easier. We decided to start off with these two as there was no guarantee that it would be possible at all and at first practiced with U2. As an experiment, we decided to try using soldering paste and by doing this made a big mistake. Without use of a proper paste dispenser the amount of soldering paste on each pad and around it becomes uncontrollable causing excess of paste remain unsoldered and trapped between pins and IC’s package. That excessive paste can cause short circuits and it is very difficult to remove.

ITead friendly OLinuXino-Micro blank board

The biggest challenge during soldering U1 was to accurately position it in such a way that all four rows of pins would rest exactly on their pads. For us it actually took more time than the actual soldering. We temporary soldered two pins diagonally then triple checked and confirmed the operation with a microscope. Finally we gave ourselves a go to solder the remaining pins. Inevitably, many of the adjacent pins became shorted during the process, this was later rectified with the help of a de-solder braid. Finally everything was carefully checked under microscope again. However, at that time we overlooked the remnants of the soldering paste which is still visible behind the pins on the picture below:

Hand soldered 128-LQFP (14×14)

After soldering the two most difficult components the rest was simple. No doubts, there was still need for a steady hand as most of the capacitors and resistors were in 0306 packages which require delicate handling but there was nothing extremely hard here. The fully assembled board was cleaned to remove flux and was inspected through a microscope again. The board looked almost like its 3D model as it is seen on the pictures below:

ITead friendly OLinuXino-Micro assembled top view

ITead friendly OLinuXino-Micro assembled bottom view

Applying power

The next step was to apply power for the first time and evaluate current consumption. To do this safe way there was a need for a regulated power supply with overcurrent protection. We set up our bench power supply to 5V and limited current to just 500mA then applied power to the board through the power jack PWR. To our surprise, the was no smoke or anything bad. The bench power supply indicated 5mA current consumption and it seemed to be too low to be truth. Shortly after we found some information in the Internet stating that in non-initialised mode the current consumption is expected to be around 6mA due to the fact that most SoC subsystems are still switched off and DRAM is not yet configured so the consumption is minimum. And if so, our board passed the first test.

Building a kernel

The process is described in detail at https://github.com/koliqi/imx23-olinuxino. However, at the moment of writing this article the original information was at least 5 years old and while trying to follow the guide we encountered many differences. This is why we decided to post a full updated instruction here. We were using the following Linux distributive:

Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

All subsequent interactions are made through a terminal. Make sure that a cross compiler and git are installed:

$: sudo apt-get install gcc-arm-linux-gnueabi
$: sudo apt-get install git

Get the Freescale bootlets, patches for them and elftousb2 utility:

$: git clone https://github.com/koliqi/imx23-olinuxino

Switch into directory kernel and download kernel sources:

$: cd imx23-olinuxino/kernel
$: wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.7.1.tar.bz2
$: tar xvjf linux-3.7.1.tar.bz2
$: mv linux-3.7.1 linux-stable

Switch into directory linux-stable and apply patches:

$: cd linux-stable
$: patch -p1 < ../0001-MXS-imx23-olinuxino-Add-i2c-support.patch
$: patch -p1 < ../0001-ARM-imx23-olinuxino-Add-spi-support.patch
$: patch -p1 < ../0001-rtl8192cu.patch

Configure kernel:

$: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- mxs_defconfig
$: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig

Select Boot options —> and select following options:

Linux Kernel 3.7.1: configuring Boot Options

To enable driver rtl8188cu first enable Multi-purpose USB Networking Framework:

Linux Kernel 3.7.1: enabling multi-purpose USB networking framework

Then activate IEEE 802.11 networking stack:

Linux Kernel 3.7.1: activating IEEE 802.11 networking stack

And activate Realtek 8192C USB WiFi and IEEE 802.11 for Host AP:

Linux Kernel 3.7.1: activating Realtek 8192C USB WiFi and IEEE 802.11 for host AP

Power LED need to have default ON trigger activated on kernel:

Linux Kernel 3.7.1: enabling LED default on trigger

Activate other drivers as needed. Save and exit from menuconfig application.

Compile kernel:

$: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage modules

*NOTE that in our environment the kernel compilation failed due to the following reasons:

  • An exception Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at kernel/timeconst.pl line 373' generated by Perl compiler. It turned out that defined has been deprecated in newer versions of Perl (newer versions of Perl) and we had to remove it from the code;
  • By default in our environment a version 5.0 of the arm-linux-gnueabi-gcc was installed which had some incompatibilities introduced since version 4.7 and only that earlier version was capable of compiling the old code. There is a method of having multiple revisions of the compiler installed on the system, the explanation on how to do it could be found here. In our case, we ended up using version 4.7.4.

When compilation successfully finishes, it is ready at arch/arm/boot/zImage
Create device tree blob .dtb file:

$: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- imx23-olinuxino.dtb

Join zImage and imx23-olinuxino.dtb into a new file zImage_dtb:

$: cat arch/arm/boot/zImage arch/arm/boot/imx23-olinuxino.dtb > arch/arm/boot/zImage_dtb

If you want to repeat this procedure, start with clean-up:

$: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- distclean
$: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- clean

The iMX23 SoC contains a built-in ROM firmware capable of loading and executing binary images in special format from different locations including MMC/SD card and NAND flash. Binary image is called a boot stream (.bs). Boot stream consists of a series of smaller bootable images (bootlets) such clock bootlet, power bootlet etc. Linking bootlets with kernel and converting from elf format to raw boot stream is done with utility elftobs. In this package, utility elftobs2 is located in directory elftosb-0.3. Switch into directory elftosb-0.3 and make symbolic link into compilers default PATH:

$: sudo ln -s `pwd`/elftosb2 /usr/sbin/

Check with locate:

$: locate elftosb2

elftosb2 should be located at /usr/sbin/elftosb2. Next, switch into directory boot and untar archive imx-bootlets-src-10.05.02.tar.gz:

$: tar xvzf imx-bootlets-src-10.05.02.tar.gz

Then switch into directory imx-bootlets-src-10.05.02 and apply patches:

$: patch -p1 < ../imx23_olinuxino_bootlets.patch

This patched package require zImage in this directory. We have created zImage_dtb instead, so make symbolic link as:

$: ln -s ../../kernel/linux-stable/arch/arm/boot/zImage_dtb ./zImage

Make boot stream file:

$: make CROSS_COMPILE=arm-linux-gnueabi- clean
$: make CROSS_COMPILE=arm-linux-gnueabi-

Final response would be:

To install bootstream onto SD/MMC card, type: sudo dd if=sd_mmc_bootstream.raw of=/dev/sdXY where X is the correct letter for your sd or mmc device (to check, do a ls /dev/sd*) and Y is the partition number for the bootstream

The bootloader is ready and it is written as sd_mmc_bootstream.raw

Making bootable SD card

Insert your SD card into a card reader of your Linux machine and list partition tables for all disks:

$: sudo fdisk -l

Identify your SD disk. In this example SD disk is recognized as /dev/sdb. Unmount all mounted partitions, i.e. sudo umount /dev/sdb2. Run fdisk:

$: sudo fdisk /dev/sdb

  • Press 'p' to show the partitions on the card
  • Press 'd' to delete a partition. Repeat to remove all partitions
  • Press 'n' to create a new partition
    • press 'p' to select the primary partition
    • press '1' for creating partition 1 on the card
    • press Enter to start from first block
    • Type '+16MB' to create the 16MB partitions
  • Press 't' to change the newly created partition type
    • Enter '53' for the new partition type
  • Press 'n' to create a second partition
    • Press Enter to accept all default setting
  • Press 'w' to write the partitions to the card and exit the fdisk

In this example SD disk is recognized as /dev/sdb. Format the second partition on the SD card:

$: sudo mkfs.ext3 /dev/sdb2

Make mount point directory /mnt/mmc

$: sudo mkdir /mnt/mmc

Mount the partition /dev/sdb2 on mount point directory /mnt/mmc:

$: sudo mount /dev/sdb2 /mnt/mmc

Download and extract the root filesystem (as root, not via sudo):

wget http://os.archlinuxarm.org/os/ArchLinuxARM-armv5-latest.tar.gz
bsdtar -xpf ArchLinuxARM-armv5-latest.tar.gz -C mnt
umount mnt
sync

Install the bootloader which we already created to the first partition (in our system sd device is /dev/sdb1):

$: sudo dd if=sd_mmc_bootstream.raw of=/dev/sdb1
$: sudo sync

The card is ready.

Boot mode and serial output

The iMX233 SoC has multiple boot sources such as USB, I2C, SPI, JTAG, SD/MMC card and so on. In order to make it boot from our SD card we had to specifically instruct it to do so. There are two ways of doing this, either by setting up jumpers or programming OTP bits. Each approach has its own pros and cons. Jumpers are easy to use and they allow multiple reconfigurations, however, they reduce the amount of available GPIO lines. The OPT bits can be programmed only once and in case of misconfiguration the board in essence becomes a piece of junk. There is also a need to a USB A-A cable and special piece of software called ‘BitBurner’ which runs on… Windows only! The software is available here. Initially we chose to use the jumpers but it turned out that under certain circumstances they don’t work. There were many people complaining in the Internet about the same issue without any working solution so we decided to switch to OTP. We downloaded the BitBurner, extracted the executable, run it, connected the board to our PC running Windows and applied power to the board. Then with the help of BitBurner we blew SD MBR Boot[3] to ‘1’ and SD_POWER_GATE_GPIO[21:20] to ’10-PWM3′ as it was advised in OlinuXino Micro User’s Manual.

In order to see console output there is a need for an external USB-To-Serial adaptor. There are many different types of them nowdays and it doesn’t really matter which one to use. There are two things to keep in mind though: an adapter must have 3.3V outputs as Olinuxino’s GPOIs are not 5V tolerant. Also, the second thing to consider for the adapter is its ability to work under Linux as there are a lot of activities which need to be done in that operating system and it simply becomes impractical to switch constantly Windows and Linux. As for us, we didn’t have one and we rushed to Jaycar to buy this Arduino compatible USB to serial adaptor module. It had a 3.3/5V switch and worked under Linux without issues, however, looked like that it was overpriced. We made sure to switch it to 3.3V mode, connected its GND, TXD and RXD with appropriate pins of OlunuXino’s U-DEBUG connector and… at that stage we were ready for our first Linux boot.

Booting up Linux

Everything seemed to be ready for the first experiment with the Linux bootup. MicroSD card was prepared and inserted into OlinuXino’s socket, OTP bits were programmed, USB-to-serial adapter was connected to the board and hooked up to a PC, terminal application was configured to read data at 115200bps, we set up our bench power supply to 5V and limited current by 500mA. Then double checked everything and at last dared to apply the power. And this was what we saw in the console:

HTLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLFC
PowerPrep start initialize power...
Battery Voltage = 0.00V
No battery or bad battery detected!!!.Disabling battery voltage measurements.
LLCJan 4 201321:57:25
EMI_CTRL 0x1C084040
FRAC 0x92926192
init_ddr_mt46v32m16_133Mhz
power 0x00820710
Frac 0x92926192
start change cpu freq
hbus 0x00000003
cpu 0x00010001
LLLLLLLFCLJ
Undefined Instruction

Let’s analyse what happened. The booting process obviously failed shortly after it started. The failure was ‘Undefined instruction’ which could be caused by an image incorrectly built or due to some hardware issue. But from the log it became obvious that a CPU was properly clocked and able to fetch and execute instructions. It also was able to boot from the SD card which meant that OTP bits were programmed correctly. It also detected DDR and tried to ramp up its clocking frequency before failing to continue.

Our first impression was that we build the kernel using incorrect target CPU. But then we prepared SD card with already precompiled U-boot described here and got exactly the same result. The suspicion fell on the hardware. We needed to test our RAM somehow. Looking at the source code of the bootlets we found that a memory test was simply disabled in imx-bootlets-src-10.05.02\boot_prep\init-mx23.c :

#if 0
	/*Test Memory;*/
	printf("start test memory accress");
	for (i = 0; i < 100; i++)
		*pTest++ = i;

	pTest = (volatile int *)0x40000000;

	for (i = 0; i < 100; i++) {
		if (*pTest != (i)) {
			printf("0x%x error value 0x%x\r\n", i, *pTest);
		}
		pTest++;
	}
#endif

So the next step was to enable the memory test, recompile the kernel, re-build the SD-card and try to boot from it again. The results were blankly pointing at issues with the memory:

...
start test memory accress0x00000000 error value 0x00000009
0x00000001 error value 0x00000009
0x00000002 error value 0x00000009
0x00000003 error value 0x00000009
0x00000004 error value 0x00000009
0x00000005 error value 0x00000009
0x00000006 error value 0x00000009
0x00000007 error value 0x00000009
0x00000008 error value 0x00000009
0x0000000A error value 0x00000009
0x0000000B error value 0x00000009
0x0000000C error value 0x0000000D
0x0000000E error value 0x0000000D
0x0000000F error value 0x0000000D
0x00000010 error value 0x00000019
0x00000011 error value 0x00000019
0x00000012 error value 0x00000019
0x00000013 error value 0x00000019
...

It looked really bad. It simply suggested that three if not four bits on data didn’t work. We were prepared for some bad soldering issues but four bits sounded devastating. The result was always the same, no matter how many times we run the test so it didn’t look like faulty memory, it rather looked like soldering issues (either broken or soldered together traces). We studied to PCB layout and couldn’t really figure out what should go wrong in order to get such an effect. It simply didn’t look like any adjacent traces accidentally joined. Then we changed the test. We only send to the console ten consecutive values ten times, after every simple writing operation to the memory. And it turned out that a write to a single address caused values at more than one address to change. From that point it also suggested that there were issues with address bus too.

Then we simplified the test even more. We wrote only one value 0x12345678 at address 0x0 and then read values from 0x0...0x9. The result was as follows:

0x12345678 
0x12345678 
0xE1A03081 
0xE1A03081 
0x12345678 
0x12345678 
0xE1A03081 
0xE1A03081 
0x12345678 
0x12345678

It looked like non-working address lines A0, A2, A3 at least. It was simply too much. We found a good binocular microscope and started peering into the board. To our shock, we saw multiple islands of soldering paste behind the pins. Those paddles of unmelted balls of solder were shorting the pins and the worst part was that washing the board couldn’t help with removal of the paste. But finally we found a solution – a paintbrush with small but stiff bristles which could penetrate behind the pins. With help of a paintbrush we could improve the situation to such an extent when the soldering balls couldn’t create shorts anymore but still couldn’t completely get rid of them. And finally, the microscope revealed one bad soldering case of a DDR pin on the address bus. After fixing the issues the memory test passed.

Finally this is what we got on the serial console:

Downloads:

1.iMX233-OLinuXino-Micro (Rev.D) iTead friendly Gerber files
2.iMX233-OLinuXino-Micro (Rev.D) iTead friendly Eagle files
3.iMX233-OLinuXino-Micro (Rev.D) iTead friendly PCBA 3D model
4.iMX233-OLinuXino-Micro (Rev.D) iTead friendly component 3D models
5.iMX233-OLinuXino-Micro (Rev.D.01) iTead friendly Bill of materials

References:

1.Henrik’s blog: making embedded Linux computer
2.Official Olinuxino Micro manufacturer’s page
3.Single board PC based on iMX233
4.Soldering a fine-pitch QFP
5.Kernel 3.7.1 for the OlinuXino
6.OlinuXino on archlinuxarm.org
7.Getting Started with the Olimex A13-OLinuXino-MICRO
8.Разработка одноплатного компьютера с нуля. Пособие для начинающих
9.BitBurner v1.0.4.6
10.OlinuXino Micro User’s manual
11.Freescale I.MX233 Embedded Linux System
12.Yocto Project
13.Rascal Micro Project

The conclusion

It has been proven that it is eminently possible to built a two layer board capable of running Linux in home environment without expensive equipment and for a price affordable to an ordinary hobbist.

Lumunardo in White Case and Blue Screen

Introducing a more stylish look of the enclosure made of white PLA material and translucent blue front and rear panels. It is very hard to find acrylic material other than transparent white with 2mm thickness so we had to modify the top and bottom shells to be able to fit 3mm thick panels.

Luminardo White Case Blue Screen

The introductory video demonstrates virtual assembling, Luminardo’s interfaces and features and then shows the process of initial set up:

Downloads:

1. Luminardo Alarm Clock Sketch (English messages), Rev.1.2 from 2016.11.07

2. Luminardo Case Top Shell 3D Model (for 3mm Acryl, 2mm extension for shrinkage compensation)

3. Luminardo Case Bottom Shell 3D Model (for 3mm Acryl)

MVFD Panel and Regular Arduino

Today we are publishing photos of fully assembled and tested MVFD 16S8D Panel, Rev 2.0. The board on the pictures is fully populated with components which means that apart from displaying alphanumeric information it can measure ambient light intensity, emit simple ‘beep’, receive signals from an IR remote control and shine with an RGB LED. As it is seen, the majority of components are located on the back side of the board so the top side looks really simplistic. It is worth mentioning that due to the use of through hole components and the fact that components are loaded on both sides the VFD glass should be soldered last during assembling process otherwise it would block access to some through hole pins.

MVFD 16S8D Panel PCBA Front Rev. 2.0

MVFD 16S8D Panel PCBA Front Rev. 2.0

MVFD 16S8D Panel PCBA Back Rev. 2.0

MVFD 16S8D Panel PCBA Back Rev. 2.0

The VFD Panel perfectly mates with either Luminardo board or MVFD Serial Backpack. However, it is also possible to drive it using basic Arduino such as Arduino Duemilanove which has not so many GPIO pin and equipped with only 32K of program memory. If needed, the number of wires can be reduced by eliminating features which are not used – for example, RGB LED, ambient light sensor, IR receiver or speaker.

MVFD Panel and Arduino Duemilanove pin mapping
Designation VFD Panel JP1 pin Arduino pin num/pin type
IR RECEIVER 1 2/digital
+5VDC 2 5V/PWR
SPEAKER 3 9/digital
GND 4 GND/PWR
DO 5 11/digital
BLUE LED 6 3/digital
DI 7 10/digital
GREEN LED 8 6/digital
CLOCK 9 8/digital
RED LED 10 5/digital
CHIP SELECT 11 7/digital
LIGHT SENSOR 12 0/analog
SHUTDOWN 14 4/digital

Driving VFD Panel is extremely simple as all heavy lifting is done by MVFD library. All that a developer needs to do is to physically wire the panel to Arduino board (of course), define VFD pins (an example is provided below) and initialise display. From that point controlling the panel becomes as easy as writing to a serial port.

#ifndef Board_h
#define Board_h

#define VFD_SPRK_PIN    	9
#define VFD_CS_PIN   		7
#define VFD_SCLK_PIN 		8
#define VFD_DATAI_PIN 		10
#define VFD_DATAO_PIN 		11
#define VFD_SHDN_PIN    	4
#define VFD_R_PIN       	5
#define VFD_G_PIN       	6 	
#define VFD_B_PIN       	3
#define VFD_LIGHT_SNR_PIN	0
#define VFD_IR_REC_PIN		2

#endif

The library contains a fair amount of embedded tests and demo effects so the first sketch showing the panel’s capabilities would be also simple (see below). The sketch makes use of a buzzer (you should hear a short ‘beep’ upon Arduino’s start), of an ambient light sensor (there is a demonstration of ‘day’ and ‘night’ modes), of the RGB LED (it pulsates during normal operation and flashes upon bootup and when an IR command is received and encoding standard is recognised). During the test the display demonstrates alphanumeric information, brightness control, flashing (blinking) effect and effect of scrolling line.

#include <util/delay.h>
#include <MVFDPanel_16S8D.h>
#include <IRremote.h>
#include <IRremoteInt.h>

#include "Board.h"

#define MAIN_LOOP_DELAY 150

uint8_t sysState;
uint8_t last_sysState;
uint8_t waitCntr;
uint8_t redValue;
uint8_t greenValue;
uint8_t blueValue;
IRrecv irrecv(VFD_IR_REC_PIN);
decode_results results;

enum enum_SysState
{
    sysSelfTest,
    sysDispScroll,
    sysDispWait,
    sysDispParams,
};

MVFD_16S8D vfd(VFD_CS_PIN, VFD_SCLK_PIN, VFD_DATAI_PIN, VFD_SHDN_PIN);    //VFD display

const char SCROLLING_DEMO[] PROGMEM = "        SCROLLING DEMO";

void setup()
{
    Serial.begin(57600);  
  
    vfd.initLED(VFD_R_PIN, VFD_G_PIN, VFD_B_PIN);
    vfd.initLightSensor(VFD_LIGHT_SNR_PIN);

    irrecv.enableIRIn();
  
    vfd.standby(false);

    redValue = 0;
    greenValue = 0;
    blueValue = 0;

    vfd.setLED(redValue, greenValue, blueValue);
  
    pinMode(VFD_DATAO_PIN, INPUT);
    vfd.reset();

    tone(VFD_SPRK_PIN, 2048, 500);
  
    vfd.setB_LED(255);  
    _delay_ms(100);
    vfd.setB_LED(0);    
    _delay_ms(100);
  
    vfd.setB_LED(255);  
    _delay_ms(100);
    vfd.setB_LED(0);    
    _delay_ms(500);

    vfd.setR_LED(255);    
    _delay_ms(100);
    vfd.setR_LED(0);      
    _delay_ms(100);
  
    vfd.setG_LED(255);      
    _delay_ms(100);
    vfd.setG_LED(0);
  
    sysState = sysSelfTest;
}

void vfd_print_f(char* str, uint8_t idx)
{
  char c;
  if(!str) return;
  while (c = str[0])
  {
    vfd.write_f_char(c, idx, false);
    idx += VFD_BYTES_PER_DIGIT;
    str++;
  }
}

void updateLEDs()
{
    blueValue++;
    if (blueValue > 60)
    {
      blueValue = 0;  
    }
    if (blueValue < 30)
    {
      vfd.setLED(blueValue/1.17, blueValue/8.6, blueValue);
    }else
    {
      uint8_t newVal = (30 - (blueValue - 30));
      vfd.setLED(newVal/1.17, newVal/8.6, newVal);
    }
}

void loop()
{  
    uint16_t lightSen = 300;
    uint8_t lightConditions = true;
    uint8_t loopCntr = MAIN_LOOP_DELAY / 10;
    char num_buf[8];
    
    while (1)
    {
        loopCntr++;
        updateLEDs();
        
        if (loopCntr >= 10)
        {
            loopCntr = 0;
            
            switch (sysState)
            {
                case sysSelfTest:
                    {
                        if (vfd.testStep() == vfd.COMPLETED)
                        {
                            sysState = sysDispScroll;
                            redValue = 0;
                            greenValue = 1;
                            vfd.initScroll_p(SCROLLING_DEMO);
                        }
                        break;
                    }

                case sysDispWait:
                    {
                        waitCntr--;
                        if (waitCntr == 0)
                          sysState = last_sysState;
                        break;
                    }

                case sysDispScroll:
                    {
                        if (!vfd.scrollStep())
                        {
                          sysState = sysDispParams;
                        }

                        break;
                    }
                    
                case sysDispParams:
                    {
                        vfd.setCur(0);
                        
                        if (lightConditions)
                          vfd.print_f_p((const char*)F("DAY "));
                        else
                          vfd.print_f_p((const char*)F("NGHT "));

                        lightSen = vfd.getLightSensorVal();
                        itoa(lightSen, num_buf, 10);

                        vfd_print_f((char*)&num_buf, 5 * VFD_BYTES_PER_DIGIT);
                        
                        vfd.flipFrame();

                        break;
                    }
                default:
                    ;       
            }
            
            //Handling RC commands
            decode_results rc_code;
            if (irrecv.decode(&rc_code))
            {
                vfd.setLED(redValue, greenValue, 255);

                vfd.setCur(0);
                if (rc_code.decode_type == NEC)
                {
                    vfd.print(F("NEC  "));
                }else if  (rc_code.decode_type == SONY)
                {
                    vfd.print(F("SONY "));
                }else if (rc_code.decode_type == RC5)
                {
                    vfd.print(F("RC5  "));
                }else if (rc_code.decode_type == RC6)
                {
                    vfd.print(F("RC6  "));
                }else 
                    vfd.print(F("UNKN "));

                vfd.print((int)rc_code.value, DEC);

                irrecv.resume();

                if (sysState != sysDispWait)
                  last_sysState = sysState;
                sysState = sysDispWait;
                waitCntr = 10;
            }
            
            if (lightSen < 200) 
            {
                //Dark conditions
                if (lightConditions == true)
                {
                    Serial.println(F("Night mode"));
                    vfd.displayOnCmd(2);
                    lightConditions = false;
                }

            }else if (lightSen > 300)
            {
                //Light conditions
                if (lightConditions == false)
                {
                    Serial.println(F("Day mode"));
                    vfd.displayOnCmd(7);
                    lightConditions = true;
                }
            }
        }
        _delay_ms(MAIN_LOOP_DELAY / 10);
    }
}

The picture of the working setup is provided below:

Arduino and MVFD 16S8D Panel in Action

The full test video showing the sketch and the panel in action is given below. In minimalistic configuration (only VFD glass is functional) only 6 wires would be needed (+5VDC, GND, DI, CLOCK, CHIP_SELECT, SHUTDOWN) so some Arduino’s GPIO pins could be freed up.

Firmware:

1. MVFD Panel Demo Sketchup

2. MVFD 16S8D Panel Lib

3. IR Lib

Hardware:

1. Magictale VFD 16S8D Panel Gerber files Rev2.0

2. Magictale VFD 16S8D Panel Eagle files Rev2.0

3. Magictale VFD 16S8D Panel PCBA SketchUp 3D Model Rev2.0

4. Magictale VFD 16S8D Panel Component 3D Models Rev2.0

5. Magictale VFD 16S8D Panel BOM (Bill Of Materials) Rev2.0

Project Description:

1. VFD Panel 16S8D, Rev 2.0 – Hardware Description

Luminardo: Fabrication and Assembling

Before STL models can be sent to a 3D printer they need to be converted into format recognized by a specific make and model of a printer. This job is usually done by software distributed with a printer. Besides, additional manipulations need to be done: the model must be properly positioned at the very centre of printer’s platform, a raft and supports for some elements of the model must be generated (most of the times they can be autogenerated by the printer’s software), material type, preferable extruder (in case of more than one available), quality and additional 3D printing parameters must be set.

In our case we used FlashForge Creator Pro which has its own tricks to achieve best possible quality. First of all, we came up to understanding that our model should be positioned on its side, sitting on its rear end which contacts with the rear acrylic panel. That way all imperfections caused by the supports will be on the rear side. The model should be oriented as if rotated 90 degrees (as shown on the picture below). That way the left nozzle won’t occasionally interfere with the deposited plastic threads as in happened few times during one of our earlier experiment. It is strongly recommended not to use the second extruder for raft and supports as two plastics simply penetrate into each other during the process and sometimes it just looks ugly.

Luminardo Bottom Shell Ready for 3D Print

Luminardo Bottom Shell Ready for 3D Print

Both top and bottom shells just off the printer are shown below. Although these two are made of ABS we strongly recommend to use PLA as it shrinks less so there will be less unpleasant surprises after the print. Supporting structures and rafts are not removed yet. The bottom shell already has M3 standoffs screwed in.

Luminardo Green Case After 3D Printing

Luminardo Green Case After 3D Printing

The fully assembled device is given below.

Luminardo Green Case Rear View

Luminardo Green Case Rear View

Luminardo’s front view can be seen on the picture below. The device is flashed with an Alarm Clock sketch.

Luminardo Green Case In Action

Luminardo Green Case In Action

Downloads:

1. Luminardo Alarm Clock Sketch (German messages), Rev.1.2 from 2016.11.07

2. MVFD Panel 16S8D Lib Snapshot from 2016.11.07

3. Luminardo Arduino IDE core Lib Snapshot from 2016.11.07

Stay tuned, more details are yet to come…

Luminardo: Designing Enclosure

The idea of making enclosure fully out of acrylic panels was abandoned due to ‘squarish’ look of the final product. We really wanted to create something a little bit more stylish and this is why the most obvious choice was 3D printing. That way it was possible to make rounded corners and streamline shape. However, with 3D printing it is almost impossible to get a transparent or at least translucent surface which was required at least for the front panel. So in the end a decision was made to have a mix of acrylic flat panels and 3D printed elements of enclosure. By doing this we could reduce the volume of 3D printed parts which are more expensive to make than acrylic laser cutting. We could also make front and rear panels transparent allowing clearly see not only VFD display but the electronics as well. And still it was feasible to give the case a modern look, thanks to the 3D printing technology which gives designer’s fantasy literally unlimited freedom. The sketch below demonstrates main features of the future case: flat rear and front acrylic panels held together by top and bottom curved halves, the top half has a cowl around the motion sensor.

Luminardo Sketch

Luminardo Sketch

The final design is done in Sketchup with free licence without need to manipulate with solid objects but it made designing effort a bit challenging and more time consuming. Both front and rear panels are made of a clear 2mm thick acrylic blank, in Ponoko the most appropriate blank was P1 (181 x 181 mm), however, it was still too big for us so we managed to fit panels for three Luminardo cases. The font panel has holes for a buzzer and RGB LED. The rear panel has cutouts for ISP, two serial and one I2C headers, a USB Type A Female and a USB mini connectors, a cutout for a temperature sensor and for a 1-Wire header.

Front and Rear Panels prepared for laser cutting in Ponoko

Front and Rear Panels prepared for laser cutting in Ponoko

The top and bottom shells are 3D printed. Both of them have internal supports for the acrylic panels and the board assembly. The shells are held together by two M3 standoffs and two M3 screws. The top shell has a niche for the motion sensor and a hole for accessing RESET button. The model of the top shell is given below.

The bottom shell has two feet beneath and two holes for M3 screws. The model of the bottom shell is given below.

When 3D design is done the next step would be to export it to STL format before sending to a 3D printer. If the model was not designed as a solid object (this is actually our case) then be prepared that first STL model most probably contains some errors. To analyse and pinpoint such problems there are countless number of software tools. We used Meshmixer and Netfabb. Netfabb turned out to be more advanced, it could still detect some issues when Meshmixer didn’t complain about anything anymore but we still couldn’t pass through Ponoko’s validator. The problem was with one face being ‘degenerated’ and despite all our effort we could not find any issue. So eventually we simply allowed Netfabb to autorepair it and when it was done we were able to upload our model to Ponoko. Two pictures below show a model at fault and its degenerated face detected by Netfabb.

Luminardo Top Shell in Netfabb

Luminardo Top Shell in Netfabb

Luminardo Top Shell - Degenerated Face

Luminardo Top Shell – Degenerated Face

The final assembly is given below.

After several experiments we came to a decision that it is much better to 3D print both shells using PLA material. It has significantly less shrinkage comparing to ABS, it is still strong enough and can be safely used indoors without risk of degrading (in spite of opinions widespread in the Internet).

A virtual assembling video is provided below:

Downloads:

1. Luminardo 2.0 Fully Assembled (PCBAs and Enclosure) 3D Model

2. Luminardo Case Top Shell 3D Model

3. Luminardo Case Bottom Shell 3D Model

Links:

1. Luminardo Front and Rear Acrylic panels on Ponoko

2. Luminardo Case Topshell on Ponoko

3. Luminardo Case Bottomshell on Ponoko

A Luminardo Board Revamp: Revision 2.1

This is a second spin of Luminardo boards with the focus on elimination minor mistakes found in the revision 1.0. A motion sensor is fully integrated with the PCB this is why the board has an inflow on top of its outline. Also an obsolete inductor is replaced with the one of a similar footprint and bill of materials has been optimised in terms of component cost. But let’s take a step back and answer the question: what Luminardo is, why it was designed and what it can be used for? In short, Luminardo is an Arduino compatible ATMega128 powered board with MVFD panel 16S8D interface, USB Host, battery backed up RTC, motion and temperature sensors. A front panel adds a buzzer, a light sensor, an RGB LED and an IR receiver. It has compact sizes, also it is expandable and stackable like Arduino. But unlike Arduino it grows in length, not in height when extra boards are stacked inbetween the front panel and the main board. The slim form factor makes it look nice and unusual and (hopefully) modern. The first immediate idea would be to use it as typical Nixie clock out of nostalgic reasons only. But it can do more than just that. With replaceable front panels, with its expandability and with USB host functionality the application areas widens significantly. It can be a part of a home automation network, or used to control a toy city. Yet it is simple enough to be built by a DIY enthusiast.

The circuit diagram is given below. Not too many changes if compare with the revision 1.0:

luminardo_rev-2-1_circuitdiagram

The PCB layout component layout is given below. Hardly noticeable changes if not to take into account an integrated motion sensor and a reset switch.

Luminardo Component Layout Rev. 2.1

Luminardo Component Layout Rev. 2.1

The PCB layout is given below. As usual, it utilises 2 layers to take advantage of good PCB manufacturer deals like Itead Studio. The design is also tailored to a specific Itead prototyping offer which is 100x50mm and comes at $25 for 10 color boards without shipment (or even $14.90 for green boards!)

Luminardo PCB Layout Ver.2.1

Luminardo PCB Layout Ver.2.1

The 3D model of the whole assembly is available at 3D Warehouse so it becomes really easy to design extension boards or enclosures.

The top view of the 3D model is given below. In essence, no changes on this side.

Luminardo V 2.1 PCBA 3D Model Top View

Luminardo V 2.1 PCBA 3D Model Top View

The bottom view of the 3D model is given below. Distinctly visible the motion sensor, the reset switch, the electrolytic capacitors and the raised 14-pin VFD header which is a custom made of two stackable Arduino headers.

Luminardo V 2.1 PCBA 3D Model Bottom View

Luminardo V 2.1 PCBA 3D Model Bottom View

The video below shows how Luminardo and MVFD panel integrate together:

Downloads:

1. Luminardo Gerber files Rev 2.1

2. Luminardo Eagle files Rev 2.1

3. Luminardo PCBA SketchUp 3D Model Rev 2.1

4. Luminardo Panel Component 3D Models Rev 2.1

5. Luminardo BOM (Bill Of Materials) Rev 2.1

6. Luminardo and MVFD Panel PCBAs Assembled SketchUp 3D Model

Order from OSH Park

A 16S8D VFD Panel Revamp: Revision 2.0

This is a deep redesign of MVFD 16S8D Panel Rev.1.0 project which fixes minor and major issues and finally solves the fundamental problem of some parts becoming obsolete. Let’s reiterate the reasons which were the main driving forces of the project to come into existence:

– Single power source (+5V) which makes it possible to drive the panel from a USB port or batteries, high and filament voltages are generated internally;
– No need in transformer which is usually a non-off-the-shelf part resulting in cheaper, lightweight and compact solution;
– Pulse filament drive is used, an equivalent of AC (as opposed to DC) eliminating brightness gradient across the length of the VFD glass;
– Popular, inexpensive and widely available chips are used to generate filament and high voltages, very low risk of them becoming obsolete;
– Feedback in high voltage generator circuitry helps to achieve constant brightness regardless of number segments and digits lit up;
– Adjustable high voltage to get highest brightness without reducing VFD lifetime;
– Adjustable DC offset for filament voltage to maximise VFD brightness and cut off ghosting effect;
– An inexpensive and popular VFD driver is used which is produced by several silicone manufactures under different names but in the same package with pin-to-pin compatibility also reducing the risk of the part becoming obsolete;
– Low power mode;
– An infra red (IR) receiver;
– A buzzer;
– An RGB LED;
– A photocell (light sensor);
– A dedicated VFD driver is controlled by SPI-like two wire iterface taking care of display refresh and offloading main CPU (even Arduino Uno can cope with the job);
– Most parts are through hole making it very easy to assemble even by DIY enthusiasts with average soldering skills;

The circuit diagram is given below. This is in essence integration of Revisited VFD PSU and MVFD 16S8D Panel Rev.1.0

MVFD 16D7D Panel Rev.2.0 Circuit Diagram

MVFD 16D7D Panel Rev.2.0 Circuit Diagram

The top and bottom component layout is given below. No dramatic changes in comparison with Rev.1.0, same PCB dimensions, same mounting hole locations, same locations for parts on the top side to maintain compatibility with the previous design. On the bottom side the bulky parts representing the PSU are grouped together allowing to free up space for mating with MVFD Serial Backpack.

MVFD 16S8D Panel Component Layout_Rev

MVFD 16S8D Panel Component Layout_Rev

The PCB layout is given below. It utilises 2 layers to take advantage of good PCB manufacturer deals like Itead Studio. The design is also tailored to a specific Itead prototyping offer which is 100x50mm and comes at $25 for 10 color boards without shipment (or even $14.90 for green boards!)

MVFD 16S8D Panel PCB Layout Ver.2.0

MVFD 16S8D Panel PCB Layout Ver.2.0

The 3D model of the whole assembly is available at 3D Warehouse so it becomes really easy to design additional peripheral to mate with the panel, to get a good understanding how the panel looks like or even make use of the 3D models of the parts for some other projects.

Once again, no facelifting on the top side, it looks pretty much the same way as Rev.1.0 looked:

MVFD Panel 16S8D V2 PCBA 3DModel Top View

MVFD Panel 16S8D V2 PCBA 3DModel Top View

The bottom side looks significantly different now mostly due to totally new design of PSU. Note, that in order to minimise dimensions, the inductor is placed horizontally but nothing prevents it from mounting vertically, it is just a matter of personal taste and size restrictions.

MVFD Panel 16S8D V2 PCBA 3D Model Bottom View

MVFD Panel 16S8D V2 PCBA 3D Model Bottom View

The video below shows how the panel integrates with previously designed MVFD Serial Backpack:

Downloads:

1. Magictale VFD 16S8D Panel Gerber files Rev2.0

2. Magictale VFD 16S8D Panel Eagle files Rev2.0

3. Magictale VFD 16S8D Panel PCBA SketchUp 3D Model Rev2.0

4. Magictale VFD 16S8D Panel Component 3D Models Rev2.0

5. Magictale VFD 16S8D Panel BOM (Bill Of Materials) Rev2.0

Order from OSH Park

Automated LED Color Recognition

The problem of automated LED color detection seems relatively easy to solve. However, the devil is in details and when it comes to practice, there is always something which goes not as expected and our practical implementation was not an exception as we encountered multiple challenges. Nevertheless, there are some ways to overcome those challenges. The task was simple to formulate: implement a reliably functioning way of automated LED color recognition for PCBAs coming off a production line. Each PCBA had a three RGB LEDs and there was a requirement to check every basic color and make sure that those colors could be controlled individually, i.e., there was no shorts. Our first approach was to take a generic Web camera and by switching LED colors sequentially take three shapshots for red, green and blue colors, then apply a blob recognizing algorithm to count points of light and detect color for each point. As a result of first experiment, a few issues arised. First of all, bright LEDs very saturating the picture and always looked like a glowing white halo with either red, blue or green rim around it making it impossible to do blob and color detection. Secondly, the background acted like noise so it had to be at least reduced if not cancelled. And thirdly, the same setup keept giving very different pictures which depended on ambient lighting conditions. A typical picture taken with a generil web camera is given below:

LED Snapshot In Focus

LED Snapshot In Focus

We began experimenting with different Web cameras and soon established that much better results are subject to deliberate camera defocus. The most dramatic effect is given on the picture below, it is seen when a camera is defocused the LEDs are turning into nice round blobs evenly painted with monotonous color. Then is becomes possible to do blob recognition and count and detect color of each blob. The only problem is a distance between camera and LEDs under test – in oder for a camera to be able to defocus more, the longer focal length that camera must have and the greater distance between LEDs and camera must be to fit all theree LEDs in narrow camera’s angle of view. The best results with point of light defocusing we got with an USB microscope but it required at least 300 mm between LEDs and the camera which was simply impractical.

LED Snapshot With Camera Defocused

LED Snapshot With Camera Defocused

Continuing our search for an optimal camera we finally found LI-OV5640-USB-72 – a 5M USB camera with manual focus. The only modification that we needed to do was removal of two white illuminating LEDs:

LI-OV5640-USB-72 USB Camera

LI-OV5640-USB-72 USB Camera

The camera didn’t have to be placed far away from the PCBA under test and at the same time it gave satisfactory results in terms of even color distribution accross the blobs while having blob borders sharp enough for reliable work of blob detection algorithm. In addition to ability to adjust brightness and saturation the camera also allowed for gain control and by finding optimal values for those three parameters and by adding a couple of layers of gray film in front of the camera lenses it also became possible to cancel the background altogether signigicanly simplyfing further image processing process. With the final tuning the camera generates pictures with the following quality which is really easy to postprocess:

LED Snapshot Camera's Final Tuning

LED Snapshot Camera’s Final Tuning – green and red colors

LED Snapshot Camera's Final Tuning - blue color

LED Snapshot Camera’s Final Tuning – blue color