I'm seeing something strange. It seems that there is an extra burst being sent after the specified bursts are done.
I send a simple file with these burst pairs:
01 a7 00 d4 ;9.023/4.522
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 1a ;0.554/0.554
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 4f ;0.554/1.685
00 1a 00 1a ;0.554/0.554
00 1a 00 4f ;0.554/1.685
00 1a 00 1a ;0.554/0.554
00 1a 00 4f ;0.554/1.685
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 1a ;0.554/0.554
00 1a 00 4f ;0.554/1.685
00 1a 00 1a ;0.554/0.554
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 00 4f ;0.554/1.685
00 1a 07 48 ;0.554/39.65
01 a7 00 6a ;9.023/2.261
00 1a 11 9b ;0.554/96.15
ff ff
Now, after the final 0.554ms on burst followed by 96.15ms leadout off time, there is another ~109ms burst. It looks like this, captured monitoring IRTX with logic analyzer:
(http://https://farm4.staticflickr.com/3926/14577838071_f21d92516c_o_d.gif)
The extra 109ms burst seems to have something to do with the size of packets being sent. That is, this particular file was being sent via the cmdline:
irtoy.exe -d COM12 -p -f test_000.bin
It reported that the 146 byte file was broken up into two 62 byte packets, followed by a 22 byte packet. It seems like if the last packet is a multiple of 62, then the extra burst doesn't show up. I'm wondering if the IR Toy FW is not stopping at the end of packets that are less than 62 bytes, but continuing on and whatever is left in the buffer past the end of the packet, gets sent.
Anybody that understands the IR Toy FW have any ideas?
I think your problem may be the following:
Your signal should end like:
........
00 1a 07 48 ;0.554/39.65
01 a7 00 6a ;9.023/2.261
00 1a FF FF ;0.554/ FFFF = terminator...
Your last valid signal must be a Mark followed by the terminator (FFFF). You hav.e a space followed by the terminator.
Yeah I agree that that has to be it. A 109ms delay is coded in the firmware to replace the 0XFFFF but it is meant to occur on the space not the mark part. If it happens on the mark then the PWM is enabled for the delay period as it is simply toggled between mark and space in the firmware after each 16-bit word. The .bin file should always be a multiple of 4 in length, including the terminator.
[quote author="Simpkins"]Yeah I agree that that has to be it. A 109ms delay is coded in the firmware to replace the 0XFFFF but it is meant to occur on the space not the mark part. If it happens on the mark then the PWM is enabled for the delay period as it is simply toggled between mark and space in the firmware after each 16-bit word. The .bin file should always be a multiple of 4 in length, including the terminator.[/quote]
Thanks Simpkins and AnalysIR. I'll check it out when I get home. It makes sense. Now I'm wondering where I got the file from. If it was a capture from the IR Toy, shouldn't it have naturally ended on a mark? It's possible that Bengt Martensson's IR Scrutinizer program was the source of that sequence. That was weeks ago and I don't remember now.
[quote author="Qwlciguk"][quote author="Simpkins"]Yeah I agree that that has to be it. A 109ms delay is coded in the firmware to replace the 0XFFFF but it is meant to occur on the space not the mark part. If it happens on the mark then the PWM is enabled for the delay period as it is simply toggled between mark and space in the firmware after each 16-bit word. The .bin file should always be a multiple of 4 in length, including the terminator.[/quote]
Thanks Simpkins and AnalysIR. I'll check it out when I get home. It makes sense. Now I'm wondering where I got the file from. If it was a capture from the IR Toy, shouldn't it have naturally ended on a mark? It's possible that Bengt Martensson's IR Scrutinizer program was the source of that sequence. That was weeks ago and I don't remember now.[/quote]
Verified. Making the final word always an "on" duration immediately preceding the 0xFFFF terminator, makes it work correctly every time. I also verified that Ir Scrutinizer is making the same mistake that I did in that they include the final "off" duration prior to the 0xFFFF terminator. I'll follow up in the IR Scrutinizer thread.