Hi !
I'm have a litle problem:
On my old remote Tsu6000 learned ir codes from adb set-top-box work fine
(yes, i know it's xmp protocol, but realy work fine) and now before import to my new tsu7000 is'nt. Learning from adb remote to tsu7000 fail.
What is wrong ??
Hex xmp codes work in old tsu6000 and not in new tsu7000 ?
Any help, please !!
Reg.
Tom

I don't know what xmp protocol is, but I can see a possibility --
*your note seems to indicate that you're surprised that xmp works when learned on a 6000
*the 7000 uses a different processor and the software is different, and guess what? you get different results when you learn the xmp protocol into it

Perhaps it's wrong that the xmp protocol codes worked in the 6000 and the more advanced electronics of the 7000 don't let you learn those commands.

Hi !
I'm surprised she did not know the XMP-1 protocol:)
You're right, but it is newer tsu7000 pronto hex format is rather the same for the whole family pronto so I was surprised that the imported codes do not work.
But I managed to get to know through decodeccf most important parameters used in the protocol xmp remote adb ( Device 42.19) and generate proper hex codes using makehex, irpanels and everything works!
When I find time to prepare all codes for controlling satellite set-top box the ADB 2850ST in pronto hex format :) and makes them available in versions for download from the "files" section.
Reg.
Tom

The NG series tries to shorten or clean up the codes and in certain cases, like changing NEC1 protocol from raw to 900A series codes, the lead out time will be shortened or lengthened and may fall outside the spec of what the equipment requires. One way to avoid this is to "double up" the repeat data such that a code that starts like this:

0000 006D 0022 0002 (one-shot data) (repeat data)

looks like this:

0000 006D 0022 0004 (one-shot data) (repeat data) (2nd copy of repeat data)

In most cases, this is enough to keep NG series from converting to short format.

If you search for 0022 0004 you will find some posts where I have discussed this before. You may be able to apply the same thing to the XMP codes.

Lyndel

Hi !
I don't know why, but tsu7000 change value in learning signals:
Look on example:
TSU6000

POWER
0000 006d 0024 0000 0008 0023 0008 004d 0008 002d 0008 006d 0008 0032 0008 0032 0008 0028 0008 0052 0008 01f1 0008 0023 0008 0057 0008 001d 0008 002d 0008 001d 0008 0023 0008 001d 0008 001d 0008 0c0b 0008 0023 0008 004d 0008 002d 0008 006d 0008 0032 0008 0032 0008 0028 0008 0052 0008 01f1 0008 0023 0008 002d 0008 0048 0008 002d 0008 001d 0008 0023 0008 001d 0008 001d 0008 0023

PROPER CODE

POWER
0000 006D 0012 0012 0008 0022 0008 004B 0008 002C 0008 006A 0008 0032 0008 0032 0008 0027 0008 0051 0008 0215 0008 0022 0008 0056 0008 001D 0008 002C 0008 001D 0008 0022 0008 001D 0008 001D 0008 0C00 0008 0022 0008 004B 0008 002C 0008 006A 0008 0032 0008 0032 0008 0027 0008 0051 0008 0215 0008 0022 0008 002C 0008 0046 0008 002C 0008 001D 0008 0022 0008 001D 0008 001D 0008 0C00

In ADB set-top-box signal "power" has number "1", hex code from tsu6000 show in decodedll device 42.19, 1 and is right, but this code not work on tsu7000.
Work this second, but this show this same result 42.19, 1 in decodedll.
Strange, but true.
Nevermind, now all buttons works fine, thank's for answering :)
Reg.
Tom