[quote author="Barf"] The short version: it is stable. It makes sending and receiving an atomic command; You just send a "send" command over the "serial" line (with parameters), and the hardware sends it. This is in contrast to the IrToy which needs to be fed with data every few milliseconds. Analogous with receiving. BTW, using IrScrutinizer, the IrToy is also very stable and reliable.[/quote] That sounds interesting and promising. Is there any reason this wouldn't work with the rPi that you can think of? I don't know as if there is a python library currently to work with your tool, which could be problematic for me... [quote author="Barf"] In IrScrutinizer, I keep the port open all of the time.[/quote] Okay, perhaps that is where I am going wrong. I open and close the port between "jobs", which run at 15m intervals. I think it also might have to do with a Linux Kernel setting for power management on the USB-bus, because my Wi-Fi adapter soemtimes will be put to sleep and not recover.
[quote author="Barf"]If I understand you correctly, you have not (successfully) used the IrToy with any application; you try it with the pyirtoy library, and that does not work. And pyirtoy says that the "other guy" is to blame... I would suggest that you try (using FW 22!) IrScrutinizer and/or some other alternative, to see if that works
Quote
can anyone recommend a suitable replacement that isn't so poorly made?
This is my "toy".[/quote] No, I've used it semi-successfully in the past with the Play/Rec demo program, but I never figured out how to get that ported to armhf to run on my Raspberry Pi, so I abandoned that line of development a few years ago. I just recently picked this back up with Python.
I got around the problem causing my toy to not send IR codes from file and only from memory.
Your device looks really well made. How stable is it? Does it randomly hang up and require being plugged/unplugged like the USB IRToy does?
[quote author="Simpkins"]Agree with Bart. I'm using the irtoy with other software and it plays from files ok. Not that there is anything different between playing from a file or from memory as for as the irtoy knows.[/quote] No, there isn't. I had made a stupid mistake in my code. Now I'm fighting to get it to not randomly hang up after sending/receiving a number of codes in a row.
Supposedly the v24 firmware had fixed an overrun/timing issue that would lead to this instability, but it still hangs up on my rPi after a while of usage.
Are there best practices to avoid this condition? Keep the port open the entire job? Open the port to send and immediately close it after send?
Unfortunately, I can't seem to find a programmatic way to reset the device/port when it hangs up. Even rebooting doesn't always get it out of the "yellow light" state.
I'm finally getting into using my IRToy to capture/repeat some signals. I've run everything below on both firmwares v22 and v24, and under Windows (10 x64 pro) and Raspbian Linux (4.4.9, armhf). Behavior is exactly the same in both places.
I'm using the pyirtoy Python3 library to capture and repeat infrared signals. This goes perfectly fine provided I don't write out the captured signal to a file. If I repeat the signal from memory, the IRToy will play back the signal just fine.
If I instead run my other python script which just plays the file from a stored file, the IRToy will error out and crash the script.
Can anyone help me debug this? I can't understand what is happening to make it error when reading a file, but it has no problems transmitting a code from memory.
Oh, okay. I thought the "simple" nature of the Play/Rec program made it ideal.
What I'm looking to do is to use CRON to play back certain captured IR commands at certain times of the day. I know I can do that with a binary like the Play/Rec program, but I have no idea if I can pass commands like that using CRON to a java program. I'm also likely to be running headless and just poking at my Pi via SSH, so I don't know if IR Scrutinizer can support that use case either.
Thank you for the quick reply Qwlciguk. As I'm sure you can see from the above question, my knowledge doesn't run terribly deep on this unit. I try to follow directions where given to ensure that I don't prevent myself from getting the device working properly. Now that I know it doesn't matter, I'll simply stop passing that argument to the program.
Thanks for saving me a few extra keystrokes :)
Do you have any advice/help for me regarding cross-compiling the Play/Record application for ARM?
I seem to have noticed a bug in the Play/Record application from the USB IR Toy v22 software package (Windows build, running under Windows 8.1 Pro x64) which does not appear to respect the speed the user sets for the port. The -s flag is supposed to set the baud rate, but the program only ever prints the speed as 115200bps regardless. I don't know if this is just a display issue, or if it simply doesn't respect the speed you set.
An unrelated request would be some help with either compiling the Play/Record application for ARM (Raspberry Pi in specific), or having someone who has it compiled for ARM already give me a copy to use. In my attempt to compile for ARM, I downloaded CodeBlocks and various GNU ARM toolchain binary packages for Windows. I was not successful in getting CodeBlocks to compile for ARM under Windows. I also tried eMIDE (a CodeBlocks-based embedded systems IDE), but it does not (amazingly enough) understand CodeBlocks Project files and I have no idea how to build a project manually.
I'd really like to be able to continue using this app, especially on my Pi.
