We aren't necessarily stuck because Zaptor has an unusual structure. It is designed so that one particular bit is always set to zero except when the final frame is being transmitted. I suppose that the the final frame indicates that the button has been released. The executors which Rob wrote some years ago don't send a final frame (I don't think we were aware of the details of Zaptor at that time.) So it may be worthwhile to try sending one regular frame followed by a final frame, or, sending just the final frame.
I prefer using RMIR for protocol work, because it has a lot of information not easily accessible in PB. For example, here's a fragment of a disassembly in PB:
The same fragment in RMIR:
Going to the Functions subtab gives the following definition:
014CH* IRMarkSpaceByPtr: Send ON/OFF burst pair for times pointed at by register HX (HCS08) or W1 (S3C80).
Here's the workflow I would use to try modifying Zaptor.
In protocols.ini, make a copy of Zaptor (variant JP1) and call it ZaptorSingleWithFinalFrame, or ZaptorFinalFrameOnly. Change to a favorite custom PID. In RMIR, File/New/RemoteImage,and select SlingboxPL. (I prefer to use an actual JP1 remote for testing, and I select RCRP05B usually.) Add a device, select the just added custom Zaptor protocol, enter the appropriate device, subdevice, frequency, and OBCs. Click OK, and then on the Devices tab, click the Zaptor custom protocol to open up the Manual Setting window. This will open with the radio button Disassembly selected, but I always immediately switch to the Assembly radio button. This erases the disassembly, so click the Disassemble button near the lower right corner. If I expect to make any significant changes to the executor, I now Save the executor with a unique name. Anytime I add a Comment, I save again.
Here's some brief comments associated with Zaptor following the timing info:
Code: Select all
L0: TM DCBUF+1, #80H ;36 or 57KHz?
JR NE, L1
LD CARRIER, #46H ;36KHz
LD CARRIER+1, #94H
CALL SetCarrier
L1: AND DCBUF+1, #7FH ;Clear toggle bit to zero
LD RC2, DCBUF+2 ;Start checksum calculation
LD RC3, RC2
LD DCBUF+2, DCBUF+3
ADD RC3, DCBUF+3
SWAP DCBUF+3
ADD RC3, DCBUF+3
AND RC3, #0FH
AND RC2, #F0H
OR RC3, RC2
LD DCBUF+3, RC3 ;end of checksum calculation
L2: CALL L3
CALL TestRptReqd
JR C, L2
OR DCBUF+1, #80H ;No more repeats, set toggle
XOR DCBUF+3, #08H ;Adjust checksum
L3: LD RC1, #22H ; L3 sends the signal
CALL IRMarkSpaceByPtr ;Zaptor uses 8,-6,2 leadin
CALL XmitIR
RET
It seems that we want to remove the lines
This will send a T=0 frame and a T=1 frame. To try only sending the final T=1 frame, we can also replace
with
After editing (and saving!) click the Assemble button. If you're using a JP1 remote, you can upload to the remote now. When you're happy with the generated signal, update protocols.ini with the new executor code by double clicking in the Protocol Code box (upper left) adjacent to S3C80. Highlight the expanded code listing, and copy with Control-C. (Note that if you subsequently click anywhere in RMIR, all of the comments will be erased. Now aren't you glad you saved?)
Sometimes the Assemble operation fails and highlights some instructions in red. This probably means that the syntax is incorrect, but it can also be caused by using Wn notation instead of RCn. I prefer using Wn, but I have better luck selecting Force RCn. Anyway, it may be necessary to substitute RC for W (or vice versa) to get a successful assembly.
I prefer to mostly ignore the Protocol Data tab. All of the same timing, etc info is available on the PF details and PD details tabs, typically with better descriptions.
Generally, I avoid using the Build and Update buttons. Build will erase all custom code. Update retains custom code, but may delete data being stored in timing registers. In this executor, the durations of the 8,-6 part of Zaptor's 8,-6,2 lead in is stored in PD10-PD13, and this is different to standard usage. So clicking update will remove the PD10-PD13 data.
