StatCounter

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: Drilled holes alignment are quite good.  







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: 
https://github.com/manis404/kalypso-bitstream/tree/master/HARDWARE

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,

m. 


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.




Result:


You can now enjoy your well deserved omxh264enc video sink.


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 usb.org "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. 


Sunday, October 16, 2011

Connecting the MRF24WB0MA to the Arduino

Power to the masses.



With the recent availability of cheap WiFi modules like Microchip's MRF24WB0MA, I find it quite difficult to NOT use them in some way or another, given their essentially limitless potential in remote sensing/control applications.

The word "remote" here retains its full meaning; you can basically turn on that lamp in your room from the other side of the planet, - or anywhere in the world for that matter - provided that you can get access to that thing we call the internet.



In this post, I will show you how to use the MRF24WB0MA on the Arduino platform.

Things you will need:

- MRF24WB0MA WiFi Module. (Available from Farnell here)
- 4x 4.7k Ohm Resistors
- 2x 1.0uF Capacitors.
- Some way of connecting these together. I used a perfboard and some wires.

[Also, check out Farnell's Arduino page for some interesting Arduino-related products. These guys are cool.]

The schematics described below are based on the WiShield 1.0 Arduino shield from AsyncLabs.

First you will have to connect the module as described below to the Arduino shield. The resistors are all 4.7k and the two caps are 1.0uF each.



Remember: Power is at 3.3v. 

The resulting circuit should be something similar to this:



Then you'll just hook this up to your Arduino. Your setup may look similar to this:



The task of connecting the WiFi module to the Arduino is way simpler than the above pictures might suggest. It's really only about connecting the SPI interface (5 wires) and Power + Reset (3 wires).

The hardware setup described is basically equivalent to an Arduino board with a WiShield 1.0 stacked on it.

Therefore, as you might have guessed, things get easier from now on - it's all software.

On your computer:


  1. Download the WiShield library here. [now mirrored on my github]
  2. Put all the files/directories under /libraries/WiShield/ directory.
  3. Restart the Arduino environment, so that the library files get built and the sketches become available.

Done. At this stage you are ready to experiment with the examples included in the WiShield libraries. 

I'll suggest you to start with the "WiShield>Webserver" example. 

This is a screencap of the page you should get when you type in the IP address of the module in your browser:




You'll have to hardcode the IP settings in the Arduino Sketch. The module does NOT support DHCP for automatic IP assignment in the examples. This implies that if you are using infrastructure mode, you will need to set your router to reserve the IP address you set in the Arduino Sketch. 

If you are using adhoc mode, things get simpler. Just make sure you set your computer up for static IP addressing. To use adhoc mode: In the sketch, change the line containing 

unsigned char wireless_mode = WIRELESS_MODE_INFRA;

to 

unsigned char wireless_mode = WIRELESS_MODE_ADHOC;

I noticed that if you use WPA2 authentication, the module will take about 30seconds to authenticate. No need to panic if the LED (shown on the schematic) does not light up right away. 

Also, make sure that you set up the security type properly:



unsigned char security_type = 0; // 0 - open; 1 - WEP; 2 - WPA; 3 - WPA2



After you've managed to correctly run the examples included in the libraries, check out AsyncLabs' forums for a variety of more interesting, real-life applications.