Page 1 of 2
Zaptor protocol revisited
Posted: Fri Aug 26, 2011 11:08 am
by alanrichey
Having another issue with this protocol again. User is reporting it works but is sending 3 copies and causing skipping. This is the upgrade protocol
Upgrade protocol 0 = 01 FF (S3C80) Manual Settings (RM v2.00-preview7)
47 92 22 8B 17 8F 84 10 08 08 00 A5 00 91 00 A5
00 91 98 21 01 4A 00 00 05 03 03 AC 1C 22 F6 01
4C F6 01 46 F6 01 0A 7B F3 B6 04 80 B6 06 08 AF
End
Could Rob, or someone, remove the repeat flag
Cheers
Al
Re: Zaptor protocol revisited
Posted: Fri Aug 26, 2011 12:13 pm
by eferz
alanrichey wrote:Having another issue with this protocol again. User is reporting it works but is sending 3 copies and causing skipping.
Could Rob, or someone, remove the repeat flag
I could be wrong the "repeat flag" is off, since the number in red is an even number. At least, for simple upgrades.
Upgrade protocol 0 = 01 FF (S3C80) Manual Settings (RM v2.00-preview7)
47 92 22 8B 17 8F 8
4 10 08 08 00 A5 00 91 00 A5
00 91 98 21 01 4A 00 00 05 0
3 03 AC 1C 22 F6 01
4C F6 01 46 F6 01 0A 7B F3 B6 04 80 B6 06 08 AF
End
Oh wait, according to Protocol Builder using a little more specific assembly.
- Addr Code Label Op Op Args Comments
FF00 47 92 DB 47h,92h ;36.199 kHz 33.031%
FF02 22 DB 22h ;2 dev, 2 cmd
FF03 8B 17 JR LFF1C
FF05 8F DB 8Fh ;pf0: 10001111=devs,cmds,dev-cmd
FF06 84 DB 84h ;pf1: 10000100=LI-same,-LO
FF07 10 DB 10h ;pf2: 00010000=0-rev
FF08 08 DB 08h ;pd00: DevBits1=8
FF09 08 DB 08h ;pd01: CmdBits1=8
FF0A 00 A5 DW 00A5h ;pd02/03: 1-burst on=330 uS
FF0C 00 91 DW 0091h ;pd04/05: 1-burst off=330 uS
FF0E 00 A5 DW 00A5h ;pd06/07: 0-burst on=330 uS
FF10 00 91 DW 0091h ;pd08/09: 0-burst off=330 uS
FF12 98 21 DW 9821h ;pd0A/0B: Leadout off=77890 uS
FF14 01 4A DW 014Ah ;pd0C/0D: Leadin on=660 uS
FF16 00 00 DW 0000h ;pd0E/0F: Leadin off=40 uS
FF18 05 DB 05h ;pd10: DevBits2=5
FF19 03 DB 03h ;pd11: Repeat=3
FF1A 03 DB 03h ;pd12: CmdBits2=3
FF1B AC DB ACh ;pd13:
FF1C 1C 22 LFF1C: LD W1,#22h
FF1E F6 01 4C CALL 014Ch
FF21 F6 01 46 CALL XMITIR
FF24 F6 01 0A CALL 010Ah
FF27 7B F3 JRC LFF1C
FF29 B6 04 80 XOR DCBUF+1,#80h
FF2C B6 06 08 XOR DCBUF+3,#08h
FF2F AF RET
Change the number in blue to the desired number of repeats.
Posted: Fri Aug 26, 2011 12:40 pm
by alanrichey
Thanks a lot, I'll get him to test it
Posted: Fri Aug 26, 2011 12:43 pm
by 3FG
Alan, if eferz' suggestion works, that's great. However, Zaptor uses a toggle bit to indicate when the last frame of an IR transmission is sent. It is a very unusual protocol in that regard. If you haven't had success before tonight, I'll take a look at the executor.
Posted: Fri Aug 26, 2011 4:07 pm
by The Robman
The weird thing is, in the protocol code quoted (which I think I wrote), it doesn't do another send after the toggle is flipped.
Eferz, this protocol does repeat, but it's controlled by the assembler rather than the bits you were looking at.
FF21 F6 01 46 CALL XMITIR - send the signal
FF24 F6 01 0A CALL 010Ah - is the button still pressed?
FF27 7B F3 JRC LFF1C - if yes, loop back and send again
The following executor does one send and nothing else, no toggle and no repeats
Upgrade protocol 0 = 01 FF (S3C8+) Motorola Zaptor (PB v4.02)
47 92 22 8B 17 8F 84 10 08 08 00 A5 00 91 00 A5
00 91 98 21 01 4A 00 00 05 03 03 AC 1C 22 F6 01
4C 8D 01 46
End
The following executor does one send, flips the toggle, then does one more send.
Upgrade protocol 0 = 01 FF (S3C8+) Motorola Zaptor (PB v4.02)
47 92 22 8B 17 8F 84 10 08 08 00 A5 00 91 00 A5
00 91 98 21 01 4A 00 00 05 03 03 AC 1C 22 F6 01
4C F6 01 46 B6 04 80 B6 06 08 8D 01 46
End
Posted: Fri Aug 26, 2011 4:23 pm
by alanrichey
Thanks Rob, and yes, it was one of yours
I haven't heard back from the user yet, but I'll post the second version as well.
Cheers
Al
Posted: Fri Aug 26, 2011 7:17 pm
by eferz
The Robman wrote:The weird thing is, in the protocol code quoted (which I think I wrote), it doesn't do another send after the toggle is flipped.
Eferz, this protocol does repeat, but it's controlled by the assembler rather than the bits you were looking at.
FF21 F6 01 46 CALL XMITIR - send the signal
FF24 F6 01 0A CALL 010Ah - is the button still pressed?
FF27 7B F3 JRC LFF1C - if yes, loop back and send again
Thanks for explaining that to me. While I don't understand assembly nor S3C80 processor, I am getting the idea how protocol builder is disassembling it.
Upgrade protocol 0 = 01 FF (S3C80) Manual Settings (RM v2.00-preview7)
47 92 22 8B 17 8F 84 10 08 08 00 A5 00 91 00 A5
00 91 98 21 01 4A 00 00 05
03 03 AC 1C 22 F6 01
4C
F6 01 46 F6 01 0A 7B F3 B6 04 80 B6 06 08 AF
End
Does the following the line bares any relevance, or is protocol builder misinterpreting it as a "repeat" because of your customization?
FF19
03 DB 03h ;pd11: Repeat=3
Posted: Fri Aug 26, 2011 7:30 pm
by alanrichey
The Robman wrote:The following executor does one send and nothing else, no toggle and no repeats
Upgrade protocol 0 = 01 FF (S3C8+) Motorola Zaptor (PB v4.02)
47 92 22 8B 17 8F 84 10 08 08 00 A5 00 91 00 A5
00 91 98 21 01 4A 00 00 05 03 03 AC 1C 22 F6 01
4C 8D 01 46
End
And the user reports it works perfectly, so many thanks to all concerned.
Al
Posted: Fri Aug 26, 2011 8:53 pm
by The Robman
That confirms that I need to go back and fix the executor that I wrote before because it doesn't send the final frame.
Posted: Fri Aug 26, 2011 9:10 pm
by The Robman
eferz wrote:Does the following the line bares any relevance, or is protocol builder misinterpreting it as a "repeat" because of your customization?
FF19 03 DB 03h ;pd11: Repeat=3
This is one of those cases where PB is not getting it exactly right because there's other things going on in the assembler code.
The DevBits1=8 byte data goes into register R12, the next byte goes into R13, etc. The last valid entry is the "Leadin off=40 uS" line. If you count the registers from R13, you'll see that that one uses R20 and R21. The four bytes that follow, which are incorrectly labeled by PB, are registers R22 thru R25.
Now look at the beginning of the assembler (with my comments):
Code: Select all
LD W1,#22h ;set W1 pointing to R22
CALL 014Ch ;send pair at W1 (ie, R22-R25)
CALL 0146h ;send regular IR signal
CALL 010Ah ;is button held
JRC LFF1C ;if yes, jump back to first line
XOR R04,#80h ;flip the toggle
XOR R06,#08h ;fix the checksum
RET ;this is where the last send should be
So, the data at R22 onwards isn't really a repeat count, it's actually just the burst times for the irregular pair that gets sent at the beginning of the data stream.
Posted: Fri Aug 26, 2011 9:59 pm
by eferz
The Robman wrote:So, the data at R22 onwards isn't really a repeat count, it's actually just the burst times for the irregular pair that gets sent at the beginning of the data stream.
Awesome! Thanks again for the clarification.
Posted: Sat Aug 27, 2011 11:46 am
by alanrichey
Rob: Using that Zaptor protocol you wrote in RM there is an extra column called 'Byte 2' which contains various numbers. But when I use IR Scope on the remote it simply reports Zaptor 16.0 <OBC> . Where does the second byte come from ?
Posted: Sat Aug 27, 2011 1:23 pm
by The Robman
The second byte is a checksum. DecodeIR doesn't report the value because it can be calculated. I didn't bother to build the checksum calculator into the executor so it needs to be supplied via the upgrade. The checksum formula is described
here.
Posted: Sat Aug 27, 2011 2:25 pm
by alanrichey
OK
I think I will file this under the 'too difficult' heading. All he is missing is the Menu button (It's a Motorola VIP 1003 and the Harmony gives the same OBC as the one in the RMDU file) and it looks like I would have to spend hours tracking that down.
Cheers
Al
Posted: Sat Aug 27, 2011 7:18 pm
by The Robman
If you'd like me to calculate the code for the MENU button, post whatever info you have.