Does anyone know if URC is working on adding the ability to enter hex codes directly into the editors? This was discussed quite some time ago and it was a very popular topic. I thought they were working on it at the time and really expected it to be added by now, but it is still notibly missing.

The kludge of entering the code into the Pronto editor and then importing it into the URC editor is a workaround (at best), not a solution. Hard to imagine continuing to recommend using a competitor's software to accomplish this.

Sean

Don't know but can you expand a little on how to copy the HX code from the pronto over to the MX Editor? I've designed several pronotos but this is my first URC - MX-3000

first, the hex has to be learned format, beginning with 0000. I believe that you can only import from ccf's not pcf's, but I could be wrong.

Then, open mx editor, hit the universal browser button on the top menu bar (looks like a couple of colored sqauers and triangles)

Open the ccf you want inside of universal browser. Navigate to the page that has the code you want. Drag and drop the button from the ccf page to the mx button you want it on. The code will copy over, and will display it as a learned code. Make sure to test this code on the mx remote immediately, as I have not been able to properly import some codes.

Fro what I've read many of us CI's have been asking (clamoring?) for URC to support direct input of Pronto-type hex codes in MX Editor ... it doesn't seem like it'd be a technical challenge (nor a legal one, since RTI is doing it), so I don't understand their reticence on this issue.

Would very much like to hear from a URC rep on this!

I'm trying to work on this now. If there are any software programmers here who want to be a part of the project, please contact me at: [email protected]



Thank you,
Damon DG
= = = = =
http://www.ProRemotes.com - Authorized Dealer & Remote Programming Services

Damon, could it be that URC is trying to avoid this so that thier database can't be exported?

No. It actually has nothing to do with their database. In order to export their database, they would have to create the connectivity to do so in the software. If they don't create it, it's not an issue. Actually, hex data would probably never come into contact with the database at all anyway. They can remain separate from one another.



Thank you,
Damon DG
= = = = =
http://www.ProRemotes.com - Authorized Dealer & Remote Programming Services

What does "this" mean?

Any convenient way to directly enter Pronto Hex would require changing the GUI of the editing program. I assume you don't have source code or other practical way to change that GUI, so this definition of "this" doesn't track.

Next best would be a way to create .mxd files similar in concept to (but hopefully less kludgy than) the way MakeHex and IrPanels together create CCF files.

The key to that is more understanding of the format of .mxd files. But that understanding would work both ways (extracting info as well as inserting info) which you seem to be denying. If that's what you're trying to do, give me some details. I don't have a lot of time to donate and I only have a very partial understanding of .mxd file internals, but I might save you some duplicate effort. And if you did figure out enough about the format I might do the work of building a direct path from something like Makehex. Of course that's all based on THAT wild guess about what you mean by "this". What do you mean?

Next best would be a way to create .mxd files similar in concept to (but hopefully less kludgy than) the way MakeHex and IrPanels together create CCF files.

Can you elaborate on this? How does this work, and does this get around the MX Editor's req't of "learned" IR codes available for import?

John,

"This" is a method of importing hex without going through Pronto Edit. Essentially, a piece of software that will allow for translation/importing of hex to a usable MXD/MCF/RCC/MXA file.

Altering the Editor software is not the direction I intend to go in, but rather working with the individual file formats themselves, as you wrote.

When explaining to Tippy that theft of the database is not an issue for URC increating their own hex importing feature, that is correct. That feature, if created by URC, does not mean that the user will be able to extract and steal the preprogrammed database. You are correct in saying that "understanding would work both ways", but I was not talking about granting the end user access. If someone had the time or skill, they can take the database now. It's not an issue of end user functionality though.

I hope this clarifies what I meant. :)



Thank you,
Damon DG
= = = = =
http://www.ProRemotes.com - Authorized Dealer & Remote Programming Services

Using MakeHex and IrPanels already is a method of importing hex without going through ProntoEdit.

It does provide all signals in the form that the MX Editor considers "learned". It doesn't generate any of the special condensed forms of Pronto Hex that the MX Editor (last I tested, which wasn't the current version) didn't accept.

I think Damon may want to bypass the Universal browser as well as bypassing ProntoEdit.

As for netarc, I've described how to use MakeHex and IrPanels to create a CCF for the universal browser in a couple other threads here. Try to find and read one of those. If you're still confused, ask some more specific questions and I'll try to help.


We all seem to be talking around and past each other on that question, rather than connecting.

I agree with you that a Pronto Hex import feature provided by URC in the MX editor would not compromise anyone's database security. I don't know why URC hasn't done that simple task.

I haven't looked into how MX software pieces fit together enough to form an opinion on whether some user project reverse engineering mxd file format would compromise someone's database security.

If I knew mxd format I would provide the easy software to decode signals into the common concise and precise form used across remote lines by many of us who jhave reverse engineered IR protocols and file formats. I expect I would also write the harder software to got the other direction (decoded form into mxd). I don't know if any of that would compromise URC's database security. I'm sure the larger impact would be to improve the effectiveness of their resellers. But companies rarely seem to understand the benefits of documenting things like mxd file format.

Took me awhile to find it again, but this link may help you.

Mike
www.SurfRemoteControl.com

Thanks, but it's mainly a subset of the obvious aspects of mxd format, not the parts I didn't see myself.

It is plenty if you want to find a specific signal in an mxd. It is enough if you want to manually change a signal in an mxd to a different command of the same device (the process described there).

But it isn't close to enough if you want to build a new mxd from external content or have a program (less than human pattern matching skills) find its way around an mxd.

He does say "a few prior to that identifies a unique ID for the learned code which corresponds to the label you'll see elsewhere in the MXD". That's one detail I didn't see on simple examination. Therehas to be a way to tie the signals in one part of the mxd to other content (button or function names, etc.) in another part. But I never figured that out nor anything else about the non signal contents of the file.

He also says: "I'm beginning to suspect that there's a lookup table in the MXD file that these individual bytes are referencing for the actual IR burst timing. It appears to exist just prior to the first learned code". That's a key aspect to understand if you want to do more than the most trivial manipulations. That's one part I do understand and I think he has misunderstood (or the files he looked at were seriously different from those I looked at).

Unfortunately that thread is all 2.5 years old, so it doesn't indicate anyone is actively pursuing the topic.

Oh well, it was worth a try. :-)

The last programming I did was over 30 years ago in and it was in Fortran, so I can't help with this. It was before URC added the Universal Browser, so I think that's why it was never pursued after that. Doug (the poster of that thread) is still very active on other forums and the e-mail address in his signature line is still valid to my knowledge. He's a software designer that lives in N.J., so you may want to contact him, Damon.

I havent done more than just glance at any file format other than the MX-3000, but I do know that format fairly well at the moment due to the work with my DMX-3000 software. I can point out each IR code, all buttons associated with it, whether or not it was a learned code or part of the included database, etc. If the other remote are of a similar file structure I should be able to do the same there.

The problem I see, as johnsfine already stated, is that since there is no way to add direct hex editing into the editors themselves, the best you can do is end up with what is already available. A standalone app that takes in a HEX code and spits out a CCF which can then be used in the Universal Browser, to me this is the best solution. Simply because the editors will all accept the same CCF as input. However, if you wanted to create MXD, MXA, RCC, etc, you will have to decipher all of those formats instead of the already well known CCF format.

Maybe I will get some spare time to read up on the Pronto HEX information. Anyone point out a good place to start ?

-3B