JP1 Remotes

vickyg2003 wrote:Every time I change anything in the code, the LSB Comp flags clear, and the hex is recomputed. So everytime I assembled that it would shoot a different signal.

I suspect that both PB and RMPB calculate the Flags for Dev!Dev, Com!Com wrong and that's why I had so much trouble. I finally gave up using the flags. And that's why it took me so many attempts.

The LSB Comp (and related) flags have nothing to do with the executor hex that is generated. They don't even exist in PB. They are not calculated by RMPB as they have nothing to do with the settings such as Dev!Dev, Com!Com. Those settings determine how the device and command bytes are assembled into the DCBUF string passed to the executor. The flags concern the translators that relate these device and command bytes to the device and OBC parameters displayed in RM or the RMIR device editor. When I say "concern", I mean what I said before. It is the text in the Data Translators panel that determine the translation, the check boxes just provide a means to create simple translators. When I load your file, the check boxes are all unchecked yet the translators panel shows

DevParms=Device 1=0,Device 2=0,Device 3=0
DeviceTranslator=Translator(lsb,comp,0) Translator(lsb,comp,1,8,8) Translator(lsb,comp,2,8,16)
CmdParms=OBC
CmdTranslator=Translator(lsb,comp,0)

where all translators are lsb comp. So when you export the protocol, the .prot file created in the AddOns folder will contain these translators and when this is loaded into RM (as part of the loading of protocols.ini), the relation between the device and OBC parameters and the values passed to the executor will be lsb comp.

You say "Every time I change anything in the code .. the hex is recomputed". This is an issue? Of course the hex is recomputed if you change the code, else why change the code???

vickyg2003 wrote:So I did as you say, I loaded my filde saved it and gave it a variant name 56repeats.

Now when I try to load it I get an error message
"You can only load a variant for a Manual Protocol"

Sorry, I forgot this one. But I am puzzled. "I loaded my file ...". But I thought it wouldn't load, it gave that lengthy string of error messages. And I never mentioned giving a variant name. I said edit the Name, not the Variant Name. You are effectively creating a protocols.ini entry and that name is what, in protocols.ini, appears in square brackets at the start of an entry. That is the name that appears in protocol drop-down lists.

Here is s youtube video of EXACTLY what I am doing.

https://youtu.be/balwXjmb5xM

As you say in your video, we are not on the same page. The only file you have posted is a .rmpb file. The file you load in your video is a .rmdu file. If you post the file you are loading in your video, I will be able to investigate further.

Your original message posts a .rmpb file with the description "Protocol builder, when loading this, it throws exceptions". That is what I have been answering. I cannot make that file throw exceptions.

RDMU file where custom protocol was created.
https://www.hifi-remote.com/forums/dload ... e_id=25467

This is a custom protocol load error file
https://www.hifi-remote.com/forums/dload ... e_id=25474

Again, my problems were the device flags are clearing changing all the hex any time I try to correct the protocol. As I said in my post, this particular protocol took me 63 builds to get it right, and that meant I had to reclick those 7 boxes 63 times. That is a lot of clicking.

My second problem is I can't get the protocol to appear in a box, if I try to load it.

The RDMU in question works fine. I was able to deliver the file and the user, and he was able to tweak the number of repeats, although he then had to do the 7 clicks.

I'm really, really trying to get my head around this PB replacement.

I appologize for not testing earlier. I know that nobody can crash a program as fast as me.

Thanks for looking.

Vicky AKA Crash

BUG Report.

Extinstall in the current version does not work with my 8820N JP1.2 extender.

I also can't open the Base.IR files that I packaged with my 8820N JP1.2 extenders in the current version of RMIR.


It used to work in 2.05 build 8....

Extender files can be found
https://www.hifi-remote.com/forums/dload ... le_id=9561

OK, now I see that there is a problem. It may take a while to resolve it, I have to think my way back into how protocol editing and RMPB works.

mathdon wrote:I have to think my way back into how protocol editing and RMPB works.

I absolutely loath "thinking my way back". I apologize for not hitting this while this stuff was fresh in your mind.

I have now posted RMIR v2.07 build 3 to the RMIR development folder. This contains fixes for those of the issues raised by Vicky that I could identify. Vicky, my testing has been exhausting rather than exhaustive, so please give it a try and report on anything you find that is not fixed. My confusion over your original posts was because I thought you were using RMPB. I had forgotten that RM can save and load manual protocols as .rmpb files.

I have found that the issue concerning the clearing of the device and command checkboxes when you edit a manual protocol goes way back to RMIR v2.02, when assembler features were first added to RM and long before RMPB was created. It just goes to show how little, if at all, those features have previously been used. Anyway, I hope I have fixed it to your satisfaction.

The issue of the non-appearance of the edited protocol in the protocol drop-down of RM does date from the creation of RMPB. The ability to create and edit manual protocols, and to create custom code for standard protocols, has been in RMIR since v2.02 but the UI for it was changed to align with that of RMPB when RMPB was created. This bug is due to an oversight in making those changes.

In my testing, I discovered an obscure bug whose consequences probably extend beyond the issue that led me to its discovery. Fixing this may have resolved other issues you may have experienced. I was never able to reproduce "closing RM shows a boatload of java exceptions". If it still happens, please give me precise instructions on how to reproduce it, as the rmaster.err file you posted turns out not to be of much help.

I hope that when the protocol editing features in RM are satisfactorily resolved, you will move on to testing RMPB itself.

vickyg2003 wrote:Extinstall in the current version does not work with my 8820N JP1.2 extender.

I also can't open the Base.IR files that I packaged with my 8820N JP1.2 extenders in the current version of RMIR.

I have downloaded the extender package from the link you gave. The file "10820N Extender A BASE.ir" loads fine in RMIR v2.07 build 3. I then created an unextended setup for the 10820N using File > New and used File > Install extender to install into it the file "10820N Extender A.hex". Again, it worked as expected. Additional devices appeared in the General tab and the Raw Data tab confirmed from the signature that it was now a setup for the extended remote.

One thing I did NOT do was use the RDF included in your package. There have been two corrections to protocol versions since that original RDF and these are included in the latest RMIR packages, but I can't see how those could cause your loading to fail. I also can't see how the changes from build 2 to build 3 can have made a difference. If you still get an extinstall failure, please post the rmaster.err file as it is a mystery to me why it should work for me and not for you.

mathdon wrote:

vickyg2003 wrote:Extinstall in the current version does not work with my 8820N JP1.2 extender.

I also can't open the Base.IR files that I packaged with my 8820N JP1.2 extenders in the current version of RMIR.

I have downloaded the extender package from the link you gave. The file "10820N Extender A BASE.ir" loads fine in RMIR v2.07 build 3. I then created an unextended setup for the 10820N using File > New and used File > Install extender to install into it the file "10820N Extender A.hex". Again, it worked as expected. Additional devices appeared in the General tab and the Raw Data tab confirmed from the signature that it was now a setup for the extended remote.

The extender works on this end too. Thank you.
What was happening before is none of the special protocols worked. This time around things work as expected. With build 2 all sorts of weird dialog boxes came up when trying to create a DSM, LKP, ...

One thing I did NOT do was use the RDF included in your package. There have been two corrections to protocol versions since that original RDF and these are included in the latest RMIR packages, but I can't see how those could cause your loading to fail. I also can't see how the changes from build 2 to build 3 can have made a difference. If you still get an extinstall failure, please post the rmaster.err file as it is a mystery to me why it should work for me and not for you.

I didn't either. I submitted my extender RDF's for maintenance by the RDF Librarian. I never thought I'd still be here this long after writing the extender.

mathdon wrote:Vicky, my testing has been exhausting rather than exhaustive, so please give it a try and report on anything you find that is not fixed. My confusion over your original posts was because I thought you were using RMPB. I had forgotten that RM can save and load manual protocols as .rmpb files.

I have found that the issue concerning the clearing of the device and command checkboxes when you edit a manual protocol goes way back to RMIR v2.02, when assembler features were first added to RM and long before RMPB was created. It just goes to show how little, if at all, those features have previously been used. Anyway, I hope I have fixed it to your satisfaction.

The issue of the non-appearance of the edited protocol in the protocol drop-down of RM does date from the creation of RMPB. The ability to create and edit manual protocols, and to create custom code for standard protocols, has been in RMIR since v2.02 but the UI for it was changed to align with that of RMPB when RMPB was created. This bug is due to an oversight in making those changes.



I hope that when the protocol editing features in RM are satisfactorily resolved, you will move on to testing RMPB itself.

RemoteMaster is a BIG program and there are so many ways of doing things that I can see how errors can get through.


I'll try to give this a better workout. I am trying to get around needing a copy of Excel. I've had it with Microsoft and that clumsy ribbon! Really what are they thinking, making it so difficult to work with a product that used to be so EASY! Now everytime you change the shape of the window, the icons move and hide. WHO EVERY THOUGHT THAT WAS A GOOD IDEA??? End of rant for till next year when I have to use Windows 10, yuck!

vickyg2003 wrote:I am trying to get around needing a copy of Excel. I've had it with Microsoft and that clumsy ribbon! Really what are they thinking, making it so difficult to work with a product that used to be so EASY! Now everytime you change the shape of the window, the icons move and hide. WHO EVERY THOUGHT THAT WAS A GOOD IDEA??? End of rant for till next year when I have to use Windows 10, yuck!

While I do use Excel 2013 at work, at home I still use Excel 2000 and Windows 7. I never allowed my PC to upgrade to 10.

vickyg2003 wrote:I am trying to get around needing a copy of Excel.

Oh, good! That means you might be using RMPB "for real", rather than just testing. Avoiding the need for Excel was one of the motivations for creating RMPB.

I've had it with Microsoft and that clumsy ribbon! Really what are they thinking, making it so difficult to work with a product that used to be so EASY!

Absolutely! I used to be the first to upgrade to new versions of MS products when new meant improved, but now I dread upgrading as new now means worse and more difficult to use.

Development build 6 of RMIR v2.07 is now available in the RMIR Development folder. It provides two new ways for Windows users to access the Bluetooth capabilities of RMIR, without the need for the Bluegiga BLED112 dongle. Please see this post in the thread Bluetooth is coming to RMIR for full details.