JP1 Remotes

Sorry to sound like a broken record, but can we clear up my problems with the Zaptor protocol.

I produced a Custom Remote for an AltiBox ADB 2720 WX which decoded as using the Zaptor protocol. The user reports it works well but double-clicks. I was a bit surprised to find that I didn't have a Zaptor (no repeat) option in PROTOCOLS.INI as I thought we had done that before. But searching through the forum I find the subject was discussed over 4 years ago !! Have we really been doing it that long ?

Also the discussion centred around the Motorola Zaptor and that has a different format to the Zaptor we have at the moment:

Motorola Zaptor Upgrade Protocol: 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

Zaptor Update Protocol: 2C 5F 31 8B 17 87 94 10 08 08 00 A5 00 91 00 A5 00 91 99 84 01 4A 00 00 05 00 03 DE 76 04 80 EB 09 E6 0E 46 E6 0F 94 F6 01 55 56 04 7F E4 05 C2 E4 C2 C3 E4 06 05 04 06 C3 F0 06 04 06 C3 56 C3 0F 56 C2 F0 44 C2 C3 E4 C3 06 F6 FF 58 F6 01 0A 7B F8 46 04 80 B6 06 08 E6 C1 22 F6 01 4C F6 01 46 AF

So are these 2 separate protocols ?

Next thing I tried was the Edit Protocol option in RM, but found it rather confusing (are there any detailed instructions for that option?). I couldn't see anything in the Disassesembly that pointed to a Repeat Rate, and in the Protocol Data tab I can see the Repeat Rate set to Minimum, but changing it to 'Forced' has no effect on the dissassembly window or the protocol listing at the top. Could someone either explain, or point me to the instructions ?

Cheers

Al

Al,
Look at this thread to see possible no repeat executors. These executors need two variable bytes and send only the 36KHz version. The longer executor seen in protocols.ini and quoted by you here can send two frequencies and only needs one variable byte, since it computes the checksum. So what frequency is needed? If 57KHz is needed, one approach is to just change the frequency of the appropriate one of Rob's executors. If the function numbers are different, it will be necessary to calculate that manually.

Otherwise we can try to turn the longer executors into a no repeat signal.

Thanks, that makes sense, and luckily I need only the 36Khz version.

Could still do with some instructions on how to use the "Edit Protocol" option in RM though.

Happy Xmas day to all our readers

Could still do with some instructions on how to use the "Edit Protocol" option in RM though.

If I'm not mistaken you have a JP1 remote and cable. Do you have access to a version of Microsoft Excel that supports Macros? I find using the Protocol Master spreadsheet, in combination with IR a lot easier for protocol tweaking. I don't get into trouble the way I do with RMIR.

But if you are not using Excel, or you no longer have a JP1 cable and remote, then RMIR is the way you want to go. I struggle with the procedure there, and get in so much trouble, but I could probably figure out how to do it, if that is the way you need to go.

Hi Vicky

No, I am using an IR Widget. I just feel embarrassed continually asking for help on setting repeat rates to zero, when it looked as though the 'Edit Protocol' option in RemoteMaster would enable me to do it myself. If that isn't true I will shut up and just keep asking

Happy Xmas

Al

As you've seen in the edit protocols tab, a protocol executor is a relatively small piece of assembler code. Sometimes it is just a list of variable values and a jump into the transmitter routine. Other times a lot of code needs to be written to create a complicated signal. Then you need to read the assembly and change the value of the repeats.

Sometimes you can just
Select all
Copy
Select the Assembly
Change values in the Protocol Data Tab
Click the update button
Click Assemble
and you are done, but the protocol I just tried to do that way changed a lot of stuff that would not allow the protocol to execute.


I went to find a protocol to update, to show you which variables to change for a (no repeats) , but I found that I had the latest and greatest protocol.ini from 3fg. So I went to download your protocols.ini, but the no repeats stuff is no longer at the end. This is going to take me a long time to pull out all the no repeats so that I can have the latest and greatest from 3fg, and have all the sling stuff too.

Yes, I tend to put the no repeat next to the original. But I have posted all the non-repeating protocols at https://www.hifi-remote.com/forums/dload ... e_id=13010

I used the suggested non-repeating protocol but the user has reported back that his Ch+/- still double-skips, so looks like we are stuck.

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

That's great thanks. The 'trick' I was missing was to click on the Disassemble button after selecting Assembly. Being faced with a blank screen that wasn't an immediately obvious choice.

I'm happy with the Assembler, I learnt much of my programming on the BBC Micro which had a very user-friendly Assembler. And what you say makes sense, I will give it a try,

Cheers

Al