I am not aware of the buffer bug. But with the new firmware, new USB stack, and new V2 hardware, things could change. A command parameter -b buffer was there but has been changed to use only a fix 64 bytes buffer.
But I will include it in the test before I put the code in svn. I am still testing some tweaks in serial.c because its really slow in linux and Mac.
Here's a working source code that works with Windows, Linux (debian 5) and Mac OS leopard. The code compiles without complain on CodeBlocks 10.05 (http://www.codeblocks.org) The 'irtoy.cbp' is the main project file to load and select build target for your platform before compiling.
The serial.c need to be tweek for both linux and MAC OS because its really slow, and the screen output is not formated nicely :)
I used the device devtty.usbmodem00000001 under MAC (no driver needed) and devttyACM0 under Debian 5
This will eventually move to svn after some tweeking.
The latest firmware (v15 rc1) and rec & play app v0.85rc1 is now at the svn.
Please note the following changes in rec & play app 0.85 rc1:
checks firmware for v15 and above in order to use 0x07 for *.bin format files., *.txt and ot her formats still use the old 0x03 transmit command. check for garbage data on firmware reply. This was added because it needs to check firmware version accurately. instead of replaying same line of ir codes transmit failed, it will now re-start (close file, and open again 5x) playing the whole file. (not yet tested, the test file didn't fail so it bypass this routine).
There's a new update for the irtoy rec and play app (v0.84b) together with the new firmware (for testing). Please note: this is specific for this firmware only: USBIRTOY-newtransmit.hex. (update irtoy firmware by using the batch file: USBIRTOY-newtransmit.bat located in the firmware directory).
Older firmware may fail.
Changes: use new transmit command 0x07 instead of 0x03 replay buffer is fix at 64 byte reply # of bytes (64) when irtoy is ready to receive at end of playing (after 0xff 0xff pair) reply with no. of bytes processed which should be equal to the filesize.
This is for forum members who wanted to test run this new firmware.
I run the files and and it works fine with the latest rec and play app v.082, using firmware V112. If the problem don't disappear it could be something else.
I don't have the v2 on win7, but old method may just work. The way I installed the irtoy inf is via devices and printers, and opened up (right-click) the irtoy (diolan, unknown device or other name with no com port assigned) then open up properties, (you may need to click change settings) , on hardware tab try to update the driver, browse to the directory where the inf is located.
I am using win64 and thats the way I did it because clicking the inf wont work.
the file size is different from mine. I am not sure if you rename it from irtoy.exe into irtoy2.exe.. the size is different from mine. And the app was compile under win64 machine, but runs on win32.
You can probably be able to run the app if you can compile it yourself. The source code is in the source package. We use codeblocks from codeblocks.org. get it from here, includes everything (source and executeble). http://code.google.com/p/dangerous-prot ... .0.zip&can
all versions of irtoy rec& play was compiled using codeblocks and should run on 32 bit environment. It will still run on x64 system in 32 bit compatibility mode.
You might try to set this to run in win32 mode, or winxp compatible mode.
I have updated the irtoy rec & play because of a bug that doesn't increment the filename in v.08 release. Please update yours from the svn
there's something weird in the previous bin file that you provided.. I got errors too when replaying it even at -b 16.. The buffer size of -b 1280 might be too big. so start at the smallest 16, 32, 64, 128 up to 1024. so I tried to use my sony remote control and do a new recording (holding a button a little bit longer) , I was able to play it back without problem at buffer 512: bin size at 3kb, I have a 15kb bin file played without problem too, using this command: irtoy -d COM9 -p -f sony -v -b 512 and notice no garbage on this port, the other one of mine has :)
[quote author="rocketteem"] So, the question is: Can this time limit be altered in the app? A simple command line switch of a timeout time would work well I am sure. Please let me know, I'm eager to get this working :)[/quote]
It now accepts -b parameter to finetune playback buffer.
It now supports playing single file by specifying a complete filename with .bin extenstion:
irtoy -d COM10 -p -f test_001.bin -v -b 256
but it will overwrite same file in rec mode, so you will have only one file created if you use a complete file name.
there is also an optional new parameter, -b for playback buffer you may use multilple of 16's, eg. 16, 32, 64, 128, 256 etc this can be use to finetune playback and reduce lost of data.