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

URC-7960
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs
View previous topic :: View next topic  
Author Message
spalter3



Joined: 15 Feb 2012
Posts: 19

                    
PostPosted: Sat Feb 18, 2012 4:47 am    Post subject: Reply with quote

if you post the current source code somewhere i can try to fix it...
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Feb 21, 2012 12:06 am    Post subject: Reply with quote

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".
Back to top
View user's profile Send private message
spalter3



Joined: 15 Feb 2012
Posts: 19

                    
PostPosted: Tue Feb 21, 2012 3:11 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
damir



Joined: 01 Oct 2003
Posts: 102
Location: Croatia

                    
PostPosted: Tue Feb 21, 2012 9:53 am    Post subject: Reply with quote

Not working with my interface.
new portmon log:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=10715
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Feb 21, 2012 1:36 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Tue Feb 21, 2012 11:34 pm    Post subject: Reply with quote

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. Cool.
Back to top
View user's profile Send private message
spalter3



Joined: 15 Feb 2012
Posts: 19

                    
PostPosted: Wed Feb 22, 2012 5:06 am    Post subject: Reply with quote

for me it's working now with both internal and usb serial ports. thanks!
Back to top
View user's profile Send private message
spalter3



Joined: 15 Feb 2012
Posts: 19

                    
PostPosted: Wed Feb 22, 2012 10:20 am    Post subject: Reply with quote

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.php?action=file&file_id=10721

and here's what i get after the download:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=10720
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Wed Feb 22, 2012 11:24 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
spalter3



Joined: 15 Feb 2012
Posts: 19

                    
PostPosted: Thu Feb 23, 2012 5:44 am    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message
regne v



Joined: 29 Oct 2004
Posts: 50
Location: Spain

                    
PostPosted: Sat Feb 25, 2012 3:58 pm    Post subject: Problem with shifted keys and Media Center code Reply with quote

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.
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Sat Feb 25, 2012 5:52 pm    Post subject: Reply with quote

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,
_________________
Graham
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Sat Feb 25, 2012 6:39 pm    Post subject: Reply with quote

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.
Quote:
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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Sun Feb 26, 2012 12:33 am    Post subject: Reply with quote

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.
Quote:
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.

Quote:
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.
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Sun Feb 26, 2012 4:24 am    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
Page 5 of 10

 
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