On 09/20/04 21:01 ET, Dave Houston said...
I don't buy the explanation (or maybe I don't
fully understand it).
In case you want to reverse engineer it yourself, here is some information that might prove helpfull. Please don't be offended if some of it is obvious and/or things you already know. I tend not to know/remember which other experts know what:
A config file for a Pronto NG is esentially a renamed .zip file. You can open it with an unzip program and get at the files inside. If you get a zip of the file from RC it's zipped twice and must be unzipped twice.
The main file inside is an XML file. That can be read with an ordinary text editor, but is linked together with id numbers that make it rather hard to manually navigate (I don't know of any generic utility for navigating XML internal links, but I assume it must exist).
If you make a new config with PENG containing just one learned signal it's quite easy to find that signal in the XML and see the internal hex form of that signal.
If you change just the Pronto hex for that signal and resave the config and re extract and view the XML (gets rather tedious) you can see how the internal hex changes for any given change in the Pronto hex. Except for the translator bugs in PENG it would be quite easy to deduce the whole internal format by a moderate sequence of such experiments. Despite those bugs you can learn quite a lot about the internal format this way.
In particular, you could take the shorter of the two signals in this thread (which IIRC will translate properly, so it didn't actually need the tweak) see how it translates, then tweak it and see how totally different the result is from that seemingly tiny change.
Is the limit on unique burst pairs or on unique
time intervals?
It's not exactly a limit, more of an effect. It is definitely not about burst pairs. It is about individual time intervals regardless of whether they are On or Off values. Simplistically it is a count of unique time intervals, but there are exceptions, that you might need to understand if you applied the same concepts to a different protocol.
I can compress both the original and "fixed" versions
to 42 bytes.
I don't understand. Does "compress" refer to anythin similar to what PENG does? If not, why would it be relevent.
There are RF codes that are known to work with
the NG which have 5 unique time intervals. Both
pulses and spaces can be any of the 5 intervals.
There are 5 burst pairs in each code so there
could be as many as 5 unique burst pairs.
You can have far more unique time intervals. 4 is not a limit nor is 5. But if you have more than 4 it changes the way the whole signal is encoded. The issue in this thread is sort of a limit on the total number of burst pairs (total count not unique count) but that limit depends on which encoding is chosen which depends on how manu unique time values there are.
Put more simply, you're allowed more total burst pairs if you have 4 unique time values than if you have 5 unique time values.
The second sample in this thread has too many burst pairs to be encoded with 5 unique time values but not too many with 4.
