Your Universal Remote Control Center
RemoteCentral.com
URC's Consumer Remotes Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
Combining two hex codes into one?
This thread has 9 replies. Displaying all posts.
Post 1 made on Sunday July 23, 2006 at 02:47
PChek
Long Time Member
Joined:
Posts:
May 2003
206
Is it possible to string together two hex codes generated by MakeHex (in this case, NEC1 Code 64 for a Toshiba HDTV), into a single hex code? I tried just concatenating them, but that didn't work. Hoping one of you gurus here may know if it can be done.

What I'd like to do is to have a single code which transmits first code 100 (Aspect) and then code 0 (digit 0); another which does 100 and then 1; another for 100 and 2; one for 100 and 3; and one for 100 and 4. What this does is bring up the aspect OSD, and then presses 0, 1, 2, 3, or 4 for Natural, TW1, TW2, TW3, or FULL.

When I place these two-code strings in a macro on the MX-850, they work perfectly. No delay is needed between the Aspect and the digit. If they could be combined at the hex level, they would become a single code. That code could then be placed on a button, allowing a push-and-hold macro to be place on the same button--something I can't do when they are places as macros.
Pchek
Post 2 made on Sunday July 23, 2006 at 07:38
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
Yes it is possible. There are a few threads in other RC forums describing how.

You might want to first read about the basics of Pronto Hex at
[Link: remotecentral.com]

The threads on merging Pronto Hex cover the aspects of Pronto Hex you need, but reading the above document may be more understandable. Either way you need to understand splitting a signal into header, one-time portion, and repeat portion. Then put those three parts of the merged signal together.

You may also want to experiment with removing the repeat portion from one (or both) of the signals. A Toshiba TV probably doesn't need the repeat portion of the NEC1 signal, but I'm not certain of that.

A merged signal must have:
A) the One-time portion of the first command.
B) zero or more copies of the repeat portion of the first.
C) the One-time portion of the second.
D) zero or more copies of the repeat portion of the second.

A, B and C must all be in the one-time portion of the merged signal. For use instead of a macro, D could also be in the one-time portion.
OP | Post 3 made on Sunday July 23, 2006 at 19:01
PChek
Long Time Member
Joined:
Posts:
May 2003
206
John, thanks again for very helpful information. It looks rather involved, but I hope to read up and perhaps give it a try, when I have sufficient time.

Based on your experience, would you think it likely that a Toshiba TV would respond properly to an Aspect-Digit combined code if it were properly constructed, or am I just wasting my time :-).
Pchek
Post 4 made on Sunday July 23, 2006 at 21:48
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
On July 23, 2006 at 02:47, PChek said...
No delay
is needed between the Aspect and the digit.

My own Toshiba has various stange and inconvenient delay requirements. (But it is too old to have Aspect at all).

If you really need no delay, a working spliced command should be easy.
OP | Post 5 made on Sunday July 23, 2006 at 22:23
PChek
Long Time Member
Joined:
Posts:
May 2003
206
What I was indicating there is that I did not have to put a delay step in the macro as recorded on the MX-850, but I have no idea whether any delay would be needed when splicing the hex strings together.

I've just finished reading Barry Gordon's article (very good) and understood it. The NEC1 Code 64 .ccf I generated matches his NEC example in pattern, though the numbers are slightly different. I can understand how a single command works.

But I have yet to read or understand how to splice them together. That's the next step. But I see a problem right off: the NEC transmissions are always of fixed length--a 32-bit ones-compliment code.
Pchek
OP | Post 6 made on Monday July 24, 2006 at 04:52
PChek
Long Time Member
Joined:
Posts:
May 2003
206
It Works! [And much thanks to all you gurus who've helped in the threads and also provided good documentation.]

After much more reading, I did some experimenting. The Aspect command is NEC1:64:100:

0000 006D 0022 0002 0157 00AC 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0015 0015 0040 0015 0040 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0040 0015 0689 0157 0056 0015 0E94

All of the Toshiba codes are of the form:

0000 006D 0022 0002 body 0157 0056 0015 0E94

where the body consists of:

the leadin - 0157 00AC
followed by 32 data bits, followed by
the leadout - 0015 0689

They all have the same two-bit repeat burst, even though some buttons repeat and some do not.

I had no idea whether the leadin and leadout portions of they body should be included for _each_ of the two strings I wanted to concatenate, or not. So I built four sets of codes, then downloaded them for testing.

The first set looked like this:

0000 006D 0044 0002 0157 00AC Aspect Body 0015 0689 0157 00AC Digit Body 0015 0689 0157 0056 0015 0E94

which is the full body (including standard leadin and leadout) for each of the two strings, followed by the standard repeat burst.

The second set looked like:

0000 006D 0044 0002 0157 00AC Aspect Body 0015 0E94 0157 00AC Digit Body 0015 0689 0157 0056 0015 0E94

which is the same as the first, except I increased the length of the leadout on the _first_ string to that of the longer leadout used on the repeat burst, in order to provide more time between the two strings in case it might be needed.

The third set was just like the first, except I removed the repeat burst as you mentioned, John, that it might not be needed:

0000 006D 0044 0000 0157 00AC Aspect Body 0015 0689 0157 00AC Digit Body 0015 0689

The fourth set was like the second (longer leadout), again with the repeat burst removed.

The results were these: All of the sets worked fine. They performed exactly like the two documented discretes that do exist (TW1 and Full). But there were some differences between the sets, having to do with repeating.

The first set did not repeat with the button held down. The second set and the fourth set both performed the desired function, then (if the button was held down) rapidly repeated *just the Aspect portion*, so that the aspect rapidly advanced from one setting to the next, as long as the button was held. I find this strange, as the second set includes the repeat burst, and the fourth set does not.

The third set repeated like sets two and four, except that it would advance two steps, then return to the programmed step, and repeat the cycle. i.e. if pressing the Aspect-1 button, it would repeat the cycle 1-2-3, whereas sets two and four, if pressing the Aspect-3 button for example would repeat the cycle 3-4-0-1-2.

The normal Aspect command does not repeat at all, but if it is pressed repeatedly while the Aspect display is on-screen, it steps to the next aspect on each press and cycles through, like sets two and four above, though obviously not as rapidly.

I have no idea why they behave this way, though I'm sure you gurus can figure it out. Is there any reason to prefer one over the others? If not, I'll just use set one, as I can see no reason for needing repeats on this command.

But for all intents and purposes, these function exactly as discretes for each of the aspects, which I find very pleasing. I haven't yet tried this with the input selections, but I'm sure they will work just as well. And I suspect that these will also work fine on other models of Toshiba TVs.
Pchek
Post 7 made on Monday July 24, 2006 at 07:48
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
On July 24, 2006 at 04:52, PChek said...
I had no idea whether the leadin and leadout portions
of they body should be included for _each_ of
the two strings I wanted to concatenate, or not.

Did you mean "leadin and leadout" or did you mean "repeat". I'm pretty sure the leadin and leadout are required for each.

So I built four sets of codes, then downloaded
them for testing.

IIUC, you did have leadin and leadout for each command in all four samples, and you left out the first repeat part in all four samples. You varied whether or not you left out the second repeat part and whether or not you added a little delay inside the first leadout. Apparently those variations made little difference.

The first set did not repeat with the button held
down. The second set and the fourth set both
performed the desired function, then (if the button
was held down) rapidly repeated

..
I find this strange, as the second
set includes the repeat burst, and the fourth
set does not.

I think that's a bug in the Universal Browser.

I didn't notice an explicit mention of the Universal Browser in this thread. But this is a URC forum, not a Pronto forum.

The device itself probably doesn't need a repeat part for the signal. A Pronto is perfectly happy to use Pronto Hex without a repeat part. But the Universal Browser won't correctly import Pronto Hex without a repeat part. I should have mentioned that earlier and explicitly asked whether the Universal Browser is involved.

I don't fully understand the transformation you get when you try to import Pronto Hex without a repeat part. I'd expect worse results than you described. But I stil think that bug is the cause of the repeats that you didn't expect.
OP | Post 8 made on Monday July 24, 2006 at 20:27
PChek
Long Time Member
Joined:
Posts:
May 2003
206
On July 24, 2006 at 07:48, johnsfine said...
Did you mean "leadin and leadout" or did you mean
"repeat". I'm pretty sure the leadin and leadout
are required for each.

IIUC, you did have leadin and leadout for each
command in all four samples, and you left out
the first repeat part in all four samples. You
varied whether or not you left out the second
repeat part and whether or not you added a little
delay inside the first leadout.

Yes, I meant leadin and leadout. This is new to me and I didn't know whether or not they were require for each--but now I do. :-) Yes, you understand correctly.

I think that's a bug in the Universal Browser.

I didn't notice an explicit mention of the Universal
Browser in this thread. But this is a URC forum,
not a Pronto forum.

Yes. In the top post, I described wanting to do this for an MX-850 as a bit of a work-around for not using a macro, and the success is perfect for that application. However, if the thread has strayed from topic for this forum, I'm sorry. I didn't specifically mention using the Universal Browser, but perhaps should have, because...

The device itself probably doesn't need a repeat
part for the signal. A Pronto is perfectly happy
to use Pronto Hex without a repeat part. But
the Universal Browser won't correctly import Pronto
Hex without a repeat part. I should have mentioned
that earlier and explicitly asked whether the
Universal Browser is involved.

I didn't know about this, but am glad that I now do, in case I need to construct any other codes. :-)

I don't fully understand the transformation you
get when you try to import Pronto Hex without
a repeat part. I'd expect worse results than
you described. But I stil think that bug is the
cause of the repeats that you didn't expect.

I'm sure you're right. I'm still a little confused though--all of the (normal, unmodified) NEC1:64 codes generated by MakeHex have the very same two-bit repeat burst. So what determines whether or not a button repeats?
Pchek
Post 9 made on Monday July 24, 2006 at 20:57
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
On July 24, 2006 at 20:27, PChek said...
all of the (normal, unmodified) NEC1:64
codes generated by MakeHex have the very same
two-bit repeat burst. So what determines whether
or not a button repeats?

The two codes you imported that had that two-bit repeat burst were taken correctly and repeated because they have that part. The two without that were taken incorrectly and transformed from signals that shouldn't have repeated to signals that did.

That still may leave some variety in exactly what is repeated and how fast, explaining any differences you see in how the device responds to the four repeating signals.

Or were you asking from the point of view of the device rather than the remote? All NEC1 signals have that repeat part sent by the remote. The device is free to ignore that repeat part if repeating is a bad idea for that particular function. That decision is in the device, not in the remote (for other protocols that decision might be in the remote).
.
OP | Post 10 made on Monday July 24, 2006 at 21:20
PChek
Long Time Member
Joined:
Posts:
May 2003
206
On July 24, 2006 at 20:57, johnsfine said...
The two codes you imported that had that two-bit
repeat burst were taken correctly and repeated
because they have that part.

Samples one and two had the repeat part, but sample one did not repeat. Sample two did repeat, but only the first part of the combined code, not the second part.

All NEC1 signals
have that repeat part sent by the remote. The
device is free to ignore that repeat part if repeating
is a bad idea for that particular function. That
decision is in the device, not in the remote (for
other protocols that decision might be in the
remote).

Barring my confusion about sample one versus sample two, this answers my question about the NEC1 protocol--that it is the device which determines the repeats.
Pchek


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse