2

We're using the stb-tester ONE to test our set-top box (STB). We have noticed that sometimes the STB misses some of the IR signals sent from the transmitter (e.g. after several iterations of the same User Journey). Possibly this might be due to the specific STB under test. Did you also observe similar issues with other STBs in the past? Do you have any particular recommendation for us to avoid this, apart from implementing controls within the code to force “retries”?

Disclaimer: I work on stb-tester and am an employee of stb-tester.com Ltd. This is a sanitised version of a question we've previously received through other support channels published here in an effort to seed a stb-tester support community on stackexchange.

1 Answer 1

2

Yes, sometimes it can be a little tricky to get the IR configuration right. We have a high confidence in our IR blaster hardware. In soak testing we have sent 1000000 presses through them without a single missed keypress†.

This leaves three general causes of IR unreliability (in order of which you should check first):

Bad positioning of the IR blaster over the IR receiver

The stb-tester ONE’s IR transmitter is a low-power transmitter (to avoid interfering with other set-top boxes in your test lab) so it has to be close against the set-top box’s IR receiver.

Some set-top boxes are very sensitive to the placement of the transmitter; for example this set-top box has a cylindrical shield extending around the IR receiver diode, so the stb-tester ONE’s IR transmitter must be placed precisely in front of the diode:

https://stb-tester.com/assets/images/charter-ir-receiver.jpg

Using a torch (flashlight) can help you to see the position of the IR receiver behind the set-top box’s plastic case.

Bad lircd.conf IR configuration

You could try fiddling with the timing information at the top of the lircd.conf infrared configuration file. We have a blog post where we describe how lirc works and there is reference documentation on each lirc directive as well.

That said, the easiest thing to do here is add a min_repeat 3 directive to your lirc config file and that will often fix issues you've been having. This goes in your config/remote-controls/xxx.lircd.conf somewhere between begin remote and begin codes.

Example: your config/remote-control/my-remote.lircd.conf config file will look like:

begin remote
  name MY_REMOTE_CONTROL
  bits 8
  frequency 35555

  ...

  begin codes
    ...
  end codes
end remote

and you add min_repeat 3 underneath frequency. So the config file now looks like:

begin remote
  name MY_REMOTE_CONTROL
  bits 8
  frequency 35555
  min_repeat 3

  ...

  begin codes
    ...
  end codes
end remote

This will cause stb-tester to send the IR signal 3 times each time you call press() from your test-script. Your set-top box should interpret this as a single press, as if the user held the button down fractionally longer than usual.

You may find that your set-top box is now performing two presses sometimes instead of one. In that case change it to min_repeat 2 instead.

Bad IR receiver hardware/software (in the set-top box)

We have seen some set-top boxes don't always react when you send them a keypress due to hardware problems or software problems. A symptom of this is that the set-top box will sometimes ignore real presses from a real remote control. There are two things you can do in this instance:

  1. Fix your set-top box - if you are the set-top box manufacturer you may be able to lean on your dev team/hardware designers to fix the software/hardware in the set-top box so it doesn't have this issue. This will be good for the end-users of the set-top box too :)

  2. Work around it in your test-scripts - it's a good idea to check that performing an action in your test-scripts had the desired result anyway, so you can add logic to retry presses if there was no effect. Using APIs like press_until_match will naturally mask these issues.

    This is a last resort however as it can reduce the readability of your test-scripts and increase the maintenance cost.

† Our gen 1 IR blasters had reliability issues (0-0.5% failure rate per press), but we replaced them all in May 2016 sending our reliable gen 2 hardware out to all our customers. You can read about our investigation and how we fixed it in our IR blaster gen 1 post-mortem blog post.

Disclaimer: I work on stb-tester and am an employee of stb-tester.com Ltd.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.