JP1 Remotes

if you post the current source code somewhere i can try to fix it...

Here's a test version of JP12Serial.dll. It adds a 10 character read to clear a couple of zero bytes that the transistor interface seems to add (compared to Tommy's USB interface). The code for non-JP1.4/JP2 remotes has a 20 character read, but that caused more delay than the URC-7960 would tolerate, so we removed it from the JP1.4/JP2 section. This is an intermediate "solution".

it's working now with my prolific usb/serial! still not working with the onboard com-port but i suppose that doesnt matter (and i cant send you the log because i cant pass on a physical com port to the 32bit VM).

thank you for the quick work-around!

Not working with my interface.
new portmon log:
http://www.hifi-remote.com/forums/dload ... e_id=10715

OK, the fix isn't really working, and in fact damir's results show that his interface is reacting differently now than in the earlier test--it doesn't even get to the revised code that I posted yesterday.

I'll send out one more attempt tonight. However, I suspect that root issue here is the electrical design isn't entirely compatible with the JP1.4/2 communication approach. Still, we may be able to compensate.

Second try If this doesn't work, I recommend trying a lower value for R3. Perhaps 50K instead of 100K. The thinking here is that real RS-232, as practiced in a PC, needs negative voltages to indicate a 1, which is also the quiescent state. The lowest voltage we can produce is ground plus the drop across Q2. So if Q2 is not able to turn on hard enough, the PC will spuriously see a start bit (+V), data bits of 0 (+V), and then if Q2 can turn on for a short period of time, it will look like a stop bit (almost ground).
Of course, the problem could be something else entirely. .

for me it's working now with both internal and usb serial ports. thanks!

it's working, but i found a new bug, this time in remotemaster (i suppose). i learned a few signals, downloaded them from the remote, edited a device, reuploaded the whole thing and noticed that half the learned signals were gone. when i re-download they're also missing.

here's what i uploaded (with 6 learned signals):
http://www.hifi-remote.com/forums/dload ... e_id=10721

and here's what i get after the download:
http://www.hifi-remote.com/forums/dload ... e_id=10720

spalter3 wrote:i learned a few signals, downloaded them from the remote, edited a device, reuploaded the whole thing and noticed that half the learned signals were gone. when i re-download they're also missing.

I can tell you what is happening, but not why, and not where the fault lies. If you open the original .rmir file as a text file (you may need to change its extension to .txt to do this) and scroll down to the lower part, you will see that three of the [LearnedSignal] sections have an entry "SegmentFlags=255" and the others do not. A missing entry is equivalent to "SegmentFlags=0". They all should be 255, and although RMIR shows all six when you load the .rmir file, the remote is ignoring those with value 0 when you upload to it.

I can see no reason why RMIR should have different values for SegmentFlags for the different signals, other than that these values were present in the remote. We don't fully understand the significance of these flags, but when bit 7 is 0 it seems to mean something like "marked for deletion", which would explain the reason why they disappear on upload.

If you want me to investigate further, could you attempt to re-create this situation. I suggest you re-learn the signals and then use RMIR to do a raw download. Save this raw download - you don't get a choice of filename, it will be 3224.ir (the first 4 digits of the signature) although it won't load into IR.exe. Then do a normal download, save it as a .rmir file and look to see if there are missing SegmentFlags entries again. If there are, please post both the raw and normal download files for me to look at. The raw one should be a faithful copy of what was in the remote, so I can see if the remote has done some unexpected things with this flags byte. And check, please, if the learned signals all actually work, as if there are learned signals in the remote with a flag byte 00 then I would not expect them to work.

you're right, when i add the segment flags all works fine. i tried recreating the problem after a master reset on the remote, but no luck. i'll post it if i should figure out how i managed to break it the first time

I've been testing RM IR Beta 1.5q with an URC7960 and I've found two quirks.

This remote has no MS Media Center code so I've uploaded one but when I press any of the keys the remote gets locked: the blue light gets on and to get it back I have to take the batteries out.

When I try to edit back the Media Center code I get a "The code for the protocol for this device ugrade is not consistent..." message and if It press the "Edit Protocol" button nothing happens.

Also I've found that I can't access shifted keys. I have several shifted keys to use in macros (see the TV device) and they can't be played either by macros neither by pressing them. Is it still "shift" the "magic" key?.

I've uploaded a dump of the remote and the Media Center device I'm trying to use here.

Thanks a lot.

I don't know where you got that protocol from, but it is for the wrong processor. You have used a protocol for the HCS08 processor in a remote that uses the S3F8 processor, which is why it locks up. As the error message says, the code is not consistent with the remote.

As far as the shift key is concerned, I too have found that doesn't work. I have been unable to find a shift facility on the URC-7960 and note that it is not mentioned anywhere in the UEI documentation. I have come sadly to the conclusion that it is not implemented in this remote,

mathdon wrote:I don't know where you got that protocol from, but it is for the wrong processor. You have used a protocol for the HCS08 processor in a remote that uses the S3F8 processor, which is why it locks up. As the error message says, the code is not consistent with the remote.

I just opened up the "Windows Media Center v2 para URC-7960" RMDU file which he included in his upload and it appears this manual protocol does in fact have a translation for both HCS08 and S3C80. In fact, the S3C80 information is duplicated in the notes section of the upgrade.

Code.HCS08=20 16 24 4B 81 CE 05 08 08 00 DD 00 00 00 00 00 DE D0 12 05 36 01 BB 04 01 B3 12 01 61 06 B6 61 A8 F0 B7 61 03 61 06 B6 66 A8 C0 B7 66 B6 68 AE 08 CD FF 8C BF 68 B7 69 6E 02 A9 6E 08 AA CC FF 5F
Code.S3C80=20 16 24 4B 81 CE 05 08 08 00 DD 00 00 00 00 00 DE D0 12 05 36 01 BB 04 01 B3 12 01 61 06 B6 61 A8 F0 B7 61 03 61 06 B6 66 A8 C0 B7 66 B6 68 AE 08 CD FF 8C BF 68 B7 69 6E 02 A9 6E 08 AA CC FF 5F
Notes=Upgrade Protocol 0 \= 01 2A (S3C8+)\n47 93 81 8B 09 00 05 37 01 A4 00 DE 00 CE 08 00 58 04 37 50 06 37 00 03 B6 04 F0 37 52 06 37 00 03 B6 09 C0 2C 08 38 0B CF 10 0C 10 0B DF 10 0C 10 0B 90 C3 FB 03 B6 0C 03 2A ED 1C 12 F6 01 4C 77 71 38 03 F6 FF 6B 38 04 F6 FF 67 B0 C6 87 36 05 F6 FF 6B 6E 37 66 F6 77 70 C6 F8 87 FF F6 01 58 F6 01 0A 7B D5 AF 4C 04 8B 02 4C 08 90 C3 7B 09 77 70 1C 18 F6 01 6D 8B 07 1C 16 F6 01 64 77 71 4A EA AF\nEnd\n\nUpgrade Protocol 0 \= 01 2A (S3C8+)\n20 16 24 4B 81 CE 05 08 08 00 DD 00 00 00 00 00 DE D0 12 05 36 01 BB 04 01 B3 12 01 61 06 B6 61 A8 F0 B7 61 03 61 06 B6 66 A8 C0 B7 66 B6 68 AE 08 CD FF 8C BF 68 B7 69 6E 02 A9 6E 08 AA CC FF 5F\nEnd

So, it could be a possible bug somewhere if Remote Master or the RDF if it is assigning the wrong processor version of the manual protocol to the URC-7960.

regne v wrote:When I try to edit back the Media Center code I get a "The code for the protocol for this device ugrade is not consistent..." message and if It press the "Edit Protocol" button nothing happens.

I just uploaded your upgrade into one of my remotes and it appears it's using the MCE protocol with Device = 4 and OEM2 = 15. This protocol is now well defined and no longer needs a manual protocol to address it. Go ahead and change protocol in RM or DUE from "Manual Settings" to "MCE" with the aforementioned parameters and it will use the built-in protocol which is built-into the protocol.ini of RM/RMIR.

eferz wrote:I just opened up the "Windows Media Center v2 para URC-7960" RMDU file which he included in his upload and it appears this manual protocol does in fact have a translation for both HCS08 and S3C80. In fact, the S3C80 information is duplicated in the notes section of the upgrade.

Code.HCS08=20 16 24 4B 81 CE 05 08 08 00 DD 00 00 00 00 00 DE D0 12 05 36 01 BB 04 01 B3 12 01 61 06 B6 61 A8 F0 B7 61 03 61 06 B6 66 A8 C0 B7 66 B6 68 AE 08 CD FF 8C BF 68 B7 69 6E 02 A9 6E 08 AA CC FF 5F
Code.S3C80=20 16 24 4B 81 CE 05 08 08 00 DD 00 00 00 00 00 DE D0 12 05 36 01 BB 04 01 B3 12 01 61 06 B6 61 A8 F0 B7 61 03 61 06 B6 66 A8 C0 B7 66 B6 68 AE 08 CD FF 8C BF 68 B7 69 6E 02 A9 6E 08 AA CC FF 5F
Notes=Upgrade Protocol 0 \= 01 2A (S3C8+)\n47 93 81 8B 09 00 05 37 01 A4 00 DE 00 CE 08 00 58 04 37 50 06 37 00 03 B6 04 F0 37 52 06 37 00 03 B6 09 C0 2C 08 38 0B CF 10 0C 10 0B DF 10 0C 10 0B 90 C3 FB 03 B6 0C 03 2A ED 1C 12 F6 01 4C 77 71 38 03 F6 FF 6B 38 04 F6 FF 67 B0 C6 87 36 05 F6 FF 6B 6E 37 66 F6 77 70 C6 F8 87 FF F6 01 58 F6 01 0A 7B D5 AF 4C 04 8B 02 4C 08 90 C3 7B 09 77 70 1C 18 F6 01 6D 8B 07 1C 16 F6 01 64 77 71 4A EA AF\nEnd\n\nUpgrade Protocol 0 \= 01 2A (S3C8+)\n20 16 24 4B 81 CE 05 08 08 00 DD 00 00 00 00 00 DE D0 12 05 36 01 BB 04 01 B3 12 01 61 06 B6 61 A8 F0 B7 61 03 61 06 B6 66 A8 C0 B7 66 B6 68 AE 08 CD FF 8C BF 68 B7 69 6E 02 A9 6E 08 AA CC FF 5F\nEnd

Okay after further examination of the upgrade, it seems that the code for the S3C80 and HCS08 is the exactly the same. Even someone with my limited intelligence knows that it is impossible for the assembly instructions for two different processor architectures to be the equal. I also noticed that it is very similar to the code documented in the protocol.ini section for the MCE variant 2. That stands to reason why Mathodon believes that it was specifically meant for an HCS08 remote.

Code.HCS08=20 16 24 4B 81 CE 05 08 08 00 DD 00 00 00 00 00 DE D0 12 05 36 01 BB 04 01 B3 12 01 61 06 B6 61 A8 F0 B7 61 03 61 06 B6 66 A8 C0 B7 66 B6 68 AE 08 CD FF 8C BF 68 B7 69 6E 02 A9 6E 08 AA CC FF 5F

I do think though it is funny that whomever wrote the notes for that upgrade probably included the proper S3C80 assembly but failed to actually implement it into the upgrade. Then they misnamed the second upgrade protocol's compatibility in the notes since that duplicates the entry of the HCS08 assembly. Oi vey, so mashugana! In any case as suggested earlier, the MCE protocol is now well defined and there's no longer a reason to use the manual protocol for pid "01 2A" which is currently mis-defined in the upgrade to represent it on anything but a HCS08 remote.

eferz wrote:That stands to reason why Mathodon believes that it was specifically meant for an HCS08 remote.

The actual reason I said it was meant for an HCS08 remote is that it disassembles sensibly in RM when copied into the HCS08 line of a new manual protocol, but crashes the disassembler when in the S3C80 line.