JP1 Remotes

Remote still worked after the new protocol but the issue is the same, the 8811 learns it and works, the MX-500 does not, here's an IR where the 8811 has learned from the Dreambox remote on L1 and L2 and learned second hand from the MX-500 on L3 and L4,

https://www.hifi-remote.com/forums/dload ... le_id=1744

broken wrote:Remote still worked after the new protocol

So the device isn't picky about a 4Khz increase in frequency. It probably also isn't picky about the 4Khz decrease in frequency apparently caused by some problem in the MX-500 learning.

The 42Khz signals were retransmitted by the MX-500 at 38Khz, just as the 38Khz signals were retransmitted at 34Khz.

I wonder if all MX-500's have this defect.

broken wrote:but the issue is the same, the 8811 learns it and works,

That's still quite confusing, because I now have a very good understanding of this protocol and the 8811 learns it wrong and it shouldn't have worked.

The correct version of this command has eight different durations: 7, 8, 11, 15, 16, 17, 21 and 22.

I'm not sure of the time scale of the 8811 exactly enough for a signal of this precision. But I can get some informative results by pretending to know that the 11 burst is exactly right, then using that to define the time scale. Then the 8811 and MX-500 versions are: The key to understanding this is to see that the 8811 did a decent job of learning the 7, 8, 11 and 15 values. But it does some "cleanup" so it saw the 16 and 17 values and decided they were so close together that the difference was an error, which it "fixed" so both 16 and 17 became 16.5. Similarly both 21 and 22 became 21.55.

Now, looking at the double learned values, I can assume that the 8811 is responsible for most of the distortion in the 16, 17, 21 and 22. But the MX-500 is responsible for almost all the distortion in the 7, 8, 11 and 15.

I noticed early on that the 7, 8 and 11 are all very close to 2.5% shorter in the MX-500 than in the 8811 (I'm computing that from more significant digits than I posted above). But I was worried that the pattern didn't hold for the larger values. Especially notice the value for 16 and 17 is 2.1% longer in the MX-500 than in the 8811.

But now I suspect that anomoly is something that happens when the 8811 combines the 16 and 17 values into one "average" rather than something that happens in the MX-500. I'm guessing the MX-500's 16 and 17 are both 2.5% too short but the 8811 somehow averages them to something 2.1% the other way.

broken wrote: the MX-500 does not,

So now I need to figure out how to tweak that protocol in the Dreambox to make all the durations 2.5% slower. That's a little trickier than adjusting the frequency. But I think I can figure it out.

Note that a 2.5% change is so tiny that in most protocols it makes no difference at all. But in this protocol a 22 needs to be seen as a 22. Note that the 8811's 22 is sent as a 21.55 which is closer to 22 than to 21 so it's probably OK. The MX-500's 22 seems to be 20.66 (but that is an ilusion caused by the double learning). More likely the MX-500's 22 is 2.5% low, which would be 21.45, which is closer to 21 than to 22 and probably is the reason this signal is missed by the real device.

wow, I'm learning alot, which is kinda the reason I got into this

I've never before tried to hit timing targets as exactly as this protocol seems to require. But I've patched that Protocol again, keeping the frequency shift and adding a general slowdown which I think should be as near to 2.5% as you could get within the structure of this upgrade.

Try this one in the usual ways (does the Dreambox remote still work? Learn Dreambox to 8811. Learn Dreambox to MX-500 to 8811. Does the MX-500 work?)

It also would help to learn a few different digit commands Dreambox to MX-500 to 8811 (with this new upgrade) to see how much the learning glitches are specific to this problem signal vs. a consisten shift of all the timing.

Upgrade protocol 0 = 01 6c (S3C80) Manual Settings
3D 7D 42 8B 05 00 00 6D 01 6C 6C 03 F6 80 99 E4
07 09 E4 08 0A E4 03 07 E4 04 08 F0 08 56 08 0F
6C 07 F6 80 99 F6 80 38 FB 0D 46 08 80 6C 07 F6
80 99 F6 80 38 7B FB AF 28 03 F6 80 71 28 04 F6
80 71 28 05 F6 80 71 28 06 F6 80 91 C6 F8 19 64
F6 01 45 28 07 F6 80 71 28 08 F6 80 71 28 09 F6
80 71 28 0A F6 80 91 C6 F8 9B 47 F6 01 45 8D 01
0A 48 C2 F0 C2 F6 80 7D 28 C4 8D 80 7D 1C 12 F6
01 39 56 C2 0F 6B 09 C6 F8 00 3F F6 01 45 2A F7
AF F6 80 71 1C 12 8D 01 39 38 C6 C7 03 F0 C0 3E
C7 13 F6 80 C1 3E C7 13 F6 80 C1 3E C7 13 F6 80
C1 60 C0 0E 56 C0 0F C7 26 56 C2 F0 42 20 D7 62
AF 28 C1 F0 C1 02 12 02 01 AF
End

Okay, after this latest upgrade the Dreambox remote no longer works but somewhat as intended, when the ON is learned onto the MX-500 the ON button works as Channel Up ( or Down, Prev or Next ), when learned onto the 8811 from the Dreambox remote does nothing, when learned onto the MX-500 then the 8811 has the same channel changing behaviour.

File has Dreambox ON > 8811 on L1 and L2, Dreambox ON > MX-500 > 8811 on L3 and L4,

https://www.hifi-remote.com/forums/dload ... le_id=1747

I kind of assumed you knew this but perhaps not, most buttons on the Dreambox remote learn fine onto the MX-500, it's a handful that don't,

Power ON / OFF ( the one we're working with )
Direction UP
OK
EXIT

And others I don't recall offhand, some do nothing ( like ON / OFF ) and others do unexpected things.

I guess the 8811 is not a good enough IR learner to tell us what the MX-500 is really sending, and the MX-500 is probably not a good enough learner to ever get that power toggle signal right. But there is another way to get things working.

Just to make sure I understand what's happening, I see in the command list one named "Bouquet-". Do you know which button that is and what it does? It looks to me like the MX-500 mislearns the altered power signal so that if it does anything at all it would be "Bouquet-".

Your description of what the mislearned power key actually does "Channel Up ( or Down, Prev or Next )" confuses me. Do you mean you don't know which of those it is, or it randomly does one of them or multiple learns of it act differently, or what?

For the solution:

1) Notice the description in this post
http://www.remotecentral.com/cgi-bin/mb ... i?2031,1#1
of an xml file in the linux system. Can you find and edit that file?

2) In IR.EXE for your Dreambox v3 remote, there is a Devices tab, in which SAT:0031 should be selected. Then you can see the Hex Command for each button.

3) In the file from (1), notice lines such as
key name="power" code="0f"
Notice that the Hex command for power in IR.EXE is 0F 00. The hex values correspond that way for all the keys, and that correspondence is the only way the Linux system knows which key is which.

4) You can pick a different hex code for any function you're having trouble with and change that function in both places and it all should work.

5) Changing it in IR.EXE is a bit less obvious than on the LInux side: Note the approximate postion of the code (such as 0F) in the readable list. Then press Edit to see a dense block. The 0F is about the same fraction of the way through the dense as it was in the list. Change the code (just 2 digits, not the following 00) in that dense block, then press OK and check that changed as expect in the readable list.

Make sure you select a function code that is not already used by any other function.

Some function codes are easier for the MX-500 to learn and some are harder. If I'm understanding the issues right, the function codes A6, 6A, 10 and 18 should be easier to learn and don't seem to be already used.

I think the altered version of the protocol does make it easier for the MX-500 to learn, even though it wasn't good enough to learn power. So try those new function codes first with the altered protocol. If that doesn't work, switch back to an earlier protocol.

Yeah I'd read about that file, there are a number of problems though. The Dreambox is based on open source images, these images all work a little different hence upgrades would probably invalidate this file which isn't so bad, bigger problem is a lot of Dreambox functionality is based on plugins, these plugins do not use that file for key definitions and therefore would not function properly with the new setup.

A little more investigation showed that the latest protocol upgrade had all the problem keys still not learning, I did a break down of what's not learning,

Key - Learns As

0
1
3
5
7
9
Up
OK - Right
Exit - Yellow / Pause
Power - Bouquet Down
Last Channel
Next Channel
Radio / Record
Vol Down - Vol Up
Bouquet Up - Bouquet Down

All the odd numbers being out seems curious to me, I'm trying to find some connection between the non-working keys.

Having a look at the codes, these are the non-functioning ones ( dashes indicate working codes, dash arrow indicates functions as )

00 00
01 00
-
03 00
-
05 00
-
07 00
-
09 00
-
0B 00 -> 0A 00
-
0D 00 -> 0E 00
-
0F 00 -> 0E 00
50 00
51 00
52 00
-
-
-
21 00
-
-
-
25 00 -> 24 00

broken wrote:Yeah I'd read about that file, there are a number of problems though. The Dreambox is based on open source images, these images all work a little different hence upgrades would probably invalidate this file which isn't so bad,

If you change that file, I guess you would need to merge your changes with any upgrades that change the same file. With a decent merge program that should take only a few seconds of effort and it shouldn't be needed very often. If there is a good merge program, you shouldn't need any effort at all. The update process should do the merge automatically. Some open source projects have update merging that good, but I don't about this one.

broken wrote:bigger problem is a lot of Dreambox functionality is based on plugins, these plugins do not use that file for key definitions and therefore would not function properly with the new setup.

I don't believe that last part. Try it and see. This xml file is used by the software that translates IR signals into key names and translates key names into action names. I expect there are other modules that use the action names or even the key names without consulting this file. But there wouldn't be any modules that look at the IR signals without consulting this file. If you edit this file to change which "code" goes to a given key name, I'm sure you have changed it for the whole of the Linux system.

broken wrote: A little more investigation showed that the latest protocol upgrade had all the problem keys still not learning, I did a break down of what's not learning,

If I understand you correctly, all the keys that had trouble with the regular protocol have trouble with the altered protocol. But they individual symptoms have changed (whether each key does nothing at all or does some other key's function). And you listed the new set of symptoms. Correct?

The encoded hex of the first part of every signal is
0E0F441A

The 8810 usually mislearns that part so it is closer to
0F0F441A
but you told me those mislearned signals work anyway, so it seems the Linux system is ignoring that error.

There are two different versions of the second half of each signal:

00000000 and 08800000 0
0F000100 and 07800100 1
0D000300 and 05800300 3
0B000500 and 03800500 5
09000700 and 01800700 7
07000900 and 0F800900 9
0D002100 and 05802100 Up
09002500 and 01802500 OK - 0A002400 and 02802400 Right
09005200 and 01805200 Exit - 0A004200 and 02804200 Yellow / Pause
01000F00 and 09800F00 Power - 02000E00 and 0A800E00 Bouquet Down
Last Channel
Next Channel
Radio / Record
Vol Down - Vol Up
03000D00 and 0B800D00 Bouquet Up - 02000E00 and 0A800E00 Bouquet Down

broken wrote:All the odd numbers being out seems curious to me, I'm trying to find some connection between the non-working keys.

I'm trying to deduce whether the MX-500 is doing some "code cleaning" similar to what the 8811 is doing but even more severe. If they are both doing code cleaning, I really doubt that they have the same rules, so I'd expect to see extra evidence. But in all the double learned samples, I only see the 8811's code cleaning. So in that case the MX-500 might do some of the same code cleaning as the 8811 but couldn't do more.

From your list above, I think the interesting case to deduce the MX-500's code cleaning is Bouquet Up. Using the known distortion of the MX-500 plus any subset of the 8811's code cleaning (duplicated by the MX-500), I can't explain Bouquet Up being misread as Bouquet down.

So show me Bouquet Up learned directly by the 8811 and double learned. The difference between them will help in understanding the MX-500's learning problem.

Notice that individual digits changed. I'm pretty sure F's consistently change to E's and 9's consistently change to A's and 5's consistently change to 4's, and some errors are ignored.

I'm pretty sure 1's do not change to 2's.

Because of that I was wondering whether the 2'nd digit matters. If the 2'nd digit mattered in the 2'nd version then OK and Exit couldn't be misread as Right and Yellow. If it mattered in the first version then Power couldn't be misread as Bouquet down.

But if the second digit didn't matter as all then the 5 key would be misread as the 4, key, which you said it wasn't.

So I can only conclude the 2'nd digit half matters. Each learn (each keypress) includes both versions of that key. If the second hex digit is right in either version the Linux system seems to accept it.

So how does Bouquet Up get misread as Bouquet Down? The D must be misread as E, which is quite unexpected, but not wholly unreasonable, and either the 3 must be misread as 2 or the B must be misread as A. It is totally unreasonable for the 3 to be misread as 2. So I expect the B is misread as A. This misread in two directions together on similar values (B down to A and D up to E) must be code cleaning not distortion and I think that particular example of MX-500 code cleaning is very different from the 8811 code cleaning.

johnsfine wrote:If I remember correctly (don't bet on it) there is some extra cost option to give the MX-500 the same kind of PC programability as the more expensive MX models (or am I totally confused?)

You are remembering correctly, the process is called IRClone but the guys who made the box have stopped making it. There is a file section for IRClone files over at R/C but I don't see a folder for "Dreambox".

johnsfine wrote:Which waste of money? I think you might mean the 8811 and JP1 cable. If so, I disagree:

It lets you do that experiment I described in post 11, which may lead us to a solution for the MX-500

It can be programmed to generate all these Dreambox signals. That may take a little more JP1 expert help than you'll get today, but not a lot. I or some other JP1 expert will help with that if you ask again later.

It's a really great remote. Once you get used to a good non-display remote, the lack of display stops mattering. You want to look at the TV, not the remote, anyway. So program the 8811 to be yor real remote and get rid of the MX-500.

(Of course if you meant the MX-500 was the waste of money, I agree).

Broken, now that you see how hard it is to get the MX-500 to control the Dreambox (and it may turn out to be impossible), you really should consider following John's advice and start using the URC-8811 to work your system as you CAN program the 8811 to control the Dreambox via a JP1 upgrade.

But I just bought the MX-500 and it was three times the cost of the 8811! Plus I dig the LCD named buttons. I've edited the XML file on the Dreambox ( which as johnsfine suspected does actually work for plugins, the important ones at least ) I've swapped the commands which the MX-500 couldn't learn with others that are unused. There's still some suspect behaviour, ie, some digits will not function on certain text entry fields,
some commands will not repeat ( hold down repeat ). But I've got all the commands and discrete on and off remapped and learnt so it's good to go. I'll just have to re-upload the file when I switch or upgrade images. Thanks for all your help johnsfine, I've a new understanding of all this stuff now.

How much control does that file give you? I wonder if it's possible to make the Dreambox respond to a different signal all together.

broken wrote: some digits will not function on certain text entry fields,

I can't explain that.

broken wrote: some commands will not repeat ( hold down repeat ).

That I can explain.

Remember the two "versions" I described above for each key. And I deduced the key is understood if either version is OK. But if only the first version is OK, the key can't repeat. If the second version is OK (whether or not the first is OK) the key will repeat correctly.

There are 256 possible command codes. I think you could go further toward finding a set of command codes that are still robust even after the MX-500's learning problems.

The Robman wrote:How much control does that file give you? I wonder if it's possible to make the Dreambox respond to a different signal all together.

I'm sure there is that much control somewhere in this open source design. But at the posted example of THAT file gives no hooks for changing any part of the IR signal other than the (two hex digit) command code.