I would like to share my painful first experiences with the USB InfraRed Toy.
About my environment: Linux Mint 13 amd64, USB InfraRed Toy v2 with FW v22
- To be sure the USB IR Toy works flawlessly, I wanted to update the firmware. I opened a terminal and sent '$'. But it took me ages to finally flash it (see next points), and meanwhile I wanted to use the firmware which was already installed. But even if you un-plug and re-plug the device, it does no go in normal mode again, but stays in bootloader mode, forcing me to flash it. It would be really nice if the device does not stay in bootloader mode when restarted. This could also be useful if the user putted the device in bootloader mode inadvertently.
- To flash the new firmware, I followed the wiki and wanted to use the diolan bootloader application. But this does not work anymore (I update it now).
- Code: Select all
- Code: Select all
- Now that it configures, it does not compile. The current (stricter) C compiler can't compile the not so young diolan bootloader application because the source files miss common library includes (stdint.h, string.h, stdlib.h).
Adding them to osdep/lnxdefs.h fixes this issue.
- Even if it compiles, it can not flash
- Code: Select all
U2IO flash erasing: FAILED.
Device is not found.
The USB device is there, the VID/PID are right, and I run it with root rights.
- the solution was to use the bootloader application from jesshaas. the libusb issue is still there, but it fixes the library header issue, and is able to flash the USB IR Toy successfully.
- next I wanted to record a signal using Logic Sniffer (0.9.6.1) with the IR Toy OLS profile. It can open the device, and the first IR bust is detected by the IR toy (LED blinks), but nothing after that. Logic Sniffer does not show the capture and the IR Toy is stuck. The LED stays on, and Logic Sniffer fails to re-open the device. You must correct that by re-plugging the device. Using the Open Bench Logic Sniffer profile, capturing and displaying the record works (activity is shown on channel 1,2, and 4 from the 8 channels recorded), but I don't know which trace it the right one. edit 2013-01-23: using v23 you can recapture without re-plugging, but no data is shown using the IR Toy OLS profile, nor the Open Bench Logic Sniffer profile.
- next I wanted to try the perl script provided in the package, but it simply doesn't even start
- Code: Select all
Can't locate object method "read_interval" via package "Device::SerialPort" at USBIRToy.pm line 91.
- so let's try IRToyRecPlay (debian5). It is very slow. It needs >5s to open the serial port. It does not show the recording (data stream) in real time, but only after ~6s. And finally, it does not respect the linux newline. This makes it unusable.
So I decided to write my own tool by using the sampling mode, but also there I already found some bugs
- after I putted successfully the IR Toy in sampling mode, reseting the device does not work. My program opens the serial port, sends 5 0x00 to reset, gets the version using 'v', and puts in sampling mode using 's'. The first time I start the program after plugging the IRToy it works really fine, and I get the stream of data. When I restart the script, the IRToy does not react to the reset command. It does not respond to the version command, but will simply send the sampling stream when there is IR activity. The only way to get the IRToy to reset it to un- and re-plug it. edit 2013-01-21: on FW v22 you have to wait a bit (I use 0.5s) after reseting and before sending another command. This is corrected in v23 (currently beta)
- when I un- and re-plug it too often, the IRToy "bricks". The LED blinks continuously, the USB device can't be enumerated, and un- and re-plugging it does not resolve the problem. The device is simply stuck. I can't put is in bootloader mode because no serial port is created. The only way to fix that is by shorting the PGD and PGC pins and re-flash the device … until it gets stuck and blinks again. edit 2013-01-21: this seems to be correted in v23 (currently beta)
- while in sampling mode, sometimes it just sends me 2-3 consecutive end of signal (0xffff) data in the middle of a burst. The IR signal did not end (0xffff should come after 1.7s of inactivity). I got the data within 0.5s, with the 3 consecutive 0xffff in the middle of the data stream. This happens most of the time with short IR burst (a single key press). edit 2013-01-21: this seems to be correted in v23 (currently beta)
- added 2013-01-21: in v22, the frequency counter (0x04 in sampling mode) returns 8 bytes, as documented in the wiki. v23 only returns 7 bytes.
- added 2013-01-23: in v22, when using the frequency counter, only the frequency calculated from the time between the 2nd and 3rd rising edge is relevant. the first value is often too high (and varies), the third is too low. This might be because the sensor is too sensible. But the second value if almost alway right enough.
- added 2013-01-23: in v22, in sample mode while replaying, when using handshake, the last free buffer count is sent 2 times after the last 0xffff. v23 doesn't do that
I just started playing with the USB IR Toy and already came across several bugs which cost a lot of time, and I think they won't be the last.
The SW as the FW are not very stable yet, and I really hope my "bug reports" will help improve that, because the HW by itself is really nice.
I will continue report the bugs I found by editing this post.