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

RM/RMIR v2.02 Beta now available!
Goto page Previous  1, 2, 3, 4, 5, 6  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: 3143
Location: Cambridge, UK

PostPosted: Wed Sep 26, 2012 6:01 pm    Post subject: Reply with quote

There is other length info in a learned signal that allows for several blocks of data, see the example given in this post . It seems to me that this, together with the overall length of the segment, is sufficient but perhaps there is some new extension that we haven't seen that does need the new length bytes.

I suspect, but haven't yet checked, that JP2 may use the new learned format too. My testing of learned signals with segmented remotes was only on JP1.4. I sort of assumed that JP2 would be the same. But in any case, I think the remote type (JP3, or both JP3 and JP2) is sufficient to distinguish between the old and new learned formats, including the relevant clock frequency.
_________________
Graham
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Thu Sep 27, 2012 10:53 pm    Post subject: Reply with quote

It looks like there are three learned formats. Besides the standard format, we have for the MAXQ612 (URC-7962):
29 92 1E 1C 00 01 2A 04 01 80 4F 71 06 00 01 CC 03 00 01 C7 01 80 01 C4 8D 13 33 33 33 23 33 00 FF

and for the MAXQ622 (Xsight Lite/ARRX12G):
54 05 30 00 01 38 06 01 51 17 A7 01 50 74 44 15 70 0D 1F 15 70 06 A2 01 50 04 F1 01 50 01 AB 22 25 54 55 55 54 45 44 44 44 55 54 55 55 44 45 44 41 82 30 FF

The MAXQ612 adds a seemingly redundant length word, and the MAXQ622 changes the length specifier from the standard byte to a word.
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Fri Sep 28, 2012 5:20 am    Post subject: Reply with quote

I have found by experiment some more info about the MAXQ612 learning format. Here are two complete learning segments:

00 34 09 FF 39 2D 2C 00 01 36 06 01 21 04 FF 04 A0 01 6E 02 60 02 B9 02 60 01 60 01 20 02 CA 01 20 01 71 0E 14 52 35 54 34 35 40 8E 14 52 53 54 34 53 40 FF
00 34 09 FF 39 2E 2D 00 01 36 06 01 21 04 FF 04 A0 01 6E 02 60 02 B9 02 60 01 60 01 20 02 CA 01 20 01 71 0E 14 52 34 55 55 25 20 8F 14 52 52 55 55 35 45 00

Both segments have the same length, 0x34, but the new length byte marked in red differs. The first one has this byte as 2C and a final FF after the normal signal end, the second has this byte as 2D and no final FF. So the FF, when present, is a padding byte and the true end of the signal is determined by the new length byte. I thought at first that it might be a two-byte little-endian length, 2C 00 and 2D 00 in these examples, but the length makes more sense if it is a single length byte and the following 00 is a new, as yet unknown, part of the signal. The length byte is then exactly the number of signal bytes, including the new 00 and excluding the padding FF if present.

The first of the six burst pair timings, marked in blue, shows another new feature. In the old learning format these burst pairs split as two 2-byte values, so 0x0121 would be the ON time and 0x04FF the OFF time. I assumed this and deduced that the ON time was in units of (carrier period)/16, which seemed rather strange but it gave the right values. This example, from the timings that it actually generates as shown by IRScope, reveals that it now splits as a 3-nibble ON time of 0x012 in units of the carrier period and a 5-nibble OFF time of 0x104FF in units, as in the earlier post, of (system clock period)/16, ie of 4/3 us.

Dave, you took your 7962 data from Mike's post which in turn took it from the signal data area of RMIR's Learned Signal Details. The first three bytes are spurious, they are RMIR constructing a JP1.x-style 3-byte header and prefixing it to what it has parsed as the signal data. The true complete segment, with the standard header up to the segment flags in brackets, is

(00 24 09 FF) 39 29 1C 00 01 2A 04 01 80 4F 71 06 00 01 CC 03 00 01 C7 01 80 01 C4 8D 13 33 33 33 23 33 00 FF

and assuming your MAXQ922 data is the part that follows the segment flags FF, the format seems the same as the MAXQ612. It would mean that for your MAXQ622 signal, 54 is the button number of the device key, 05 is that of the key generating the signal, 30 is the new length byte (which is the correct length) and 00 is the new, unknown, first signal byte.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Fri Sep 28, 2012 5:44 am    Post subject: Reply with quote

MikeT wrote:
I transferred my URC-7960 configuration to the URC-7962 remote.

The following 3 devices are working:
Sony TV and Sony Blu-Ray Player: PID 0027:new (Sony Combo12/15/20)
AppleTV remote: PID 01E0 Apple (Official)

The other 3 devices are not working using the downloaded configuration:
Sky S HD 3 (Humax PR-HD 3000C): PID 01A2:2 (URC-7960 was using 01A2)
Denon AVR3300: PID 009C Denon Combo (Official)
Fujitsu Activy Media Center: PID 0173 Nokia32 (Custom) => no such protocol for the URC-7962

By loading your files my_URC_7960.rmir and my_URC_7962.rmir into these remotes and looking at the signals with IRScope, it seems that the Denon AVR3300 does not work with your Tuner/1177 setup code as the Device code is 0 instead of 2. You can use the Functions tab of the Device Upgrade Editor to change this value. I can't see why the Sky S HD 3 does not work because the 7960 and 7962 send the same signals in the MCE protocol. Are you quite sure that it doesn't work? This protocol has a toggle bit, so the first press may not work if the toggle is out of sync with the device. The Nokia32 protocol, PID=0173, is more of a problem. We don't have a MAXQ code for this protocol. Since your remote is new, why not contact UEI to get an official upgrade for your Fujitsu Activity Media Center, from which we can get the protocol.
_________________
Graham
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Fri Sep 28, 2012 10:34 am    Post subject: Reply with quote

Quote:
It would mean that for your MAXQ622 signal, 54 is the button number of the device key, 05 is that of the key generating the signal, 30 is the new length byte (which is the correct length) and 00 is the new, unknown, first signal byte.
Yes, 54 is the virtual device number, and 05 is the bound button number. I've only tried one group of learned signals (NEC1, device 4), and all of these learns were the same length, and of course all have a pad byte.

I have checked to see if adding a soft key name to the learned signal might trigger a new block of information in the learned signal format, and it does not. Soft key names are instead stored in a 0A segment.
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Sat Oct 13, 2012 10:49 am    Post subject: Reply with quote

mathdon wrote:
The Nokia32 protocol, PID=0173, is more of a problem. We don't have a MAXQ code for this protocol. Since your remote is new, why not contact UEI to get an official upgrade for your Fujitsu Activity Media Center, from which we can get the protocol.

After I almost finished my mail to OFA, I noticed, that the code cable/0858 is supported which also uses the Nokia32 protocol. In the protocol list of the RDF, there is a 0173:1 entry, but this variant is not known in protocols.ini, so it is not listed and can not be selected in RemoteMaster. Therefore I thought is not supported.

I added the following entry to protocols.ini:
Code:
[Nokia32]
PID=01 73
VariantName=1
DevParms=Device,Sub Device,X,High X-bit:Constant|Toggle|Release
DeviceTranslator=Translator(3,8,0) Translator(0,8,8) Translator(1,8,16) Translator(2,8,24)
FixedData=00 00 00 00
CmdParms=OBC=0
CmdTranslator=Translator()
Code.MAXQ610=35 6f 41 96 00 05 06 00 0a 00 06 00 10 00 06 00 16 00 06 00 1c 00 b5 0c 0f 00 0a 00 00 84 00 00 00 01 0c 56 0c d0 01 56 08 e0 01 17 d3 d3 80 c3 54 c4 80 71 72 73 74 1c 56 1c ba 01 16 95 95 cf 16 96 96 1f 55 0c d0 02 15 bb bb 01 57 08 00 00 15 12 12 80


With this entry I was able to download and use the update I build originally for the URC-7960.
I don't understand most of the RDF parameters, so I just copied the original Nokia32 entry and adapted VariantName and Code.MaxQ610. What is the difference between 0173 and 0173:1?

Michael
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Sat Oct 13, 2012 3:19 pm    Post subject: Reply with quote

I think nearly all UEI executors are 0173:1. A couple of Kameleon HCS08 remotes (URC-8204 and 8206, I think) are 0173:2.

I don't really understand how RMIR reads in entries in protocols.ini, but judging from rmaster.err (which has a lot of startup logging), if RMIR doesn't recognize the variant of an executor, it tries to use one which is listed. So I experimented using my 1056B03 (a MAXQ processor) and RMIR didn't display Nokia32 in the protocols list. I added the Code.MAXQ610=35 6f.... line you've supplied to the existing Nokia32 0173 entry, and RMIR now displays Nokia32. So I think we only need to add the one line rather than adding an entire entry for variant 1.
Back to top
View user's profile Send private message
Jim W



Joined: 18 Oct 2012
Posts: 5

PostPosted: Thu Oct 18, 2012 8:53 am    Post subject: RMIR v2.02 Beta does not work with URC-8820BC1-SA-R Reply with quote

RMIR v2.02 Beta does not work with URC-8820BC1-SA-R.

I have used RMIR with Cox 7820 remotes without any problems. Upgraded to Cox Whole Home DVRs and received replacement remotes with Sticker in battery compartment: C113901 URC-8820BC1-SA-R. The Cox tech who installed my Whole Home DVRs told me that Cox is now only giving out this remore with all their DVRs.

Bought and received Tommy's new JP1.2-4 Flash Interface Cable and 5-Pin Adapter.

A few days ago I downloaded the latest Beta and RDFs that I could find for my remote. Remote master info:

RemoteMaster v2.02 Beta DecodeIR version 2.43
Interfaces:
• JP1.X Serial version 0.20 Beta
• JP1 USB version 0.031
• JP1 Parallel version 0.02
System Properties:
• java.version = "1.6.0_10"
• java.vendor = "Excelsior, LLC"
• os.name = "Windows XP"
• os.arch = "x86"

Problem: The only thing that works is raw data download.

Raw Data:

F800: 30 CF 00 10 00 FF 02 00 00 03 2A FF 01 01 01 01

So there is no valid Signature.

Ran JP2Sniffer.exe and did Begin Comm; GetInfo; GetSigBlk [62CC] and the Signal Block displayed was:

00 2E 00 32 35 33 36 30 32 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 08 00 62 CB 62 F8 F7 FF F8 00 FF FF 02 00 FF FF FF FF E7

The data 32 35 33 36 30 32 is 253602 as it should be.

Steps that I used:

1) Plug remote cable into USB port and wait until your Flash Interface’s LED stops blinking.
2) Start JP2Sniffer.exe
3) Select USB port from “Select COM port” window
4) Click on “Low Level” tab
5) Click Begin Comm button
6) Click GetInfo button then 62CC will appear in box to right of GetSigBlk button
7) Click GetSigBlk button and Signal Block info shown above was displayed.

Do you need more information? What do you suggest I do?


Last edited by Jim W on Thu Oct 18, 2012 11:08 am; edited 1 time in total
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Thu Oct 18, 2012 10:59 am    Post subject: Reply with quote

I'd like to know what RMIR responds when asked for an ordinary download. Also, using JP2Sniffer, and the High level tab, what is the response to Download from remote?

Are you using this RDF? It is the same as the RDF included in the "base package".

Here's the first sentence of the readme.txt file for JP2Sniffer:
Code:
JP2Sniffer must be started after interface cable is plugged into the Computer USB port.
How do you think it should be phrased?

Concerning the signature, JP2 remotes don't store the signature at the beginning of E2 memory.
Back to top
View user's profile Send private message
Jim W



Joined: 18 Oct 2012
Posts: 5

PostPosted: Thu Oct 18, 2012 11:53 am    Post subject: Reply with quote

3FG wrote:
I'd like to know what RMIR responds when asked for an ordinary download. Also, using JP2Sniffer, and the High level tab, what is the response to Download from remote?
. . .
Are you using this RDF? It is the same as the RDF included in the "base package".
. . .
Here's the first sentence of the readme.txt file for JP2Sniffer:
Code:
JP2Sniffer must be started after interface cable is plugged into the Computer USB port.
How do you think it should be phrased?


1) I tried 3 different .RDF files and got message: “No RDF matches signature starting [blanks then y with two dots above it]”. Will go back and find link to each .RDF file that I tried and the exact results if you want me to. Which .RDF file should I be using? I will try that one.

2) JP2Sniffer Download from E2 shows 11 lines of data:
Code:
FF 02 00 00 03 2A FF 01 00 01 01 2C FF
FF 01 00 01 07 55 7F 01 00 01 01 2C FF
FF 03 00 02 02 15 FF 01 00 01 01 2C FF
FF 04 00 03 03 FF FF 01 00 01 01 2C FF
FF 00 04 0E 3A 10 10 10 10 12 13 12 10 13 0F 13 0E 01 00
FF 00 05 01 01
FF 01 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 02 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 03 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 04 00 04 17 18 19 1A 01 07 55 01 05 60 01 0F FF 01 0F FF FF
FF 00 00 0A 1E 0A 08 03 FF FF FF

3) Have corrected my post. The instructions are clear as can be. But I misread them.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3246

PostPosted: Thu Oct 18, 2012 1:45 pm    Post subject: Reply with quote

It appears that while JP2Sniffer is reading the signature correctly, RMIR is not. One possibility is that JP12Serial.dll V.20 Beta is not working correctly with the 8820BC1. Would you mind trying an older version of the DLL, which I believe has been shown to work with the 8820BC1?
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Thu Oct 18, 2012 2:12 pm    Post subject: Re: RMIR v2.02 Beta does not work with URC-8820BC1-SA-R Reply with quote

Jim W wrote:
RMIR v2.02 Beta does not work with URC-8820BC1-SA-R.

Bought and received Tommy's new JP1.2-4 Flash Interface Cable and 5-Pin Adapter.

A few days ago I downloaded the latest Beta and RDFs that I could find for my remote. Remote master info:

RemoteMaster v2.02 Beta DecodeIR version 2.43
Interfaces:
• JP1.X Serial version 0.20 Beta
• JP1 USB version 0.031
• JP1 Parallel version 0.02
System Properties:
• java.version = "1.6.0_10"
• java.vendor = "Excelsior, LLC"
• os.name = "Windows XP"
• os.arch = "x86"


You certainly have the latest JP1.X version but not the latest RMIR. You need the latest development version, v2.02 Beta 1.5v to work with this remote.
_________________
Graham
Back to top
View user's profile Send private message
Jim W



Joined: 18 Oct 2012
Posts: 5

PostPosted: Thu Oct 18, 2012 3:00 pm    Post subject: Reply with quote

Thanks 3FG and mathdon. I've got it working with your posts. Tried 3FG's suggestion and got same result. Saw mathdon's post and when I looked at the files in the .zip I realized that I had 1.5V installed but it didn't show in About.

Renamed dll from 3FG's post and went back to the version that I had been using. Clicked on RemoteMaster.jar. Everything worked and About showed RemoteMaster v2.02 Beta 1.5v.

My error was: I had been using a icon that pointed to "C:\Program Files\www.hifiremote.com\RemoteMaster\RemoteMaster.exe" instead of RemoteMaster.jar.

Update: The Cox DVR firmware has a known bug that causes it to lose the Variable Audio function at power off. Created a macro on Cox 8720 for AUX key that works to circumvent this bug by toggling the Variable Audio setting.
Code:
Settings;Down;Down;Down;Down;Right;Right;Right;Down;Select;Up;Select;Exit;CBL

Can set the same key macro in Cox 8820 Remote with RMIR RemoteMaster v2.02 Beta 1.5v but Cox 8820 does not execute AUX key macro. No problems found with RMIR with Cox 8820.

Thanks for the help.


Last edited by Jim W on Sun Oct 21, 2012 12:15 am; edited 1 time in total
Back to top
View user's profile Send private message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

PostPosted: Fri Oct 19, 2012 10:50 am    Post subject: Reply with quote

MikeT wrote:
I don't understand most of the RDF parameters, so I just copied the original Nokia32 entry and adapted VariantName and Code.MaxQ610. What is the difference between 0173 and 0173:1?
Variant 1 has an option to send a final frame with bit 7 of the 4th fixed byte toggled (or set in some versions). Variant 2 does not have this function.
_________________
Mike England
Back to top
View user's profile Send private message
Jim W



Joined: 18 Oct 2012
Posts: 5

PostPosted: Fri Oct 19, 2012 11:11 pm    Post subject: Can program URC-8820BC1 macros with RMIR v2.02 Beta 1.5v Reply with quote

I have found a way to program my URC-8820BC1 with working macros using RMIR v2.02 Beta 1.5v. When the assigned key is pressed, the Cox 8820 sends the IR command sequence to the cable box. I am working on the detailed instructions that I will post and an example file that I will upload to the File Section.
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 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 5 of 6

 
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
Get Smart! the band's official homepage Rockabilly Central