357902 URC-625000-04R00 OSN JP1.4

[mathdon]

Thank you for the disappointing news that the test of the RTS line fails. I see no point in progressing further with that remote, but if you want to continue experimenting with Realterm, the correct baud rate is 38400. As the RTS test doesn't depend on baud rate, I didn't bother to suggest setting that in my earlier post.

Creation of an RDF requires a great deal more information than that in the file you posted, a lot more knowledge of the workings of these remotes than you have, and a lot of experience too. That is why I cannot create RDFs for JP1.3 remotes and why it is not possible to give a simple explanation of how to create one yourself. You really do need an expert in JP1.3 remotes to do it.

[Tiku]

Thank you for the disappointing news that the test of the RTS line fails.

Just to be 100 percent sure before throwing them in the garbage can, I Tried Realterm Test with few more Jp1.3 working remotes, and i am getting two blinks, also OSN Jp1.3 blinks twice,
So the problem lies in the RTS Line of both jp 1.4 remotes.

[mathdon]

Both JP1.4 remotes? You have only mentioned one in your previous posts, the one with signature blink-back 35792, giving a true signature of 357902.

[Tiku]

At present i have total 3 OSN Remotes, one is jp 1.3 and two is jp1.4
Unfortunately both 1.4 version shows Remote Not Found, and neither of them blinks in Realterm only 1.3 version blinks which also shows signature not found 3211 in RMIR.
I Have upgraded couple of JP1.4 Versions in the past for Friends.
Don't have any of the previous remotes with me now.

The signature is the same in both 1.4 remotes, which you mention in above post.

Creation of an RDF requires a great deal more information than that in the file you posted, a lot more knowledge of the workings of these remotes than you have, and a lot of experience too. That is why I cannot create RDFs for JP1.3 remotes and why it is not possible to give a simple explanation of how to create one yourself. You really do need an expert in JP1.3 remotes to do it.

Ok, if its a job of an expert, I have an another alternative, if its posiible?
Is it possible to Make RMDU File From RMIR Backup, I have a Essence one for all 4 In 1 Universal Remote (URC 7140), It has a Reader Option, Once i had made a copy of BeoutQ STB Original Remote into Essence 7140 and uploaded a backup rmir file, from which Rob had made a RDF,Maps, RMDU.
If this is not as much difficult as making a whole RDF, then please guide how can i do it? so that i can just copy facing master remote to Essence 7140, Copy the file from RMIR and make RMDU For different Jp1.xx Remotes.
Thanks

[mathdon]

Unfortunately both 1.4 version shows Remote Not Found, and neither of them blinks in Realterm only 1.3 version blinks which also shows signature not found 3211 in RMIR.

I have today tried the RTS test with four very different JP1.4 remotes and in all cases I get two flashes when the RTS line is changed from Set to Clear. So I see only two possibilities: (a) both your JP1.4 remotes have a broken RTS connection from the 6-pin connector or (b) you have a type of JP1.4 remote that we have not previously seen. If (a) then there is no point in proceeding with them in RMIR, but they continue to work in normal mode so you can set any built-in setup code and change any other settings without access to RMIR, if (b) then there is nothing I can do without having one of these remotes to explore, and possibly not even then.

Is it possible to Make RMDU File From RMIR Backup.

If I understand you correctly, this is easy. Load the backup .rmir file into RMIR, go to the Devices tab, select the device you want as a .rmdu file and press the Edit button. On the Device Upgrade Editor panel that then opens, press the Save as button and select where you want it saved as a .rmdu file.

[Tiku]

If I understand you correctly, this is easy. Load the backup .rmir file into RMIR, go to the Devices tab, select the device you want as a .rmdu file and press the Edit button. On the Device Upgrade Editor panel that then opens, press the Save as button and select where you want it saved as a .rmdu file.

Great, You Got My Point.
Thanks

[HamburgerHelper1]

I have a similar situation Jp1.4 Remote signature 33931
I can not do raw download But what i do get in Real Term is that the Backlight turns on when I press "Clear"
Since the URC625000-04R00 And URC625001-00R00 are not backlit this behavior would not have been observed.
Is the Back light behavior a sign that RST is working ?
I purchased the remote from Ebay and can get more
https://www.ebay.com/itm/275770925858
Graham since i can purchase another one and If you think this is a type of JP1.4 remote that we have not previously seen
I will ship it out to you if you think it is worth pursuing. What are your thoughts ?

[mathdon]

I can not do raw download But what i do get in Real Term is that the Backlight turns on when I press "Clear". ... Is the Back light behavior a sign that RTS is working ?

I don't know the answer to that, but it does seem to be a remote with some unknown behaviour. I would be interested to have one, thank you very much for the offer, but I may be some time before I can get round to working on it as we are about to have some disruptive work done in the house. If you don't mind that, then I would be pleased to take you up on the offer.

[HamburgerHelper1]

If you don't mind that, then I would be pleased to take you up on the offer.

I don't mind the wait.
In fact I already ordered another one so I will send you that one since it will be in pristine shape without the 980 resets i did on mine

[HamburgerHelper1]

Dismantled the URC-2060 and if i did this correct pin 2 goes to the processor
and the common connection for the transport keys.

[mathdon]

The only info I have found about the internals of a JP1.4 remote is this from Tommy Tyler about the OARI06G. He gives the processor as an S3F80KB and lists the JP1.4 pin connections to it as pin 1 to Vdd, pin 2 to RESET, pin 3 to Vss, pin 4 to SDAT, pin 5 to TEST, pin 6 to SCLK. The KB in the processor type is not KiloByte as there is also an S3F80JB, which appears to have a somewhat different pinout. So Randy, is the processor type identifiable in your disassembled URC2060? Can you post any pics of the internals? Can you tell what processor pin the connector pin 2 goes to? As I said in a PM to you, connector pin 2 which we identify as RTS does not appear to be a processor RESET pin as a reset by removing and replacing a battery does give 2 flashes but using RealTerm to change RTS from Set to Clear does not do so. For that matter, I suppose we can't be sure what ANY connector pin goes to on the processor.

I have been doing some tests with RealTerm on a URC3680, which is also JP1.4, viewing the signals with a logic analyzer and don't understand what I find even with that remote. I can see with the analyzer exactly what RMIR sends when starting a raw download and what the responses are, and can send exactly the same with RealTerm, but with RealTerm there is no response at all. I cannot find any interaction between RMIR (or jp12serial) and the remote that I am missing that might explain the difference. Is there anyone with a better understanding of RealTerm who can help? I feel if I could understand this difference then it might help also with the URC2060.

[HamburgerHelper1]

Unfortunately I have no idea what processor connector pin 2 goes to

[WagonMaster]

I have been doing some tests with RealTerm on a URC3680, which is also JP1.4, viewing the signals with a logic analyzer and don't understand what I find even with that remote. I can see with the analyzer exactly what RMIR sends when starting a raw download and what the responses are, and can send exactly the same with RealTerm, but with RealTerm there is no response at all. I cannot find any interaction between RMIR (or jp12serial) and the remote that I am missing that might explain the difference. Is there anyone with a better understanding of RealTerm who can help? I feel if I could understand this difference then it might help also with the URC2060.

Graham,

I don't know anything about JP1.4 remotes and my experience with RealTerm is rather limited, so please forgive me if this is not the issue, but having dealt with the JP1.2 and JP1.3 remotes extensively back in 2009 while fixing bugs in the 'jp12serial' library, I'm wondering if the issue is somehow related to the UART 'break' condition.

I know that you already know this but, to be specific and for anyone following along, the JP1.2 and JP1.3 remotes require the UART 'break' condition to be "set" and held while other UART signals are manipulated before then being "released". This was, in fact, one of the bugs in the library code back then.

The part I'm wondering about is if the 'break' condition is being accurately mimicked when you replicate the RMIR/jp12serial actions under RealTerm. In RealTerm, the "Pins" tab allows you to manually "Set Break" and "Clear Break" and I suspect that you would have to have done that at some point if a JP1.4 remote behaves anything like the JP1.2 and JP1.3 remotes.

P.S. Can someone please shrink that overly wide image that's making all the text on this page so hard to read?

[3FG]

JP1.4 and JP2 remotes don't use the "break" mechanism to initate programming mode. Instead after reset, the processor listens for 4 specific characters, and if they are received the remote enters programming mode. If the specific characters are not received, the remote begins normal operation.

The 4 characters need to be sent within about 100msec, but this time duration varies depending on processor type. There also needs to be a short delay after exiting reset before the characters can be sent.

IIRC, I could get these timings by messing around using scripts in RealTerm, but I quickly decided to write standalone utility programs like JP2Dumper, anong others, so that I could easily find the acceptable timing range.

I think it is possible that this timing for this remote is somewhat different than we currently assume in JP12Serial.dll.

[WagonMaster]

JP1.4 and JP2 remotes don't use the "break" mechanism to initate programming mode.

Doh! Thanks for the education, 3FG. I should have delved into the 'jp12serial.cpp' source code a bit before commenting. Sorry for the noise, folks.

Aside: The situation was complicated enough back in 2009. Unfortunately, the proliferation of various types of remotes has made it even worse since then. I don't think I could possibly keep it all straight in my head these days! Good thing my JP1.2 remotes are still working.

P.S. Thanks for shrinking that image width, HamburgerHelper1!