Search This Blog

Wednesday, December 21, 2011

LENA - Now featuring dose measurement

The DOSE feature discussed in the previous post is now done. Taking into account the GM tube characteristics, a realistic measure of radiation dose in uSv/hour is now being calculated, based on the single event rate. From the information obtained on the internet regarding the SI-39G tube, the value of 0.00049 uSv per pulse was taken into account for the calculation of the dose.

Additionally, another mode usually found in most Geiger counters and dosimeters is the CPM (Counts Per Minute) mode. It provides a relative measure (that is of course GM tube dependent) of the radiation exposure, based on the ammount of particles detected by the tube. In this case these can be either Beta particles with more penetrating energy, and Gamma photons. Alpha particles cannot be detected by this particular tube (the SI-39G).

All the calculations are performed on the User Interface module (the cream colored box). No firmware changes had to be performed on the probe module (where an Atmel ATTiny85 is used). Only on the PIC18F2455 responsible for controlling the UI module.

The video below shows the new set of features in operation:



To enrich the feature set of the device, battery voltage measurement was also added. As the PIC also has an ADC converter, monitoring the voltage was just a mather of adding a resistive voltage divider, and a 5.1 V Zener diode for protecting the ADC input in case of excess voltage (given the designed voltage divider, in excess of 18 Volts).

Friday, December 16, 2011

LENA - The Geiger Counter that was finally made portable!



With the Geiger Muller tube module having been posted in a previous post, namely here, another important development was missing. While fully functional at that time as a sensor device which could readily be interfaced with via I2C, or having the pulses be directly picked up via a dedicated TTL signal, by itself the device could not be carried on the field and be expected to operate without additional hardware.

This is where the user interface module I am presenting here comes into play. Having been baptized after my daughter's name (shortname for Helena), it is also acronym for a more elaborate name: "Lightweight Energy and Nuclides Analyser". Since the beginning I have looked forward to adopt a modular approach and allow the probe element and its intrinsic electronics to be decoupled from the user interface, data presentation and power supply/management part. This would allow different types of sensing elements to be used. For example instead of a Geiger tube, a semiconductor based device. In this case both the detector element and the associated electronics are inherently different.

As such the idea was to build a battery powered compact device, featuring a display, control buttons and audio amplification for the pulses. This device would couple with the Geiger tube
module through a connector for carrying the I2C bus signals, single event pulse and power.

For the solution I looked forward to select an appropriate microcontroller. I considered a few basic requirements:

* Low power consumption;
* I2C master capable (at least 100 KHz);
* Plenty of I/O pins for the display and remaining elements (LED's, buttons);
* Analog pins to monitor battery voltage;
* Moderate RAM, EEPROM and Flash resources, to enable complex applications and measurement data to be retained;
* Reasonable cost;
* Compatibility with available tools.

Having some familiarity with Microchip PIC devices, I have analysed the specs of several models, with special emphasis to the PIC18 family, and found the PIC18F2455 to be an adequate choice. This device
has a broad range of features and in spite of not being part of the XLP family (eXtreme Low Power), it still has a reasonably low power consumption (which of course still depends on several factors including user options). Besides I2C support through its MSSP peripheral, it also supports serial communications, and with greater relevance, has integrated USB capability. This provides great flexibility for interfacing with the PC.



In respect to the display, instead of spending money on a new one, I found that I had a couple of HDLO-2416 originally manufactured by HP. I had these for years stored in a box, and finally found an interesting application for these. Each one has a 4-character dot-matrix, based on LED technology. Given its age (roughly 20 years) power consumption is not its best characteristic (modern LED's are more efficient). But as I didn't want to spend more money and was more interested in having a working prototype, I moved forward with this display solution. Additionally, the adoption of an exotic luminescent display sounded interesting, giving it somewhat of a vintage look (where the edge of looking for retro designs would be to use Nixie tubes :) ).



For the enclosure I went for the dirtiest, cheapest, easy to find solution. A simple plastic box used in household electrical installations:



Aesthetical aspects aside, it would do the job, allowing all the components to be fitted inside with just about enough room to also acomodate the battery.



In the case of the Geiger tube, a regular can was used. Given its metal composition, it is well suited to provide electromagnetic shielding, preventing incorrect readings.



To finalize the description of the device, here is a video showing it during operation. It illustrates the implemented functions to date. These are the following:

* Single event count - CNT;
* Delay between events (in multiples of 16 ms - to be improved) - LPSE;
* Watchdog timer ticks (multiples of 16 ms) - TICK
* Firmware version display - VER

The DOSE option is also visible in the video. It is just a placeholder for the future functionality, which will provide a measure of exposure to radiation in microSieverts/hour.



Future developments may include the implementation of a semiconductor probe, based on a photodiode or maybe a solar array shielded behind aluminium foil. While it is tipically
a challenge to use semiconductors to consistently detect single events, several key benefits exist, including the ability to quantitatively measure the energy of each particle and the
mechanical robustness, which is easier to be made higher than the Geiger tube.

In terms of overall battery consumption, figures aren't particularly exciting. On average we have about 110 mA of current drain from a 9 Volt batery. This gives about 4 hours of autonomy in the best case. Screen blanking is being performed after every 4 seconds of inactivity from the user or lack of events. Still with display blanked, consumption will not drop below 100 mA.One of the culprits is for sure the Geiger tube electronics.The HV power supply is completely unoptimized, given the fact that it was tweaked to reach the 400 Volts. Originally it would provide 300 Volts, having in this case a much lower consumption of about 8 mA (about 50 mA with 400 Volt output).

So some hardware improvements to provide better battery life are still expected, along with firmware changes that can also help increase battery life (e.g. change internal clock speed, better manage I2C communications and write operations to the display, dim the panel leds through PWM). So by carefully implementing these changes it is likely that an interesting drop in power consumption would be achieved.Comparing the current figures with those of a modern Geiger counter such as the Gamma-Scout (http://www.gammascout.com/), I would see my design as the pre-history of the low power consumption. Most of the models of this manufacturer have a battery life of 10 years. Typical power consumption is around 10 microamperes (!!) So trying to compete with these guys is out of question :)

Sunday, November 27, 2011

Me and my employer in the Elektor magazine!

In late september (the 29th to be more exact) PDMFC's online store Microsensus was officially launched. This event gathered a lot of people from the portuguese microelectronics community. And is needless to say it was a success. It was an opportunity to expose our work to many relevant people, from universities to SME's and large companies. The event also captured the media attention, in particular the portuguese version of the Elektor magazine. I had the chance to talk about the products and what motivated PDMFC to enroll in the hardware business.

As it was published, it felt good to see my face and the rest of the team printed in the pages of a magazine that for me and many people in the electronics world is legendary for its articles and its role at stimulating young minds towards creativity through the use of technological artifacts.

Saturday, November 26, 2011

Looking back to the pre-blog era

I guess back in 2002 the blog concept wasn't yet broadly disseminated. Recently I thought of taking a peek to a long unattended website I have created almost a decade ago. This web site, which you can readily access here:

http://clientes.netvisao.pt/teixelui/

has a few interesting projects which pretty much remind me of how I am consistent as a person, even after 10 years. This helps me understand that a person tends to have a reasonably stable mindset, regardless of how life worsens in complexity, challenges, problems, pain, isolated events of joy, etc.

The sense of loss is many times compensated by other gifts. Wouldn't there be a catch, as so many times is the case, these would be two vectors that cancel each other. Life, however isn't black and white. A good thing sometimes conceals a price to pay. So many times greater than simply denying it.

In life, taking the default option tends to have a costly outcome. Failing the be more actively involved in the decision process is most of the time a regretful scenario.

Anyway, after 10 years you can't help putting your life in perspective and realizing
how precious time is when compared to some many pointless things that come and go, and one way or another cause you to consume some of that precious time.

Wednesday, October 26, 2011

I2C Geiger Counter




With nuke plants operating under questionable technical safety, natural events threatening humans and their dangerous energy production artifacts, and other humans disseminating fear through nuclear sovereignty upon the rest of the world, we came a long way from the happy ignorance of distant decades.

As such, in an attempt to further increase the sense of paranoia we readily accept to live in, I took some time to design and build another sensor, in this case a low level radiation detector. Having modularity in mind, I though of creating the device in such way to serve its purpose in more than one context. In order to keep it modular, I have put all the components necessary for it to operate in a stand-alone fashion, and communicate through a standard bus with other modules. Given its adequation to the solution, I have selected the I2C bus. The necessary elements for autonomous operation would have to be:


  • Geiger Tube - bought a russian made SI-39G. Known to detect at least hard gamma radiation;

  • HV power supply - the tube requires about 400 V DC, and very small current supply. In this case I have used a modified camera flash circuit. Originally would output 300 V. I had to tweak it to generate an extra 100 V without exceding the component ratings;

  • Pulse stretching and amplification electronics - the pulse output by GM tube is too short for the human ear to identify (less than a microsecond). At the same time, the pulse signal must be conditioned to be properly handled by digital electronics;

  • Pulse counting and I2C interface - a simple 8-bit microcontroller such as the ATMEL ATTiny85 is enough to handle the job. Additionally it also outputs a short tone (about 4 ms long), every time a disintegration is detected (e.g. gamma photon). This tone can then be amplified and fed to a speaker through external electronics;

  • Linear regulator - Unlike the rest of the circuitry in the module, which is powered at 5 Volts, the HV power supply only requires 3 Volts. As such a linear regulator had to be added (in this case a LM317 adjusted to produce 3 Volts);



The big thing about this modular design is that I can either use the sensor in my other project, the AMIRO robot (link), or attach it to a still-to-be-implemented UI module, made up by a display, speaker, and microcontroller to receive the data, convert event counts to microsieverts (radiation dose unit), and possibly log the data and make it available via USB. Pretty good! The only issue, having time to materialize the ideas. In this case I can at least say almost half the implementation effort is done, 100 % of the hardware design is done, 30 % of the firmware (which accounts for the full ATTiny85 routines), and a few drafts of the mechanical layout are done in my sketchbook. One step at a time, as after all this is a hobby to be kept as a pleasing activity, out of the race track. And of course the longer the ignorance about the radiation, the better the bliss :)

About the testing of this module, it has only been done in respect to the background radiation (that is the radiation that is all around us, coming from several sources such as the trace amounts of radon gas that is in the air, Potassium 40 from our bodies, from the soil, and of course from the outer space). An average of 6 or 7 counts per minute is obtained, which converting to microsieverts (using the tube datasheet) accounts for about 0.100 microsieverts per hour, which is consistent with the expected background radiation for our location and altitude.

Tests with other sources have not yet been carried out, given its scarcity (fortunately :) ). Yet to be tested are common things known to emmit slightly more radiation than background, such as Brazil nuts, granite, bananas, thorium gas mantles (a bit hard to find these days), americium smoke detectors (practically discontinued in the EU), etc. Some of these materials do not release quite many gamma photons, making radioactivity harder to detect. A pancake detector would in this case be far more efficient at detecting a broader range of charged particles.

Sunday, October 9, 2011

Baby monitor



While preparing to be a father for the first time, I have found most baby products to be more expensive than would otherwise be desirable, given its ephemeral usefulness. Considering the full blown economical crisis that we face today, spending copious ammounts of money in things that soon become useless, seems a little too light headed and perhaps irresponsible.

Either essential or non essential products tend to be more expensive than it is reasonable to pay for. As such it is my belief that the consumer must be clever and refrain from indulging the will to buy every fancy baby product that sellers expose.

One thing I found is that quality products are incredibly overpriced if bought locally on a pharmacy or baby shop (e.g. a mere breast pump, sterilizer, pacifier, etc) when compared to large online sellers (but here it not specific to baby products).

Another case are the products which are easily replaceable by general purpose alternatives. One such example is a non-contact thermometer. While being quite convenient and fast to use, baby non-contact thermometers are technically the same (but more limited in the temperature range) than a general purpose non-contact thermometer (these are sometimes even more precise). While first considering buying a baby thermometer, I found that besides being equally effective, a general purpose equivalent would cost me about half the money, and I could use it for a myriad of other applications than for checking the baby temperature. While having the look of a work tool, it didn't really bother me, as it does the job equally well.



But the case I want to focus on is about baby monitors. While technically simple devices, these tend to cost way more money than an intelligent human being is tipically willing to pay. Even CTCSS walkie talkies are usually more powerful than these devices, and sometimes provide the same function, for less money.

In a first approach, I checked the feasibility of building a baby monitor from scratch, but soon found it to be too laborious, even though I would probably not spend much money in parts. I also considered buying the CTCSS walkie talkies, but while being less expensive I considered that I would not give future use to these, so this option was also discarded.

I have taken a look at the stuff I had in lying around at home, and found that I had at least two of the three parts of the puzzle already. One thing is an all band communications scanner I bought a few years ago for listening to all sorts of analog transmissions:



Another thing was a pair of wireless headphones from Sony, which featured quite a reasonable quality, but which I rarely used:



The headphones transmitter had a pretty good range, and I found that I could tune the scanner to either of its two transmitting frequencies: 863.520 MHz or 864.520 MHz. I could listen in perfection selecting wideband FM. Only the stereo signal didn't seem to be encoded the same way as regular broadcasting stations. So I had to listen in mono, but no problem for monitoring the baby anyway.

The only part of the puzzle left was how to connect microphones, as the transmitter only had line level inputs (0.7 Vrms), and the electret microphones signal would be well below this level to be properly heard.

So I had to build a pre-amplifier. I first tested on a breadboard some single transistor approaches, but soon realized that the quality would be below what I would be interested in.

So I looked at the popular LM358 opamp chip, which seemed to potentially provide more than enough gain for this purpose. And besides this, each package contains two amplifiers, easily allowing a stereo pre-amplifier to be built, without having to add an extra opamp for the other channel.

The following schematic describes the device:



And after testing on breadboard the finished circuit, mounted on veroboard, and placed in a nice appropriate enclosure.



First I used random electret microphones I had in my "junk repository", but inevitably found that even the most similar parts, have quite distinguishable characteristics. So for a stereo setup this should be avoided. As such I went to the cheapest place I could eventually get microphones: a chinese store. After a bit of searching in the electronics section, I found PC microphones that seemed to be quite suitable:



Costing 2 euros each, I thought it would be worth it. Took two of these and went home to test against my circuit. One would provide excelent results and the other had lousy sensitivity. This really made me even more aware of what to expect from quality control in cheap chinese products. Curiously the package had the indication "We have passed ISO9001 certification". Whatever...
Anyway, I went back to the store and replaced the bad microphone with another one I selected randomly from the stack (crossing fingers to be more lucky this time). And in fact this time I was lucky (I dont know what the odds are, but perhaps 50/50 ?). Both microphones had apparently equal performance (as far as my hearing can tell), and the final result was very good (true immersive stereo sound when heard from the sony headphones).

All in all, ignoring that the first two parts of the puzzle I already had (which by the way were not all that cheap - 50 euros the sony headphones, and about 100 euros the all band scanner), mounting the pre-amplifier was cheap (around 15 euros and one day of labour). In my case what mathers is that I saved money, as otherwise would be throwing 50 to 70 euros to something that would later become useless. This however can also be used connected to a computer or other device with audio inputs, and provide excelent sound sensitivity (similar to human hearing) for recording a conversation, music performance, etc.



Now that we are talking about electronics engineering projects, I take the opportunity to refer to a company developing great devices, aimed not only to hobbyists but to integrators. Microsensus solutions, given its use of wireless technology fits greatly into applications such as people monitoring. One of the products (the Tiny family) even has the baby monitoring as one of the design motivations:

Wednesday, August 17, 2011

AMIRO - more enhancements.

After a few months of posting abstinence here are some fresh new things to show this summer. The android application has been dramatically improved with new features and better visual layout. Additionally a portable video screen have been build, in this case sporting a 4.3" tft panel, a 1.2 GHz analog video receiver (originally used in a fixed manner), a LiPo battery, and a custom made battery voltage warning circuit (yes, LiPo batteries are particularly susceptible to damage under deep discharge situations).



What this video shows is the control console for steering the amiro autonomous rover.
It is made up by a color video receiver, and the control and telemetry module, which in this case is implemented on top of an android phone. The phone communicates via wifi with the drone, sending driving commands, and receiving status information and telemetry from sensors and other parameters. We can manually steer the car, control the throttle and pan the camera about its horizontal and vertical axis. We can also control the lighting, by varying the slider, which will give us either visible or infrared light.

The white projected square on the left side of the image is from one the infrared sensors used to determine obstacle distance. In the current version of the software, these are only being used for showing the user the distance of the obstacle to which is pointing. In future versions of amiro it is expected that these, together with the sonar sensor will be used for preventing collisions on erroneous user input.

The range of the car is limited to the wifi maximum distance, which in open space is roughly 100 meters.

The video transmitter, while operating in the 1.2 GHz band has a similar range.

The android application displays in realtime the telemetry data. It includes:

* Speed;
* Distance covered;
* Left and right infrared sensor measured distance;
* Sonar measured distance;
* Air temperature;
* Main and control battery data such as:
* voltage and
* capacity

The interface also enables the distance counter to be reset on demand, and the steering to be trimmed.

Sunday, March 13, 2011

Controlling Amiro (the name I have baptized the car) from an Android phone (HTC Desire)

While the Java PC application is useful for testing and controlling the robotic car while sitting in a chair, for on the field fun a more practical solution had to adopted. So using a popular platform that Android is, I decided to port the (Java Swing) application I already had, to run on any Android phone with a accelerometers and a Wifi connection. As the car behaves like an access point, all it is necessary is to associate the phone to it, and run the application.

Just about as fun as it is to drive it, coding the client in Android was quick an fun experience.
The interface had to contain just the essential elements. While the target hardware has abundant resolution (480x800), like in any mobile platform, screen real estate is always a concern. As such I had to economize on the components to be displayed. The result was a relatively simple UI:



It shows the data from the different active sensors (speed, 3 obstacle range values, temperature and battery status). One slider controls the throttle (the vertical one), and another slider controls the intensity of the LED headlights (also enabling the switching between white and UV LEDs).

The video below shows the car in action, this time controlled by the Android phone: