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

Protocol identifications and questions

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

PostPosted: Tue Dec 22, 2015 12:39 pm    Post subject: Protocol identifications and questions Reply with quote

Here are a few discoveries from my investigation into MAXQ executors. I've posted separately a discovery concerning the NRC16 protocol. I've given this thread a very general title as I am sure there will be more discoveries and questions, which can then also go into this thread.

PID 0171 is a variant of CanalSat, PID 018C, differing only in frequency. PID 0171 is 38.2k, CanalSat is 56.1k.

PID 01E6 is functionally identical to XMP (PID 016C.2), differing only in slight coding differences. PID 01E5 is an XMP variant differing only in frequency. PID 01E5 is 36.1k, PIDs 01E6 and 018C are 38.0k. PIDs 01E5 and 01E6 have the same coding, apart from this frequency change in the header bytes.

The Denon/Sharp protocol (PID 001C) is shown in DecodeIR.html as having the IRP

{38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)+ (Denon)
{38k,264}<1,-3|1,-7>(D:5,F:8,1:2,1,-165,D:5,~F:8,2:2,1,-165)+ (Sharp).

The 001C MAXQ executor has a flag, bit 0 of the fixed byte, which sends these forms when that bit is 0, which is its fixed value in protocols.ini. The executor, however, allows this bit to be 1, in which case it sends a variant protocol with only a 3-bit device code

{38k,264}<1,-3|1,-7>(D:3,F:8,0:1,1,-165,D:3,~F:8,1:1,1,-165)+ (Denon)
{38k,264}<1,-3|1,-7>(D:3,F:8,1:1,1,-165,D:3,~F:8,0:1,1,-165)+ (Sharp)

Is this a known variant? Should protocols.ini support it?

These IRPs in fact do not quite correspond to what the executor sends, as it repeats the first half-frame as a final frame on key release. This is not just a MAXQ behaviour, I have noticed it previously also with an HCS08 remote.

The Dish Network (and Dish Network Combo) executor, PID 0002.5, also has variants not available through protocols.ini. The last two bits of the first fixed byte, as decimal value, can be 0, 1 or 2 but protocols.ini sets it to 0. This gives the DecodeIR.html IRP form

{57.6k,400}<1,-7|1,-4>(1,-15,(F:-6,S:5,D:5,1,-15)+)

but values 1 and 2 give respectively

{38.0k,400}<1,-7|1,-4>(1,-15,(F:-6,S:5,D:2,1,-15)+) (change of frequency and only 2-bit parameter D)
{38.0k,400}<1,-7|1,-4>(1,-15,(F:-6,S:5,D:5,1,-15)+) (change of frequency keeping 5-bit parameter D)

Again, are these known and should protocols.ini support them?
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18403
Location: Chicago, IL

PostPosted: Tue Dec 22, 2015 1:35 pm    Post subject: Reply with quote

Sometimes UEI expands an executor so that it produces more than just the 1 protocol, and sometimes the executor always supported the additional protocols but we either didn't know, or didn't care if they're really rare.

As to your question about whether protocols.ini should support something, I think the main thing is, it needs to be in sync with DecodeIR, because if DecodeIR doesn't report it, nobody will try to use it, therefore there's no need for it to be in protocols.ini, but if it DOES report it, then yes, protocols.ini should support it too.

Of course, the real question is, how many devices are out there that need these possibly obscure protocols?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


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

PostPosted: Tue Dec 22, 2015 6:15 pm    Post subject: Reply with quote

DecodeIR reports frequencies but does not use them in identifying a protocol, other than in the few cases where two protocols differ only in frequency. So one conclusion I draw from your comments is that protocols.ini should support frequency variants. Another is that it should explicitly support NRC16, since DecodeIR does report it.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18403
Location: Chicago, IL

PostPosted: Tue Dec 22, 2015 7:39 pm    Post subject: Reply with quote

Just because 2 signals come from the same executor doesn't mean we have to treat them as the same protocol, or variants of the same protocol. We can if we chose, but we can also call them different protocols, like we do with the NEC family.

All that I was trying to say is, the two should be in sync, so that if DecodeIR says the protocol is "ABC" or "ABC 56khz" or whatever, the next thing the user is going to do is go to RM and try to select "ABC" or "ABC 56khz" or whatever.

Talking specifically about frequency variants, maybe the different frequency gives it a different name, like "Sharp" vs. "Denon" or, "ABC 38kHz" vs. "ABC 56kHz", or maybe it reports it in some other fasion, just as long as it gives the user enough information to make the right choice when they go to RM to build an upgrade.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Wed Dec 23, 2015 11:58 am    Post subject: Reply with quote

I think we should include 0171 in protocols.ini. I recall seeing this once in a decoded IR signal. We'd probably call it CanalSat-38, following the predominant usage in which Fujitsu56 would mean a 56bit version of the protocol, and Fujitsu-56 would mean a 56KHz version .

UEI has a number of executors which are capable of sending two or more frequencies: Protocols.ini has entries for Amino 019C, Blaupunkt 00A5, DirecTV 0162, RC6-M-20n 0020, RCA 00AF:2, and Zaptor 01CD. We don't include a frequency indicator in the names for these executors, but the choices are available in RMIR.

I've been loosely following the idea that if a UEI executor is in protocols.ini and we discover a new capability, I'll include the feature if it doesn't require making a custom translator or adding a new entry in protocols.ini. In the case of the Denon/Sharp 3 bit device capability, it isn't obvious how we would implement it unless we made an entirely new entry. IMO, the 3 bit version is not something we should add.

For Dish Network, we can add the additional frequency easily. I'd vote against implementing the 2 bit device version.

Finally, regarding XMP, I think the situation is even more complicated than Graham outlined. I'll communicate with him directly.
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Thu Dec 24, 2015 10:57 am    Post subject: Reply with quote

Here are a few more identifications.

PID 00B7 is a variant of NEC1 that has a frequency of 34kHz rather than 38kHz. The timing is the same as standard NEC1 in terms of the number of clock cycles, so durations are corresponding longer in time.

PID 0206 is NEC1-rnc, in the terminology of DecodeIR. It differs from NEC1 in that the 4th data byte sent, normally the complement of the 3rd, is here the complement of the 3rd with its nibbles reversed. It appears that although this is recognised by DecodeIR, this is the first known executor for it (there is no home-made one in protocols.ini).

PID 01AC is a Denon/Sharp/Denon-K Combo that can send any combination of these three protocols. It differs from Denon/Denon-K Combo with PID 01C8 in that it can send both Denon and Sharp signals, but it allows only one pair of device/subdevice values for Denon-K to be specified rather than the six pairs of that executor.
_________________
Graham
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Thu Dec 24, 2015 11:27 am    Post subject: Reply with quote

Here's a S3F80 PID=0206 executor to compare with the MAXQ version:
43 8b 21 8b 12 cf 4d 08 08 01 21 03 30 01 21 00 fd d2 dc 11 94 08 b6 20 11 e4 05 06 60 06 f0 06 8d 01 46
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sat Dec 26, 2015 1:58 pm    Post subject: Reply with quote

A couple more:

PID 01C3 is an RC-5 Combo that supports two frequencies, 38k and 56k, and four device numbers rather than the three of the standard RC-5 executor. As with that executor, each device number can be set to support OBCs either in range 0-63 or in 64-127.

PID 01E1 is a Nokia32 Combo that supports signals with differing values of the Nokia X-parameter. In the standard Nokia32 executor the X-parameter is the same for all signals.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sun Dec 27, 2015 12:42 pm    Post subject: Reply with quote

Another three:

PID 011E is a 38kHz variant of RC-5 that is otherwise functionally identical to the RC-5 executor with PID 00E8. This 38kHz variant of RC-5 is the same as that included in the combo protocol with PID 01C3 mentioned in the post above.

PID 00F3 is a variant of Barco with PID 002A that has the same functionality but slightly different timings. Neither is recognised as Barco by DecodeIR and a Widget, as it is an unmodulated protocol with a very short time unit that is faster than a Widget can cope with. I haven't tried these executors with a learning remote. The timings in the Barco protocol are not critical, see this post, but perhaps some equipment will respond better to one or other of these executors.

PID 0177 is the G.I.RG protocol that was added to DecodeIR in v2.44 by 3FG.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sun Jan 03, 2016 10:56 am    Post subject: Reply with quote

I am very curious about the MAXQ protocol with PID=01BA. This is almost NEC1-f16, i.e. NEC1 with no relationship between the four bytes, but there is a weird twist. The NEC1-f16 protocol in IRP notation is

{38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E:8,1,^108m,(16,-4,1,^108m)*)

where D,S,F,E are unrelated. PID 01BA has two fixed bytes, the D and S here, and two variable bytes, the F and E here, and sends this form when the msb of E is 0. However, when the msb of E is 1, the ditto frame has a slightly longer SPACE in its single burst pair, giving

{38.0k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E:8,1,^108m,(16,-4.5,1,^108m)*).

This protocol is used in the OARUSB04G and OARI06G in setup Audio/1155, which a code list shows to be used by a DLO audio accessory.

A string of NEC variants seem to have been discovered in recent years, with names in DecodeIR.html such as NEC1-y1 and NEC1-rnc as well as NEC1-f16. Is this another one to be added to the list or is it a one-off of no interest to anyone?
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18403
Location: Chicago, IL

PostPosted: Sun Jan 03, 2016 12:43 pm    Post subject: Reply with quote

Are you saying that there is assembler code in the executor that extends the ditto frame like that? Do you know what setup code uses this executor, and maybe what device uses that setup code?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3240

PostPosted: Sun Jan 03, 2016 1:38 pm    Post subject: Reply with quote

Graham said:
Quote:
This protocol is used in the OARUSB04G and OARI06G in setup Audio/1155, which a code list shows to be used by a DLO audio accessory.
The OARI06G is a S3F80 remote and the executor is:
Code:
43 8b 22 8b 14 cf 4d 08 08 01 20 00 ff 01 20 03 31 d2 dc 11 94 08 b6 04 ce 76 06 80 6b 09 0c d2 f5 22 c0 0e f5 23 c0 8d 01 46
The OARUSB04G is a MAXQ remote and it explicitly changes the alternate lead-in burst from 8892uS/2210uS to 8892uS/2470uS.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 18403
Location: Chicago, IL

PostPosted: Sun Jan 03, 2016 2:18 pm    Post subject: Reply with quote

Interesting, looking at the S3F8 assembler, I see that it tests the first bit of the 2nd cmd byte to decide whether to change the timing or not.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


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

PostPosted: Sun Jan 10, 2016 10:43 am    Post subject: Reply with quote

A few more.

PID 01EA sends NEC1 and NEC2 signals with a twist: the function bytes precede the device bytes. The IRPs are

{38.0k,564}<1,-1|1,-3>(16,-8,F:8,~F:8,D:8,S:8,1,^108m,(16,-4,1,^108m)*) and
{38.0k,564}<1,-1|1,-3>(16,-8,F:8,~F:8,D:8,S:8,1,^108m)+.

When S takes its default value as the complement of D, these show in DecodeIR as NEC1 and NEC2. In a single signal this protocol is indistinguishable from standard NEC1/2. However, when several signals are sent to DecodeIR then it is the device code that varies, not the OBC, as the two roles are interchanged. For a general S, these show in DecodeIR as NEC1-f16 and NEC2-f16 with OBC2 being the subdevice of this variant protocol.

PID 01A5 is a Konka mini-combo. The Konka protocol has an OBC with a range 0-255. This mini-combo still uses a single variable byte but 2 bits select from one of four device codes and the remaining 6 bits are the OBC with the restricted range 0-63.

PID 01F8 is the Elan protocol. In DecodeIR.html this is shown with the IRP

{40.2k,398,msb}<1,-1|1,-2>(3,-2,D:8,~D:8,2,-2,F:8,~F:8,1,^50m)+.

This executor is similar to that for NEC in that it allows the two device bytes to be independent, thus

{40.2k,398,msb}<1,-1|1,-2>(3,-2,D:8,S:8,2,-2,F:8,~F:8,1,^50m)+,

so allowing a subdevice S whose default value can be set to be the complement of D.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Sun Jan 10, 2016 1:49 pm    Post subject: Reply with quote

A couple more.

PID 0117 is a Panasonic (old) combo that uses two command bytes to specify both the device code and the OBC.

PID 0087 is listed under the Panasonic (old) entry in DecodeIR.html as an alternative to PID 0000 for this protocol, but although it has the same functionality, it is a 35kHz variant instead of the standard 58kHz.
_________________
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 - General Forum All times are GMT - 5 Hours
Page 1 of 1

 
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