JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

What do you need to write your own protocol executor
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7002
Location: Florida

PostPosted: Wed Nov 14, 2018 5:26 am    Post subject: What do you need to write your own protocol executor Reply with quote

What do you need to write your own protocol executor? The information is scattered all over the place, this is my attempt to take hide and seek out of the equation.

EDUCATION;
Ideally you'll have some programming experience but where there is enough desire, that shouldn't be a showstopper. You will need to learn how to use the Assembly language of your target chip, and you should learn the Samsung Assembly language, at least enough to read it. Almost every protocol executor exists for the Samsung chip. Although writing in assembler is tedious, an executor's code typically will fit on one screen, so it's not a horrible task.

If you learn to read IRP, you can find examples of other signals that do something similar, and see the assembly code that was used to accomplish the task in something similar.

There are chip datasheets on Rob's website. Some describe the chips assembler language:
http://www.hifi-remote.com/files/
http://www.hifi-remote.com/forums/dload.php?action=category&cat_id=162

HARDWARE
You will need a UEI remote to shoot your signals. Ideally you'll have some way to capture your output for debugging purposes. I found an IRWidget to be ideal, but if you have some other tool that will capture timings such as a spare UEI learning remote that will do.

SOFTWARE TOOLS
The JP1 community has two tools that will help you write a protocol executor.

1) If you have Microsoft Office (not the starter version) you can use ProtcolBuilder (PB) with KeymapMaster (KM) .
2) You can also create/edit a protocol executor in RemoteMaster (RM).

Each executor building tool allows you to save a text file with your assembly code, but they will not import that text from each other.

Each tool has its own strength and weakness.

I find PB, KM and IR easier for me to experiment with because repeated attempts don't cause anything to crash.

In my opinion, RM has a superior disassembly tool, it has settings that allow you to have meaningful mnemonics in the code it generates..

The PB feature in RM has not been heavily used, so as of version 2.07 build 2, there are still some major bugs. If you use RM, I recommend that you do your development in an RM session that was NOT started off the RMIR File New.

The link for the current version of RM will be found in a Sticky in the software forum.
http://www.hifi-remote.com/forums/viewforum.php?f=9

RMPB_Readme.html is included in the RemoteMaster zip file. You'll want that readme file even if your are using PB. The RMPB readme file gives some insight about what the IRengine can do in the various remotes.

ProtocolBuilder (PB) is an excel spreadsheet run by macros, so it requires genuine MS Excel. The link for the last version of PB will be found with protocol file section. You can also find PB txt files that give you commented examples of executors, but these are only for PB not RM.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2305

"Variable and vector chart" - You need that information to write a protocol executor. That “variables and vectors chart” spreadsheet can be opened by any spreadsheet program. Without this key piece of information, you can't write code to send a signal.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6879

KM version 9.22 KM is a another macro driven Excel spreadsheet requiring genuine Excel. Upgrades created with KM can be opened by both KM and RM, RM upgrades can not be opened by KM (this tool has been archived, at this time RM does a better job with KM files, than it does with its own format)
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=1888


IR version 8.04 (this tool has been archived, when working trial and error, this tool is way more forgiving than RMIR)
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=11605




GETTING STARTED

In order to write a protocol executor you are going to need to know the timing pattern and the frequency of the signal. The timing data can come from many sources. Learned signals, ICT files, LIRC files manufactures documents.....

The following beginners document gives you some idea of what the numbers represent, including terms that may make it easier to understand some of the terminology you'll see in the protocol executor building tools .
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6996

The next step of the process decode the signal. Decoding includes finding the stationary parts of the signal, vs the parts that change with each function. Sometimes the pattern will be very simple, sometimes the pattern is diabolically clever. To fully understand the pattern we need as many samples of the signal as possible. Getting these from the person that actually needs the signals, is like pulling teeth.

You should also read this PB help document from Rob. It gives an example for using PB. The same information applies to RM's pb functionality.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2304

In addition there are lots of timing decoding examples of this in the protocol forum. If you find the pattern recognition part over your head, you can always post the timing data in the protocol decode forum and ask for help.

The tools to create a device upgrade are used by most everyone in the JP1 community. It is assumed that you have already created a few device upgrades, and have observed how they have some fixed data, and then data that changes with each command. The device upgrade holds the signal data necessary to create the on-off pattern.

The executor holds the timing data, Protocol Flags, Protocol data, and object code. When you write an executor, you decide how many variables you need and how the hex is going to be loaded.

Fortunately the protocol executor building tools go a long way towards automating the process of creating a protocol executor and answer some questions, and the tools can build you a skeletal upgrade, that will send a signal based on those answers.

SIZE MATTERS
We want to see how small we can make the combination of the executor and upgrade that calls it.

Tip: One of the tricks we often use on a NEC signal, is to make a complement of the second command byte in the code, instead of storing an extra byte for each and every command in the device upgrade.
There are 2 bytes of protocol flags, that are going to set a bunch of bits that tell the remote how to load the data into the buffer, and how to send the data. In a situation like the NEC to compute the protocol flags, set the device and command count to the size of the signal you want to send before you create your skeletal upgrade, then change protocol data values to use the number of device and commands to match your input for loading purposes. In the code where you manipulate the databuffer, change the value of the device and command count bytes to match the value you had when you calculated the protocol flags.

Besides making the overall size of the device upgrade smaller, we also want the function portion to be 1 byte if possible, because some older remotes can't handle a 2byte keymoves.

MSB LSB COMP
For a standalone upgrade with a manual executor, both KM and RM only allow you to specify if the hex is going to be calculated MSB LSB or Comp or NonComp. If there is already a translator for this signal, we want to make the LSB or MSB match the decoded values. If your exploring new uncharted territory, choose your settings based on if there is a way to make the number OBC values appear in numerical order.

KM lets you change the LSB and Comp settings after the fact preserving the hex and changing the OBC , RM does too, but you need to turn on the "Allow Preserve Control" feature from the Options menu or the hex will change.

In addition, in RM you can also make an entry in Protocols.ini to get advanced translators for your hex, but nobody can use the upgrade unless their protocols.ini has also been altered.

WRITE
I usually start by writing comments on what my code is going to do.
Next write the code outlined by the comments.

TEST
Load up a remote, and send the signal.

OPTIMIZE
Your code should be as small as you can get it. See if rearranging the code can save some steps. Look to see if there are instructions that generate fewer bytes.

FINAL TEST
Perform one more test, to make sure everything is working.

SHARE.
Post your upgrade so that someone else can enjoy your work.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.


Last edited by vickyg2003 on Fri Nov 16, 2018 10:03 am; edited 3 times in total
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18563
Location: Chicago, IL

PostPosted: Wed Nov 14, 2018 12:31 pm    Post subject: Reply with quote

Nice write up Vicky. When I get a chance, I think I want to copy this over to the Wiki
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 841

PostPosted: Wed Nov 14, 2018 1:13 pm    Post subject: Reply with quote

Vicky, very impressive! Cool Some thoughts:

I think we should distinguish between executors and protocols. A protocol (for example Nec1) is a mathematical object that takes a few parameters (like D, S, F) to an IR signal. An executor is an implementation of one (or more, "combos") protocol(s), a program for a particular processor. It is IMHO quite confusing when we denote both of these animal with the same name. Yes I know, RM(IR) is full of it...

More substantially, for the last years I have been working with a program called IrpTransmogrifier, so named since it "transmogrifies" an IRP-Protocol to all kind of cool things, like generating code for executors for different targets. Presently, I have been playing with Java and C/C++ as the target, but assembler in the sense of RM and/or PB fits fine in the scheme. So, the one who needs (or discovers) a new protocol can write the IRP form, try it out with IrScrutinizer (equipped with sending hardware), thus verifying that it makes what it should, then "press a button" and have the assembler for RM/PB generated, together with a Protocols.ini fragment, and then flashing it to the remote using RMIR. Or possible tweak the generated code...

I have not yet pursued the idea. There are a few arguments against investing work: most executors are already written Wink, due to the nature of remotes with very limited memory, tweaking may be needed anyhow,... etc.

Anyone thinks this is a good idea?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18563
Location: Chicago, IL

PostPosted: Wed Nov 14, 2018 2:54 pm    Post subject: Reply with quote

Re: protocols vs. executors: agree totally.

Re: IrpT
That might be a good idea for some folks Bengt, especially folks who have no clue how to write assembler. The thing is, if the protocol is simple enough, you can do most of it in PB with no assembler, you only need assembler when you need to tweak the rules, or manipulate the data. Of course, for really complicated protocols, sometimes you need to do it all by hand.

I have become quite comfortable with S3C8 assembler and Vicky owns HCS08, but I don't think either of us have dipped our toes into the MAXQ or TI assemblers, I think the 2 Dave's own those.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7002
Location: Florida

PostPosted: Thu Nov 15, 2018 10:27 am    Post subject: Reply with quote

The Robman wrote:
Nice write up Vicky. When I get a chance, I think I want to copy this over to the Wiki


Its not ready. I'd like to get this over there too, but first it needs to be somewhere where it will get feedback.

Barf wrote:
I think we should distinguish between executors and protocols. A protocol (for example Nec1) is a mathematical object that takes a few parameters (like D, S, F) to an IR signal. An executor is an implementation of one (or more, "combos") protocol(s), a program for a particular processor. It is IMHO quite confusing when we denote both of these animal with the same name. Yes I know, RM(IR) is full of it...


Point taken. Edited to either replace protocol with "protocol executor" or "executor" where this applies.

Re: IrpT
Bengt, I haven't tried IrpT for a year, and at that time it was not doing what I'm looking for. There is a tool that is needed. There is an awful lot of grunt work analyzing these timings. Multiple pieces of software need to be used, copy, paste, copy, paste, copy, paste.

You would be my choice for a developer to make a simpler tool, because you understand all the the formats that learns come in, and you have the Java skills to make this work. I want a "Binary-afier" before a Transmongifier.

I'd like to be able to read in a signals from an ICT, RMIR, IR, LIRC and any other learned format that you understand

I'd like to be able to eliminate signals that are obviously bad learns, there are always some,

I'd like the tool to identify
biphase
quadphase
and
binary pulse width
quad pulse width
octal pulse width
octal pulse width
hex pulse width

and be able to spit out a text file with the The timing values and then the BINARY REPRESENTATION and function name.

Then and only after that capability was in the tool would I want to Advanced feature suggest the IRP for the SELECTED signals.

If you could make something, that streamlines the conversion to Binary, you'd have me on board.

Rob wrote:
I have become quite comfortable with S3C8 assembler and Vicky owns HCS08, but I don't think either of us have dipped our toes into the MAXQ or TI assemblers, I think the 2 Dave's own those.

I own HCS08, now that's scary. This is the second time I've seen reference to the MAXQ assembler. I can't seem to find any references to vectors and variables, nor any way to modify them.

That's the kind of information I would like to incorporate.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 841

PostPosted: Thu Nov 15, 2018 3:49 pm    Post subject: Reply with quote

Thanx for those nice words.

I was discussing IrpTransmogrifier's code generation facilities in my first post. As Rob points out, unfortunately the practical value is probably somewhat limited (and the effort probably rather high, since there are sevaral different assemblers (targets). So I an probably not going to do that.

Vicky instead interests herself for the analyze function of IrpTransmogrifier. So I will discuss that next.



vickyg2003 wrote:

I'd like to be able to read in a signals from an ICT, RMIR, IR, LIRC and any other learned format that you understand


IrpTransmogrifier understands raw signals (either straigjht-forward or in a bracketed format), Pronto Hex, and ICT. Not more. This is a deliberate decision, since it is intended to be integrated in programs like IrScrutinizer, that will provide support for the "other learned formats". But it can read many of these signals from text files, with name or without.

Quote:

I'd like the tool to identify
biphase
quadphase
and
binary pulse width
quad pulse width
octal pulse width
octal pulse width
hex pulse width

It tries interpreting the signal(s) using a few different methods (TrivialDecoder, Pwm2Decoder, Pwm4Decoder, Pwm4AltDecoder,
XmpDecoder, BiphaseDecoder, BiphaseInvertDecoder, BiphaseWithStartbitDecoder,
BiphaseWithStartbitInvertDecoder, BiphaseWithDoubleToggleDecoder,
SerialDecode), every (successful) interpretation is assigned a "weight", and the interpretation with the lowest weight is output. However, the user can request that all interpretations should be output, or just one interpretation, regardless of weight.

Quote:

and be able to spit out a text file with the The timing values and then the BINARY REPRESENTATION and function name.


Lets play! Consider the problem here. assume that the RemoteCentral codes are saved in a text file RTI_Relay.txt. First,
Code:

$ irptransmogrifier analyze   --namedinput RTI_Relay.txt
Relay 1 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400004,B=0x80}
Relay 1 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000004,B=0x80}
Relay 2 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400002,B=0x40}
Relay 2 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000002,B=0x40}
Relay 3 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400001,B=0x20}
Relay 3 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000001,B=0x20}
Relay 4 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400000,B=0x1010}
Relay 4 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000000,B=0x1010}

Want the timings?
Code:

$ irptransmogrifier analyze  --statistics  --namedinput RTI_Relay.txt
Timebase: 398.0

Gaps:
A:      398     = 1*398         512
B:      795     = 2*398         40
C:      19898                   8

Flashes:
A:      398     = 1*398         512
B:      795     = 2*398         48

Pairs:
AA:     464
BA:     48
AB:     40
AC:     8

Relay 1 On  AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400004,B=0x80}
weight = 17     BiphaseInvertDecoder
Relay 1 Off AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000004,B=0x80}
weight = 17     BiphaseInvertDecoder
Relay 2 On  AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400002,B=0x40}
weight = 17     BiphaseInvertDecoder
Relay 2 Off AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000002,B=0x40}
weight = 17     BiphaseInvertDecoder
Relay 3 On  AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400001,B=0x20}
weight = 17     BiphaseInvertDecoder
Relay 3 Off AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000001,B=0x20}
weight = 17     BiphaseInvertDecoder
Relay 4 On  AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400000,B=0x1010}
weight = 17     BiphaseInvertDecoder
Relay 4 Off AA AA AA AA AA AA AA AA AA AA BA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AB BA AA AA AA AA AA AB BA AA AA AC
{40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000000,B=0x1010}
weight = 17     BiphaseInvertDecoder

How are the bits utilized?
Code:
$ irptransmogrifier anal --bit-usage  --namedinput RTI_Relay.txt
Relay 1 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400004,B=0x80}
Relay 1 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000004,B=0x80}
Relay 2 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400002,B=0x40}
Relay 2 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000002,B=0x40}
Relay 3 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400001,B=0x20}
Relay 3 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000001,B=0x20}
Relay 4 On  {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404040400000,B=0x1010}
Relay 4 Off {40.2k,398,msb}<1,-1|-1,1>(A:63,B:13,-19.5m){A=0x7ff0404000000000,B=0x1010}

Bit usage analysis:
A       11111111111000001000000010000000*0000000*0000000000000000000***
B       *0000****0000

You asked for a binary representation; your wish is my ... no, scratch it!
Code:

$ irptransmogrifier anal --radix 2 --eliminate-vars   --namedinput RTI_Relay.txt
Relay 1 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000100:63,0b10000000:13,-19.5m)
Relay 1 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000100:63,0b10000000:13,-19.5m)
Relay 2 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000010:63,0b1000000:13,-19.5m)
Relay 2 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000010:63,0b1000000:13,-19.5m)
Relay 3 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000001:63,0b100000:13,-19.5m)
Relay 3 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000001:63,0b100000:13,-19.5m)
Relay 4 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000000:63,0b1000000010000:13,-19.5m)
Relay 4 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000000:63,0b1000000010000:13,-19.5m)

Using the bit usage, we refine the parameters length, and list how the different signals use the different parameters
Code:

$ irptransmogrifier anal --parametertable --parameterwidths 32,1,7,1,19,4,4,4 --named  RTI_Relay.txt
Relay 1 On  {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x1,C=0x0,D=0x1,E=0x0,F=0x8,G=0x0,H=0x8,I=0x0}
Relay 1 Off {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x0,C=0x0,D=0x0,E=0x0,F=0x8,G=0x0,H=0x8,I=0x0}
Relay 2 On  {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x1,C=0x0,D=0x1,E=0x0,F=0x4,G=0x0,H=0x4,I=0x0}
Relay 2 Off {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x0,C=0x0,D=0x0,E=0x0,F=0x4,G=0x0,H=0x4,I=0x0}
Relay 3 On  {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x1,C=0x0,D=0x1,E=0x0,F=0x2,G=0x0,H=0x2,I=0x0}
Relay 3 Off {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x0,C=0x0,D=0x0,E=0x0,F=0x2,G=0x0,H=0x2,I=0x0}
Relay 4 On  {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x1,C=0x0,D=0x1,E=0x0,F=0x1,G=0x0,H=0x1,I=0x0}
Relay 4 Off {40.2k,398,msb}<1,-1|-1,1>(A:32,B:1,C:7,D:1,E:19,F:4,G:4,H:4,I:4,-19.5m){A=0xffe08080,B=0x0,C=0x0,D=0x0,E=0x0,F=0x1,G=0x0,H=0x1,I=0x0}

Parameter table:
Relay 1 On      ffe08080        1       00      1       00000   8       0       8       0
Relay 1 Off     ffe08080        0       00      0       00000   8       0       8       0
Relay 2 On      ffe08080        1       00      1       00000   4       0       4       0
Relay 2 Off     ffe08080        0       00      0       00000   4       0       4       0
Relay 3 On      ffe08080        1       00      1       00000   2       0       2       0
Relay 3 Off     ffe08080        0       00      0       00000   2       0       2       0
Relay 4 On      ffe08080        1       00      1       00000   1       0       1       0
Relay 4 Off     ffe08080        0       00      0       00000   1       0       1       0


That is a little fraction of the options.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7002
Location: Florida

PostPosted: Thu Nov 15, 2018 7:26 pm    Post subject: Reply with quote

Quote:
Barf wrote:

You asked for a binary representation; your wish is my ... no, scratch it!
Code:

$ irptransmogrifier anal --radix 2 --eliminate-vars   --namedinput RTI_Relay.txt
Relay 1 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000100:63,0b10000000:13,-19.5m)
Relay 1 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000100:63,0b10000000:13,-19.5m)
Relay 2 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000010:63,0b1000000:13,-19.5m)
Relay 2 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000010:63,0b1000000:13,-19.5m)
Relay 3 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000001:63,0b100000:13,-19.5m)
Relay 3 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000001:63,0b100000:13,-19.5m)
Relay 4 On  {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000001000000010000000000000000000000:63,0b1000000010000:13,-19.5m)
Relay 4 Off {40.2k,398,msb}<1,-1|-1,1>(0b111111111110000010000000100000000000000000000000000000000000000:63,0b1000000010000:13,-19.5m)


You do realize that we are not just trying to find the on off, we need to find a way to make this into a reasonably small executor, needing the minimum space in the E2 area.

In order to use the binary rep, I need ALL THE ZEROS, in order to use this I had to pad this out to 13 bits by hand, then take the :63 out and start playing.

This signal can easily be sent using one Command bit where the On/Off bit is packed with the relay code, and then unpaced and setup in the buffer.

Code:

Relay 1 On  (0b 1 11111111 11000001 00000001 00000001 00000001 00000000 0000000 00001000 00001000 0000:13,-19.5m)
Relay 1 Off  0b 1 11111111 11000001 00000001 00000000 00000000 00000000 0000000 00001000 00001000 0000:13,-19.5m)
Relay 2 On  (0b 1 11111111 11000001 00000001 00000001 00000001 00000000 0000000 00000100 00000100 0000:13,-19.5m)
Relay 2 Off (0b 1 11111111 11000001 00000001 00000000 00000000 00000000 0000000 00000100 00000100 0000:13,-19.5m)
Relay 3 On  (0b 1 11111111 11000001 00000001 00000001 00000001 00000000 0000000 00000010 00000010 0000:13,-19.5m)
Relay 3 Off (0b 1 11111111 11000001 00000001 00000000 00000000 00000000 0000000 00000010 00000010 0000:13,-19.5m)
Relay 4 On  (0b 1 11111111 11000001 00000001 00000001 00000001 00000000 0000000 00000001 00000001 0000:13,-19.5m)
Relay 4 Off (0b 1 11111111 11000001 00000001 00000000 00000000 00000000 0000000 00000001 00000001 0000:13,-19.5m)



We'd use the first pulse as the lead in,
3 static bytes
When divided this way we see the on/off code is in the 4 & 5th byte,
2 more static bytes
unit code is on the 8th and 9th byte
last nibble 0
We can pack the unit code and the on/off code into 1 command byte, and set move things around to produce this signal into small upgrade and a small executor.

Do you see how much work this can be.

The checking was just repeating the command and unit code.

Sometimes the checking as math or logic operands, that can be rather hard to spot. Look at all the work Rob did on the MCE codes that had that horrible checksum pattern!!!!
Robs work on that was dazzling!!!

It would be really nice to have a tool that lets us do some rounding, lets us force Bi-phase to odd or even, and lets us produce the binary that we'd like.

It would really be nice to have a tool that could do this, easily, and had some gui to let us tweak things.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.


Last edited by vickyg2003 on Fri Nov 16, 2018 10:07 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18563
Location: Chicago, IL

PostPosted: Thu Nov 15, 2018 8:25 pm    Post subject: Reply with quote

If the learns are in the RMIR file, Graham has modified RMIR to do a pretty good job with that already Vicky. Of course, he'll just get you to the binary, if there's a checksum in there, you're on your own with that.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7002
Location: Florida

PostPosted: Fri Nov 16, 2018 6:20 am    Post subject: Reply with quote

No I didn't realize that RMIR could now do this. The last time I tried to do it over a year ago, the learns were in a a newer remote that only RMIR could understand, and I had to copy all the learns to an an image of an older remote, save it as an IR file and then open it in IR. Its fantastic that RMIR can now do this without that timeconsuming event.


If a signal has a check that is anything other than a simple duplication, complement, or parity there is no way that I'd be able to find it.

It would be really cool if I could have a tool where I could break things apart identify the checksum portion, and then have the computer see if there was some mathematical/logicical relation to the byte that I don't understand, but that's just a pipedream.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7002
Location: Florida

PostPosted: Fri Nov 16, 2018 8:12 am    Post subject: Reply with quote

RMPB, comes with 15 tabs of documentation on how to use RMPB available from the Help Menu.

It describes the workflow from within RMIR, which I had not read before my trip down the RMPB path. If all else fails read the documenation!

The Limitations tab, was especially informational to me, because it says the amount of information you can transmit from the dcbuf varies by remote processor.

Each Remote has a 10 byte buffer to hold device and command data, I would have thought that would mean they could send 80bit signals, but that is not the case.

RMPB_Readme wrote:

There are some limitations, but many of these are general limitations that apply to ANY protocol.

The total number of bits cannot exceed the maximum allowed, and this would include bits created by bit doubling. This maximum varies depending on the processor used as follows:
Code:
       HCS08 .............. 80 bits
        S3C80 .............. 64 bits
        SST ................. 48 bits
        6805-RC16/18 .... 48 bits
        P8/740 ............ 48 bits
        6805-C9 ........... 40 bits



I remember once reading that the JP1.2 remotes could send a longer signal than the other remotes with a simple jump to the transmitter. This was the first time I ever saw that the simple transmitter had a bit limit that might be shorter that the number of bits the buffer could hold.

So the only remotes that could send a signal this long, without some special code would be a HCS08 (Jp1.2) remote. And that half nibble could only be done without assembler code if the executor had 2 bytes of dev data, and 8 bits of command data.


So there is a lot more to sending the signal than just packing a buffer with data.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18563
Location: Chicago, IL

PostPosted: Fri Nov 16, 2018 12:55 pm    Post subject: Reply with quote

Yeah, but apart from A/C units, when was the last time you needed to format an 80-bit signal?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7002
Location: Florida

PostPosted: Fri Nov 16, 2018 2:44 pm    Post subject: Reply with quote

Well yes, but this simple on off relay takes 76 bits to describe the signal. Just an example.

The RMPB_readme covers a lot of important stuff, that I've picked up along the way. I've added it to my resource list.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18563
Location: Chicago, IL

PostPosted: Fri Nov 16, 2018 3:46 pm    Post subject: Reply with quote

Yeah, for a signal like that, you'll probably need to send the bytes manually
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3005
Location: Cambridge, UK

PostPosted: Sat Nov 17, 2018 2:52 pm    Post subject: Reply with quote

vickyg2003 wrote:
This is the second time I've seen reference to the MAXQ assembler. I can't seem to find any references to vectors and variables, nor any way to modify them.

I'm not sure what is meant here by "MAXQ assembler". There is, of course, a MAXQ assembler to convert assembler language to binary, but it is irrelevant for MAXQ protocols. MAXQ protocols use a pseudocode, not native machine code and the structure of a MAXQ protocol is sufficiently complex that we have not been able to create any tools to assist with it. So the few of us that create MAXQ protocols create them by hand. The result can be checked, though, as RMPB includes an analyser for MAXQ (and TI) protocols in place of the assembler/disassembler it has for earlier processors. That analyser includes a disassembler for the pseudocode as well as giving a description of the non-code elements of the protocol.
_________________
Graham
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7002
Location: Florida

PostPosted: Mon Nov 19, 2018 1:43 pm    Post subject: Reply with quote

mathdon wrote:
MAXQ protocols use a pseudocode, not native machine code and the structure of a MAXQ protocol is sufficiently complex that we have not been able to create any tools to assist with it. So the few of us that create MAXQ protocols create them by hand.

Is there an example somewhere?

I am trying to pull together some resources so its not so hard to get started. I don't play hide-and-seek very well. I don't think other people do either, since I found that PB had been downloaded nearly 1000 times, but only 111 people had found the variable and vector chart, vital information needed to write anything but a barebones PB.

Quote:
The result can be checked, though, as RMPB includes an analyser for MAXQ (and TI) protocols in place of the assembler/disassembler it has for earlier processors. That analyser includes a disassembler for the pseudocode as well as giving a description of the non-code elements of the protocol.


Hmm is there some trick to this? I am starting with an Atlas B03 code, trying to get this to reveal, but I can't figure it out, is it buried somewhere in the documentation?

I've tried to avoid MaxQ remotes, but I did accidentally get some in a batch of dirty Atlases......
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central