Newer Samsung UN75CU7000, IR?

[The Robman]

There is also the Samsung TV master file, which includes every OBC that I could find in all of the Samsung TV upgrades.
http://hifi-remote.com/forums/dload.php ... e_id=13742

[vickyg2003]

The Samsung master file was a great help.

The TV is a challenge for automation.
1. Context sensitive quick menu is a PITA to navigate.
2. Random advertising pop ups make macros misfire.
3. Interface is extremely slow to navigate and so to point the remote for a long time

My TV doesn't have a discrete off, every one of the codes acted as a toggle.

[3FG]

Vicky,
As I posted earlier in this thread, I also have a S90D. It is model QN77S90DAFXZA, with software T-PTMDAKUC-1301.1.

The Discrete Off IR command does work for us. I wonder if the firmware in your TV was up to date when you did the testing.

[vickyg2003]

Dave, I think you hit the nail on the head. When I was doing my code search I was getting updates ALL the time. I must have had 4 updates the first month I owned the s90. I never thought to go back and recheck that the button codes might have changed behavior.

[vickyg2003]

Earlier in this thread i was cmplaining about how my new Samsung TVs hate working with a Roku. When my Tv recognizes that a Roku is plugged in, it issues a play command on the Roku. Every time i switch to the Roku.

My solution was to unplug the Roku and the TV and then replug it in but stopping the recognition process before it set it up as a Roku. I have not had the problem since January. while the Roku was being called a PC. Today after a power outage the TV recognized my Roku as a Roku and now the problem is back. The random PLAY command just installed Paramont +

I know several of you have newer Samsung TVs and yet I am the only one with the problem!!!

[stama]

I don't know if this will be of any help to you, but I uploaded a device upgrade file with IR codes that work on my S95C TV here.

Quoting myself:

This device upgrade has functions from three sources:
- the Standard Remote
- the Smart Remote (the Solar Cell remote which comes with the S95C is one version of a Smart Remote)
- the Service Remote.

Some keys have different behaviors depending on the duration of the key press. Pressing "Mute" for one second or more is seen as having pressed "AD/SUBT." key instead according to the "Learn Remote" feature present in the Accessibility Shortcuts menu, which will speak out loud what key was pressed on the remote while in this menu.

The Notes have lots of details of what happens when you press the key in different scenarios.

The beginning of a note usually starts with the name the key would normally have on a remote inside parentheses - for instance (Info) or (AD/SUBT.).

Some keys, when pressed for longer than 1 second, or 5 seconds, or 10 seconds, are interpreted by the TV as the press of another key on the remote. Pressing the (Mute) key for 1 second or more is interpreted as a press of the remote key "AD/SUBT." for instance. The device upgrade file notes list this other key as well - the function with OBC 15 which would normally be interpreted as a (Mute) key press, also lists (AD/SUBT. on LKP) in its note description.

This TV was not connected to the Internet, so the apps which require Internet connection might have not been properly identified. The keys which would normally trigger Netflix/Amazon Prime and so on are mapped to PIP and Teletext instead because of this, but this can be easily changed.

Later Edit: perhaps you have the "Universal Remote" feature enabled on your Samsung TV?

This will either use HDMI-CEC (Anynet+ in Samsung speak), or the TV will send IR signals (!!!) as if it were a remote control for the external device.

For more information, refer to "Controlling External Devices with a Samsung Remote Control - Using the Universal remote setup" in the TV user manual.

[stama]

So I continue trying to make sense of the repeats: Saving uncle's signals to a text file, and invoking irptransmogrifier from the shell gives:

Code: Select all

./irptransmogrifier anal  -s  --input uncle.txt

Gaps:
A:	304			31
B:	540			100
C:	721			71
D:	958			47
E:	1688			56
F:	4525			4
G:	48583			4
H:	177821			55
I:	303697			4

Flashes:
A:	304			236
B:	540			132
F:	4525			4

Pairs:
BB:	72
AC:	71
BE:	56
AH:	55
AD:	47
AA:	31
AB:	28
AI:	4
BG:	4
FF:	4

#0	FF BE BE BE BB BB BB BB BB BE BE BE BB BB BB BB BB BB BB BB BB BB BE 
BE BB BE BE BE BE BE BB BB BE BG AD AA AC AH AC AA AC AH AD AA AC AH AD 
AB AC AH AD AB AC AH AC AA AC AH AD AA AC AH AD AB AC AH AD AA AC AH AD
AB AC AH AD AB AC AH AD AB AC AH AD AB AC AH AD AB AC AH AD AA AC AH AD 
AB AC AH AD AA AC AH AC AA AC AH AD AB AC AH AC AA AC AI

#1	FF BE BE BE BB BB BB BB BB BE BE BE BB BB BB BB BB BB BB BB BB BB BE 
BE BB BE BE BE BE BE BB BB BE BG AD AA AC AH AC AA AC AH AD AA AC AH AD 
AB AC AH AD AB AC AH AC AA AC AH AD AA AC AH AD AB AC AH AD AA AC AH AD 
AB AC AH AD AB AC AH AD AB AC AH AD AB AC AH AD AB AC AH AD AA AC AH AD 
AB AC AH AD AA AC AH AC AA AC AH AD AB AC AH AC AA AC AI

#2	FF BE BE BE BB BB BB BB BB BE BE BE BB BB BB BB BB BB BB BB BB BB BE 
BE BB BE BE BE BE BE BB BB BE BG AD AA AC AH AD AA AC AH AD AB AC AH AD 
AA AC AH AD AB AC AH AD AA AC AH AD AA AC AH AD AB AC AH AD AA AC AH AD 
AB AC AI

#3	FF BE BE BE BB BB BB BB BB BE BE BE BB BB BB BB BB BB BB BB BB BB BE 
BE BB BE BE BE BE BE BB BB BE BG AC AA AC AH AD AB AC AH AC AA AC AH AD 
AB AC AH AD AA AC AH AD AB AC AH AD AB AC AH AC AA AC AH AC AA AC AI

(Irrelevant lines deleted, long lines broken.)
What is disturbing here is that there are the presence of both AC and AD. C (= 721) and D (= 958) appears "not that close", and makes the dittos different. Increasing the tolerance (arbitrarily to 40%) gives

Code: Select all

./irptransmogrifier -r 0.4 anal  -s  --input uncle.txt

Gaps:
A:	316	= 1*316  	59
B:	583	= 2*316  	131
C:	952	= 3*316  	59
D:	1688			56
E:	4525			4
F:	48583			4
G:	177821			55
H:	303697			4

Flashes:
A:	316	= 1*316  	236
B:	583	= 2*316  	132
E:	4525			4

Pairs:
BB:	72
AA:	59
AB:	59
AC:	59
BD:	56
AG:	55
AH:	4
BF:	4
EE:	4

#0	EE BD BD BD BB BB BB BB BB BD BD BD BB BB BB BB BB BB BB BB BB BB BD 
BD BB BD BD BD BD BD BB BB BD BF AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AH
#1	EE BD BD BD BB BB BB BB BB BD BD BD BB BB BB BB BB BB BB BB BB BB BD 
BD BB BD BD BD BD BD BB BB BD BF AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AH
#2	EE BD BD BD BB BB BB BB BB BD BD BD BB BB BB BB BB BB BB BB BB BB BD 
BD BB BD BD BD BD BD BB BB BD BF AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AH
#3	EE BD BD BD BB BB BB BB BB BD BD BD BB BB BB BB BB BB BB BB BB BB BD 
BD BB BD BD BD BD BD BB BB BD BF AC AA AB AG AC AA AB AG AC AA AB AG AC 
AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AG AC AA AB AH

and suddenly all the dittos are identical!! So I try to add a new protocol with a four-pulse ditto

Code: Select all

    <irp:protocol name="NECx3">
        <irp:parameter name="prefer-over">NECx-f16</irp:parameter>
        <irp:irp>
            <![CDATA[{38.4k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F:8,1,^108m,(316u,-952u,316u,-316u,316u,-583u,316u,-177821u)*) [D:0..255,S:0..255=255-D,F:0..255]]]>
        </irp:irp>
    </irp:protocol>

to IrpProtocols.xml, and, voila:

Code: Select all

 ./irptransmogrifier decode  --input uncle.txt 
        NECx3: {D=7,S=7,F=96}, beg=0, end=227, reps=20
        NECx3: {D=7,S=7,F=96}, beg=0, end=227, reps=20
        NECx3: {D=7,S=7,F=96}, beg=0, end=147, reps=10
        NECx3: {D=7,S=7,F=96}, beg=0, end=139, reps=9

It decodes!!

So how do we handle this case

This is very interesting!

While using IrScrutinizer with my S95C TV I also noticed that it was detecting the IR codes as being detected randomly as either NECx-f16 or NECx2.

But I soon realized using NECx-f16 would not work fine when sending repeated signals.

Pressing "Mute" is supposed to show the "Accessibility Shortcuts" menu when pressed for 1 second or more, according to the user manual, but this was not happening when using NECx-f16 in IrScrutinizer as the protocol.

Switched to Necx2, and the "Accessibility Shortcuts" menu popped up when pressing "Mute" for 1 second or more. NECx2-f16 was also working fine.

Is there any change still planned for the protocol to be used with Samsung TVs, or do we still use Necx2?

[unclemiltie]

I'm finding that I get a lot of "bouncing" on some buttons using NECx2 on my TV. (e.g. if I push the down arrow the cursor will move two unless I poke it very short). I suspect this has something to do with what barf reported above

[Barf]

I'm finding that I get a lot of "bouncing" on some buttons using NECx2 on my TV.

Just change them to NECx1. I already explained why this happeded, which justifies just changing it.

[Barf]

I have checked in NECx and NECx3, as above, in IrpProtocols.xml. The ones who desire can download that file and replace the current IrpProtocols.xml in RemoteMaster.jar.

The inclusion of NECx3 is experimental, and may be reverted.

Looking forward for comments from the protocol watchers, in particular Graham. What executor mapping make sense?

And it still bugs me that the rest of the world is saying "Samsung"...

[stama]

I tested the NECx3 protocol from the new IrpProtocols.xml with my use case, of sending a long press "Mute" key and checking if it was being interpreted by the TV as the press of the AD/SUBT. key instead like the user manual says it should happen.

And it works, it's just that I have to increase the number of repeats in the IrScrutinizer Hardware tab from 10 (the value I was using with NECx2) to 20. The value of 15 (which is the previous value available in the "Count" drop-down) would not trigger the behavior.

Since I don't know which of these (NECx2 with 10 repeats, or NECx3 with 20 repeats) is supposed to represent "1 second or more" of signal sent, I'm going to assume that both are fine.

mathdon, Barf, do you think it would be possible to add this protocol to RMDU, to be able to create a device upgrade file and test it with the Samsung TV?

Or at least point me to some documentation which says how I could do that myself?

[Barf]

First of all, I would like to find out why we have found this new protocol in a Samsung TV. I have seached in the Global Cache ControlTower database and the Flipper IRDB data base, and could not find anything like this.

Assuming that it is a real new protocol (-variant) we have discovered, the next step is to write an executor for the particular remote you are using (ideally for all the common processors). For this, the "Protocol Builder" (this is a misnormer, it builds executors), contained in the RMIR package, can be used. Normally, the executor experts volunteer very quickly, for some reason not here . With that, your remote can send the new protocol from parameters, just like the built in executors. There is docs in the wiki. Then it remains to write the rules for mapping the protocol to the executors, see this document.

Independent of all this, you can just replace the file IrpProtocols in RemoteMaster.jar (which is really a ZIP file with some extra functionality) using your favorite achive program. We use to use WinZip (on Windows), but nowdays an achiver program is contrained in "all" modern OS (I think...).

This should keep you busy for the rest of the day.

[unclemiltie]

Barf

something interesting with this TV and this newly found protocol

So initially I had loaded up my Nevo with the NECx2 protocol and had reported here that I was having issues with some keys "bouncing". you suggested that I swap to NECx1, which I did

I then started having issues with intermittent keys not working. I was hoping that it wasn't the remote so I loaded up another remote and had the same isssue. Swapped back to NECx2 and have been going for a couple of days without the intermittent issue.

[MaskedMan]

Going back almost thirty years oem and universal remotes have had the wrong protocol for Samsung tv's. Resulting in non-repeating volume commands. UEI finally came up with corrected preset code TV 0702. Later the standard UEi code for Samsung tv's was TV 0812. It took TiVo remotes like 10 years to finally have corrected code 0305 in their remotes.

[The Robman]

TV/0702 uses NECx2 dev 7.7