RMIR v2.15.0 pre-release for testing

[HamburgerHelper1]

FTDI cable using DIY GADGET JP1 adapter on RS 15-1994 works for me

[jmezz13]

@jmezz13: I am unclear from your last post what the situation now is concerning uploading to the 8811. You say it now works. Is that with jp12serial v0.24 or with the version present in RMIR? The difference between v0.24 and later versions is that it will repeat read attempts on failure, which is why the later ones are "less finicky" about the connection. I was wondering if this behaviour was incompatible with the JP1 EEPROM Adapter that you must be using to communicate with the 8811 with a JP1.x interface. I would be interested to know what adapter you are using, and whether the JP1.x cable is an FTDI one, as I can't really see why there should be any such incompatibility.

The upload to the 8811 is working with v0.24, but still errors with v0.25. Here is the upload error with v0.25 from rmaster.err with the rmir file included in my diagnostics upload. This is with 2.15.4 as well. It also doesn't just error on this file, it errors with both extended and unextended rmir uploads.

Edit: BTW, I see the current jp12serial.dll is 0.32 according to Help/About.

Code: Select all

Testing interface: JP1.X Serial
Port Name = COM5
Opened on Port COM5
Opened interface type 7
Interface opened successfully
Base address = $0
Data writing phase succeeded, bytes written = 2048.
Upload verification phase starting.
0380: FF != 21
Upload verify failed: data read back doesn't match data written.
Ending upload

The cable I'm using is the FTDI cable with the DIYGagdet EEPROM adapter. If you have any troubleshooting suggestions, I would be interested.

Also, thanks for your extra work tracking down the bug in such an old remote. I"m not sure how I got it working in the first place back then.

[jmezz13]

Just in case it is helpful, I uploaded a file to the diagnostics area showing the data source (in IR file format) that was supposed to be written, and a raw download that reflects the data that was actually written which triggered the verification failure.

http://www.hifi-remote.com/forums/dload ... e_id=26715

[jmezz13]

FTDI cable using DIY GADGET JP1 adapter on RS 15-1994 works for me

@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?

[mathdon]

Also, thanks for your extra work tracking down the bug in such an old remote. I"m not sure how I got it working in the first place back then.

Still on the issue of the raw download .ir file, can you confirm whether this actually works in the remote? In particular, do all 8 special functions work? What I have found shows that the data structure of JP1 remotes supports such extra-long special functions, that RMIR can create them and can decode them on a download, but whether or not they actually work in the remote is a different matter. That will depend on the implementation of the extender, and the only way to know is to test it and see. Now that RMIR can load the file without error and without changing any bytes, you can upload it to the remote for testing if, as I presume, you don't have a remote that still has this setup.

If it doesn't work, or even crashes the remote and needs the batteries taken out and replaced to restore working order, then I think I will leave RMIR able to decode it but will display a warning message when such a file is loaded or created.

[davecs]

I've tried some stuff on the URC-3661 with 2.15.4

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.

Because there is no Push/Pop or Hold/Restore function on this remote, Global Macros are only any use for startup, or selecting dev4/8. What I was trying to do was allocate a long-press button to restore sound, as the amplifier on my system switches itself off after a period where it doesn't have any input.

I did a long-keypress on the Mute button, which sends Discrete Power On, then Discrete Unmute. In everything except Audio mode, this obviously has to be topped by 'Audio' and tailed by the device being used. It means a separate macro for each device, but this would be impossible without RMIR. You have to say that this remote is very powerful indeed. But only with RMIR.

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?

[davecs]

I did a long-keypress on the Mute button, which sends Discrete Power On, then Discrete Unmute. In everything except Audio mode, this obviously has to be topped by 'Audio' and tailed by the device being used. It means a separate macro for each device, but this would be impossible without RMIR. You have to say that this remote is very powerful indeed. But only with RMIR.

Arrrggggghhh!

This prevents the "Punch through" on the plain Mute key from working. Looks like I'll have to use a less obvious key. I already found that I can't use the Input key because it has a Key Move on it.

Still, it will be worth it in the end. I'll have to use a key that makes sense in terms of its label. And that has no macros nor key moves on.

UPDATE: Moved the MultiMacros to the Last Channel key. Working as intended.

You have to work hard to get the best out of the 3661, as I understand it's not possible to put an extender on it, but it's worth it in the end. And, to repeat myself, not possible without RMIR.

[davecs]

I just did the same thing on the 6440, but all I had to do was change a global macro on the MUTE button to a Global DKP (I have used DKPs on that remote).

One small thing, when I added the new DKP on the Special Functions Tab, the left hand column, instead of saying <none>, was blank. The entry in Segments, however, looked correct (started 10 etc). On saving and reloading, the <none> entry was there. Seems a little strange in the respect that it was blank when a previous testing version left that column blank and used the wrong flag (0F) which led to the remote not working. This does, however. The TV has been taken over right now so I can't tell you for certain, but it does appear to be working.

[mathdon]

One small thing, when I added the new DKP on the Special Functions Tab, the left hand column, instead of saying <none>, was blank.

Thanks for pointing this out. I want to get even little things right. I have just fixed this for the next build, but I don't think that on its own it warrants issuing a new one yet.

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?

Yes, this limitation was already present in v2.14 builds and I put it there after testing.

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 will look into highlighting the Global Multimacro case too. Again, thanks for spotting this.

I think those are the only actual issues arising from your posts, the rest being just a report of your findings. If I've missed something that needs fixing, please post again to point it out.

[jmezz13]

Also, thanks for your extra work tracking down the bug in such an old remote. I"m not sure how I got it working in the first place back then.

Still on the issue of the raw download .ir file, can you confirm whether this actually works in the remote? In particular, do all 8 special functions work? What I have found shows that the data structure of JP1 remotes supports such extra-long special functions, that RMIR can create them and can decode them on a download, but whether or not they actually work in the remote is a different matter. That will depend on the implementation of the extender, and the only way to know is to test it and see. Now that RMIR can load the file without error and without changing any bytes, you can upload it to the remote for testing if, as I presume, you don't have a remote that still has this setup.

If it doesn't work, or even crashes the remote and needs the batteries taken out and replaced to restore working order, then I think I will leave RMIR able to decode it but will display a warning message when such a file is loaded or created.

I'm able to upload the IR file using 0.24 jp12serial.dll. The good news is that it doesn't crash the remote. The bad news is that the macros don't quite work as intended (either using or not using the special functions). The macros seem to set up the modes correctly (transport etc), but will not send actual button functions (like power on/off etc).

[mathdon]

@jmezz13: If you instead load from the .rmir file to the remote, which should be the same but with the extra-long special function shortened, do the macros then run correctly? If they still don't, could you try uploading the .rmir file with v2.14.18? I really would like to identify where they are going wrong.

I also have a bug find of my own to report, which I probably won't have time to fix till Tuesday. I have tried to install v5 of the extender for the RCRP05B into that remote and it fails, but it works in RMIR v2.14.18. I suspect the fix is quite simple, but out of time now till Tuesday.

[davecs]

I will look into highlighting the Global Multimacro case too. Again, thanks for spotting this.

I think those are the only actual issues arising from your posts, the rest being just a report of your findings. If I've missed something that needs fixing, please post again to point it out.

The other clash on the 3661 is between Volume Punch Through and Multi Macros on Mute (and by implication, Vol+ and Vol-). What happened is that a short press on Mute, in TV mode, caused the TV to mute instead of the amplifier, ignoring the VPT on that key. The long press worked as intended.

I do find it funny that One For All has stopped you using Timed Macros on the keys meant for Multi Macros, and vice versa, but allowed them both on most other keys! But just as well for our purposes.

[davecs]

@Graham: Oh by the way, I've noticed another, positive, difference and I'm wondering if it's anything you did? Just to say that when I use the URC6440 and OARUSB04G, set up as per the thing I put in the wiki in 2019, RMIR autodetects the remote. Before, if I had previously used a JP1.x remote, I had to type in the path to the USB remote, but now I don't have to. Was that your handy-work?

[HamburgerHelper1]

Potenza BC4 download shows it has four segments type 17
RMIR V2.1.5.0 reports "segment type not known to RMIR"
I also believe the RDF is incomplete

[jmezz13]

@jmezz13: If you instead load from the .rmir file to the remote, which should be the same but with the extra-long special function shortened, do the macros then run correctly? If they still don't, could you try uploading the .rmir file with v2.14.18? I really would like to identify where they are going wrong.

I tried the original rmir file in 2.14.8 and even tried back to 2.10.3 and both had the same results as the ir file. When I press TV then Power to activate the extender, I get four blinks. Device macros don't work as intended and just pressing the power button always gives four blinks so something about the structure of my file just isn't compatible. I did try an earlier version of an extended setup with macros and special functions and it works fine so I don't think the remote itself is at fault.

Also, I have to admit I don't see where the two byte difference exists in the Special Functions. When I open the Raw DL ir file and the original rmir file, the special function lengths look the same to me, but I'm probably missing something obvious. The SAT Xshift-Phantom3 has this hex in all the formats as far as I can tell:
27 47 2D 63 40 3E 47 3E 47 2E 63 3F 55 3E

The fact that this behavior occurs in 2.15.4, 2.14.18 and 2.10.3 leaves me scratching my head how I had this working at one time. I tried some earlier builds like around 2.03, but they won't run on my Win11 machine. Feel free to ignore this issue as you see fit - I'm not trying to take this update down a rabbit hole. I am kind of interested in getting the JP1.x cable upload working with these remotes, but that too probably has limited applicability to the user base. Right now, I've just reverted to using the Delcom interface for these remotes.