that may be the cause, I tested it in a normal room with sunlight and stuff. I'll give it a try in a dark environment and give you feedback. If this won't work properly I'll try the downgrade way.
thanks for the response, I hope you enjoyed your trip :)
Are there any tools to create those .bins on a Linux (Ubuntu) or Mac OSX 10.8.1 (Mountain Lion)? I have a Windows VM (to make the firmware updates), but to be honest, working with this free Win XP IE 6 Test VM sucks more than hell :D
If there is a way to make this with the OS I have, it would be a honor to help you and the community to find those bugs.
I'm currently doing my first steps with the USB IR Toy and the Pyton module. I want to implement some more functions to the python module (and share it, of course), but I got some issues that I can't explain to myself. Im trying to implement the frequency detection with the help of this documentation: http://dangerousprototypes.com/docs/USB ... pling_mode
My calculation (based on the docs) return some strage values, that can't be right, no matter where I place the remote (near, far).
Based on this example: {00}{F4}{02}{43}{03}{91}{01}{B3}
PIC timer Period 1 count = 0xf941-0x5c92=0x9caf (40111) PIC timer Period 2 count = 0x2beb-0xf941=-0xcd56 (-52566) Total infrared pulse count = 0x0001 = 1
The result looks wrong to me, especially because of the negative value of the second calculation. In the example the results of calculation 1 and calculation 2 are really close to each other - mine are really far from each other ^^
I'm currently using USB IR Toy v2 with the 2.2 Firmware.
Are there any news? I got a similar problem, but I only got a Mac OS X with the Python module and not those fancy Windows tools. Is there any hope for me?
I got the same Issue using the USB IR Toy with the Version 2.1 and 2.2. Is there a way to get out of this state and "reset" the device to default, without doing the unplug/replug workaround?
