Search This Blog

Tuesday, March 27, 2012

New layout

After way too much time with the same layout, finally and in sync with Blogger restructuring and connection to Google+, I present you with a bit of a nicer look, which is at least is clearer for reading. Stay tuned, as some new posts are on the pipe, with updates on various topics, such as:
  • Geiger Counter - full schematics and firmware source code will soon be posted;
  • Time Lapse Photography - some new scenes of nature at its best will soon be made available.

Saturday, March 24, 2012

Simulation mode for the Geiger Counter




While obtaining samples of materials radioactive above background is not an easy task (fortunately for the sake of human health), I had to find a way of testing the dose measurement algorithm in a different way. As I have explained in a previous post, the device is divided in two modules: a UI module, and the detector device. Each has its own digital logic, and communicate with each other through an I2C bus. As such creating a simulation mode would be a simple mather of programming a new function in the detector that would allow randomly spaced pulses to be generated, instead of being triggered by the Geiger tube. This have been done simply by using the Atmel standard libraries random() function. Using the interrupt generated by the watchdog timer overflow, the following code is executed periodically:


ISR(WDT_vect) {
int i;

disable_wdie();

if(current_time.value < MAX_SHORT)
current_time.value++;
else
current_time.value = 0;

if(simul_mode) {
new_event = (random() % 2 == 0);

if(new_event) {
if(rad_count.value < 0xFFFF)
rad_count.value++;
else
rad_count.value = 0;

for(i = 0; i < 3; i++) {
cbi(PORTB, PB1);
_delay_us(570);
sbi(PORTB, PB1);
_delay_us(570);
}

new_event = 0;
}
}

enable_wdie();
}


Basically it checks if simulation mode is enabled, in this case getting a new random value every 16 millisseconds. Depending on the value being divisible by 2 or not, a pulse is produced, and just like in normal operation, the event counter is increased. As such on the UI module, these are treated just like real events.

Simulation mode can be enabled or disabled just by writing commands via I2C. The current status (simulation or real mode) can be read by reading the corresponding register through the I2C bus as well.

As such the firmware on the UI module was modified to include this as a new menu function.

The video below demonstrates the new function in operation.



A tone sequence is now triggered during bootup to test the audio amplifier and provide the user an indication of the current volume level.

Saturday, March 10, 2012

More in Time Lapse

And to add to the party, another bit of playing around with time lapse. This time zoomed in on the Tagus river, and obtained this interesting sequence. To achieve it, the intervalometer was set to take a picture every 10 seconds. Again, automatic settings such as ISO sensitivity and aperture were chosen. Only the focusing was kept manual.

Sunday, March 4, 2012

The timelapse intervalometer - the technology behind the device



With the results having been posted in a previous post, it is now time to flesh through the details that led to the creation of this simple yet useful device.

I started with the optimism that my Fujifilm S9600 camera would have some form of remote control possibillity other than the mechanical shutter release that is supported in the shutter button itself. Obviously I wanted something electronic, easy to interface with a programmable device such as a microcontroller. By doing some web surfing, I found that someone had hacked the original RR-80 remote, which connects to the camera mini-USB connector, and managed to do other things such as triggering via IR (http://www.trafficshaper.com/RR-80/RR-80.html). While this was not the scope of my project, the
detailed pictures allowed me to understand how the remote control would operate.

It is 100% passive, having just three resistors and a special push button that just like in the digital camera (and some auto-focus analog cameras), when half pressed it triggers the focusing and when fully pressed triggers the shutter. As such the button has two independent circuits, and is of the normally open type. A schematic of the circuit is described by the following diagram:



This is pretty simple, and I found that it could be easily interfaced with a microcontroller using just a pair of bipolar transistors to do the switching.

I wanted to do it as simple and with the fewest components as possible, in order to make it an efficient and cheap device. As such I selected a pretty cheap microcontroller, the PIC12F683.
While not being the cheapest of all, it is very affordable, and yet powerful enough for a variety of uses. More than enough for an intervalometer.

I had however the problem of how to interface with the device, and tell it what interval setting I would want in each shooting session. As it had only 8 pins, from which only 6 available for GPIOs, I was quite limited in options. From the six available pins, I knew that 2 would be required for the camera interfacing, one for a push button to activate the triggering, and one for a status LED. This would leave me with 2 pins for the interval selection mechanism I would adopt. I could use some encoder switch, but the firmware would be a bit complex, and it would not retain the position after cycling the power (unless it would be stored in EEPROM). Another approach which seemed interesting, and one that I had seen from previous designs, was to use a 12 position rotary switch with a resistive divider. It would work a kind of like a potentiometer, but with discrete steps. As the PIC had an ADC, recognizing different steps would be a simple matter of adjusting the expected range of values in the firmware. Piece of cake! And this way we would have 12 distinct modes to select from.

At the end I came up with the following design:



The selected transistors were a couple of 2N2222, enough for the low current necessary for the interface in the camera side. A 9 volt battery would suffice for a few tens of hours of operation. Without much optimization I obtained an average of 8 mA of consumption.

The finished device ended up fitted into a box that once belonged to an ADSL filter:



The veroboard assembled circuit, featuring an 9 Volt battery as the power source:



Bill of materials:


  • 1 x PIC12F683;
  • 1 x 78L05 linear regulator;
  • 2 x 2N2222 bipolar NPN transistor;
  • 1 x 3 mm green LED (active);
  • 1 x 3 mm red LED (focus);
  • 1 x 330 nF capacitor;
  • 1 x 10 nF capacitor;
  • 1 x 0.1 uF 10V capacitor;
  • 1 x 10K 1/4 W resistor;
  • 4 x 1K 1/4 W resistors;
  • 1 x 100K 1/4 W resistor;
  • 1 x 12K 1/4 W resistor;
  • 1 x 39K 1/4 W resistor;
  • 1 x 82K 1/4 W resistor;
  • 11 x 470 Ohm 1/4 W resistors;
  • 1 x single circuit 12 position rotary switch;
  • 1 x push button (normally open type);
  • 1 x lever switch SPST;
  • 1 x MicroUSB male connector;
  • 1 x 9V battery receptacle;
  • 1 x female DC connector (for external power supply);
  • 1 x Veroboard;
  • 1 meter of 2 conductor cable (for camera power and USB connector);
  • 1 x plastic case to contain the circuit and battery.


In my assembled version, the DC connector and power cable were added, so that both the camera and the intervalometer could be powered from the same supply. In this case I used a 2 Amp 5 Volt power supply from a Sony PSP, which suited just fine. In order not to damage the linear regulator with reverse voltages, the DC connector was put in parallel with the input. Given that this input is 5 Volts, there is a drop to approximately 3.5 Volts at the regulator output. Still this has proven to be enough to power the PIC and remaining electronics without issues.

In a final post about this subject I will provide some info about how the firmware was written. I can mention that the first stable version of MPLAB X was used together with the Hi-tech C compiler for PIC 12 MPU's.