Small Arduino Project

[Michael Nicholls]

Hi Guys,

Have a personal project that I would like to complete and was
wondering if anyone else was interested or had any experience.

My Dad has a Nikon SLR camera and a tripod and I have been telling him
that I shall try to build a remote for him since it would be a lot
cheaper and a lot more fun. This was before I discovered Arduino, but
now the project should be a whole lot simpler. At one time I think I
found a web page with all the timings, but will need to dig that out.

I was wondering if anyone had any experience with this, but also would
anyone else be interested in working on it. I was thinking of
prototyping on a standard Arduino board, but would ultimately like to
condense it down into a keyfob. Not exactly sure what would be the
best way to do this.

Maybe even somehow include support for other cameras/timings in the
future?

Cheers,
Mike

[Ade]

Hi Mike

Im not sure about cheaper (as they run at about £14) but certainly a
lot more fun

I think maybe the page you are thinking of is http://wordpress.bolanski.com/?p=9

I have an Arduino but havent done too much with it, so Id look forward
to learning a little more

Ade

2009/7/6 Michael Nicholls <nicho...@googlemail.com>:

[Michael Nicholls]

Hi Ade,

I didn't realise they were that cheap, but I am really in it for the
fun ;-)

Thanks for the link. I had a similar link for a Nikon camera, although
the project didn't use Arduino. So I just need to get the timings from
that other page and I should be able to build something that works
reasonably quickly.

I presume I would just need some resistors and a IR led?

Will order a board and grab an led.

Cheers,
Mike

On Jul 6, 3:12 pm, Ade <adrian.brads...@gmail.com> wrote:
> Hi Mike
>
> Im not sure about cheaper (as they run at about £14) but certainly a
> lot more fun
>

> I think maybe the page you are thinking of ishttp://wordpress.bolanski.com/?p=9

>
> I have an Arduino but havent done too much with it, so Id look forward
> to learning a little more
>
> Ade
>

> 2009/7/6 Michael Nicholls <nicholls...@googlemail.com>:

[nikki]

NYCResistor posted something about arduino-controlled time-lapse
photography a while ago:
http://www.nycresistor.com/2009/06/07/time-lapse-video-how-to/
There might be something in there that's useful to you.

I recently bought and assembled a RBBB from Modern Device
http://moderndevice.com/RBBB_revB.shtml

They're significantly cheaper than the pre-made Arduinos from
Tinker.it or equivalent and could possibly point the way to something
key fob sized.

nikki



On Jul 6, 3:25 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

[Ade]

2009/7/6 Michael Nicholls <nicho...@googlemail.com>:

>
> Hi Ade,
>
> I didn't realise they were that cheap, but I am really in it for the
> fun ;-)

Yup, I got mine (wireless) from Amazon £14 (http://tinyurl.com/NikonML-L3)

> Thanks for the link. I had a similar link for a Nikon camera, although
> the project didn't use Arduino. So I just need to get the timings from
> that other page and I should be able to build something that works
> reasonably quickly.

> I presume I would just need some resistors and a IR led?

Not sure - I guess you'd need an optocoupler as well but Ive not used one before

[Michael Nicholls]

I think this is the original page I found: http://www.bigmike.it/ircontrol/

And also this: http://www.alanmacek.com/nikon/

With the sequences from these pages I should think it would be quite
simple to get something working.

Mike

On Jul 6, 4:04 pm, Ade <adrian.brads...@gmail.com> wrote:
> 2009/7/6 Michael Nicholls <nicholls...@googlemail.com>:

[G Bulmer]

On Jul 6, 3:12 pm, Ade <adrian.brads...@gmail.com> wrote:

>...

>
> I think maybe the page you are thinking of ishttp://wordpress.bolanski.com/?p=9
>

I had a quick look at that code.

I'm happy to believe it works well, but you could do it on the
Arduino, and write the whole thing in C, using the Arduino's IDE,
which may be easier to understand.

I have done some IR stuff to record IR remotes, and an IR controller
to drive my TV using an Arduino.

I used a timer (timer1 or timer2 are available) to drive the basic
modulation of the IR LED directly with the timer hardware. This avoids
the problem of tuning the software to get the modulation timing
accurate enough; you could change crystal or use the internal
oscillator and get the modulation correct by changing just one number.
I think the pulse timing could be done with just the Arduino's
delayMicroseconds() function, and digitalWrite()

That leaves plenty of flexibility to make an intervalometer, or
trigger the camera based on sensor inputs (take photo's of the Ben &
Jerries thief as the open the deep freeze door?)

Once it works, you could put the code into a ATtiny to make it
physically small. You could prototype on veroboard.
(Rapid sell ATtiny's for £1.55 (+VAT) or less, and some are in small
SOIC packages.)
If you use the internal oscillator, you only need a few extra
components, so it can be small.
Have you got an AVR In Circuit Programmer to put your code into a
different chip?

GB-)

[Michael Nicholls]

Thanks for look at that.

Am I right in thinking that when you are sending an IR pulse you have
to oscillate it at about 38KHz and this is what you suggest would be
best to run off the hardware timer?

I have read people have had to tweak when using delayMicroseconds and
digitalWrite. Is there a list of how long each Arduino operation
should take? I suppose that is one benefit of using Assembly, you know
how many cycles each op will take.

It's funny you should mention an intervalometer as my Dad uses the
camera to take photos of weather phenomena a lot. Maybe he could use
it to capture a setting sun every min or two to get the best picture.
Also I have read you can hook up some kind of light sensor that
detects lighting and activates the shutter, although I suppose IR
would be too slow to activate this. I am guessing the camera would
have some kind of port for a wired based remote shutter. Maybe thats a
seperate project ;-)

My next question after getting a prototype working on an Arduino was
going to be, how do I build this into a permanent key fob, power by a
button battery. Not heard of ATtiny, so will go away and research.

The only thing I have is my Arduino and a few components, which all
arrived in the post this morning :-)
I had time to compile and upload the blink sketch to confirm things
worked.

I am guess an AVR In Circuit Programmer is somethign you plug an AT
chip into to upload code to it. (Basically what the Arduino does, but
without all the other stuff?)

I am going to nip to Maplins and pick up an IR LED. Do you think I
will need anything else to get the prototype going? I am thinking at
the most basic level I can wire the LED between 13 and GND and just go
from there to get it working?

Not going to have any time to play with it as I am away this weekend,
so will be coming to the meeting next week all ready to start it.
Would appreciate your help if you are going to be there.

Also what does the G in your name stand for?

Cheers,
Mike

[Michael Nicholls]

Wow.

Thanks for all that info G.

I think I understand most of the basic concepts behind getting it
working, will just need to query some details as we are going along.

Sounds like there is a lot we could learn from you :-)

I look forward to next weeks meeting and discovering your true
identity lol.

Cheers,
Mike

On Jul 8, 1:19 pm, G Bulmer <gbul...@gmail.com> wrote:
> On Jul 8, 10:26 am, Michael Nicholls <nicholls...@googlemail.com>
> wrote:> Thanks for look at that.

>
> > Am I right in thinking that when you are sending an IR pulse you have
> > to oscillate it at about 38KHz and this is what you suggest would be
> > best to run off the hardware timer?
>

> Yes. Use the hardware to generate a continuous 38KHz square wave. An
> IR LED on the right pwm pin will then flash with the right modulated
> carrier signal. Then just switch the signal on and off using the
> timings in the article.
>
> Set up the timer registers in setup(), and use analogWrite to the
> appropriate pin.
>
> Here's an example . Please don't assume this is all correct, it is
> just fragments from a program I wrote last year. I set the things to
> flash very slowly so I could see it working with an ordinary LED. It
> needs to be adjusted a bit to generate 38KHz.
>
> #include <avr/io.h>
>
> void setup()
> {
>   // Switch off Timer1 PWM
>   TCCR1A = 0;    // clear control register A - 15.11.1 pg 131 - 133
>   TCCR1B = 0;    // clear control register B - 15.11.2 pg 133-134
>
>   // Set Waveform generation mode - table 15-4 page 133
>   // set mode  9:  phase and frequency correct pwm with OCR1A sets
> TOP, i.e. controls frequency
>   TCCR1B = _BV(WGM13);    // WGM1_3=1 WGM1_2=0
>   TCCR1A = _BV(WGM10);    // WGM1_1=0 WGM1_0=1
>
>   // set Timer1 prescaler to 1024, i.e. 16MHz/1024 = 16KHz-ish
>   TCCR1B |= _BV(CS12) | _BV(CS10);    // CS12=1 CS11=0 CS10=1, Table
> 15-5, pg 134
>
>   TCNT1 = 0;               // Zero Timer1 counter
>   OCR1A = 0x3FFF;     // slow frequency -slow enough to be seen, 16KHz/
> 32k = about 1/2 Hz
>
>   DDRB |= _BV(PB1);   // sets data direction register for pwm output
> pin 9
>
>   TCCR1A |= _BV(COM1A0);   // activate the output pin to toggle on
> Compare Match
>
> }
>
> then you could use analogWrite, or:
> void pwmOn()
> {
>   TCCR1A |= _BV(COM1A0);              // activate output pin OC1A (pin
> 9), to toggle on/off when compare match}
>
> and
> void pwmOff()
> {
>   TCCR1A &= ~ (_BV(COM1A1) | _BV(COM1A0));    // Disconnect, and hence
> decativate OC1A (pin 9) *ALWAYS*, no matter which mode
>
> }
>
> Assuming the timings are:
> 2.0ms on
> 27.8ms off
> 0.5ms on
> 1.5ms off
> 0.5ms on
> 3.5ms off
> 0.5 ms on
> repeated after a 63.0 ms pause
>
> then write a shoot() function, which would look like (remember I am
> not testing any of this):
>
> void shoot()
> {
>   pwmOn();
>   delayMicroseconds(2000);
>   pwmOff();
>   delayMicroseconds(27800);
>   pwmOn();
>   delayMicroseconds(500);
>   pwmOff();
>   delayMicroseconds(1500);
>   pwmOn();
>   delayMicroseconds(500);
>   pwmOff();
>   delayMicroseconds(3500);
>   pwmOn();
>   delayMicroseconds(500);
>   pwmOff();
>
>   delay(63); // wait for 63 mSec
>
>   // repeat
>   pwmOn();
>   delayMicroseconds(2000);
>   pwmOff();
>   delayMicroseconds(27800);
>   pwmOn();
>   delayMicroseconds(500);
>   pwmOff();
>   delayMicroseconds(1500);
>   pwmOn();
>   delayMicroseconds(500);
>   pwmOff();
>   delayMicroseconds(3500);
>   pwmOn();
>   delayMicroseconds(500);
>   pwmOff();
>
> }
>
> just call this from loop() when you want to tell the camera to take a
> picture.

>
>
>
> > I have read people have had to tweak when using delayMicroseconds and
> > digitalWrite.
>

> Strongly depends on what they are doing.
>
> I looked at the code (wiring.c), and I believe the error in
> delayMicrosecond() is pretty small because they have done the
> instruction timing for you. Very short delays (under 5 uSec) may be a
> bit problemtic though.
>
> In the timer-based approach, the timer is happily generating the 38KHz-
> ish signal, and the error on pwmOn() and pwmOff() are fairly
> consistent (and should be sub microsecond), so it is very unlikely to
> be an issue.
>
> For many applications (like this one) an Arduino is crazy fast, when
> you can let its hardware do the 'heavy lifting'.
> Once you use the timer to do the basic modulated signal, there isn't
> anything which is timing critical (probably within 50 uSec, or 800
> instructions is good enough).
>
> digitalWrite does have checks to make sure it is working correctly,
> and is general purpose (have a look at wiring_digital.c), which slows
> down how fast it turns a pin on or off.
> I measured it a while ago, and I think it was around a 100KHz, but it
> may have been a bit faster (it is pretty easy to test).
> Even that is likely to be well within the tolerance of the camera.
>
> When I care about speed, I use code like:
>    TCCR1A |= _BV(COM1A0);
> which compiles down to similar code to assembler programmer would
> write anyway.
>
> IMHO, it is usually *much* easier to get code working in C, and then
> make it fast enough, than do it all in assembler.
> A good rule of thumb is more than 80% of the performance of a program
> is determined by less than 20% of the code.
> It is unusual to find a problem where it is too hard to get the code
> going well enough in C, but easier in assembler.

>
> > Is there a list of how long each Arduino operation
> > should take?
>

> Yes, look at:http://www.atmel.com/dyn/resources/prod_documents/8161S.pdf
> Section 6. Instruction Set Summary, page 12.
> It is measured in cycles. An arduiino's ATmega is running at 16MHz-
> ish, so 0.0625-ish uSec/cycle.

>
> > I suppose that is one benefit of using Assembly, you know
> > how many cycles each op will take.
>

> True, but what good will it do?
> It is quite a lot of work to keep accounting accurately, especially
> when the code is experimental and changing.
> The timer interrupt will still fire, so every millisecond, the code
> will take much longer than it looks.
> It is pretty difficult to get two code paths (e.g. in an if () ...
> else ...) to come out the same, and loops can be messy too.
>
> If you move code to a processor which runs at 8MHz (like a lillypad),
> the code would need a rewrite to correct the timing.
>
> I'd rather use reasonably accurate clocks, and just change a bit of
> the setup and a few numbers.
>
> IMHO a key point is I think most mass produced electronics are pretty
> forgiving of errors under 20% because they have to work at widely
> differing temperatures, with stuff made years apart using components
> with 10% tolerances. You could do an experiment with the camera to see
> how forgiving it is.

>
>
>
> > It's funny you should mention an intervalometer as my Dad uses the
> > camera to take photos of weather phenomena a lot. Maybe he could use
> > it to capture a setting sun every min or two to get the best picture.
>

> Yes, that would be straightforward.
>
> You could try to be even sneakier, and measure the light levels, or
> using filters, measure the colour of light !-)
> With experimentation, you may be able to look for coloured sky (a few
> sensors pointed at different parts of the sky).
> I am not a photographer though, so I have little intuition about how
> much effort that would take to get right.
>
> Another thing to try is long exposure photo's of the sky at night:http://www.flickr.com/photos/steventheamusing/3035302174http://www.digitalfieldguide.com/blog/1413
>
> Do you know if there are other features than 'shoot' available on IR
> for that camera?
> If it lets you adjust exposure as well as shoot, you could do some Hi-
> Dynamic Range images.

>
> > Also I have read you can hook up some kind of light sensor that
> > detects lighting and activates the shutter,
>

> Oops. commented above.
>
> Yes, light sensors like these:http://uk.rs-online.com/web/search/searchBrowseAction.html?method=ret...
>
> are sensitive to visible light, and are pretty easy to use (you need a
> resistor and a small capacitor).
>
> You would read the light level with analogRead() and control when to
> 'shoot' a picture.
> With this approach, you could shoot a sequence of pictures which shows
> the light gently falling (or on a morning, getting lighter).

>
> > although I suppose IR
> > would be too slow to activate this.
>

> How fast do you want to trigger the camera?
>
> The total time to send the 'shoot' signal twice is roughly 140mSec,
> which is comparable (a bit slower) to human reaction time. If it
> triggers on the first 'signal' that is under 40mSec, which is probably
> faster than most people can shoot (and may be faster than the camera).
> So maybe just give it a go.

>
> > I am guessing the camera would
> > have some kind of port for a wired based remote shutter. Maybe thats a
> > seperate project ;-)
>

> :-)

>
>
>
> > My next question after getting a prototype working on an Arduino was
> > going to be, how do I build this into a permanent key fob, power by a
> > button battery. Not heard of ATtiny, so will go away and research.
>

> Have a look at Rapid electronics:http://www.rapidonline.com/Electronic-Components/Integrated-Circuits/...
>
> They are exactly the same core processor as the Arduino, so your
> normal code will work unchanged. To make them smaller and cheaper they
> have a subset of an ATmega's peripheral hardware (e.g. fewer PWM's or
> ADC's, no UART), and smaller memories. ATtiny's come in smaller
> package than ATmega's (under 8mm x 6mm if you really want it).
>
> This application is so small, you may be able to make do with a 20,
> 14, or even 8 pin device (depends on the human interface you want to
> use, because the IR control only uses 1 pin).
>
> Lots of information at:http://www.atmel.com/dyn/products/devices.asp?family_id=607#791
>
> It needs some sort of AVR ISP to get the program in, but once that's
> done, it runs like an Arduino's ATmega.

>
>
>
> > The only thing I have is my Arduino and a few components, which all
> > arrived in the post this morning :-)
> > I had time to compile and upload the blink sketch to confirm things
> > worked.
>

> It is a wonderful feeling when it works !-)
> I got such a thrill, and I've been programming a long time. When I got
> some school children to do it, they were a bit amazed that it was
> within their capability to make something act or react.
>
> With a bit of fiddling around you can make a stroboscope, which can
> 'freeze' things like a spinning fan, or show a guitar string vibrate.
> Get a potentiometer and you can use that to adjust the strobe speed.
> (I hope you are not sensitive to flashing lights. If you are be don't
> do it).

>
>
>
> > I am guess an AVR In Circuit Programmer is somethign you plug an AT
> > chip into to upload code to it.
>

> Yes, exactly. It treats the Atmega like a little memory chip, and just
> writes the program into it.

>
> > (Basically what the Arduino does, but without all the other stuff?)
>

> No, the Arduino processor has a program already loaded into it, called
> a bootloader.
> When you power-on an Aduino, that bootloader program runs on the
> Arduino, and starts looking for a program to come down the wire, and
> it is the bootloader program (talking to the host pc, which is running
> a download program called AVRdude [under the Arduino IDE covers])
> which takes the program off the wire and puts it into flash memory.

>
> > I am going to nip to Maplins and pick up an IR LED. Do you think I
> > will need anything else to get the prototype going? I am thinking at
> > the most basic level I can wire the LED between 13 and GND and just go
> > from there to get it working?
>

> You will need a resistor to limit the current, about 220 ohms
> (anything from 180 to 560 ohm will do).
> I would also get a few ordinary coloured LEDs; I find it really
> frustrating to try debugging something I can't see :-)
>
> If you want to really go for long distance, you might want to shop
> around and get a high-power, narrow focus IR LED and a transistor to
> drive it. But I suggest you get it working first, then upgrade the
> electronics once the code is right.
>
> You can start experimenting on pin 13, but you will need to move to a
> PMW pin if you are going to try the timer-modulation approach.

>
>
>
> > Not going to have any time to play with it as I am away this weekend,
> > so will be coming to the meeting next week all ready to start it.
> > Would appreciate your help if you are going to be there.
>

> Yes. I will be there.
> I will bring the ATmega manual too, so we can look up the right
> settings for the timer - once that is correct, you are probably good
> to go.

>
>
>
> > Also what does the G in your name stand for?
>

> I rarely broadcast that so it makes spam very easy to filter out :-)
> I will tell you when I see you, if that is okay?
>
> GB-)> Cheers,
> > Mike

[G Bulmer]

On Jul 8, 6:00 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:
> ...

>
> I think I understand most of the basic concepts behind getting it
> working, will just need to query some details as we are going along.

No problem.
I think the main thing we'll need to fix are the parameters for the
timer, TCCR1B, TCCR1A,and OCR1A.
The values in that code will flash about 20,000 times slower than
needed :-)

You might want to use Timer2 instead of Timer1.
Timer1 is a 16 bit timer, which is a bit wasted on generating the
38KHz signal; the 8 bit Timer2 is good enough.

The basic 'shoot' message looks like the values from the web site.

I am planning on visiting my brother (his birthday), and will mostly
be out range of the Internet over the weekend on until next Wednesday
a.m..

GB-)

[G Bulmer]

Mike

Which Nikon DSLR has your dad got?
As far as you know, do they all respond to the same IR remote control
signal?
Several of my chums have Nikon DSLR's, so this might be interesting to
them too.

GB

On Jul 6, 2:57 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

[Michael Nicholls]

I think I did read somewhere that many of the Nikon cameras respond to
the same signal, but I am not certain.

Mike

[G Bulmer]

On Jul 11, 9:41 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> I think I did read somewhere that many of the Nikon cameras respond to
> the same signal, but I am not certain.
>
> Mike

Well, if we get it all working on Wednesday, I'll make another, and
see one of my Nikon chums later in the week!-)

It should be straightforward to make a remote with an IR LED, a
resistor or two and a button. The user interface for an intervalometer
will be a bit more complex than a single button.

You could also control it from a PC (write a program to talk down the
USB to an Arduino program), so a PC program could have a look on the
internet for sunset, and start shooting pictures around the
appropriate time :-)

GB-)

[G Bulmer]

On Jul 11, 11:19 pm, G Bulmer <gbul...@gmail.com> wrote:
>...

> It should be straightforward to make a remote with an IR LED, a

> resistor or two and a button. ...

Have you noticed any information which says whether the peak
sensitivity of the IR remote control receiver in the camera is 880nm,
or 940/950nm (or something else)? It'd be easy enough to match it.

Thinking about it, it would make a nice little plug-in for an Arduino
header on a little piece of veroboard.

A shorter range version would just be a 4 pin header plugged into pin
11, 12, 13 and Gnd. This would be easy to experiment with, and
relatively stable (unlike a breadboard).

For more range, we'd use a high-current IR LED (maybe a SFH4501/
SFH4502 from RS components are only 7p each in packs of 5), and drive
the IR LED with a transistor to get more current through it.

If we used something like an MPSA13 Darlington transistor (6p reach in
packs of 5 from RS), or a FET, we could drive several IR LEDs which
should increase the range. Your only taking pictures occasionally, so
a coin battery would last quite a few shots.

If we were going for a higher current approach on the Arduino, we'd
also need to put a wire into 5V to power it all, and add a reservoir
capacitor.

Anyway, we can talk about this on Wednesday.

GB-)

[Bob Clough]

Found a couple of bits an the arduino playground that might help:
http://www.bemasher.net/archives/114 this one is fairly simple
http://www.vonroth.com/Arduino/NikonIrControl/ this one has a full library to control it, maybe it ca do more things?

Bob

[G Bulmer]

On Jul 11, 11:59 pm, Bob Clough <para...@ivixor.net> wrote:
> Found a couple of bits an the arduino playground that might help:http://www.bemasher.net/archives/114this one is fairly simplehttp://www.vonroth.com/Arduino/NikonIrControl/this one has a full library

> to control it, maybe it ca do more things?

(If your gobotics Bob - Hi Bob, I have a small gear you left in my car
when I gave you a lift to the train station.)

Thank you for the links. Fascinating.

There is an important point on the:
delayMicroseconds(27800);
because it doesn't work over 16383 (http://arduino.cc/en/Reference/
DelayMicroseconds)
My fault.
(probably delay(28) is worth trying.)


RANT ON (please don't read this if you are sensitive)

I read the code, and both examples use software for near-microsecond
timing rather than let the hardware do the 'heavy lifting'.

It takes quite a lot of effort to write micro-second scale time
critical software on something running at 8-16 instructions/
microsecond. IMHO, it should be avoided where practical.

IMHO, generating a simple repetitive square wave is what the three on-
board hardware PWM timer units are for! They can be sub-10th-micro-
second accurate, without any software intervention. The LED is
directly driven by the hardware.

I do accept, it looks ugly to set up the timer, but it 'just
works' (TM).

The other advantage of letting the PWM hardware do the time-critical
part of the job (rather than software delays), is the Arduino/ATtiny
can do other things at the same time.

Instead of:
delayMicroseconds(2000);
(which is a straightforward way to get this all working, and
definitely how I'd start)

we could do:
long now = micros();
while (now+2000 > micros()) {
// do something useful and interesting ...
}

Safe in the knowledge that the time critical 38/39KHz modulation is
working accurately in the background.

Using hardware timers makes it easier to move to a different processor
(like an ATtiny) running at a different clock speed. Just change a
couple of numbers, and it'll work.

(Of course, an even tidier solution is to have an interrupt handler on
the PWM timer and just do the whole thing in the background, but I
feel it is better to get it working first, and then get fancy.)

We could extend the remote to be an intervalometer; with one pin it
could generate the digital camera 'shoot' signal and with another pin,
listen for a 'Pound Shop' IR remote control to program the
intervalometer delays. It could be reprogrammed while it is shooting.

I feel that it is straightforward to build something reliable, robust
and extensible. It does take the effort to read the manual (RTFM).

I'm sorry if I come across as dismissive. I do feel sad when folks
write complex or fragile code and publish it when a simple, stable,
robust method is available. I feel even sadder when further people
takes that fragile stuff and try to reuse it.

I have contacted both authors and offered to give them timer-based
code.

GB-(

[BeMasher]

I found this group while I was looking through the referrer's on my
blog. I read that you had tried to contact both authors of the code
samples just recently posted though I have a feeling that google was a
bit over-zealous with it's spam handling and I never received it. I've
actually just recently finished a class on microcontrollers at the
University of Arizona which covered timers in detail. However my main
problem with trying to use timers on an arduino is that I've had bad
luck with finding documentation on using timers on arduino boards.

Any input you could provide would be great, since the way I wrote the
code I posted on my blog was pretty far from optimal.

-BeMasher

On Jul 12, 6:29 am, G Bulmer <gbul...@gmail.com> wrote:
> On Jul 11, 11:59 pm, Bob Clough <para...@ivixor.net> wrote:
>

> > Found a couple of bits an the arduino playground that might help:http://www.bemasher.net/archives/114thisone is fairly simplehttp://www.vonroth.com/Arduino/NikonIrControl/thisone has a full library

[Michael Nicholls]

Sorry guys I have been away in Scotland over the weekend.

I agree timers are the way to go G. It's perfectly suited to generate
the pulses.

I suppose a lot of people have done it other ways simply for a lack of
knowledge of the ATmega.

I didn't really realise until you said that I could access all the
features like you have detailed, although have messed around a little
bit with a microcontroller before and so recognised the possibilities.
Maybe it should be made more obvious in documentation for Arduino that
you can access all the registers and do more advanced stuff.

I guess they didn't to keep it simple, but some advanced docs would be
good.

Bought some IR leds last night so should be all good to go, just need
to pick my dads camera up.

BeMasher, we should be able to share our code with you once we have
got it up and running and you can see what you think.

Incidentally, I am not sure I am going to be able to get hold of the
manual for the camera, but I understand it needs to be placed in a
certain mode to pickup the IR signal. Do you have any idea where this
options would be?

Mike

On Jul 15, 11:51 am, BeMasher <bemas...@gmail.com> wrote:
> I found this group while I was looking through the referrer's on my
> blog. I read that you had tried to contact both authors of the code
> samples just recently posted though I have a feeling that google was a
> bit over-zealous with it's spam handling and I never received it. I've
> actually just recently finished a class on microcontrollers at the
> University of Arizona which covered timers in detail. However my main
> problem with trying to use timers on an arduino is that I've had bad
> luck with finding documentation on using timers on arduino boards.
>
> Any input you could provide would be great, since the way I wrote the
> code I posted on my blog was pretty far from optimal.
>
> -BeMasher
>
> On Jul 12, 6:29 am, G Bulmer <gbul...@gmail.com> wrote:
>
> > On Jul 11, 11:59 pm, Bob Clough <para...@ivixor.net> wrote:
>

> > > Found a couple of bits an the arduino playground that might help:http://www.bemasher.net/archives/114thisoneis fairly simplehttp://www.vonroth.com/Arduino/NikonIrControl/thisonehas a full library

[nikki]

I came across this a while ago:

http://www.cibomahto.com/2008/04/analysis-of-the-millis-function/
http://www.faludi.com/2007/12/18/arduino-millis-rollover-handling/
"On the Arduino microcontroller, the millis() function counts the
number of milliseconds since the program started running.
Unfortunately, this count resets to zero after approximately 9 hours
and 32 minutes."

I don't know if it's relevant to your project, but its probably worth
putting into the general fizzPOP concious anyway...

nikki

[G Bulmer]

On Jul 15, 11:51 am, BeMasher <bemas...@gmail.com> wrote:

> I found this group while I was looking through the referrer's on my
> blog. I read that you had tried to contact both authors of the code
> samples just recently posted though I have a feeling that google was a
> bit over-zealous with it's spam handling and I never received it. I've
> actually just recently finished a class on microcontrollers at the
> University of Arizona which covered timers in detail. However my main
> problem with trying to use timers on an arduino is that I've had bad
> luck with finding documentation on using timers on arduino boards.
>
> Any input you could provide would be great, since the way I wrote the
> code I posted on my blog was pretty far from optimal.
>
> -BeMasher

Hi! Glad to try to help.

The base timer code is (I should double check this version!):

void timer2Setup(unsigned int freqCount) // good value of
freqCount is 416
{
unsigned int realCount = freqCount >> 1; // Phase correct PWM
counts twice, so half count

if (realCount < 8) return; // arbitrarily ignore 1 Megahertz or
faster
// goal is to ensure an
interrupt service routine doesn't kill response

TCCR2B = 0; // switch off the counter
TCCR2A = 0; // switch off connection to OC2A & OC2B pins
// NB: use timer2PulsesOn to connect pin to
output

OCR2A = (unsigned char)realCount; // set PWM frequency, actually
2x slower
OCR2B = ((unsigned char)realCount) >> 1; // aim for close to 50:50
mark/space ratio

TCNT2 = 0; // Initialise counter

// Data Direction Register *MUST* be set - this is a simple
approach :-)
pinMode(3, OUTPUT);

// Phase Correct PWM: TCCR2B:WGM22=1, TCCR2A:WGM21=0 |
WGM20=1
// Clock-divide = 1, is actually /2 for PWM, Phase Correct
// Clock-divide = 1 is TCCR2B:CS22=0 | CS21=0 | CS20=1
TCCR2A = _BV(WGM20); // WGM21=0
TCCR2B = _BV(WGM22) | _BV(CS20); // start counter with clock
prescale=1
}


/* void timer2PulsesOn
* connects PWM counter pulse to drive pin 3
*
* TBD: Should reset counter to 0
*/
void timer2PulsesOn(uint8_t pin)
{
TCCR2A |= _BV(COM2B1) | _BV(COM2B0); // pin 3 == OC2B
}


/* void timer2PulsesOff
* disconnects counter output from pin 3
*/
void timer2PulsesOff(uint8_t pin)
{
TCCR2A &= ~(_BV(COM2B1) | _BV(COM2B0)); // pin 3 == OC2B
}


(We used timer2 for the base 38KHz modulation as we wanted to leave
timer1 doing its current job, and I like to retain the 16bit timer1
for harder tasks)

Mike has the code working very nicely. He discovered a better set of
overall timings than the ones posted above in my previous code.
Kime found the new ones are more reliable; they worked at 7+metres, so
those are worth using.
That distance was using pin 3 directly driving the IR LED, via a 220
ohm resistor, so there is a bit more range available by increasing the
current through the LED.

I plan to try a second Nikon DSLR, just to make sure it is reasonably
and reliable.

GB-)

[Michael Nicholls]

Well I think we can declare the basic prototype a success.

Of course now I am thinking about the next step...

On the one hand I am keen to put it into a keyfob, just so I have a
small remote control, but on the other hand I would like to develop
the lightening detection feature to make it a bit more unique.

So then I ended up thinking maybe the following would be good.

Possibly start by prototyping a small version using a small ATiny and
button battery, but I am thinking also stick two buttons and a
photodiode on it. That way you can have one button dedicated to
sending a shoot message and one button to switch between 'press to
shoot' mode and 'lightening detection shoot' mode. Also i don't see
any reason why we couldn't program it with the IR codes for several
other brands and we could set it so you just hold the mode switch
button for several seconds to enter a mode that then allows you to
press the shoot button to cycle through different IR codes and when
you are happy, you just press the mode switch button to get back to
ready to shoot.

I suppose it would be better to get the above working on the Arduino
first before thinking about the ATiny, but to make the power last I
suppose we would need to wire both switches to interrupt enabled pins
so that we could sleep until someone presses a button. Only other
thing is can we sleep whilst waiting for lightning. Firstly would it
wake quick enough and secondly can we fire an interrupt using this
sensor through an analogue pin? Also I am guessing that we aren't so
spoiled for features on the smaller ATiny chips?

In the mean time I am very interested to know what it would take to
get an ATiny up and running. After programming is it just a case of
wiring power and i/o?

For programming I did see this: http://www.ladyada.net/make/usbtinyisp/index.html

I am guessing using this device it should be quite easy to program an
ATiny? Also I think it would be fun to build it from scratch as I want
to practise some soldering skills ;-)

Ultimately I think it would be great to have a small keyfob, that can
trigger several different manufacturers of camera, either by button
press or lightning detection in a small easy to use package :-)

Can you buy keyfob enclosures?

Do we think it's do-able?

Mike

[Michael Nicholls]

Ok had a little look online and came up with this:

http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=4510668

It is supposed to be for RF, but we could bore holes where ever we
need them for LED's. Also it takes the GP23A battery which would give
us 12v with 38mAh. I can't remember what we said the button batteries
could do, but if it is similar then maybe this could work and give us
a mostly pre-built enclosure. Those batteries are only £1 each.
Enclosure comes in 1, 2 and 3 button types. Not sure if there is
anything more suitable as an enclosure.

Mike

On Jul 16, 11:18 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

[Trevor White]

Those keyfob cases look great and they are quite cheap. If they have the
contacts for the battery etc I think they would save you a lot of work
and work give a great finish to the product.

Trev

[Michael Nicholls]

Yeah they look ok don't they Trev.

Also just found this one: http://uk.farnell.com/boss-enclosures/2957-23/case-keyfob-two-button/dp/1171646

I think that one has a coin cell battery compartment. So does this
one:

http://uk.farnell.com/boss-enclosures/2955-20r-2/case-keyfob-two-button/dp/1264654

Infact this is the whole list:
http://uk.farnell.com/jsp/search/browse.jsp?N=500006+1001393&Ntk=gensearch_001&Ntt=keyfob&Ntx=

They have a variety of styles and number of buttons. Not sure which
would be best, but it does look like we could build this into a neat
professional looking package and with the lightening detection mode it
would make it much more unique, especially if it could target many
different manufacturers :-) Quite excited by the prospect.

Mike

On Jul 16, 1:26 pm, Trevor White <trevor.white...@googlemail.com>
wrote:

> Those keyfob cases look great and they are quite cheap. If they have the
> contacts for the battery etc I think they would save you a lot of work
> and work give a great finish to the product.
>
> Trev
>
> Michael Nicholls wrote:
> > Ok had a little look online and came up with this:
>

> >http://uk.rs-online.com/web/search/searchBrowseAction.html?method=get...

[Michael Nicholls]

Been having a quick look at the ATTiny chips.

Would an ATTiny25 provide enough stuff (pins/PWM Timer/Power Saving)
to allow us to run the IR Led, upto two switches that would trigger an
interrupt to wake the system (and be able to identify which was
pressed?) a sensor for the lightning detection and possible an normal
led to indicate status?

Also are they reasonably easy to program?

I am guessing GB might be able to answer most of these.

Mike

On Jul 16, 1:47 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Yeah they look ok don't they Trev.
>

> Also just found this one:http://uk.farnell.com/boss-enclosures/2957-23/case-keyfob-two-button/...

>
> I think that one has a coin cell battery compartment. So does this
> one:
>

> http://uk.farnell.com/boss-enclosures/2955-20r-2/case-keyfob-two-butt...
>
> Infact this is the whole list:http://uk.farnell.com/jsp/search/browse.jsp?N=500006+1001393&Ntk=gens...

[G Bulmer]

On Jul 16, 11:18 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Well I think we can declare the basic prototype a success.
>
> Of course now I am thinking about the next step...
>
> On the one hand I am keen to put it into a keyfob, just so I have a
> small remote control, but on the other hand I would like to develop
> the lightening detection feature to make it a bit more unique.
>
> So then I ended up thinking maybe the following would be good.
>
> Possibly start by prototyping a small version using a small ATiny and
> button battery, but I am thinking also stick two buttons and a
> photodiode on it. That way you can have one button dedicated to
> sending a shoot message and one button to switch between 'press to
> shoot' mode and 'lightening detection shoot' mode.

Could use two buttons, or hold down one button for more than, say 1/2
second, and have it change between modes.
Probably need a visible LED to signal which mode it is in.

> Also i don't see
> any reason why we couldn't program it with the IR codes for several
> other brands and we could set it so you just hold the mode switch
> button for several seconds to enter a mode that then allows you to
> press the shoot button to cycle through different IR codes and when
> you are happy, you just press the mode switch button to get back to
> ready to shoot.

Yes, we only need the timing of the cameras - could even make it be a
TV be-gone :-)

> I suppose it would be better to get the above working on the Arduino
> first before thinking about the ATiny,

I think we'd start on the Arduino, but do a bit of checking to see
which ATtiny's would be good choices.
ATtiny's have a subset of ATmega facilities (though they do have a few
unique features), so by cosidering which ATtiny's you'd likely use, we
can write the software so that it'll be easy to move to the ATtiny.

> but to make the power last I
> suppose we would need to wire both switches to interrupt enabled pins
> so that we could sleep until someone presses a button.

I don't understand all of the low-power modes, but that is what I
assume.

> Only other
> thing is can we sleep whilst waiting for lightning.

Depends on how we detect lightening.
I had two thoughts:
1. Check the light detector quite frequently, and look for dramatic
changes (within a few milliseconds) - hard to avoid using power
2. Use an external bit of electronics to detect the lightening, and it
wakes the processor.

I did wonder if there is a light filter that could be used to filter
most light except for the lightening? In that case it might be
straightforward to detect lightening with an Op Amp, and use it's
output to wake the processor.

> Firstly would it
> wake quick enough

I'm not an expert, but the wake time for some of the lower-power modes
is a few clock cycles, so a few micro-seconds is quoted in the data
sheet.

> and secondly can we fire an interrupt using this
> sensor through an analogue pin?

There are reduced-power modes which run the ADC, but the processor
would have to wake to do something with the value.
If the ADC cycle is quite slow, then switching off while the ADC is
doing its stuff may save power.

> Also I am guessing that we aren't so
> spoiled for features on the smaller ATiny chips?

They are only a subset of features, so we'd need to keep an eye on the
ATtiny's features while deciding on the functionality you want.

> In the mean time I am very interested to know what it would take to
> get an ATiny up and running. After programming is it just a case of
> wiring power and i/o?

AFAIK there is nothing weird. They have an internal oscillator, so
they need very few components.

> For programming I did see this:http://www.ladyada.net/make/usbtinyisp/index.html

Yes, I believe that would do the job. It says it is supported by
AVRdude which is the software used to download programs under the
Arduino IDE.

> I am guessing using this device it should be quite easy to program an
> ATiny?

The Arduino IDE should use it if I have understood the comment about
AVRdude support.

> Also I think it would be fun to build it from scratch as I want
> to practise some soldering skills ;-)

The instruction pictures look quite doable. Go for it!
eBay sometimes have something similar (but maybe not as flexible).

> Ultimately I think it would be great to have a small keyfob, that can
> trigger several different manufacturers of camera, either by button
> press or lightning detection in a small easy to use package :-)

Yes, I think I know some photographers who'd like one, especially if
it were under £5.

> Can you buy keyfob enclosures?

Yes.

> Do we think it's do-able?

Yes.
I would do the software on the Arduino first (very easy to wire up and
make changes), and do an experiment with an ATtiny in a breadboard.
We could do the first shrink to veroboard, which is pretty easy to use
(and might fit in a ticktac box). That would allow you to adjust it
and find how it works in a portable form.
If you have the dexterity, you might even do 'dead-bug' wiring (no
PCB).

It would be very nifty.

GB-)

[G Bulmer]

On Jul 16, 1:18 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Ok had a little look online and came up with this:
>

> http://uk.rs-online.com/web/search/searchBrowseAction.html?method=get...
Yum, looks very nice! I might get one to examine.

> It is supposed to be for RF, but we could bore holes where ever we
> need them for LED's. Also it takes the GP23A battery which would give
> us 12v with 38mAh.

I think we'd be okay with 3V or more (need a big enough voltage to
trigger IR lED, and allow for voltage drop by ATmega/ATtiny).
After that, it is current (milli-amp hours) rather than voltage which
we'll need.

> I can't remember what we said the button batteries
> could do,

Around 200 mA hours, 3V.

> but if it is similar then maybe this could work and give us
> a mostly pre-built enclosure. Those batteries are only £1 each.
> Enclosure comes in 1, 2 and 3 button types. Not sure if there is
> anything more suitable as an enclosure.
>
> Mike

I am impressed with those, they look very good.

These look like they may be okay:
http://www.rapidonline.com/Tools-Fasteners-Production-Equipment/Cases/Hand-Held/Angled-keyfob-enclosures/71254
http://www.rapidonline.com/Tools-Fasteners-Production-Equipment/Cases/Hand-Held/Keyfob-remote-control-cases/62604
http://www.rapidonline.com/Tools-Fasteners-Production-Equipment/Cases/Hand-Held/Modular-keyfob-cases/81497
http://www.rapidonline.com/Tools-Fasteners-Production-Equipment/Cases/Hand-Held/Keyfob-enclosures/71253

GB-)

[G Bulmer]

On Jul 16, 5:58 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Been having a quick look at the ATTiny chips.
>
> Would an ATTiny25 provide enough stuff (pins/PWM Timer/Power Saving)
> to allow us to run the IR Led, upto two switches that would trigger an
> interrupt to wake the system (and be able to identify which was
> pressed?)  a sensor for the lightning detection and possible an normal
> led to indicate status?

So that sounds like pins for:
2 - switches
1 - IR LED
1 - light sensor (might need more than one to cover enough of the
sky?)
1 - visible LED
Total: 5

If we can use the internal oscillator, and 8-pin device like an
ATtiny25 would do.

This page has a lists of ATtiny's. That page can sort columns, so you
can see what devices have a feature.

An extra which may be interesting is to have an IR *detector* on board
too, so that it can be 'taught' a camera's 'shoot' signal.
With an IR detector, it could use an IR remote handset (£1 shop) to
set it's interval timing, choose camera's, etc.
A second (or more) visible LED might be useful as part of the user
interface.

A thing I like, which it doesn't have, is a 16 bit counter.
That can generate a wake-up signal as slowly as every 4 seconds at
16MHz (or 64 seconds at 1MHz), so, it might be a good way to save
power for an active intervalometer; the processor might use under
0.1mA in this mode.

Other things worth looking at carefully are:
- some ATtiny's have an amplifier on the ADC, which may be useful to
raise lightening sensor signal to an easier to detect level
- amount of EEPROM - we could store camera IR timings in EEPROM
without reprograming the chip
ATmega compatible programming system (e.g. should work with the same
programming that you use for the Arduino's ATmega)

>
> Also are they reasonably easy to program?

I have never used one, but I have looked at the datasheets, and they
are pretty much identical to an ATmega; though they are only a subset
of peripherals, like timers and ADC.

Only ATtiny2313 has a UART, so it is the only one which could
(potentialy) download code (but it is so small a memory, that isn't
likely useful).

That means an In-Circuit-Programmer will be needed, like the ladyada
device. I have an Atmel programmer which should work.
We'd have to give some thought to what electronics is connected to the
same pins that the programmer uses.
For example, if the programmer is in parallel with an input, like a
light sensor, programming could be corrupted by a bright light coming
on while downloading the program. A lot of the I/O is buttons and
LEDs, so we should be able to design an okay solution.

>
> I am guessing GB might be able to answer most of these.
>
> Mike
>

I HTH

GB-)

[Antonio Roberts]

> On the one hand I am keen to put it into a keyfob, just so I have a
> small remote control, but on the other hand I would like to develop
> the lightening detection feature to make it a bit more unique.

I have a vision in my head of having one of these and walking through
Birmingham setting people's cameras off!

Great prototype so far, well done!!

Ant

2009/7/16 Michael Nicholls <nicho...@googlemail.com>:

[G Bulmer]

On Jul 17, 1:55 am, Antonio Roberts <bv3...@gmail.com> wrote:
> > On the one hand I am keen to put it into a keyfob, just so I have a
> > small remote control, but on the other hand I would like to develop
> > the lightening detection feature to make it a bit more unique.
>
> I have a vision in my head of having one of these and walking through
> Birmingham setting people's cameras off!
>
> Great prototype so far, well done!!
>
> Ant

That is a very fun idea! Like a TV-Be-Gone, but a Camera-Be-On.

Of course, the camera is likely pointed at you when this happens,
which may not be ideal :-)

So, you may want to disguise your face.

I believe most digital cameras will record Infrared, so having some
bright IR LEDs in front of your face (ideally near your eyes) would be
invisible to the naked eye, but might add a demonic quality to the
photo's :-)

GB-)

[G Bulmer]

On Jul 17, 1:47 am, G Bulmer <gbul...@gmail.com> wrote:
> On Jul 16, 5:58 pm, Michael Nicholls <nicholls...@googlemail.com>
> wrote:> Been having a quick look at the ATTiny chips.
>
> > Would an ATTiny25 provide enough stuff (pins/PWM Timer/Power Saving)
> > to allow us to run the IR Led, upto two switches that would trigger an
> > interrupt to wake the system (and be able to identify which was
> > pressed?)  a sensor for the lightning detection and possible an normal
> > led to indicate status?
>
> So that sounds like pins for:
> 2 - switches
> 1 - IR LED
> 1 - light sensor (might need more than one to cover enough of the
> sky?)
> 1 - visible LED
> Total: 5
>
> If we can use the internal oscillator, and 8-pin device like an
> ATtiny25 would do.
>
> This page has a lists of ATtiny's. That page can sort columns, so you
> can see what devices have a feature.

Doh! I cut, but forgot to paste :-(

This is the page that lists all of the Atmel 8-bit processors
including the ATtiny's (tinyAVR):
http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC

None of the 8-pin ATtiny's have a 16-bit timer, so I'll take that idea
'off the table'.

To reduce the power use, we'll need to control the power to the light
sensor(s), which will take more pins.
If there is an IR detector, or 2nd LED, we'll need more than 8 pins.
The next size up from 8-pins, is 14 pins.
These are the ATtiny24, ATtiny24A, ATtiny44A, ATtiny84.

The ATtiny24A and ATtiny44A are part of Atmel's 'PicoPower' range of
devices. These are specifically designed to use less power than the
standard chips (i.e. ATtiny24A uses less power than the functionally
identical ATtiny24).

The specification for these is pretty impressive:
Low Power Consumption:
– Active Mode: 210 µA at 1.8V and 1MHz
– Idle Mode: 33 µA at 1.8V and 1MHz
– Power-Down Mode: 0.1 µA at 1.8V

Idle mode is one which the datasheet says it can wake up in a few
clock cycle. In idle-mode a 200mA hour battery would theoretically
last 252 days. So this may be the state we need to aim for most of the
'actively working' time. It may be feasible to wake up every
millisecond, 'taste the air' (look at the buttons, and light sensor)
and go back to idle.

With a 200mA hour coin cell, power-down mode would theoretically last
200/0.0001 = 2,000,000 hours = 228 years. No battery technology I'm
aware of lasts this long, though, but this would be a nice state for
it when it isn't being used.

It'll be hard to approach those battery life figures though, because
the current through the sensors, switches, and LEDs would consume
battery power too (so we need to think hard:-).

HTH
GB-)

[Michael Nicholls]

There's some good ideas there ;-)

If we store the timings in EEPROM then we can preload it with standard
ones, but allow adding of extra timings by.....

an IR detector, which could learn from the original remote or have
another mode to allow the £1 shop remote to type in timings.

Not too sure what you mean by a wake up timer for the intervalometer,
although I don't really know how it would work, which is where I
betray my lack of knowledge in this area.

We would use a photodiode which is better than an LDR? I am guessing
they are suited to different purposes?

The ADC is the thing inbetween the analogue pins and the processor
that takes an analogue reading of the voltage on the pin and converts
it into some digital number for us? Pretty clueless about amps. What
would an amp give us?

I was going to try and experiment putting the ATMega into the deepest
sleep mode and then seeing if I can use a switch to bring it back out
of sleep. Looking at the datasheet it says I can use a pin change
interrupt to wake it from Power Down mode using it configured as a
level interrupt. Am I right in thinking that if I pull the configured
pin to low then I would generate an interrupt?

Now I have read a bit about switches on pins and I read you need a
pull-up resistor to make sure you get stable voltage levels when you
press the button? I know the ATMega has internal pull-up resistors you
can enable, but do you know if these can be enabled when the pin is
used as an interrupt trigger or only when doing i/o? If not, what kind
of value resistor would I need?

Now once I have triggered the interrupt and woken the chip up I read
that it will execute the interrupt routine and then continue running
from the instruction after sleep. How do I specify the interrupt
routine? Is it just a function address in a register? ( SOMEREG =
&myfunction;) do I have to declare the interrupt routine as anything
special or call anything special in my interrupt (e.g. disable
interrupts at the start and re-enable at the end?) Also is there a C
call that executes the sleep command?

If I can understand that then I should be able to right the prototype
to fire the shoot message when the button is pressed and sleep in the
intervening time :-)

Mike

[G Bulmer]

On Jul 17, 12:15 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> There's some good ideas there ;-)
>
> If we store the timings in EEPROM then we can preload it with standard
> ones, but allow adding of extra timings by.....

Yes. There are a couple of issues.

EEPROM is the easiest place for an ATtiny to save all data which must
last longer than a battery. Using the program memory (flash) is not
the way to go (I believe).

The EEPROM can be programmed at the same time as we putthe program in,
using the in-circuit programmer. The major advantage is it's easy for
an program running on the ATtiny to change the values later in life,
without needing an in-circuit programmer.

>
> an IR detector, which could learn from the original remote or have
> another mode to allow the £1 shop remote to type in timings.

By putting an IR detector on the key fob, we could write some software
to record (and 'learn') another IR controller.

One could borrow an IR controller for a camera, record it, and return
the IR controller.
This would give folks much more flexibility. They would never need
access to an in-circuit programmer.

>
> Not too sure what you mean by a wake up timer for the intervalometer,
> although I don't really know how it would work, which is where I
> betray my lack of knowledge in this area.

Okay. I am assuming:
1. lightening lasts many milliseconds, and
2. the vast majority of the time, there is no lightening, so we don't
need to be fully active..

Even when the lightening-shooter is being used to photograph
lightening, it doesn't need to be fully awake all of the time. It can
spend most of its time in a lower power state (idle), which extends
the battery life.

It will wake up occasionally, and have a look for lightening. If it
doesn't see anything, it will reduce power by going 'idle'

It still needs to wake to 'look' for lightening because I don't think
we can reliably get the ADC to wake up the processor (unless we can
design an external bit of electronics which will detect lightening and
wake the processor up). It is that 'wake up' timer that I am trying to
describe.

I assume we'll wake up every milli-second, or so. Hence it might only
be fully-awake for 20% of the time, while it is waiting for
lightening, allowing the battery to last, maybe 5x longer.

When it isn't being used as a lightening, but used for an
intervalometer, it can spend all of the time between intervals in a
sleep, and that is the reason for thinking a big (16 bit) timer may be
handy - I assume most time lapse would be many seconds apart.

When not shooting lightening, or doing time lapse, it will be in a
deeper sleep, and woken when the user presses a button.

>
> We would use a photodiode which is better than an LDR? I am guessing
> they are suited to different purposes?

The LDR's I am aware of are quick 'slow' devices, with a reaction-
times in the few-100 milli-seconds (one spec said 10 seconds to
recover from a bright light!). They can be relatively insensitive too
(though I have limited experience), so we may find they don't really
react until the lightening has got very bright before it responds,
which is way too late to start triggering the camera.

I think we will want something quite quick so that we can work out
what is happening.

Photo-diodes are the quickest, with some reaction times as fast as
nano-seconds, photo-transistors are in micro-seconds up.

I'd suggest building a little test rig, with a few different sensors,
and recording data in a lightening storm to see what works well.

>
> The ADC is the thing inbetween the analogue pins and the processor
> that takes an analogue reading of the voltage on the pin and converts
> it into some digital number for us?

Yes, exactly.

> Pretty clueless about amps. What
> would an amp give us?

An Op Amp (Operational Amplifier) would let us amplify and filter the
signal from the detector.

We only have a couple of volts to detect lightening with.
We might want to amplify the signal so that we see a change while it
is small, giving more time to work out what is happening.
As another example, we might want to filter-out street lighting 50Hz
flashing, or the even slower flash of car headlights sweeping bye. Op
amps help make that sort of thing easier, fast, and robust.

We may need the amplification anyway, and some Atmel processors can
increase the amplification of change without external components.

>
> I was going to try and experiment putting the ATMega into the deepest
> sleep mode and then seeing if I can use a switch to bring it back out
> of sleep.

That's a very good idea.
There are a couple of pins (INT0=pin 2, and INT1 = pin 3, which is
already used for the IR LED) which are designed to trigger interrupts,
so I think a button on pin 2 would be a reasonable experiment.

> Looking at the datasheet it says I can use a pin change
> interrupt to wake it from Power Down mode using it configured as a
> level interrupt.

Yes, that would do it.

> Am I right in thinking that if I pull the configured
> pin to low then I would generate an interrupt?

With pin change, either direction will work.

> Now I have read a bit about switches on pins and I read you need a
> pull-up resistor to make sure you get stable voltage levels when you
> press the button?

Yes, that's correct, otherwise the unconnected pin floats around.

> I know the ATMega has internal pull-up resistors you
> can enable, but do you know if these can be enabled when the pin is
> used as an interrupt trigger or only when doing i/o?

Good question. I don't know, but I have always assumed they're
intended for this purpose, so my 'knee jerk' is yes.
I'll look. (I need tea, so this may take some time).

> If not, what kind
> of value resistor would I need?

It can be relatively high. I would start with 10K, and go bigger
(1Mohm should be okay as the input resistance of digital inputs is
huge, and this would use much less current).

>
> Now once I have triggered the interrupt and woken the chip up I read
> that it will execute the interrupt routine and then continue running
> from the instruction after sleep. How do I specify the interrupt
> routine? Is it just a function address in a register? ( SOMEREG =
> &myfunction;)

No.
It will be declared as an ISR or SIGNAL.

Have a look at wiring.c in the Arduino's files, and you'll see the
function which catches the interrupt which handles timer1. It is
declared as:

SIGNAL(TIMER0_OVF_vect)

I believe the more modern recommendation would be
ISR(TIMER0_OVF_vect)
(I've done both, and feel 'clean and modern' when I use ISR:-).

> do I have to declare the interrupt routine as anything
> special

Yes, it will be a SIGNAL() or ISR(), and have a name which matches the
type of interrupt you're using.
Look in iom168p.h

It contains:
#define TIMER1_OVF_vect _VECTOR(13) /* Timer/Counter1 Overflow */
(the one above), and:
#define INT0_vect _VECTOR(1) /* External Interrupt Request 0
*/
#define INT1_vect _VECTOR(2) /* External Interrupt Request 1
*/
#define PCINT0_vect _VECTOR(3) /* Pin Change Interrupt Request
0 */
#define PCINT1_vect _VECTOR(4) /* Pin Change Interrupt Request
0 */
#define PCINT2_vect _VECTOR(5) /* Pin Change Interrupt Request
1 */

> or call anything special in my interrupt (e.g. disable
> interrupts at the start and re-enable at the end?)

The ATmega168 manual (which you already have, I guess) has guidance on
this, for example "4.7 Reset and Interrupt Handling".

The Atmel documents say you need to store the status register SREG
away, and restore it as you exit. In this situation, it might not
matter.

The SIGNAL()/ISR() function may be okay empty, as all you want to do
it wake up and carry on.

> Also is there a C
> call that executes the sleep command?

I don't know. Time for tea!-)

>
> If I can understand that then I should be able to right the prototype
> to fire the shoot message when the button is pressed and sleep in the
> intervening time :-)

Yes, that would be an excellent experiment. It would be enough to make
a remote fully viable.

If you have access to a sensitive current measuring instrument, you
might want to power the thing off a battery (into a header, not via
the current regulator) and see what the change in supply current is
too. IIRC the power regulator on the Arduino is a power-pig, and may
mask any change that yo get from sleeping.

I'll be very interested in the results!

Take care, and have fun
GB-)

PS - I'll get back to you on sleeping. I do need a cup of tea.

[Michael Nicholls]

Just having a cup myself before I head off from work.

I have had a little read around the subject and think I have enough
info to give it a go.

I saw the ISR stuff you were talking about and also seen there are a
host of C functions to trigger the sleep mode.

http://www.nongnu.org/avr-libc/user-manual/group__avr__sleep.html

The whole reference looks like one to bookmark for these more advanced
applications.

When I read about it I could see the two external interrupts, but if
we are using the one pin for the led and we want to to wire in two
buttons then I thought maybe we could use the pin change interrupts
which also appear to be able to wake from power-down mode. Not sure if
there are any problems with using these as it gives us more
flexibility with pins (especially when we move to an ATtiny). Also it
looks like waking from a mode other than idle requires configuration
of the interrupt pin to be level, which I am guessing means hold low
for a while.

I am only vaguely aware of the power regulator. I am guessing from the
name that it regulates the power ;-) Meaning it smooths it out
somehow? If I power off a 9v battery for a test, how would I avoid the
power regulator?

Would we need a power regulator for our ATtiny version, or would it be
a case of power, gnd and data pins?

Hopefully I might get some time this weekend to have a go at getting
it sleeping and waking from the interrupt.

I understand what you mean about the timer now. I suppose it is all
about making a sensible interface. We can wake up every now and then
for lightning detection mode, but then maybe we have a timer
(Watchdog?) to return to standard mode (Which just deep sleeps most of
the time) that is set for 30 mins or something. We want to be
efficient and processing, but we also want to drop to that power down
state whenever is sensible, so even if someone forgets to switch a
more power hungry mode off, it should eventually drop back down
anyway.

Might order some photodiodes to play with then. Could rig an
experiment board, but as Doc Brown once said "What we need is a bolt
of lightning. Unfortunately you never know when or where it's going to
strike". Although if anyone is likely to end up in a storm it is me
and my family, so I should prob build something I can grab in the
event of a storm chase.

I have ordered a tinyusbisp kit so will be able to assemble that ready
for some ATtiny experiments in the future.

Mmmmmm that was a good cup of tea ;-)

Mike

[G Bulmer]

On Jul 17, 5:34 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Just having a cup myself before I head off from work.

Hmmm. Refreshing ...

> I have had a little read around the subject and think I have enough
> info to give it a go.
>
> I saw the ISR stuff you were talking about and also seen there are a
> host of C functions to trigger the sleep mode.
>
> http://www.nongnu.org/avr-libc/user-manual/group__avr__sleep.html

Yes. The stuff we need is in avr/sleep.h

The comment at the start of that header file is full of useful help.

>
> The whole reference looks like one to bookmark for these more advanced
> applications.

Yes. I didn't think to look there for sleep, but they have good stuff,
like "Data in Program Space"

>
> When I read about it I could see the two external interrupts, but if
> we are using the one pin for the led and we want to to wire in two
> buttons then I thought maybe we could use the pin change interrupts
> which also appear to be able to wake from power-down mode.

That would work fine too.
I vaguely remember that there is some other handy capability on INT0/
INT1
but several people have used pin change. It is worth trying both.

> Not sure if
> there are any problems with using these as it gives us more
> flexibility with pins (especially when we move to an ATtiny).

Agreed.

> Also it
> looks like waking from a mode other than idle requires configuration
> of the interrupt pin to be level, which I am guessing means hold low
> for a while.

Level usually means held at a voltage (rather than triggered on an
edge); I believe you are correct that the pins like ground.

>
> I am only vaguely aware of the power regulator. I am guessing from the
> name that it regulates the power ;-) Meaning it smooths it out
> somehow?

It is a bit smarter than that. It produces a constant voltage as the
input voltage drops (as a battery reduces in voltage). Capacitors are
used to 'smooth' variation

> If I power off a 9v battery for a test, how would I avoid the
> power regulator?

You can't. 9V would blow the ATmega.

BUT, if you used 4.5 V, it should run. I wouldn't bother with this for
now, but you might want to connect your photodiodes to the 3.3V so it
is easier to move your code to a lower voltage, battery powered,
setup.

>
> Would we need a power regulator for our ATtiny version, or would it be
> a case of power, gnd and data pins?

We should be able to power the ATtiny directly from a battery without
a voltage regulator.
It isn't that voltage regulators are inherently bad, it is just:
a. they burn power in order to keep the voltage stable (and so would
reduce battery life), and
b. they need an input voltage a volt or more above the electronics, so
they can force an extra battery too.

>
> Hopefully I might get some time this weekend to have a go at getting
> it sleeping and waking from the interrupt.

That would be a very interesting step forward. I'll be around, so
write if you feel the need.

> I understand what you mean about the timer now. I suppose it is all
> about making a sensible interface. We can wake up every now and then
> for lightning detection mode, but then maybe we have a timer
> (Watchdog?) to return to standard mode (Which just deep sleeps most of
> the time) that is set for 30 mins or something.

The watchhdog isn't a good fit.

I am thinking:
1. Normal Camera Remote - very deep sleep, only wakes when a button is
pressed, fires the camera, then deep sleeps.
2. Intervalometer mode - wakes to fire the shutter, and sleeps as deep
as it can (while keeping a timer running) and only wakes to shoot the
next picture (interval may be so long that it needs to wake for a few
microseconds to 'push the snooze button')
3. Lightening mode - wakes every miliisecond to 'taste for lightening'
and sleeps in-between, keeps the ADC running
4. Mode selection - active, to get into the right mode

There may be a time-out from the active states, but that may be more
irritating than they are worth unless the user can select an
acceptable time-out.

> We want to be
> efficient and processing, but we also want to drop to that power down
> state whenever is sensible, so even if someone forgets to switch a
> more power hungry mode off, it should eventually drop back down
> anyway.

Agreed, but it may quite be a long time (e.g. 12 hours). It'd be
infuriating to discover the thing had 'fallen asleep' while waiting
for lightening.

>
> Might order some photodiodes to play with then. Could rig an
> experiment board, but as Doc Brown once said "What we need is a bolt
> of lightning. Unfortunately you never know when or where it's going to
> strike". Although if anyone is likely to end up in a storm it is me
> and my family, so I should prob build something I can grab in the
> event of a storm chase.

If you have access to another camera, you could use it's flash to
simulate lightening.

>
> I have ordered a tinyusbisp kit so will be able to assemble that ready
> for some ATtiny experiments in the future.

Very cool.
I was thinking of ordering the PCB, and buying components in the UK,
partly to see how cheap it'd be.

>
> Mmmmmm that was a good cup of tea ;-)
>
> Mike

Yes, I'm going back for another tea.

GB-)

[Michael Nicholls]

Right after some messing about Friday night I managed to get the
prototype to sleep and wake when pressing a button. This was using the
external interrupt, but I wanted to try to get it to fire from the Pin
Change interrupt to give more flexibility. After realising today that
I had been using the wrong interrupt number I managed to get this
working.

Not measured the current of the circuit and am sure I could power down
a lot of the chips peripherals, but essentially it looks like a basic
prototype for a one button remote. With this in mind I am very tempted
to buy some enclosures and some ATtiny chips and look to build and
package a one button remote, just to see a working finished product,
although in the long term I want to get the Intervalometer and
lightening detection built-in, but I think this will take longer.

If it was built on veroboard and used a button battery, what other
parts apart from the stuff we have on the breadboard now, the ATtiny
and the battery would we need?

Looking at my current code, the Arduino IDE says the Binary sketch
size is 2202 bytes, which is bigger than 1 or 2k so maybe a 4k device
like the ATtiny45 would be good to experiment with (If I have got
those numbers and my units correct).

Also if we normally drive the Arduino board ATMega 328 with 5v then
what happens when you want to drive an ATtiny with only 3. Does it
still work?

Got some issues with the way it triggers when you hold the button
down. I have got round them, but not sure if there is a better way. We
can always take a look at that.

If it arrives and I can build my USBtinyISP before the next meeting
then maybe we could try breadboarding an ATtiny prototype?

Mike

[G Bulmer]

On Jul 19, 6:18 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Right after some messing about Friday night I managed to get the
> prototype to sleep and wake when pressing a button. This was using the
> external interrupt, but I wanted to try to get it to fire from the Pin
> Change interrupt to give more flexibility. After realising today that
> I had been  using the wrong interrupt number I managed to get this
> working.

Great progress.

> Not measured the current of the circuit and am sure I could power down
> a lot of the chips peripherals, but essentially it looks like a basic
> prototype for a one button remote. With this in mind I am very tempted
> to buy some enclosures and some ATtiny chips and look to build and
> package a one button remote, just to see a working finished product,
> although in the long term I want to get the Intervalometer and
> lightening detection built-in, but I think this will take longer.

Well, how about a veroboard ATtiny? That is going in the right
direction.

It might be simple enough to use one of these to shrink even further
for a surface mount version:
http://www.futurlec.com/SMD_Adapters.shtml
(Unless you have access to PCB manufacturing, in which case do that)
But veroboard would be pretty small anyway.

>
> If it was built on veroboard and used a button battery, what other
> parts apart from the stuff we have on the breadboard now, the ATtiny
> and the battery would we need?

Well, if you go crazy and use an external crystal (so everything runs
at the same speed as an Arduino), this shows what you'd need for an
ATmega, and the same components would transfer to an ATtiny
http://tinkerlog.com/2008/01/07/arduino-on-a-prototype-board/

This shows an ATtiny:
http://www.evilmadscientist.com/article.php/card2313v11

Essentially, it is a few capacitors, resistors, and a crystal.

If you want to ditch the crystal (so the ATtiny will instead run off
the internal oscillator), it can be reduced to this:
http://hcgilje.wordpress.com/resources/arduino-standalone/

A capacitor between power and ground, and a resistor to pull reset
high.
The advantage of ditching the crystal is you get two pins back which
can be used for I/O, so an 8-pin ATtiny might do the job (it would
have 6 I/O pins)

>
> Looking at my current code, the Arduino IDE says the Binary sketch
> size is 2202 bytes, which is bigger than 1 or 2k so maybe a 4k device
> like the ATtiny45 would be good to experiment with (If I have  got
> those numbers and my units correct).

I would go for 4K too, for now, then it's easier to get working.
Once it is all working, we can look to trim the code down further if
you want to fit into a smaller memory device.

>
> Also if we normally drive the Arduino board ATMega 328 with 5v then
> what happens when you want to drive an ATtiny with only 3. Does it
> still work?

Most of the devices will run at 1.8V-5.5V:
http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC

Though they won't run at full speed at lower voltages.
The datasheet will say what speed they run at for a particular
voltage.

A quick look at an ATtiny45 datasheets says upto 10MHz at 2.7V (so the
internal clock would work).

We need to be a bit careful, as the output pin can only supply 2.5V
when the chip is powered from 3V, and we need enough voltage for the
IR LED.

>
> Got some issues with the way it triggers when you hold the button
> down. I have got round them, but not sure if there is a better way.

Are you getting 'bounce' from the button?

> We can always take a look at that.

Yes, have you access to an oscilloscope, or better, a storage scope?
That might show what is happening.

>
> If it arrives and I can build my USBtinyISP before the next meeting
> then maybe we could try breadboarding an ATtiny prototype?

Yes! That would be good fun.

Take care,
GB-)

[Michael Nicholls]

Yeah I think breadboarding it and then just building on veroboard to
put in the enclosure should be good, although I should have a look at
surface mount because I know very little about it and should learn ;-)

So if we ran an ATtiny45V (because it can run at lower voltages and so
we should get more out of the battery?) and ditch the external crystal
then I think that's good. I think I am getting my head around pull up
resistors so I understand we need to pull reset high (although in this
case we couldn't just connect reset to Vcc could we? We need the
resistor to limit current?).

I presume the capacitor is there to smooth out and provide a steady
voltage to the ATtiny?

Just trying to understand what every component is doing and why we are
using it ;-)

So the pin can only provide 2.5v when running of 3v battery. How much
does the LED need? Will we need to tweak the resistor to get maximum
effect?

Not getting typical bounce... When the button is pressed it triggers
the interupt and wakes the chip, which fires the signal, loops around
and then goes back to sleep. If your finger is still on the button
then lifting it up cause a logic change and therefore triggers the
interrupt again. My current solution is a while loop that waits until
the button is no longer pressed before sleeping. Not sure if there is
a better way.

No access to scopes I am afraid :-(

Mike

> ATmega, and the same components would transfer to an ATtinyhttp://tinkerlog.com/2008/01/07/arduino-on-a-prototype-board/

>
> This shows an ATtiny:http://www.evilmadscientist.com/article.php/card2313v11
>
> Essentially, it is a few capacitors, resistors, and a crystal.
>
> If you want to ditch the crystal (so the ATtiny will instead run off
> the internal oscillator), it can be reduced to this:http://hcgilje.wordpress.com/resources/arduino-standalone/
>
> A capacitor between power and ground, and a resistor to pull reset
> high.
> The advantage of ditching the crystal is you get two pins back which
> can be used for I/O, so an 8-pin ATtiny might do the job (it would
> have 6 I/O pins)
>
>
>
> > Looking at my current code, the Arduino IDE says the Binary sketch
> > size is 2202 bytes, which is bigger than 1 or 2k so maybe a 4k device
> > like the ATtiny45 would be good to experiment with (If I have  got
> > those numbers and my units correct).
>
> I would go for 4K too, for now, then it's easier to get working.
> Once it is all working, we can look to trim the code down further if
> you want to fit into a smaller memory device.
>
>
>
> > Also if we normally drive the Arduino board ATMega 328 with 5v then
> > what happens when you want to drive an ATtiny with only 3. Does it
> > still work?
>

> Most of the devices will run at 1.8V-5.5V:http://www.atmel.com/dyn/products/param_table.asp?family_id=607&Order...

[G Bulmer]

On Jul 20, 10:39 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Yeah I think breadboarding it and then just building on veroboard to
> put in the enclosure should be good, although I should have a look at
> surface mount because I know very little about it and should learn ;-)

IMHO, getting the circuit working on veroboard is easier and quicker
than surface mount; veroboard is fairly forgiving.

When we know exactly how the circuit works, and there are no changes
to make, it should be straightforward to go to surface mount.
If we are sneaky, we may be able to design the surface mount PCB on a
single sided board, which is straightforward to DIY (laser printer,
and a few shallow baths of chemicals).

>
> So if we ran an ATtiny45V (because it can run at lower voltages and so
> we should get more out of the battery?)

Hmm. I think the critical voltage is determined by the IR LED or photo
detector.
We need enough voltage so that the output voltage on a pin can drive
those devices.
There is roughly a 0.6V drop between the input voltage, and the
voltage a pin can drive out.

I will look at the datasheets, but I don't think an ATtiny45V has a
lower voltage drop between input voltage and the output pin.

> and ditch the external crystal then I think that's good.

That will save space on the board. Also, I think I read in one of the
datasheets that the internal oscillator may have a faster startup time
from deep sleep than an external crystal, which might be handy.

> I think I am getting my head around pull up
> resistors so I understand we need to pull reset high (although in this
> case we couldn't just connect reset to Vcc could we? We need the
> resistor to limit current?).

Yes, the RESET pin needs to be pulled up with a resistor.
There are several issues. One is current limiting.
The other is programming the chip. This can only happen when the reset
pin is forced low by the in-circuit programmer. If the reset pin were
tied directly to Vcc, that would be impossible to do.

>
> I presume the capacitor is there to smooth out and provide a steady
> voltage to the ATtiny?

Yes. There are several sources of 'noise' which might confuse the
processor.
When the IR LED goes on, it will conduct a 'lot' of current (more than
the chip uses for itself) and may cause a dip in voltage, and the
capacitor will help smooth that out.

>
> Just trying to understand what every component is doing and why we are
> using it ;-)

That's good. I don't have all of the answer, so asking helps me too.
The fewer the components, the smaller it'll be.

>
> So the pin can only provide 2.5v when running of 3v battery.

Yes, that is described in the Electrical Characteristics section, and
DC characteristics subsection of the datasheet.
In fact, the spec says 2.5V at 5mA, which isn't a lot of current, so
it may be a lower voltage (It is slightly worse than that looking
later in the datasheet at the pin strength current curves).

> How much does the LED need?

The datasheet for the IR LED you're using says worst case forward
voltage is 1.4 V, so not a lot of headroom, but okay.
(Concretely, if we need to use a transistor to switch the IR LED on,
in order to get more current than the ATtiny can supply (at 3V), then
there isn't much headroom)

(Also, the ATtiny45V datasheet says it can drive an output pin to 1.2V
on a 1.8V supply, which would be too low a voltage to be sure to
properly drive the IR LED. I think 3V may be the best fit voltage).

> Will we need to tweak the resistor to get maximum effect?

We'll need to tweak the resistor to get as much current as we can,
while still keeping the chip happy.
We should try around 100 ohms, which would be a bit over 10mA, (we may
need to go bigger).
It can be a small low-power resistor as we are putting way under 0.1W
though it. RS sell some small resistors in packs of 10 (for about 10p)

>
> Not getting typical bounce... When the button is pressed it triggers
> the interupt and wakes the chip, which fires the signal, loops around
> and then goes back to sleep. If your finger is still on the button
> then lifting it up cause a logic change and therefore triggers the
> interrupt again.

Okay, I understand. I thought it might be electrical.

> My current solution is a while loop that waits until
> the button is no longer pressed before sleeping. Not sure if there is
> a better way.

Well, the logic low interrupt may be okay, I believe it only triggers
once.

>
> No access to scopes I am afraid :-(

No need. I thought there may be something horribly electronic going
on, but your explanation makes it clear.

Take care
GB-)

[Michael Nicholls]

Yeah I suppose the LED is the driving factor behind the voltage. We
don't loose anything by going with the ATtiny45V do we? I was going to
order some in, but could get the ATtiny45 if needed.

Pulling the reset pin up makes perfect sense now. I was thinking we
wanted to pull it high all the time, but forgot the ISP will need to
pull it low to be able to program it.

One question regarding the capacitor. I might end up building a little
8 pin chip programmer with an ICSP header. I am guessing I would still
need the cap on this circuit?

Also can you buy ICSP headers or do you just soldering in two rows of
6 pins? What do they usually call them in catalogues?

Not quite getting all the numbers for working out the LED voltage/
current/resistance, but I can pick your brains on the night about
that.

I did have it running on the external interrupt programmed to respond
to low level, but I get a similar problem. If I hold the button down
then it keeps triggering the interrupt. I tried disabling interrupts
with cli, but the unit seemed to lock up. Maybe I need to leave
interrupts on but disable the specific interrupt I am using? I suppose
if that worked I would still be triggering the the shoot signal on
holding the button as it would loop back round to sleep and then get
triggered again by the low level, so it's sort of the same problem.
Ultimately it may not be a problem, you may expect that holding the
button down continually triggers the camera, but in the long run when
we add other features we may want to detect holding of buttons to
switch modes.

Got a saved basket on rapid at the moment holding all the bits I think
we will need. Hopefully my USBtinyISP kit arrives sometime this week
and I can nip down maplins and get a decent iron and decent solder and
let the fun begin ;-)

Might pick up some photodiodes for lightning detection experiments.
Any particular recommendations?

Mike

[G Bulmer]

On Jul 21, 10:51 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Yeah I suppose the LED is the driving factor behind the voltage. We
> don't loose anything by going with the ATtiny45V do we? I was going to
> order some in, but could get the ATtiny45 if needed.

As far as I can see from the datasheet, the ATtiny45V's support 1.8V,
but I am confused because it says in one place that it can't run at
8MHz below 2.7V, but elsewhere talks about calibrating the internal
oscillator at 1.8V to 3.6V.

I would get ATtiny45's, because I can't figure out how the ATtiny45V's
differ, but I suspect it wont matter at 3V.

>
> Pulling the reset pin up makes perfect sense now. I was thinking we
> wanted to pull it high all the time, but forgot the ISP will need to
> pull it low to be able to program it.
>
> One question regarding the capacitor. I might end up building a little
> 8 pin chip programmer with an ICSP header. I am guessing I would still
> need the cap on this circuit?

Yes, you need to reduce noise on the Vcc.

>
> Also can you buy ICSP headers or do you just soldering in two rows of
> 6 pins? What do they usually call them in catalogues?

It is just made with two rows of standard 0.1" pin header. Maplin,
Farnell, Rapid, RS all sell it. It is a pig to find, sometimes it is
listed as pin strip, also as 2.54mm pin header.

>
> Not quite getting all the numbers for working out the LED voltage/
> current/resistance, but I can pick your brains on the night about
> that.

It is Ohm's law. E.g.
R = V/I
The voltage across the resistor is:
V = 2.5V (Attiny output Voltage on a pin) - 1.4V (IR LED Vforward
maximum)
I = 5 mA (this is an initial value, based on the ATtiny45 datasheet,
and we might tweak this)

so R = 1.1V / 0.005 = 220 ohm is safe

>
> I did have it running on the external interrupt programmed to respond
> to low level, but I get a similar problem. If I hold the button down
> then it keeps triggering the interrupt. I tried disabling interrupts
> with cli, but the unit seemed to lock up. Maybe I need to leave
> interrupts on but disable the specific interrupt I am using?

Only use cli for a few instructions, then sei again.

> I suppose
> if that worked I would still be triggering the the shoot signal on
> holding the button as it would loop back round to sleep and then get
> triggered again by the low level, so it's sort of the same problem.

Sorry, I had thought there was a way of clearing it. My mistake.

> Ultimately it may not be a problem, you may expect that holding the
> button down continually triggers the camera, but in the long run when
> we add other features we may want to detect holding of buttons to
> switch modes.

Agreed, that the sort of UI i was imagining.

>
> Got a saved basket on rapid at the moment holding all the bits I think
> we will need. Hopefully my USBtinyISP kit arrives sometime this week
> and I can nip down maplins and get a decent iron and decent solder and
> let the fun begin ;-)
>
> Might pick up some photodiodes for lightning detection experiments.
> Any particular recommendations?

Not really,
I would look for something fast (sub 10 uSec), and with human-eye/
visible response (not Infrared).

The thing I don't understand is how wide a field of view the camera
will have.
It makes some sense to use a photodiode with a field of view
comparable to the camera lens you use, so probably not a very narrow
angle, but you know better than me.

HTH
GB-)

[G Bulmer]

I tried the IR trigger on a Nikon D80, and once the camera was set up,
it worked fine.
I put a 400 mSec delay after the shoot was sent to stop us going mad.

GB-)

[Michael Nicholls]

Excellent News G.

I am really excited by the thought of a finished version.

I was trying to apply Ohms law and failed miserably. I didn't take the
LED voltage from the supply voltage :-( I will get there with it
someday.

So I need to get a 104K (100n) capacitor, but does it need to be of
any particular type?

Rgarding the pin header. Does this look like the stuff?

http://www.rapidonline.com/Cables-Connectors/Connectors-Multipole/PCB-Interconnect/2.54mm-PCB-Interconnection-system/63793

Do you think any of these IR emitters would be any better? Was
thinking probably need to get some more and if any of these look
better then I might as well add them to the order.

http://www.rapidonline.com/products.aspx?tier1=Electronic+Components&tier2=Optoelectronics&tier3=Infrared+Devices

Photodiodes that look decent are expensive ;-)

https://www.rapidonline.com/productinfo.aspx?tier1=Electronic+Components&tier2=Optoelectronics&tier3=Photodetectors&tier4=BPX65+PIN+Photodiode+TO-18&moduleno=76731
https://www.rapidonline.com/productinfo.aspx?tier1=Electronic+Components&tier2=Optoelectronics&tier3=Photodetectors&tier4=BPW21+PIN+Photodiode+for+visible+spectrum&moduleno=76209

Do you think either of those are the kind of thing we might be looking
for? I shall try to get a look at the field of view of the camera, but
I was thinking if we mount it on top then it should pick up most
lightening if calibrated correctly. This will most likely mean a lot
of photos being taken where the lightening is to the side or behind,
but I would hope it would still work.

Also is this the kind of stuff that is suitable to use as jumper wire?

http://www.rapidonline.com/productinfo.aspx?&tier1=Cables+%26+Connectors&tier2=Equipment+Wire&tier3=Equipment+Wire&tier4=Flexible+PVC+insulated+hook+up+wire+%28UL1015%29&moduleno=71069&catref=01-1394

Nearly ready to click order ;-)

Mike

[G Bulmer]

On Jul 22, 11:22 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Excellent News G.
>
> I am really excited by the thought of a finished version.
>
> I was trying to apply Ohms law and failed miserably. I didn't take the
> LED voltage from the supply voltage :-( I will get there with it
> someday.

I must admit, I often just use the entire voltage (i.e. pin out
voltage, or even 5V) to get a safe part for kids, then there is less
chance to break something if it's wired up wrongly.
In our case, we want as much current as we can get to increase the
range (Powwwwwweeeeeer! That was my Jeremy Clarkson impression :-)

>
> So I need to get a 104K (100n) capacitor, but does it need to be of
> any particular type?

It should have a relatively low resistance, so most people use
'ceramic' capacitors. I follow the crowd!

http://uk.rs-online.com/web/search/searchBrowseAction.html?method=retrieveTfg&Ne=4294961138&Nr=AND%28avl%3auk%2csearchDiscon_uk%3aN%29&N=4294963016+4294955329+4294911131&Ns=stockPolicy_uk%7c1%7c%7cnew_uk%7c1&binCount=2087&multiselectParam=4294963016%204294955329&selectAttribute=100nF#breadCrumb

http://uk.farnell.com/jsp/search/browse.jsp?N=1000225+401+598933&No=0&getResults=true&appliedparametrics=true&locale=en_UK&prevNValues=1000225&originalQueryURL=%2Fjsp%2Fsearch%2Fbrowse.jsp%3FN%3D1000225%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Den_UK

http://www.rapidonline.com/products.aspx?tier1URL=Electronic-Components&tier2URL=Capacitors&tier3URL=Ceramic

>
> Rgarding the pin header. Does this look like the stuff?
>

> http://www.rapidonline.com/Cables-Connectors/Connectors-Multipole/PCB...
Yes, that's the stuff.
You can easily break a long strip into appropriate pieces with a pair
of pliers, so I always get the long strips.

>
> Do you think any of these IR emitters would be any better? Was
> thinking probably need to get some more and if any of these look
> better then I might as well add them to the order.
>

> http://www.rapidonline.com/products.aspx?tier1=Electronic+Components&...
I am a bad person to ask. I always buy a few sensors to try out, so
for me it is an emphatic YES :-)
The high-power LED 58-0112 looks similar to the Maplin part for less
under 1/4 the price
You might want to consider getting a smaller IR LED (e.g. 3mm), or
even surface mount to see how small the remote can be made.

>
> Photodiodes that look decent are expensive ;-)
>

> https://www.rapidonline.com/productinfo.aspx?tier1=Electronic+Compone...https://www.rapidonline.com/productinfo.aspx?tier1=Electronic+Compone...

>
> Do you think either of those are the kind of thing we might be looking
> for?

I don't understand what is ideal for lightening.
Those look pretty impressive, so are as good as I would be able to
recommend.

I was thinking of something cheaper from this set:
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=retrieveTfg&Nr=AND%28avl%3auk%2csearchDiscon_uk%3aN%29&N=4294767569+4294955175+4294922315&binCount=168&method=retrieveTfg&multiselectParam=4294767569%204294955175&Ns=I18NPrc1_uk&Nso=0#resultArrow

where this looks interesting:
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=6548671

at 58p each (but in packs of 5).
It is very, very fast, but more usefully has a reasonably wide
acceptance angle of +/- 75 degrees.
At least you (or I) can get those over the counter from RS.

or
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=retrieveTfg&Ne=4294922322&Nr=AND%28avl%3auk%2csearchDiscon_uk%3aN%29&N=4294767569+4294955175+4294916407&Ns=stockPolicy_uk%7c1%7c%7cnew_uk%7c1&binCount=168&multiselectParam=4294767569%204294955175&selectSubRange=Detectors%20-%20Human%20Eye%20Sensitivity#breadCrumb

I did a quick search at Farnell and found these:
http://uk.farnell.com/jsp/search/browse.jsp?N=1004342+401+409222+395743+395744+395745+395746+395749+395750+395753+395755+395757+395760&Ns=PRICE_PLS_006_PRICE1%7c0&locale=en_UK&appliedparametrics=true&getResults=true&originalQueryURL=/jsp/search/browse.jsp%3FN%3D1004342%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Den_UK

Do you know what the peak wavelength of lightening is? The photodiode
you identified seems to have a lovely wide spectral response.

> I shall try to get a look at the field of view of the camera, but
> I was thinking if we mount it on top then it should pick up most
> lightening if calibrated correctly. This will most likely mean a lot
> of photos being taken where the lightening is to the side or behind,
> but I would hope it would still work.

Yes. I was thinking along similar lines, I thought something around
+/- 75 degree (150 degrees) should cover most of the sky even if the
camera doesn't see it.
We could write a bit of code to time the lightening pulses (and maybe
store the values in EEPROM) to figure out if it can work.

>
> Also is this the kind of stuff that is suitable to use as jumper wire?
>

> http://www.rapidonline.com/productinfo.aspx?&tier1=Cables+%26+Connect...
That looks okay to me, but I use whatever I can find :-)

>
> Nearly ready to click order ;-)
>
> Mike

Exciting!

Garry

[Adrian Godwin]

On Wed, Jul 22, 2009 at 1:52 PM, G Bulmer <gbu...@gmail.com> wrote:

Do you know what the peak wavelength of lightening is? The photodiode
you identified seems to have a lovely wide spectral response.

I'm pretty sure lightning has a lot if UV in it : people get sunburns from electrical discharges (and of course it's blueish). So you want the short wavelengths rather than IR sensitivity. But the short wavelengths are more energetic anyway so unless it has an optical filter that only passes IR, most things should be OK.

-adrian

[G Bulmer]

On Jul 22, 11:22 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:
> ...

>
> Photodiodes that look decent are expensive ;-)
>

> https://www.rapidonline.com/productinfo.aspx?tier1=Electronic+Compone...https://www.rapidonline.com/productinfo.aspx?tier1=Electronic+Compone...

>
> Do you think either of those are the kind of thing we might be looking

> for? ...

If we try for UV sensitive parts ...

Farnell's search can be helpful to throw up possible matches.
For example:
http://uk.farnell.com/jsp/search/browse.jsp?N=1004342+401+409222+395743+395744+395745+395746+395749&Ns=PRICE_PLS_006_PRICE1%7c0&locale=en_UK&appliedparametrics=true&getResults=true&originalQueryURL=/jsp/search/browse.jsp%3FN%3D1004342%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Den_UK

Only includes devices with peak response in the shorter wavelengths
(blue and above to UV)
The lowest cost UV sensitive device is £32.40.

I think we'd be okay with something with visible light sensitivity,
with good blue sensitivity.
The lowest-cost part is a surface mount device:
http://uk.farnell.com/avago-technologies/apds-9005-020/light-sensor-smd/dp/1548110
and costs 55p each. It is practical to solder single surface mount
parts onto veroboard.

(or one which is 'reverse mounted' i.e. it looks through a hole in the
PCB:
http://uk.farnell.com/avago-technologies/apds-9006-020/light-sensor-reverse-smd/dp/1548111
but that's beyond my ability to use without a PCB)

RS charge a lot for UV sensitive parts:
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=retrieveTfg&Nr=AND%28avl%3auk%2csearchDiscon_uk%3aN%29&N=4294767569+4294955175+4294684087&binCount=168&method=retrieveTfg&multiselectParam=4294767569%204294955175&Ns=I18NPrc1_uk&Nso=0#resultArrow

But they devices which claims to be human-eye-like:
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=retrieveTfg&Ne=4294922322&Nso=0&Nr=AND%28avl%3auk%2csearchDiscon_uk%3aN%29&N=4294767569+4294955175+4294916407&Ns=I18NPrc1_uk&binCount=168&method=retrieveTfg&method=retrieveTfg&method=retrieveTfg&multiselectParam=4294767569%204294955175&multiselectParam=4294767569%204294955175&selectSubRange=Detectors%20-%20Human%20Eye%20Sensitivity#breadCrumb

The things I pointed out before would likely be fine:
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=6548671
Do you want to split a pack of 5? I ill probably get a pack anyway
because I like to have a range of photodiodes for robot sensors.

Preferably, we'd use a blue-sensitive visible-light part, but I agree
with Adrian, lightening will likely show up on any visible light
sensor; after all we get an after image on our eyes, so it must be
bright :-)

We can try to measure some lightening to get duration and brightness.
I can imagine that lightening might be too short lived for us to
trigger the camera, but an Arduino could just measure it. We could
store 500 ADC values in RAM during a 'flash' and upload it to a PC.
That would be interesting data, like 'real science'!-)

We could also put a potentiometer on an ADC input so that you can
'tune' the sensitivity, and a button to say 'Yes, that was
lightening', calibrate yourself. With an LED to say 'I thought that
was lightening', we'd have a flash-o-meter :)

GB-)

[Michael Nicholls]

Yeah I will go halves on a pack.

I think a flash-o-meter would be great. We could hopefully use the
data to see if we can practically use it to trigger the camera and
then build a version that incorporates it all together.

I like the idea of "training" it on lightning and having a "I think
this lightning" LED.

Bring on "real science".

Mike

On Jul 23, 11:06 am, G Bulmer <gbul...@gmail.com> wrote:
> On Jul 22, 11:22 am, Michael Nicholls <nicholls...@googlemail.com>
> wrote:
>
> > ...
>
> > Photodiodes that look decent are expensive ;-)
>

> >https://www.rapidonline.com/productinfo.aspx?tier1=Electronic+Compone......

>
> > Do you think either of those are the kind of thing we might be looking
> > for? ...
>
> If we try for UV sensitive parts ...
>
> Farnell's search can be helpful to throw up possible matches.

> For example:http://uk.farnell.com/jsp/search/browse.jsp?N=1004342+401+409222+3957...

>
> Only includes devices with peak response in the shorter wavelengths
> (blue and above to UV)
> The lowest cost UV sensitive device is £32.40.
>
> I think we'd be okay with something with visible light sensitivity,
> with good blue sensitivity.

> The lowest-cost part is a surface mount device:http://uk.farnell.com/avago-technologies/apds-9005-020/light-sensor-s...

> and costs 55p each. It is practical to solder single surface mount
> parts onto veroboard.
>
> (or one which is 'reverse mounted' i.e. it looks through a hole in the

> PCB:http://uk.farnell.com/avago-technologies/apds-9006-020/light-sensor-r...

> but that's beyond my ability to use without a PCB)
>

> RS charge a lot for UV sensitive parts:http://uk.rs-online.com/web/search/searchBrowseAction.html?method=ret...
>
> But they devices which claims to be human-eye-like:http://uk.rs-online.com/web/search/searchBrowseAction.html?method=ret...
>
> The things I pointed out before would likely be fine:http://uk.rs-online.com/web/search/searchBrowseAction.html?method=get...

[G Bulmer]

On Jul 23, 11:24 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Yeah I will go halves on a pack.

Okay, will get a pack.

>
> I think a flash-o-meter would be great. We could hopefully use the
> data to see if we can practically use it to trigger the camera and
> then build a version that incorporates it all together.
>
> I like the idea of "training" it on lightning and having a "I think
> this lightning" LED.
>
> Bring on "real science".
>
> Mike

It occurred to me, that we could try to simulate the recorded
brightness of lightening using bright LEDs.
We could even slow down the replay of a flash of lightening so that it
is easier to see what is happening.
It might also be interesting to record several sensors with filters so
we could get an idea of colour. Who knows, lightening colour may vary,
so that would be another interesting piece of data for Nikki's Jars of
Weather.

Do you know if it is possible to control your Nikon DSLR over USB?
That may be an alternative which we could try for a faster trigger.

GB-)

[Michael Nicholls]

Sorry it's taken me a while, but was away on a Stag Do at the weekend
and still recovering ;-)

I think simulating the lightning could be the way to go as it is going
to be difficult to capture.

Don't think the camera can be triggered over USB, but it might be
worth checking.

I am hoping that the IR would be quick enough.

Maybe see you tomorrow if I get my car sorted :-(

Mike

[Michael Nicholls]

Made a little progress...

Last night I assembled my USBtinyISP and it works like a dream :-)

I put an ATtiny45 on a breadboard, hooked up the 5v and GND from the
programmer (with 104K cap), pulled RESET high and then hooked up the
serial pins to the programmer. After getting over some Linux
permission issues I could communicate with the chip using avrdude :-)

I reprogrammed one of the fuses so that I am getting an 8Mhz clock as
a pose to a 1Mhz clock. I used avrdude to upload a .hex file produced
by the Arduino IDE, but it didn't seem to work (most likely because I
forgot to change the board type to one that uses 8Mhz) but compiled
some pure C code with gcc-avr and then uploaded the resulting hex file
and low and behold I have an LED blinking :-)

Thinking I might persue porting the code to pure C and see if I can
get the remote prototype working against it. Will also try it with a
CR2032 and see how it goes. If I wanted to try driving the LED from
Vcc instead of a pin directly using a transistor, what else would I
need. I understand transistors basically, but am guessing I may need a
resistor between output pin and the base of the transistor?

I am on holiday over the weekend, but will hopefully use some of the
time to try and get this ATtiny prototype working :-)

Mike

On Jul 28, 10:57 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

[G Bulmer]

On Jul 31, 10:58 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Made a little progress...
>
> Last night I assembled my USBtinyISP and it works like a dream :-)

Excellent news. Well done.

>
> I put an ATtiny45 on a breadboard, hooked up the 5v and GND from the
> programmer (with 104K cap), pulled RESET high and then hooked up the
> serial pins to the programmer. After getting over some Linux
> permission issues I could communicate with the chip using avrdude :-)
>
> I reprogrammed one of the fuses so that I am getting an 8Mhz clock as
> a pose to a 1Mhz clock. I used avrdude to upload a .hex file produced
> by the Arduino IDE, but it didn't seem to work (most likely because I
> forgot to change the board type to one that uses 8Mhz) but compiled
> some pure C code with gcc-avr and then uploaded the resulting hex file
> and low and behold I have an LED blinking :-)

That's very good progress. There will still be details to sort out,
but should mostly be 'down hill' :-)

>
> Thinking I might persue porting the code to pure C and see if I can
> get the remote prototype working against it. Will also try it with a
> CR2032 and see how it goes.

Once that goes, you have a the 'platform' working.

> If I wanted to try driving the LED from
> Vcc instead of a pin directly using a transistor, what else would I
> need. I understand transistors basically, but am guessing I may need a
> resistor between output pin and the base of the transistor?

Yes, limit current into the base, usually use a few hundred ohm
resistor will keep things inside the operating range of the ATtiny and
transistor.

Also limit the collector/emitter current (really the current through
the LED).
Don't go too crazy with a big resistor as the transistor is amplifying
the current into the base, and a typical, cheap, single transistor
only has gain around 100 (ratio of base current to LED current).

Ohm's law will be:
LED-current limiting resistor = (battery voltage - LED forward voltage
- transistor voltage drop [usually about 0.6V]) / LED current
You can safely make it bigger, but not smaller :-)

>
> I am on holiday over the weekend, but will hopefully use some of the
> time to try and get this ATtiny prototype working :-)
>
> Mike

You might want to consider Darlington transistors like an MPSA13 which
cost about 6p each, and will switch upto 0.5 Amps (I think it should
be fine, as we are only switching at 38KHz, and it is off most of the
time, so power dissipation shouldn't be a problem, except when the
code is broken :-).
Darlington;s are two transistor connected together inside a single
package, and have quite high gain (well over 1000), so it can be
driven with less current from the ATtiny than a single transistor.
Also you could have a bank of IR LEDs, like an IR 'search light', and
it'll do the job, which may be handy if you want to drive multiple
cameras pointing in different directions.

(Examples:
http://www.rapidonline.com/Electronic-Components/Discrete-Semiconductors/Darlington-Transistors/Darlington-NPN-transistors/66250/kw/MPSA13
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=6254657
http://uk.farnell.com/on-semiconductor/mpsa13g/transistor-npn-to-92/dp/1459126

One thing to consider is the amount of current that will leak through
a transistor when it's off.
I HAVE NOT looked so I may be wrong, but it might consume current
comparable to a sleeping ATtiny, even when the transistor is off.

GB-)

[Andrew Thomas]

Hi,

If it's any help, there's a very good nuts'n'volts article on the parallax website about using switching transistors with microcontrollers. If you want to look you can find it at the url below: Column #6: Silicon steroids for your stamp. It's for Basic Stamp microcntrollers, but just as useful for other types too.

http://www.parallax.com/Resources/NutsVoltsColumns/NutsVoltsVolume1/tabid/444/Default.aspx

There are loads of other nuts'n'volts articles there to download too, which are easily ported.

I hope that helps.

Best wishes,

Andrew.




--- On Fri, 31/7/09, G Bulmer <gbu...@gmail.com> wrote:

[G Bulmer]

On Jul 31, 2:46 pm, G Bulmer <gbul...@gmail.com> wrote:
>
> ...

> You might want to consider Darlington transistors like an MPSA13
>

Mike don't use a Darlington! I forgot about the 3V battery.

A Darlington pair drops roughly double the voltage of a single
transistor; it will drop so much voltage, there is a danger the LED
won't switch on.
Sorry about that. I think my 'Jeremy Clarkson side' was bellowing
"Power" into my ear when I wrote that note yesterday.

GB

[Bob Clough]

Might it be worth looking at a FET for switching?  In your low current application you're likely to lose less voltage that the 0.7v drop on a normal bipolar transistor.

Bob Clough
http://gobotics.net

[G Bulmer]

This is an edited version of a posting on 9th July 2009.
I took the original down because the code did not contain the
appropriate license statement, and there is no way to edit a
positing.

On Jul 8, 10:26 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:
> Thanks for look at that.
> Am I right in thinking that when you are sending an IR pulse you have
> to oscillate it at about 38KHz and this is what you suggest would be
> best to run off the hardware timer?


Yes. Use the hardware to generate a continuous 38KHz square wave. An
IR LED on the right pwm pin will then flash with the right modulated
carrier signal. Then just switch the signal on and off using the
timings in the article.
Set up the timer registers in setup().

I will release code under an appropriate license.


> I have read people have had to tweak when using delayMicroseconds and
> digitalWrite.


Strongly depends on what they are doing.
I looked at the code (wiring.c), and I believe the error in
delayMicrosecond() is pretty small because they have done the
instruction timing for you. Very short delays (under 5 uSec) may be a
bit problemtic though.
In the timer-based approach, the timer is happily generating the
38KHz-
ish signal, and the error on pwmOn() and pwmOff() are fairly
consistent (and should be sub microsecond), so it is very unlikely to
be an issue.
For many applications (like this one) an Arduino is crazy fast, when
you can let its hardware do the 'heavy lifting'.
Once you use the timer to do the basic modulated signal, there isn't
anything which is timing critical (probably within 50 uSec, or 800
instructions is good enough).
digitalWrite does have checks to make sure it is working correctly,
and is general purpose (have a look at wiring_digital.c), which slows
down how fast it turns a pin on or off.
I measured it a while ago, and I think it was around a 100KHz, but it
may have been a bit faster (it is pretty easy to test).
Even that is likely to be well within the tolerance of the camera.
When I care about speed, I use code like:
TCCR1A |= _BV(COM1A0);
which compiles down to similar code to assembler programmer would
write anyway.
IMHO, it is usually *much* easier to get code working in C, and then
make it fast enough, than do it all in assembler.
A good rule of thumb is more than 80% of the performance of a program
is determined by less than 20% of the code.
It is unusual to find a problem where it is too hard to get the code
going well enough in C, but easier in assembler.
> Is there a list of how long each Arduino operation
> should take?

Yes, look at:
http://www.atmel.com/dyn/resources/prod_documents/8161S.pdf
Section 6. Instruction Set Summary, page 12.
It is measured in cycles. An arduiino's ATmega is running at 16MHz-
ish, so 0.0625-ish uSec/cycle.
> I suppose that is one benefit of using Assembly, you know
> how many cycles each op will take.

True, but what good will it do?
It is quite a lot of work to keep accounting accurately, especially
when the code is experimental and changing.
The timer interrupt will still fire, so every millisecond, the code
will take much longer than it looks.
It is pretty difficult to get two code paths (e.g. in an if () ...
else ...) to come out the same, and loops can be messy too.
If you move code to a processor which runs at 8MHz (like a lillypad),
the code would need a rewrite to correct the timing.
I'd rather use reasonably accurate clocks, and just change a bit of
the setup and a few numbers.
IMHO a key point is I think most mass produced electronics are pretty
forgiving of errors under 20% because they have to work at widely
differing temperatures, with stuff made years apart using components
with 10% tolerances. You could do an experiment with the camera to
see
how forgiving it is.
> It's funny you should mention an intervalometer as my Dad uses the
> camera to take photos of weather phenomena a lot. Maybe he could use
> it to capture a setting sun every min or two to get the best picture.


Yes, that would be straightforward.
You could try to be even sneakier, and measure the light levels, or
using filters, measure the colour of light !-)
With experimentation, you may be able to look for coloured sky (a few
sensors pointed at different parts of the sky).
I am not a photographer though, so I have little intuition about how
much effort that would take to get right.
Another thing to try is long exposure photo's of the sky at night:
http://www.flickr.com/photos/steventheamusing/3035302174
http://www.digitalfieldguide.com/blog/1413
Do you know if there are other features than 'shoot' available on IR
for that camera?
If it lets you adjust exposure as well as shoot, you could do some
Hi-
Dynamic Range images.
> Also I have read you can hook up some kind of light sensor that
> detects lighting and activates the shutter,

Oops. commented above.
Yes, light sensors like these:
http://uk.rs-online.com/web/search/searchBrowseAction.html?method=ret...
are sensitive to visible light, and are pretty easy to use (you need
a
resistor and a small capacitor).
You would read the light level with analogRead() and control when to
'shoot' a picture.
With this approach, you could shoot a sequence of pictures which
shows
the light gently falling (or on a morning, getting lighter).
> although I suppose IR
> would be too slow to activate this.

How fast do you want to trigger the camera?
The total time to send the 'shoot' signal twice is roughly 140mSec,
which is comparable (a bit slower) to human reaction time. If it
triggers on the first 'signal' that is under 40mSec, which is
probably
faster than most people can shoot (and may be faster than the
camera).
So maybe just give it a go.
> I am guessing the camera would
> have some kind of port for a wired based remote shutter. Maybe thats a
> seperate project ;-)

:-)
> My next question after getting a prototype working on an Arduino was
> going to be, how do I build this into a permanent key fob, power by a
> button battery. Not heard of ATtiny, so will go away and research.


Have a look at Rapid electronics:
http://www.rapidonline.com/Electronic-Components/Integrated-Circuits/...
They are exactly the same core processor as the Arduino, so your
normal code will work unchanged. To make them smaller and cheaper
they
have a subset of an ATmega's peripheral hardware (e.g. fewer PWM's or
ADC's, no UART), and smaller memories. ATtiny's come in smaller
package than ATmega's (under 8mm x 6mm if you really want it).
This application is so small, you may be able to make do with a 20,
14, or even 8 pin device (depends on the human interface you want to
use, because the IR control only uses 1 pin).
Lots of information at:
http://www.atmel.com/dyn/products/devices.asp?family_id=607#791
It needs some sort of AVR ISP to get the program in, but once that's
done, it runs like an Arduino's ATmega.
> The only thing I have is my Arduino and a few components, which all
> arrived in the post this morning :-)
> I had time to compile and upload the blink sketch to confirm things
> worked.


It is a wonderful feeling when it works !-)
I got such a thrill, and I've been programming a long time. When I
got
some school children to do it, they were a bit amazed that it was
within their capability to make something act or react.
With a bit of fiddling around you can make a stroboscope, which can
'freeze' things like a spinning fan, or show a guitar string vibrate.
Get a potentiometer and you can use that to adjust the strobe speed.
(I hope you are not sensitive to flashing lights. If you are be don't
do it).
> I am guess an AVR In Circuit Programmer is somethign you plug an AT
> chip into to upload code to it.


Yes, exactly. It treats the Atmega like a little memory chip, and
just
writes the program into it.
> (Basically what the Arduino does, but without all the other stuff?)

No, the Arduino processor has a program already loaded into it,
called
a bootloader.
When you power-on an Aduino, that bootloader program runs on the
Arduino, and starts looking for a program to come down the wire, and
it is the bootloader program (talking to the host pc, which is
running
a download program called AVRdude [under the Arduino IDE covers])
which takes the program off the wire and puts it into flash memory.
> I am going to nip to Maplins and pick up an IR LED. Do you think I
> will need anything else to get the prototype going? I am thinking at
> the most basic level I can wire the LED between 13 and GND and just go
> from there to get it working?

You will need a resistor to limit the current, about 220 ohms
(anything from 180 to 560 ohm will do).
I would also get a few ordinary coloured LEDs; I find it really
frustrating to try debugging something I can't see :-)
If you want to really go for long distance, you might want to shop
around and get a high-power, narrow focus IR LED and a transistor to
drive it. But I suggest you get it working first, then upgrade the
electronics once the code is right.
You can start experimenting on pin 13, but you will need to move to a
PMW pin if you are going to try the timer-modulation approach.
> Not going to have any time to play with it as I am away this weekend,
> so will be coming to the meeting next week all ready to start it.
> Would appreciate your help if you are going to be there.


Yes. I will be there.
I will bring the ATmega manual too, so we can look up the right
settings for the timer - once that is correct, you are probably good
to go.
> Also what does the G in your name stand for?


I rarely broadcast that so it makes spam very easy to filter out :-)
I will tell you when I see you, if that is okay?
GB-)
> Cheers,
> Mike

[G Bulmer]

Please Note.

The code I posted in this forum is Copyright Garry Bulmer, and
released under a GPL 3 license.
This means attribution and my copyright must be preserved.

GB

[G Bulmer]

Yes, a FET would be fine.

Before trying an external transistor, I'd try using several ATtiny
pins in parallel.

GB-)

[Michael Nicholls]

During my weekend away I got it working :-)

Rewrote the code into pure C and loaded it onto the ATTiny. Also got
it powered off the 3v battery so I had an untethered, self powered
remote :-)

I need to tweak the resistors for maximum effect and need to get
maximum output from IR led.

Saw all the stuff about transistors, but also saw using several AT
pins in parallel.
I can't remember what the effect is on voltage and current when combed
in parallel? As I would need to recalculate that resistor.

Also I am guessing I can use the Output Compare Interrupt to toggle
the extra pin(s).
How many pins do you think would be the best to try this with?

I think once all those issues have been worked out I work on the first
veroboard version so I can stick it in the keyfob.

Do people use Eagle? Was thinking it might be useful to draw up the
schematics for this, but not really used it before.

Mike

[G Bulmer]

On Aug 5, 10:54 am, Michael Nicholls <nicholls...@googlemail.com>
wrote:
> ...

>
> I need to tweak the resistors for maximum effect and need to get
> maximum output from IR led.
>
> Saw all the stuff about transistors, but also saw using several AT
> pins in parallel.
> I can't remember what the effect is on voltage and current when combed
> in parallel? As I would need to recalculate that resistor.

The voltage would be the same (4.2V) but the capacity to supply
current goes up.
You'd need to read the ATtiny datasheet, but the 26L says a maximum of
60mA output for the whole set of output pins, excluding the reset pin.
For example
R = (4.2V - IR LED minimum forward voltage) / 0.060 Amps

I would leave myself some headroom initially, and use 1/2 current, and
see if the chip gets warm.

I would write directly to the pins, rather than use digitalWrite, to
make them all change at, as near as I could, the same time.
That is very direct and efficient, e.g. on is something like PORTx |=
BITS;

>
> Also I am guessing I can use the Output Compare Interrupt to toggle
> the extra pin(s).

Yes. You will have to write a tiny interrupt service routine (ISR)
which just sets the pins on or off.
I wouldn't bother connecting the output compare unit to the pin (my
pulseOn/pulseOff code), I'd just switch all the pins on or off in the
interrupt service routine.

> How many pins do you think would be the best to try this with?

How many have you spare? I'd try at least three, and I'd start start
with 30mA current limiting resistor.

>
> I think once all those issues have been worked out I work on the first
> veroboard version so I can stick it in the keyfob.

With a bit of care, and one of the larger keyfob cases you might not
need a PCB.

>
> Do people use Eagle? Was thinking it might be useful to draw up the
> schematics for this, but not really used it before.
>
> Mike

Folks do use Eagle. I find the user interface a bit frustrating, so I
use omnigraffle for schematics, but I believe the experts set up the
keyboard to make it easier (and I haven't bothered). I you only want
to produce a schematic, something like Visio or Omnigraffle would
probably be quicker. But for making a PCB, you may find Eagle worth
the effort.

Sparkfun have a set of Eagle tutorials which may help get you going:
http://www.sparkfun.com/commerce/advanced_search_result.php?keywords=eagle&x=14&y=15&search_section=tutorials

Also, you should download the Eagle ATmega libraries so that you have
the right part outlines. Without them, it will be even slower to
produce a schematic. I didn't like the Eagle part library selection
dialogue, but that may be because I don't use it enough, and folks say
it got a bit better recently, I can't comment.

GB-)

[Michael Nicholls]

Cheers G.

Think I understand all that and should be able to give it a try.

Only other thing is that I have a normal red led on a separate pin
that comes on while the signal is being sent. I guess I would have to
factor that into my calculations?
As in all the current being drawn from all pins must not exceed 60mA?

If I use 3 pins for IR led, 1 for push button and one for red led then
I have used all pins (except for RESET), so should work ok for this
version.

Might give Eagle a go and see how I get on.

Cheers,
Mike

> Sparkfun have a set of Eagle tutorials which may help get you going:http://www.sparkfun.com/commerce/advanced_search_result.php?keywords=...

[G Bulmer]

On Aug 5, 4:11 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Cheers G.
>
> Think I understand all that and should be able to give it a try.
>
> Only other thing is that I have a normal red led on a separate pin
> that comes on while the signal is being sent. I guess I would have to
> factor that into my calculations?

Yes you need to include everything.
You could use a 1K resistor to current limit that red LED (and draw a
few mAmps) so it would have a much smaller impact.
I am cautious, so I would recommend you start with a current limiting
resistor 2x bigger to see if the chip gets warm. (Inside the keyfob,
it won't get much ventilation)

> As in all the current being drawn from all pins must not exceed 60mA?

That is what I got from an ATtiny datasheet I looked at,.
I've just had a quick glance (no guarantees) at an ATTtiny45
datasheet, and it looks the same, 60mA max for all pins (excluding
RESET).

>
> If I use 3 pins for IR led, 1 for push button and one for red led then
> I have used all pins (except for RESET), so should work ok for this
> version.

Yes.

I assume the push button is pulled up or down with, at least, a 10K
resistor, so it won't matter (less than 0.5mA is under 1% which is "in
the noise" for this sort of estimate).

>
> Might give Eagle a go and see how I get on.

Good luck with Eagle.

GB-)

[Superhands]

Have we all seen this?

http://blog.makezine.com/archive/2009/08/nice_diy_intervalometer_for_nikon_d.html?CMP=OTC-0D6B48984890

Is this you?

On 16 July, 17:58, Michael Nicholls <nicholls...@googlemail.com>
wrote:
> Been having a quick look at the ATTiny chips.
>
> Would an ATTiny25 provide enough stuff (pins/PWM Timer/Power Saving)
> to allow us to run the IR Led, upto two switches that would trigger an
> interrupt to wake the system (and be able to identify which was
> pressed?)  a sensor for the lightning detection and possible an normal
> led to indicate status?
>
> Also are they reasonably easy to program?
>
> I am guessing GB might be able to answer most of these.
>
> Mike
>
> On Jul 16, 1:47 pm, Michael Nicholls <nicholls...@googlemail.com>
> wrote:
>
> > Yeah they look ok don't they Trev.
>
> > Also just found this one:http://uk.farnell.com/boss-enclosures/2957-23/case-keyfob-two-button/...
>
> > I think that one has a coin cell battery compartment. So does this
> > one:
>
> >http://uk.farnell.com/boss-enclosures/2955-20r-2/case-keyfob-two-butt...
>
> > Infact this is the whole list:http://uk.farnell.com/jsp/search/browse.jsp?N=500006+1001393&Ntk=gens...
>
> > They have a variety of styles and number of buttons. Not sure which
> > would be best, but it does look like we could build this into a neat
> > professional looking package and with the lightening detection mode it
> > would make it much more unique, especially if it could target many
> > different manufacturers :-) Quite excited by the prospect.
>
> > Mike
>
> > On Jul 16, 1:26 pm, Trevor White <trevor.white...@googlemail.com>
> > wrote:
>
> > > Those keyfob cases look great and they are quite cheap. If they have the
> > > contacts for the battery etc I think they would save you a lot of work
> > > and work give a great finish to the product.
>
> > > Trev
>
> > > Michael Nicholls wrote:
> > > > Ok had a little look online and came up with this:
>
> > > >http://uk.rs-online.com/web/search/searchBrowseAction.html?method=get...
>
> > > > It is supposed to be for RF, but we could bore holes where ever we
> > > > need them for LED's. Also it takes the GP23A battery which would give
> > > > us 12v with 38mAh. I can't remember what we said the button batteries
> > > > could do, but if it is similar then maybe this could work and give us
> > > > a mostly pre-built enclosure. Those batteries are only £1 each.
> > > > Enclosure comes in 1, 2 and 3 button types. Not sure if there is
> > > > anything more suitable as an enclosure.
>
> > > > Mike
>
> > > > On Jul 16, 11:18 am, Michael Nicholls <nicholls...@googlemail.com>
> > > > wrote:
>
> > > >> Well I think we can declare the basic prototype a success.
>
> > > >> Of course now I am thinking about the next step...
>
> > > >> On the one hand I am keen to put it into a keyfob, just so I have a
> > > >> small remote control, but on the other hand I would like to develop
> > > >> the lightening detection feature to make it a bit more unique.
>
> > > >> So then I ended up thinking maybe the following would be good.
>
> > > >> Possibly start by prototyping a small version using a small ATiny and
> > > >> button battery, but I am thinking also stick two buttons and a
> > > >> photodiode on it. That way you can have one button dedicated to
> > > >> sending a shoot message and one button to switch between 'press to
> > > >> shoot' mode and 'lightening detection shoot' mode. Also i don't see
> > > >> any reason why we couldn't program it with the IR codes for several
> > > >> other brands and we could set it so you just hold the mode switch
> > > >> button for several seconds to enter a mode that then allows you to
> > > >> press the shoot button to cycle through different IR codes and when
> > > >> you are happy, you just press the mode switch button to get back to
> > > >> ready to shoot.
>
> > > >> I suppose it would be better to get the above working on the Arduino
> > > >> first before thinking about the ATiny, but to make the power last I
> > > >> suppose we would need to wire both switches to interrupt enabled pins
> > > >> so that we could sleep until someone presses a button. Only other
> > > >> thing is can we sleep whilst waiting for lightning. Firstly would it
> > > >> wake quick enough and secondly can we fire an interrupt using this
> > > >> sensor through an analogue pin? Also I am guessing that we aren't so
> > > >> spoiled for features on the smaller ATiny chips?
>
> > > >> In the mean time I am very interested to know what it would take to
> > > >> get an ATiny up and running. After programming is it just a case of
> > > >> wiring power and i/o?
>
> > > >> For programming I did see this:http://www.ladyada.net/make/usbtinyisp/index.html
>
> > > >> I am guessing using this device it should be quite easy to program an
> > > >> ATiny? Also I think it would be fun to build it from scratch as I want
> > > >> to practise some soldering skills ;-)
>
> > > >> Ultimately I think it would be great to have a small keyfob, that can
> > > >> trigger several different manufacturers of camera, either by button
> > > >> press or lightning detection in a small easy to use package :-)
>
> > > >> Can you buy keyfob enclosures?
>
> > > >> Do we think it's do-able?
>
> > > >> Mike
>
> > > >> On Jul 16, 1:21 am, G Bulmer <gbul...@gmail.com> wrote:
>
> > > >>> On Jul 15, 11:51 am, BeMasher <bemas...@gmail.com> wrote:
>
> > > >>>> I found this group while I was looking through the referrer's on my
> > > >>>> blog. I read that you had tried to contact both authors of the code
> > > >>>> samples just recently posted though I have a feeling that google was a
> > > >>>> bit over-zealous with it's spam handling and I never received it. I've
> > > >>>> actually just recently finished a class on microcontrollers at the
> > > >>>> University of Arizona which covered timers in detail. However my main
> > > >>>> problem with trying to use timers on an arduino is that I've had bad
> > > >>>> luck with finding documentation on using timers on arduino boards.
>
> > > >>>> Any input you could provide would be great, since the way I wrote the
> > > >>>> code I posted on my blog was pretty far from optimal.
>
> > > >>>> -BeMasher
>
> > > >>> Hi! Glad to try to help.
>
> > > >>> The base timer code is (I should double check this version!):
>
> > > >>> void timer2Setup(unsigned int freqCount)     // good value of
> > > >>> freqCount is 416
> > > >>> {
> > > >>>   unsigned int realCount = freqCount >> 1;    // Phase correct PWM
> > > >>> counts twice, so half count
>
> > > >>>   if (realCount < 8) return;    // arbitrarily ignore 1 Megahertz or
> > > >>> faster
> > > >>>                                          // goal is to ensure an
> > > >>> interrupt service routine doesn't kill response
>
> > > >>>   TCCR2B = 0;    // switch off the counter
> > > >>>   TCCR2A = 0;    // switch off connection to OC2A & OC2B pins
> > > >>>                          // NB: use timer2PulsesOn to connect pin to
> > > >>> output
>
> > > >>>   OCR2A = (unsigned char)realCount;    // set PWM frequency, actually
> > > >>> 2x slower
> > > >>>   OCR2B = ((unsigned char)realCount) >> 1;  // aim for close to 50:50
> > > >>> mark/space ratio
>
> > > >>>   TCNT2 = 0;  // Initialise counter
>
> > > >>>   //  Data Direction Register *MUST* be set - this is a simple
> > > >>> approach :-)
> > > >>>   pinMode(3, OUTPUT);
>
> > > >>>           // Phase Correct PWM:  TCCR2B:WGM22=1, TCCR2A:WGM21=0 |
> > > >>> WGM20=1
> > > >>>           // Clock-divide = 1,  is actually /2 for PWM, Phase Correct
> > > >>>           // Clock-divide = 1 is TCCR2B:CS22=0 | CS21=0 | CS20=1
> > > >>>   TCCR2A = _BV(WGM20);              // WGM21=0
> > > >>>   TCCR2B = _BV(WGM22) | _BV(CS20);  // start counter with clock
> > > >>> prescale=1
>
> > > >>> }
>
> > > >>> /* void timer2PulsesOn
> > > >>>  * connects PWM counter pulse to drive pin 3
> > > >>>  *
> > > >>>  * TBD: Should reset counter to 0
> > > >>>  */
> > > >>> void timer2PulsesOn(uint8_t pin)
> > > >>> {
> > > >>>   TCCR2A |= _BV(COM2B1) | _BV(COM2B0);  // pin 3 == OC2B
>
> > > >>> }
>
> > > >>> /* void timer2PulsesOff
> > > >>>  * disconnects counter output from pin 3
> > > >>>  */
> > > >>> void timer2PulsesOff(uint8_t pin)
> > > >>> {
> > > >>>     TCCR2A &= ~(_BV(COM2B1) | _BV(COM2B0));  // pin 3 == OC2B
>
> > > >>> }
>
> > > >>> (We used timer2 for the base 38KHz modulation as we wanted to leave
> > > >>> timer1 doing its current job, and I like to retain the 16bit timer1
> > > >>> for harder tasks)
>
> > > >>> Mike has the code working very nicely. He discovered a better set of
> > > >>> overall timings than the ones posted above in my previous code.
> > > >>> Kime found the new ones are more reliable; they worked at 7+metres, so
> > > >>> those are worth using.
> > > >>> That distance was using pin 3 directly driving the IR LED, via a 220
> > > >>> ohm resistor, so there is a bit more range available by increasing the
> > > >>> current through the LED.
>
> > > >>> I plan to try a second Nikon DSLR, just to make sure it is reasonably
> > > >>> and reliable.
>
> > > >>> GB-)

[G Bulmer]

On Aug 10, 4:53 pm, Superhands <ajbeaum...@gmail.com> wrote:
> Have we all seen this?

No. Nice find.
I like Mike's idea of a keyfob sized device more.

>
> http://blog.makezine.com/archive/2009/08/nice_diy_intervalometer_for_...
>
> Is this you?

No, it would be veroboard if it were me :-)

That project uses a very different style of programming. The actual
'snap a picture' function isn't included in that code.

I'm think I should "get my finger out", and blog about how I like to
do IR remote control.
The approach I like is a bit more complex to trigger the camera, but I
think the rest of the functions get simpler.

GB-)

[Michael Nicholls]

Interesting.

Will have to read a bit more indepth to how they have done the UI as
we will need some system like that when we add more features.

G, I def think you should blog about the timing aspect of your IR
code. I never addressed it in my post just to keep the post size down
and simple, but I think it is the most fun part of the code to
understand ;-)

I tried running the IR LED from 3 pins and just triggering the pins
from the compare interrupt, but it didn't seem to work. I worked back
and got it working from the compare out pin mode and found if i enable
the timer0_compb_vect interrupt and leave it empty, the code stops
working. Putting in a visible LED shows that it still seems to trigger
the LED in a similar manar, but enabling the empty interrupt has
broken something :-( I couldn;t see anything in the docs, but maybe
having the interrupt active stops the compare out pin setting from
functioning.

Maybe we could take a look tonight if I can make it?

After that I just need to tweak resistors and then I think it is ready
to try to get onto veroboard.

Have some question about building it on veroboard, but I can field
those this evening.

Not sure if and how long I can be around tonight as if it is a clear
night my Dad and I are going to try to photograph the Perseids using
the IR remote to control the shutter, but equally don't want to miss
the session :-)

Mike

[G Bulmer]

On Aug 12, 12:16 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:

> Interesting.
>
> Will have to read a bit more indepth to how they have done the UI as
> we will need some system like that when we add more features.

To keep size down (on verobard), you might want to consider some 1.8mm
LEDs:
http://www.rapidonline.com/Electronic-Components/Optoelectronics/Miniature-LEDs
they fit on a 0.1" pitch. I use them for my "patented" Arduino
debugger :-)
These might give a nicer finish, they say they 'stack' (though I
haven't used any):
http://www.rapidonline.com/Electronic-Components/Optoelectronics/Rectangular-LEDs

Maybe consider a small display?
http://www.rapidonline.com/Electronic-Components/Optoelectronics/LED-Displays/17.3mm-Dot-matrix-display/29387
If you turn a 5x7 display on its side, you can fit two digits drawn on
a 3x5 grid on it, or little icons (needs more pins to drive than a few
LEDs, but very flexible).
Might be a good UI while you are experimenting with it.

>
> G, I def think you should blog about the timing aspect of your IR
> code. I never addressed it in my post just to keep the post size down
> and simple, but I think it is the most fun part of the code to
> understand ;-)

Thank you for the encouragement. I thought I was just a bit weird, but
if there is someone interested in reading it, then I should!-)

>
> I tried running the IR LED from 3 pins and just triggering the pins
> from the compare interrupt, but it didn't seem to work. I worked back
> and got it working from the compare out pin mode and found if i enable
> the timer0_compb_vect interrupt and leave it empty, the code stops
> working.

Glerk! That's a bit weird. Is this on the ATtiny, or an Arduino?
I didn't think you were using timer0, is that what it maps to on an
ATtiny?

So if you have a bit of code like
ISR(timer0_compb_vect) {}

It stops working.
But if the code is doing almost nothing:
ISR(timer0_compb_vect) { uint8_t tmpSREG - SREG; SREG = tmpSREG; }
it works?


I'd like to make a bit of time to fiddle around with this, maybe next
week ... ?-(
Rapid ran out of ATtiny45's, so I'll just use an Arduino, but if I can
reproduce the same behaviour, that would be "educational".

> Putting in a visible LED shows that it still seems to trigger
> the LED in a similar manar, but enabling the empty interrupt has
> broken something :-( I couldn;t see anything in the docs, but maybe
> having the interrupt active stops the compare out pin setting from
> functioning.

Hmm. Am I understanding correctly? When the ISR is empty, it breaks,
but when the ISR has code, it works?

How are you setting up the compare interrupt?

>
> Maybe we could take a look tonight if I can make it?

I feel a bit guilty that I didn't get there, but I rarely see my
friend ...

>
> After that I just need to tweak resistors and then I think it is ready
> to try to get onto veroboard.
>
> Have some question about building it on veroboard, but I can field
> those this evening.

What sort of things?
If you have a good "Stanley Knife" or scalpel, you can cut the tracks
between holes, and pack stuff pretty tight.

>
> Not sure if and how long I can be around tonight as if it is a clear
> night my Dad and I are going to try to photograph the Perseids using
> the IR remote to control the shutter, but equally don't want to miss
> the session :-)
>
> Mike

Wow. Did you gets some shots of the Perseids?
I have been in dark sky's a couple of times when the shower happened,
and it was lovely.

GB

[Michael Nicholls]

I currently have a smaller LED for my red one, but it is 3mm. Will
check those other ones out.

I like the look of that display unit. Never played with segment
displays, but would like to ;-)

Yeah the tiny45 timer 0 is 8bit with PWM.

The problems with the code were as follows:

I took the code I had working and simply turned on an empty compb
interrupt and this caused the camera to stop being tirggered, even
though putting in a standard LED showed that it was still pulsing.

Using Trev's wonderful little digital oscilloscope we found that the
38.4 KHz pulse was fine, but the bursts were being miss timed. Trev
then pointed out that given the fact the interrupt is called so often
and I am using _delay_us with long delays would likely cause the code
to fall out of sync as even though the impact of the interrupt is
small, it would be quite large once applied to a delay of say 27ms
which is the longest delay in the signal. Other than that it turns out
then the code I was going to put in the interrupt to switch the
multiple pins on and often seemed to work, but the timing was a
problem. So we said either a Transistor or possibly use a hardware
timer to time the delays. In the end we went for a transistor and a
resistor tweak and it all seems to work nicely. Got at least the same
range we had that first night we got it working.

I have since dropped a 33ohm resistor in with the LED so I work that
out to be:

V = 3 - 1.4 (FV LED) - 0.7 (FV Transistor)
R = 33

I = 0.9 / 33 = 0.027 = 27mA

From the data sheet (http://www.maplin.co.uk/Media/PDFs/yh70m.pdf) I
can see that it has a Continuous Forward Current of 100mA, but other
readings (e.g. Forward Voltage) are given with the forward current at
20mA. Does this mean I should really be running it at about 20mA or is
that just the average they expect people to run it at? I am guessing
it gets to point where it won't get much brighter no matter how much
current is flowing? Although theoretically I could stick a bit less
than 100mA through it if I really wanted to and it would be ok?

Trev, worked out that the reason we were seeing the whole circuit
taking 4mA even when asleep was that the programmer, even though not
plugged into the computer was drawing current. I unplugged it from the
programmer and now I get a measurement of about 4uA at idle which I
think is about right :-)

Questions about veroboard were mainly best way to cut it up into
smaller sections and best way to cut tracks. Will want to cut in
between holes if I mount a 6 pin ISP header (which would be nice if I
have the space).

I am currently playing in Eagle to try to get some sort of layout that
fits it all in ;-)

Didn't go after the Perseids on Wednesday as it was too cloudy, but
went last night and saw a couple before it clouded over. It's a bit
rubbish, but had the shutter open and caught this:

http://farm3.static.flickr.com/2468/3819666891_9f6937660b_b.jpg

The smudged line in the middle is a meteor. Quite pleased for a first
attempt, but it wouldn't have been possible without the remote so
thanks again guys for all the input into this, I am learning loads :-)

Mike

On Aug 13, 3:49 pm, G Bulmer <gbul...@gmail.com> wrote:
> On Aug 12, 12:16 pm, Michael Nicholls <nicholls...@googlemail.com>
> wrote:> Interesting.
>
> > Will have to read a bit more indepth to how they have done the UI as
> > we will need some system like that when we add more features.
>
> To keep size down (on verobard), you might want to consider some 1.8mm

> LEDs:http://www.rapidonline.com/Electronic-Components/Optoelectronics/Mini...

> they fit on a 0.1" pitch. I use them for my "patented" Arduino
> debugger :-)
> These might give a nicer finish, they say they 'stack' (though I

> haven't used any):http://www.rapidonline.com/Electronic-Components/Optoelectronics/Rect...
>
> Maybe consider a small display?http://www.rapidonline.com/Electronic-Components/Optoelectronics/LED-...

[Trevor White]

Michael Nicholls wrote:
> I currently have a smaller LED for my red one, but it is 3mm. Will
> check those other ones out.
>
>

You can get 1206 smt leds that would fit across 0.1" pitch tracks.

> I like the look of that display unit. Never played with segment
> displays, but would like to ;-)
>
>

They are cool and you can learn some interesting things about embedded
coding driving them.

> Yeah the tiny45 timer 0 is 8bit with PWM.
>
> The problems with the code were as follows:
>
> I took the code I had working and simply turned on an empty compb
> interrupt and this caused the camera to stop being tirggered, even
> though putting in a standard LED showed that it was still pulsing.
>
> Using Trev's wonderful little digital oscilloscope we found that the
> 38.4 KHz pulse was fine, but the bursts were being miss timed. Trev
> then pointed out that given the fact the interrupt is called so often
> and I am using _delay_us with long delays would likely cause the code
> to fall out of sync as even though the impact of the interrupt is
> small, it would be quite large once applied to a delay of say 27ms
> which is the longest delay in the signal. Other than that it turns out
> then the code I was going to put in the interrupt to switch the
> multiple pins on and often seemed to work, but the timing was a
> problem. So we said either a Transistor or possibly use a hardware
> timer to time the delays. In the end we went for a transistor and a
> resistor tweak and it all seems to work nicely. Got at least the same
> range we had that first night we got it working.
>
>

Quite surprised how useful the scope turned out to be in the end. I was
going to leave it at Fizzpop but think I shall just bring it each
session for others to use. Here is the link to it. Sure someone pointed
it out before.

http://www.seeedstudio.com/depot/digital-storage-oscilloscope-diy-kit-with-panels-p-166.html

Postage is very cheap. Building it yourself does require some decent
soldering skills but nothing too painful.

> I have since dropped a 33ohm resistor in with the LED so I work that
> out to be:
>
> V = 3 - 1.4 (FV LED) - 0.7 (FV Transistor)
> R = 33
>
> I = 0.9 / 33 = 0.027 = 27mA
>
>

Not sure this calculation is correct. Is this for the series resistor
with the transmitter LED. The transistor saturates and so is more likely
to drop approx. 0.2 voltage. The 0.7 volt drop is across the base to
emitter. The voltage across the collector emitter is different and what
you are interested in.

So you are more likely to want:

V = ( 3 - 1.4 ) - 0.2

1.4/33 = 44mA approx.

> From the data sheet (http://www.maplin.co.uk/Media/PDFs/yh70m.pdf) I
> can see that it has a Continuous Forward Current of 100mA, but other
> readings (e.g. Forward Voltage) are given with the forward current at
> 20mA. Does this mean I should really be running it at about 20mA or is
> that just the average they expect people to run it at? I am guessing
> it gets to point where it won't get much brighter no matter how much
> current is flowing? Although theoretically I could stick a bit less
> than 100mA through it if I really wanted to and it would be ok?
>
>

You can overdrive LEDs in pulse mode and I have heard they are okay. You
only drive them for a little bit. I do not have time to check the
datasheet but if it does say continuous then your pulsing implementation
is safe.

> Trev, worked out that the reason we were seeing the whole circuit
> taking 4mA even when asleep was that the programmer, even though not
> plugged into the computer was drawing current. I unplugged it from the
> programmer and now I get a measurement of about 4uA at idle which I
> think is about right :-)
>

Thats better. Excellent.

> Questions about veroboard were mainly best way to cut it up into
> smaller sections and best way to cut tracks. Will want to cut in
> between holes if I mount a 6 pin ISP header (which would be nice if I
> have the space).
>
>

Might be worth getting 6 pins and making a conversion header. I have
some spare header pins if you need some.

> I am currently playing in Eagle to try to get some sort of layout that
> fits it all in ;-)
>
>

I am tempted to say if you can lay the board out with cad (and want to)
I might be able to make the pcb for you. Its a great learning experience
and maybe thinking about it I will offer to make the actual pcb if you
want as long as you blog it as a project on fizzpop showing people how
the whole thing came together. Be a nice resource on the site for others
to learn from. And as you are learning yourself your blog will come from
the best angle for new people.

> Didn't go after the Perseids on Wednesday as it was too cloudy, but
> went last night and saw a couple before it clouded over. It's a bit
> rubbish, but had the shutter open and caught this:
>
> http://farm3.static.flickr.com/2468/3819666891_9f6937660b_b.jpg
>
>

That is an excellent photo!

> The smudged line in the middle is a meteor. Quite pleased for a first
> attempt, but it wouldn't have been possible without the remote so
> thanks again guys for all the input into this, I am learning loads :-)
>
>

This looks like something really positive that has come out of Fizzpop.
Well done Fizzpop.

Trev

[G Bulmer]

On Aug 14, 1:55 pm, Michael Nicholls <nicholls...@googlemail.com>
wrote:
> ...

>
> The problems with the code were as follows:
>
> I took the code I had working and simply turned on an empty compb
> interrupt and this caused the camera to stop being tirggered, even
> though putting in a standard LED showed that it was still pulsing.
>
> Using Trev's wonderful little digital oscilloscope we found that the
> 38.4 KHz pulse was fine, but the bursts were being miss timed. Trev
> then pointed out that given the fact the interrupt is called so often
> and I am using _delay_us with long delays would likely cause the code
> to fall out of sync as even though the impact of the interrupt is
> small, it would be quite large once applied to a delay of say 27ms
> which is the longest delay in the signal.

I think I don't understand the explanation.

As I understood the code, the LED was switched on and off in an
interrupt service routine.
I had a look at the source of delayMicroseconds.
Unfortunately, it switches off all interrupts (so that it can't be
stretched by the timer interrupt), so in retrospect, I don't really
understand how the 38.4KHz signal was okay if on/off was in an
interrupt routine.

> Other than that it turns out
> then the code I was going to put in the interrupt to switch the
> multiple pins on and often seemed to work, but the timing was a
> problem. So we said either a Transistor or possibly use a hardware
> timer to time the delays. In the end we went for a transistor and a
> resistor tweak and it all seems to work nicely. Got at least the same
> range we had that first night we got it working.
>
> I have since dropped a 33ohm resistor in with the LED so I work that
> out to be:
>
> V = 3 - 1.4 (FV LED) - 0.7 (FV Transistor)
> R = 33

Let me think about this. It doesn't look right.
The maximum output voltage from a pin of the ATtiny running at 3V is,
I think, 2.3V.
Maybe that "comes out in the wash", because you have reduced the 3V by
0.7V
The minimum LED forward voltage is 1.2V (typical is 1.4V, but you want
to use the worst case).
(Most of my electronics is dimly remembered, or the Art of
Electronics).

>
> I = 0.9 / 33 = 0.027 = 27mA
>
> From the data sheet (http://www.maplin.co.uk/Media/PDFs/yh70m.pdf) I
> can see that it has a Continuous Forward Current of 100mA,

Yes, that is the ABSOLUTE MAXIMUM continuous current.
It also says power dissipation is 100mW, but as the 38.4KHz signal is
50:50 mark space ratio (on to off), you should be okay.

> but other readings (e.g. Forward Voltage) are given with the forward current at
> 20mA. Does this mean I should really be running it at about 20mA or is
> that just the average they expect people to run it at?

Well, the datasheet quotes luminous intensity at 50 mA, so I would
assume that is okay (it also means there is a x2 safety factor built
in).

> I am guessing it gets to point where it won't get much brighter no matter how much
> current is flowing?

I really don't know, I can't remember seeing the curves plotted that
far, it usually stays well below absolute maximum. The 'curves' I can
remember are pretty straight lines.
I had assumed it just burns out before it stops getting brighter, but,
thinking about it, brightness does fall with tempertature, so maybe it
does reach a plateau.
I don't think this is relevant though, as you don't want to drive the
LED to the point where it is getting hot.

> Although theoretically I could stick a bit less
> than 100mA through it if I really wanted to and it would be ok?

Yes, that's what the spec says. It is normal to give yourself some
headroom,
If I were driving that continuously, I would drive at 50mA.
BUT, providing the software works, it'll never be on more than 50% of
the time, so I would run higher.
Having said that, I was told Lithium batteries have an initial voltage
several tenths of a volt higher. I'd need to google around to confirm
that.
So I would stay under 80% (or 80mA).

>
> Trev, worked out that the reason we were seeing the whole circuit
> taking 4mA even when asleep was that the programmer, even though not
> plugged into the computer was drawing current. I unplugged it from the
> programmer and now I get a measurement of about 4uA at idle which I
> think is about right :-)

Very good. Is that close to what the ATtiny consumes in the idle mode
you are using?

>
> Questions about veroboard were mainly best way to cut it up into
> smaller sections and best way to cut tracks.

I use a vice and hacksaw, or get a helpful chap to use his electric
bandsaw.
I use a Stanley knife or scalpel to cut tracks. I often cut the track
between holes using a scalpel from an art & craft shop (they were
pretty cheap)

> Will want to cut in
> between holes if I mount a 6 pin ISP header (which would be nice if I
> have the space).

Yes, that is straightforward with a scalpel. Just gently 'scribe' two
grooves near each other, between two holes, and keep cutting gently
until the scalpel blades gets through the track. You'll have a little
rectangular sliver of copper, which you remove. Well worth having a
check with a magnifying glass.

>
> I am currently playing in Eagle to try to get some sort of layout that
> fits it all in ;-)

Well, if you have the right libraries (and I am pretty sure they are
available), it shouldn't be too difficult.
This is probably a good circuit to practice on, as there aren't too
many components.

>
> Didn't go after the Perseids on Wednesday as it was too cloudy, but
> went last night and saw a couple before it clouded over. It's a bit
> rubbish, but had the shutter open and caught this:
>
> http://farm3.static.flickr.com/2468/3819666891_9f6937660b_b.jpg

Very nice. It maybe a smudge to you, but it's better than I have ever
photographed.

>
> The smudged line in the middle is a meteor. Quite pleased for a first
> attempt, but it wouldn't have been possible without the remote so
> thanks again guys for all the input into this, I am learning loads :-)
>
> Mike

Seeing pictures like that makes it all worthwhile.

GB-)

[G Bulmer]

On Aug 14, 2:24 pm, Trevor White <trevor.white...@googlemail.com>
wrote:
> Michael Nicholls wrote:
>> ...

>> I have since dropped a 33ohm resistor in with the LED so I work that
> > out to be:
>
> > V = 3 - 1.4 (FV LED) - 0.7 (FV Transistor)
> > R = 33
>
> > I = 0.9 / 33 = 0.027 = 27mA
>
> Not sure this calculation is correct. Is this for the series resistor
> with the transmitter LED. The transistor saturates and so is more likely
> to drop approx. 0.2 voltage. The 0.7 volt drop is across the base to
> emitter. The voltage across the collector emitter is different and what
> you are interested in.

I assume your electronics is better than mine, but don't you need to
be able to drive the base 0.7V about the emitter for that to be true?

>
> So you are more likely to want:
>
>  V = ( 3 - 1.4 ) - 0.2
>
> 1.4/33 = 44mA approx.

I accept my electronics isn't great, but doesn't it matter how all of
this is wired?
If it is effectively an emitter-follower, the transistor emitter can't
get higher than the base, and the base can only get to the voltage of
the ATtiny output pin, which, at 3V, is 2.3V.
Maybe I am missing something?

>
> > From the data sheet (http://www.maplin.co.uk/Media/PDFs/yh70m.pdf) I
> > can see that it has a Continuous Forward Current of 100mA, but other
> > readings (e.g. Forward Voltage) are given with the forward current at
> > 20mA. Does this mean I should really be running it at about 20mA or is
> > that just the average they expect people to run it at? I am guessing
> > it gets to point where it won't get much brighter no matter how much
> > current is flowing? Although theoretically I could stick a bit less
> > than 100mA through it if I really wanted to and it would be ok?
>
> You can overdrive LEDs in pulse mode and I have heard they are okay.

They certainly are.
Micromice often use very heavily driven LEDs as LEDs are used to
illuminate the maze walls, to provide a measure of distance.

> You
> only drive them for a little bit. I do not have time to check the
> datasheet but if it does say continuous then your pulsing implementation
> is safe.

The datasheet says "PEAK FORWORD CURRENT 1A", but at 300 pulses/
second, with each pulse of 1 microsecond, which is so low a duty cycle
as to be almost irrelevant.
I am pretty confident that 100mA would be fine, but I would leave some
headroom until it has been breadboarded and tested.

Several micromousers with high-power (well over maximum continuos)
pulsed LEDs have blown LEDs when they have hit a software bug (and it
is IR, so it takes a fraction more effort to discover).

GB

[Trevor White]

G Bulmer wrote:
>
>> Not sure this calculation is correct. Is this for the series resistor
>> with the transmitter LED. The transistor saturates and so is more likely
>> to drop approx. 0.2 voltage. The 0.7 volt drop is across the base to
>> emitter. The voltage across the collector emitter is different and what
>> you are interested in.
>>
> I assume your electronics is better than mine, but don't you need to
> be able to drive the base 0.7V about the emitter for that to be true?
>
>

See diagram below

>> So you are more likely to want:
>>
>> V = ( 3 - 1.4 ) - 0.2
>>
>> 1.4/33 = 44mA approx.
>>
> I accept my electronics isn't great, but doesn't it matter how all of
> this is wired?
> If it is effectively an emitter-follower, the transistor emitter can't
> get higher than the base, and the base can only get to the voltage of
> the ATtiny output pin, which, at 3V, is 2.3V.
> Maybe I am missing something?
>
>

I did not connect it that way. I drew a quick pic to show how I
connected it. You are right for an emitter follower. Was there a reason
to configure it this way?

Trev

[G Bulmer]

On Aug 18, 1:47 pm, Trevor White <trevor.white...@googlemail.com>
wrote:

Now that you ask, erm, no :-(

I have worried in the past that a logic-low of 0.6V wouldn't be low
enough to guarantee to switch *off* a transistor "at the bottom" (NPN,
emitter to ground) (Maybe that's why I like Darlington transistors?-).
So other than laziness (and the cost of a pull-down resistor), I have
no reason to wire it that way.

Sorry for the confusion.
GB

[G Bulmer]

On Aug 14, 2:24 pm, Trevor White <trevor.white...@googlemail.com>
wrote:
> Michael Nicholls wrote:
> > ...

>> I have since dropped a 33ohm resistor in with the LED so I work that
> > out to be:
>
> > V = 3 - 1.4 (FV LED) - 0.7 (FV Transistor)
> > R = 33
>
> > I = 0.9 / 33 = 0.027 = 27mA
>
> Not sure this calculation is correct. Is this for the series resistor
> with the transmitter LED. The transistor saturates and so is more likely
> to drop approx. 0.2 voltage. The 0.7 volt drop is across the base to
> emitter. The voltage across the collector emitter is different and what
> you are interested in.
>
> So you are more likely to want:
>
>  V = ( 3 - 1.4 ) - 0.2
>
> 1.4/33 = 44mA approx.
>

(Ooops - chopped this bit out by mistake)

So the voltage drop = Lithium Battery V - LED forward V - Transistor
Collector emitter saturation V
Wikipedia says Lithium batteries can be 3.7V open circuit, but I don't
think that is relevant, but may explain the comment I was given.

The LED spec says 1.2V forward voltage drop, is worst case, so
= 3V - 1.2V - 0.2V (assuming saturation voltage is 0.2V worst case)
= 1.6V

1.6V/33 ohm = 48mA (which is close to 50% max)

So, for 80mA (leaving 20% headroom)
R = 1.6V / 0.08A = 20 ohm, nearest larger preferred value is 22 ohm,
though 18 ohm should be okay (88mA)

GB

[Michael Nicholls]

Hey Guys,

Sorry it's been a while, lots going on and been ill for a few days.

Before some of the above posts I went with a 33ohm resistor and
proceeded to build the veroboard version. It is all in place and
works, just need to solder the IR led in once i have finished making
the hole for it at the front of the keyfob.

So hopefully version one is very near completion :-)

Thats a great offer Trev. Would love to do a proper PCB version. Think
that if it gets developed along the lines we were thinking then PCB
would be needed to fit things in better. I have had to drop the ISP
port as I couldn't fit it in. The battery is quite big ;-)

Quite keen to play about with an IR detector now. Use it to 'learn'
signals or receive commands from another remote.

Mike