Newer Samsung UN75CU7000, IR?

[Barf]

Nice to hear. Please report all quirks you enounter with the Mac version, since there are very few Mac users.

To use the signals captured in IrScrutinizer, use for example "export parametric remote" as Girr. This file can then be directly opened by RMIR/Remotemaster.

[unclemiltie]

Well, it worked to gather the signals, but does not work to control the TV. None of the buttons that I learned with irScruinizer work on the remote when an upgrade is built.

suggestions?

[Barf]

I can only guess. My guess is that the remote sends both IR and BT (or RF), and the TV, through hardware, software or configuration only listens for BT (or RF).

If in IrScrutinizer you select Import -> Remotelocator -> Samsung -> TV (or TVs) you will find a plethora of IR files captured in other projects. Do they agree with your captures?

[unclemiltie]

The TV is looking for IR. If I take the factory remote and put it behind a book or something the TV doesn't respond.

I'll look at other imports to see what I can find. This one is running Protocol NECx-f16f with device=7, sub=7

[mdavej]

Try plain old NECx2

[The Robman]

I think we'd need to see the IR learns and the RMDU file that you created in order to spot the problem. NECx-f16 uses 2 OBCs for each function, so we'd need to make sure that you populated both of them correctly.

Having said that, most Samsung TVs do indeed use NECx2 with 7.7, so I suspect that the NECx-f16 protocol is incorrect.

[unclemiltie]

Changing to NECx2 did the trick, the limited number of buttons learned from the remote now seem to work. (this is a very, very limited button remote)

Now onto finding a similar upgrade with other defined buttons and discretes to see if I can make the Nevo work!.

Thanks all


Any idea why both the learns into the remote and IR scrutinizer seem to think it was NECx-f16?

[Barf]

Any idea why both the learns into the remote and IR scrutinizer seem to think it was NECx-f16?

In order not to keep guessing, please post the raw signals captured by IrScrutinizer. For this, turn off Options -> invoke repeat finder as well as Options -> invoke signal cleaner. Capture on the the Scrutinize remote / Raw remote pane. Make several captures of the same signal, giving them unique names. Then "export raw remote" as Girr with Raw enabled and upload to the diagnostics area.

[unclemiltie]

Heres's a ZIP file with several captures of the "UP" button on the factory remote. When I went to save these it says there were learn errors


http://www.hifi-remote.com/forums/dload ... e_id=27223


I can do some learns on the OARUSB04G if you want me to, got the same results. Looks like the device/subdevice numbers are right and the OBC is right but the protocol is wrong.

[vickyg2003]

I have had a lot of difficulties taming the new Samsung TVs.

Even with the OEM remote the arrow keys are unreliable. Often jumping multiple times.

The menus are context sensitive and so the same sequence of buttons don't have the same results.

I have rearranged the quick menu items, moving speaker selection, closed captioning and multi-view near the beginning of the menu

I have successfully tamed the input selection, aspect ratio, closed captioning, speaker selection.

My biggest problem is that it "knows" all the passwords that My Samsung tablet knows. I guess I should have set up a new Samsung account for the TVs.

[Barf]

Thank you uncle for this. Turns out to be very interesting.

The first segment, "intro", is exactly what we expect from Samsung, the intro of NECx1 or NECx2 (which should probably have been called Samsung32, but that is another story). Now, for some reason, IrpProtocols does not contain a protocol named "NECx" but "only" NECx-f16. Strictly speaking, the former is a special case of the latter. After the intro comes a "repeat" (which is not really a repeat since they are different) and that is radically different from the repeats we have seen in NECx1 and NECx2. So the decode stops decoding after the intro, and considers the rest of the signal garbage:

Code: Select all

./irptransmogrifier decode --input uncle.txt 
        NECx: {D=7,S=7,F=96}, beg=0, end=67 {UNDECODED. length=160}
        NECx: {D=7,S=7,F=96}, beg=0, end=67 {UNDECODED. length=160}
        NECx: {D=7,S=7,F=96}, beg=0, end=67 {UNDECODED. length=80}
        NECx: {D=7,S=7,F=96}, beg=0, end=67 {UNDECODED. length=72}

So that explains and justifies

Looks like the device/subdevice numbers are right and the OBC is right but the protocol is wrong.

I will look into the repeat stuff shortly.

[Barf]

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

[unclemiltie]

Is there one of the Samsung TV files that has the most comprehensive list of discovered codes in it? I have been doing code searches and have found that there are a number of them that bring up "not available" on the screen when sent. Another I've found is "this app is not available in your region"

The "not available" are probably things that only work when the TV is doing something else so it'd be good to know what they are.


thx

[vickyg2003]

Bill, I think you should try mine. As I said earlier in this thread, I worked my way through the Samsung master file for my 2024 Oled and Qled Samsung TVs.


Discrete On
Discrete Inputs



Samsung S90D Series OLED 4K UHD Smart TV (2024)

[unclemiltie]

Vicky

For what it's worth, I DID find a Discrete Off, and it works, in my code search. It's OBC 152/Hex E6. So maybe not working is particular to your specific TV?