I'm a big fan of image processing that I've put to use in various previous projects, related to robotics and artificial vision, such as this one, or for video surveillance and motion detection, but also other work projects.
Image processing is a vast and captivating domain, handling ways of image representation and the transformations that can be applied , for unlimited applications. We can use it to extract characteristics related to the image: shapes (such as detecting human faces), numbers and text (for OCR purposes), enhancing the visibility, content readability or simply for aesthetic purposes (in photography), we can encode information (cryptography/security), or make a robot follow the user's red jacket. The imagination is the limit.
All the image related operations can consume a lot of processing power, so optimized algorithms taking advantage of the way the image is encoded, and doing low level operations at bit level, must be used. Math is also required as many image transformations use mathematical models that not only need to work correctly, but must be implemented in the most optimum way.

Leptonica

Over the time, mostly for academic purposes I've implemented various libraries to handle image processing both for mobile and desktop platforms. But recently I decided to use an open source library, named Leptonica, and presented as an "a pedagogically-oriented open source site containing software that is broadly useful for image processing and image analysis applications." A few days after using it I couldn't go without it. Not only it offers a robust interface to the basics: various file formats, loading and saving images, supporting and converting from multiple representation systems, but it implements powerful primitives to allow almost any possible transformation on an image. It is open source and so it exposes the internal secrets to anyone willing ot customize the code or to push the performance even further. And talking about performance , it is doing great: bit-wise operations, mathematically improved algorithms, to minimize the work load and do the job in the shortest time.

A sample

As per the article's title, the plan is to implement a simple cartoon transformation effect, using leptonica, on a regular picture. Well not quite regular, as I chose a beautiful lady for the viewer's delight.

Step 1	Step 2	Step 3
Step 4	Step 5	Step 6

Step 1: loading the original image

PIX *pixSrcImg = pixRead("girl_with_roses.jpg");

Step 2: convert to grayscale, taking the maximum deviation into account

PIX *pixGrayMM = pixConvertRGBToGrayMinMax(pixSrcImg, L_CHOOSE_MAX);
pixWrite("leptonica_cartoonizer_01_gray.jpg", pixGrayMM, IFF_JFIF_JPEG);

Step 3: perform edge detect

PIX *pixEdges = pixEdgeFilter(pixGrayMM,  L_ALL_EDGES);
pixWrite("leptonica_cartoonizer_02_edges.jpg", pixEdges, IFF_JFIF_JPEG);

Step 4: invert the edges

PIX *pixEdgesInverted = pixInvert(NULL, pixEdges); 
pixWrite("leptonica_cartoonizer_03_edges_inverted.jpg", pixEdgesInverted, IFF_JFIF_JPEG);

Step 5: blur the inverted edges, to reduce the roughness a little bit

PIX *pixBlur = pixBlur5(pixEdgesInverted);
pixWrite("leptonica_cartoonizer_04_blur.jpg", pixBlur, IFF_JFIF_JPEG);

Step 6: combine the last result with the original image, using a factor (150, can be changed)

PIX *pixCartoon = pixBlendHardLight(NULL,  pixSrcImg, pixBlur,0,0 ,150);
pixWrite("leptonica_cartoonizer_05_cartoon.jpg", pixCartoon, IFF_JFIF_JPEG);

Here's the result:

The code is composed of 4 major parts, each set in a separate class file.
1: CarouselView.java
It extends the Gallery class, to create our custom carousel view. In it's constructor it exposes:

this.setStaticTransformationsEnabled(true);

that allows us to handle the transformation of each item displayed, based on it's distance to the center: we want to rotate the items, as they get away from the center:

 
/**
 * {@inheritDoc}
 *
 * @see #setStaticTransformationsEnabled(boolean) 
 */ 
protected boolean getChildStaticTransformation(View child, Transformation t) {
	CarouselViewItem s = (CarouselViewItem)child;
	final int childCenter = s.getLeft() + s.getMaxW()/2;
	final int childWidth = s.getMaxW();
 
	int rotationAngle = 0;
 
	t.clear();
	t.setTransformationType(Transformation.TYPE_MATRIX);
 
	if (childCenter == mCoveflowCenter) {
		transformImageBitmap(s, t, 0);
	} else {      
		rotationAngle = (int) (((float) (mCoveflowCenter - childCenter)/ childWidth) *  mMaxRotationAngle);
		if (Math.abs(rotationAngle) > mMaxRotationAngle) 
			rotationAngle = (rotationAngle < 0) ? -mMaxRotationAngle : mMaxRotationAngle;   
		transformImageBitmap(s, t, rotationAngle);         
	}     
	return true;
}
 
 
 
 /**
  * Transform the Image Bitmap by the Angle passed 
  * 0 for center item
  * @param imageView ImageView the ImageView whose bitmap we want to rotate
  * @param t transformation 
  * @param rotationAngle the Angle by which to rotate the Bitmap
  */
 private void transformImageBitmap(CarouselViewItem s, Transformation t, int rotationAngle) {            
	 mCamera.save();
	 final Matrix imageMatrix = t.getMatrix();;
 
	 final int imageWidth = s.getMaxW();
	 final int imageHeight = s.getMaxH();
 
	 final int rotation = Math.abs(rotationAngle);
	 //As the angle of the view gets less, zoom in     
	 float zoomAmount = (float) (rotation * 3);
	 mCamera.translate(0.0f, 0.0f, zoomAmount);          
 
	 mCamera.rotateY(rotationAngle);
	 mCamera.getMatrix(imageMatrix);               
	 imageMatrix.preTranslate(-(imageWidth/2), -(imageHeight/2)); 
	 imageMatrix.postTranslate((imageWidth/2), (imageHeight/2));
	 mCamera.restore();
 }
 

2: CarouselViewItem.java
Is a class that defines one custom item, in this case a scalable image view with a text label at the bottom. Nothing fancy, just a class extending relativelayout with two views inside.

3: CarouselDataItem.java
The data we store for one item. We'll use this to populate our custom adapter, fill in data, and for further processing, eg. for filtering or for handling clicks on items.

4: CarouselViewAdapter.java
The custom view, as an extension to BaseAdapter. The getView method is essential: we get the item attached CarouselDataItem data, we use it to load the image from the disk, we transform the image by making a nice reflection effect and then create the corresponding CarouselViewItem object.
The advantage is that we do this on the fly, only for the displayed items. By doing so, we can show thousands of items in our Carousel view.
The reflection effect looks even better on the white-gray gradient set as background for the parent container.

 
public View getView(int position, View convertView, ViewGroup parent) {
	 // empty items
	 if (mDocus.size() ==0){
		 Bitmap empty = BitmapFactory.decodeResource(mContext.getResources(), R.drawable.empty);
		 Bitmap reflection = createReflectedImage(empty);
		 empty.recycle();
		 CarouselViewItem scaIv = new CarouselViewItem(mContext, reflection, "empty doc", m_w, m_h);
		 return scaIv; //fix divide by zero on filtering
	 }
	 // we got content
	 if (position >= mDocus.size()) { 
		 position = position % mDocus.size(); 
	 } 
 
	 Bitmap originalImage = BitmapFactory.decodeFile(mDocus.get(position).getImgPath());
	 Bitmap reflection = createReflectedImage(originalImage);
	 if (originalImage != null)
		 originalImage.recycle();
	 CarouselViewItem scaIv = new CarouselViewItem(mContext, reflection, mDocus.get(position).getDocText(), m_w, m_h);
 
	 return scaIv;
 } 
 

This class is also important for offering the filter option (the search box at the top). The idea here is that the adapter is the one that must identify the data we apply the sorting option to. In this case it is the text string attached to each item as the item name.

 
public Filter getFilter() {
	return new Filter() {
 
		@Override
		protected FilterResults performFiltering(CharSequence constraint) {
			final FilterResults oReturn = new FilterResults();
			//final CarouselDataItem[] mDocus;
			final ArrayList<CarouselDataItem> results = new ArrayList<CarouselDataItem>();
			if (mDocusOrig == null) mDocusOrig = mDocus;
			if (constraint != null) {
				if (mDocusOrig != null && mDocusOrig.size() > 0) {
					for (final CarouselDataItem g : mDocusOrig) {
						if (g.getDocText().toLowerCase()
								.contains(constraint.toString()))
							results.add(g);
					}
				}
				oReturn.values = results;
			}
			return oReturn;
		}
 
		@SuppressWarnings("unchecked")
		@Override
		protected void publishResults(CharSequence constraint,
				FilterResults results) {
			mDocus = (ArrayList<CarouselDataItem>) results.values;
			notifyDataSetChanged();
		}
	};
}
 
public void notifyDataSetChanged() {
	super.notifyDataSetChanged();
	//notifyChanged = true;
} 
 

Creating the Carousel view is easy. We need to create the control itself, and then populate it by attaching the custom adapter, filled with our data. This logic is done in MainActivity.java:

 
// copy images from assets to sdcard
AppUtils.AssetFileCopy(this, "/mnt/sdcard/plasma1.png", "plasma1.png", false);
AppUtils.AssetFileCopy(this, "/mnt/sdcard/plasma2.png", "plasma2.png", false);
AppUtils.AssetFileCopy(this, "/mnt/sdcard/plasma3.png", "plasma3.png", false);
AppUtils.AssetFileCopy(this, "/mnt/sdcard/plasma4.png", "plasma4.png", false);
 
//Create carousel view documents
ArrayList<CarouselDataItem> Docus = new ArrayList<CarouselDataItem>();
for (int i=0;i<1000;i++) {
	CarouselDataItem docu;
	if (i%4==0) docu = new CarouselDataItem("/mnt/sdcard/plasma1.png", 0, "First Image "+i);
	else if (i%4==1) docu = new CarouselDataItem("/mnt/sdcard/plasma2.png", 0, "Second Image "+i);
	else if (i%4==2) docu = new CarouselDataItem("/mnt/sdcard/plasma3.png", 0, "Third Image "+i);
	else docu = new CarouselDataItem("/mnt/sdcard/plasma4.png", 0, "4th Image "+i);
	Docus.add(docu);
}  
 

Creating the control itself:

 
// create the carousel
CarouselView coverFlow = new CarouselView(this);
 
// create adapter and specify device independent items size (scaling)
// for more details see: http://www.pocketmagic.net/2013/04/how-to-scale-an-android-ui-on-multiple-screens/
m_carouselAdapter =  new CarouselViewAdapter(this,Docus, m_Inst.Scale(400),m_Inst.Scale(300));
coverFlow.setAdapter(m_carouselAdapter);
coverFlow.setSpacing(-1*m_Inst.Scale(150));
coverFlow.setSelection(Integer.MAX_VALUE / 2, true);
coverFlow.setAnimationDuration(1000);
coverFlow.setOnItemSelectedListener((OnItemSelectedListener) this);
 
AppUtils.AddView(panel, coverFlow, LayoutParams.FILL_PARENT,LayoutParams.WRAP_CONTENT, 
		new int[][]{new int[]{RelativeLayout.CENTER_IN_PARENT}},
		-1, -1); 
 

The setOnItemSelectedListener will catch the click-on-items events. There's a toast message informing the user what was just clicked on:

The filter also works great, simply adding a text in the edittext at the top, will call the onTextChanged callback, and give the string to the custom adapter filter:

 
public void onTextChanged(CharSequence s, int start, int before, int count) {
	m_carouselAdapter.getFilter().filter(s.toString()); 
}  
 

The case of no results (after filtering is also handled), where a custom image is displayed, and the "empty doc" text as the label:

The code is released under GPL v2.0 license and can be downloaded below. For any questions feel free to use comments section.
Download source code here, or on Google code.

 
// create tiled background
Bitmap bmp = BitmapFactory.decodeResource(getResources(), R.drawable.background_pattern);
BitmapDrawable bitmapDrawable = new BitmapDrawable(bmp);
bitmapDrawable.setTileModeXY(android.graphics.Shader.TileMode.REPEAT, android.graphics.Shader.TileMode.REPEAT);
 

To set it as layout background, use:

 
// create main panel
RelativeLayout panel = new RelativeLayout(this);
panel.setLayoutParams(new LayoutParams(LayoutParams.FILL_PARENT,LayoutParams.FILL_PARENT));
panel.setBackgroundDrawable(bitmapDrawable);
 

Voila!

Sample code is available here:
BackgroundTile

Details:
The Amperex 258-B is a half-wave Mercury-Vapor rectifier tube used in power supplies. Identical to CV2594.
Filament Vf 2.5 Volts / If: 7.5 Ampere / -: Direct /
Description 7.5KV PIV, 640mA. Bi-pin version of 249B.
Amperex, Continental, Hytron, Taylor and WE known manufacturers.
Literature Taschenbuch zum Röhren-Codex 1948/49
- - Manufacturers Literature
Tube Lore, Sibley, USA 1996

Datasheet:
n/a

Links:
258-B on Radiomuseum

Details:
The Svetlana GP-5 (ГП-5) is a glass-envelope beam power triode intended for use as a shunt regulator or pulse modulator in high-voltage systems. It features anode operating voltage of 30 kV and a plate dissipation of 37.5 watts. Originally intended for color-TV voltage stabilization, the GP-5 is similar to the Telefunken ED500 and may be used to retrofit equipment which uses the American type 6BK4 or other high-voltage beam triodes.
Military equipment with "OTK" mark. Near equivalent: ED500 and 6BK4. The tube is manufactured by the Svetlana, St. Peterburg, Russia.

Datasheet:
General characteristics:
Name: GP5
Cathode: oxide-coated, unipotential
Voltage (AC or DC), V: 6.3 (± 0.6)
Current, mA: 210 (± 20)
Heater-cathode voltage, peak, V: ±200
Amplification factor (nominal): 2750
Transconductance (nominal), uS: 700
Interelectrode capacitances (typical), with cathode grounded:
- Input 4.0 pF
- Output 1.5 pF
- Feedback 0.1 pF

Mechanical characteristics:
Base standard magnoval, glass button
Socket Svetlana SK509 or similar
Anode cap approx. 3/8 in (9 mm) diameter
Anode connector same as 6BK4 or 807
Operating position Any (vertical for convection cooling)
Nominal dimensions:
- Height of glass envelope 100 mm (3 7/8 in)
- Diameter of glass envelope 46 mm (1 3/4 in)
- Overall height 125 mm (4 7/8 in.)
Net weight: 115g

Maximum ratings:
Anode voltage: 30KV
Anode dissipation: 37.5W
Anode current, continuous: 2mA
Grid voltage: -450V
Maximum grid-circuit resistance: 3 MOhms
Envelope temperature: 250C

Links:
Radiomuseum
Russian tubes

Variant 1 : Atmega8 + Nokia 5110 LCD + 3V power supply

I am using an Atmega8-8PU (configured for 8MHz with external crystal), a Nokia 5110 lcd, and a transistor to handle the pulses from a reed relay. A 3.3V regulator provides the voltage for the entire circuit.

Everything has been mounted on a test board, including the headers for: ISP programmer (USBAsp), the 5110 Nokia LCD, the power supply (5V in, fed to the 3.3V regulator), the Reed relay connector, the reset button connector and another 2 pins connector, used to read the polarity of coil winding machine's motor, so we know we either increment or decrement the counter.

There are a few connectors:
J1: is for the power supply. The circuit takes 5V, that get into the L7833 for 3.3V output used by the atmega8 uC and the LCD.
J2: is the LCD connector, going to the Nokia 5110LCD.
J3: goes to the reed relay. This is the place we generate pulses for the microcontroller to count.
J4: is the polarity connector. It must be connected in parallel on the coil winding machine's motor. It was designed for a 12V motor (but this can be changed by adjusting the voltage dividers formed by R3-R4 and R5-R6, so they take in the motor voltage, and output not more than 5V). If the motor is connected in normal polarity, we will read PD0 high, if the motor is in inverse polarity, we'll have PD1 high. This info is used in the code to either increment or decrement the counter.
J5: is just a simple momentary switch. When pressed, will reset the counter to zero.
ISP connector: is a 10 pin connector used with the USBAsp AVR programmer.

Circuit diagram:

Fuse bits:
External 8MHz crystal. The settings are:

 
avrdude -p atmega8 -c usbasp -U lfuse:w:0xff:m 	-U hfuse:w:0xc9:m 	
 

Source code:
You can download and use the source code, under the Apache license, here.

Variant 2 : Atmega8 + 2x16 HD44780 Character LCD + 5V power supply

Some of my readers asked for a custom variant, that uses a 2x16 HD44780 LCD (or a 1x16 smaller variant). These displays require a 5V voltage supply, so here is variant 2 of the digital counter, modified to support these requirements.

2x16 LCD Circuit Diagram:

Hex file, SCH and source code:
Can be downloaded here: atmega reed digital counter 2x16LCD

In a world dominated by Android and iOS, how hard is it for another mobile platform, be it one bearing the glory of the past, to reconquer the market shares it once had? It's all about marketing, a bit of luck, but from my point of view (not generally applicable, see how iOS started), the technology involved - the actual value resulting from the time and effort invested in making something better. Blackberry has reinvented itself in a new, fierce competitor with its latest release, the Blackberry 10. The handsets running the new OS are impressive: huge 768 x 1280 pixel screens, 8Mega pixel camera (with geotagging and face detection), 2GB of Ram memory and a Dual-core 1.5 GHz Krait processor. A beast in terms of hardware capabilities but also a huge step forward.

Installing the tools

The technology also refers to the software available, and the software dedicated to developers to make even more apps for the platform. Here I was surprised to find new changes, as compared to my previous experience with these devices.
Installing the new development tools is easy, it is a customized IDE based on Eclipse, the installer does everything, including requesting the code signing information (the developer account and all resources, including the signing keys are all free). To start, go here.
Once installed, you can go to File->New Project to start your own development work, or File->New->Example to pick one of the tens of samples available.

A simple hello World application

When starting a new Blackberry 10 project, the wizard gives us several choices:

BlackBerry Native SDK provides APIs to access some of the low level/core functionality of the device, ranging from events, to screens, audio, sensors, network etc. Use the Native SDK when you need direct access to the hardware. The Cascades SDK is a UI toolkit built upon the Qt toolkit. It provides you with a common set of UI controls, with a common look and feel. A good choice for building User interfaces.
Cascades rely on a static QML file. My common practice is to build the interface dynamically: it can get more complicated at the cost of code readability, but it gives total control over the interface, during the runtime (conditional creation/deletion of various UI elements, eg.serial key field only if the software is not registered, etc). So instead of presenting a QML based Hello World interface, I'll show you how to create the equivalent, using only C++ code.

 
ApplicationUI::ApplicationUI(bb::cascades::Application *app): QObject(app)
{
	// create root object for the UI
	Page *page = new Page();
	// set created root object as a scene
	app->setScene(page);
 
 
 	Container* pContainer = new Container();
	page->setContent(pContainer);
 
	// create top text field
	m_tf = new TextField();
	m_tf->setText("Status");
	pContainer->add(m_tf);
 
	// Position button 1 horizontally centered of the container
	Button* pButton1 = Button::create().text("Button1");
	pButton1->setHorizontalAlignment(HorizontalAlignment::Center);
	// catch click events
	connect(pButton1, SIGNAL(clicked()), this, SLOT(onButton1Clicked()));
	// add button to container
	pContainer->add( pButton1 );
 
	// Position button 2 horizontally centered of the container
	Button* pButton2 = Button::create().text("Button2");
	pButton2->setHorizontalAlignment(HorizontalAlignment::Center);
	connect(pButton2, SIGNAL(clicked()), this, SLOT(onButton2Clicked()));
	// add button to container
	pContainer->add( pButton2 );
 
	// create a text label
	QString labelText = "Hello World! www.pocketmagic.net";
	Label *label = new Label();
	label->setText(labelText);
	pContainer->add( label );
 
	// create an image view
	ImageView* imageView1 = new ImageView();
	imageView1->setImage(Image("asset:///logosymbol.png"));
	imageView1->setHorizontalAlignment(HorizontalAlignment::Center);
	pContainer->add( imageView1 );
}
 

The Slots for the two buttons, have to be defined in aplicationui.hpp as following:

 
public slots:
void onButton1Clicked();
void onButton2Clicked();
 

The debug function with output to Console in the Eclipse IDE, can be defined in main.cpp:

...
void myMessageOutput(QtMsgType type, const char* msg){
               fprintf(stdout, "%s\n", msg);
               fflush(stdout);
}

Q_DECL_EXPORT int main(int argc, char **argv)
{
    // this is where the server is started etc
    Application app(argc, argv);

    qInstallMsgHandler(myMessageOutput);
    ...

To set some of the button's fields separately, you can also create it by using:

 
QString buttonText = "myText";
    Button *button2 = new Button();
    button2->setText(buttonText);
    button2->setImage(Image("asset:///image.png"));
 

Where image.png is a png image file, placed in your project's assets folder.

Here is the result of running the program above, both on landscape and portrait:

The code is available for download.

The detector element is a ionization chamber, that consists of a gas-filled chamber with two electrodes; known as anode and cathode. The electrodes in the CDV-717 are in the form of a cylinder arrangement with a co-axially located internal anode wire. A voltage potential is applied between the electrodes to create an electric field in the fill gas. When gas between the electrodes is ionized by incident ionizing radiation, Ion-pairs are created and the resultant positive ions and dissociated electrons move to the electrodes of the opposite polarity under the influence of the electric field. This generates an ionization current which is measured by an electrometer circuit. The electrometer must be capable of measuring the very small output current which is in the region of femtoamperes to picoamperes, depending on the chamber design, radiation dose and applied voltage.

There is a manual available online here and more resources on the civildefensemuseum website or on orau.org. Some additional details on the ionization chambers can be read here.

The circuit diagram:

The CDV-742 Radiological Dosimeters are electrostatic devices used for measuring an
accumulated dose (over a period of time) of radiation. The civil defense dosimeters are a standard dosimeter design. This same type of dosimeter would be used anywhere people would have to measure their accumulated radiation dose. The electrostatic type of dosimeter is charged with a dosimeter charger (pictured above). This charger, charges the inner chamber of the dosimeter tube with a high voltage charge which zeros the dosimeters hair like crystal in the viewing scale. When ionizing gamma radiation passes through the dosimeter it discharges it causing the hair like crystal to move up scale resulting in a reading of the accumulated dose received by the dosimeter.

The inside of a dosimeter pen contains a capacitor (charged with the charger/CDV-750), an electroscope (the quartz fibre), lenses to focus the light to allow observations via the eyepiece and finally a scale (working as an overlay on top of the quartz fibre shadow):

And yet more in-detail diagrams:

Resources:
[1] orau.org
[2] michigancivildefense.com
[3] civildefensemuseum.com
[4] vaughns-1-pagers.com
[5] hosfelt.com

Checking everything step by step, I saw the following:
1. The oscillator works
2. Only 100V output, after the rectifier diode
Here is the circuit diagram:

I changed the two caps right after the diode. The issue remains. Disconnecting the diode's positive end, shows 900+ volts, but when connected in the circuit, I barely can get 200V, and the funny thing is the unit was operational last time I've used it. I then changed the second transistor (the one handling the headset and the dial) (PNP) to a generic PNP and also changed the selenium diode to a 14KV 10mA modern one. No luck.
Thanks to the CDV700CLUB group, I got some excellent suggestions on what to try next, but most of that I checked already to no avail: Bad regulator, leaky hv cap, bad probe cable, bad geiger tube.
As disklog suggested, the problem might be failure of the T1 transformer, resulting in the defects that I have observed/measured. So I would either need to rewind the transformer or find a replacement (which is a bit complicated for such old designs).

Doug was so kind to help me on this matter, and sent me not one but two CDV700 circuit boards and some additional components. Thanks Doug!
Given this nice donation, getting my CDV700 operational again was so easy. I replaced the entire board with one received from him:

It worked from the first try!

Details:
External Cavity, 1KW at 1075 to 1096MHz. 'Electrodeless' discharge: the tube has the ground ring and a keep-alive electrode connection in the base. Made by Bomac and Sylvania. It measures 38x20mm (12mm across glass).

Datasheet:
n/a

Links:
Radiomuseum
Tubecollector
Disk seal vacuum tubes

Details:
5J29 is a split anode magnetron. This device is water cooled, the water flowing round the metal loop.
Identical to: 5J29 = CV3842 = ZP579
Filament: Vf 2.2 Volts / If: 35 Ampere / -: Direct /
Description: External magnet, split-anode, glass body CW magnetron; 350 to 770MHz; 75 to 150W out. Liquid-cooled through the anode tubular pins and the internal loop, part of the tuning line resonator.
450mA max at 2500V, 1500 gauss flux density. Used in the AN/APT-4 jammer. 'Confidential' etched on the glass.

The 5J29 is an unusual device, a water-cooled split anode magnetron, used primarily in the AN/APT-4 radar jammer. Unlike a conventional multicavity magnetron, the 5J29 is effectively a miniature cyclotron accelerator. The 5J29 is best known as a GE product; the second-source FTR version is much rarer. The 5J29 operates at frequencies between 350 and 770MHz.

The AN/APT-4 Radar Jammer

"This jammer, code named Broadloom I, was the first to use one of the techniques feverishly explored in the middle of the war to raise power outputs at VHF and UHF frequencies. Faced with the inability to use conventional triodes and tetrodes at power levels of more than 20 or 30 watts output, this transmitter was designed to use an early 1930s development - a split anode magnetron - to obtain 150W CW output from about 140 MHz to almost 800 MHz. They used two different tubes to cover this frequency range , along with an impressive amount of hardware devoted to the care and feeding of this simple(!) one tube transmitter. These tubes differed from the more familiar cavity magnetrons used for pulse radar work in that they used an external resonant LC circuit, sometimes called a tank, to provide an impressive tuning range.

Composed of three separate packages - left to right a power supply, an AM modulator using a pair of 813 PA tubes, and the transmitter - this prototype set by Stromberg Carlson had a production run of only 100 sets.

GE was selected to manufacture the final product, and there are small changes between this rare example and the later GE set that had an initial production of 2,092 sets. Below is a photo of the interior of the GE transmitter, showing the long tuning cavity and coaxial line stretcher "trombone" used to get the frequency down to its surprising low end of 2 meters.

There was a serious filament "back heating" problem that plagued the early developers (analogous to thermal runaway in a transistor circuit), Initial operation with the split anode tube ran into an impractically short lifetime of less than 30 hours for the tube. It seems that you have essentially a miniature cyclotron at work in the tube, and especially at frequencies below about 150MHz, electron leakage from the anodes bombarding the glass seals was causing the early failure. Eventually, the simple addition of washers and nuts above the seals deflected the electrons from the seals enough to make the tubes last ten times as long. Even so, there is an impressive amount of heat to be carried away from an operating tube, and this package is filled with electric motors to accomplish that task - three blowers (two to blow air through the glycol cooled radiator used to keep the tube temperature down), as well as a coolant pump at lower left. The recirculation method depended on which of the two magnetrons was used. The lower frequency magnetron at left below required coaxial brass tubes to circulate pure glycol deep into each anode of the magnetron, recovering the hot fluid coming back out in the outer brass tube. The higher frequency tube had a continuous loop through the tube, so circulation wasn't quite so difficult a problem and could recover more heat in operation. Changing magnetron types on the Stromberg Carlson prototype required turning a valve 90 degrees, while the later GE set accomplished the same thing through the tube attachments. Below is a closeup of both tubes - a 5J30 on the left and 5J29 on the right. " Source [4]

Datasheet:
n/a

Links:
[1] Radiomuseum
[2] The Vintage Technology association
[3] Tubecollector
[4] Magnetron Jammers
[5] TDY-1 Radar Jamming system

Given its extraordinary chemical reactivity, there are multiple applications for this substance. Preparing it via electrolysis is the easiest way to go, however we need to use a molten sodium hydroxide electrolyte, as the resulting sodium would react with the water in an aqueous solution. Not that hard to do, as NaOH melts at 318 °C . The temperature is reasonably low to allow the separation of the resulting sodium without spontaneous ignition in air, but extra caution must be exercised as the chemicals involved are highly caustic, especially at high temperatures.

I used a ceramic electrolysis container with two steel electrodes. Carbon rods doesn't go to well. The power supply was my trusty variable regulated DC supply, and most of the time I used 7-10V. To melt the sodium hydroxide I used a butane torch: melting is necessary to get the electrolysis going , but then the flowing current will keep the NaOH in molten state and the torch is not required anymore.

In the laboratory, with carefully controlled conditions, sodium metal can be isolated from the electrolysis of the molten monohydrate in a low temperature version of the Castner process, according to the following reaction:

4 NaOH·H2O(l) → 4 Na(l) + O2(g) + 6 H2O(g)

The monohydrate does not need to be heated in order to melt, as the process produces enough heat due to ohmic heating. However, it must be initiated with a small quantity of liquid water to create an electrically conductive electrolyte. As the system's temperature increases, the monohydrate will start to melt at about 65 °C as stated above. Only when the temperature reaches about 100 °C can sodium be isolated. Below this temperature, the water produced will react with the sodium: above this point, any water formed will be driven off in the vapour phase, creating an essentially anhydrous reaction. While this process has some advantages over other electrolytic processes, it is not preferred by most chemists because a marginal quantity of sodium produced boils at the electrode interface.

If temperature is too high, part of the sodium will dissolve in the molten NaOH, as shown in the video (the black substance surrounding the metallic sodium spheres). Also the electrodes should be some space apart to prevent short-circuit due to the liquid sodium getting mixed in the electrolyte.
NaCl might be a good alternative, but at the high temperature needed to melt it, handling sodium is more problematic.

Eye protection is an absolute must, as the chemicals involved will quickly burn through skin!

Besides the multitude of screen densities, that can be handled satisfactory by using the DPI approach, there are also very big differences in screen resolutions, especially when comparing phones with tablets.
Creating a separate layout xml file might be a painful experience, not to mention that that are times when we simply want to scale the same interface, to maintain its look and consistency when running on a phone, but also when running on a tablet. So, here is the question:

How to scale an Android User Interface on multiple screens?

Let's start with an example: two android devices, a tablet (MDPI, 1280x800 pixels) and a phone (HDPI, 960x540). The sample code shows an image, centered on the screen. The image is provided in res/drawable-mdpi and res/drawable-hdpi. Here are the two variants:

The tablet picks up the 48x48 one, and the phone the 72x72 one, as expected, based on their DPIs. The code to draw the image is simple:

 
 public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
        RelativeLayout panel = new RelativeLayout(this);
        setContentView(panel);
 
        ImageView iv = new ImageView(this);
        iv.setImageResource(R.drawable.scaletest);
        RelativeLayout.LayoutParams lpv = new RelativeLayout.LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);
        lpv.addRule(RelativeLayout.CENTER_IN_PARENT);
        panel.addView(iv, lpv);
 
    }
 

Here are screen captures showing the result, and a real photo. The real photo shows that the DPI is correctly taken into account, and the image appears of having the same size on these different density screens:

Now let's assume we are designing a single interface layout in Photoshop: we place some given size buttons, some given size images, and all in one, the entire interface is designed to fit a certain aspect ratio. How can we have that fit into the two screens used as examples above?

Well, for a start, if we go for full sized/no titlebar and no statusbar option:

 
requestWindowFeature(Window.FEATURE_NO_TITLE);				
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,WindowManager.LayoutParams.FLAG_FULLSCREEN);
 

then the tablet has (in landscape mode) a screen ratio of 1280/752=80:47 (because the bottom tablet bar also uses space, out of the total 1280x800 screen size) while the phone has 960/540=16:9. Both interfaces should be on landscape, so if we design our interface layout to be of 960x640 pixels, we'll need to scale the height (640) to match the tablet's screen height, and so for the phone's screen height. Using this scaling factor, we then resize the width as well, and our interface designed for 960:640 will get: 1128x752 (scale factor 1.175, padding horizontal: 76pixels) on the tablet, and 810x540 (scale factor 0.84375. padding horizontal: 75pixels):

So what we can do at this step is design the entire interface to match 960x640 pixels, then put all images in drawable-nodpi (so we always get constant size bitmaps), and scale everything on screen according to our scaling factor, m_fFrameS:

 
@Override public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
        requestWindowFeature(Window.FEATURE_NO_TITLE);				
        getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,WindowManager.LayoutParams.FLAG_FULLSCREEN);
 
        RelativeLayout panel = new RelativeLayout(this);
        setContentView(panel);
 
        /*ImageView iv = new ImageView(this);
        iv.setImageResource(R.drawable.scaletest);
        RelativeLayout.LayoutParams lpv = new RelativeLayout.LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);
        lpv.addRule(RelativeLayout.CENTER_IN_PARENT);
        panel.addView(iv, lpv);*/
 
        DisplayMetrics dm = new DisplayMetrics();
		getWindowManager().getDefaultDisplay().getMetrics(dm);
		int m_nTotalW = dm.widthPixels;
		int  m_nTotalH = dm.heightPixels;
		// scale factor
		float m_fFrameS = (float)m_nTotalH / 640.0f;
		// compute our frame
		int m_nFrameW = (int) (960.0f * m_fFrameS);
		int m_nFrameH = m_nTotalH;
		// compute padding for our frame inside the total screen size
 
		int m_nPaddingY = 0;
		int m_nPaddingX = (m_nTotalW - m_nFrameW) / 2;
 
        Log.d("ScaleTest", "Total:"+m_nTotalW + "x"+m_nTotalH+ " Scale:"+m_fFrameS+" Frame:"+m_nFrameW+"x"+m_nFrameH + " Padding:"+m_nPaddingX+"x"+m_nPaddingY);
 
        RelativeLayout frame = new RelativeLayout(this);
        frame.setBackgroundColor(Color.GRAY);
        RelativeLayout.LayoutParams lpv = new RelativeLayout.LayoutParams(m_nFrameW, m_nFrameH);
        lpv.leftMargin = m_nPaddingX ;
        lpv.topMargin = m_nPaddingY;
        panel.addView(frame, lpv);
    }
 

Scaling method 1: scaling the drawables

As you can see , we are more interested in preserving our interface's coordinates, and graphical elements intact, then of actually having our buttons have the exact length in centimeters between various devices (not really important). To continue, let's use another example, where we design a complete 960x640 user interface (the floral brown background), and we have one single imageview (the purple flower), placed at some exact coordinates. We want this interface to be drawn exactly the same way, when running the code on various devices:

The coordinates for the imageview are given by the cyan guidelines. We save the two images (background, flower) in /res/drawable-nodpi . To load them we use:

 
public Bitmap getScaledBitmap(Context context, float scalex, float scaley, int id) {
	Bitmap bitmap = BitmapFactory.decodeResource(context.getResources(), id);
	Matrix matrix = new Matrix();
	matrix.postScale(scalex, scaley);
	matrix.postRotate(0);
	Bitmap scaled =  Bitmap.createBitmap(bitmap, 0, 0, bitmap.getWidth(), bitmap.getHeight(), matrix, true);
	bitmap.recycle();
	return scaled;
}
 
public Drawable getScaledDrawable(Context context, float scalex, float scaley, int id) {
	return new BitmapDrawable(context.getResources(), getScaledBitmap(context, scalex, scaley, id));
}
 

And then the code to display the background and the image is:

 
       frame.setBackgroundDrawable(getResources().getDrawable(R.drawable.background_ui_android));
 
        ImageView iv = new ImageView(this);
        iv.setImageDrawable(getScaledDrawable(this, 
        		m_fFrameS, m_fFrameS, // same scaling factor on horizontal and on vertical 
        		R.drawable.flower_ui));
        lpv = new RelativeLayout.LayoutParams(
        		Scale(231,m_fFrameS), Scale(192, m_fFrameS));
        lpv.leftMargin =  Scale(410,m_fFrameS);
        lpv.topMargin = Scale(239,m_fFrameS);
        frame.addView(iv, lpv);
 

And here is the result: tablet vs phone:

As you can see, the images are perfectly scaled, aspect ratio matched, on two different android devices.
Sample code available here: ScalingTest_1

Scaling method 2: scaling the Views

The first approach was to scale the drawables we feed to the views. Let's try instead, to create custom views of exactly the same we provide, while their content scales automatically. We'll be needing a custom ImageView, so we'll just extend the class.
The trick is to override the onMeasure method:

 
public class ScalableImageView extends ImageView {
	int m_w, m_h;
 
	public ScalableImageView(Context context, int w, int h) {
		super(context);
		m_w = w; m_h = h;
	}
	@Override 
	protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec){
		super.onMeasure(widthMeasureSpec, heightMeasureSpec);
		this.setMeasuredDimension(m_w, m_h);
	}
}
 

And the result is very much the same, but without having to allocate memory for the scaled drawable, as in example 1:

The code: ScalingTest_2

To connect it to an Atmega8, you can use the following diagram:

The code, written as a C++ class, allows you to output text or draw pixels, position anywhere on the screen, or even draw images. The initialization function is highly flexible, allowing you to specify the pins allocated for the LCD, on the fly:

 
// define the 5 LCD Data pins: SCE, RST, DC, DATA, CLK
lcd.lcd_init(&PORTB, PB0, &PORTB, PB1, &PORTB, PB2, &PORTB, PB3, &PORTB, PB4);
 
while (1) {
	// image demo
	lcd.printPictureOnLCD(introScreen);
	_delay_ms(2000);
	lcd.lcd_clear();
 
	// goto and char demo
	for (int i=0;i<14;i++)
		for (int j=0;j<6;j++) {
			lcd.lcd_goto_xy(i,j);
			lcd.lcd_chr('0' + (i + j) % 10);
			_delay_ms(10);
		}
	_delay_ms(2000);
	lcd.lcd_clear();
 
	// formatted string demo
	for (int i=10;i>0;i--) {
		lcd.lcd_goto_xy(0,1);
		lcd.lcd_string_format("   00.00.%02d   \n  pocketmagic \n     .net     ", i);
		_delay_ms(200);
	}
	_delay_ms(2000);
	lcd.lcd_clear();
 
	// draw a chart
	for (int i=0;i<84;i++) {
		int f = (i * i) % 48;
		lcd.drawPixel(i,0, 1);
		lcd.drawPixel(i, f, 1);
	}
	_delay_ms(2000);
	lcd.lcd_clear();
}	
 

Here is the result of the code above:

A few pictures:

The image data with the two cats, available in introscreen.h, has been generated out of a monochrome, 84x48 pixels BMP, using the LCDAssistant software, by Radoslaw Kwiecien.

The code is available as open source, licensed under GPL v2:
lcd_5110

The signal shape at the emitter:

The signal at the receiver, just before the diode:

The range is excellent, at about 4 meters, the receiver was returning more than 100mV, for the detected signal, while at less than 1 meter it was putting out 4 V. The emission cone's angle is almost 40 degrees wide. An excellent module for robotics!

Update: And speaking about robots, here are some neat ultrasonic detector modules, built for the differential rover robot I'm currently working on.
These modules can be hooked up to a microcontroller's ADC port, and will return distance dependent voltages. So not only you can use them to spot the direction the sound is coming from, but you can also estimate the distance. The output is via the "signal" pin, which will provide approximately 0..5V depending on the power level of the detected ultrasonic signal.
I built two, as I need differential data to be able to pinpoint the source beacon easier.

Circuit diagram and PCB layout

Eagle PCB layout available here: ultrasonic_beacon_receiver

Resources:
Ultrasonic Barrier
A cheap ultrasonic range finder

A few pictures with the construction itself:

Opens a world of possibilities, doesn't it?

Pictures

A quick test:

Circuit diagram:

PCB available here: hbridge

H-Bridge can limit the motor current

Resistors R1, R2, R5 and R6 can be used to control the amount of current available to the motors. Using the default 1K value, there might not be enough current to allow steering (turning around while standing by using the differential system):

Changing the resistors to lower 150 Ohm values, produces a completely different result: more current is available to the motors, expressed in higher torque and the steering movement is successfully executed:

So keep this in mind when building your own. Controlling the current is a great feature to use when we want to limit the amount of current available to the load. We can use it to avoid overheating or for other applications.
But for this particular construction, the motors need the extra current to allow turning the robot correctly.

Hardware tools

To set the fusebits you can use the same tool you use to write the .hex. In my case, this is my trusty USBAsp USB programmer, that works great!

Software tools

Here things get a bit more complicated. On one hand you need the software that works with USBAsp, but on the other hand you need to correctly compute the fusebit values that will be programmed in your AVR.
For the first I use Winavr. If working with a command prompt line tool seems complicated to you, consider using alternatives such as Extreme burner.
For computing the fusebits, there are quite a few online webpages that help you achieve the goal in easy steps: here or here . Any of these two will do. Accessing one of these pages, you must select the AVR you need to program the fusebits for , then several tables with apparently complicated settings show up:

To help you get going, here are a few details you should know:
Clock selection
This controls how the chip is clocked. The drop down menu shows a big list of options, but reading those carefully you'll quickly see they all mention the Clock Source and the Clock Startup. Wrong clock settings can make your AVR unusable. If this happens, see the Fusebit doctor below, to learn how to reset the fuses and "revive" your AVR.
The Clock Source contains the following:
External Clock, Internal 8MHz clock, Internal 4MHz clock, Internal 128KHz clock, External Crystal (0.4-0.9 MHz), External Crystal (0.9MHz - 3.0MHz), External Crystal (3.0MHz - 8.0MHz) or External Crystal (8.0MHz +)
The Clock Startup can be one of the following:
14CK + 0 ms, 14CK + 4 ms, 14CK + 65 ms.
External Clock means that a square wave is being input into the CLOCK-IN pin by using a clock generating chip. This is uncommon and usually you won't be needing it.
Internal Clock sets the avr to use the internal oscillator that is not very precise but good for most projects that don't have fine timing requirements. You should know that this clock varies with temperature and the power supply voltage. You can chose from a 8MHz, 4MHz or 128KHz clock. The 128KHz clock is for very low power applications where the low speed helps conserve power. By using the internal clock, you don't need to wire up a crystal so we can use the XTAL1 and XTAL2 pins for various other purposes.
External Crystal option is used when you need a special clock rate, like 8MHz or 12MHz or a high precision clock that will not vary with temperature or power supply voltage fluctuations. In this case you need to connect an external crystal or oscillator.
The Startup Time is a short delay, used to pause the clock for the given time, the very first time the power is applied. To be on the safe side, go with the longest setting 14CK + 65ms unless you know for a fact your settings must be different.
Clock Output (available for some AVRs only) produces a square wave of the same frequency of the clock input (internal, external, crystal, etc) on a given pin (D2, B0, etc). This is useful if you're debugging the clock rate, or if you want to use the clock to drive another chip.
Clock Divide (available for some AVRs only), causes the chip to divide the clock rate by 8. So if the clock source is set to Internal 8MHz and you have this fuse set, then you'll really be running at 1MHz. By default, this is turned on.
Reset Disable, turns the Reset pin into a normal pin instead of a special pin (as it is set by default). If this fuse is enabled (Reset Disabled), you won't be able to program the chip using ISP anymore. Be careful about this option, and never set it on, unless you really need the one extra pin. If you set this fuse in error and you can't access your AVR anymore, see the Fusebit doctor, to learn how to reset the fuses and "revive" your avr.
Brown-out Detect fuses set the voltage threshold for the Brownout protection circuitry on. A "brown-out" happens when the voltage drops and your clock radio may stop working: the power voltage is too low to run reliably at the predefined. ex: ATtiny2313 can run as fast at 20MHz but only if the supply voltage is between 4.5V and 5.5V. If the voltage decreases below 4.5V, the AVR may behave erratically, erasing or overwriting the RAM and EEPROM, it may also start running random piece of the flash program, all in one an action with unpredictable results, nothing you would want your hardware to do. To keep it under control, set the brownout voltage to 4.3V. If the voltage goes below this threshold, the chip will turn off until the voltage returns. It will then reset and start over. If the chip is meant to run at 5V, set the brown-out to 4.3V. If the chip can run as low as 3.3V you can set the brown-out to 1.8V. If the chip is a 'low voltage compatible' chip such as the attiny2313V (which can run as low as 1.8V if its clocked at 4MHz or less) then you can set the brownout to 1.8V. You can read more in the datasheet.
By default, this option is disabled. If your AVR uses a bootloader or the EEPROM, you must set the BOD for safety!
SPI programming (SPIEN fuse), if this fuse is not enabled, the part must be programmed using high-voltage, and the SPI interface will not be usable (so no USBASP for you). Be careful about disabling this fuse, as without a high voltage programmer, your AVR might become unusable. Also see the Fusebit doctor below, to learn how to reset the fuses and "revive" your avr.

As a result of carefully choosing the FUSEBIT Settings, you get several numbers in HEX, representing the LOW FUSE, the HIGH FUSE, and for some AVRs the EXTENDED FUSE.
To set them with AVRDUDE (WinAVR) or Extreme Burner, see the examples below:

Examples

ATMega8 default settings: 1MHz internal oscillator
avrdude Syntax:

 
avrdude -p atmega8 -c usbasp -U lfuse:w:0xE1:m 	-U hfuse:w:0xD9:m
 

Extreme burner

As you can see the lfuse and hfuse numbers are the same (0xE1 and 0xD9). To save on article length, and increase readability, I will only show the AVRdude settings, while you can easily insert those numbers in Extreme Burner for the same results.

ATMega8 8MHz external crystal

 
avrdude -p atmega8 -c usbasp -U lfuse:w:0xDC:m -U hfuse:w:0xD9:m
 

ATMega8 16MHz external crystal

 
avrdude -p atmega8 -c usbasp -U lfuse:w:0xFF:m -U hfuse:w:0xC9:m
 

ATMega128 default

 
avrdude -p atmega128 -c usbasp -U lfuse:w:0xE1:m -U hfuse:w:0x99:m
 

ATMega128 16MHz external crystal fuses

 
avrdude -p atmega128 -c usbasp -U lfuse:w:0xFF:m -U hfuse:w:0x89:m
 

ATMega168 default fuses, 1MHz internal oscillator

 
avrdude -p atmega168 -c usbasp -U lfuse:w:0x62:m -U hfuse:w:0xDF:m -U efuse:w:0x1:m -U lock:w:0xFF:m
 

ATMega168 16MHz external crystal fuses

 
avrdude -p atmega168 -c usbasp -U lfuse:w:0xdf:m -U hfuse:w:0xDF:m -U efuse:w:0xF9:m -U lock:w:0xFF:m
 

ATMega328p default fuses, 1MHz internal oscillator

 
avrdude -p atmega328p -c usbasp -U lfuse:w:0x62:m -U hfuse:w:0xD9:m -U efuse:w:0x7:m -U lock:w:0xFF:m 
 

ATMega328p 3-8MHz external crystal

 
avrdude -p atmega328p -c usbasp -U lfuse:w:0xdc:m -U hfuse:w:0xDF:m -U efuse:w:0xFF:m -U lock:w:0xFF:m 
 

ATMega328p 16MHz external crystal fusebits settings

 
avrdude -p atmega328p -c usbasp -U lfuse:w:0xdf:m -U hfuse:w:0xDF:m -U efuse:w:0xF9:m -U lock:w:0xFF:m 
 

Fusebit doctor

The fusebit doctor, designed by manekinen, is a device for repairing dead ATmega and ATtiny family AVRs by writing the default, correct fusebits. Most common causes for dead AVRs, are wrong clock source settings (CKSEL fusebits), disabled SPI programming (SPIEN fuse) or disabled reset pin (RSTDISBL fuse). This circuit uses the parallel and serial high-voltage programming method: HVPP = high voltage parallel programming and HVSP = high voltage serial programming.
Manekinen's device come with a database of supported chip, stored in the board's main microcontroller, that is used to recognize the faulty chips, and restore their original settings. To do this, we only need to place them in the correct socket and press the START button. So easy. As all project resources have been kindly provided by the author, I built my own board to repair some of my faulty chips.

One of my atmega328p's had faulty fusebit settings, because of some complications while writing its firmware. To revive it , I put it in the AVR Doctor's socket, and pressed the START button. Almost instantly the GREEN Led turned on, and the "patient" was cured. So simple.

PCB, Schematics and firmware available here or here.

Short Intro. NMEA Sentences

Most GPS Modules output serial data, using the RX TX pins, and the UART protocol. The data itself is in the NMEA format, a CSV (comma separated value) format with predefined keywords. One such set of NMEA CSV values, that starts with $ and ends with EOL, is called a [b]NMEA sentence[/b].
The NMEA sentence is a comma separated list of values which contains information on a single GPS reading. There are a number of sentence types, each with its own, variable number of values, as defined by the NMEA protocol, such as the GPRMC (Recommended minimum specific GPS/Transit data) sentence, the GPGGA (Global Positioning System Fix Data) or the GPGSV (GPS Satellites in view) just to name a few. See this page for more details on the NMEA sentences.

More details

The library consists of two files, nmea.cpp and nmea.h defining a C++ class, named NMEA. The GPS data is provided to a instance of this class (an object) using the feed function int fusedata(char c); . As you can see this function takes one char, and must be called each time serial data is received from the GPS module.
For AVR - GPS communication, I wrote another handy piece of code, an UART library allowing both polling based and interrupt based information exchange. As this is written as a C++ class (uart.cpp and uart.h), you'll be able to instantiate any number of objects, providing only the UART ports you are planning to use. For the Atmega128 this is extremely useful as this chip supports two UART gateways: uart0 (rx0/tx0) on pins PE0+PE1 and uart1 (rx1/tx1) on PD2+PD3. I hooked the GPS up to uart0, and for uart1 I connected an UART Bluetooth module. This proved extremely useful for debugging my code, while implementing this NMEA parser library, as there were many situations that required careful analysis of the algorithm and its results (string parsing, string cutting, etc). Connecting the Bluetooth module to the PC, a simple terminal application such as Putty can be used to visualize strings received from the microcontroller board:

With only two objects, we can handle both the GPS and the Bluetooth modules easy:

 
UART	uart0, // gps module
	uart1; // bluetooth module
//USART0 RX interrupt this code is executed when we recieve a character
ISR(USART0_RX_vect){
	volatile char c = UDR0; //Read the value out of the UART buffer
	nmea.fusedata(c);
}
 
//USART1 RX interrupt this code is executed when we recieve a character
ISR(USART1_RX_vect){
	volatile char c = UDR1; //Read the value out of the UART buffer
	if (c == '1') _delay_ms(10000); // pause execution when we send char '1' for debugging
}
// init serial link
uart0.Init(0,4800, true); //uart0: GPS
uart1.Init(1,9600, true); //uart1: Bluetooth
 

The serial data is assembled on the fly, without using any redundant buffers. When a sentence is complete (one that starts with $, ending in EOL), all processing is done on this temporary buffer that we've built: checksum computation, extracting sentence "words" (the CSV values), and so on.
When a new sentence is fully assembled using the fusedata function, the code calls parsedata. This function in turn, splits the sentences and interprets the data. Here is part of the parser function, handling both the $GPRMC NMEA sentence:

 
/* $GPGGA
	* $GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh
	* ex: $GPGGA,230600.501,4543.8895,N,02112.7238,E,1,03,3.3,96.7,M,39.0,M,,0000*6A,
	*
	* WORDS:
	*  1    = UTC of Position
	*  2    = Latitude
	*  3    = N or S
	*  4    = Longitude
	*  5    = E or W
	*  6    = GPS quality indicator (0=invalid; 1=GPS fix; 2=Diff. GPS fix)
	*  7    = Number of satellites in use [not those in view]
	*  8    = Horizontal dilution of position
	*  9    = Antenna altitude above/below mean sea level (geoid)
	*  10   = Meters  (Antenna height unit)
	*  11   = Geoidal separation (Diff. between WGS-84 earth ellipsoid and mean sea level.  
	*      -geoid is below WGS-84 ellipsoid)
	*  12   = Meters  (Units of geoidal separation)
	*  13   = Age in seconds since last update from diff. reference station
	*  14   = Diff. reference station ID#
	*  15   = Checksum
	*/
if (mstrcmp(tmp_words[0], "$GPGGA") == 0) {
	// Check GPS Fix: 0=no fix, 1=GPS fix, 2=Dif. GPS fix
	if (tmp_words[6][0] == '0') { 
		// clear data
		res_fLatitude = 0;
		res_fLongitude = 0;
		m_bFlagDataReady = false;
		return;
	}			
	// parse time
	res_nUTCHour = digit2dec(tmp_words[1][0]) * 10 + digit2dec(tmp_words[1][1]);
	res_nUTCMin = digit2dec(tmp_words[1][2]) * 10 + digit2dec(tmp_words[1][3]);
	res_nUTCSec = digit2dec(tmp_words[1][4]) * 10 + digit2dec(tmp_words[1][5]);
	// parse latitude and longitude in NMEA format
	res_fLatitude = string2float(tmp_words[2]);
	res_fLongitude = string2float(tmp_words[4]);
	// get decimal format
	if (tmp_words[3][0] == 'S') res_fLatitude  *= -1.0;
	if (tmp_words[5][0] == 'W') res_fLongitude *= -1.0;
	float degrees = trunc(res_fLatitude / 100.0f);
	float minutes = res_fLatitude - (degrees * 100.0f);
	res_fLatitude = degrees + minutes / 60.0f;
	degrees = trunc(res_fLongitude / 100.0f);
	minutes = res_fLongitude - (degrees * 100.0f);
	res_fLongitude = degrees + minutes / 60.0f;
 
	// parse number of satellites
	res_nSatellitesUsed = (int)string2float(tmp_words[7]);
 
	// parse altitude
	res_fAltitude = string2float(tmp_words[9]);
 
	// data ready
	m_bFlagDataReady = true;
}
 

See the entire code for a better understanding of the logic implied. After parsing, the data is sent to the LCD:

 
lcd.lcd_cursor_home();
if (nmea.isdataready()) {
	// use index to change display on every iteration: easy way to show more content on a small screen
	if (i%2 == 0) { // show latitude, number of sats, longitude, altitude
		lcd.lcd_string_format("%f SATs:%d    \n%f A:%dm    ", 
		 nmea.getLatitude(), nmea.getSatellites(),
 		 nmea.getLongitude(), (int)nmea.getAltitude());
	} else { //show speed, bearing, time and date
		lcd.lcd_string_format("S:%2.2f B:%2.2f    \n%02d:%02d %02d-%02d-%02d    ",
		 nmea.getSpeed(), nmea.getBearing(),
		 nmea.getHour(),nmea.getMinute(),
		 nmea.getDay(),nmea.getMonth(),nmea.getYear());
	}				 
} else {
	lcd.lcd_string("Waiting for GPS  \nfix. No Data.       ");
}
 

The code above uses an index (i) to show more content on the tiny 2x16 LCD. First we show latitude, number of satellites used, longitude and altitude (in meters) and on the next iteration we show speed, bearing UTC time and UTC date. As you can see we call isdataready() function first, to make sure we have a GPS fix and valid data.

Conversions

To represent the coordinates, NMEA uses DM.MM, (degrees, minutes, decimal minutes) followed by N or S for latitude, and E or W for longitude. Example sentence:
$GPRMC,230558.501,A,4543.8901,N,02112.7219,E,1.50,181.47,230213,,,A*66,
The GPS Library code converts latitude & longitude obtained from NMEA's GPGGA or GPRMC to decimal:

 
// parse latitude and longitude in NMEA format
res_fLatitude = string2float(tmp_words[3]);
res_fLongitude = string2float(tmp_words[5]);
// get decimal format
if (tmp_words[4][0] == 'S') res_fLatitude  *= -1.0;
if (tmp_words[6][0] == 'W') res_fLongitude *= -1.0;
float degrees = trunc(res_fLatitude / 100.0f);
float minutes = res_fLatitude - (degrees * 100.0f);
res_fLatitude = degrees + minutes / 60.0f;
degrees = trunc(res_fLongitude / 100.0f);
minutes = res_fLongitude - (degrees * 100.0f);
res_fLongitude = degrees + minutes / 60.0f;
 

Speed, as returned by GPRMC is in knots/hour. The knot (pronounced not) is a unit of speed equal to one nautical mile (1.852 km) per hour. So to get the speed in km/h we do:

 
res_fSpeed = string2float(tmp_words[7]);
res_fSpeed /= 1.852; // convert to km/h
 

The rest is straight forward, but in case you have any questions, feel free o use the comments form below.

Notes:
The LCD is connected using only three wires, using a shift register, as explained here. The pins used are visible in the code:

 
lcd.Init(&PORTC,PC0,	// data/rs
 &PORTC, PC1,	// clk
 &PORTC, PC2);  // lcd e
 

License

This library is free software, licensed under GPL v2; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
For other licensing options, feel free to contact me.

Code available here, and on Google Code here.

For the Android Controlled robot project, I've decided I'll be needing an LCD, to show various parameters and make debugging easier. In the end it will also be useful to show content to the user on various topics, like low battery, or GPS coordinates.

So, here is an improved version of the HD44780 LCD library code.

1. Classic 4Bit HD44780 code: using 6 wires to connect the LCD

To save a few pins, I've connected the LCD in 4 bit mode. We are only using D4,D5,D6 and D7. Also RS and E. So 6 pins are used on the microcontroller. The Atmega128 has plenty IO pins, still if you need to optimize, see the next paragraph, where I used a 74HC164 to serialize the LCD data and use only 3 pins.

To use the LCD you need to include the HD44780 library. Then call the init function:

 
	HD44780 lcd;
	// init LCD: RS, E, D4, D5, D6, D7
	lcd.lcd_init(&PORTA,PA6, &PORTA,PA7,
		&PORTA, PA5, &PORTA, PA4, &PORTA, PA3,&PORTA, PA2);
 

As you can see, you need to provide all LCD pins in the function call. This is a very easy way to go, and even allows you to create multiple LCD objects if you want to use more than one display at the same time.
The connections are as follows: RS - PA6, E - PA7, D4 - PA5, D5 - PA4, D6 - PA3, D7 - PA2, but you can change this to any other configuration.
Source code: atmega128_parallel_HD44780_LCD

2. Shift register 74HC164: using only 3 wires to connect to the HD44780 in 8bit mode

Running the LCD in 8 bit mode, means that we will use all the D0,D1,..D7, RS and E pins. That's a total of 10 wires/pins, and would mean a complete waste of IO pins on a regular microcontroller.
Using a shift register instead, we can cross the boundaries between the parallel and serial worlds. By doing so, it is easy to reduce wire counts, pin use and even help take load off of the cpu by being able to store their data.
For this example, I will used the 74HC164, a 8 bit, serial in parallel out, non latched, shift register.
To better understand this last sentence, here are a few additional details (source).
First, the name:
74 — places it as part of the 74xx logic family, and since its logic it cannot directly control very much current (16-20ma for the entire chip is common), for more current transistors can be used.
HC means its a high speed cmos device and a low power device that will run from 2 to 5 volts.
164 is the model number for this chip, more info is available here.
"8 bit"
A shift register is made up of flip flop circuits, a flip flop is 1 bit of memory, this one has 8 (or 1 byte of memory). Since it is memory, if you do not need to update the register you can just stop “talking” to it and it will remain in whatever state you left it, until you “talk” to it again or reset power.
"serial in parallel out"
This means the shift register takes serial data (received from a microcontroller, our atmega128 in this case) and places each bit on the correct output pin. This data processing model only requires 2 wires for total control (one for data, and one for clocking), so you can use 2 digital pins on the microcontroller, and break those 2 out to 8 more digital, parallel outputs.
This fits our purpose perfectly. We want to send the LCD data in a serial mode, using only a few wires, feed it to the 74HC164 that will provide the many parallel connections required by the HD44780.
"non latched"
As data enters a shift register via serial, it shows up on the first output pin, when a clock pulse enters in, the first bit shifts over 1 place, creating a scrolling effect on the outputs, for example 00000001 would show up on the outputs as 1, 01, 001, 0001, 00001, 000001, 0000001, 00000001 .
If your talking to other logic devices who are sharing the same clock and not expecting this, it could cause issues. Latched shift registers have an extra set of memory, so once the data is done entering the register you can flip a switch and show the outputs, but it adds another wire, software, and things to keep up with.

As explained above, it is possible to connect to the HD44780 using only 2 wires, but this complicates the code. To keep everything crystal clear, I opted for a 3 wire interface. One wire for the data, one for the LCD's E pin, and another one for the Clock. The wiring can be see below. 74HC164 Pin 14 is Vcc and is connected to 5V, Pin 7 to GND, and Pin 9 via a 10K pull up resistor to VCC.

Similar to the first paragraph, the code encapsulates the HD44780 functionality in a class, where the init function takes the ports and pins used to connect the device. This way you can hook up multiple LCD's to your microcontroller, if required by your application.

The last photo shows the three wires (gray, white, yellow) used to control the LCD. Now this sure saves a few pins, considering the LCD is connected in 8 bit mode!
The code is configured to use the following pins: RS/DATA - PA0, CLK - PA1, LCD E - PA2, but you can change it as you like.
Download the 3 Wires, 74HC164 code: atmega128_3Wire_74HC164_HD44780_LCD

A big thank you goes to the following articles:
The 74HC164 Shift Register and your Arduino using GD74HC164 microcontroller
AVR 3-Wire HD44780 LCD Interface (avr-gcc)
arduinoshiftreglcd

A total of 200 frames, taken at a 15minutes interval. The setup is simple:

And here is the Hyacinth, after the photo shooting session was over, with most of its flowers open. Beautiful, isn't it?

White mold microscope photos

Blue mold microscope photos

For more microscope pictures see this article.

My friend Kevin, contacted me for building an advanced autonomous companion robot. The final goal is to have to robot following its user. This is the construction log page, with more content added as the project moves on. As this project continues what I have shown in a previous article, you can see this post a a follow-up, named as Part2.

1. January 21, 2013

Kevin carefully prepared everything for the long trip, and the package with the hardware components got here today. For the new robot I will drop my previous Ara robotic rover platform, in favor of the neat A4WD1 from Lynxmotion. Essentially this is a similar differential control rover platform, using 4 geared motors of 200RPM 37mm diameter, one for each wheel (HN-GH12-2217).


Putting the rover together was easy except for the tires which required a little Vaseline. The robot's central processing unit will be an Atmega128 microcontroller and not the Lynxmotion's BASIC Atom Pro 28 Pin (which also requires the custom "bot board II"). Atmega128 wins here with its 128KB flash memory, 16MHz max operating frequency and a multitude of IO ports, while the Basic atom pro can only provide 32K of Program Space and a limited operating frequency (Not to mention the costs, Lynxmotion products are also very expensive).
The motors are to be driven via a Sabertooth 2X12 R/C Regenerative Dual Channel Motor Controller . I am yet to see how well this performs when compared to my simple H-Bridge that I used before. The battery is a generous 12V 2800mAh from Lynxmotion.

2. February 06, 2013

The rover's bottom is a thin black plexiglass sheet, that looks great but can't sustain much weight. In this case, the battery seemed a bit too heavy for the bottom sheet, especially considering high speed movements over rough terrain. So I had to build a battery holder using some steel. Hope I won't get to replace all the original rover by the end of this project . But this is what perfectionists usually do.


The steel support is placed longitudinally at the bottom, fixed in screws. This can be used to support other components as well, as I drilled multiple holes for that. Two U-shape holders have been fitted using rivets, this way I got no difference in level, and no sharp points to puncture the battery to be placed in this support:

The prominent ends have been leveled with a metal file. The U-shaped holders got some little plastic spacers, made from PVC plastic heated and bended in a convenient angle. With the battery in place, here is the first motor test:

3. February 12, 2013

The Atmega128 board got a power supply, for both 5V and 3V. The latter is for the Bluetooth module and one of the GPS modules.

The power supply consists of a high efficiency DC-DC converter built using the LM2596 IC. There are plenty of such converters available on Ebay for just a few bucks. I replaced the pot with a fixed 1KO resistor, so the converter would put out a fixed 5V voltage. The 3V is obtained using two L78L33 's. The power boards where fixed to the Atmega128 board.

4. February 18, 2013

New Atmega128 board, with pin connectors including power and gnd to make connections easier. The microcontroller board has been mounted to the robot's platform. The Sabertooth 2X12 has also been mounted. Thick wires link the h-bridge and the motors.

5. February 25, 2013

I finished the top board, exposing the bluetooth UART module and the NMEA GPS module. This will be mounted outside the robot's body, to make sure the modules get maximum radio signal. An LCD is to provide vital information such as battery levels and other diagnosis messages.

And with these last modules, I had to write a considerable amount of software. And this is only the beginning of the long road ahead:
- HD44780 LCD code . The LCD uses only 3 wires to connect to the Atmega128, using a shift register, 74HC164, to save a few IO pins.
- UART code, to handle data from the UART Bluetooth module and the UART GPS Module.
- GPS NMEA Parser, highly optimized to save memory and processing power. Also available on Google code, here.
And the first problems didn't wait too long to show up. It appears the bluetooth module's RF creates some kind of interference that reduces the GPS signal. As a result, having the Bluetooth module on, I can barely get a GPS fix. When the signal is good (8 satellites in use), turning the bluetooth module on will reduce the signal (3-4 satellites). Here is a demo to show this defect. The red jumper wire is used to power on/off the Bluetooth module. The "sats" value displayed on the LCD is the number of fixed satellites.

So to bypass the issue, I'll need to rework the top-board and move the Bluetooth module at some distance from the GPS module. I was not aware of such a design requirement.

6. March 27, 2013

The Sabertooth 2X12 R/C Regenerative Dual Channel Motor Controller needs to be hooked up to an UART port. On the microcontroller board I have no free UART port available, so to simplify I plan to use a dual H-Bridge built from scratch. You can see the Dual H-Bridge here.

Schematics and PCB available in the Dual H-Bridge article.

The LCD has been mounted inside the chassis, must admit it looks perfect this way: low profile, high tires, black paint, and that blue electric LCD light. All combined with a highly energetic movement.

7. March 28, 2013

Following the successful dual HBridge integration, I added the Bluetooth UART module, and wrote a software for Android OS, to allow me to control the robot by using the phone. Here's a demo video:

And a few pictures to show the final robot shape:

Next thing to do is to make the robot follow the user, AUTOMATICALLY! I'm currently considering two options, one involves using the GPS Module, send the coordinates via bluetooth to user's mobile phone that also has GPS and can then inform the robot where it needs to go, the second option would be to use some kind of beacons, the user would carry in his/her hand (or pocket), and the robot would detect those and follow the signal.

8. April 08, 2013

As I've shown above, the purpose of this robot is to follow its user, and I imagined two instruments for implementing that:

1) a global localization method, using GPS. The PROs are that we can place a GPS module on the robot, and the user can have a mobile phone with its own GPS module. The phone can establish a connection to the robot using Bluetooth, and send the user coordinates periodically. Then the robot can calculate the path it needs to run, to get in close proximity of the user, and follow him/her. Sounds good, but the CONs are bad: first, the GPS errors are too big to allow us to make the robot follow the user; it would rather jump like a crazy monkey all around the user, and this is the best scenario. Another issue is also the GPS signal which is poor or unavailable indoors.
If we place a stationary GPS receiver, here's how the GPS coordinates look like:

As you can see, despite the fact our GPS receiver is stationary, the localization data we receive has a tolerance of a few meters or even tens of meters, placing us on a disc surrounding the real position. This is inappropriate for the purpose of this work, so I have decided to find different means of robot positioning and orientation; this number -2- below:

2) The local method will use a closed system for localization, formed of only the robot itself, the user, and a signaling beacon. Normally the user will carry a signaling beacon (ultrasonic, infrared, radio, etc), which the robot will "see" and follow. Easy to say, doing it is of course much harder, as we need a smooth robot movement, so a lot of error compensation and fuzzy logic must be involved.
Recently I made some excellent progress using ultrasounds as a transmission method, to create a simple beacon detector. You can read more on it here.
The user needs to carry this tiny, low power ultrasonic beacon which the robot should be able to "hear" and use the signal to navigate to the target, and follow it.

These wonderful modules will not only return a signal when ultrasounds are detected, but the output amplitude is directly proportional with the actual distance to the beacon. So we'll know both where the beacon is, and how far.
Given these tools, there are several ways of implementing the working mechanism:
a) using a single ultrasonic receiver, placed in front of the robot: the rover will need to rotate until it detects a maximum level of signal. Then it should move forward until the detected signal reaches a given threshold (so it will not hit the user, but stop right before him/her). It doesn't really work well, as the software gets overcomplicated and the results are not as good as expected.
b) similar to a), but use a servo motor to rotate the ultrasonic sensor instead of rotating the entire robot. When the maximum signal is detected, the robot should turn towards the source, and begin moving forward . It still doesn't solve many of the issues found with a)
c) using two ultrasonic receivers, placed some space apart, in the frontal part of the rover. Now we can make differential measurements, so it's easy to know from which part is the signal coming from, as the corresponding sensor will have higher readings. The robot can now directly turn towards the beacon, and follow the forward direction while the two sensors give approximately similar readings. If the right sensor output increases, then it means the robot needs to turn right, to face the beacon and continue moving forward. Same case for left. A similar approach has been used in a project by Andrew Wiens :

d) using more than two sensors, ideally 8, placed at 45 degrees in a radial disposition. This would pinpoint the source more accurately, and reduce the time needed to find the beacon. Still, to simplify, I plan to go for the differential measurements presented at c) .

The ultrasonic sensors already return an output signal which is a function of the distance to the beacon / user. This can be used to measure the distance. If greater accuracy is required, we can involve infrared light in the process:
- the beacon sends a set of 38KHz modulated Infrared pulses marking moment of time t0
- the beacon immediately sends out the ultrasonic pulses
- the receiver which is a few meters from the beacon, receives the infrared pulses practically instantaneously and knows the time is t0 (using a TSOPXX38)
- the receiver registers the incoming ultrasonic pulses at the time t1, where t1>t0. By using the speed of sound in air, we can get the exact distance to the beacon.
All in one we use light to signal the start for counting, and we stop when the ultrasonic waves reach the destination.
More on this here, here or here.

9. April 09, 2013

Using the ultrasonic sensors differential readings (with sensors placed in front, at angles of aprox. 15 degrees of the longitudinal axis), I got some excellent results: the robot is able to follow me, and keep track of my speed, and orientation:

The algorithm compares the readings from the two sensors and decides whether to turn left (if left sensor return higher readings), right or to move forward (if the output of the two sensors is similar).
There are some remaining issues:
- if the robot approaches a wall, and the beacon signal is coming from the back, it will reflect in the wall and confuse the robot
- no detection capabilities for signal coming from any other direction, other than the front
To solve these issues, three more ultrasonic receiver boards are needed, namely one for back, and one for each of the sides. Also the movement is a bit shaky, and this can also be improved by changes in the robot's software code. More to follow soon.

I built some nice PCBs for the ultrasonic sensors, and provided more details on Detecting an ultrasonic beacon, here.

10. April 10, 2013

I built a total of 5 ultrasonic receivers, that are to be placed two in the front, one at the back and two on each side.

The idea is to have the robot turn around facing the ultrasonic signal, and then to make it follow the source using the two frontal sensors. The differential readings will help us decide whether to adjust the direction for left or right.
Using some PVC pipes, I built some nice and robust plastic enclosures, by heating and pressing the plastic to get the desired shapes:

The result looks great:

For some uber-coolness factor, I decided to add frontal white lights and back position red lights, controllable from the software (on/off). The frontal side now also houses a nice Sharp 2y0a infrared sensor, that will help avoid hitting any obstacles. So now the robot is capable to hear and see its surroundings. Love how it looks:

11. May 01, 2013

Time has come to build the TX ultrasonic beacon. This time I wanted to try something new, so here is my first PCB for SMD components:

It uses a NE556, dual timer, and is configured to emit short bursts of 40KHz pulses. You can see the circuit here:

Eagle file also available, beacon TX.
A case was also needed, to enclose the 9V battery as well, and make it comfortable for holding it in the hand. The final results looks like this:

12. May 03, 2013

This project finally comes to an end, so I recorded two demo videos to show the robot following me, outdoors. A few modifications in software are likely to be done, but all in one, the work is pretty much complete:
Demo 1:

Demo 2:

13. May 22, 2013

As I am a perfectionist with all that I build, I couldn't stay away and had to make this robot even better. So I did two things:
1) For the autonomous, human following software: I improved the ultrasonic detection algorithm, and the movement logic: Now the robot will follow its user more precisely, and the speed will vary with the detected signal: if the robots sees the user at a greater distance, will engage with a greater speed. If closer to the user, will proceed with smaller steps. The calculations are not linear, so I used some time to get the best formula. In the end I'm quite pleased, we can see some nice improvements when compared to previous two videos - so here are two new demos:
Demo 3:

Demo 4:

2) For the remote control software, where the user controls the robot using a phone, the rover now reports its frontal sensor readings (that show the proximity in centimeters to any detected obstacle), to the smartphone. So the movement commands go from phone to robot, and the sensor readings go the opposite way, from robot to phone. The Android software now allows the user to turn the lights on and off, and using the frontal distance sensor, a red line is drawn, showing the proximity to an obstacle. The robot can be controlled this way - without actually seeing what it is heading for, as this simple radar will be enough to get a clear path. Here is another demo:

3) When bluetooth is connected, the robot will ignore any ultrasonic signals from its beacon. So better separates the two modes of operation discussed above.

Resources:

Mechanisms for Combining Infrared and Ultrasound Signals for Indoor Wireless localization
Infrared / Ultrasonic beacon
Ultrasonic Source Localization
Mobile Robot Navigation
Learn about GPS
Robo-Dog on Hack A Day

01. January 31, 2013

Time interval: 18:11:08 - 18:17:07 (Bucharest timezone, GMT+2)
Atypical measurement: radiation level

Measure units: cpm (counts per minute, as related to Geiger tube SBM-19)
Measurement resolution: 1 minute
Max value recorded: 3781
Typical average value for the last 2 months: 81
Relevant Debug data:
T_RO:31.Jan.2013 18:10:09,T_UC:19:15:0,ID:1,VOL:400,DUTY:69,T1:9.50,T2:8.40,H2:73.70,L3:0,T4:8.00,P4:100401,CPM:70
T_RO:31.Jan.2013 18:11:08,T_UC:19:16:0,ID:1,VOL:399,DUTY:69,T1:9.50,T2:8.40,H2:74.20,L3:0,T4:8.00,P4:100401,CPM:2292
T_RO:31.Jan.2013 18:12:08,T_UC:19:17:0,ID:1,VOL:399,DUTY:69,T1:9.50,T2:8.40,H2:74.50,L3:0,T4:8.00,P4:100406,CPM:3781
T_RO:31.Jan.2013 18:13:07,T_UC:19:18:0,ID:1,VOL:401,DUTY:69,T1:9.50,T2:8.40,H2:74.40,L3:0,T4:8.00,P4:100408,CPM:3148
T_RO:31.Jan.2013 18:14:07,T_UC:19:19:0,ID:1,VOL:400,DUTY:69,T1:9.50,T2:8.40,H2:76.20,L3:0,T4:8.00,P4:100410,CPM:3027
T_RO:31.Jan.2013 18:15:07,T_UC:19:20:0,ID:1,VOL:400,DUTY:69,T1:9.50,T2:8.40,H2:75.50,L3:0,T4:8.00,P4:100414,CPM:3012
T_RO:31.Jan.2013 18:16:08,T_UC:19:21:0,ID:1,VOL:402,DUTY:71,T1:10.00,T2:8.40,H2:75.30,L3:0,T4:8.00,P4:100410,CPM:2997
T_RO:31.Jan.2013 18:17:07,T_UC:19:22:0,ID:1,VOL:399,DUTY:69,T1:10.00,T2:8.40,H2:76.60,L3:0,T4:8.00,P4:100409,CPM:264
T_RO:31.Jan.2013 18:18:07,T_UC:19:23:0,ID:1,VOL:399,DUTY:69,T1:10.00,T2:8.40,H2:75.40,L3:0,T4:8.00,P4:100414,CPM:90
Legend:
T_RO: Event timestamp, indicating real date and time in Timisoara, Romania
T_UC: internal uRADMonitor time
VOL: voltage on Geiger tube, SBM-19
DUTY: the duty cycle driving the 400V inverter in thousand percents
T1: measured temperature on sensor 1 (DS18B20) in degrees Celsius
T2: measured temperature on sensor 2 (DHT22) in degrees Celsius
H2: measured humidity on sensor 2 (DHT22) in relative nits
L3: measured luminosity on photodiode sensor 3 in relative units
T4: measured temperature on sensor 4 (BMP085) in degrees Celsius
P4: measured barometric pressure on sensor 4 (BMP085) in Pascals
CPM: measure radiation level on Geiger tube SBM-19, in counts per minute
Comments:
All system's parameters indicate the uRADMonitor is functioning in normal parameters.
The tube voltage is in normal parameters (400V +-5V).
All other measurements indicate typical values.
Persistence: none, radiation abnormal readings lasted for only 6 minutes, than the data gets back to normal/typical levels.
System malfunction probability: none / highly improbable.

02. February 08, 2013

Time interval: 00:26:43 - 00:33:42 (Bucharest timezone, GMT+2)
Atypical measurement: radiation level

Measure units: cpm (counts per minute, as related to Geiger tube SBM-19)
Measurement resolution: 1 minute
Max value recorded: 5175
Typical average value for the last 2 months: 81
Relevant Debug data:
T_RO:08.Feb.2013 00:25:43,T_UC:12:46:0,ID:1,VOL:400,DUTY:69,T1:4.50,T2:3.20,H2:91.90,L3:0,T4:3.00,P4:99285,CPM:81
T_RO:08.Feb.2013 00:26:43,T_UC:12:47:0,ID:1,VOL:400,DUTY:69,T1:4.50,T2:3.20,H2:91.90,L3:0,T4:3.00,P4:99295,CPM:3444
T_RO:08.Feb.2013 00:27:42,T_UC:12:48:0,ID:1,VOL:400,DUTY:69,T1:5.00,T2:3.30,H2:91.50,L3:0,T4:3.00,P4:99297,CPM:5175
T_RO:08.Feb.2013 00:28:42,T_UC:12:49:0,ID:1,VOL:400,DUTY:69,T1:4.50,T2:3.30,H2:92.00,L3:0,T4:3.00,P4:99291,CPM:4056
T_RO:08.Feb.2013 00:29:42,T_UC:12:50:0,ID:1,VOL:399,DUTY:69,T1:4.50,T2:3.40,H2:91.10,L3:0,T4:3.00,P4:99296,CPM:3868
T_RO:08.Feb.2013 00:30:42,T_UC:12:51:0,ID:1,VOL:399,DUTY:69,T1:4.50,T2:3.40,H2:90.60,L3:0,T4:3.00,P4:99307,CPM:3502
T_RO:08.Feb.2013 00:31:42,T_UC:12:52:0,ID:1,VOL:399,DUTY:69,T1:5.00,T2:3.40,H2:91.60,L3:0,T4:3.00,P4:99300,CPM:3354
T_RO:08.Feb.2013 00:32:42,T_UC:12:53:0,ID:1,VOL:400,DUTY:69,T1:4.50,T2:3.40,H2:92.30,L3:0,T4:3.00,P4:99295,CPM:3326
T_RO:08.Feb.2013 00:33:42,T_UC:12:54:0,ID:1,VOL:399,DUTY:69,T1:4.50,T2:3.40,H2:92.10,L3:0,T4:3.00,P4:99290,CPM:1955
T_RO:08.Feb.2013 00:34:42,T_UC:12:55:0,ID:1,VOL:399,DUTY:69,T1:4.50,T2:3.40,H2:91.20,L3:0,T4:3.00,P4:99318,CPM:86
Legend:see above.
Comments:
All system's parameters indicate the uRADMonitor is functioning in normal parameters.

03. February 15, 2013

Time interval: 21:52:44 - 21:57:44 (Bucharest timezone, GMT+2)
Atypical measurement: radiation level

Measure units: cpm (counts per minute, as related to Geiger tube SBM-19)
Measurement resolution: 1 minute
Max value recorded: 5849
Typical average value for the last 2 months: 81
Relevant Debug data:
T_RO:15.Feb.2013 21:51:44,T_UC:2:41:0,ID:1,VOL:399,DUTY:70,T1:8.00,T2:6.60,H2:99.90,L3:0,T4:6.00,P4:100607,CPM:89
T_RO:15.Feb.2013 21:52:44,T_UC:2:42:0,ID:1,VOL:399,DUTY:70,T1:8.00,T2:6.60,H2:99.90,L3:0,T4:6.00,P4:100591,CPM:3521
T_RO:15.Feb.2013 21:53:44,T_UC:2:43:0,ID:1,VOL:399,DUTY:70,T1:8.00,T2:6.60,H2:99.90,L3:0,T4:6.00,P4:100597,CPM:5849
T_RO:15.Feb.2013 21:54:44,T_UC:2:44:0,ID:1,VOL:399,DUTY:71,T1:8.00,T2:6.50,H2:99.90,L3:0,T4:6.00,P4:100577,CPM:5591
T_RO:15.Feb.2013 21:56:44,T_UC:2:46:0,ID:1,VOL:399,DUTY:70,T1:8.00,T2:6.50,H2:99.90,L3:0,T4:6.00,P4:100586,CPM:1927
T_RO:15.Feb.2013 21:57:44,T_UC:2:47:0,ID:1,VOL:399,DUTY:71,T1:8.00,T2:6.60,H2:99.90,L3:0,T4:6.00,P4:100571,CPM:72
Legend: see above.
Comments:
All system's parameters indicate the uRADMonitor is functioning in normal parameters.

04. February 19, 2013

Time interval: 00:57:20 - 00:58:20 (Bucharest timezone, GMT+2)
Atypical measurement: radiation level

Measure units: cpm (counts per minute, as related to Geiger tube SBM-19)
Measurement resolution: 1 minute
Max value recorded: 2875
Typical average value for the last 2 months: 81
Relevant Debug data:
T_RO:19.Feb.2013 00:56:20,T_UC:14:11:0,ID:1,VOL:376,DUTY:52,T1:4.00,T2:2.60,H2:85.10,L3:0,T4:2.00,P4:100628,CPM:72
T_RO:19.Feb.2013 00:57:20,T_UC:14:12:0,ID:1,VOL:382,DUTY:53,T1:4.00,T2:2.60,H2:86.40,L3:0,T4:2.00,P4:100612,CPM:2139
T_RO:19.Feb.2013 00:58:20,T_UC:14:13:0,ID:1,VOL:373,DUTY:52,T1:4.00,T2:2.60,H2:85.00,L3:0,T4:2.00,P4:100615,CPM:2875
T_RO:19.Feb.2013 00:59:20,T_UC:14:14:0,ID:1,VOL:364,DUTY:48,T1:4.00,T2:2.60,H2:85.50,L3:0,T4:2.00,P4:100611,CPM:83
Legend: see above.
Comments:
All system's parameters indicate the uRADMonitor is functioning in normal parameters. Tube is currently operating on 375V.

05. February 20, 2013

Time interval: 20:35:49 - 20:40:49 (Bucharest timezone, GMT+2)
Atypical measurement: radiation level

Measure units: cpm (counts per minute, as related to Geiger tube SBM-19)
Measurement resolution: 1 minute
Max value recorded: 3893
Typical average value for the last 2 months: 81
Relevant Debug data:
T_RO:20.Feb.2013 20:34:49,T_UC:7:38:0,ID:1,VOL:374,DUTY:50,T1:7.00,T2:5.60,H2:68.70,L3:0,T4:5.00,P4:100443,CPM:82
T_RO:20.Feb.2013 20:35:49,T_UC:7:39:0,ID:1,VOL:375,DUTY:50,T1:6.50,T2:5.60,H2:69.00,L3:0,T4:5.00,P4:100431,CPM:1205
T_RO:20.Feb.2013 20:36:49,T_UC:7:40:0,ID:1,VOL:378,DUTY:51,T1:7.00,T2:5.60,H2:69.40,L3:0,T4:5.00,P4:100441,CPM:3893
T_RO:20.Feb.2013 20:37:49,T_UC:7:41:0,ID:1,VOL:375,DUTY:50,T1:7.00,T2:5.60,H2:69.90,L3:0,T4:5.00,P4:100436,CPM:3321
T_RO:20.Feb.2013 20:38:49,T_UC:7:42:0,ID:1,VOL:375,DUTY:50,T1:7.00,T2:5.60,H2:70.40,L3:0,T4:5.00,P4:100440,CPM:3117
T_RO:20.Feb.2013 20:39:49,T_UC:7:43:0,ID:1,VOL:375,DUTY:50,T1:6.50,T2:5.60,H2:69.80,L3:0,T4:5.00,P4:100436,CPM:301
T_RO:20.Feb.2013 20:40:49,T_UC:7:44:0,ID:1,VOL:374,DUTY:50,T1:6.50,T2:5.70,H2:70.20,L3:0,T4:5.00,P4:100436,CPM:102
T_RO:20.Feb.2013 20:41:49,T_UC:7:45:0,ID:1,VOL:375,DUTY:50,T1:7.00,T2:5.60,H2:69.40,L3:0,T4:5.00,P4:100442,CPM:60
Legend: see above.
Comments:
All system's parameters indicate the uRADMonitor is functioning in normal parameters. Tube voltage has been reduced to 375V.

06. February 22, 2013

Time interval: 22:25:12 - 22:37:12 (Bucharest timezone, GMT+2)
Atypical measurement: radiation level

Measure units: cpm (counts per minute, as related to Geiger tube SBM-19)
Measurement resolution: 1 minute
Max value recorded: 4812
Typical average value for the last 2 months: 81
Relevant Debug data:
T_RO:22.Feb.2013 22:24:12,T_UC:9:29:0,ID:1,VOL:375,DUTY:56,T1:6.00,T2:4.30,H2:99.90,L3:0,T4:3.00,P4:99621,CPM:95
T_RO:22.Feb.2013 22:25:12,T_UC:9:30:0,ID:1,VOL:375,DUTY:56,T1:6.00,T2:4.30,H2:99.90,L3:0,T4:3.00,P4:99627,CPM:850
T_RO:22.Feb.2013 22:26:12,T_UC:9:31:0,ID:1,VOL:375,DUTY:56,T1:6.00,T2:4.40,H2:99.90,L3:0,T4:3.00,P4:99631,CPM:4812
T_RO:22.Feb.2013 22:27:12,T_UC:9:32:0,ID:1,VOL:375,DUTY:55,T1:6.00,T2:4.40,H2:99.90,L3:0,T4:3.00,P4:99635,CPM:3643
T_RO:22.Feb.2013 22:28:12,T_UC:9:33:0,ID:1,VOL:375,DUTY:55,T1:6.50,T2:4.40,H2:99.90,L3:0,T4:4.00,P4:99640,CPM:3337
T_RO:22.Feb.2013 22:29:12,T_UC:9:34:0,ID:1,VOL:375,DUTY:56,T1:6.50,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99629,CPM:3158
T_RO:22.Feb.2013 22:30:12,T_UC:9:35:0,ID:1,VOL:375,DUTY:55,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99624,CPM:3102
T_RO:22.Feb.2013 22:31:12,T_UC:9:36:0,ID:1,VOL:375,DUTY:56,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99629,CPM:3081
T_RO:22.Feb.2013 22:32:12,T_UC:9:37:0,ID:1,VOL:375,DUTY:56,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99630,CPM:3031
T_RO:22.Feb.2013 22:33:12,T_UC:9:38:0,ID:1,VOL:375,DUTY:55,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99623,CPM:3155
T_RO:22.Feb.2013 22:34:12,T_UC:9:39:0,ID:1,VOL:376,DUTY:56,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99620,CPM:3121
T_RO:22.Feb.2013 22:35:12,T_UC:9:40:0,ID:1,VOL:375,DUTY:55,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99624,CPM:3105
T_RO:22.Feb.2013 22:36:12,T_UC:9:41:0,ID:1,VOL:375,DUTY:56,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99624,CPM:3094
T_RO:22.Feb.2013 22:37:12,T_UC:9:42:0,ID:1,VOL:375,DUTY:56,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99629,CPM:2433
T_RO:22.Feb.2013 22:38:12,T_UC:9:43:0,ID:1,VOL:375,DUTY:55,T1:6.00,T2:4.50,H2:99.90,L3:0,T4:4.00,P4:99631,CPM:89
Legend: see above.
Comments:
All system's parameters indicate the uRADMonitor is functioning in normal parameters. Tube voltage has been set to 376V

Introduction

In part 1 of this article I have indicated three ways of injecting events on the Android platform:
Method 1: Using internal APIs, mainly relying on the WindowManager and the two APIs: injectPointerEvent and injectKeyEvent

Method 2: Using an instrumentation object

Method 3: Direct event injection to /dev/input/eventX

While the first two rely on the dreaded INJECT_EVENTS permission, available only to platform makers, and have suffered great changes in the last OS versions, the third method is at the moment of writing this article the best bet for properly injecting events on Android.

The /dev/input/eventX are event input nodes, part of the linux platform beneath Android. Normally their permissions are set so only the Owner and its Group can read and write from/top these files. There are no permissions set for Other, and there is where our code is situated, since it is not owner of the linux input event nodes, nor member of the Owner group:

So to be able to use method 3, and to directly interface to the input event nodes, we need to be able to alter the permissions, in order to set the Other permission bit to Read (if we want to intercept input event data) or Write (if we want to push events, as indicated in the article's title: Injecting events). The best way to go is to set the bit to allow +rw (read and write) , using the chmod native command:

Without root access, this fails, with "operation not permitted". So here is the point where we can only proceed if we are using a Rooted Android phone. Everything else shown in this article will work without root, but for changing the permissions we need root, and there's no way around it. A bit frustrating, considering we are talking about such a tiny information segment. More on linux filesystem permissions, here.

Once the input event nodes are set to allow both reading and writing, we can open them as regular files, and read the content or write our own content, to intercept events or inject our own keys or touch events. The format accepted by the input event node files is:

struct input_event {
    struct timeval time;
    unsigned short type;
    unsigned short code;
    unsigned int value;
};
/* type and code are values defined in linux/input.h. 
 * For example, type might be EV_REL for relative  moment of a mouse, 
 * or EV_KEY for a keypress, and code is the keycode, or REL_X or ABS_X for a mouse.
 * The linux/input.h is part of the Android NDK
 */

Make sure to read more on this topic, for a better understanding. A nice article is available on Linux Journal.

By popular demand on my two previous articles: Programmatically Injecting Events on Android – Part 1 and Android Overlay Mouse Cursor, but also to standardize method #3, I have developed a JNI library for Android, to take care of all these details to do what the standard API refuses to do: simple event injection for all your development needs. But it requires root, as explained previously.

The library, named "android-event-injector" is released as Open Source, under GPL, and available on Google code, here.

Android Event Injector functionality

This library uses JNI, and you will need to setup Android NDK if you want to change it or compile it. It uses a low level, native component, that completely handles the input event node interaction: discovering the files (ScanFiles), opening them (OpenDev), Closing/Removing allocated memory (RemoveDev) or getting event node details such as Path and Name. With an open Input Event Node, we can do polling (PollDev, getType, getCode, getValue) or event injection (intSendEvent). Via JNI, we are handling all this functionality in Java (Events.Java). This class builds multiple instances of the InputDevice class, that correspond to the number of discovered native input event nodes (the number of /dev/input/eventX files). When we open such a file, we use the API call Open(boolean forceOpen):

 
/**
* function Open : opens an input event node
* @param forceOpen will try to set permissions and then reopen if first open attempt fails
* @return true if input event node has been opened
*/
public boolean Open(boolean forceOpen) {
  int res = OpenDev(m_nId);
  // if opening fails, we might not have the correct permissions, try changing 660 to 666
  if (res != 0) {
    // possible only if we have root
    if(forceOpen && Shell.isSuAvailable()) { 
      // set new permissions
         Shell.runCommand("chmod 666 "+ m_szPath);
         // reopen
           res = OpenDev(m_nId);
       }
  }
  m_szName = getDevName(m_nId);
  m_bOpen = (res == 0);
  // debug
  Log.d(LT,  "Open:"+m_szPath+" Name:"+m_szName+" Result:"+m_bOpen);
  // done, return
  return m_bOpen;
}
 

As you can see, at this point we also use chmod to make sure our process can read and write the input event node (/dev/input/eventX file).

If we are successful in opening an event node, we can use it for listening for events (system touch events, key presses, etc), or for injecting events. The code on Google code, exemplifies all these:

Listening for incoming events

Here is a simple example on how to use my library, to create a thread that intercepts all system input events and shows them in logcat:

 
/**
* Starts our event monitor thread that does the data extraction via polling
* all data is displayed in the textview, as type-code-value, see input.h in the Android NDK for more details
* Monitor output is also sent to Logcat, so make sure you used that as well
*/
public void StartEventMonitor() {
m_bMonitorOn = true;
Thread b = new Thread(new Runnable() {
  public void run() {
    while (m_bMonitorOn) {
      for (InputDevice idev:events.m_Devs) {
        // Open more devices to see their messages
        if (idev.getOpen() && (0 == idev.getPollingEvent())) {
          final String line = idev.getName()+
              ":" + idev.getSuccessfulPollingType()+
              " " + idev.getSuccessfulPollingCode() + 
              " " + idev.getSuccessfulPollingValue();
          Log.d(LT, "Event:"+line);
          // update textview to show data
          //if (idev.getSuccessfulPollingValue() != 0)
          m_tvMonitor.post(new Runnable() {
            public void run() {
              m_tvMonitor.setText(line);
            }
          });
        }
      }
    }
  }
});
b.start();    
}  
 

This is very useful when you need to better understand the event structure and the involved values for type,code and value. Make sure you have a look on linux/input.h contents as well, inside your Android NDK folder.

Injecting events

Again, input.h is our friend, since it details the event codes we need to use. But you will also want to use the event monitor to be able to write down all the complex events sequence generated by the system when the user touches the screen. Here are a few wrapper functions to serve as a sample:
Home hardware key injection:

 
/**
* Finds an open device that has a name containing keypad. This probably is the event node associated with the keypad
* Its purpose is to handle all hardware Android buttons such as Back, Home, Volume, etc
* Key codes are defined in input.h (see NDK) , or use the Event Monitor to see keypad messages
* This function sends the HOME key 
*/
public void SendHomeKeyToKeypad() {
boolean found = false;
for (InputDevice idev:events.m_Devs) {
  //* Finds an open device that has a name containing keypad. This probably is the keypad associated event node
  if (idev.getOpen() && idev.getName().contains("keypad")) {
    idev.SendKey(102, true); // home key down
    idev.SendKey(102, false); // home key up
    found  = true; break;
  }
}
if (found == false)
  Toast.makeText(this, "Keypad not found.", Toast.LENGTH_SHORT).show();
} 
 

And another example, for injecting touch events:

//absolute coordinates, on my device they go up to 570x960
if (m_selectedDev!=-1)
   events.m_Devs.get(m_selectedDev).SendTouchDownAbs(155,183);
 

Don't forget to correctly use the Event input devices. When you open them, you also have access to the Device Name. Make sure you insert key events to the device named "keypad" or "keyboard" and not to the compass or other input devices if you want this to work. Also for touch events, make sure you insert your touches/click events to "touchpad" or "ts". The namings can be different from a device to another, or from a platform to another. Try to develop an algorithm to correctly identify your target before injecting input data.

Additional resources:

Programmatically Injecting Events on Android – Part 1
Android Overlay Mouse Cursor
The code is available on Google Code, under GPL. Use it only if you understand the terms of Open Source software distributed under GPL.
The library and a sample can be downloaded here or EventInjector

Being mostly used in RADAR technology, the radioactive elements have been added to increase the electronic response by improving the internal ionization processes.

The film shows the following tubes, in order: 11TN40, MA340, 313CD, JAN-8370, JAN-4C35, TG-77, EII-43-100, JAN-346B, 1B26, 1B22

11TN40

MA340F

313CD

JAN-8370

JAN-4C35

SIGNALITE TG-77

EII-43-100

JAN-346B

1B26

1B22

The soldering station can regulate temperature in precise discrete steps: 1 degree or 10 degrees per button push up/down, but it can also jump directly to predefined values: 200,300,400 degrees Celsius. There's also a Fahrenheit conversion button, but I don't really need that since we use Celsius here. The values are displayed on its big LCD, and all options are available by the use of large push buttons, making the operation easy and comfortable, allowing the user to focus on the target PCB.

The Soldering Iron is connected to the base via a flexible cable, and the holder is robust, avoiding any accidental burns due to unexpected overturns.

The tips are interchangeable, and I've located multiple providers with good price offers. Here's one. Changing the tip is easy, but nevertheless I expect the default one to last for a while.

Specs:
Power supply voltage: 110volt (110volt-130volt) /60Hz and 230volt (220volt-240volt) /50Hz
Electric iron Power: 48watt
Equipment power supply fuse:T1 A250volt(50x20mm glass pipe)
Regulating scope of temperature: 150-450
Temperature display:2*31/2grades LCD display, display interval:150-450
Display precision:5%
Allowed use humidity:+5-+40,relative humidity <85%
Atmospheric pressure:600hpa-1000hpa
Case size:210x125x135mm width/height/depth(Without electric iron)
Weight:about 1800grams

The spare parts:
Spare soldering iron
88-201A 24V 48W with temperature probe

Spare tip
79-1116 TIP N1-16 Hi quality
79-1126 TIP N1-26
79-1136 TIP N1-36
79-1146 TIP N1-46
79-1156 TIP N1-56

Spare heater
78-201A 24V 48W 88-201A with temperature probe

Sponge
79-7301 57x37mm

Christmas tree light installation with leds running on mains

Since it is Christmas which brings some free time, and my wife's favorite Christmas three light installation was broken, I decided to fix it using my new ZD 937. That included changing the original 24V bulbs (hard to find nowadays) to big white leds, running directly on mains (220V). I used this approach:

And mounted everything on a test board, making sure it would fit the original little plastic case connector , that came with this light installation:

After a quick test, everything was ready to go. A lovely result I would say, and nice to know this light installation won't be breaking again, nowhere soon at least, that's for sure.

Merry Christmas to all of you!

Short description

I started from scratch, designing a complete dosimeter unit around the Atmel Atmega8 microcontroller and a Russian Geiger Muller tube. Here you'll see the CTC-1 tube, for high gamma doses, but the dosimeter can be used with any other tubes such as SBM-20, LND-712 or more sensitive ones such as the SBM-19 or the pancake tube SI-14B. Changing the tube requires changing the software, to adjust the dose conversion calculation. This circuit can be used with almost any geiger tube, as even the inverter's output voltage driving the tube is adjustable in the software.
Here is a video showing a high count rate when using a Si12b tube and Am241 alpha emitter from a smoke detector:

Similar to my uRADMonitor, the micro-controller takes care of everything:
1. Generates a variable duty PWM signal using Timer1, to drive the 400V inverter needed to operate the Geiger tube; The inverter doesn't need a multiplier, as the ferrite's transformer secondary puts out exactly the amount required. The transformer is made on a A22 ferrite core, with 16 turns in the primary and 600 in the secondary.
2. Uses one ADC port to measure the inverter's voltage and adjust the PWM duty cycle for constant output (exactly 400V for stable operation)
3. Counts the time, using Timer0 so we can compute the dose
4. Uses interrupt INT0 to count the pulses produced by the Geiger tube
5. Drives a 2x16 LCD to output the results.
Some other circuits on the Internet come with improper 400V inverters (some people seem not to be able to design a proper inverter), they are redundant (using 555's and additional components, when the microcontroller can take care of EVERYTHING), use the wrong signal detection/counter circuit, or other small defects that result in wrong measurements. Not to mention the complicated aspect of computing dose in sieverts out of counts per minute.
Given all these wrong designs, my detector tries to fill in some of the gaps. So here is exactly what you need: a stable design, with several improvements made over time, all packed in this nice construction that you can easily replicate.

Some pictures

Before getting into the construction details, and the theory involved in my geiger counter, here are some pictures of my construction. I might use them later to point out critical aspects of the construction.

Building the Ferrite transformer

Building the case

Once again, I used PVC pipes as a good source of plastic sheets. Here is another case I built for this Geiger dosimeter:

And the result

Construction details

The circuit diagram can be seen here:

I had some issues with my first PCB that are now fixed. Here is the final PCB version:

Battery pack

Besides using an external power adapter, I added rechargeable batteries to this device so it can operate on independently. 4 AAA NiMH batteries have been packed together using my micro-spot capacitor welder, and inserted in the bottom part of the case.

Bluetooth Module and remote radiation monitor capabilities - optional

You might be familiar with the The CD V-717 that was designed for use in fallout monitoring stations. This detector has a removable bottom with a 25 foot extension cable. The detector element (ion-chamber) is mounted inside the removable bottom. This allows for the placement of the detector element outside of the shelter area while the metering section of the metering unit would remain inside of the shelter area connected to the detector with the 25 foot cable.
In a similar fashion remote operation is possible on my dosimeter, by using... Bluetooth. Hooked to the main microcontroller, there is an UART Bluetooth module packed with its 3.3V regulator. The software running on the atmega8, sends measured dose rate values, via UART (Rx/Tx) to the Bluetooth module.

By doing so, a mobile phone can be used to read the radiation data, from a remote location, without being exposed to what the dosimeter actually measures. Currently I wrote an application for Android phones, that can search nearby bluetooth modules, find the dosimeter, connect to it and display the dose rate, as received via the radio connection. Here is a demo video:

For the Android software, see the bottom of this article.

Showing the Dosimeter on TVR Timisoara

Thanks to Andrei Borosovici, I had the chance to discuss this topic on "Vezi ce-ti doresti" TV Show running on TVR Timisoara. Here is the 14.01.2013 recording, in Romanian:

More on Geiger Counters

Here is a list with must-read resources:
uRadMonitor - a Geiger counter radiation monitoring station (v3.3)
Centronic Geiger Muller tubes
A simple Geiger counter (v3.2)

License

This work is free software, licensed under GPL v2; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. For other licensing options, feel free to contact me.
License for using my work

HEX Firmware for the Atmega-8

STS-1 geiger tube: GMD_STS-1
SBM-19 geiger tube: GMD_SBM-19
For changing the firmware to make the dosimeter work with other Geiger tubes, contact me.

Source code and other resources

Eagle SCH and PCB: download
Dosimeter source code: The code is available on Google Code, under GPL. Use it only if you understand the terms of Open Source software distributed under GPL.
You can also download it here.
Optional, if UART Bluetooth module has been added to the dosimeter: Bluetooth Dosimeter Android Application

Here are some variants created by my readers

DREDD Dosimeter

Key features:
Pressure range: 300..1100hPa (+9000m ... -500m above sea level)
Supply voltage: 1.8..3.6V (Vdda) 1.62V..3.6V (Vddd)
Low power: 5uA at 1sample/sec in standard mode
Low noise: 0.06hPa (0.5m) in ultra low power mode ; 0.03hPa (0.25m) ultra high resolution mode
Operating temperature: operational in -40..+85°C, with full accuracy in 0..+65°C
Resolution of output data: 1Pa for pressure, 0.1°C for temperature
Complete datasheet here.

On Earth, standard atmospheric pressure is 101 325 Pa. Meteorological barometric pressure reports typically report atmospheric pressure in hectopascals. More here. The BMP085 returns the measured pressure in Pascals and the temperature in degrees Celsius.

The BMP085 is designed to be connected directly to a microcontroller via the i2c bus. The pressure and temperature data has to be compensated by the calibration data of the EPROM of the BMP085. Reading the calibration done must be done only once, before reading the pressure or temperature data:

 
void getcalibration() {
	uint8_t buff[2];
	memset(buff, 0, sizeof(buff));
	//ac1 = read16(BMP085_CAL_AC1);
	bmp085_readmem(BMP085_REGAC1, buff, 2);
	ac1 = ((int)buff[0] <<8 | ((int)buff[1]));
	bmp085_readmem(BMP085_REGAC2, buff, 2);
	ac2 = ((int)buff[0] <<8 | ((int)buff[1]));
	bmp085_readmem(BMP085_REGAC3, buff, 2);
	ac3 = ((int)buff[0] <<8 | ((int)buff[1]));
	bmp085_readmem(BMP085_REGAC4, buff, 2);
	ac4 = ((unsigned int)buff[0] <<8 | ((unsigned int)buff[1]));
	bmp085_readmem(BMP085_REGAC5, buff, 2);
	ac5 = ((unsigned int)buff[0] <<8 | ((unsigned int)buff[1]));
	bmp085_readmem(BMP085_REGAC6, buff, 2);
	ac6 = ((unsigned int)buff[0] <<8 | ((unsigned int)buff[1]));
	bmp085_readmem(BMP085_REGB1, buff, 2);
	b1 = ((int)buff[0] <<8 | ((int)buff[1]));
	bmp085_readmem(BMP085_REGB2, buff, 2);
	b2 = ((int)buff[0] <<8 | ((int)buff[1]));
	bmp085_readmem(BMP085_REGMB, buff, 2);
	mb = ((int)buff[0] <<8 | ((int)buff[1]));
	bmp085_readmem(BMP085_REGMC, buff, 2);
	mc = ((int)buff[0] <<8 | ((int)buff[1]));
	bmp085_readmem(BMP085_REGMD, buff, 2);
	md = ((int)buff[0] <<8 | ((int)buff[1]));
}
 

I used a BMP085 breakout board, that already has thee 4.7k pull-up resistor on the SDA and SCL pins.

Knowing the pressure it is possible to compute the altitude. A convenient alternative to GPS!

 
// we assume sea level pressure is 101325 Pa
float convertAltitude(int32_t pressure) {
	return ((1 - pow(pressure/(double)101325, 0.1903 )) / 0.0000225577);	
}
 

Here is the code, based on Davide Gironi's work on the BMP085, and the i2c interface originally developed by Peter Fleury.
BMP085

Specs:
Model RHT03
Power supply 3.3-6V DC
Output signal digital signal via MaxDetect 1-wire bus
Sensing element Polymer humidity capacitor
Operating range humidity 0-100%RH; temperature -40~80Celsius
Accuracy humidity +-2%RH(Max +-5%RH); temperature +-0.5Celsius
Resolution or sensitivity humidity 0.1%RH; temperature 0.1Celsius
Repeatability humidity +-1%RH; temperature +-0.2Celsius

Datasheet: here

Here are some variants created by my readers

Vanja's DHT22 board
DHT22 Eagle SCH

Source code:
DHT-22, Atmega8 with 16Mhz
DHT-22, Atmega8 with 8Mhz

The HC-SR04 is an Ultrasonic ranging module. It provides 2cm - 400cm non-contact measurement function, the ranging accuracy can reach to 3mm. The module includes the ultrasonic transmitter, receiver and control circuit.

The basic principle is:
(1) Using IO TRIG Pin, trigger for at least 10us high level signal ,
(2) The Module automatically sends eight 40 kHz and detect whether there is a return signal.
(3) If the ultrasonic signal returns, the time elapsed is used to compute distance, knowing the sound speed in air: Test distance = (high level time×velocity of sound (340M/S) / 2
Datasheet: available here.

Circuit diagram:

Here are some variants created by my readers

Glide built a nice PCB for this sonar. Here are his pics and the eagle files (SCH+PCB)

glide sonar eagle

Source code:
Sonar HC_SR04
Thanks to wzona. It comes with excellent details, make sure you check it out.

A few pics with the sonar used with a 5110 Nokia graphical LCD. Code for the LCD available here.

Introducere

Locuiesc in Timisoara. De curand am terminat o statie de monitorizare a fondului de radiatii, numita uRADMonitor. Statia e montata in exteriorul imobilului, si functioneaza la foc continuu, 24/7, pentru a masura variatii ale fondului de radiatii. Mai jos ofer acces public la datele colectate. Variatiile fondului vor putea fi urmarite sub forma de grafice. Debitul dozei ambientale corespunzator fondului natural de radiatii, conform masuratorilor, este de 0.12uSv/h. Acest debit al dozei ambientale poate sa varieze, fara un impact major asupra sanatatii. Media globala a debitului dozei datorat fondului natural de radiatii este de 0.27uSv/h. Stam mult mai bine decat media.

Pe langa nivelul debitului dozei datorat fondului natural de radiatii, am afisat date de temperatura, umiditate si luminozitate (cat de multa lumina ambientala exista), care se pot dovedi utile pentru cei interesti.

O scurta prezentare video

Ce sunt radiatiile ionizante?

Agentia nucleara si pentru deseuri radioactive din Romania, are un excelent ghid introductiv, care poate fi citit la sectiunea "Despre radioactivitate". Va recomand sa il lecturati pentru o mai buna intelegere a celor discutate aici.

De la inceput vreau sa clarific ca statia masoara radiatii ionizante, parte a fondului natural.
Radiatiile ionizante produc ionizari, procese electro-chimice in care substantele implicate sunt modificate. Raportate la corpul nostru, aceste procese pot fi nocive, pentru ca ionizarile pot provoca distrugeri la nivelul celulelor, inclusiv modificari ale lanturilor de ADN.
Dar asa a fost de cand e lumea, si ne-am adaptat conditiilor de pe Pamanat. In permanenta celulele afectate sunt reparate sau inlocuite.
O problema devine cresterea nivelului de radiatii peste limitele acceptate, cum se intampla in cazul accidentelor nucleare (Cernobal, Fukushima, etc). Daca corpul nostru e bombardat de o doza prea mare de radiatii , distrugerea cauzata poate fi ireversibila.
Pe langa proprietatile ionizante, unele tipuri de radiatii, cum sunt radiatiile gamma, sint radiatii puternic penetrante. Ele pot patrunde in interiorul corpului unam, putind in acest fel produce ionizari, nu doar la nivelul pielii ci si in interiorul corpului.

Radiatiile electromagnetice, cum sunt cele emise de antenele de telecomunicatii (telefonie, televiziune, radio), nu sunt ionizante. Nu exista date care sa lege expunerea la radiatiile electromagnetice de probleme de sanatate.

Radiatiile ultraviolete sunt ionizante, dar au putere de penetrare mica, energia lor fiind mica. Dar pot afecta pielea si ochii, si pot cauza boli grave cum e cancerul de piele sau distrugeri ale retinei.

Asadar pe aceasta pagina veti putea vizualiza nivelul radiatiilor in Timisoara, asa cum e masurat de statia pe care am construit-o. Datele sunt pur informative, si nu pot sa garantez acuratetea lor, proiectul fiind realizat in regim de amator, dar cu o pregatire rezonabila in fiecare din tehnologiile implicate.

De unde apare radiatia de fond?

Cu precadere din doua surse: cosmice si terestre.
Radiatia cosmica include ioni si nuclei grei proveniti din afara Sistemului Solar. Acestia ne bombardeaza direct, sau interactioneaza cu elemente din atmosfera pentru a produce jerbe de radiatii secundare: raze X, particule alpha, protoni, electroni, neutroni, etc. Compusi secundari se formeaza si prin transmutarea elementelor din atmosfera in radioizotopi sub influenta razelor cosmice, care la randul lor vor fi surse secundare de emisie.
Componenta de radiatie cosmica contine si particule expulzate de catre furtunile solare, particule neincarcate electric ce pot trece de centurile Van Allen.
Sursele terestre includ radioizotopii aflati in natura (elemente radioactive), cum sunt uraniul, toriul, dar si unii izotopi ai potasiului si carbonului. Elementele radioactive naturale, terestre, se dezintegreaza in timp, dezintegrari, care in final duc la elemente stabile, ne-radioactive. Uraniul 238 se dezintegreaza in Radiu 226, care la randul lui trece in Radon 222. Acesta din urma e un gaz care ajunge in atmosfera si la randul lui se dezintegreaza in alte elemente. Toate dezintegrarile se produc cu emisii de radiatii.

Exista si radiatia de fond produsa prin mijloace artificiale, adica produsa de om, care provine din teste nucleare (in special cele deasupra solului), arderea in cantitati mari a carbunelui care duce la concentrarea in cenusa a materialelor radioactive naturale (Uraniu, Toriu si Radon), industria chimica care introduce in circuitul natural aceleasi produse, prin prelucrarea materiei prime cu continut de U sau Th, eliberarea in atmosfrea de tritiu si C-14 de catre reactoarele nucleare in functionare normala sau accidente nucleare (Cernobal, Fukushima).

Toate aceste fenomene contribuie la fondul natural de radiatii.

Grafice in timp real, pentu Timisoara

Cu exceptia catorva institute din tara, care rar dau publice graficele privind fondul de radiatie, statia mea e probabil singura alternativa de acest gen, disponibila utilizatorului obisnuit.
Iata grafice realizate cu date culese in ultimele 7 zile, cu o integrare de 3 ore. Integrarea se refera la cumularea mai multor valori citite, intr-o valoare medie, pentru a observa mai usor si mai corect tendinta de evolutie. Graficele prezinta numele si unitatea de masura in partea de sus, si data, ora si valoarea, in partea de jos:
Atypical data has been logged here Variatiile atipice sunt centralizate aici

Grafice pe ultimele 30 de zile

Am introdus grafice pe ultimele 30 de zile. Sunt prea mari pentru a le introduce ca poza, asa ca va rog dati click pe linkurile de mai jos. Integrarea e calculata la 3 ore. Daca aveti nevoie de rezolutii mai fine, puteti sa-mi spuneti. Nu uitati, aparatul a fost pus in functiune in data de 20 Octombrie, la publicarea acestui articol nu existau inca 30 de zile de inregistrari.
Radiatia in Sievert/Ora
Radiatia in CPM (numar de pulsuri detectate/minut)
Temperatura in grade Celsius
Umiditatea relativa in procente
Luminozitatea relativa in procente la mie

Alte resurse

Pagina proiectului uRADMonitor e accesibila aici.
Detaliile de constructie, inclusiv schema electronica, pot fi accesate aici.
Pentru intrebari sau alte detalii, va stau la dispozitie, puteti folosi sectiunea de comentarii de mai jos.


Noiembrie 16, 2012
Am raspuns invitatiei lui Andrei Borosovici, si astfel am participat la emisiunea lui, pe TVR3 , unde am avut ocazia sa prezint, in linii mari, detalii din spatele acestui proiect:



Decembrie 7, 2012
Proiectul a facut atentia celor de la Hack a Day, unde a stat azi pe prima pagina. Articolul in engleza, poate fi citit aici.


For English, click here.

uRADMonitor demo video in English, "Invisible Enemy - Radiation":

There is also a Romanian version of the film, here.

Graphs built in real time with uRADMonitor data. Time is GMT+3 (Europe/Timisoara):

Atypical data has been logged here Variatiile atipice sunt centralizate aici

Background radiation


*** Note: The dose in uSv/h is only an estimation extrapolated from the CPM readings, based on geiger tube characteristics (SBM-19).
Temperature



Humidity

Barometric pressure


Sky luminosity

How uRADMonitor works

Several sensors, including a Geiger counter, are connected to a microcontroller (Atmega168). A network interface chip (enc28j60) provides an Ethernet interface. Data from sensors is collected on a one minute interval and exported online to the server (pocketmagic.net). Using PHP and SQL, the data is stored and post processed, so users connecting via a webbrowser can access various charts, in real time.

Data access

Currently I provide a simple interface to access the data collected by uRADMonitor #1, working in Timisoara, Romania. For server-side optimization reasons, the data is cached. Every time you access the data, you will receive charts not older than 2 minutes!
The data can be accessed as pre-generated charts, of variable parameters, via a HTTP-GET:

http://www.pocketmagic.net/uradmonitor/public.php?param=STRING&interval=VALUE&integration=VALUE&size=STRING&gmt=STRING_URL_ENCODED

param: usvh|cpm|temp1|temp2|humi|lumi identifies the data: usvh for radiation in micro sieverts per hour, cpm for radiation in counts per minute, temp1 for temperature sensor #1 (DS1820), temp2 for temperature sensor #2 (DHT-11), humi for humidity sensor (DHT-11), lumi for luminosity sensor
interval: the last number of days data to retrieve. The uRadMonitor #1, started gathering data on October 21, 2012
integration: the average interval in hours. For better observations of the natural background radiation level , you should use a value of 4 (hours).
size: small | medium | large | xlarge
gmt: the gmt for the time coordinates, url encoded (default is Europe/Bucharest)

Try the following examples:
Example 1. The Radiation data on the last 3 days (3x24hours) with an integration average of 4 hours (each point in the chart represents the average of 4 hours of sensors data), with a chart size of 1200x800 pixels, and time displayed with GMT corresponding to London, UK.

http://www.pocketmagic.net/uradmonitor/public.php?param=cpm&interval=3&integration=4&size=xlarge&gmt=Europe%2FLondon

Example 2. The temperature data on the last day (1x24hours) with an integration average of 1 hour1 (each point in the chart represents the average of 1 hour of sensors data), with a chart size of 400x250 pixels, and time displayed as US Eastern time.

http://www.pocketmagic.net/uradmonitor/public.php?param=temp1&interval=1&integration=1&size=medium&gmt=US%2FEastern

Raw data access, containing a huge collection of sensor data, with a 1minute time resolution is also available on request.

Measuring The Dose

Short Intro
If you've seen the above video, you know that radiation cannot be detected with our senses. This is why we had to develop tools to see what our eyes cannot.
A Geiger detector is a device that can sense the presence of ionizing radiation . It is composed of a sealed tube with two electrodes to which a potential difference is applied. A particle entering the tube will initiate a conductive channel between the two, by ionizing the medium inside. When this happens, we can count the pulse, with a counter connected to the tube. The conductive flow needs to be quenched, so the tube gets back to the initial status and it is ready to start detecting again. A special gas is added inside the tube, ex. halogens, that combine with the newly formed ions to neutralize them.

Counts per minute (CPM)
The number of pulses / time, gives us a new unit for describing the radiation, that we call DOSE. The simplest unit of measure is the CPM , meaning counts per minute. Some tubes are more sensitive than others, so two different tubes will show different CPM readings when placed to the same radioactive source. This means that the CPM value is tube dependent.

Non linear answer to energy
The Geiger tube's sensitivity can change relative to the incoming radiation's energy. Most tubes show a linear response only above 150keV. This means that a weak source of radiation, of energy below 150keV, will produce false readings on an uncalibrated tube, showing a bigger dose than there actually is. This type of calibration is called "energy response compensation" and it implies placing a thin metal shield, to reduce the intensity of low energy particles. This shield will not interfere with higher energy particles that will pass unaffected, so we can successfully apply the compensation only to the interval of interest, by choosing the shield's geometry (covering the tube partially or completely) or by choosing its thickness.

Can we compute the Equivalent dose from CPMs?
The CPMs uRADMonitor calculates, are an indication of how much energy is ceded by the radiation to the geiger tube. We call this "the absorbed dose", and it is measured in Gy/h.
Assuming a tube is compensated for energy response, then there is a linear correspondence between CPMs and Gy/h. This function is usually presented in the tube's datasheet in regards to various isotopes such as Co-60 or Cs-137.
If the tube is not compensated, it will express a higher sensibility mostly for energies below 150keV. We say that the tube's answer to energy is non-linear:

The context for what we do here is extremely important: remember that uRADMonitor measures background radiation. This background is composed of cosmic radiation, of very high energy, and three main terrestrial components of background gammas that are K-40 1462 keV, Bi-214 1760 keV from the U decay series, and Tl-206 from the Th decay series. Smaller contributions to total background come from Pb-212 239 keV, Bi-209 609 keV, Tl-208 908 keV and Bi-214 1120 keV. The most serious non-linearity of energy response in uncompensated GM tubes occurs below 150 keV - and most of that below 100 keV - so none of the background emissions listed above will be seriously affected, nor will the majority of cosmic rays.
The most seriously affected - and, in many ways, the most interesting - part of the background gamma spectrum that will fall within the GM tube's most non-linear energy response region is skyshine - the radiation scattered by the air above both natural and man-made sources like particle accelerators, reactors, and high-level waste dumps. Most skyshine falls below 500 keV, and most of that below 100 keV.
So this means that CPM to Gray/hr conversions, using manufacturers data based on either Cs-137 or Co-60 will not be too inaccurate to be of use across the natural background gamma spectrum. An integration period of four hours should be used for reliable gamma background assessment. (Thanks to Proud Mary, 4HV.org)
Moving from Gy/h to Sv/h is possible due to the Radiation weighting factor, which , for gamma radiation (the main constituent of the background radiation), is 1. 1Sv = 1Gy for gamma.
Bottom line is, that for the restricted case of having the uRADMonitor measure only the small doses involved in the background radiation field, and considering the above mentioned isotopes only, we would computed the dose in Sv/h within a reasonable tolerance. uRADMonitor is not intended as a general purpose Dozimeter.

Resources

Skyshine Contribution to Gamma Ray Background
Background as a Residual Radioactivity Criterion for Decommissioning
On the Interpretation of the Diurnal Variation of Cosmic Rays
Centronic Geiger Muller tubes

Indications of commercial dosimeters at the same location

Updates:

I constantly improve this device by adding new sensors or changing the software. Updates can be tracked on the construction page, here.


November 30, 2012:
With uRadMonitor's impact on the local press, I got an invitation to a TV show, where I had the chance to discuss some of the details behind the project. Here is a recording of the transmission on TVR3 (national TV), from 16.11.2012, in Romanian:



December 7, 2012
I'm proud to announce this Project is my second work to be featured on HackAday.

December 8, 2012
First snow is here.

January 31, 2013

uRADMonitor has been functioning continuously for the last 3 months. I have created a page to present all major atypical variations, that are not caused by technical issues or malfunctions. The page is available here.

February 16, 2013
The recent atypical measurements raised a few questions on the nature of the events: malfunction of the detector (specifically the Geiger Tube due to age) or a legitimate manifestation of a radiation phenomenon.
Some bits of additional info, even if redundant, should share some light on the Geiger detector, as used in the uRADMonitor system. For a start, here is the current circuit diagram:

The R7 10M anode resistor is a quality component, mounted correctly without fingerprints, dust or humidity. Should this resistor malfunction in any way, one result could be avalanche discharges in the Geiger tube. This resistor has been checked recently and it meets the requirements.
Resistor R5 is used in a voltage divider , by the microcontroller to continuously measure the voltage across the Geiger tube, using one of its ADC (analog to digital) ports. In just a few words, for 400V set on the tube, the voltage divider will return 3.96V ( 400V x 47/(4700+47) ). The micro-controller is set to use a relative voltage of 5V (Vref). The ADC port that measures the tube voltage, has a resolution of 10bits, so for a maximum of 5V on PC3/ADC3, the software would read the max value of 2^10 = 1024. For 4V we would get the proportional value. By doing so, the measurement of the anode voltage is extremely precise.
Should the voltage on tube be lower than the preset threshold (400V), the duty cycle factor of the inverter's PWM is increased, in small steps, until we reach the target voltage (in a given tolerance, initially set to 5V and now changed to 2V). If the voltage on the tube is too high, we do the opposite and decrease the duty factor. In a few words, this is a known regularization mechanism that works well, fact confirmed by the logs, showing several months of constant voltage tube values.
Some time ago, there was an issue with R5: After some use, it "burned" and got interrupted. As a result, the voltage measurement could no longer be done, and the software saw the voltage on tube as being 0. As a result, the duty cycle began to rise, resulting in uncontrolled high voltage generation, way above the tube's safety limits. Luckily, this high voltage also resulted in microcontroller temporarily failure, and so the PWM generation stopped . This in turn, also stopped the dangerous voltage from being applied to the tube (except for the first few miliseconds). R5 has been replaced with a better quality resistor.
I was recommended the following useful resources:
1. An investigation into the causes of short lifetimes of geiger-muller tubes used in aircraft oil gauging systems
2. Test Procedure for Geiger-Mueller Radiation Detectors
3. Geiger Mueller Counting
This valuable resources are a must-read, proving their utility especially for understanding failure causes that can result in avalanche discharges and erroneous readings . Because of the recent atypical radiation measurements recorded by uRADMonitor, I need to evaluate every possibility including a malfunction of the tube.
Test Procedure for Geiger-Mueller Radiation Detectors (2), proposes a 15% slope as the cut off between good and bad tubes: "In general, the value of the slope must be less than 15 % to consider that the detector is in good conditions." This seems to be a very large figure when you think of really good new GM tubes having plateau slopes of less than 3%.
I ran a few measurements with the current setup. SBM-19's operation interval is 350-475V. For my particular tube, I got unsatisfactory readings for 350V, but good performance in the 375-450V interval, despite its age.
The measurements has been performed during several hours, to acquire sufficient data for computing average values.
Voltage on tube / CPM (with natural background radiation)
349.33 / 65.88
375.64 / 78.62
399.65 / 79.98
424.71 / 80.18
449.51 / 79.68
Complete measurement details in attached PDF document: sbm_19
To test the tube's performance indicator as presented in "Test Procedure for Geiger-Mueller Radiation Detectors",
I set N1 = 78.62 , V1 = 375.64V , N2 = 79.68 and V2 = 449.51V
For P = 100 * ((N2 - N1)/(V2-V1)) * (100 / ( (N1+N2) / 2)) we get: 1.81060853% a lot lower than the 15% limit proposed in the paper.
The device has been set to 375V (in software), as compared to 400V used from October 2012 until now.

Pentru limba romana, click aici.

Progress summary:
2012-05-25, Geiger Dosimeter (video)

Digital Geiger Dosimeter:
2012-09-02, Digital Geiger Dosimeter
2012-09-11, Update on Atmega8 Timers and Counters
2012-09-15, Update on Issues with Timer1
2012-09-16, 400V Inverter Instability Issues fixed
2012-10-11, Some enc28j60 remarks
2012-10-12, Atmega168 up and running, first online beta test open
2012-10-18, Sensor board ready; Signal Capacitor (C7) comparison
2012-10-19, Device enclosure box ready
2012-10-20, The results
2012-11-11, Updates

May 25, 2012 - Geiger Dosimeter 3.2

Here's a video featuring version 3.2 of my geiger counter circuit, tested with several tubes:

I did some additional changes to my v2.0 simple geiger clicker, to improve it even further. See below the new 3.2 circuit diagram followed by some explanations. The ExpressSCH circuit diagram is here.

1. The High voltage supply
The goal is to have a counter working at 3V (2xAA batteries) with very little power consumption. This excludes using 555 timers or other fancy ICs. My choice is a feedback based one transistor oscillator. It provides 400V output, for 100mA at 3V.
I am using a ferrite core transformer, 17 turns for primary and 17 for the feedback coil, with 0.2mm CuEm wire. The secondary has 550turns with 0.1mm. The oscillator is operating at a frequency of aprox. 23KHz.

The transformer's output is rectified and multiplied by the 3 stages multiplier (10nF 1KV capacitors / BYV26E fast diode).
2. The voltage regulator
The geiger tube requires very precise voltages to operate. For this setup, I need to get 400V from this supply, regardless of variations in the input voltage (weak batteries, etc).
This task is achieved by the string of Zeners and the Q2 transistor. When the voltage produced by the multiplier exceeds the Zener threshold , the Q2 transistor opens, and pull down the base of Q1, stopping the oscillation. By doing so, the output voltage remains at a constant level, that equals the Zener threshold. The multiplier must produce a little more than the voltage that triggers the zener string.
3. Connecting the Geiger tube
An essential component is the Anode resistor (10M in my circuit). The resistor's minimum value, for any given tube, is specified in the datasheet, but it is a good practice to use a higher value where possible.
The anode resistor is responsible of the following:
- reduces the anode voltage when the tube is conducting. This allows the tube to recover after the discharge. Without this, the tube would conduct continuously and would be destroyed quickly.
- it limits the current flowing through the tube, leading to longer tube life
- it has an effect on the plateau length, a lower value of R1 gives a shorter plateau length [1]

For the pulse signal, there are two connection options:

Anode signal connection This type of connecting is not preferred: - at switch on, a high voltage transient will be fed to the measuring circuit, resulting in additional protection requirements. - noise in high voltage rail, will be fed to the measuring circuit via R3.

Cathode signal connection Centronics' "Geiger tube theory" recommends using the cathode connection whenever possible [1]. R2/R1 should be 1/45, taking into account a large value for R1 as explained above (eg. 10M).

4. Measuring circuits
With the cathode connection, the measuring circuit's task will be to count and evaluate the positive pulses connected at the cathode resistor R2.
For the circuit v3.2, we will collect the signal, in point A, at the emitter of transistor Q4. Here is how the pulses look like:

I was able to successfully connect it to my CD4026 digital counter , as seen in the video. It works great as a counter showing the individual pulses.

The final setup for v3.2:

References
[1] CENTRONIC , Geiger Muller Tubes, link

September 2, 2012 - Digital Geiger Dosimeter v3.3

For this update, my goal is to go digital. I need to use a microcontroller to take care of everything: regulated high voltage invertor using PWM and ADC voltage feedback, a timer to count seconds, a counter for tube pulses, and finally an Ethernet interface to export data via a network.
The result will be an Internet connected Geiger Counter, collecting various data and provided graphs over large periods of time.
I am planning to use the Atmega8 microcontroller, and push the little program space to its limits.
The Ethernet part is complete, and has been presented here: Atmega8 and enc28J60 for Ethernet support.
...
A few hours later, I got a timer and a counter working on the Atmega8, so now I can measure time and also count the pulses coming from the tube . This gives us the dose measured in cpm, sweet first results!

All's left to do is to integrate the HV supply to the uC's circuit, using a simple PWM driver with feedback.

September 11, 2012 - Atmega8 Timers and Counters

I did some progress on the HV inverter needed for the tube. I will have to stick to 400V . The project will be boxed and placed on a remote location outside. From there it will collect data and build various graphs. I have the geiger couter , a temperature sensor, a humidity sensor and a light intensity one. If anyone has other ideas on additional hardware that I should pack in, now it's the right time to say it.

A future project might be having a geiger counter dosimeter with multiple tubes, etc, and a nice LCD display to output the data. Or even some kind of "lab-tool" for testing the tubes.

Multiple pulses happen, and would be good to measure them correctly. This is called discrimination. The following pics show a few such pulses, as recorded with the oscilloscope:

A little update on my progress. I managed to put the microcontroller software together. As I am using an ATMega8, I opted for the following:
- INT0 interrupt to count all incoming pulses on raising edge. I do not have any discriminator yet.
- T0 timer to count passing time. I configured it to generate 1.024ms events, so 976 such events will count for a second.
- T1 timer to generate PWM signal. I got it to accept variable frequency and duty factor. I will probably go for 40KHz to drive a little 2n2222 transistor that pumps the primary of a small ferrite core transformer:

I noticed that without any protection, I will get voltage spikes in the microcontroller circuit, measured at PB1, where the PWM signal is provided (spike backs from the ferrite transformer, most likely). So a fast diode, used as snubber was needed across the primary of the small ferrite transformer . See the following images, first without and second with protection:

I still have some issues:
1. I almost used all the program memory available for the atmega8 and still need to code some additional routines. I might be forced to move to a more capable uC. I'll try to optimize and reduce code before I have to do anything like that.
2. There's some interference, between the timer1 PWM, with the ISP interface that handles the Ethernet module:

Because of that, the microcontroller hangs at some times. This is extremely annoying considering I need to have this project as a remote box running for large periods of time.
Some of the factors that are causing this:
- bigger duty cycle (timer1's PWM)
- some delays in the software's main loop
- reading ADC ports : I need to read them for sensors, and for checking the inverter voltage. The inverter produces roughly 400V when powered on. The voltage is read using one ADC port. If the voltage is less then required, the duty cycle is increased. If the voltage is bigger then the target set, the duty cycle is decreased.

I will find the cause of this eventually. As it is now, the software opens a TCP/IP socket on port 80 where it exposes some HTML content. So it is a small WEB Server, where you can see some details such as number of times it was accessed, pings received, time since startup, number of counts, CPM, and the dose in uSv/h , estimated for the SBM-19 tube.
Instead of this functionality, which I needed only for testing, the final software needs to work as a client, not a server. After computing all the sensor data locally (including the radiation dose), it will send it online, to a script running on my webpage. So instead of opening a port and waiting for incoming connections, the idea is to have it open a connecting to my server and export the data there. Easy. I believe the timing issues that currently lock my uC from time to time, will be resolved, as having an ongoing connection instead of keeping a port open is better.

Here's a photo showing the software run on a test board, with a LCD hooked up for showing the dose in uSv/h

September 15, 2012: v3.3.100 - Issues with Timer1

I decided to set numbers for these updates to help organize it better. So this is 3.3.100.
I've been working on the inverter. It seems I'll be able to have it run in a very wide range of values. This is thanks to a new ferrite core transformer that I made: A22 ferite core (it is really small, 1cm diameter), 16 turns primary with 0.2mm wire, and 600 turns secondary with 0.1mm wire. It is driven by a PN2222A generic transistor, using the 5V rail.
The output is fully rectified using 4 fast diodes set in a bridge. No multiplier required!

I made some tests with various frequencies. Here are some results, yellow/CH1 is at the PB1 pin, while cyan/CH2 is the inverter output:

40KHZ, duty:16% 396V, duty:35% 792V

20KHz, duty:10% 396V, duty:15% 616V

10KHz, duty:1% 200V, duty:16% 768V

I will probably choose a 20KHz frequency to set it out of the audible spectrum. The driving signal seems a little distorted, as I am still getting some spike backs from the ferrite transformer. I should fix this as well.

I'm still having issues when using the enc28J60 code together with the Timer1 PWM code. So either I have the Ethernet interface, either I have the PWM signal for the HV inverter. Sometimes it works, but not very stable. Here is the current circuit diagram, version 3.3.100:

I got some interesting results, and good news on the same time. Using a 8x prescalling when setting the Timer1 PWM, seems to allow the code to work together with the enc28j60, as expected. So this seems a good starting point, too bad I don't know the exact cause of these issues. Code for enc28j60 is rather complex , already.

September 16, 2012 - v3.3.101 - 400V Inverter Instability Issues fixed

I finally fixed the instability problems, the network module / PWM interference, and most of the issues I've mentioned before.
The problem was improper filtering in two key points:
1. The inverter's driver needed a little protection from those spike backs. For this I used two resistors at the inverter's driver base , and a little choke between the transformer's primary and the positive rail. This solved the spike backs, CH1/yellow at PB1, CH2/cyan inverter output:

Notice the PWM waveform still seems a little shaky at the top.
2. Voltage regulators (5V and the 3.3V), needed a few electrolytic caps

Now the PWM looks much better (have a quick look to the previous oscilloscope screens), and the circuit performs as expected, seems like the Ethernet module was greatly influenced by all the variations and improper filtering.
Here is the new schematic, v3.3.101:

This works great, finally! I am able to adjust the duty cycle and get perfectly regulated high voltage needed for the geiger tube. The voltage feedback reading with ADC will be used to adjust the duty cycle automatically: increase it if voltage is less than 400V (or any other target voltage), or decrease it to lower the output voltage, if more than 400V is being generated.
Compared to V3.2, the ripple is almost zero! See the two photos below:

The first, shows my version 3.2 inverter output, that uses a NPN oscillating transistor in an Armstrong oscillator, and a feedback mechanism constructed with zenner diodes set for 400V, that triggers an oscillator-blocking second transistor. Illustrated as trace for CH1 - yellow, set for 400V.
The second shows the output in 3.3, fully rectified and produced by a a precisely calculated PWM signal. See the CH2, cyan trace, set for 350V. That was only for testing, as the feedback mechanism now sets the voltage for 400V.

October 11, 2012 - Some enc28j60 remarks

For now just a few observations:
The ENC28J60 will work without the 74LS125N buffer just fine, assuming you don't have other devices connected over SPI. This simplifies things a bit. I also did minor changes on the ENC28J60 code and now the stability is much improved. Can be seen here.
Now a bigger problem is that I've consumed most of ATmega8's flash memory, and still need to do some additional programing. This forces me to move one step higher , to the Atmega168 microcontroller, featuring 16KB of flash memory, instead of ATmega8's 8KB.
Still , it will be possible to use the Atmega8 for a standalone dosimeter, with 1 tube, LCD screen, and built in high voltage power supply. But not if we want the ENC28J60 ethernet interface, like for this project.

October 12, 2012 - Atmega168 up and running, first online beta test open

Some news. Got the new little board up an running, featuring an Atmega168 micocontroller instead of the original Atmega8, because the TCP/IP stack was already consuming 7KB of our Atmega8's 8KB total flash memory. Besides the network stack, I need to drive the HV inverter, check the HV value for regularization, count the time and the pulses, do some logic on those values, and so on... additional programming that would not fit in the Atmega8.

What should have been a simple task, since the 168 has the same pin layout like the Atmega8, ended up as a mess, wasting two days of my time. I will structure the findings and indicate the critical issues, in case others will walk this path.

In the end, it works... not yet in the final form, as I need to build charts and store the data, add sensors, and lots of bells and whistles, BUT, here is how it looks like:

The software computes a CPM value based on a 5seconds time constant and displays the corresponding Sieverts/Hour dose in regards to the SBM-19 Geiger tube characteristics.

The board is currently up and running for a stability test, and can be accessed over the internet, here (edit: test ended). Give it a run, and let me know what you think!

Issues migrating from Atmega8 to Atmega168:
1. Atmega168 will not work with enc28J60, unless you use PB2 for CS. Atmega8 did not have this issue, which cost me two days to figure out. If PB2 is not used, the Atmega168 will hang in enc28j60Init, when doing the first enc28j60WriteOp, because the waitspi(); never gets to finish.
2. Keep the code inside interrupt callbacks light: the T0 interrupt was computing some time related values, but also reading the ADC port for voltage regularization. This crashed my uC until I moved the ADC reading code to the main loop.
3. Keep the strings to a minimum, since the RAM is extremely limited. Buffer overflows are hard to debug on a microcontroller. So are the other memory related issues. Double check, triple check or rewrite the code differently.
...

After 2 hours the device is still running with good stability. The absolute CPM given by my background radiation is 90 cpm . A very raw conversion to uSv/h, based on SBM-19 characteristics, would give us 0.18uSv/h.

After 15hours of continuous use, the device is still functioning well. Here is another snapshot of the web interface. What's interesting is the absolute CPM, has dropped significantly. I wonder why.

Here is the setup so far:

Circuit diagram, v3.3.103

The signal is processed by a small preamplifier, with the two transistors 2n5551 and BC558, resulting in a positive pulse of 50-100uSec and 5V amplitude, that is fed to the microcontroller's interrupt INT0 pin: PD2.
Source code:
3.3.103, available on request
...
After 42Hours it is still up and running, so I would say stability has been proven for this circuit, and I will stop this test here:

...
Update October 14, 2012
Some news: I managed to successfully initiate a Tcp/ip connection from the Geiger counter to a PHP script on this blog. It's late now, but I have everything in place to start exporting data.

October 18, 2012 - Sensor board ready; Signal Capacitor (C7) comparison

I've completed the sensor board:

Sensors and microcontroller software are working together. This project was full of obstacles, almost every single step came with bugs and issues, but eventually my determination prevailed.
Finally , here's the data received on my server, comments added after #
id=1 #this is a simple id, in case I will build more of these devices
cip=192.168.2.153 #the local device IP obtained by DHCP - no network config required!
vol=400 #the voltage on tube
duty=74 #7.4% inverter's duty cycle responsible of the 400V produced - used in regularization
pulses=2463 #number of pulses counted since start up
s1t=22 #ds1820 sensor, this is temperature in degrees celsius
s2t=24 #dht11 sensor, temperature in degrees celsius
s2h=75 #dht11 sensor, relative humidity
s3l=19 #photodiode sensor, luminosity
td=0 #number of days since start up
th=0 #number of hours since startup
tm=16 #numer of minutes since startup
ts=41 #seconds from startup
cpm=72 #CPM for the last 5 seconds , just for debugging purposes
Note:absolute CPM would be 2463 / 16.6 ->148 cpm . a bit high I'd say
...
pulses=4166
th=0
tm=38
ts=11
absolute CPM after 38minutes: 109.63 cpm , it is getting closer to expected dose rate.
...
pulses=6323
th=1
tm=4
ts=1
absolute CPM after 1hour: 98cpm

Thanks to Stella on 4HV.org, I've changed the C7 Capacitor (see diagram 3.3.103) to a smaller value. As Stella kindly explained, "The larger the capacitor, the slower will be the rise and fall times of the pulse. I would have expected to see a capacitor of 20 - 100 pF here ", while I've used a huge 20nF capacitor!
This is now changed to a 33pF capacitor, and here is a comparison chart showing the pulse shape/length with three capacitors, while the tube is exposed to natural radiation, to a Am241 source, and to a Cs137 source:

The modification will show in the next circuit diagram update.

October 19, 2012 - Device enclosure box ready

Box is ready, completely made of PVC pipe plastic, after transforming a piece of pipe into a sheet and cutting it when heated:


I also created sockets, from the same plastic source, for the geiger tube:

The orange plastic is great, the finished box actually gives the impression of a very good quality plastic / case! Funny considering what materials I've used.

October 20, 2012 - The results

Final software adjustments have been made. A new SQL database has been configured on pocketmagic.net to receive the data from the online dosimeter. Box has been closed and sealed, then mounted outside my home. Drilling a hole in the outside wall allowed me to install the power and Ethernet cables.

Circuit diagram, v3.3.120:

Source code:
3.3.120, available on request

3.3.110 2:07 PM 10/23/2012
SERVER/php:
- final data export script: public.php . deleted clones
- standardization of export script parameters
- fixed interval: last value shown is last present value
- caching implemented and set to 2 min interval
- fixed bug with displaying last hour in chart
CLIENT/atmega168:
- s2 bug fix, for invalid >100 values
- luminosity computed in percents 0..1000
- time calculation fixed, g_nTimeMilis >= 960
- added isp external connector

November 11, 2012 - Updates

3.3.121 12:51 PM 10/28/2012
SERVER:
- added subdomain uradmonitor.pocketmagic.net
- fixed server downtime chart calculations: missing data time zones are skipped - the graph will simply jump to the next data available.
- added uSv/h
todo: add offline text if no fresh (>5min) data available
- 3 digits added to values. back to 2 digits.
- added redicted in pocketmagic.net/uradmonitor to uradmonitor.pocketmagic.net
- limits set on the PHP script parameters: 30 for interval and 24 for integration

3.3.122 2:18 PM 11/02/2012
SERVER:
- debug now shows duty cycle too.
CLIENT:
- changed the R5 resistor , as the original burned out (poor chinese quality)
- recalibrated the inverter voltage feedback, by measuring the new R5 value.
- placed safety limits for upper duty cycle percent interval: the burned R5 caused a voltage increase up to 800V!! No other components were harmed.

3.3.130 2:14 PM 11/11/2012
SERVER:
- added new graphs: pressure (bmp085) and temperature 3 (bmp085)
CLIENT:
- dht11 sensor replaced with dht22
- bmp085 sensor added
- new sensor PCB board
- new sensor board sun shield
- additional code for the new sensor and i2c bus connectivity
- atmega168 replaced with atmega328p
Photos of 3.3.130 update:



Circuit diagram 3.3.130



3.3.131 6:28PM 12/10/2012
SERVER:
CLIENT:
- time computing code updated
- dht22 issues below 0 degrees, because of issues in CRC computation
Source code: available on request

DS18B20 - digital temperature sensor

My previous article on the DS18B20, focused on getting only the positive temperature values out of this sensor's Scratchpad. For a better approach the 12 bit data needs to be interpreted correctly, with the most significant bit as the sign bit. This leaves us with 11 bits for the integer temperature part , and 4 bits for the decimal.
A few bitwise operations, and a little bit level surgery, gets the job done.

 
// first 12bits represent the integer temperature
// the last 4bits represent the fractional temperature
// I I I I I I I I I I I I F F F F
//Store temperature integer digits and decimal digits
uint16_t integer_bits = temp >> 4,
		fractional_bits = temp & 0xF;
int negative = 0;
if (integer_bits & 0x800) negative = 1; //the 12th digit is one, representing a negative number
 

Here's a direct conversion using the float data type:

 
float therm_read_temperature() {
	//Reset, skip ROM and start temperature conversion
	therm_reset();
	therm_write_byte(THERM_CMD_SKIPROM);
	therm_write_byte(THERM_CMD_CONVERTTEMP);
	//Wait until conversion is complete
	while(!therm_read_bit());
	//Reset, skip ROM and send command to read Scratchpad
	therm_reset();
	therm_write_byte(THERM_CMD_SKIPROM);
	therm_write_byte(THERM_CMD_RSCRATCHPAD);
	uint8_t l = therm_read_byte();
	uint8_t h = therm_read_byte();
	therm_reset();
	float temp = ( ( h << 8 ) + l )*0.0625;
	return temp;
}				
 

The DS18B20 can do much more than this . See the complete datasheet, here.

DHT11 - cheap digital temperature and humidity sensor

This Temperature & Humidity Sensor features a temperature & humidity sensor complex with a calibrated digital signal output. It includes a resistive-type humidity measurement component and an NTC temperature measurement component, and connects to a high-performance 8-bit microcontroller, offering excellent quality, fast response, anti-interference ability and cost-effectiveness. Datasheet here.
This sensor returns sequences of 5bytes representing the humidity integer value, the temperature, and a checksum. To get the values correctly, precise timing at the 40uS scale is required.

 
// READ OUTPUT - 40 BITS => 5 BYTES or TIMEOUT
for (int i=0; i<40; i++)
{
	loopCnt = 10000;
	while(!(DHT11_PIN&(1<<DHT11_DQ)))
		if (loopCnt-- == 0) return DHTLIB_ERROR_TIMEOUT;
 
	unsigned long t = micros();
 
	loopCnt = 10000;
	while((DHT11_PIN&(1<<DHT11_DQ))) //high
		if (loopCnt-- == 0) return DHTLIB_ERROR_TIMEOUT;
 
	if ((micros() - t) > 40) bits[idx] |= (1 << cnt);
	if (cnt == 0)   // next byte?
	{
		cnt = 7;    // restart at MSB
		idx++;      // next byte!
	}
	else cnt--;
}
 
// WRITE TO RIGHT VARS
// as bits[1] and bits[3] are always zero they are omitted 
*humidity    = bits[0];
*temp = bits[2];
 
uint8_t sum = bits[0] + bits[2];
 
if (bits[4] != sum) return DHTLIB_ERROR_CHECKSUM;
return DHTLIB_OK;
 

Schematics:

Source code:
I have designed the code for an Atmega8 microcontroller. The code is available here.

Project summary:
2012-09-26, Introduction
2012-09-28, First test
2013-04-06, The wooden case

September 26, 2012

My first target is the GU-81M VTTC, which I'll show in this article. Here is Vasil's original circuit diagram:

I got all the precious components , including the tube, caps, a mot, diodes, even the primary and the secondary coils!

So here is what I did:

1. The secondary: The coil has been added a few extra turns, so I had to find a way to improve the insulation. I opted for epoxy, with some extra quantity added over the soldering:

2. Grid leakage resistor (R1) new PCB board - 20 x 27Ohm 10W resistors in series, for a total of 540Ohm:

3. Supply filter cap (C3) 6x polypropylene caps 6nF/1600V in series:

September 28, 2012

Got it ready for a first test. Unfortunately it didn't work - yet . I probably made a mistake when connecting the feedback coil.

April 6, 2013

The wooden case is complete.

Lime soda glass window, S-11 type photocatode; 11 dynodes coated with CsSb. 14 pin, B14B base. Intended for scintillation counter applications.
EMI/US, North Hollywood, CA, USA, known manufacturer.

Datasheet:

Links:

http://www.radiomuseum.org/tubes/tube_9524b.html

Features and specs:

Model: Galen 3 (?)
Manufacture year: ?
Style: Inclined Binocular
Serial #: 31-74-26
Eyepiece: Wide Field 10X
Nosepiece: Quadruple
Focusing: Coaxial coarse & fine adjustment
Stage: Graduated mechanical stage
Objectives: 4x, 10x, 40x, 100x (oil): A4/0.10 160/-, A10/0.25 160/-, A40/0.65 160/0.17, A100/1.25 160/0.17 (oil)
Substage: Abbe Condenser 1.25 N.A. with rack & pinion
Light Source: Variable intensity control 6v 20w
Power input: 110V
This unit also features phase contrast accessory however the objectives, while a set of B&L matched objectives, are not optimized for phase contrast. Abbe condenser, iris diaphragm and variable intensity quartz lamp. Mechanical stage that is tight and works perfectly. The binocular head has dual diopter adjustments. A few interesting details here and here.

Simple mod for 220V power input

As I got this unit from the USA, it was designed for 110V outlets. I had to change it to take 220V. In it's original form, it came with a 110V / 6V transformer, a voltage adjustable regulator, and a 6V/20W halogen bulb.


I only changed the bulb, for a 12V 20W one, and the power plug for 220V European outlets. Powering the unit at 220V will double the transformer's output, in this case 12V. This is a bit hard for the transformer, but it works good. I just need to be careful when adjusting the light to maximum level, as this makes the transformer heat up in a matter of minutes. I might change this electronic setup later.

First micro photographs

This microscope doesn't have a digital camera adapter, as explained above. But taking pictures via the eyepiece is not that hard. Having my camera set on manual settings (including the focus) did a decent job:
Onion skin cells
The cells of an onion skin are generally rectangular in shape and range in size from 0.25 to 0.4 millimeters in length (250-400 micrometers):

White mold formed on grapes

Live spider (no spider was hurt in the process, but it was hard to focus the little moving guy)

I will post other microphotos from time to time.

Progress summary:
2012-07-30, First setup, using a buffer
2012-10-11, A simpler variant with no buffers
2012-11-03, Another simple webserver

July 30, 2012

My Atmega8 will use an external crystal, and run at 16MHz. It is connected to a 5V supply. The enc28J60 requires 3.3V. The two chips must communicate using the SPI interface.

I found the original project posted on tuxgraphics . The solution is a good starting point, but it has lots of issues like: no buffering between the microcontroller and the Ethernet chip, microcontroller takes CLK signals from the Ethernet chip, not being able to run at various values, not a chance at 16MHz as I need it.

There are numerous reports of issues caused by the voltage difference in the SPI link. I have decided to use a buffer, as indicated by Mirek, from Poland, here. He also sells ready made Ethernet boards that are extremely well built and will save you considerable time for such a project.

The buffer chip is SN74LS125A. For the Ethernet chip I purchased a simple board from Ebay, featuring the enc28J60 chip, the 25MHz crystal, the magnetic ethernet connector, and a few other components:

When the 3.3V are applied and the network cable is connected, the two leds green and yellow should turn on from time to time. I bought two, and both refused to show any led activity. The boards were dead. Looking carefully I've noticed the crystals are soldered improperly and were shorting a few paths of the circuit. Correcting this, solved the problem and the boards were ready for use.
Here is the circuit diagram for these boards:

The connector exposes CLKOUT, INT, WOL, SO, SI, SCK, CS, RESET, VCC and GND. I'm currently using only INT,SO,SI,SCK,CS, VCC and GND. The board takes 3.3V so make sure you use a regulator.

Here is how to connect the Ethernet board to the SN74LS125AN buffer. Only INT and SO need to be buffered:

Now you are ready to connect it to the Atmega8. SO goes to MISO, SI to MOSI, SCK to SCK, I have connected CS to PB2(SS/OC1B) and INT to PD2 (INT0).

The software

The software I've prepared for this article, comes with a minimalistic TCP/IP stack supporting IP, ARP, UDP and TCP, based on the original work of Guido Socher and released under GPL V2 license.
I made it as a simple webserver, to open TCP port 80, so you can connect with your browser but you need to provide a few parameters: http://microcontroller_ip/?cmd=1 . In my sample I've used http://192.168.2.24/?cmd=1 , but you'll need to change the code for a new IP that matches your network settings.

The firmware replies to PINGs which are counted and displayed on the LCD and on the Atmega webpage. The webpage shows the number of times it has been accessed.

Source code:
ATMegaEth

Update: October 11, 2012

For a simpler variant, you can skip the buffer and just connect the ENC28J60 module directly to the Atmega8. It will work well, especially if you don't have other devices connected via SPI.

Here is the software to get this running. It comes as a small WEBSERVER, configured as 192.168.2.24 in code, and supports a DS18B20 temperature sensor connected to the PC4 pin, as well as a DHT-11 temperature and humidity sensor, to show the temperature via the web interface:
ATmega8_ENC28J60_NOBUFFER_TEMP_WEBSERVER
The problem is the ENC28J60's mini TCP/IP stack uses a lot of the Atmega8's available flash memory. Aprox.6-7K out of 8K available. This leaves very little room for additional logic.

More on temperature sensors here.

Update: November 03, 2012

Here is the very basic webserver implementation, featuring only the Ethernet interface, and the minimum software, that runs a local webserver. IP is configured as 192.168.2.24, so take that into account when building your own.
Circuit diagram:

I tested this on my testboard, nothing fancy:

It works great, here are some images with pings and the web page it exposes:

The code is available here:
webserver_atmega8

We can draw the cursor at the framebuffer level, and while this provides optimum performance, it requires special privileges that regular apps don't have.
The second approach , and the subject of this article, is drawing a cursor using an Overlay.

What is an overlay? The SDK defines them as: "Window type: system overlay windows, which need to be displayed on top of everything else. These windows must not take input focus, or they will interfere with the keyguard. " So what we are about to do is have a small view created, make it show a cursor image, and move it around. To make things easier, I created a special service class, since the code that displays a cursor would probably be a service , running in the background, and accepting cursor position updates. Sample application You can download the sample application here. You can use the code in free or non commercial applications.