Skip to main content


This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - rct

USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
[quote author="pio"]The IR Widget is not a substitute for the IR Toy, it just saves you the trouble of having to flash the IR Toy twice and use a jumper to do so.[/quote]

Considering a IR Widget from Tommy Tyler will cost $25 US (or $50 US if you live in a state Obama won), you could just get a 2nd USB IR Toy rather than buy an IR Widget.  (If you live in one of the affected states, you could get two IR toys and still have some money left over vs. an IR Widget).  Sure the IR Toy doesn't come with a nice case like the IR Widget does, but you won't have someone's politics forced on you.

[quote author="pio"]Another option is to integrate the IR Widget functionality as another mode, although that could require modification of the IR Scope software.[/quote]

I think this would be a good option if you can find an interested party who has an MS VC++ license and already has that development option set up.
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
Interesting, given that he can't keep his politics out of his business, I'd have no problem letting people know the IRToy 2 is a much more capable device than the IR widget and clearly the better deal.

If I had a license for MS Visual C++, I'd modify IRScope to be IRToy 2 friendly (talk to it using serial data instead of trying to signal with RTS/DTR.  I've looked through the code, as I recall adding support for a new device shouldn't be that hard, there are about three or four places where the device types are coded.  The most complexity in it is from support for the microcontroller-less widget that shifts in samples at 115K baud and doesn't use the same sample buckets as the widgets with an actual controller.

Note: IRScope can't be compiled with the free MS express compiler as it relies on Microsoft libraries that are only available with the paid version of Visual C++.  I think it's Microsoft Foundation Classes. 

Note 2:  It's been a year or two since I looked at any of this.

Happy New Year all.
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
First, I'm curious as to whether you actually get different protocol decoding results using the IrWidget emulation firmware for the USB IR Toy.

I built an ATTiny based IR Widget clone using a circuit and firmware provided by the original author,  (I didn't built the PIC version because I didn't have a programmer)

For some of remotes, I tried, I got similar results because the hand tuned protocol details that pick out the device and command numbers hadn't been added to IRdecode, the component used by IRScope to identify protocols.
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
[quote author="osbock"]Is this what you are thinking?
 If IRScope never sends anything to the IR Widget
1. Some other program sends code to set into IR Widget mode. Mode stored in eeprom as default for power cycles
2. If you want to change it back, the IR widget mode could listen for a specific code being sent to it, and switch the default mode back?[/quote]

For the IR Toy to work with IRscope and any other software that uses the IRWidget without modifications, yes, I think that is the only way. 

On the other hand, the current IRwidget protocol/handshaking, using DTR/RTS, etc. is very limiting, so it might be better in the long run to see if the current maintainer of IRScope, (mathdon on the hifi-remote forum) will accept changes for supporting the iR toy that put it into the right mode and start capture by sending characters instead of using signal lines.
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
[quote author="osbock"]What confused me was that it is off from what I expected, and measured with a real scope. I assume it's some sort of undersampling error. At what frequency is it sampling?[/quote]

The IR Widget protocol sends the number of IR pulses it saw during a 100 us window.  The intent of the IR Widget (and IR Scope) counting IR pulses rather than durations is to avoid the errors that occur with IR demodulators determining when an on period has ended.  IR demodulators can add 50-75 us to the on period while waiting 'long enough' (the absence of pulses) to drop the output.

What device did you have connected to the scope to see the IR?  If it was an IR demodulator you saw the error even if you were using a 'real scope'.  If you don't have an IR detector, try using an IR LED as a photo-voltaic device.  The sending remote needs to be as close as you can get it to the IR LED.  With a remote that didn't have any plastic window, I was able to observe pulses of nearly 1 volt with just the oscilloscope and an IR LED.  Note: the red window on some remotes can block too much of the signal to generate enough voltage in the LEDs.
USB Infrared Toy / Re: IR TOY2 does IRscope2 (IR Widget)
There is an IR Scope and IR Widget User's Guide on the Hifi Remote (JP1) Wiki that will be useful to those trying IRScope for the first time.

It would be nice to see the USB IR Toy be fairly plug and play with IRScope.  Currently IRScope never sends anything out the serial port to the IR Widget.  Instead it uses raising and lowering of DTR or RTS to reset and signal what mode to use. 

I've looked through the IRScope source code.  It looks like it wouldn't be too hard to add support for additional hardware.  There are maybe 3 or 4 places in the code that would need to change.  Unfortunately you need the MS VC++ compiler to compile it since it uses MFC.  I don't have a license for it and the freely downloadable express compilers exclude MFC.

Note: Somewhat understandably, the people behind irscope/irwidget strongly request that support not be added for devices that use IR demodulators only like the original IR Toy V1 because the IR demodulators do not give accurate representations of the IR signal.  The IR Widget and IR Toy V2 can do IR pulse counting which gives a more accurate representation of the signal which is more important if you are trying to learn the signals for sending via learning remotes.

Hope This Helps,
General discussion / new forum styling.
Is it just me or is the font on the new forum smaller (or just harder to read) than the old one?

Also, I don't know if it's an intentional design choice, the width of the forum display, (the gray bordered white box) is fixed width.  If your browser window is too narrow you get a scroll bar,  too big and you wind up with lots of dark gray around the sides.  It makes the actually text part feel cramped on a high res display.

General discussion / Getting somewhat random notifications from the forum.
Is anyone else getting somewhat random notifications from the new forum?

In the past couple of days I've believe I've seen some correct notifications, where the link seems to take me to a new message in a forum I'm subscribed to.  However others:
- Notifications to topics that don't appear to have been updated.  Like this one:  viewtopic.php?f=41&t=1447&p=17267&e=17267

- This one also doesn't appear to be updated.  It's about compiling pirate loader with MinGW, but it's in the Pirate PIC Programmer forum.    Was this topic in the wrong thread originally or is it some misbehavior

- Another one that doesn't appear to be updated, viewtopic.php?f=28&t=991&p=17189&e=17189
AVRDude / Re: avrdude: initialization failed, rc=-2
[quote author="rct"]
2. AVRdude isn't getting responses from the target avr.   You don't have it wired correctly or it's a bad chip, wrong target type, etc.

Forgot to mention this class of error can also occur if your fuse settings aren't correct/don't match your target environment.  For example, if you've set the fuses to use an external crystal / resonator as a clock source, but don't have one during programming.

Note: I've seen some instructions for programming the Arduino boot loader onto a fresh ATmega chip that set the fuses first and program the chip second.  If you are doing this with the bare chip connected to the programmer, the first step setting the fuses will succeed, however the 2nd step will then fail because you've now programmed the chip to operate with a 16 mhz clock that doesn't exist.   So to be able to talk to the chip again, you need to connect a clock source or place it in an arduino style board and connect to the isp connector.    Reversing the instructions so you program the bootloader first, and then change the fuses last once you are sure you are done programming.

Hope this helps,
AVRDude / Re: avrdude: initialization failed, rc=-2
Can you copy and paste your output?  

Off the top of my head, I think you have the right versions of avrdude and the bus pirate firmware.

There are two common error cases for "initialization failed, rc=..."

1. AVRdude can't talk to the programmer.   Which could be you don't have the right port, or you have one of the bad combinations of avrdude and buspirate firmware"

2. AVRdude isn't getting responses from the target avr.   You don't have it wired correctly or it's a bad chip, wrong target type, etc.
USB Infrared Toy / Re: Software Wanted
[quote author="vk2tds"]
I think what I am hearing is that if I want to do this without needing to learn all the remotes is to take this down a level and go closer to hardware. This would mean detecting the Ton/Toff times, transmitting them and then remodulating. And as you say, this would cause issues as operating systems tend to be non-deterministic with timing.

I think what I need to do is work on a more electrical layer device to do what I want, possibly connected to a USBIRT. Something with up to eight IR receivers, connected to a matrix and then to up to 8 IR diodes. Oh, and also connect to the Input and Output of the USBIRT. Given than I have about a mile of CAT-5 in my home, I dont think it will be a problem connecting the repeaters up.

I may not really understand your requirements, but if I overlay my feelings towards home automation, etc. on top of them, I think you do want to do things at a higher level, especially in the middle and only deal with IR when necessary at the end points.    As far as "learning" all the remotes, it's not that you need to try and record every single button press from every remote.   Once you determine what protocol your remotes are using you can usually look up the details.     In many cases you can differentiate the remote and the signal by only looking at the timing of the first lead-in on/off pulse.

Also, do you really want to use the remotes that came with your consumer electronics?   Or are you already using a programmable remote?   Would you rather use a tablet/phone/ipod touch as the remote?    If you are using a programmable remote than on the input side you could use the IR codes from a manufacturer that mades a wide range of devlces like Sony.   This could really simplify any recognition code, not to mention eliminating the latency involved in trying to figure out whether you've received the whole signal yet.

Also if it were up to me, I'd be thinking about how much longer am I going to be thinking about controlling cable boxes.  (actually in my house all of the cable boxes have DVRs (Tivo) in front of them.   The newer Tivo's can be remote controlled via IP, there are iphone/android remotes apps available)

Do you currently have a stand alone, non-network connected bluray player?  

I started playing in this area with the Sony 200 disc CD jukeboxes around 1995.   Eventually there was a product the Slink-e from, which started in a UCB dorm room by an EE student.   The later slinke's could do 8 ir zone's.    It was a pretty cool PIC based system for it's time.  Eventually microsoft bought the IP.    Not much need for a CD jukebox these days, by about 2000 all of my CDs were fully ripped.    I still use a Sony receiver that is controllable via s-link as the receiver in the basement that is driving a number of the speakers throughout the house.

Anyway, that's kind of a roundabout way of says, I think your IR end points will slowly fade away and the central semantic control is where the meat in your requirements are.

I don't know if this really helps at all, or if I've just babbled incoherently.

USB Infrared Toy / Re: Extend IRtoy with RF- Anyone knows?
[quote author="rsdio"]
USB IR Toy can transmit on any carrier frequency, but it can only receive on one.

At the risk of being pedantic that isn't technically correct.    The IR demodulator receives a range of frequencies, however the filter in it, reduces the strength of signals that aren't at the same frequency as the filter is designed for.

I just noticed the sensitivity graph for the Panasonic PNA 4602 detector in the LadyAda tutorial is in percent of sensitivity instead of the usually decibel scale, so it's a bit easier to read.   According to that graph, the detector has 100% sensitivity for signals at 38 khz.   However, it's sensitivity to signals at 36 khz or 40 khz is only 50% of it's sensitivity at 38 khz.    (IIRC the detector used by the USB IR Toy had nearly the same -3 dbi drop for being 2 khz off the center frequency.

USB Infrared Toy / Re: Extend IRtoy with RF- Anyone knows?
[quote author="tsachi"]
I was wondering if anyone tried to send the IR pulse to a RF transmitter -> RF receiver and have some IR emmiting circuit connected to the receiver, in order to get the IR pulses go through walls. Basically a DIY IR extender.

There are actually quite of few of these types of devices around as products if you look for "IR remote extender".    Some of the higher end universal remotes have an option for an RF transmitter in the remote.   There appear to be some projects described if you search for schematics and/or circuit.  The majority of the DIY IR repeater projects I've come across are for hardwired IR repeaters.   If all you want to do is repeat the IR signal, you don't really get a lot of benefit from using the a microcontroller based system like the USB IR Toy.  However as soon as you want to do things that are more complicated, microcontrollers are the way to go.

There are two levels of looking at IR signals.   There is the logical level which is the longer On/Off times that you see from the USB IR Toy or other devices that receive IR by using an IR demodulator.   To avoid interference IR signals are actually sent similar to radio ways.  The sending IR LED is flashed on/off rapidly during the length of the on periods you see at the "logical' level.   This is referred to as a modulated signal.   The frequency of the on/off flashes allows the IR receivers to be tuned to that frequency which helps eliminate interference from other sources of IR light.

If your radios have enough bandwidth you could send the rapid IR pulses that make up the carrier signal, and you'd be able to repeat a very wide range of IR signals.   

On the other hand if you could just send the demodulated signal, aka the logical signal, which has the on/off carrier pulses removed, you'd be restricted to a smaller range of IR signals but: you'd require less bandwidth from the radios, you'd be able to send a cleaner, more "digital" signal that would be less prone to interference.

A few IR tutorials that may help.   Note: so far I haven't found one tutorial that covers everything, they all cover parts:

General discussion / Re: DP forum configuration
I know I ran into a problem with .py in the past, you may have already added these, just in case:

.py  - python
.pl  .pm  - perl
.bin  - ir toy captures