I am posting this in hope that someone from URC will see it. There is a bug when importing a CCF that contains the DISH codes. When importing the CCF, the frequency and functional protocol is correct, but the timebase parameters are off by a factor of 1/3, so the ir code is sent out 1/3 faster than it should be.

Example of DISH Power Off:

Original pronto code:
0000 0048 0001 0011 0017 0159 0017 005C 0017 00A1 0017 00A1 0017 005C 0017 005C 0017 005C 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 00A1 0017 0159

Code created on import (from .mxd)
04 00 68 00 E7 00 6C 00 3E 00 0F 12 22 41 43 42 42 43 43 43 42 42 42 42 42 42 42 42 42 42 41 43 42 42 43 43 43 42 42 42 42 42 42 42 42 42 42 41 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

It should be:
04 00 68 01 59 00 A1 00 5C 00 17 12 22 41 43 42 42 43 43 43 42 42 42 42 42 42 42 42 42 42 41 43 42 42 43 43 43 42 42 42 42 42 42 42 42 42 42 41 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Note that the codes are identical except for bytes 3-10. These correspond to the 4 timebase parameters.

I am not the only person who has experienced this ([Link: remotecentral.com])

Its not clear why this seems to only effect the dish pronto code. Perhaps it effects others and it just hasn't been caught. I have seen a couple of threads in which people have had ccf import problems. Perhaps this is the issue??

Hi Ron,

There have been a number of improvements made to the Universal Browser since the thread in October. so the first question I should ask you is Have you Live Updated your software?

And out of curiousity, I have two other questions:

Why aren't you using the Dish codes in the pre-programmed database?

And, how are you reading the hex from a .mxd file?

Best Regards,

-Eric

Eric Johnson
VP of Technology
Universal Remote Control, Inc.

I am using the latest version that was put out a few days ago. I don't have te version info handy at the moment, but it is the version that has evidently been pulled back because of the mx-3000 page swithing issues.


I frankly haven't decided which preprogrammed codes I'm going to use yet. I have been an mx-500 owner for years and I recently purchased the mx-700. I'm still experimenting.

However, there are some devices that are missing some of the codes in the databases (I think DISH is complete however). There are devices that don't always put the preprogrammed codes where I want them. Now I know I can use shortcuts to "move" the codes and I know that I can physically move them on the LCD panels, but it seems if I create a shortcut on a hard button, that I no longer have access to the underlying code (unless I'm missing something), so I will need a least one learned code in this case.

I'm using a hex editor. The format of the code itself is very similar to that of an mx500 (which the irclone guys describe in good detail) so it wasn't to tough to decode the format.
byte 0: the number of parameters
byte 1,2: frequency (clock period = 2 * (256 * MSB + LSB) / 12000000)
byte 3,4: parameter 1 (Period = (256 * MSB + LSB) * clock period)
byte 5,6: parameter 2 (Period = (256 * MSB + LSB) * clock period)
byte 7,8: parameter 3 (Period = (256 * MSB + LSB) * clock period)
byte 9,10 : parameter 4 (Period = (256 * MSB + LSB) * clock period)


Thanks for your response.

Ron

BTW, I can easily work around this issue now that I understand the problem (I simply increase the timebase value in makehex from 400 to 600). However, since this does appear to be a universal browser bug, I felt that I should bring it to your attention, as I suspect other protocols other than the dish protocol may also be affected.

Ron

Do you have a URL for that?

I tried a while back to make an mxd file for a protocol that just has a one-time part and no repeat part. I couldn't get it to work.

I haven't tried again with the latest universal browser, but importing from a CCF gave me total garbage for any code that had a zero length repeat part.

Manually editing the mxd, I could adjust the repeat part to be anything from one burst up to the whole signal. But I couldn't get the repeat part to be zero bursts.

A question more than a statement, but do all the URC remotes operate on the same 12MHz oscillator as the MX500. If not then that calculation doesnt hold true across the board.

For that matter does anyone know what the other remotes operate at, specificially the MX-950 and MX-3000 since these are the two remotes I currently use.

-3B

I think you want to ask a slightly different form of that question:

What models store their IR signals in files such as mxd in a form based on a 12MHz oscillator?

The oscillator frequency implied by file format used for IR signals isn't necessarily the same as the actual oscillator used for sending the signal. The PC software might convert things before loading into the remote and/or the remote's firmware might convert things as part of the transmit process.

I have no clue what URC has varied across models. Other companies with similar issues have had the signal format fit the hardware for a first model and later decided it was more important to match signal format across models than to have that format fit the hardware of later models.

Also - I did a back to back comparison on ir formats between the mx500 and mx700 and the frequency value was the same, so I would assume that the same algorithm applies.

I have not yet checked out the repeat vs. one time portions of the code. the mx-700 may do this differently than the mx-500.

The link for the mx-500 file descriptions is

[Link: irclone.com]

In particular you want the key code discovery and mx500 memory map

I have a few additions to the key code discovery that I will post when I have some more time.

Ron

In that "key code discovery" document, note what it documents in cells D22, D23. I had reached the same conclusion and based on that I thought a signal which is entirely one-time should have the same value in those two bytes. But that didn't work.

I figured out how to do this on the mx-500. I need to find my notes and will let you know. It involves setting an extra bit on the parameter count and ending the code with a zero. It was not documented in the irclone documents. I will try to find it in a couple of hours - I have a meeting to run off to right now.

Ron

John,

Following are notes that I made to myself concerning the mx-500 codes. I'm not sure how they apply to the mx-700, 800 lines of remotes.

If bit 6 is set (i.e. MS nibble = 4), There is no repeat. In this case I have always seen the repeat values set from 0 to codelength - 1. The last nibble of the last active/blank pair is always set to 0.

If bit 7 is set I have noticed that all the active/blank pair values have an upper nibble of 0. Not sure what this means - need to investigate.

Some active/blank pairs have a compressed mode. PioneerDVD is an example of this. In the case of the PioneerDVD protocol, there are 7 active/blank pairs. A D is equvalent to 77 and an E is equivalent to 76. For example, normally b1101 would be 76 76 77 76, but in the compressed mode it would be DD ED, which takes half the space. The compressed mode can be combined with normal pairs in the same code. I have not investigated this further than the PioneerDVD protocol.

Here's an example of an mx-500 code with no repeat (nec variant):

47 00 A0 0E 30 05 E4 01 53 00 AA 00 55 00 40 00 15 00 2B 34 77 76 76 77 77 77 77 76 76 76 77 76 77 76 76 77 77 76 77 77 77 77 77 77 76 77 76 76 76 76 76 76 72 35 71 35 71 35 71 35 71 35 70 FF FF FF FF FF FF FF FF FF FF FF FF

OK - I did some experimenting. This may be an overly simple view of the problem, but it seems as though the timebase parameters in the mxd file are always (improperly) calculated using a base frequency of ~38600 Hz instead of using the frequency provided in the hex code. If the original pronto code is somewhere in the vicinity of 38600 (as most NEC based codes are), then things are fine. The further the original codes carrier frequency is from 38600, the further off the timing will be. In the case of the DISH code it is 57600/38600 = 1.49, which is the factor that was needed to correct the DISH pronto code to make things work.

I used makehex to create 3 nec1 codes, which were identical except for the frequencies. I used 38000, 48000 and 58000

The hex codes are:

Device Code: 134 Function: 0 - 38000 Hz
0000 006D 0022 0002 0157 00AC 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0689 0157 0056 0015 0E94

Device Code: 134 Function: 0 - 48000Hz
0000 0056 0022 0002 01B3 00D9 001B 001B 001B 0052 001B 0052 001B 001B 001B 001B 001B 001B 001B 001B 001B 0052 001B 0052 001B 001B 001B 001B 001B 0052 001B 0052 001B 0052 001B 0052 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 001B 0052 001B 0052 001B 0052 001B 0052 001B 0052 001B 0052 001B 0052 001B 0052 001B 0848 01B3 006D 001B 127A

Device Code: 134 Function: 0 - 58000
0000 0047 0022 0002 020F 0107 0021 0021 0021 0063 0021 0063 0021 0021 0021 0021 0021 0021 0021 0021 0021 0063 0021 0063 0021 0021 0021 0021 0021 0063 0021 0063 0021 0063 0021 0063 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0021 0063 0021 0063 0021 0063 0021 0063 0021 0063 0021 0063 0021 0063 0021 0063 0021 0A08 020F 0084 0021 1661



The resulting codes in the mxd file were:

07 00 66 0E CC 06 A2 01 5C 00 AE 00 58 00 41 00 16 24 25 34 77 76 76 77 77 77 77 76 76 77 77 76 76 76 76 77 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76 72 35 71 35 71

07 00 7C 0E CC 06 A2 01 5C 00 AE 00 58 00 42 00 16 24 25 34 77 76 76 77 77 77 77 76 76 77 77 76 76 76 76 77 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76 72 35 71 35 71

07 00 9D 0E CC 06 A2 01 5C 00 AF 00 58 00 41 00 15 24 25 34 77 76 76 77 77 77 77 76 76 77 77 76 76 76 76 77 77 77 77 77 77 77 77 77 76 76 76 76 76 76 76 76 72 35 71 35 71

Note that the frequency changes as it should, but the 7 parameters are essentially the same in each of the 3 codes. They should change as they are supposed to be based on the period of the frequency specified in bytes 1 and 2. The result is the speed up of the ir code as has been witnessed by capture ir capture devices.

Has anyone successfully imported and used ccf file that uses a carrier in the 58000 range?

BTW I'm using an mx-700

Ron

I've been too busy to follow up on any of this and expect to be too busy for it until January. But I didn't want you to think I'm ignoring you.

Of course having Eric Johnson pay attention to your results is a lot more important than having me do so. The best I could do would be add some MakeHex documentation and/or feature to help those using MakeHex work around the bug. Now that you've clarified the behavior of the bug, Eric should be able to have someone fix it very easily.