On 04/19/05 12:54 ET, TwistedMelon said...
Seems to me that the Pronto, like many remotes,
just doesn't have enough repeats by default for
IR it transmits.
For IR in sequences, it has too few for some protocols. But in the firmware version that had more, it was still too few for some protocols, but was too many for others. It should be under the user's control and it seems like they finally got that.
it doesn't mean there's anything
wrong with the Hex you see in PEdit (or posted
above).
There may be seperate issues with representing the JVC lead-in as the whole one-time portion and the real signal as the repeat part. If the transmit firmware had no timing problems, it would be OK to represent it that way. But I haven't heard enough to be sure whether even the duration control is enough to really get JVC right. It may still also need the longer form of the Pronto Hex (that I posted in this thread) to get a really good signal.
For the Pronto, sure adjusting duration can fix
such a problem, but it shouldn't be necessary.
The thing should have a repeat count property
and apparently doesn't seem to.
If the user knows the (protocol specific) conversion there is no effective difference between controlling repeat count and controlling duration. It's just a question of which unit the user is more likely to have for the initial request.
I've seen a lot more users looking for how to achieve a specific duration than looking for how to achieve a specific repeat count. ProntoEdit ought to do that conversion for you in both directions. But it isn't too hard to do yourself.
Changing the JVC IRP to produce anything other
than what's outlined in the various JVC documents
I based in on reverse engineering signals long before I saw any JVC documents. Such JVC documents as I recall described something closer to the 18 burst one-time part and 17 burst repeat part (that I posted in this thread) rather than the 1 burst one-time part and 17 burst repeat part of the .irp file.
For a transmitter that behaves sanely, there is no difference between those two forms. (So I chose to write the .irp for the shorter of the two).
On a single action key the transmitter SHOULD:
1) Start transmitting the one-time part so soon after the key is pressed that the delay wouldn't even enter the computations at a time scale of IR signals.
2) At the end of each part (the one-time part or each iteration of the repeat part), completely overlap all processing delay into the final gap of the part being completed (as an old Pronto or an OFA remote does) so the next part starts exactly at the end of the current part.
3) During that overlapped processing, decide whether to start the (next) repeat part based on whether it has completed debouncing the release of the key.
4) Whenever it starts any repeat part, complete that repeat part (stop only on the boundary before or between repeats).
From the symptoms I've heard, the NG must fail badly at (1). The short press behavior couldn't be as bad as reported unless it delays recognising the press substantially longer than it delays recognising the release.
We know the NG fails (2) very badly because of the behavior of codes where it learned the repeat pattern out of phase. The out of phase repeat would be nearly symptom free unless it also introduced large and fairly inconsistent processing delays between parts.
I believe it also has some debounce issues to get (3) wrong. But that's a very indirect inference from ambiguous symptoms.
I haven't heard anything implying it gets (4) wrong.
