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.


Wednesday, January 2, 2013

Solar powered, Wireless autonomous radiation sensor network



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. 


Schematics

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: http://theiopage.blogspot.com/2012/09/simple-gm-tube-interfacing-to-arduino.html

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: https://github.com/manis404/RadSenseNode


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: https://github.com/manis404/WiFly-Shield

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.

(15/03/2013 - Schematic corrected!)

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.