It sucks ! Especially on windows, having to use third party devices to put into boot loader mode. Getting annoying each time i want to test a new firmware. So I wrote something better ..
I attached the latest firmware with my boot loading program. Basically all it does is, ask the user the com port the Ir Toy is currently attached (virtually) to, then it opens the com port, resets the device and puts it into boot loading mode. No third party programs needed. Give it a spin see if it works okay.
I am struggling here a little with the new transmit mode. I found a few stability bugs in winlirc which i am trying to fix with regards to sending. I noticed with really long transmissions, not packet wise but time. The commands issued to the IR Toy will have returned, but the IR Toy is still busy transmitting. In that state if you issue a new command it basically crashes it the IR Toy. Not good :p
Will this Enable transmit notify on complete (0x25) fix that ? I assume that only returns after it has finished sending. The idea is to only return the function upon transmission completion. My other option it to send the thread to go to sleep for the duration of the pulse/spaces.
My next problem is the hand shaking .. It doesn't work quite as I expect.
If i ask for the packet size I get 62, Then i sent 62 byte packet. Then I ask for next packet size <--- fails here every time Then I send next 62 packet Then I ask for next packet size <-- works here every time + plus every call after
If I assume the packet size is 62, and skip the first query before sending it works every time.
I think it would be a lot better/easier if we just assumed the packet size was always something like 64. Then as soon as the IR Toy is ready for the buffer to be filled, it would send a packet ready request or something, saying send the next 64 bytes ! Can't be dealing with variable packet sizes. I am sending unsigned shorts, what am I meant to do if the packet size isn't a multiple of 2? How am I meant to handle this if it fails
Sleep(1); timecounter++; if (timecounter> 2000) { printf(" IRtoy Got no reply...n"); break; }
A sleep of 1000 microseconds would destroy sync totally.
** Summary ** - Easier if we used 64byte fixed packet sizes - IR Toy could send a buffer fill request once it has space for the next 64bytes rather than variable sizes
I am putting together a new winlirc version. I fixed a bug in the irtoy.dll that stopped irrecord working properly with some remotes. It still worked, but it appears it needed to reset the hardware each time. Basically the space from the terminator value was getting lost, as irrecord flushes the recording buffers and the space from the terminator was in it. I appended it to the next pulse and thus stopped it getting lost :p
anyway new version should be out this week so keep an eye out :)
With added sending support ! Most config files don't have any frequency specified, and that's fine. It'll use the default which is 38k I think. But if you add the word frequency and X to your config file, where X is the frequency in hz, the ir toy will set and use that one. (Well that's the plan anyway :p)
Trying out the new sampling transmit mode. Does it actually work ? Every time I try it the light just stays on and the device appears to get stuck. Sending 0x0 5 times seems to reset it. Am i doing something wrong ?
I had a bit of time today try and finish this winlirc plugin.. It's not finished yet, some stuff is hard coded, and it has little/no error checking. However .. it actually works.
Heres a capture of the signal using my own graph program (not released this yet).
And heres my winlirc build with extra debug stuff, you can see it's successfully decoding signals for my dvd remote
Hi guys, I'm a total newbie to these sort of hardware projects. Anyway I want to upgrade the firmware to the latest version so I can have a bash at getting this to work in WinLIRC. However I can't seem to update the hardware. What am i doing wrong ?
Edit: I meant to add I am using Vista32 if that makes any difference.