Zaptor protocol revisited

[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

[eferz]

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 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

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.

[alanrichey]

Thanks a lot, I'll get him to test it

[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.

[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

[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

[eferz]

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

[alanrichey]

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

[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.

[The Robman]

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.

[eferz]

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.

[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 ?

[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.

[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

[The Robman]

If you'd like me to calculate the code for the MENU button, post whatever info you have.