Hi!

I am using a Dreambox satellite receiver and I have never been able to learn the buttons from that remote reliably. However, since the latest firmware it is getting better, but I still have problems. Some keys work, some don’t and most of the only work sometimes.

I downloaded a ccf from RC with a lot of codes and they all seem to work fine. However, I am still missing some keys and I like to get them.

These codes are examples of keys that are working fine (from an ccf in the RC file area)
1: 0000 006C 0012 0012 0008 001E 0008 0066 0008 001D 0008 006B 0008 0032 0008 0032 0008 0022 0008 0051 0008 021B 0008 001D 0008 006B 0008 001D 0008 001D 0008 001D 0008 0022 0008 001D 0008 001D 0008 0C20 0008 001D 0008 0066 0008 001D 0008 006B 0008 0032 0008 0032 0008 0022 0008 0051 0008 021B 0008 001D 0008 0042 0008 0047 0008 001D 0008 001D 0008 0022 0008 001D 0008 001D 0008 0C20

V+: 0000 006C 0012 0012 0008 001D 0008 0066 0008 001D 0008 006B 0008 0032 0008 0032 0008 0022 0008 0051 0008 021B 0008 001D 0008 003C 0008 001D 0008 001D 0008 001D 0008 0051 0008 001D 0008 001D 0008 0C20 0008 001D 0008 0066 0008 001D 0008 006B 0008 0032 0008 0032 0008 0022 0008 0051 0008 021B 0008 001D 0008 0066 0008 0047 0008 001D 0008 001D 0008 0051 0008 001D 0008 001D 0008 0C20

LEFT: 0000 006C 0012 0012 0008 001E 0008 0066 0008 001D 0008 006B 0008 0032 0008 0032 0008 0022 0008 0051 0008 021B 0008 001D 0008 0057 0008 001D 0008 001D 0008 0028 0008 002D 0008 001D 0008 001D 0008 0C20 0008 001D 0008 0066 0008 001D 0008 006B 0008 0032 0008 0032 0008 0022 0008 0051 0008 021B 0008 001D 0008 002D 0008 0047 0008 001D 0008 0028 0008 002D 0008 001D 0008 001D 0008 0C20

These are the same keys, but learned with my RU-950 remote and they work erratically:
1: 0000 006C 000C 0012 0008 001D 0008 006A 0008 001D 0008 006A 0008 0032 0008 0032 0008 0023 0008 0052 0008 021B 0008 001D 0008 006A 0008 001D 0008 001D 0008 001D 0008 0023 0008 001D 0008 001D 0008 0C20 0008 001D 0008 006A 0008 001D 0008 006A 0008 0032 0008 0032 0008 0023 0008 0052 0008 021B 0008 001D 0008 0042 0008 0041

V+: 0000 006C 000C 0012 0008 001D 0008 0068 0008 001D 0008 0068 0008 0032 0008 0032 0008 0023 0008 0052 0008 021B 0008 001D 0008 003D 0008 001D 0008 001D 0008 001D 0008 0052 0008 001D 0008 001D 0008 0C20 0008 001D 0008 0068 0008 001D 0008 0068 0008 0032 0008 0032 0008 0023 0008 0052 0008 021B 0008 001D 0008 0068 0008 0041

LEFT: 0000 006C 000C 0012 0008 001D 0008 006A 0008 001D 0008 006A 0008 0032 0008 0032 0008 0023 0008 0052 0008 021B 0008 001D 0008 0052 0008 001D 0008 001D 0008 0028 0008 002D 0008 001D 0008 001D 0008 0C20 0008 001D 0008 006A 0008 001D 0008 006A 0008 0032 0008 0032 0008 0023 0008 0052 0008 021B 0008 001D 0008 002D 0008 0041

Is there an expert who can tell me what is going on, and perhaps how I can change the non-reliable codes to more reliable codes?

Thanks!

My decode software doesn't handle that IR protocol. I'll try to find time soon to fix that, and to create a .irp file that will let my MakeHex program generate clean signals.

For testing my decoder, I just downloaded the CCF from
[Link: remotecentral.com]
If that isn't the one you were referring to, please provide a correct URL.

If I do update both the decoder and the .irp, and you get my DecodeCCF program and MakeHex program and learn how to use them, then you could fix the problem signals yourself. But in case you need more help, or if one of the other experts wants to give you the results before the tools are ready, you should post the problem signals:

You posted good and bad versions for three signals for which you have both. That's useful information (it may enable me to make the decoder able to resolve bad signals). But to provide real help would require the Pronto Hex that you need the help with, the signals that you only have bad versions of, not good.

Hi,

Thanks for your help. I am not sure which CCF file I used, I think I used several and combined them all together (because none of them where complete).

I have a complete list of codes I use (they all seem pretty clean to me) and a list of all the learned keys. I will send them to your email address mentioned in your profile, and I will indicate what problem I have with each of them (works always, sometimes, repeat problems or do not work at all). I also have a few codes I only have the learned version of, and do not work reliable. I will include them as well.

It will take me some time to put this all together. I hope I can do this tonight or otherwise tomorrow. Is there any other information I can provide you with?

BTW, I do have some experience with MakeHex and DecodeCCF, I used them several months ago. I don't expect problems there and will certainly use it to search for more discrete codes as soon as you have a new version available!

Thanks again!

sddroog,

The short answer is that these are fairly complex IR commands. Probably the most complex I have seen. Each key has two commands one sent once and then a repeat command that is similar but 1 bit changes . The commands that worked had both the complete one time and repeat command the ones that didn't had only a partial repeat command.

To learn these commands start the learning process in your Pronto then hold the OEM key down for a long time.

John,

This may help. There are some device upgrades in the OFA/JP1 files for dream box and one for Force that use the same protocol. I decoded the Force upgrade and best I can tell it uses 16 different burst pairs 0-F and the protocol is 8 burst pairs a mid frame burst and another 8 burst pairs. In your new irp notation. D(n) are fixed data bytes, :

16X16

{38k,msb}<210 -760|210 -896|210 -1032|210 -1168|210 -1304|210 -1440|210 -1576|210 -1712|210 -1848|210 -1984|210 -2120|210 -2256|210 -2392|210 -2528|210 -2664|210 -2800>>(D1:8,D2:8,D3:8,D4:8,210,-13.8m,C:8,0:8,F1:8,F2:8,210,-80.4m),(D1:8,D2:8,D3:8,D4:8,210,-13.8m,C:8,128:8,F1:8,F2:8,210,-80.4m)+

Where the top nibble of C=0 and the bottom nibble of C is the value such that the sum of the rest of the variable nibbles=0. Looks like the first byte might be the same thing, too.

Using that structure I decode the three commands above as:

0E 0F 44 1A 0F 00 01 00 1
0E 0F 44 1A 07 80 01 00 1 R(repeat segment)

0E 0F 44 1A 0B 00 23 00 L
0E 0F 44 1A 03 80 23 00 L R

0E 0F 44 1A 06 00 0A 00 V+
0E 0F 44 1A 0E 80 0A 00 V+ R

0F 0F 44 1A 0F 00 01 00 1
0F 0F 44 1A 07 7 Repeat Fragment

0F 0F 44 1A 0A 00 23 00 L
0F 0F 44 1A 03 7 Repeat Fragment


0E 0E 44 1A 06 00 0A 00 V+
0E 0E 44 1A 0E 7 Repeat Fragment



This message was edited by jarmstrong on 08/02/04 16:29.

Thanks Jon. I was almost ready to start figuring that out when I saw your post. It would have taken me a while to duplicate your results.


I bet it won't work.

I'm pretty sure the learning problem is that the protocol is too complex for this version of the Pronto firmware. While there are superficially similar learning problems caused by releasing the original remote key too soon during learning, that is not the case here.

Fortunately, the second section is redundant with the first (We can assume Jon is correct about one specific bit consistently changing between the two sections) so one can easily construct the correct whole signal from one of the bad learns, which I'll do as soon as I get that email including the bad learns for which good learns aren't available.

I'll check that JP1 upgrade to see if it gives any hints for an .irp version of this.

Wow! You guys are great helping out on this issue!


It doesn't make a difference whether you use a long or a short press. Even if you keep the button pressed until ProntoEdit says it finished, it will give you exactly the same result...

Right now I am testing all the different buttons (which is hard to do when my wife is watching television). I am sure I will get it done by tommorow.

There is just one thing I do not understand: where do the working codes come from? Did the older Pronto models do better on these codes?

Thanks!

The older Prontos do better at everything directly related to IR signals: learning them, transmitting them, etc.

I don't have any Pronto, so I can't comment usefully on the display or button differences between new and old Prontos. I assume they must have improved somewhere. But if you take the attitude (I do) that a universal remote exists to learn and send IR signals, they messed up big time.

On the other subject, I see no reason for you to TEST your learned signals (for this device). If you learned them on the NG Pronto, they're definitiely bad. If you took them from an old Pronto CCF, they're probably good. If you post or email the bad ones, Jon or I (or other experts) know how to reconstruct the good signal from the bad one.

John,

Did you receive my email? Can you do anything with it? I can't wait to do some testing and trying to find additional discrete codes.

In the mean time, can you or some other expert try to make to following code work (based on the information in my original mail above)? I have read a lot of information about IR codes, and I am able to understand most of them, but I just can figure these ones out.

0000 006C 000C 0012 0008 001D 0008 006A 0008 001D 0008 006A 0008 0033 0008 0033 0008 0023 0008 0052 0008 021B 0008 001D 0008 005C 0008 001D 0008 001D 0008 002D 0008 0023 0008 001D 0008 001D 0008 0C20 0008 001D 0008 006A 0008 001D 0008 006A 0008 0033 0008 0033 0008 0023 0008 0052 0008 021B 0008 001D 0008 0033 0008 0041

Thanks again!

Unless I made some clerical error, I think this is it:

0000 006C 0012 0012 0008 001D 0008 006A 0008 001D 0008 006A 0008 0033 0008 0033 0008 0023 0008 0052 0008 021B 0008 001D 0008 005C 0008 001D 0008 001D 0008 002D 0008 0023 0008 001D 0008 001D 0008 0C20 0008 001D 0008 006A 0008 001D 0008 006A 0008 0033 0008 0033 0008 0023 0008 0052 0008 021B 0008 001D 0008 0033 0008 0047 0008 001D 0008 002D 0008 0023 0008 001D 0008 001D 0008 0C20

It works! Thanks!

Now, can you explain to somebody who understands a little bit about IR codes (like the first 4 fields and the lead-in and lead-out stuff) how you did this?

Thanks.

First notice that if IR transmitting in the NG weren't so messed up, the original one would have worked.


I assume you mean you understand the first four fields and understand that this signal has 12 decimal pairs sent once followed by 18 decimal pairs sent repeatedly.

Jon discovered that the correct signal has 18 pairs sent once and 18 pairs sent repeatedly and the two 18-pair sequences differ only in the 12'th pair.

The original learn has the correct first 12 pairs of the 18 to be sent once. Then it has 6 pairs doing double duty. They are encoded as the first 6 of the repeat part but they're actually the last 6 of both parts. Finally it has the 12 pairs that logically begin the repeat part.

To help visualize that, use the letters ABC to represent 3 groups of 6 pairs in the part to be sent once and AbC to represent the 3 groups of 6 pairs to be sent repeatedly, which differ at just one spot from the first set of 3x6.

Logically the signal should be ABC once with AbC repeating, but for some vey good reasons it was learned as AB once with CAb repeating. If you string those together, they're really the same as long as the key is held:
ABC AbC AbC AbC AbC ...
AB CAb CAb Cab CAb ...
Since the spaces I put there aren't really there, the two sequences are the same.

But, you observed that AB with CAb repeating didn't work, while ABC with AbC repeating did work. That needs to be explained.

I notice that in addition to rearranging from AB CAb into ABC AbC, Jon also increased the last duration in b a little (changed a 41 to a 47). Let's assume he knew what he was doing (generally a good bet). Then why in a learn this consistent and generally clean was a value that must have been about 47 in the original learned signal changed by so much?

My best guess is that the IR transmitting firmware is so slow in the NG Prontos, that it adds some extra duration on the repeat boundary. I'll then guess someone at Philips tried to compensate for that elsewhere in the process by subtracting a little from the stored signal at that same boundary. If so then they got the amount wrong. Without relearning the signal from an NG remote to a better learner, we can't be sure, but I think the gap on the boundary is the wrong duration.

Most protocols don't care at all about such tiny changes in a gap length. They especially don't care when those changes occur on a correctly aligned repeat boundary. This protocol needs to care about much smaller relative changes than other protocols do, but it still doesn't care about such changes if they hit on its repeat boundary. But the repeat pattern that a pure pattern match algorythm finds in this signal is CAb as described above. The true repeat is AbC. The protocol can absorb sloppiness at the end of each C but can't absorb slopiness at the end of each B or b.


This message was edited by johnsfine on 08/06/04 10:34.

John, as always I learn something your posts. I just assumed the Learning/PENG had some serious flaws and never considered your explanation. A few technical corrections but this in no way makes your explanation invalid.


Actually the 11th and 12th pair differ. The 11th is a check nibble and the 12th is 8 in the second segment and 0 in the first, the 11th will depend on the other variable bytes. Here would be the entire sequence to compare:

0F 0F 44 1A 0C 00 31 00
0F 0F 44 1A 04 80 31 00


I'll explain the calculation for sdroog's benefit. After the first four hex words, the remaining hex words represent alternating On and Off times expressed in wavelengths of the IR carrier frequency. In this case 0008 is always the On portion and the Off portion can be one of 16 values so every burst pair represents 4 bits or a nibble of hex. The formula is:

752+Y*135 = Off Burst length in uS (where Y can be 0 to 15)

In this case we want the value of 8 so,
752+8*135 = 1832
1832/25.9 = ~71 decimal =>0x 0047

Where, 25.9 is the wavelength in uS and derived from the second word 006C:
W/L=108*.24=25.9 (006C=>108 dec and .24 is a constant used in ProntoNG commands)


I agree and with a delta of only 135 uS representing a change in value, then it's unlikely that it responds that quickly.

Back at you with similar comment, and a really trivial technical correction.


...


Since 135 is the full difference between two values and the original values would be on nominal centers, anything over HALF of 135 uS represents a change in value.

Hi,

I have learned a lot today from you and Jon, thanks!. I am able to convert other 'dirty' codes to clean codes as well now. I must admit that where you guys go into detail about the burst length I lost it a little bit, so I guess I have to read it over a few times and try to understand.

Thanks again!