Friday, March 20, 2015

DirtyPCBs two layer ENIG PCB closeups

The standard service is $14 for 10 boards. You can have the pads ENIG finished for $15 more, which brings the total cost to $29 for 10 boards, shipped. It is still an excellent deal. The quality is excellent too, as the closeups below illustrate.

Fig 1: The pads for this 0.5mm pitch QFN were solder mask defined in the design. 

Fig 2: Actual solder mask on the PCB. They expanded the clearance here by quite a bit, but this is perfectly reasonable. 

Fig 3: Tigher clearances here on this side.

Fig 4: 0.1 inch header - Drilled holes alignment are quite good. 

Fig 5: 1mm pitch Flat-flex connector pads. 

Fig 6: Pads for 0603s. To the right is a 2mm pitch, two-pin header. 

Sunday, October 12, 2014

HDMI input shield for the olimex lime

Update: Check out the awesome work of the Videobrick team. They have developed an HDMI input shield for the olimex lime complete with software support based on the ADV7611!

The Allwinner A20 and A10 chips have a 165Mhz 24-bit parallel video input interface. What that implies is that we can theoretically feed a full HD video stream to the IPU of the SoC, encode it to h.264 and livestream it.

Proto Rev 1.0

Proto Rev 2.0

A few months ago, I designed an HDMI imput shield for the Olimex-Lime development board which essentially converts the HDMI's TMDS to a 24-bit parallel feed.  The board uses TI's TFP401 to do the conversion. 

The schematics are available at my github:

The boards has a few minor mistakes so don't build this version just yet. 
The software side is currently under development. I will release everything as soon as it is completed. 

Stay tuned,


Saturday, April 20, 2013

Enabling hardware h264 encoding with gstreamer on the Raspberry Pi

This should be helpful for those trying to use the hardware h264 encoder inside the BCM2835.

The repo already contains precompiled binaries for the raspberry pi, so this will be much faster than building gst-omx from source. We should thank [Defiant] for this.


You can now enjoy your well deserved omxh264enc video sink.

Wednesday, January 2, 2013

Solar powered, Wireless autonomous radiation sensor network

24/09/14: A 'single chip' version of this project, based on TI's CC3200 is currently under development. Stay tuned.

I designed a system a few months ago that had the aim to track the amount of radiation of my backyard over a period of time. I figured that the least cumbersome way to keep track of the count-rate was to make the radiation sensor post the data directly to the internet, via cosm Xively. Cosm Xively is basically an 'internet-of-things' platform where devices can freely post, access and share data points.

This project can be particularly interesting for those who, like me, want to keep track of the relative radiation rates for some reason. (This is not a radiation dosimeter, hence the 'relative count rate')

I found it worthy to share this design because:
  1. It is solar powered, and (energetically) fully self sufficient.
  2. It connects to the internet via Wi-fi, so no messy ethernet cables trailing across the backyard. (Assuming, of course, it is within range of your wifi router.) 
  3. It is fully weather-resistant due to the IP-66 rated casing and connection terminals.
  4. Data-collection is automatic and cosm provides various interesting ways to share the collected data points(twitter, custom API, etc...)
  5. It is a very low cost system for what it does. B.o.M is under $100. 

Hardware overview

Component list:

First some pictures for a general overview of how one node is assembled.

Holes for two watertight cable pass-throughs

Adafruit's solar charger board. A bit overpriced in my opinion, but works very well. 

Roving Networks RN-XV WiFly 'wonder' Module

The RP-SMA connector was sealed with silicone glue after the antenna was  screwed-in

Arduino+WiFly+Solar Power Subsystem minus the Geiger interface

The Geiger Muller Interface + GM Tube attached , as described previously

Cramming everything together produces this. 


I won't be describing how to connect up the power subsection as this is pretty obvious, and is also dependent on what exact components you chose to use.

I will only describe how to connect the WiFly module and the GM tube interface, in the way expected by the Arduino code.

Part I - RN-XV to Arduino

The pin numbering scheme of the RN-XV module is shown above. This project uses only 6 pins from the module and they are connected to the Arduino as described by the table below.

The Arduino code puts the module to sleep by pulling pin 7 to LOW. For the module to obey this, it must be configured so that when it gets a 'LOW' signal on pin 4, it goes to sleep. For instructions on how to configure the module, please consult its instruction manual about 'GPIO8'.

If the WiFi module does not enter sleep mode, the LiPo battery will be eventually drained as the solar panel won't be able to keep up with the load. From my experiments, the system will only last 2-3 days if that happens. 

The Arduino code also wakes up the module by pulling pin4 'High' (pin 16 on the RN-XV) after a certain period has elapsed. No configuration is needed for that as the module automatically wakes up from sleep as its pin 16(UART_CTS) is pulled high.

It is highly recommended that you give it's instruction manual and datasheet a good read before wiring the module up. How this module works is far from obvious, but very interesting nevertheless.

Part II - GM-Interface to Arduino

The GM-interface used is exactly the same as described in this post:

It consumes a few micro-amps when not active and about 10mA when its high-voltage generator(boost converter) is active. By default, it is active for about 30 seconds each 30 minutes so that the overall current draw remains adequate for what a small solar panel can provide.

It has 4 wires to the arduino: Vcc, PWM_IN, Pulse_Out and Ground.

  1. Vcc can be anything less than 6.0V but above 3.0V. (note: The HV is not regulated - just a ballpark value that works.)
  2. The "PWM_IN" of the GM-Interface is connected to Pin 9 of the Arduino Pro Mini. This is for the boost converter section of the interface. The firmware is programmed to send a 1.9KHz PWM signal through Pin 9. 
  3. The "Pulse_Out" of the GM-Interface is connected to Pin 2 of the Arduino Pro Mini. This is for the 'pulse detection' section of the interface. Each time a pulse is detected, it triggers an interrupt on the Arduino for it to register the event as one count. The Arduino accumulates theses counts over a period of time to produce the count per minute value. 

Arduino Sketch

The Arduino sketch can be downloaded here:

You have to change a few things before you upload the sketch to the Arduino Pro Mini.

  • You'll need to hardcode your wifi AP settings inside the "Credentials.h" file. 
  • You'll need to have a cosm account and enter your cosm feed details in the "Credentials.h" file
  • You need to have the WiFly library installed for it to compile. I've made a copy of the original Sparkfun WiFly library to maintain compatibility:

After these, your code should compile and work properly.

The documentation is still very minimal, but this will hopefully change progressively.

Random extra text

My current Cosm feed is currently private, but I will make it public and post it here soon after I complete some add-ons.

You can also use a GM-Array instead of a single tube to get a more reliable count rate.

Sunday, September 16, 2012

The $3 Geiger Muller tube to Arduino Interface

This is a "Revision 1.0". Rev 2.0 coming soon(longer tube life, better filtering..)! 

While complete Geiger Muller shields for the Arduino are available on the market, I tend to find them:
  • Unnecessarily Bulky
  • Too complexified for what they do.
Other awesome open source gm-counter projects do exist, however, they do not fit my (rather simplistic) requirements - just getting a TTL pulse for each ionization event.  

In this post, I will document how we can easily drive a GM tube with less than $3 worth of parts and an 
Arduino. It's not exactly the optimal circuit for GM tube driving, but it gets the job done in a very compact form factor.

In a nutshell, driving a GM tube typically consists of 2 distinct parts. 
  1. We need to provide the tube with a high voltage source for it to operate. 
  2. We need to detect each ionization event and convert it to a format that can be used by the micro controller. Interestingly, the circuit described above does exactly that. 

Prototyping a 400V boost converter

The first transistor (T1) takes a PWM signal(~1.9kHz) from the Arduino and together with L1, D1 and C1, acts like a boost converter to produce 400V. This voltage is then fed to the center pin of the GM tube(GMTUBE_1). 

The second pin of the GM tube, GMTUBE_2, goes to the pulse detector part of the circuit. Basically, each ionization event causes the 'Pulse_out' pin to to make a 'high-low-high' transition. This triggers an interrupt on the Arduino, which registers the event as one count. 

Typically, you'll want to count the ionization events over a certain period of time and report the results in counts per minute (cpm). You'll need to consult the datasheet of your tube to get the µRem/h conversion factor. 

The PWM_IN pin is connected to pin 5 on 8MHz Arduinos or pin 9 on 16MHz Arduinos. 
The PULSE_OUT pin is connected to pin 2 of the Arduino.

The test code can be easily edited to suit your needs. By default, it will report the "CPM" sampled over 10 seconds over serial. 

Good to know:
  • The arduino sketch included below assumes that the AVR is running at 8Mhz. If you are running at 16Mhz,  edit the code as instructed in the source file. (you'll get an incompatible PWM frequency if you don't, as the PWM frequency depends on the microcontroller's clock speed) 
  • When the PWM is at 0%, the circuit consumes a few micro amps. It consumes around 20mA during operation. 
  • The GM tube I used is a Russian, cold-war era, Si-29BG. Rugged, compact and sensitive enough. 

(Here's a video of the circuit in action - Thanks Johan! )

- M.

Saturday, June 16, 2012

Increasing the Raspberry Pi's USB Host current limit (polyfuse mod)

UPDATE: As of later revisions, the Raspberry Pi designers choose to remove the polyfuses. Therefore, this article is only valid for the first revision boards only. You can identify your board revisions by searching the Raspberry Pi forums. However, the USB hot-swap issue still remains thus the second half of the article can be useful to some Raspi hackers. 

As many of you might already know, the USB host ports of the Raspberry Pi are current-limited to 140mA per port. I find this absolutely ridiculous for such a revolutionary device to have that kind of limitation. The 'official' way around this is using a powered USB hub, but I hate the idea of adding unnecessary complexity to a project.

My way around this is to bridge the polyfuses(F1,F2) seated next to the USB ports.

This surprisingly simple mod will allow you to feed higher powered devices like certain wlan adapters directly from the RasPi's power supply line without throwing a kernel panic every 33.5 seconds. With a 5V 3A power supply, I even managed to get an external hard disk(yes, of the spinning kind) powered directly off the USB port, although I had to bridge the main 700mA polyfuse to get reliable operation and use a SHORT  data cable. [Short cables will minimize steady-state voltage drops due to cable resistance in high-current applications]

On the "Voltage Droop" issue

What is "Voltage Droop"? (hint: NOT voltage drop)

This issue is particularly annoying if you try to hot swap higher current devices, as it causes the SoC to reset due to a sudden voltage sag.

USB allows users to plug and unplug USB devices while the PC is still in operation. When an USB
device is plugged into a port, inrush current occur as the newly plugged device’s internal bypass capacitor
charges to its full potential. This current is drawn from the USB VBUS power plane of the motherboard and
causes the VBUS to sag momentarily.

(520mV sag upon device connection = more kernel panics + random restarts)

That temporary sag you see above will occur even with an overpowered power supply.

Therefore, an additional mod that could improve the hot swapping performance of high-current USB devices (like hard disks) is to use an additional low ESR capacitor between the power lines of the ports. If you look closely at the schematic, the bypass bulk-storage capacitor C32 is only 47uF. This is way too low for spec 2.0 compliance. I quote a whitepaper from "In accordance to the USB Specification Revision 2.0, the VBUS power lines must be bypassed with no less than 120µF capacitance of low-ESR capacitance per USB port." Thus, if your high-current device still behaves erratically even when you bridged the fuses and used a 2A power supply, try to place a 150uF cap between the Vusb and Gnd. If things still don't work, you can then safely proceed to blame it on the software guys.

Sticky note:
  1. If you don't know why the fuses were installed in the first place, please do not attempt this mod. 
  2. Obviously, to take advantage of the polyfuse mod, you need to have a power supply that can match up the total system power consumption at full load. (For what it's worth, I've had wlan adapters peaking at 480mA during Tx...)

Additional info: 

Monday, June 4, 2012

Raspberry Pi

This guy needs no introduction. I was VERY lucky to be on the wait-list for the second production batch.

Package on Package Assembly. 

More on this soon.