RMIR v2.15.0 pre-release for testing

[HamburgerHelper1]

If you didn't do this already, can you upload a file to the remote, then open a different RMIR file and try to upload that and see if it works on the RS 15-1994?

Works like it should 1st time, then closed RMIR and tried again this time i got error upload verified failed.
Sorry I was busy playing with other remotes since i saw segment 17 in the potenza as being unknown or i would have done this sooner

[mathdon]

I found that you can't have Long-Key Press using Multi-Macros, on keys where the ordinary function involves Key Moves. I get the yellow/brown highlighting if I do a Device Specific Multimacro, and the regular key is the one that doesn't work. But if I do a Global Multimacro, there is no highlighting, but the Multimacro doesn't work.

I have tested this myself and think that there is no need for highlighting in the Global Multimacro case. The intention of the yellow/brown highlighting is to indicate that only one of the highlighted items will work, so the user should select which one they want and delete the other. That is not the case with your Global Multimacro situation. Yes, on the device and key that has the keymove, any length of keypress will send only the keymove signal. But that key on any other device will work as intended, a short press will send the normal signal for that key (assuming there is no keymove on it in this device), and a long keypress will send the multimacro keys. So both the keymove and the global multimacro are active, making it a valid choice to keep both of them.

I noticed that you can't put Real Time Macros on the 4 colour keys, nor Multi Macros on the 3 App keys. I assume this has been tested?

I will put a new option, "Disable Upload Restrictions", on the Advanced menu in the next build. With this option selected, there will be no highlighting of conflicts and everything will be uploaded to the remote. This will enable you, and everyone else, to test it if they feel that RMIR is disallowing some combination that they think should work. The option will not be persistent, so it will be deselected every time RMIR starts, even if it was selected when RMIR was last shut down.

Also, I have to admit I don't see where the two byte difference exists in the Special Functions.

The difference will be obvious if you enable highlighting of raw data, menu Options > Highlighting. You will then see in the Size & Color column that in the .rmir case the size for the SAT/XShift-Phantom3 is 16 and in the .ir case it is 18. If you double-click that column and set a highlight color then the 16/18 bytes will be highlighted in the raw data column.

[HamburgerHelper1]

I noticed that you can't put Real Time Macros on the 4 colour keys, nor Multi Macros on the 3 App keys. I assume this has been tested?

From previous testing and reading the user manual the 4 colored keys are dedicated for multimacro to make a channel list and the 3 App keys are dedicated to timed macros
for the purpose of giving the correct timing for a streaming app to respond.
I believe early on in one of the threads of the 3660 during development of the RDF
all of this was tested but it might be worth playing with to see if someone can force those button to do other things.
Although being dedicated in the firmware I doubt anything else can be done

[davecs]

I noticed that you can't put Real Time Macros on the 4 colour keys, nor Multi Macros on the 3 App keys. I assume this has been tested?

I will put a new option, "Disable Upload Restrictions", on the Advanced menu in the next build. With this option selected, there will be no highlighting of conflicts and everything will be uploaded to the remote. This will enable you, and everyone else, to test it if they feel that RMIR is disallowing some combination that they think should work. The option will not be persistent, so it will be deselected every time RMIR starts, even if it was selected when RMIR was last shut down.

I wouldn't expect you to do that. I only asked because, in the drop down list for available keys on the 3661, if you select Multi, then App1/2/3 aren't in the list. If you select RealTime, then Red/Green/Yellow/Blue aren't in the list. Nothing to do with conflicts. Just checking to see if this was deliberate, based on experience, that's all. If it's right, it's right, leave it alone.

[HamburgerHelper1]

I stand corrected Real-time macros will work on colored buttons
I simply put # in front of the multi-macros line like this
and then put a timed dsm on Red and it works
#[MultiMacros]
Red=0
Green=0
Yellow=0
Blue=0

[jmezz13]

If you didn't do this already, can you upload a file to the remote, then open a different RMIR file and try to upload that and see if it works on the RS 15-1994?

Works like it should 1st time, then closed RMIR and tried again this time i got error upload verified failed.
Sorry I was busy playing with other remotes since i saw segment 17 in the potenza as being unknown or i would have done this sooner

Thanks. I was trying to make sure it wasn't just my remote or PC (although I have tried it on 3 PC's with the same error).

The difference will be obvious if you enable highlighting of raw data, menu Options > Highlighting. You will then see in the Size & Color column that in the .rmir case the size for the SAT/XShift-Phantom3 is 16 and in the .ir case it is 18. If you double-click that column and set a highlight color then the 16/18 bytes will be highlighted in the raw data column.

I think I really confused everything when I uploaded the first file (8811_UploadDownloadIssues.zip) into the diagnostic area because I included files for both the download and upload error. The rmir file in that file was meant to be reviewed with the rmaster(UploadFail)2_12_5.err for upload issues. That rmir does have 16 bytes in the SAT/XShift-Phantom3, but the file causing the download problems was 8811br(sam40pandvddish)v2.rmir and that file has 18 bytes in that same Special Function. This file was uploaded to the diagnostics area in 8811_UploadErrorCompare.zip along with the Raw Download (ir format) of that file. They both have 18 bytes in that special function. I am very sorry for the confusion I caused.

That said, the significance of the long special function is still there as the v2 of the rmir file with an 18-byte special function doesn't work on the remote whereas v1 with the 16-byte special function does.

To summarize since I've confused everybody including myself, the RMIR file I shared with the 18-byte special function does not work when uploaded to the 8811 remote (even with 2.15.4) and also causes a download error when trying to do a standard download to the remote. So, it's probably best to revert back to supporting only 16-byte special functions. Not sure if it's worth it to highlight non-comforming special functions. I'd consider the download error report as resolved and not a bug in RMIR, but due to a non-conforming RMIR file.

The upload error still remains a mystery and was also confirmed by HamburgerHelper1 on his RS 15-1994 so I assume this implies that jp12serial.dll ver 0.25 and above may have an issue with the EEPROM adapter from DIYGadget(?). I wonder if it's worth trying an Arduino EEPROM adapter since I still have an extra Arduino Nano lying around.

[HamburgerHelper1]

For any one Testing with the URC-3660/61/68
I suggest for background info you read the thread "New Remote URC-3660"
This lengthy conversation is the development of the 3660 RDF
and Mathdon's explanations will give you insight as to what was tested
and how things work.
Matrhdon's hard work and explanations might help you in your endeavor of more testing.
I know it helped me

"New Remote URC-3660"

http://www.hifi-remote.com/forums/viewt ... highlight=

Randy

[mathdon]

I wouldn't expect you to do that. I only asked because, in the drop down list for available keys on the 3661, if you select Multi, then App1/2/3 aren't in the list. If you select RealTime, then Red/Green/Yellow/Blue aren't in the list. Nothing to do with conflicts. Just checking to see if this was deliberate, based on experience, that's all. If it's right, it's right, leave it alone.

I've now done it, not just for you but because I think it is a valuable aid to testing, for me as much as anyone else. It can save a lot of fiddling when trying to test something that is forbidden in standard use. Yes, I know your question is not to do with conflicts, but what I have done addresses that as well. When Disable Upload Restrictions is selected, all buttons become available for all macro types and will upload to the remote. If the option is deselected while an otherwise forbidden macro is in the setup, that macro will get a new highlight color, Light Purple when not selected, Dark Purple when selected, and will not be included in an upload. I need to do more testing before posting it, though. Also be aware that new features can also introduce new bugs, so be on the lookout when you try it.

In view of HamburgerHelper1's finding, I will use this myself to test whether or not the RDF needs amending. I am not too surprised if it does, as new features of the 3660 series were found bit by bit and incrementally added into RMIR, which is not a good recipe for creating a good final structure.

@jmezz13: I only have one JP1 remote, a URC-8550. I will test on this, and if I too find the behaviour you are getting then I can investigate it. My JP1 EEPROM Adapter is a Tommy Tyler one, though, not a DIYGadget one. I don't know how much they differ. If I can't reproduce the behaviour then it becomes much harder for me to investigate it.

[davecs]

I stand corrected Real-time macros will work on colored buttons
I simply put # in front of the multi-macros line like this
and then put a timed dsm on Red and it works
#[MultiMacros]
Red=0
Green=0
Yellow=0
Blue=0

I tested this on the 3661 and can confirm it works, as I put a Real Time Macro onto the Blue button.

[mathdon]

Quick update for jmezz13. I too find with my URC-8550 that a first upload to the remote succeeds, a second one with a different setup done straight afterwards fails on verification. Since then, all further upload attempts have also failed with the verification error. So I do have something to work with.

[HamburgerHelper1]

Weird it appears that it is working but with a hic-cup
I can add a device then upload and get the error but re-download and the device I added is there in the remote then if i add more devices uploads and downloads work
I even tried a different setup RMIR and got error but download shows it worked and can then add more devices after the first initial download right after the error

[jmezz13]

Quick update for jmezz13. I too find with my URC-8550 that a first upload to the remote succeeds, a second one with a different setup done straight afterwards fails on verification. Since then, all further upload attempts have also failed with the verification error. So I do have something to work with.

That's good news. I'm glad to hear it is reproducible even on a different JP1.x cable setup. It probably means the Arduino EEPROM adapter won't help, but I'll probably try it anyway for fun.

Weird it appears that it is working but with a hic-cup
I can add a device then upload and get the error but re-download and the device I added is there in the remote then if i add more devices uploads and downloads work
I even tried a different setup RMIR and got error but download shows it worked and can then add more devices after the first initial download right after the error

That is weird. Does the rmaster.err show a memory location for the verify error? Mine was saying the verification issue started at 380H (but that's on a 8811 remote, so others may be different). Does the uploaded RMIR work completely as intended?

Edit: Make that 3C0H not 380H for the 8811

[HamburgerHelper1]

rmaster.err does not show a memory location just fail
and yes remote works as expected with the upgrade I added

[jmezz13]

@HamburgerHelper1 - Thanks, that is interesting.

Given that, I just tried uploading an RMIR setup and getting the verify error, then just downloading the remote and re-uploading with no changes and do not get an error. The setup on the remote seems to be working normally. I can then add a device and upload without additional errors. Maybe more info for mathdon to help in troubleshooting.

[mathdon]

I have found what is happening. There is a bug in jp12serial. Writing to the remote is performed in blocks. Recent versions do some optimization so that they do not write a block that consists entirely of FFs. A block is erased to all FFs before it is written, so writing FFs to it would take time but make no difference.

Well, that is the case with the E2 area in flash. JP1 remotes have their data in a real EEPROM. You do not need to erase an EEPROM before writing to it, but jp12serial still skips writing blocks that are entirely FFs, so leaving behind the previous data in that block. These blocks that are entirely FFs are past the end of the data that is actually read by the remote, so in a practical sense, leaving old data behind should not matter. As some of you have found, the upload does actually work despite the verification failure. So this cannot be end end of the story.

The final chapter is the existence of checksums. Checksums are calculated on the data in the whole address range specified for that checksum in the RDF. This includes the left-behind data, so verification finds the checksum values to be wrong. If you look in the raw data tab after downloading to RMIR a remote that has uploaded with a verification error, you will find just a few boldface bytes. These are the erroneous checksums.

I hope to be able to fix this tomorrow.