JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RMIR v2.13 available
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jul 17, 2021 8:39 am    Post subject: RMIR v2.13 available Reply with quote

Edit: RMIR v2.14 is now available and supersedes this version, see this announcement.

RMIR v2.13.0 is now officially released..

Version 2.13.0 of RMIR contains a large number of minor improvements and bug fixes since the last official release, which was v2.12.15. In particular the version of IrpTransmogrifier that it incorporates has been updated to v1.2.10 LTS (Long Term Stable), the jp12serial library has been updated to v0.28 and a new interface, JP11USB, has been added. This new interface provides one of two means to connect to remotes that use a JP1.1 connection. This is the one connection type that it had not been possible to test with RMIR as the developers did not have one to test with. When testing became possible, due to a user kindly donating such a remote, it was found that RMIR did not work with it. This has now been fixed. For details, select JP11USB from the Remote > Interface menu and a pop-up will give full details.

As mentioned above, RMIR incorporates IrpTransmogrifier by Bengt Martensson (Barf). This is a program for decoding, analyzing and rendering IR signals that is used by RMIR but is entirely separate from it. Command-line access to IrpTransmogrifier itself is available if required through the command files irptransmogrifier.bat (for Windows) and irptransmogrifier.sh (for Linux and Mac OS X) in the RMIR installation folder.

The supported platforms are 32-bit and 64-bit Windows, Linux and Mac OS X, together with experimental support for Raspberry Pi. This version, like the others since 2.09, requires Java 8 or later. All later Java versions are supported, the current one is Java 16. Oracle has recently changed the way Java is licenced and distributed, as described in this informative article.

RMIR supports all currently known types of UEI remotes, including XSight and Simpleset remotes. UEI has closed down the EZ-RC.com website that provided support for XSight and similar remotes. RMIR provides complete replacement support for these remotes, including the ability to upgrade the firmware to the last version that UEI issued. XSight users new to RMIR, especially ones who have been directed here from the legacy page at EZ-RC.com, should read the Wiki article Getting started with XSight and Nevo for further information.

No special action is needed to perform a firmware upgrade on an XSight remote. Just do a download in the usual way. If a firmware upgrade is available it will be offered. You may install it or not, at your choice, and if you choose not to install it, you are given the opportunity not to be offered the upgrade again in future.

The XSight and Simpleset remotes are supported by RMIR directly via their USB interface, without the need for any cable other than the USB lead supplied with the remotes. Other remotes are supported through their JP1 6-pin connector with JP1.x interface cables that use an FTDI chip. These cables are also available with a Prolific chip instead of the FTDI one, but many remotes will not work with these cables. More information on this is given below. It is strongly advised that you use a cable with a genuine FTDI chip - there are also cables with counterfeit FTDI chips on the market and these too will often not work.

Remotes that support the Bluetooth UEI phone app can access RMIR through their Bluetooth interface, in several ways. All supported OS platforms can do so with a BLED112 Bluetooth dongle. Windows users have two additional access methods. One uses the Bluetooth stack that is built in to Windows 10, but the remote needs v2.00 of the Bluetooth extender installed and this installation requires a one-off use of a JP1.x cable. The other is available both for Windows 10 and some earlier Windows versions (but so far only tested on Windows 8.1) and does not require this use of a JP1.x cable, but needs the installation of the BlueSoleil Bluetooth stack. See the Bluetooth thread Bluetooth is coming to RMIR for more details.

To upgrade from v2.12 without losing your settings, delete everything in your installation folder other than the RemoteMaster.properties file that contains your settings. Then unzip the new installation package into that folder and you are done. Alternatively, if you wish to keep your v2.12 installation and port your settings to v2.13, follow the installation instructions below and then copy the RemoteMaster.properties file from your v2.12 installation to this new one. In this case, however, you will need to use the menu item File > Set Directory to change the locations of the RDF, Images and AddOns folders from being in the old installation folder to the new one.

The RMIR menu item Help > Check for updates checks for new builds as well as new versions. If a new build or version is available then this menu item displays a message containing a hyperlink that will take you straight to the download for the update. This works in any build from v2.11 on, but not with versions earlier than v2.11 due to a change in the SourceForge website that maintains the distributions.

To install RMIR for any OS, first unzip the installation package to a new folder that is not read-only. For a Windows OS this means, in particular, that it should not be unzipped into a subfolder of the Program Files folder. After unzipping it, do the appropriate one of the following:
  • If your OS is Windows then run Setup.vbs by double-clicking or otherwise. This will create three shortcuts, one each for RMIR, RMDU and RMPB. They will be created in your installation folder, but they are also copied to Start > All Programs > Remote Master if you are running a Windows version that has a Start menu. You may copy them to your desktop, or any other location, as you wish. Setup.vbs also creates file associations to open .rmir files in RMIR, .rmdu files in RMDU and .rmpb files in RMPB.

  • If your OS is Linux then run setup.sh from Terminal as a shell script. If the current directory in Terminal is the RemoteMaster installation directory then the command "sh setup.sh" will run the script. It creates three .desktop shortcuts, one each for RMIR, RMDU and RMPB. They will be created in your installation folder, but they are also copied to your $HOME/.local/share/applications folder to ensure that they appear on your Dash. setup.sh will also add you to the dialout group of users, if you are not already in it. If you need to be added, then it will ask you for your sudo password as this step needs to be run with root privileges. This step is needed to enable RMIR to access USB serial ports without RMIR itself being run as root.

    The distribution also contains a text file linux_xsight.rules. If you have an XSight or Nevo remote, you may need to copy this to the directory "/etc/udev/rules.d/". It may be re-named if desired, provided the extension .rules is kept. This file provides a user-friendly name for the XSight as a USB device. Some users have found that Linux systems cannot find the XSight/Nevo remote unless RM/RMIR is run as root, even after running setup.sh, unless this file is present.

  • If your OS is Mac OS X then there is as yet no special installation procedure.
With all three OS's, RMIR can be opened without using a shortcut by double-clicking or otherwise running the Java file RemoteMaster.jar. RMDU can be opened from RMIR with the menu item File > New > Device Upgrade and RMPB with the menu item File > New > Protocol. The instances of RMDU or RMPB so opened are independent of the RMIR instance from which they are opened, so you can then close RMIR and leave RMDU or RMPB open if you wish. RMDU can also be opened from a command line by running RemoteMaster.jar with an argument -rm and RMPB with an argument -pb. Please note that although it is optional to run Setup.vbs in Windows as RMIR, RMDU and RMPB can always be opened in these ways, in Linux you need either to run setup.sh or to use some other means to add your user id to the dialup group of users. This need only be done once ever, however, as it is a system setting that is not specific to the RemoteMaster program.

A few remotes have an external 5-hole connector rather than the 6-pin connector in the battery compartment that is common in UEI remotes. These need an adapter to convert the 5-hole connector to the standard 6-pin one. Detailed instructions for making such an adapter are given here. The most recent processors used by UEI are from Maxim, Texas Instruments (TI) and GreenPeak (now part of Qorvo). These can all be connected with a standard JP1.2/3 interface cable but only one that uses the FTDI chip. Cables with chips of other manufacturers such as Prolific have difficulty communicating with these processors. This is discussed in some detail in this thread. The remotes with TI processors either support Bluetooth as described above or have RF capability through the RF4CE protocol, depending on the processor concerned.

When using XSight remotes (and similar ones such as Nevo) with Windows 8.1 and Windows 10, Enhanced Power Management needs to be disabled for access to the remote through the USB port. Changing this setting affects only the connection for that specific remote, leaving other devices accessed through USB ports unaffected. RMIR v2.13 checks for this and displays a message giving instructions for disabling it if it finds that this setting is still enabled.

RMIR is available only as a Java file and from version 2.09 onwards has required a Java 8 or later runtime environment, either 32-bit or 64-bit. Versions from 2.04 through 2.08 required Java 7 or later, version 2.03 and earlier only required Java 6. The release package includes the following support files:
  • DecodeIR v2.45 as library files for Windows (32-bit and 64-bit), Linux and Mac OS X.
  • jp12serial v0.28 as library files for Windows (32-bit and 64-bit), Linux, Mac OS X and Raspberry Pi.
  • digitmaps.bin with digit maps up to number 748.
  • protocols.ini which is a database of protocol executor data.
  • RMIR.sys that contains the data needed by RMIR to perform firmware upgrades of the XSight remotes.
  • The RDF File Specification, Version 4.
  • The RDF File Specification, Version 5 as revision 16 of an Addendum to Version 4.
An update to any of these files will result in a new build being released, so there is no need for separate updating of any of them. Version 4 of the RDF File Specification covers RDF files for remotes with interfaces up to JP1.3. Version 5 is required to support remotes with interfaces from JP1.4 onward. Version 5 is under continuous review as UEI remotes with new features are discovered, with revisions of the Addendum being issued as required.

Please visit the JP1 Community Wiki for information about how to use RMIR. A link to the Tutorial in the Wiki is also included in the Help menu. Please note that as this project is supported solely by volunteers, the Wiki may not be up to date. This version of RMIR contains many new features required to support the newer types of remote. At the time of its release, these are not covered by the help files contained in the Wiki. RMIR itself, however, shows notes and tooltips (the text shown when you hover the mouse pointer over a button or table entry) designed to make its use as self-explanatory as possible.

The download package is available in the following folder. Just click on it to start the download.
Please see above for installation instructions.

Links:
The RemoteMaster project home page.
IrpTransmogrifier manual.
JP1 Community Wiki
Tutorial (part of the Wiki)
Getting started with XSight and Nevo (also part of the Wiki)
Nevo and XSight Remotes (thread specific to these remotes)
Bluetooth is coming to RMIR (announcement thread for the new Bluetooth interface)
RF Support in RMIR (announcement thread for RF support through RF4CE)
RMIR XSight Support (development thread)
RemoteMaster on Raspberry Pi with Raspian (development thread)
IrpTransmogrifier: new program/library for IRP protocols (development thread for IrpTransmogrifier)
Guide to Java Versions and Features (guide to the recent changes in Java availability)
How to install Java 8 on Windows XP (YouTube video and written instructions)
Connecting a JP1.1 remote via USB (info on this legacy remote type)
RM/RMIR v2.12 available (announcement thread for last official version)
_________________
Graham


Last edited by mathdon on Thu Mar 03, 2022 6:57 am; edited 2 times in total
Back to top
View user's profile Send private message
andyross



Joined: 13 Jun 2004
Posts: 261
Location: Aurora, IL

                    
PostPosted: Sun Jul 18, 2021 9:41 am    Post subject: Reply with quote

Just want to verify that this latest version of RMIR will work with 64-bit Java on Windows 10? I remember in the past it didn't, and am not sure if that was ever fixed. I currently have 32-bit Java installed.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Jul 18, 2021 11:32 am    Post subject: Reply with quote

andyross wrote:
Just want to verify that this latest version of RMIR will work with 64-bit Java on Windows 10? I remember in the past it didn't, and am not sure if that was ever fixed.

Yes, as did all builds of v2.12. That is what I run, so I am sure of it.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Jul 31, 2021 7:12 am    Post subject: Reply with quote

mathdon wrote:
andyross wrote:
Just want to verify that this latest version of RMIR will work with 64-bit Java on Windows 10? I remember in the past it didn't, and am not sure if that was ever fixed.

Yes, as did all builds of v2.12. That is what I run, so I am sure of it.

I may have spoken too soon Embarassed . It appears to be true of almost all interface cables, but since writing that I have come across one USB-to-Serial converter that causes RMIR to crash when used with 64-bit Java on Windows 10, though not with 32-bit Java or non-Windows OS.

The cause of the crash appears to be outside the control of RMIR, but it can be worked around by an update to the jp12serial library from v0.28 which is included in RMIR v2.13.0 to v0.29. See this post for more details, where a link to v0.29 is given. This new version of jp12serial will be included in the next release of RMIR but is available now for anyone who needs it.
_________________
Graham
Back to top
View user's profile Send private message
davecs



Joined: 28 Mar 2005
Posts: 319
Location: UK

                    
PostPosted: Sun Aug 22, 2021 8:05 am    Post subject: Reply with quote

I recently managed to lose the contents of my hard drive (Don't ask! Lesson learned and regular backup regime started). I downloaded 2.13 and it's great, but I was only able to get it working with my URC6440 Simpleset on Linux by following the instructions that I put in the wiki at the back end of 2019. There is a reference/link in the "readme" file relating to other remotes that need special attention, perhaps the link for the 6440/OARUSB04G can be added for them, too, in future readme files? It did take me a while to find it (I knew it was somewhere but didn't think to look in the WIKI!).

Anyway, thanks for all you do, guys!
_________________
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661
Back to top
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21211
Location: Chicago, IL

                    
PostPosted: Sun Aug 22, 2021 1:57 pm    Post subject: Reply with quote

Hi Graham,
I just tried using RMIR v2.13 to program a couple of remotes but I kept getting "no remotes found", so I checked the About page found that jp12serial hadn't loaded, so I checked the Windows-amd64 file and found that it's not there (there are old _024 and _025 versions though), so I downloaded version 29 from the link below to get it to work.

https://sourceforge.net/p/controlremote/code/HEAD/tree/trunk/jp12serial/
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Aug 23, 2021 1:09 pm    Post subject: Reply with quote

The Robman wrote:
I checked the About page found that jp12serial hadn't loaded, so I checked the Windows-amd64 file and found that it's not there ...so I downloaded version 29

I cannot explain this, as it is included in that folder in the RMIR distribution. However, I will very soon be posting a beta version of jp12serial 0.30 for you to test. This is a significant update, which among other things makes Prolific cables work with all remotes, nullifying the warnings we have given for years that they do not work with remotes with MAXQ processors. I believe I have now tested 0.30beta with all processors used by UEI, with all chips I am aware of that are used in USB-to-Serial converters (FTDI, Prolific, CH340G and CP2102N), and even with transistor interfaces and everything works as intended. The changes are significant, however, so I hope that you will give the beta version a good testing.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Aug 26, 2021 11:45 am    Post subject: Reply with quote

I have now posted the beta version of jp12serial 0.30. This beta version is available for Windows only, and the binaries are intended as a straight replacement for those in RMIR v2.13.0. In particular it supports a Prolific interface cable with ALL remotes from JP1.2 upwards, including those with a MAXQ processor that used not to work with this cable.

I would be grateful if anyone who tests it would report their findings here.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Oct 24, 2021 12:51 pm    Post subject: Reply with quote

RMIR v2.13.2 is now officially released. This is the first release since v2.13.0 as build 1 was for development purposes only. This adds two new features to RMIR and also includes a major update of the jp12serial library. RDF, map and image files for the URC-2981 have also been added, together with revised RDFs for certain remotes to support the new features.

The first new feature is support for Global Punchthrough for those JP1.4, JP2 and later remotes that have this function, which on the remote is created with a 984 command. The RDFs for the Inteset INT-422-3, Atlas 1056 B03, Titan URC-2056 and Comcast URC-1067BC4 remotes have been updated to activate this new feature in RMIR, which shows as a new tab named (for conciseness) "Global punchthru", as they have been confirmed to have this function. If anyone knows of other such remotes that support the 984 command, please post in this thread and their RDFs will also be updated. Certain JP1.3 and earlier remotes also support the 984 command. These, such as the RCA RCRP05B, should already have it supported in RMIR in the Settings panel of the General tab rather than through this new tab.

The other new feature is support for Controlled Macros. This is new type of macro that has been found to be an undocumented but supported feature of the remotes with Bluetooth support. These are the URC-7980, URC-7880 and URC-7955. These macros allow greater control than normal on the hold time of buttons in a macro and the delay between the buttons, and in particular it allows fast macros with effectively zero delay between the buttons. It has also been found that these remotes support Device-specific Macros (DSMs), both as Normal and Controlled Macros. See the thread Extended Macros in the URCs 7980, 7880 and 7955 for full details. The relevant RDFs have been updated to provide access to these features.

For a long time, users have been warned not to use interface cables for RMIR that use a Prolific chip, as they do not work with recent remotes that have a MAXQ processor. Our recommendation has been to use only cables that have an FTDI chip, with all other USB-to-Serial converter chips strongly discouraged. This new release of RMIR includes v0.30 of the jp12serial library in which this issue with Prolific cables has been fixed, so these cables now work with all remotes (other than legacy JP1 remotes which have an entirely different interface). The only other USB-to-Serial converter chips of which I am aware are the CH340G and CP2102N and issues with these have also been fixed, so any USB-to-Serial converter that gives access to either the RTS or DTR line in addition to the serial input and output lines should now be able to be used to interface to any remote. See this post for more details. The post concerns the Windows-only beta version of jp12serial v0.30 but all still applies to the final release that supports all OS supported by RMIR.

Original JP1 remotes still need a JP1 EEPROM Adapter in addition to the JP1.x interface cable and these adapters seem currently to be difficult to obtain. However, it is possible to use an Arduino as such an adapter. See this post and the links it contains for more details.
_________________
Graham
Back to top
View user's profile Send private message
WagonMaster



Joined: 16 Apr 2009
Posts: 360

                    
PostPosted: Thu Jan 20, 2022 6:29 pm    Post subject: Reply with quote

Graham,

Having been away from JP1 for a while, I want to begin this post by saying, publicly, how much I appreciate your hard work over all these years on 'IR.exe', RM/RMIR, and the various other things you've had a hand in. I'm simply in awe of your intellect and dedication! (Bowing with reverence and respect...)

Wouldn't it be nice if all posts ended like that? Smile Of course, like everyone, I'm posting to report a problem, so please forgive me, oh wise one....

I hinted at this earlier in this post of mine in another thread, but it seems like RMIR is also disrupting "serial port" communication under certain circumstances in a manner quite similar to what I wrote about for IrScrutinizer.

For the record, I'm running 64-bit Slackware 14.2 Linux and (the binary release of) RMIR 2.13.2, run from a command line as "java -jar RemoteMaster.jar", under Java "11.0.11".

In RMIR, unlike IrScrutinizer, I have the much-appreciated option to enter a specific port name, so I avail myself of that opportunity by using a name which is a symbolic link with an unchanging name that points to a '/dev/ttyUSB{#}' device name with a number which can vary each time the device is plugged in. For example, '/dev/ftdi-jp1' is an automatically created, constant-named, symbolic link to my FTDI 'TTL-232R-3V3-WE' cable (which connects my remote controls to the PC), regardless of which '/dev/ttyUSB{#}' it happens to be assigned at plugin. That constant string is what I enter in "Remote", "Interface", "JP1.X Serial..." under "Other:". This method works perfectly and I'm a happy man.

But until I get to the point in a fresh install of RMIR of having entered that constant name, and every time I merely open that dialog afterward, changing nothing, I see RMIR disrupting communication on at least one port that does not have the FTDI cable attached. Typically, this will be my (RS-232) UPS, attached via IoGear GUC232A RS-232/USB adapter, but....

As I dug a bit deeper, a decade-old bad memory returned. IIUC, it looks like the 'jp12serial' library code, when built for the Java environment, is doing something very naughty -- blindly opening all the ports in a hard-coded list of common ports (on Windows, Linux, and Solaris)!

Now, I'm equally "guilty" in this because this naughty behavior has been around since the days before I put out version 0.14 of that library, circa 2009. I remember seeing things in that library that made me shudder, but I clearly didn't address all of them, so I apologize for that. Embarassed

Having said all that, it is the case, for me, that the broader issue of disrupted comm is much less of a problem with RMIR than it is in IrScrutinizer because once I've got RMIR set up, I can simply avoid opening that "JP1.X Serial..." dialog thereafter. But I suspect that this is something that might merit some attention at some point in the future, if you agree and if/when you have the time.

As for an eventual solution, I think the code that "wildly" opens ports simply has to be removed. For some time thereafter, the existing list of common ports might suffice to build RMIR's UI, especially since one has the option of entering anything in the "Other:" field. In the long run, on Linux, there are ways to scan for ports that don't involve opening any of them, but that may prove somewhat non-standardized -- I really don't know. Digging into it a bit, some folks recommend using the list of available ports in '/dev/serial/by-id'. There are other techniques too, but it's probably premature to get too deeply into that just yet. I just wanted to let you know that there are palatable options. (Easy for me to say, right? Smile)

Whatever you think about all this, I'll gladly supply more information and/or do more testing if I can assist in any way.

And, as I said to Barf, any consideration that you can give to this, whenever that might be, is appreciated.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Jan 21, 2022 9:58 am    Post subject: Reply with quote

WagonMaster wrote:
it seems like RMIR is also disrupting "serial port" communication under certain circumstances in a manner quite similar to what I wrote about for IrScrutinizer.

You have raised this at an opportune time, as I will shortly be issuing RMIR 2.14.0 to handle two new processors. I expect to post development version RMIR 2.13.7 in the next few days as a release candidate for v2.14.0 and I have now incorporated something that I believe will meet your needs.

The disrupting behaviour comes from a call to getPortNames in jp12serial which returns the list of ports displayed in the port selection dialog for JP1.X Serial. When you are making a fresh install of RMIR you have to open this dialog in order to set the "Other" port name you want to use. I have added a new entry "No port search" on the Remote menu which is a persistent option and which you can select before you select the JP1.X Serial interface. This turns off Auto-detect and prevents getPortNames from being called, so that when you open the JP1.X Serial dialog, all you get is the "Other" option.

I don't agree with you when you write
Quote:
As for an eventual solution, I think the code that "wildly" opens ports simply has to be removed.

As far as I know, you are the first user ever to have a problem caused by this action, so an option that avoids the problem for users who do experience it seems to me to be sufficient.

Please test my fix when I post the development build and report back on how you get on,.
_________________
Graham
Back to top
View user's profile Send private message
WagonMaster



Joined: 16 Apr 2009
Posts: 360

                    
PostPosted: Fri Jan 21, 2022 11:03 am    Post subject: Reply with quote

Graham,

I think that what you have implemented will be perfectly adequate. Thank you!

While I doubt that typical JP1 users have an always-open handle on a USB port servicing a "serial"-type device, making the problem with 'jp12serial' rare enough to have gone unnoticed (or, at least, "unreported") all these years, I will say, with some authority, that opening a bunch of serial ports to see which ones are "available" is comically bad design, especially without that having been a user-initiated action, and should be strictly verboten! That code never should have gone into 'jp12serial' to begin with and, if I knew who added it originally, I'd rap their knuckles, right after rapping my own for having let it remain in version 0.14, over 12 years ago! Smile

Having said that, I iterate my agreement that your solution is a perfectly acceptable compromise, even if I consider it non-ideal in the broader view.

Many thanks for your interest and efforts and I will certainly give the development build a trial run when I see it and report back here.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Jan 21, 2022 2:18 pm    Post subject: Reply with quote

I have now posted development build RMIR v2.13.7 in the RMIR Development folder on SourceForge. This is a release candidate for RMIR v2.14.0, which will be a major new version with substantial additions and improvements.

This build adds support for two new processors, the TI CC2533 first seen in the URC3220 and the GP565 first seen in the URC2135BC0. It enhances the data included in the .rmir and .ir file formats in an entirely backward-compatible manner, in that earlier files can still be read by the updated RMIR and files created by the updated RMIR can be read by earlier versions with the additional data being ignored. The jp12serial library has been upgraded to v0.32 to allow the additional data to be read from the remote. Interface libraries internal to RMIR have been correspondingly updated.

This build includes the support for Arduino boards used as complete interfaces to JP1 EEPROM remotes that was introduced in development build 5. This support accesses such remotes through the USB port of the Arduino board (no JP1.2/3 cable required). The Options > Advanced menu gained a new persistent option, Find all Arduino, that should be selected when using an Arduino in this way. Remotes other than JP1 EEPROM ones will still be identified as usual when this option is selected, but it delays their identification by 2 seconds so the option should be deselected when RMIR is used with such a remote if this delay is unacceptable. The support includes a new folder, JP1EEPROMSupport, in the RMIR installation folder that contains detailed instructions for building such an interface with an Arduino Nano, Nano Every or a clone, together with the Arduino sketch (Arduino's name for a program) that needs to be uploaded to the Arduino board for it to act as such an interface.

RDF, map and image files have been added for the URC3220 and URC2135BC0 mentioned above and in addition there have been a number of bugs fixed and minor features added.
_________________
Graham
Back to top
View user's profile Send private message
WagonMaster



Joined: 16 Apr 2009
Posts: 360

                    
PostPosted: Fri Jan 21, 2022 9:17 pm    Post subject: Reply with quote

Graham,

Just ran the new RMIR 2.13.7 under Slackware Linux and the new "No port search" option is working perfectly, exactly as you described.

After unpacking and running the new build, I selected that new option, opened the "Port Selection" dialog, selected "Other:" and entered my constant "/dev/ftdi-jp1" symbolic link name. I did a download from a remote and played around in various ways, including re-opening the "Port Selection" dialog. Never once was communication disrupted on the open comm port reading my UPS' status (on '/dev/ttyUSB1'). The FTDI cable was on '/dev/ttyUSB0'.

I also shut RMIR down and unplugged the FTDI cable. Then I unplugged and re-plugged my RS-232/USB adapter cable so that the UPS was now on '/dev/ttyUSB0' (which is more typical). I connected the IR Widget (appearing at '/dev/ttyUSB1') and then the FTDI cable (appearing at, you guessed it, '/dev/ttyUSB2', with the '/dev/ftdi-jp1' symbolic link automatically adjusting to the change as usual). Fired up RMIR again. Downloaded from the remote again. Working perfectly! Played around some more. Still no disruption whatsoever in the open UPS comm port at the new spot!

Very nice! Thank you so much for this excellent option!
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sat Jan 22, 2022 1:44 pm    Post subject: Reply with quote

I downloaded and made a quick test.

The Girr export issue appears to have been fixed. Thank you.

I would suggest moving the new option from Remotes to Options (or Options/Advanced), since it is actually an option. Also, the name "No port search" is sort-of difficult to understand, possibly "Manual port name entry only" would be better?

The new popup if this option is selected is ugly: it contains a degenerated radio-button set with only one selection, which the user must select. Not a catastrophe, but not very logical (or very pretty) either.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control