• The forum software that supports hummy.tv has been upgraded to XenForo 2.1!

    This upgrade brings a number of improvements including the ability to bookmark posts to come back to later. Please bear with us as we continue to tweak things and open a new thread for any questions, issues or suggestions in Site/Forum Issues.

T2 changing channels, volume and going into standby by itself

cdmackay

Active Member
hi all,

Since yesterday, we're suffering quite badly from the problem described in this old thread; I'm not sure whether it's acceptable to resurrect a thread not updated in 5 years, so I'm starting a new one. If folks would prefer I update that old one, I will move this post there.

The symptoms are that the T2 changes channels by itself, as though it were receiving IR remote signals that I'm not knowingly sending. It also changes volume, and goes into standby, exactly as in the above thread.

The channel changes don't seem to be random: it moves up the channel list one at a time, as though ChUp (or equiv) were being pressed.

Everything was fine until yesterday evening: we'd never seen this before. Since then, it's doing it constantly; sometimes once a second, sometimes not for 20 or 30s, but rarely does it go longer than that.

Of course, "nothing has changed", as they say, at least as far as we're aware.

I've tried the following to no avail:

• factory reset (which was hard, since it wouldn't complete the power-on retune without going back into standby, but I eventually managed to get past it somehow.

• changed IR mode (also hard, since I use the Harmony remotes, can't find the original remote, and the Harmony system seems to have a bug in selecting the IR mode; see here).

• unplugged external USB disk, and ethernet cable. Powered off nearby switch, and other equipment.

• Tried a direct HDMI connection, rather than via my HDMI matrix as normally connected.

• Tried three different HDMI cables, directly connected to the TV, using two different HDMI ports on my TV (Samsung, old). Note that CEC is disabled on those ports (probably on all, but definitely on those two)


I've yet to open up the Humax; I will do that, give it a clean, and reseat the front-panel connectors.


One interesting point that I didn't see mentioned in the old thread is that my problem doesn't seem to happen at all when the TV is switched off.

i.e. if I power on the Humax only, then use the webif, or the cmdline "status" via an ssh connection, and monitor it, it does not change channels, nor does it go into standby, when the TV is switched off. I can change channels manually using the remote control, and that works fine, but it doesn't change by itself.

The instant the TV is switched on, it starts to happen. Does that mean that it's not likely to be the front panel gone bad?

Assuming that it might therefore be some EMI (but from where?) that is being picked up on the HDMI cable, is there anything I can do? Presumably a random ferrite bead/choke isn't a good idea, given that HDMI cables are supposed to carry high-frequency signals?

Any ideas what I might try next, please?

thanks very much; the poor Humax is quite unusable in this state; although we can still record (but not watch).

--

Web interface version: 1.4.4-7
Custom firmware version: 3.03 (build 2368)
Humax Version: 1.03.12 (kernel HDR_CFW_3.03)
 
Last edited:

/df

Active Member
The other thread suggests setting up your T2 somewhere with a different mains supply.

Or based on what you have found so far (is there a power supply fault in your TV feeding noisy mains into the T2?), just with a different TV?

Or with the TV plugged into a different mains socket, or with some sort of mains filter?

Finally, how about a test using SCART instead of HDMI?

Not that it is likely to be relevant, but your CF is an old version.
 
OP
cdmackay

cdmackay

Active Member
The other thread suggests setting up your T2 somewhere with a different mains supply.

Or based on what you have found so far (is there a power supply fault in your TV feeding noisy mains into the T2?), just with a different TV?

Or with the TV plugged into a different mains socket, or with some sort of mains filter?

Finally, how about a test using SCART instead of HDMI?
Thanks very much.

I've not yet been able to extract the T2 from the huge pile of inter-wired stuff behind the telly; I will need to dismantle a few other things to do that, but that's the plan, and then I can test it on a long extension from a mains socket in another room, and a bit further from all the other crap behind the telly (although it's all been fine there for years).

Ditto TV power.

I'll also try the T2 upstairs on another telly, although there's no aerial cable up there, so that may put the T2 into a sulk?

I've got some ferrite beads arriving tomorrow, so will try those on the mains cable(s) too.

I don't have a SCART cable to hand (but could get one from a friend, I think).

thanks again.
 

Ezra Pound

Well-Known Member
you could monitor the IR codes using Telnet on the humaxtv.log file :-
Code:
Humax1# tail -f /tmp/humaxtv.log

GetEvents(): faking key 05 (2)
Real IR code: 00000000 0xfa051000 (5) [foreign=0]
GetQueueSize: 1
GetEvents(): faking key 05 (1)
Real IR code: 0x000001 0xfa051000 (5) [foreign=0]
Real IR code: 00000000 0xfc031000 (3) [foreign=0]
Real IR code: 0x000001 0xfc031000 (3) [foreign=0]
Real IR code: 00000000 0xfb041000 (4) [foreign=0]
Real IR code: 0x000001 0xfb041000 (4) [foreign=0]
Real IR code: 00000000 0xfa051000 (5) [foreign=0]
Real IR code: 0x000001 0xfa051000 (5) [foreign=0]
NOTE :- Use CTRL C to exit tail

Edit
I have just noticed (on another thread), that you have already done this, did it give any clues to your problem?
 
Last edited:
OP
cdmackay

cdmackay

Active Member
Thanks both; I enabled IR debugging with ir3/debugon, and then watched /var/log/humaxtv.log

As far as I can see, it is not receiving IR codes when the switching etc occurs.

I tried manually pressing the remote whilst watching the log file, and I do see that activity, but I don't see any activity corresponding to the phantom channel changing etc.

I've added ferrite beads to both power cables (TV & Humax), with no effect.

One interesting thing: it does not happen when the TV is off, but happens constantly with the TV switched on even if the TV and the Humax are not connected, e.g. I've removed the HDMI cable at both ends.

I've been out working in the garden all day; tomorrow I will dismantle things and try things remote from the normal location, etc.
 

Black Hole

May contain traces of nut
One interesting point that I didn't see mentioned in the old thread is that my problem doesn't seem to happen at all when the TV is switched off...

The instant the TV is switched on, it starts to happen...
even if the TV and the Humax are not connected, e.g. I've removed the HDMI cable at both ends.
As far as I can see, it is not receiving IR codes when the switching etc occurs.
You have eliminated the IR command channel and CEC from the list of possibilities; as per Conan Doyle: "once you have eliminated the impossible, whatever remains, however improbable, must be the truth" (which is at least as valid in engineering fault finding as it is in fictional detective work).

There is a common factor involved in the commands you list in the title: they are all available via front-panel controls. Presumably you have not noticed any misoperation that could only be simulated by handset button presses. This coincidence also eliminates rogue IR - what are the chances rogue IR would confine itself to those operations?

Hypothesis: the front panel assembly has become susceptible to interference from the TV, or a TV fault has caused it to increase interference levels beyond the front panel assembly's tolerance. Either way, moving the HDR away from the TV should reduce the incidence of the problem.

Making sure the front panel is clean (and free from any spray polish residue!) may help.
 
OP
cdmackay

cdmackay

Active Member
Thanks. Indeed, the front panel was covered in dust.

But the problem disappearing when the TV is off suggests it's not a capacitative front panel issue, I think? I've cleaned it, regardless (after moving it, see below)

Hypothesis: the front panel assembly has become susceptible to interference from the TV, or a TV fault has caused it to increase interference levels beyond the front panel assembly's tolerance. Either way, moving the HDR away from the TV should reduce the incidence of the problem.
Yes, indeed, that was my thinking, and indeed it's worked.

I've moved the Humax about 4' away from the telly, reintroduced all the wires, and the problem is now not happening.

Of course, I've changed two things here, which isn't ideal: the location, and also that the Humax is now plugged into a different mains socket, well away from the telly.

Now it's working again, I can carefully experiment: e.g. plug into old mains socket whilst leaving it in the location where it's working. And moving it to the old location whilst plugged into remote mains, etc, etc.

I had already put a ferrite on the mains lead, but it may not have been enough. Or the interference (if any) is EMI rather than (or as well as) carried via wires.

Thanks very much :)
 
OP
cdmackay

cdmackay

Active Member
I can't come to that conclusion myself. Contamination may affect the noise margins.
interesting, yes, I suppose so. Well, I've cleaned it anyway.

I'll give a final report when I'm done experimenting, but at least it's unable again now; thanks for all the help, everyone.
 

everthewatcher

Forum Supporter
Although I was involved in such things may years ago I've not investigated which touch sensing method is used on the HDR front panel. There's a Atmel AVR doing it so I'd hope it uses the Quantum/QProx capacitive sensing technique that Atmel (and now Microchip) gained the rights to when they bought Quantum in 2008. But it may be a much cruder technique that's susceptible to false activations under non-ideal conditions.

I have a hunch as to what may be happening. To confirm it (or not), should the problem return earth the HDR chassis - it's OK and quite safe - and report back if it works.
 
OP
cdmackay

cdmackay

Active Member
Although I was involved in such things may years ago I've not investigated which touch sensing method is used on the HDR front panel. There's a Atmel AVR doing it so I'd hope it uses the Quantum/QProx capacitive sensing technique that Atmel (and now Microchip) gained the rights to when they bought Quantum in 2008. But it may be a much cruder technique that's susceptible to false activations under non-ideal conditions.

I have a hunch as to what may be happening. To confirm it (or not), should the problem return earth the HDR chassis - it's OK and quite safe - and report back if it works.
Very interesting, thanks. If I can reproduce it, I will definitely try that.

But isn't the chassis routinely earthed through the mains connection anyway?
 
OP
cdmackay

cdmackay

Active Member
No - it's a double insulated device with a two-core (line and neutral) flex.
Goodness! i'd never noticed, thanks.

You'd think with all that metalwork, there'd be an earth simply for "metal parts" protection, e.g. the chassis becoming live because of something external to it, i.e. bonding?
 

MikeSh

Well-Known Member
Goodness! i'd never noticed, thanks.

You'd think with all that metalwork, there'd be an earth simply for "metal parts" protection, e.g. the chassis becoming live because of something external to it, i.e. bonding?
There is a potential (excuse the pun) problem with earthing the case. If the shared earth wiring, or the neutral/earth in a pme system, becomes faulty then all the earthed equipment can become live. It's not usually a problem, but it can be happen. Double insulation can actually be safer.
 

prpr

Well-Known Member
Unbalanced audio and earth loops are a nightmare to start with. Earthing equipment just makes it a whole load worse.
 

Black Hole

May contain traces of nut
If the shared earth wiring, or the neutral/earth in a pme system, becomes faulty then all the earthed equipment can become live. It's not usually a problem, but it can be happen.
Oh yes! Been there, done that, singed the tee shirt.

Logic analyser with earthed chassis and mains input filtering, IEC mains cable with a faulty earth connection, so I got (mildly) zapped every time I touched the analyser or anything the analyser was connected to. Reason: the mains input filter uses the earth as a shunt, so with the earth disconnected the chassis floated to half mains voltage. It is technically incorrect to use the protective earth connection this way, but it also solves a mains-borne interference problem so that's what is done.

(The other big no-no is using the handy centre mounting bolt on a toroidal transformer as a convenient place to connect the earth lead!)
 
Last edited:
Top