It might help to talk a little bit more about your intended use cases. It sounds like you are envisioning the network as a universal transport for consumer IR with lots of actual IR endpoints (transmitters and receivers) attached to the network as needed. I had, I think somewhat similar ideas for a whole house IR repeating and routing system that was programmable by me in a high level language.
Unfortunately Consumer IR isn't really network friendly. If you look at the signaling layer it's all about timing -- information is typically encoded in the time intervals for IR pulses on/off. General purpose operating systems like Windows, *nix, Mac OS, and most networks especially TCP/UDP over IP over ethernet are non-deterministic when it comes to doing things with fixed timing constraints. Many of the IR "gateways" that are built to attach to computers use dedicated microcontrollers like the PIC or AVR, to handle the timing sensitive parts. (Note: the simple devices typically used with LIRC that didn't have dedicated microcontrollers, relied on device drivers and low-level access to interrupts in the host computer.
Many IR messages are simple commands like play, stop, pause, on/off. They may be repeated a few times for reliability, but typically don't continue sending the command as long as the button as held down. Controls like volume, fast forward, rewind, repeat for as long as the button is held down, so now you need to send two timing sensitive messages, button was pressed button released. A lost or delayed button released message can be extremely annoying.
Available products tend to do simple IR repeating, in which case they are copying the signal at close to the electrical level for turning the IR LEDs on and off, or IR gateways (receivers and/or transmitters) that attach to the computer. Due to the timing issues you typically don't see a hybrid system that can universally forward any remote signal. The protocols used in consumer IR and the frequencies vary widely. Part of the job of the engineers who build them is to make sure that no other existing remote signal is accidentally recognized so everything can peacefully co-exist.
Universal remotes, typically have a large "database" of IR signals that are stored in some sort of ROM-ish persistent storage. The manufacturer of the universal remote controllers tries to collect every available remote signal and figure out how to boil it down to some representation that will compact nicely for storage. Once the protocol is known, the commands like play, stop, etc. typically differ by only a few bits. See the JP1/hifi-remote forums for more info.
Learning remotes or sampling devices like the USB IR Toy detect the sequence of IR pulses and then send some sort of bit stream that represents the timing to the computer. These bit streams can be in the several K range. There are guesses that must be made like how long to wait in the absence of an IR pulse before decided that the current message is complete. This adds latency which makes trying to reproduce the signal somewhere else in real time that much harder. Repeaters that work at the electrical level don't have this problem.
Most likely you can accomplish some or all of what you want by doing things at a different level and adding some restrictions. If you deal with a set of known protocols, you can much more quickly recognize the signal, and turn it into a higher level message with the right semantics, Tell Device X to Play. On the sending side that message can be then turned back into the right sequence of IR flashes that will be recognized by the piece of consumer electronics you are trying to control. Picking good programmable / customizable universal remote controls would let you limit the number of protocols you have to deal with and let you simplify the recognition side.
The output side could be improved by selecting devices that can be controlled with direct digital connections (serial, ethernet/wifi). Fortunately the industry is moving in that direction and there are many "media center" type players.
On a somewhat related note, there has been some movement in standardizing consumer IR over RF which will help. RF transports has almost completely eliminated IRDA. It will take a lot longer but Consumer IR given the problems with line-of-sight, interference from CFL, and therefore LCD backlighting, is ripe to be replaced.
[quote author="dukey"] cat, try capturing in raw mode -f command line [/quote]
Dukey: Does the WinLIRC IR Toy plug-in do anything with the requested frequency setting from the LIRC config file?
Cat: If so, and you can get 'irrecord -f ' to create an LIRC config file, you can experiment by editing the frequency line. I'd try 40000, 50000, 56000.
[quote author="dukey"] But what RCT said, if the carrier frequency of the remote is non standard, ie 50khz, you'll fail to get a proper signal, it'll come out as garbage, unless of course your receiver is matched for the frequency. [/quote]
To the best of my knowledge that isn't necessarily the case, and nor what I implied, especially if the remote is close to the IR toy when capturing.
In order to eliminate interference, most consumer IR receiver modules whether they are detectors (QSE15x) or demodulators like the one used in the IR Toy have a band pass filter that is tuned for the desired carrier frequency. Signals at or near that frequency are allowed to pass with little or no drop in signal strength. The bigger the difference in frequency the more the filter should attenuate the signal. The result is that undesired signals should be eliminated though in reality they are reduced in strength to be at the level of noise. How much the signal is reduced depends on the design of the filter. Usually in the data sheet there is a diagram showing the filters response. Typically it looks like an inverted V. The X axis is the frequency, and the Y axis is how much the signal level is reduced. See figure 5 - http://www.vishay.com/docs/81733/tsop382.pdf
If the signal is very strong, for example as a result of being very close to the receiver, it's level will be reduced, but since it is very strong to start with, the resulting signal may be well above the noise level and will still be recognizable.
So I believe you should be able to capture a good representation of the signal with the original remote very close to the IR Toy even if the carrier frequency is in the 50+ khz range. Where the problem comes in is in transmitting the signal from the IR toy and getting it to the devices IR receiver. If there is a mismatch in carrier frequency, and there is a reasonable distance between the IR Toy and the device, the signal may wind up being filtered out.
Since the carrier frequency isn't known, I'd try sending the captured signal at different carrier frequencies as well as getting the IR Toy as close to the device as possible. However, I don't know if any of the current IR Toy send/receive utilities have the ability to specify changing the carrier signal. The default send carrier frequency of the IR toy is 36 khz. I think it should really be 38 khz to be better centered on the most common frequency.
Note: The .bin files do not contain any carrier frequency information. They only contain raw timings. Personally, I think the .bin format should be abandoned.
What I observe is that I never get the same recording. If I repeat the capture at a fixed distance I see similar patterns but different raw data.
Within reason, that is to be expected, you are basically looking at a signal that has been sampled. There are many reasons for variations when sampling. it is the pattern, which is typically in multiples of 100's of microseconds that is decoded. The signal you posted was in multiples of 500-600 us patterns of on/off times. Guessing from your captures, a zero is approx. 500 us on (ir led pulsing at carrier frequency) and ~500 us off (no ir led pulses), where a one is ~500 us on followed by 3 x ~500 us off time.
As far as the carrier frequency:
Most IR protocols are near 38 khz. With the most common ones being 38 khz and 40 khz. There are some that are at 50+ khz, and a rare few that are at 455 khz. The IR demodulator on the IR Toy seems to be picking up the signal though it seems a little like it might be a little short from the two samples you provided. If your remote is 50+ khz, it may be capturing it fine, but when the IR toy send it's it needs to be using the higher carrier frequency otherwise it will be filtered out by the AC's IR demodulator unless it's really close. I don't remember if any of the record/playback applications let you change the carrier timings. The same rough durations for on and off times will be used but the number of times the IR LED is pulsed during on times will vary.
[quote author="cat"] Regarding your comment on ditto frames and trying to keep the button pressed for a longer time when sampling, I don't think it applies. This is an air conditioner remote, the commands are all one time and the remote is statefull. In fact there is an icon on the remote screen that indicates when a signal is being sent (I verified this with a camera looking at the IR beam). The commands are short 1 second bursts. [/quote]
The .bin files you posted are both approximately 175 milliseoonds long. Look at the graph in IRScope, the time values on the left are in microseconds. ISome remote protocols aren't complete until they see a repeat of some form. May not be your problem, but if the actual remote seems to be flashing for anything close to a second (or even half second) there are probably some repeats in there.
First simple question, what's the distance between the IR Toy and the AC when you try sending the signal? Have you tried sending the captured signal with the IRToy as close to the AC as you can get it? The early IR Toy doesn't have a lot of range, due to the IR LED used and the overly conservative current limiting resistor.
Two things come to mind:
Looking at http://www.hifi-remote.com/johnsfine/DecodeIR.html, 48-NEC2, should repeat itself through "ditto frames", which aren't complete copies but usually have the long lead in signal, and some short bit to just say "Ditto" to indicate the button is still being held down. However, looking at IRScope, I don't see any ditto frames captured. it says there are two complete copies but no dittos. Many manufacturers vary the protocols, so it's possible your remote doesn't use it, however, I would try capturing the signal again, holding down the button for longer to see if you get ditto frames. If the rest of your captures look the same, then don't worry about it, that implementation may not utilize ditto frames. However if it does and you didn't capture any it could be that the AC is ignoring the signal since it doesn't see at least one.
Unfortunately there are no clues about the carrier frequency from the info available. I believe the NEC protocols are typically in the 38-40khz range which is pretty standard. You could try varying the carrier frequency to see if the AC will recognize it.
Quote
Can I somehow use this info to tell WinLIRC or EventGhost to re-create the command?
Technically yes, you have enough information from IRScope to create a LIRC configuration file, though you have to do it by hand. I don't know of any direct utilities. The timings are in the file and show in the summary screen. I haven't used WinLIRC, but I think there should also be a way of doing captures using the WinLIRC utilities as long as you are using the full sampling mode plugin and not the IRman compatible mode.
Can you capture and play back other IR Signals? Have you verified that your IR Toy doesn't have the IR LED installed backwards? Can you see it send a signal with a digital camera like a cell phone camera?
Have you looked at the captured signal? There are several methods you can use depending on what platform you are on. My preferred method is to convert the .bin file to an .ict file that can be loaded into IRScope on a windows box. If IRScope can identify the IR protocol used you might be able to find the carrier frequency.
First question is what do you want to do with it? What kind of signals are you measuring?
Before you buy anything, I would try to understand the sampling capabilities of all, and try to get a handle on what all the sampling terminology means. Currently you have your Bus Pirate which can measure 0-5.5, providing something on the order of 6000 samples per second (6 khz) at 10 bit resolution. I think there was a proposal to provide an 8 bit sample mode which would allow for more samples per second. Using the sound card input on the computer with a probe circuit can get you into sampling rates in the 20-40 khz range. However, you can only measure AC signals. If there is any non-alternating current part of the signal, you won't see it, since the input has a capacitor that is used to block DC in order to provide "AC coupling".
FWIW, I originally was looking at other small cheap scopes, mostly USB types rather than standalone like the DSO nano. After reading enough it became clear to me that the limitations, especially when coupled with my inexperience probably wouldn't give me very useful results. I could miss a lot, especially if I didn't understand the many limitations of the test equipment at hand. Note: you always really need to understand your test equipment's limitations in order to get useful measurements, but the situation is must worse with severely limited equipment. So after reading many different forum posts, I eventually purchased a standalone DSO, the Rigol DS-1052E 50 Mhz, which is available for approx. $400 US from reasonable dealers, no just china direct. I'm very happy with it. I've learned and understood quite a bit from using it and experimenting. I was originally concerned about the physical size of keeping a scope around, but the new DSOs are really pretty compact. Check out the EEVblog reviews.
I could be wrong, but I think the problem is that you are expecting to see data come in from doing a 'cat < /dev/ttyUSB0' on the USB IR Toy. There are several things that can go wrong with that, so I wouldn't use that method to test.
If you use a terminal program, such as Minicom, when you type a 'T' at the USB IR Toy, do you get any response? It should be a V10x.
Note: in the mode the USB IR Toy powers up in, IR man compatible mode, it will only decode RC-5 format IR signals, it will ignore everything else. Many of the applications that use the USB IR Toy, since as the WinLIRC plugin, put the USB IR Toy in sampling mode. In sampling mode, no decoding is done, the IR Toy sends raw samples, so any remote will work.
I believe the current state for LIRC, (not winLIRC), is that the USB IR Toy is only usable in IR man compatible mode, so a remote that sends RC-5 is required. Media center remotes (you mentioned mce-usb for some unknown reason, send a variant of RC-5 or RC-6. I believe they will be ignored by the USB IR Toy in ir man compatible mode (the default mode). This is different that using WinLIRC with the plugin since it uses raw mode and will send data for any remote signal.
[quote author="wasyu"] I installed IR-TOY on Ubuntu 10.10 by reading the online manual "http://dangerousprototypes.com/docs/USB_IR_Toy:_Configure_LIRC". But I got error.
dmesg: ============================================= [40172.158734] usbserial_generic 2-2:1.0: Generic device with no bulk out, not allowed. [40172.158755] usbserial_generic: probe of 2-2:1.0 failed with error -5 [/quote]
I've never seen this message before. However the rest of the log says it did assign it a port, so the usb-serial driver is attached to that device.
Quote
[40172.158928] usbserial_generic 2-2:1.1: generic converter detected [40172.159184] usb 2-2: generic converter now attached to ttyUSB0
You didn't provide much info, so it's 20 question time. First step is can you communicate with the serial device without LIRC being involved?
Can you open /dev/ttyUSB0? Do you get an error? Can you use a terminal program (screen, minicom, microcom, putty, etc.) to see if you are communicating with the USB IR Toy? Try running a self test.
[quote author="st0rm"] My IR toy has the firmware version 1.05. [/quote]
Try upgrading the firmware on the IRToy to the current version v09a. Transmitting in IR sampling mode didn't make it into the firmware until v07 I believe.
BOM has 0.1uF on the crystal. Duh. My fault, apologies all around. [/quote]
noob question: I notice that many of the AVR designs use a ceramic resonator instead of a crystal and loading caps. It it a difference in the MCU design or a just a per (board) designer's preference?
[quote author="jamz"] There is a new update at the svn for the irtoy rec and play app. its currently on version 0.06 [/quote]
Thank you for working on this. Please take this comment constructively -- there are now 6 different versions of IRToy Record and Play in the source code control system. (That's not even counting the .save versions of the source in each directory.) I hope I'm not out of line, but I suggest using the source code control system (SVN) to handle the version management for you instead of making lots of copies.
