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

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

T2 changing channels, volume and going into standby by itself

cdmackay

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:
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.
 
/df said:
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?
Click to expand...

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.
 
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:
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.
 
cdmackay said:
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...
Click to expand...
cdmackay said:
even if the TV and the Humax are not connected, e.g. I've removed the HDMI cable at both ends.
Click to expand...
cdmackay said:
As far as I can see, it is not receiving IR codes when the switching etc occurs.
Click to expand...
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.
 
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)

Black Hole said:
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.
Click to expand...

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 :)
 
Black Hole said:
I can't come to that conclusion myself. Contamination may affect the noise margins.
Click to expand...

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.
 
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.
 
everthewatcher said:
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.
Click to expand...

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?
 
everthewatcher said:
No - it's a double insulated device with a two-core (line and neutral) flex.
Click to expand...

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?
 
cdmackay said:
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?
Click to expand...
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.
 
Unbalanced audio and earth loops are a nightmare to start with. Earthing equipment just makes it a whole load worse.
 
MikeSh said:
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.
Click to expand...
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:
You must log in or register to reply here.
Back
Top