Soundbar doesn't recognize volume signals from URC-3660

[The Robman]

My bet is on the crystal. I have replaced the crystal on several remotes in the past

What is the crystal and how do you replace it, and how do you get replacement crystals?

[HamburgerHelper1]

Typically the crystal is the blue thing found in remotes.
I have seen other colors and i think color is used as a way of marking frequency
Sometimes they only have 2 leads but most cases now a days its 3 leads.
I the case of the 3660/3680 with the battery cover removed you can see the crystal
in the bottom left corner of of the hole for the battery cover notch.
They are not super small so if you know how to solder they are relatively easy to replace.
Some times I have just sacrificed an old remote that i no longer use for the crystal
Digikey should have them available to order as well and not expensive.
I think some of the diagrams in the schematic section should have the frequency on them and it may depend on the processor as to what frequency it uses.

[HamburgerHelper1]

From looking at boards i have laying around id say it is a 8 mhz ceramic resonator

[The Robman]

The main trouble with ordering electronic parts is knowing what to search for, so a link to an example of a crystal would be great. For example, Graham has posted info about building your own IR circuits and he says any LED will do, but try going to Digikey or Mouser and searching for just "LED" and a ton of completely irrelevant stuff will show up.

[HamburgerHelper1]

Rob Stated

The main trouble with ordering electronic parts is knowing what to search for

and i agree i just did not have time to look.

This list is for example only and not to rush and purchase any of them
more study of processor is needed.

Since i have unlimited access to used parts at work i am used to just puling a used part for testing to see if that will repair the item before purchasing new.
I would probably not bother replacing the crystal if this was my remote and wait and see if it gets worse.
Although I would take it apart and re-solder the crystal anyway
With the switch to Lead free solder I have run into numerous bad solder joints
Lead free solder joints develop small cracks in them


https://www.digikey.com/en/products/det ... B0/2588926

https://www.digikey.com/en/products/det ... -B0/584420

https://www.digikey.com/en/products/det ... -B0/584431

[jmezz13]

I would probably not bother replacing the crystal if this was my remote and wait and see if it gets worse.

Agree, not touching it. I assume it's one part that is at edge-of-tolerance or out-of-tolerance. But, with an easy workaround, the remote is working perfectly.

Although I would take it apart and re-solder the crystal anyway
With the switch to Lead free solder I have run into numerous bad solder joints
Lead free solder joints develop small cracks in them

Love this - as a retired electronics process/materials engineer for a large defense contractor you wouldn't believe how much work went in to worrying about lead-free solder being used in hi-rel electronics. It can be done well but has a tighter design and process window, so it can also be more easily done badly. Also, lead-free and tin-lead solder should not be mixed (for example in rework or repair) which can cause premature failure.

[jmezz13]

However, looking closer at the "LG sound bar remote vol + (works)" (which DecodeIR calls NECx1) shows that it is not quite NECx1: the repeat reads (IRP) 8,-8,D:1,1,^108, where D:1 is an encoded zero (Pronto: 0015 0015), while the learned code contains an encoded one (Pronto: 0015 0041). So it is not really NECx1, despite DecodeIR saying so. (IrpTransmogrifier's no decode is the correct answer.) It is quite plausible that the soundbar does not like what we call NECx1 -- for whatever reason -- and rejects it.

Writing an executor for the protocol: {38.4k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F:8,1,^108m,(8,-8,0:1,1,^108m)*) [D:0..255,S:0..255=255-D,F:0..255] ??

Barf,

Now that I have an AIRWidget & Girs Nano along with IRScrutinizer, I can finally understand what you said here. I see now the 1 bit in the repeating section that is different (1 instead of 0) for the NECx1 protocol. Interestingly, if I make a quick press on the remote with IRScrutinizer, it decodes as NECx-f16, I assume because there is no repeating section in the capture. When I make a longer press, IRScrutinizer does not produce a decoded format presumably because of this difference in the repeating section. When I did this in RMIR, learning on a remote, RMIR using DecodeIR identified as NECx1 which worked fine on the Soundbar. So, evidently the soundbar isn't picky about it's own remote format, but is when trying to read others!

So, if the Soundbar hadn't responded to NECx1, were you suggesting using PB to create another protocol?

[Barf]

Using IrScrutinizer and the Arduino, first verify this: Sending a few (say 10) repeats (that is the "Hardware" pane, "Count", pretty much in the middle), please confirm that:

Code: Select all

0000 006C 0022 0003 00AD 00AD 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 06FB 00AD 00AD 0016 0016 0016 0E98

does not work, while

Code: Select all

0000 006C 0022 0003 00AD 00AD 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 06FB 00AD 00AD 0016 0041 0016 0E98

works.

[jmezz13]

They both work.

Out of the 10 repeats sent, the soundbar accepted 7 of them for both. I assume the repeats might be a bit too fast for the receiver.

As a side note but not intending to sidetrack the thread, what have you found for the distance between emitter and receiver on the Arduino to get receivers to pick up the signal? I'm getting about 3-4 inches which I take to be because the Arduino has a such a low current sinking capability on the data lines.

[Barf]

They both work.

"This cannot happen". Back to square 1.

I would recommend using IrScrutinizer + the Arduino to capture a number of "different" Volume+ signals in raw mode. Select pane "Scrutinizer remote" -> Raw Remote. Deselect Options -> Invoke repeat finder and Options -> Invoke signal cleaner. Capture a number of different Volume+ signals, with different sending remotes, different number of repeats (short as well as long), and write down the outcome in the Comment column. Then export the result as Girr, Text (with raw format) or "Spreadsheet". See if you can spot a pattern there. And post it in the diagnose uploads.

As a side note but not intending to sidetrack the thread, what have you found for the distance between emitter and receiver on the Arduino to get receivers to pick up the signal? I'm getting about 3-4 inches which I take to be because the Arduino has a such a low current sinking capability on the data lines.

What exactly are you asking for? "the distance between emitter and receiver" is the distance between some components on the boad, and it is a too corny of a question. The sending covers 5-10 meters (15-30 feet), reading with the non-modulating receiver 1-2 m (3-6 feet), the modulating receiver some 40m (120 feet) (according to data sheet). A board such as the Arduino nano supplies up to 40mA, which is not "low". (More modern boards often only provides 1mA or such.)

[jmezz13]

What exactly are you asking for? "the distance between emitter and receiver" is the distance between some components on the boad, and it is a too corny of a question. The sending covers 5-10 meters (15-30 feet), reading with the non-modulating receiver 1-2 m (3-6 feet), the modulating receiver some 40m (120 feet) (according to data sheet). A board such as the Arduino nano supplies up to 40mA, which is not "low". (More modern boards often only provides 1mA or such.)

I was asking about the distance between the Arduino and whatever receiver you're sending to. I played around trying to learn on an old 8810 by sending signals from the Arduino. Could only get a successful learn at about 3.5". I see the transmitter's rating is based on 100mA which is why I thought the Arduino could be causing a reduced range. Maybe the learning receiver on these remotes aren't very sensitive? I'll play around some more.

[Edit: I just tried sending to the Soundbar itself from the Arduino and it worked from 6 ft away. So I guess my original experiment was flawed with my assumption that the learning remote receiver functions similarly to the receiver's on actual equipment.]

I will do the experiment with the LG Soundbar remote and report back.

[jmezz13]

I would recommend using IrScrutinizer + the Arduino to capture a number of "different" Volume+ signals in raw mode. Select pane "Scrutinizer remote" -> Raw Remote. Deselect Options -> Invoke repeat finder and Options -> Invoke signal cleaner. Capture a number of different Volume+ signals, with different sending remotes, different number of repeats (short as well as long), and write down the outcome in the Comment column. Then export the result as Girr, Text (with raw format) or "Spreadsheet". See if you can spot a pattern there. And post it in the diagnose uploads.

I tried with four different configurations with short and long presses:
1) LG Soundbar Remote
2) 3660 with device upgrade using NECx1 protocol for the Soundbar
3) 3660 using learned command from LG remote
4) 3360 using learned command from Barf's suggested Pronto code that matches the NECx1 protocol (D:1=0 on repeats)

In all four configurations, the remote successfully controls the soundbar including repeats for long presses.

The only signal that technically matches the NECx1 protocol is the one build on Barf's Pronto Code. Even the device upgrade using the NECx1 protocol built-in to the remote puts the "1" bit where there should be a "0" on the repeats. Not sure what's going on there. Maybe the NECx1 protocol is intended to be a little more flexible than currently defined?


The export GIRR file is here:
https://www.hifi-remote.com/forums/dload ... e_id=26677

[Barf]

@jmezz13: since your captures (which look fine btw) do not contain any one that did not work, not much I can do. Or possibly the original problem has gone away?

[The Robman]

@jmezz13: since your captures (which look fine btw) do not contain any one that did not work, not much I can do. Or possibly the original problem has gone away?

IIRC, the soundbar always responded to its own NECx1 dev 44 signals, in all of the variants presented. The original problem was that it didn't respond to some variants of the Vizio TV NEC1 dev 4 signals.

The soundbar is programmable so that it will respond to your TV remote, in addition to its own remote, saving you from needing a universal remote. What Jay found was that the soundbar does respond to the OEM TV remote, and some of his other JP1 remotes, but it does not respond to his URC-3660 (programmed with the Vizio TV code), even though the Vizio TV itself does respond to it.

[jmezz13]

Rob got it right. Using the learned soundbar signals in a device upgrade worked right away, but this thread took on a life of it's own due to technical curiosity (hopefully of more than just me) and I learned quite a bit!

Thanks all!

Jay