I'm currently playing around with flooding the irtoy with many commands in serial. Sooner or later I get into the problem that the led keeps on and the app hangs. I can see in the logs for such cases that the irtoy is not responding with the handshake after sending a part of the hexcode (62 bytes). I also tried some sleep but there is also no response 3 seconds later. when this happens, there is never again any response, even not after the reset (5x 0xFF and start sampling mode).
does somebody know if I need to apply some sleep somewhen? (I saw it in some of the perl/python/c scripts).
@zigma: the stuff with the freeze is very annoying. I did not found any logic when it happens or how long it requires to be in standby. maybe it depends on the device when it is going to deep sleep or so. but I can't solve it with a reboot.
It would be interesting if firmware v23 could fix these issues (the usb stack should be rewritten). but I have no idea about the current state of the firmware. there is one post but also later a comment that the version is rubbish.
Ok I see it is working quite good. Here my latest state of the proof-of-concept app. But as I can see, there is not that much improvment :( You don't need to take over the whole irtoy.java class and lose the translation, you can simply merge it. the only improvment seems to be in the leseTransmitCount() function where it can handle now the correct handshake when there was sent more than 256 bytes (maybe not relevant for your project, but you never know).
Except the receiving part, is it working perfect now for the sending stuff? Or are there still any issues? I still have two issues where I'm working on: - I want to create a 'send synchronous' function where the calling thread is blocked and gets a boolean response if the send was successfull (required for sending depending commands). current issue: when the sending is called multiple times (eg. the button is hitted multiple times), it is crashing and the LED keeps on, even if I synchronize the work :( - Sometimes when my tablet goes to standby, the irtoy freezes at the bootloader mode and will not work anymore until the firmware is flashed. do you have also such problems?
in my case, I also have 3 different remotes/devices to control. but at the end, it doesn't matter from which remote you have learned the command. you are just sending hex codes and the correct target device will understand it. so create a connection at the start of the app and close it at the end. between, you send the desired commands as hex codes from whatever remote.
yeah I forgot one thing. As I mentioned, I'm taking also the hex codes using the perl script by taking the codes from the original remote. to convert the .bin file into hex codes, I made a small C# script that I want to share now. the attachment contains the binary exe and the sourcecode as well. it is very easy to use:
where it creates input.txt as output file. It should be possible to send these hex codes. it works at least for my Samsung TV, the Sony HiFi and also the RC6 windows media center (but here I had to disable the debounce).
I'm corrently optimizing my api class, it needs to be more stable. but my biggest problem is that the device sometimes stuck in bootload mode (led is on all the time) when the tables goes to sleep. there is another thread in this forum regarding this problem, but it is mainly about windows.
attached the current state of my playground. it contains the FTDriver.java which I have a little bit enhanced with debug statements to be able to see where it fails. then it contains the IrToy.java which should become an 'IrToy API' to init the device, send commands and close the device. it contains the implementation of the sampling mode. and there is also the MainActivity.java which is nothing more than a simple app with an init button, two buttons to send commands and a big logging area to see what happens.
please note that the exception handling is rubbish at the moment, there is a lot to do. and sorry, a part of the code is commented in german, a translator might be your friend ;)
Happy to see your posting, I'm currently having also the same idea: control IrToy via Android; but as you maybe have also realized: there is currently nothing out of the box available. the effort required is quite high. but it possible!
I'm currently playing around with a Huawei MediaPad 10 FHD and I'm also using the way via an OTG cable. Here are links to two threads which helped me a lot and is a good starting point for getting into it: viewtopic.php?f=29&t=5605 viewtopic.php?f=29&t=5614
I'm currently using the FTDriver which you will find in the first linked posting. It is more or less an additional layer that is using the Android USB host API. it does not need an additional driver or rooted device. Then an implementation of the sample mode is needed, it is described here: http://dangerousprototypes.com/docs/USB ... pling_mode
To keep my project a little bit more simple, I'm currently not researching on how to get data from the toy. So I'm connecting the irtoy to the PC and record the codes via the perl script provided by the USBIRToy.package.v22. however, here I had the first challenge that the perl script (irtoy_record.pl) is not giving the same codes as the IRToyRecPlay sample is giving. the codes from the IRToyRecPlay did not work when I sent them out, the ones from the perl script are working. Once I have the hex codes, I implement them in my android application and send them out. --> sending the hex codes out seems to work. I first play around with my kenwood hi-fi system and it is able to control the volume. at least a start.
I can share some bit of code later, currently I have a few issues: - sometimes when I plug in the OTG cable, my tablet is just restarting. this might be an issue on the tablet or on the irtoy, but at the end it is a problem which prevents from using the solution :( - sometimes the irtoy just stopps working. when I plugin the device, the LED stays on, it stucks in bootloader mode I guess. but connecting it to windows is showing a yellow icon on the HID devide. the only way to fix it I have currently is to apply the jumper and flash the firmware again (v22). however this is also an killer issue.
