I have a JVC DVD, XV-S500BK. I've been living with the fact that a simple TSU3000 key tap doesn't work with that particular unit. It usually needs a prolonged (minimum half second ?) press.

When I look at my learned code (from the original remote), for example "Pause"

0000 006D 0001 0011 0140 00A2 0014 003D 0014 003D
0014 003D 0014 003D 0014 0014 0014 003D 0014 003D
0014 003D 0014 003D 0014 0014 0014 003D 0014 003D
0014 0014 0014 0014 0014 003D 0014 0014 0014 0295

... I see 1 burst pair for the one key press and 17 pairs for the repeat. Even John Fine's Makehex produces the same structure.

I figured I could copy the repeat portion into the one key press portion and adjust the counters.

0000 006D 0011 0011 0014 003D 0014 003D 0014 003D
0014 003D 0014 0014 0014 003D 0014 003D 0014 003D
0014 003D 0014 0014 0014 003D 0014 003D 0014 0014
0014 0014 0014 003D 0014 0014 0014 0295 0014 003D
0014 003D 0014 003D 0014 003D 0014 0014 0014 003D
0014 003D 0014 003D 0014 003D 0014 0014 0014 003D
0014 003D 0014 0014 0014 0014 0014 003D 0014 0014
0014 0295

Although the code apparently works, the simple key tap is still not consistant. So back to questions.

Can someone:

1- explain what is the reason of that single press being one pair long?
2- tell me if this structure is unique to JVC?
3- offer an alternative for a consistant one key press?

I find this behavior quite annoying, specially with the up/down arrow commands when I want to position the cursor at a specific line within the menu. I REALLY need to time that press and hold so not to overshoot. I've assigned the up/down arrow commands to the Pronto's cursor pad: could this have anything to do with it?

Here's a late twist....

I have a button, let's call it M1, containing 2 links:
- the first link is to a button (B1) containing an X10 IR command (code) to an IR543
- the second is a link to a button (B2) containing the Pause IR code for that JVC

Even a short tap on M1 consistantly works, the thing pauses. But if I press B2, then I need to press and hold for the Pause to occur. I would have anticipated the opposite, so there goes another portion of sanity.

Any clues, theories?

Have you tried setting the duration for this code?

I guess the TSU3000 is so lame that it may be worth changing the JVC.irp file used by MakeHex.

You got it nearly right in copying the repeat part into the one time. But it might work better if you add the repeat part onto the one time rather than replace:

0000 006D 0012 0011 0140 00A2 0014 003D 0014 003D 0014 003D 0014 003D 0014 0014 0014 003D 0014 003D 0014 003D 0014 003D 0014 0014 0014 003D 0014 003D 0014 0014 0014 0014 0014 003D 0014 0014 0014 0295 0014 003D 0014 003D 0014 003D 0014 003D 0014 0014 0014 003D 0014 003D 0014 003D 0014 003D 0014 0014 0014 003D 0014 003D 0014 0014 0014 0014 0014 003D 0014 0014 0014 0295

The JVC protocol has that extra burst on just the first frame. The JVC.irp file has the extra burst instead of the whole first frame, because that OUGHT to give the same result. The extra burst is so short you couldn't release the key fast enough that it would be released before the extra burst is done. If the key is still pressed at the end of the one-time part, the only correct behavior for the Pronto is to immediately start the repeat part. But the TSU3000 seems to throw some extra pauses where they don't belong and gets this wrong.

Your JVC device may need a long enough press that even the version I posted above won't do it.

Do I understand Peter's reply correctly? That means the promised firmware upgrade that will allow direct control of duration has already been released? If so then that would be a better way of dealing with this problem.

Peter,

After my initial post, I did try setting the duration at 0.5 sec and a few quick tests gave positive results.

John,

Interesting point. As I've learned, the Pronto, when I press and hold, still emits the single press burst before emitting the repeat burst. So, does the Pronto:

a) process the single press burst and then after, and only then, verify whether the key is still depressed?
b) process the single press burst and, in parallel, verify whether the key is still depressed?
c) process the single press burst and, in parallel, wait a certain number of cycles before verifying whether the key is still depressed? This would compensate for human reflexes

Maybe the simpler question would be: how does the Pronto distinguish between a 'press and hold' and a 'one press' from a slow reacting person? Logic would dictate a latency factor.

My real objective with this thread is to better understand the Pronto's logic, which is driving nuts at times and so I can understand why a button containing the IR code is less responsive than one linking to the first.

John, the new firmware has been released and looks like we have a case here where setting duration has worked.

Seems to me that the Pronto, like many remotes, just doesn't have enough repeats by default for IR it transmits. it doesn't mean there's anything wrong with the Hex you see in PEdit (or posted above).

For instance, if you look at a Sony code in Pronto hex you won't see repeats. However, when a device receives a Sony IR code, it does expect to see it multiple times in a row. I've seen some people post 2 and others post 3. Sony's flagship Navitus for instance gets this right on single-key presses, but fails to adhere to the repeat count in macros.

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. Remotes such as those from RTI and Harmony support a repeat property and even allow it to be changed by the customer/programmer per device (RTI actually allows it to change per command).

Changing the JVC IRP to produce anything other than what's outlined in the various JVC documents would not be in the best interest of the community at large - regardless of what this specific Pronto remote does. Unless a special "Pronto3xJVC.irp" or something similar were made for this specific purpose.

Bruno

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.


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.


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.


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.

First, I can tell you that this "IR duration" parameter is just great. On my JVC S500BK DVD, I modified the duration of every key press to 0.2 secs and now single tap presses work reliably. BTW, 0.1 didn't work for me. I could have tried in between's but I held back my obsession.

Now the question: How would the IR duration operate if the code had no repeat section, only a single press section?