Best options to program JP1 remotes with USB in 2021!

[The Robman]

It would be useful if we knew whether a genuine Arduino is needed or if a knock-off would work, just so we can tell folks.

[mathdon]

It would be useful if we knew whether a genuine Arduino is needed or if a knock-off would work, just so we can tell folks.

Fear not, I am getting one to test, and would have done so without this gentle prod. The bigger issue for me, however, has been to find out why the Arduino Mega 2560, and maybe other Arduino models too, do NOT work through their built-in USB port. If I could resolve that, then your question would disappear as all Arduinos would work.

It has taken me several days to figure this out, but I have now done so. The first thing that jp12serial does is set the baud rate to 38400, after which it continues processing immediately. I find that in the Mega 2560 (but presumably not the Nano) this triggers a reset of the Arduino processor that takes several seconds, during which the code in the Arduino is unresponsive. As jp12serial has continued in ignorance of this delay, RMIR sees no remote.

The solution has simply been to put a delay of several seconds after the baud rate setting. However, I can see no way of detecting that this delay is needed and clearly it is not acceptable to add several seconds to the upload and download operations of all remotes to cater for this very special case. So unless I, or anyone else, can come up with a better solution then I will need to make this a selectable option in RMIR.

BTW On the issue of original Nano (such as Chinese clones) versus the newer Nano Every, to me one advantage of the Nano Every is that it uses a Micro USB socket for which virtually everyone will already have a cable, while the older Nano design uses a Mini USB socket that is now a much rarer beast.

[mathdon]

@Rob

The solution has simply been to put a delay of several seconds after the baud rate setting. However, I can see no way of detecting that this delay is needed and clearly it is not acceptable to add several seconds to the upload and download operations of all remotes to cater for this very special case. So unless I, or anyone else, can come up with a better solution then I will need to make this a selectable option in RMIR.

I don't like the idea of a selectable option but have come up with an alternative solution on which I would welcome your opinion, Rob. The solution is to put the delay at the end, after all other interface types have been tested, so the Arduino is looked for twice. One like the Nano will be found on the first attempt, essentially immediately. One like my Mega 2560 will fail that test but be found by the second test at the end. The effect on the performance of RMIR is as follows:

1. For any remote other than a JP1 remote connected with an Arduino, there will be no difference, as the code will never reach the end delay. This includes JP1 remotes connected with a "real" JP1 EEPROM adapter.

2. For a JP1 remote connected with an Arduino like the Nano, which does not reset itself when RMIR sets the baud rate, again there will be no difference. This is also the case if an Arduino like the Mega 2560 is used as a JP1 EEPROM adapter connected with a separate JP1.2/3 cable.

3. For a JP1 remote connected with an Arduino like the Mega 2560 through its USB port, with no need for a separate JP1.2/3 cable, RMIR will work. These are the Arduinos which reset themselves when RMIR sets the baud rate and which do not work with the current RMIR version. It will take about 15 seconds to recognise the remote, but after that, downloading and uploading will be at the usual fast speed.

4. All the above is fine. The only drawback is what happens with a remote with an interface type that RMIR cannot recognise. This includes the case where a JP1.2/3 interface cable is plugged into the PC but without being connected to a remote. In this situation RMIR will come up with its usual "No remotes found!" message but it will take about 20 seconds to do so, significantly longer than at present.

In my view this is acceptable, as case 3 is a real case that takes 15 seconds to be identified, so taking 20 seconds to check all possible interfaces and finding none of them work is surely quite reasonable. Also by far the most likely reason for "No remotes found!" is, in my opinion, forgetting to plug the cable into the remote. (If the cable is not plugged into the PC then the message occurs as quickly as at present.) This is user error and I am not concerned by that taking longer than at present to be identified.

The contrary argument, though, is that case 3 is such a special case that it is not worth bothering with. Possibly I will be the only user who will ever come across it, so best to leave things alone and forget about this case. To this, I would say that RMIR still supports transistor-based USB interfaces for JP1.1/2/3 remotes through real serial ports and also parallel ports for JP1 remotes, all of which are virtually extinct, so I prefer to cover ALL situations, including this newly discovered case 3 above.

Although I have addressed this to Rob for his views, I would of course also welcome the views of anyone else who cares to comment.

[The Robman]

Given that #3 is such a special case, with only 1 user at present and maybe no more than 5-10 users ever, I think it's a good idea to have it as a selectable option. Then, for all other folks, they will quickly get the "no remotes found" when it's applicable, rather than waiting 20 seconds for it.

[HamburgerHelper1]

Your solution is acceptable to me.
I have a a "real" JP1 EEPROM adapter. but I want to get the Arduino as a backup
I have just been waiting to see what you come up with so that I purchase the correct product

[mathdon]

Given that #3 is such a special case, with only 1 user at present and maybe no more than 5-10 users ever, I think it's a good idea to have it as a selectable option.

I'm not offering that choice. Options selectable through the menus are virtually invisible, hardly anyone ever looks for them. It is not an easy thing to make an option of jp12serial selectable through an RMIR menu, and since I believe I have a better solution already implemented, I am not prepared to do it. So it is a yes/no choice. I would like to know your vote.

[The Robman]

sorry, I thought I was voting on the options you gave. I am not prepared to vote on options that I don't understand, so do what you want.

[mathdon]

Rob, I really would like your opinion. The issue is simple. The choice is between

A. RMIR unchanged from present version, works with everything except original JP1 remote connected with certain Arduino boards, such as Mega 2560, through their USB port.

B. RMIR changed to work with the case that A does not work with, but at the expense of it taking longer (about 20 seconds in all) to return "No remotes found!" with remotes with an unknown interface type. There are not believed to be any such remotes, except faulty ones and when the user has forgotten to plug the cable into the remote.

I have not made my own mind up on this choice, so your view really is valuable to me.

[mathdon]

It would be useful if we knew whether a genuine Arduino is needed or if a knock-off would work, just so we can tell folks.

Fear not, I am getting one to test

I have now received my Chinese clone of an Arduino Nano which has, like all Chinese clones appear to do, a CH340 chip instead of an FTDI one. I can confirm that it works. To remove any doubt, this is with the current RMIR, v2.13.2, the Nano connected through its mini USB port and the interface set to Auto-detect.

All that is required of hardware is a Nano clone with pins, a mini USB lead (NOT a micro USB one) to connect the Nano to the PC and five female-to-female Dupont patch cables. One of these is to connect pins 1 and 2 of the remote's 6-pin connector together, the other four connect the other connector pins to the Nano as follows: pin 3 to Nano GND, pin 4 to Nano A4, pin 5 to Nano GND (there are two Nano GND pins so this does not conflict with pin 3) and pin 6 to Nano A5.

Note that not all Nano clones come with the pins already soldered to the board. Some supply the pins separately for you to use or not as you wish, and of course, any other means of making the connections is equally OK. My suggestion is, however, a way that requires no soldering.

For software you need the Arduino JP1 EEPROM Adapter program and the Arduino IDE to load it into the Nano. You also need the CH340 driver, but this should be installed automatically by Windows when you first connect the Nano. In the Arduino IDE you need to make three settings under the Tools menu. Under Board, select Arduino AVR boards > Arduino Nano. Under Processor there are three choices, "ATmega328P", "ATmega328P (Old Bootloader)" and "ATmega168". It should be one of the first two. Try one and if the software does not upload, try the other. I needed the Old Bootloader one despite this apparently being for Nanos from 2017 and earlier. Finally select the Port. Unless you have other USB ports connected, there should only be one choice listed. Then, with the software installed in the Nano and the connections as described above, all is ready and RMIR should work to download and upload to a JP1 remote as normal.

A few final comments. The original Nano design that the clones all use is a little ungainly. It has components and pins on both sides of the board and uses a mini USB connector which is now a rarity. The updated version, the Nano Every, has components and pins on only one side of the board and uses the pretty standard micro USB connector. If you use a Nano Every then you will find the board under Arduino megaAVR boards > Arduino Nano Every. Instead of a choice of Processor there is now Registers emulation > ATMEGA328 and the driver that will load is now for an Arduino NANO Every as it does not have a separate USB-to-Serial converter chip. Everything else, including the connections, is as described above for the original Nano.

[3FG]

Graham,
I sometimes get a "no remotes found" message. These can be caused by an offset or upside down connector, or it fell off the remote. Sometimes I don't know why the remote isn't found and I just disconnect everything and reconnect. My view is that a 20 second wait is rather longer than a user should expect, and this behavior is likely to cause problems, especially among new or infrequent users.

I understand that you dislike a selectable option, but IMO it really is the better approach here. Anyone using an Arduino will know that they are using one and will have needed to follow instructions to get started at all. It seems to me that these users are exactly the ones who should be able to use a selectable option, especially since they can be prompted to select the Arduino option while setting up the Arduino. I see this situation as quite different to one where the user may have no idea that a selectable feature is even possible.

[mathdon]

I sometimes get a "no remotes found" message. These can be caused by an offset or upside down connector, or it fell off the remote. Sometimes I don't know why the remote isn't found and I just disconnect everything and reconnect. My view is that a 20 second wait is rather longer than a user should expect

OK, I take your point. When I originally mentioned the need for a selectable option, I was thinking that it would need to be like a new interface type to cope with the situation that my case A failed on. Now I know that I can produce a version of jp12serial that copes with all situations, my case B, I have a different view. What I could do is put a new entry on the Advanced menu that switches the behaviour of jp12serial between that of my cases A and B, rather than making a new version of jp12serial that was just case B. The default, of course, would be case A (with some suitable name). Users would only need to switch to case B if they had an Arduino that did not work with case A. The important point for me is that they could then leave RMIR permanently in case B, putting up with the delay to "No remotes found!" and for you, I think, is that they could switch between the two cases so they were not permanently left with that extra delay if they also had remotes that were not original JP1.

Does this seem a suitable way forward?

[3FG]

Yes, I think that is a very suitable approach.

[Lurker]

by far the most likely reason for "No remotes found!" is, in my opinion, forgetting to plug the cable into the remote. (If the cable is not plugged into the PC then the message occurs as quickly as at present.) This is user error and I am not concerned by that taking longer than at present to be identified.

Although I have addressed this to Rob for his views, I would of course also welcome the views of anyone else who cares to comment.

I get "no remotes found!" sometimes and it is not because of "forgetting" or "user error". Usually unplugging it and plugging it back in fixes it, like it was some kind of loose connection. I am sad that you are unconcerned about punishing me with a long delay every time this occurs.

[mathdon]

I get "no remotes found!" sometimes and it is not because of "forgetting" or "user error". Usually unplugging it and plugging it back in fixes it, like it was some kind of loose connection. I am sad that you are unconcerned about punishing me with a long delay every time this occurs.

This will not happen. I do listen to users' opinions. See the exchange with 3FG above.

[Lurker]

I get "no remotes found!" sometimes and it is not because of "forgetting" or "user error". Usually unplugging it and plugging it back in fixes it, like it was some kind of loose connection. I am sad that you are unconcerned about punishing me with a long delay every time this occurs.

This will not happen. I do listen to users' opinions. See the exchange with 3FG above.

Ah, I see 3FG said basically the same thing I said. Sorry I did not see that before. I think I had an emotional reaction to your post and couldn't go any further without responding. The advanced option for Arduino users is a great idea.