next topic »

[on:]

Has anyone ever tried making a bootloader that could program an AVR using a photocell? (Like the old Timex Datalink watches)
If it hasn't already been done, I'm thinking of trying it.  I think it has some interesting potential.
You could reprogram a device by playing a Youtube video on your phone.
You could batch-program a bunch of devices by holding them all up to the screen (or holding the screen over them).
If you had a bunch of devices scattered around a room, a few well-aimed bright LEDs could reprogram the devices when the lights are out.  Or, maybe use controlled flashing of the room lights.
I'm sure it would be slow, but I can't help but think it must be possible somehow.  Am I completely insane?

[Reply #1 on:]

I'm not sure how practical the idea is but yes a bootloader can get it's data from wherever you like, including an LDR.

_____
Rob

[Reply #2 on:]

Is there something code or hardware related that you think would make this impractical?  I'm just curious if you have any specific reasons, or if it just fills you with a general sense of unease.
My biggest worry is how long programming might take.  Using a YouTube video on a phone or something, I think it would be tough to get more than 30 bits/second (or whatever the video framerate is) without a much more complicated mechanism.  Similarly, even a dedicated app on a desktop PC would be limited by the 60Hz refresh rate of a monitor.  The only way to do fast programming would be to use an LED, I would imagine.

[Reply #3 on:]

Is there something code or hardware related that you think would make this impractical?  I'm just curious if you have any specific reasons, or if it just fills you with a general sense of unease.
My biggest worry is how long programming might take.  Using a YouTube video on a phone or something, I think it would be tough to get more than 30 bits/second (or whatever the video framerate is) without a much more complicated mechanism.  Similarly, even a dedicated app on a desktop PC would be limited by the 60Hz refresh rate of a monitor.  The only way to do fast programming would be to use an LED, I would imagine.

There's actually a technology out there that uses LED lamp sources (like in an office environment, that replace overhead fluorescent bulbs) for high-speed networking, termed "li-fi":

http://www.economist.com/node/21543470

Also, there is (was?) the IRDA standard (http://en.wikipedia.org/wiki/Infrared_Data_Association) for optical data transfer. It used to be something installed on laptops and printers, mainly - but you don't see it much (if at all?) any more.

I can see what the OP wants being possible, using high-brightness IR LEDs (or clusters), and IR receiver modules (or maybe a photocell/phototransistor as proposed - but I think a proper module would be better); it seems like it would basically just be a hardware issue. The best way to experiment would be to hook up an FTDI cable (to get TTL serial from the PC) to a circuit doing IR TX/RX, and on the other end having the same thing, but connected to pins 0 and 1 on the Arduino.

In fact, a quick google of "IR serial" turned this up:

http://iguanaworks.net/products/series-transceiver/

/once again, something the OP could've done... 

[Reply #4 on:]

Light is not a very reliable form of communications.

Batch programming is a problem because there's no easy way for each device to report errors without a protocol.

IR would be better and a lot faster but you need to decode the IR signal.

All this points to quite a lot of code and a bootloader should be small or there's no room for the program.

That said it can be done, have a look at these little fellows

http://www.eecs.harvard.edu/ssr/projects/progSA/kilobot.html

They are all programmed from a central IR transmitter.

Whether or not it's worth the effort in your case it up to you

______
Rob

[Reply #5 on:]

This is another source that may be helpful:

http://www.lirc.org/

[Reply #6 on:]

Thanks for the feedback folks.

I guess it looks like doing programming via a video on a screen is unfeasible.  I thought it would be an interesting way for users to flash a device in-the-field without needing any special hardware (just a smartphone), but realistically, it's probably too slow.  I suppose it *might* be useful for something, but I'll probably focus my efforts elsewhere.

I've heard about that "Li-Fi" technology before.  That's actually what gave me the idea of using the room lighting to program devices.

I've seen IR serial modules before, but I couldn't find any references to Arduino bootloaders that would use IR.  It only just occurred to me to try searching for AVR bootloaders instead, and I've found a couple possible examples:
http://thedenneys.org/pub/robot/avr/
http://avrirdownloader.wordpress.com/

That Killobot project looks really interesting.  I'll have to dig into that a bunch more if I decide to spend some time on this, rather than just daydreaming about it.

[Reply #7 on:]

I'm currently working on this as a small part of an ongoing project.
The first step was getting the boot loader to compile which I detailed here:
http://n0m1.com/2012/04/01/how-to-compiling-the-arduino-bootloader/

And I've now added a 38kHz pwm to the boot loader, to modulate the outgoing IR...
It will be similar to the Asuro IR boot loader, 9600 baud.
When I get it working, I'll blog the details...

Michael
http://n0m1.com/

[Reply #8 on:]

t looks like doing programming via a video on a screen is unfeasible.

It sounds like it would be unacceptably slow.  (internet) Video normally plays at 10 to 30 frames/sec, and you'd be looking at no more than 1 bit per frame...

(now, somebody did a bootloader over audio port, which has some similar properties in terms of distribution media...)

[Reply #9 on:]

Screen programming could be faster if different colors are used, something akin to FSK as opposed to OOK...

The 38kHz 2400 baud IR bootloader I'm working on is almost going.
But I've just discovered the IR demodulators I'm using are not rated for continuous operation. 
After a few bits in a row, exceeding a certain duty cycle, the demodulator stops responding.
I have some TSOP58038 parts on order, rated for continuous, that should fix this.

With 2400 baud and ten bits per byte (8 + start and stop) we get 16 carrier waves (@ 38Khz) in a single bit.
The carrier wavelength being 26.3us and the the baud bit length being 426us.
There is some phase shift (about 8 wavelengths) as a result of the demodulation circuit that prevents it from being any faster.

Interestingly, IRDA specifies the carrier to be 3/16 the wavelength of the bit length.
So the carrier for 115k baud is 614 kHz, and the carrier for 9600 baud is 51kHz. 
This is considerably better than the 1/16th I'm getting with the 38kHz TV remote demods..
 
I've also looked at the audio bootloader.
It's going to have the same speed issue as 38kHz IR, a little slower, the maximum carrier will be 20kHz.
At least with audio, multiple carries can be used for a multi-bit FSK scheme.
But that would require either decoding FSK in the AVR or some external analog filters...

Michael
http://www.n0m1.com

[Reply #10 on:]

After a few bits in a row, exceeding a certain duty cycle, the demodulator stops responding.

Maybe they are designed for Manchester encoding where there is no DC build up.

______
Rob

[Reply #11 on:]

Some of the datasheets for these parts indicate less than 20% duty cycle which is about what I'm seeing.
The continuous bit stream I want to send them probably averages very close to 50%.
I suspect the shutdown is due to the automatic gain control circuitry.

I now understand why the NEC protocol has a specific command for repeated hold.
The repeat code is extremely low duty cycle...

The datasheet for one of the parts I've tried (TFM5360) is quite revealing.
According to page 5, the suitable TFM part is the TFM1xx0 series...   

[Reply #12 on:]

I've just finished up the post for the IR bootloader.
The maximum reliable speed obtained is around 4000 baud, not fast but not terrible...

The info, source and video is here:
http://n0m1.com/2012/05/07/superduplex-an-infrared-bootloader-for-arduino/

[Reply #13 on:]

Nice job, this could be very useful for code updates in the field, especially when having a socket on the enclosure is not possible or desirable.

______
Rob

[Reply #14 on:]

Nice job

Thanks! 

It was quite a bit of work getting everything to play nice together, especially the half duplex timings and the phase delay...
Looks like it just made Hackaday: http://hackaday.com/2012/05/07/program-your-arduino-via-ir-using-the-arduino-ide/