Besides the features mentioned at the manual page, is this toy going to have extra buttons for standalone operation?
From the picture, I can only see TX, RX and GND provided. May be could use those to connect with another user interface board for standalone mobile usage.
I'm now standing by to place order for it at SeeedStudio but first would like to know its actual capability.
I'll post the complete writeup later today. There is a footprint on the back for a button that resets the chip in TV-B-Gone mode. It is NOT populated on the Seeed boards, it's strictly DIY (2 sided placement costs more). I don't think that's what you're looking for though, I didn't design this version for complete stand-alone operation, but it could be done.
A second version perhaps? a voltage regulator for stand alone operation, eeprom for capturing codes and a bunch of buttons would be awesome.
More buttons are a good idea.
The F2550 has 256bytes of internal EEPROM which can store a dozen or so RC5 codes at 10khz sample rate.
What supply did you have in mind? If you provide it with a 4.75-5.25volt supply you can get by without a regulator.
Maybe a different design would be better for portable use. Something with a slower clock speed (less power hungry) that could run on 2 AAAs or a coin cell. What kind of uses did you have in mind?
If I'm able to send in the codes for transmission and vice versa through the given serial header, then it would be enough to make it portable by adding another user interface controller.
I'm imagining this toy as a module which could be used on PC for transceiving and also could be hand-held to go around capture codes or fool with other IR devices.
By the way, can we use the +5V and GND on the ICSP to power the board instead of relying only on USB power?
From the datasheet, 18F2550 might be able to operate on 3.0V so using a couple of AA or AAA or even a coin cell might work.
The current firmware doesn't use the serial header, but it is USB upgradable so we can add stuff like that. The changing it to a UART instead of USB is just a few lines of code.
Sure, the 5volt pin on the ICSP header can be used to power it. You can also use the PGC/PGD pins as general I/O (for buttons, etc), I believe they have interrupts too. You could use the ICSP header to add a battery supply and two buttons (record, replay), two more with the UART pins (save to EEPROM, erase). A separate firmware without USB stuff could be loaded for this type of use, that way there's more RAM to buffer receives, and the clock could be slowed way down for better battery life (currently 48mhz for usb).
Was thinking a voltage regulator to just give something stable from a supply up to about 9v, could use a big eeprom to store raw codes like some of the codes in the tvbgone library, with a big one we could store the entire tvbgone db which would be awesome. This project can easily become what the unzap failed at.
[EDIT]
I was hoping to be able to use it to capture raw IR signals and save them to fiddle with later, dump them to the pc via usb for example. Maybe generate some similar codes, store them and go try them on the device you got the originals from.
I totally agree with s3c - capturing some ir-signals somewhere in the wild, dumping and analyze them on the pc, change them and replay them to the original target would definitely be fun (and of course enable some pranks :)
-> So a standalong capture/replay interface would be nice - because people often get quite suspicious when you point around with some 'naked' hardware attached to a laptop :)
Would be nice to know wether this might be possible by using another firmware version or wether the hardware would have to be changed as well.
It depends on how fast the data link will be. For low speed stuff, the pic can capture to 4K of ram and store the samples with very little power use. It won't work forever, but sleep with memory retention is really good. The PIC has 256 bytes of eeprom, which holds 2000 samples at 10khz sampling rate.
If something is just a UART over IR, then you could probably capture it by hacking the IR receiver and transmitter to connect to the UART pins. They're both through holed components, so it's not out of the realm of possibility. I didn't do the hardware that way because I thought it might be good to have the UART free to interface with data loggers, palm pilots, etc.
I don't know anything about the range of IR RX/TX techniques though, the IR toy is primarily aimed at experimenting with remote controls, and controlling TV/VCR/Cable boxes from the PC.
How do you store 2000 samples in just 256 bytes?
A bit more power would be pretty nice as well, maybe just up the number of IR leds, so Ian, any change of upgrading this project in the future?
Perhaps some day, but I just published this design today. You can hack the current hardware to have a more powerful emitter, or probably just use a smaller current limiting resistor.
8bits/byte * 256bytes = 2048 samples.
Sir Ian, to reduce cost and major hardware change, I would recommend you to release 2 types of hacking friendly firmwares.
First will have the original firmware added up with buttons on the pins you mentioned.
Second firmware will have both USB CDC and serial header enabled so that we could send in commands using either way of connections. It could be both connections allowed at once or either one only at an instance.
[quote author="ian"]
8bits/byte * 256bytes = 2048 samples.
[/quote]
Ah, I was thinking something way different, not sure how many codes that would be but think you could probably reduce the sampling rate.
The RC5 codes I captured were about 30 bytes long, probably fit 7 or 8 codes.
I was looking for hardware to simplify something like this on my laptop:
http://events.ccc.de/congress/2005/fahrplan/events/535.en.html (http://http://events.ccc.de/congress/2005/fahrplan/events/535.en.html)
Pretty interesting read, what about a free PCB for the first person to find an undocumented feature using the IR Toy?
Sure, I'll send a free PCB to the first 5 people who find undocumented features, or make software that automates known ir easter eggs, using the IR Toy. Great idea!
- Could use 2 of them for 9600-baud IR data transfer (for what it's worth)...
- You could always give one side a well-powered IR LED array (something like this.. was the first thing I found on google: http://www.mcmelectronics.com/product/28-8070 (http://http://www.mcmelectronics.com/product/28-8070) ) and go for long-distrance transmissions to a single receiver. If you're aiming it, you'd probably want to use a snoot on the giant transmitter and the little receiver to help aim the transmitted light and help keep stray light (like the sun) out of the receiver.
- You could always use it for the usual TV-B-Gone-type thing, or for even more fun, a "TV-B-On" to turn on TVs or ceiling-mounted projectors (especially in classes where the teachers can't find the remotes).
- If you have a sibling who likes to change channels on you, you could always use it as an IR-Jammer by basically flooding the receiver with 100% duty-cycle Infrared.
- If you were feeling especially masochistic, you could try decoding the GameBoy Color's IR protocol.
- Print to an IR-enabled printer
- Communicate with a palm pilot? Maybe have a terminal emulator on the palm or something over IR?
IR receivers are designed to filter out ambient light, that's why a switching carrier is needed, ie, a 100% duty cycle signal will be filtered out as well, any other duty cycle should work though.
A jammer is a great idea! That will go into the next firmware release because it's a simple, fun addition.
Actually, I added a test mode (post in a few days) for Seeed, it exits with the IR transmitter on at 38KHz so it can be inspected with a digital camera. That would probably do it.
[quote author="s3c"]
IR receivers are designed to filter out ambient light, that's why a switching carrier is needed, ie, a 100% duty cycle signal will be filtered out as well, any other duty cycle should work though.
[/quote]
Maybe a random duty cycle then? :D
It would be nice to be able to network two (or more) IR toys to for an IR repeater system.
I'd imagine it would be possible to connect two using the uart pins and some cat 5?
Should be easy but overkill, you could do the same with an IR receiver, wires, a couple of passives and a 555.
[quote author="s3c"]
Should be easy but overkill, you could do the same with an IR receiver, wires, a couple of passives and a 555.
[/quote]
Could you elaborate? How would you use the 555? Would it be for cleaner reproduction of the pulses? How would you set the 555's timing?
Thanks
(a software guy)
How far could one extend the IR receiver from the IR toy with just CAT 5 cable? Would additional components be necessary for filtering? Would it be possible to wire several IR receivers in parallel as long as only one was receiving at a time?
Thanks.
You could probably get several meters with cat 5 cable before it was too much to drive, I'm not sure though. The signal is very low speed.
I'm not sure about wiring then in ||, the receiver is open collector with an internal pull-up resistor, so I suppose it's electrically feasible. I'm not sure about interference in timing from the different receiver modules though.
[quote author="rct"]
[quote author="s3c"]
Should be easy but overkill, you could do the same with an IR receiver, wires, a couple of passives and a 555.
[/quote]
Could you elaborate? How would you use the 555? Would it be for cleaner reproduction of the pulses? How would you set the 555's timing?
Thanks
(a software guy)
[/quote]
The IR receiver strips the carrier from the signal so you'll need the 555 on the transmitting side to put it back, simply hook up the 555 in Astable mode with the same frequency as the transmitting remote. Connect the output of your receiver to the reset pin of the 555 through an inverting stage and you're all done. I'm guessing you'll get 10m with cat5 easy.
http://en.wikipedia.org/wiki/555_timer_IC (http://en.wikipedia.org/wiki/555_timer_IC)
http://tinyurl.com/ycr2lyt (http://tinyurl.com/ycr2lyt)
Hi
Any info on when the first pre-order will ship from seed ?.Ordered almost a month ago end also waited for their holiday to end but still no shipment.
Hi DTR2, sorry about the hold up. I think they're just about to ship. Last week they were almost ready, I'm hoping they ship this week sometime. I'll check with Seeed again on Monday and post an update here.
(Mine was shipped on the 20th, USPS tracking doesn't have anything useful to tell me about it yet. Today, I was able to use my Bus Pirate to record some IR signals today with just an IR receiver.)
In the meantime, here's a useful blog entry on some of the different methods of representing IR codes in repositories. It will probably help for grabbing codes from LIRC or the JP1 oriented hifi-remote site.
* http://www.arcfn.com/2010/03/understanding-sony-ir-remote-codes-lirc.html (http://http://www.arcfn.com/2010/03/understanding-sony-ir-remote-codes-lirc.html)
There is also this software called IR Scope, listed in the hifi-remote forum. Source is available, I don't know yet if it would be worth trying to get the USB IR toy emulate their existing usb device or whether it would be better to try to add usb ir toy support to ir scope.
* http://www.hifi-remote.com/forums/viewtopic.php?t=11668 (http://http://www.hifi-remote.com/forums/viewtopic.php?t=11668)
Thanks,
--Rob
If I recall the IRToy is LIRC compatible so you can probably use xmode2 as well.
The IRToy pretends to be a simple IRMAN receiver. LIRC (and about everything else) support irman.
If anyone is interested electronics-lab just posted an article of an IR remote extender that is basically the exact same design I was explaining in one of my previous posts:
http://www.electronics-lab.com/projects ... index.html (http://www.electronics-lab.com/projects/sensors/004/index.html)
[quote author="s3c"]
IR receivers are designed to filter out ambient light, that's why a switching carrier is needed, ie, a 100% duty cycle signal will be filtered out as well, any other duty cycle should work though.
[/quote]
IR receivers can indeed be swamped out by always on ir light if it is bright enough. How do you propose the receiver would detect the off time of the carrier if it were swamped with the same wavelength ir light? The carrier does make it resistant to false positives from the flicker of fluorescent lights though. The brighter the ambient light in the proper wavelength (~980nm) is, the less sensitive, to the carrier, the ir receiver becomes. All that said, you are absolutely correct that it would be much more efficient to just use the continuous 38khz carrier, even if at a very low duty cycle.
[quote author="ian"]
Sure, the 5volt pin on the ICSP header can be used to power it. You can also use the PGC/PGD pins as general I/O (for buttons, etc), I believe they have interrupts too. You could use the ICSP header to add a battery supply and two buttons (record, replay), two more with the UART pins (save to EEPROM, erase). A separate firmware without USB stuff could be loaded for this type of use, that way there's more RAM to buffer receives, and the clock could be slowed way down for better battery life (currently 48mhz for usb).
[/quote]
I like the direction this is going. Perhaps you could use each button for two functions. For example, holding the button for a long press could capture a code and assign it to that button, then a short press would play it back. This would be optimal if you could bring the rest of the unused io out to a header. Then you would basically have the ability to use it as a learning universal remote with two way communication. Hmmmmm, sounds pretty sweet, doesnt it?
[quote author="s3c"]
If I recall the IRToy is LIRC compatible so you can probably use xmode2 as well.
[/quote]
Regarding xmode2:
I'm probably missing something, if I try xmode2 -d /dev/ttyACM0 -H irman, I get an error that your device
isn't supported since it doesn't implement that pulse/space layer. This is with lirc 0.8.6.
XMODE2 won't work with the USB IR Toy or any IRMAN devices. I'm sorry, I wasn't clear on what is was until I googled it just now. For the uninitiated, it's basically a signal capture program that comes with lirc (my confusion) that's used to test interrupt-based serial port IR receivers (by timing the change in an interrupt pin on the serial port). It won't work with hardware that does on-board decoding:
http://www.lirc.org/html/xmode2.html (http://www.lirc.org/html/xmode2.html)
The main purpose of these programs is to check operation of your home-brew LIRC receiver hardware and to see the IR waveform of the remote controller without an expensive oscilloscope. Very useful for debugging. Of course this program won't work with hardware that decodes the signals itself like e.g. TV cards or the Irman.
[s:]Any more info on what is 'pulse/space layer'? Is there an alternate IRMAN mode you can try?
Some (very) old irman used the CTS/RTS lines in the handshake, but all modern implementations have the host say 'IR' and the irman device says 'OK'. The USB IR Toy just responds 'OK' to 'r' or 'R'. The protocol is 6bytes per command, pretty simple.[/s:]
Is the IRIO mode specific to the USB IR toy or is it something other IR devices do as well?
IRIO is a custom mode I 'made up' for raw IR input and output. I'm sure other devices do something similar, but I doubt it's with the same protocol.