Note: Descriptions are shown in the official language in which they were submitted.
CA 02740662 2011-05-19
Page
MULTIMEDIA DEVICE TEST SYSTEM
[001] TECHNICAL FIELD
[002] The present disclosure relates to test systems.
[003] BACKGROUND
[004] Existing test systems for set tops and other devices suffer from lack of
scalability. In
existing systems a central processing unit employs a defined test sequence,
receives and
processes raw test data, and then analyzes and stores results. This is an
inefficient and error
prone approach.
[005] BRIEF DESCRIPTION OF THE DRAWINGS
[006] In the drawings, the same reference numbers and acronyms identify
elements or acts with
the same or similar functionality for ease of understanding and convenience.
To easily identify
the discussion of any particular element or act, the most significant digit or
digits in a reference
number refer to the figure number in which that element is first introduced.
[007] FIG. I is a block diagram illustration of an embodiment of a test
system.
[008] FIG. 2 is a block diagram illustration of an embodiment of logic modules
in a test unit.
[009] FIG. 3 is a block diagram illustration of an embodiment of a test system
including a
pluggable, type-specific modular interface between a test unit and a unit
under test.
[0010] DETAILED DESCRIPTION
CA 02740662 2011-05-19
Page i 2
[0011 ] References to "one embodiment" or "an embodiment" do not necessarily
refer to the same
embodiment, although they may.
[0012] Unless the context clearly requires otherwise, throughout the
description and the claims, the
words "comprise," "comprising," and the like are to be construed in an
inclusive sense as
opposed to an exclusive or exhaustive sense; that is to say, in the sense of
"including, but not
limited to." Words using the singular or plural number also include the plural
or singular
number respectively. Additionally, the words "herein," "above," "below" and
words of similar
import, when used in this application, refer to this application as a whole
and not to any
particular portions of this application. When the claims use the word "or" in
reference to a list
of two or more items, that word covers all of the following interpretations of
the word: any of
the items in the list, all of the items in the list and any combination of the
items in the list.
[0013] "Logic" refers to machine memory circuits, machine readable media,
and/or circuitry which
by way of its material and/or material-energy configuration comprises control
and/or procedural
signals, and/or settings and values, that may be applied to influence the
operation of a device.
Magnetic media, electronic circuits, electrical and optical memory (both
volatile and
nonvolatile), and firmware are examples of logic. Those skilled in the art
will appreciate that
logic may be distributed throughout one or more devices, and/or may be
comprised of
combinations memory, media, processing circuits and controllers, other
circuits, and so on.
Therefore, in the interest of clarity and correctness logic may not always be
distinctly illustrated
in drawings of devices and systems, although it is inherently present therein.
[0014] The techniques and procedures described herein may be implemented via
logic distributed
in one or more computing devices. The particular distribution and choice of
logic is a design
decision that will vary according to implementation.
[0015] A novel test system includes a supervisor unit coupled to a control
interface. The control
interface is coupled to multiple test modules. Each test module is coupled to
a device under test
with inputs and outputs that are decoded and sent to the test unit for further
diagnostics. Each
test module includes multiple logic modules. Among the logic modules are a
first logic module
to test macro blocking errors; a second logic module to perform optical
character recognition, a
third logic module to perform signal to noise ratio measurement, and a fourth
logic module to
perform random noise measurement. New or different logic modules may be
included in the
CA 02740662 2011-05-19
Page: 3
test module to configure the device under test under new specifications and/or
requirements and
process information to meet new test requirements.
[0016] The supervisor unit includes logic to start and control each module.
Each test module
includes server logic that is adapted to control each logic module of the test
modules as a server
service. Thus, the supervisor module may interact with each logic module of
each test module
using a client-server communication model.
[0017] Each test module may include additional logic modules, including one to
communicate
commands to setup the proper menus on the device under test, and one or more
to perform tests
with the multimedia device (e.g. Audio, DVR, Video).
[0018] The supervisor unit communicates control commands via the control
interface to the
multiple test modules. Each test module is associated with a device under
test. Each (video
related) logic module obtains a video frame from the device under test and
operates on the
video frame according to the control commands received from the supervisor
unit. Each audio
related logic module may configures the hardware on the test module to decode
audio (e.g.
PCM, Dolby) and processes information from the device under test (e.g.
Frequency, THD).
Each logic unit communicates to the supervisor unit, via the server interface
of the associated
test module, a result of operating on the video frame.
[0019] Commands from the supervisor unit to the test units (e.g. OCR, DVR,
HSL, THD) may be
implemented via a server-client messaging model. The test unit may include
server logic which
responds to commands from the server by initiating and/or controlling
particular logic modules
as server services on behalf of the supervisor unit.
[0020] The test modules may comprise logic to store in nonvolatile memory one
or more reference
patterns for use by the logic modules. Commands from the supervisor unit to
the test units to
control certain logic modules (e.g. for macroblocking, for SNR) may solely use
the reference
pattern (e.g. HSL reading), or the test unit may use a combination of the test
patterns stored in
nonvolatile memory and the reference pattern(s) being used as the source
signal to verify the
multimedia device presents no video related issues (e.g macroblocking, SNR).
[0021] FIG. 1 is a block diagram illustration of an embodiment of a test
system. A supervisor unit
102 comprises logic to communicate commands to a plurality of test units 104-
106. Each test
unit 104-106 responds to the commands by performing certain tests on a unit
under test (LTJT)
108-110.
CA 02740662 2011-05-19
Page 4
[0022] Each test unit 104-106 operates under remote control of the supervisor
unit 102, and also
operates somewhat autonomously. Described herein is a unique combination of
remote control
and autonomous operation for particular test procedures, including optical
character recognition
(OCR), signal to noise ratio (SNR), random noise measurement, audio quality,
and video
quality (e.g. macroblocking).
[0023] FIG. 2 is a block diagram illustration of an embodiment of a test unit.
The test unit 202
comprises a plurality of logic modules 204-209, including logic modules to
perform an OCR
test 204, SNR test 205, macro blocking test 206, random noise test 207, unit
under test setup
208, and also potentially other tests and procedures 209.
[0024] The test unit 202 further comprises server logic 211 which enables the
logic modules 204-
209 to be controlled as server processes via a client-server communication
mechanism.
[0025] One embodiment of commands to control the various logic modules is
provided in Table I.
The following parameters are common to several of the commands:
[0026] handler a reference to the logic module to which the command is
directed.
[0027] SKT - Socket number, indicates which of a plurality of logic boards to
direct the OCR
command to (SKT = 1,2,3 etc.).
[0028] STBType - an identifier of the type of the unit under test (e. g.
make/model, series number,
firmware/software revision number, etc.).
[0029] IRCmds - infra red commands (OEM dependant) directed to the unit under
test to set its
state and/or control its behavior for testing purposes.
Command Description Parameters
oemOCR (handler, SKT, STBType, Commands the OCR pageNo - A self -
PageNo, IRCmds, res) logic that converts a diagnostic menu the device
video frame or image under test provides with
into an ASCII text file, information in regards to
This function call its statuses, provisioning
instructs the OCR and code download object
logic to get an area of a that can be analyzed
frame, or a ROt through OCR via logic
(Region of Interest) on modules.
video a output of the
CA 02740662 2011-05-19
Page 5
set-top box. and res - res is a memory
converts it to text. location where results of
Once the text is conversion are stored. The
obtained, the OCR contents of res are
logic may determine formatted as ASCII text.
whether an identified
set of characters is
present in the text.
DbRFct (handler, SKT. STBType, chI, Commands the signal- chl - identifies the
channel
outSNRI, outHSLI, ch2, outSNR2, to-noise ratio test logic that is played on
the primary
outHSL2) based on monitoring tuner of the unit under test.
the maximum and The content on chl may be
minimum values of a recorded and analyzed.
video signal during a outSNRI -the value
time window. The obtained by calculation of
parameters of different the Signal to Noise Ratio on
test patterns are stored the content on channel chl.
into logic (e.g. an This value is passed back to
FPGA) of the test unit. the caller.
outHSL 1 - Hue, Saturation
and Luma values obtained
from the content on chl.
ch2 - identities the channel
that is played on the
secondary tuner of the unit
under test. The secondary
channel ch2 is exercised to
stress the unit under test
during the recording of the
CA 02740662 2011-05-19
Page 6
content on ch 1 (the primary
channel).
outSNR2 -the calculation of
the Signal to Noise Ratio for
the secondary channel.
outHSL2 - Hue, Saturation
and Luma obtained from the
content from the secondary
channel.
AudTest (handler, SKT, STBType, Commands the audio anCh -the channel used for
anCh, digCh, audType, IRcmds, res) test logic to verify the analog audio
verification.
quality of the unit The channel has a defined
under test analog and (expected) amplitude and
digital audio outputs. frequency.
The unit under test is digCh - the channel to use
to be set on a defined for digital audio
test pattern, verification. This channel
comprising an audio has a defined (expected)
tone with a known amplitude and frequency.
frequency and audType -indicates the type
amplitude. The audio of the output being
from the unit under test evaluated. The test module
is demodulated and configures its hardware to
output to the test unit. decode an analog signal as
well as digital audio such as
PCM and Dolby 5.1 format.
res - return value, equal to
zero when no errors were
found in the audio signal
tested.
CA 02740662 2011-05-19
Page 7
MacroTest (handler, SKT. STBType, Commands the macro pattern -the pattern to
use as
pattern, ch, res) block test logic. A a reference. Each test
stream of deo frames pattern has unique number -
vi
are compared against a 1,2,' )..etc. Different types of
reference frame in real unit under test require
time. Excessive macro specific reference test
blocking in the stream patterns. The pattern itself
indicates faulty video may be stored by the test
codec logic in the unit unit.
under test. ch -channel to tune for the
video stream to test . The
channel may vary
depending on the type of
unit under test.
res -a memory location
where results of testing are
stored. A value of zero
indicates no errors where
found. If there were frames
with excessive macroblocks
this value indicates the
number of defective frames
detected during the test
time.
Pretest (handler, SKT, STBType, defCh) Commands logic to set defCh -used as a
reference
up menus of the unit for some types of unit under
under test and perform test. Depending on the
other pretesting. configuration of the unit
under test, after
initialization the unit
displays the default
CA 02740662 2011-05-19
Pagej8
configuration (e.g. specific
channel) and statuses that
indicates the unit is ready
for testing.
VideoTest (handler, SKT, STBType, 1. Configure the remCh - the channel to tune
remCh, pattern, videoType, ch, res) input to be analyzed by for the video
test. For many
the test module. types of devices under test,
2 Grab the frame this will be channel 3 or 4.
or sets of frames for pattern - this parameter is
evaluation passed when a golden
3. Video analysis pattern is needed in order to
with the test module to define which values and
determine quality of lines to extract from the
the frame(s) video frame. It might not be
4. For testing required when the feed is a
colors space accuracy live video sample.
the color bars pattern videoType - indicates the
applied to UUT and type of video output from
then firmware related which to sample the video
algorithm samples frames. Some values are
video signals from baseband, rf output, high
different lines (up to 8) definition component, or
and for each color bar. HDMI signal.
Then the algorithm ch - Specific channel the
calculates average device under test is locked
values of video to before performing audio
samples for each color and video analysis. Test
bar, reconstructs RGB patterns or a specific live
values and then video is being displayed on
calculates HSL values. the various outputs of the
5. PSNR. The device under test and then
CA 02740662 2011-05-19
Page 9
ratio between the the signal is decoded by the
maximum power of the test module.
signal and the power of res - when res is equal to
the noise can be zero it indicates no errors
obtained by the test where found during the call.
module calculation If there was a system error
representing the degree or a failure on the unit, an
of quality of the video error code may be used to
frame obtained troubleshoot or fail a bad
unit.
[0030] FIG 3 illustrates an embodiment of a novel automated test system for
end-user devices.
Inputs to a unit under test (UUT) are received at a pluggable interface module
302, which adapts
and positions the signals to be received by the UUT 304. The interface module
302 comprises
inputs to and outputs from the UUT 304.
[003 1] A multi-media format board 306 (MMFB) may be configured with logic
that is downloaded
and installed on the board 306, making it a programmable multi-media format
board (PN1FB). This
may enable use of a single PMFB with multiple makes and models of UUT. The
PMFB 306 may
be configured to provide all of the inputs that the UUT 304 receives, and to
receive all outputs of
interest for testing from the UUT 304. In this manner, it may be possible to
simply disengage a
particular UUT from the interface module 302, and plug in a new UUT, without
manually
removing or installing any cabling or connections to the UUT 304 or PMFB 306.
A daughter board
322 may be employed to couple the PMFB 306 the interface module 302.
[0032] The daughter board 322 may comprise an identification (e.g. an assembly
part number) that
corresponds to the supported model. This identification may be coded into a
non-volatile memory
of the daughter board 322. The PNIFB 306 may be adapted to automatically
detect the make and
model of a UUT 304 coupled thereto by interacting with the UUT 304 and/or with
the daughter
board 322, and may download and/or activate appropriate logic (e.g. from the
test/analysis logic
308) to interact with and facilitate the testing of the UUT 304. Upon
detecting the make and model
of a UUT 304, the PMFB 306 may inform the supervisor logic 308 of this
information, so that the
supervisor logic 308 may select appropriate test and analysis logic for the
UUT 304. Logic of the
CA 02740662 2011-05-19
Page 10
test system may provide for parallel processing, such that each UUT 304 may be
tested
independently and concurrently. Multi-threading may be employed to accomplish
this.
[0033] The PM1FB 306 may convert outputs of the LFUT 304 to a binary format
suitable for
processing and analysis. Each PMFB 306 may have associated test logic modules
and may output
results in parallel to shared supervisor logic 308. Outputs of the PMFB 306 to
supervisor logic 308
may be provided in some embodiments via universal serial bus (USB), Ethernet,
wireless, or other
transport method. The pluggable interface module 302 may be adapted to fit,
e.g. slot into, a
retainer 310. The interface module 302 is interchangeable and may be specific
to a make and model
of UUT 304, whereas the retainer 310 may comprise a universal configuration
(inputs and outputs)
common among all makes and models of UUT 304. A slide rack 312 driven by a
lever 314, crank,
or other mechanism may be provided for loading the UUT 304 and for
mechanically engaging it
with the interface module 302 via operation of the lever 314 or other control
The lever 314 or other
control may likewise be employed to disengage the UUT 304 from the interface
module 302, at
which point the UUT 304 and/or the modular interface 302 may be removed and
replaced with
another UUT 304 andior interface module 302. The pluggable interface may
include an
identification in non-volatile memory of a number of times it has been
interfaced (e.g. plugged
into) units under test.
[0034] The PMFB 306 may comprise logic for the decoding and reformatting of
various media
formats. The format logic may also support S/PDIF and/or coaxial/optical audio
formats, to name
just some examples. Logic to decode different media formats may be downloaded
by the PMFB
306 in some embodiments. Thus, a single PMFB 306 may be employed with various
UUTs that
operate upon or output various media formats.
[0035] Polling, control, initialization, and configuration signals provided by
the service provider
(e.g., a cable television network operator, an Internet Service Provider,
etc.) to the UUT are
provided via a source signal selector 316. The source signal selector 316 may
choose from among
multiple available service provider sources and direct signals from the chosen
source to the
interface module 302 (note that the signals from the chosen source may in some
implementations
be directed to the retainer 310, which may comprise inputs and outputs common
to all makes and
models of UUT 304. For example, the source signal selector 316 may choose
signals from a
particular headend of a cable television provider, depending upon the
make/model of the UUT 304.
The source signal selector 316 may choose signals from different service
providers depending on
CA 02740662 2011-05-19
Page I l
the type of UUT (e.g. set top box, game console, etc.). The source signal
selector 316 may
comprise a configurable RF attenuation control to stress the RF input of the
unit under test. This
may be employed to detect anomalies on units failing when the RF level is
below certain threshold
levels.
[0036] A carousel server (OLL, e.g. a Motorola Offline Loader, not shown in
drawings) may be
employed to load code objects on various set-top boxes. Deploying an OLL may
increase the
throughput of loading desired code objects independent from a service provider
source. The signal
selector 316 may be used in conjunction with the OLL to help prepare the set-
top boxes with
specific code objects.
[0037] The supervisor 308 may determine the make and/or model of the UUT 304.
If the
supervisor 308 makes this determination. it may in some embodiments
communicate the
make/model information to the PMFB 306 to direct the source signal selector
316 to select a
particular source. Media signals may be provided via a tunable RF channel from
a local source 318,
instead of from the provider network. The local source need not be `local" to
the test system, but
may be any source other than the service provider network. The local media
test signals may be
substituted for signals from the provider network (e.g. the provider signals
may be filtered out and
replaced), or the local signals may supplement the polling, control,
initialization, and configuration
signals normally provided by the service provider.
[0038] The source 318 of the local media test signals may be a separate server
for this purpose. In
some embodiments, the media test signals may be selected according to the make
and/or model of
the UUT 304. The system may include logic to apply the media test signals to
the UUT via a same
physical medium as service provider configuration signals are applied to the
UUT. This logic may
be comprised by the source signal selector 316, the pluggable interface module
302, the media
format board 306, or some other device (e.g. an RF coupler in the signal
path).
[0039] Control signals that drive features of the UUT 304 may be provided, for
example by an IR
port and/or USB from the PMFB 306. PCI or SPI control and data exchange may
also be employed
to interact with the UUT 304. The PMVIFB 306 may operate as a frame grabber
which captures one
or more frames output by the UUT 304 , buffers the captured frame(s), tests
the frames, and
transfers results to the supervisor logic 308, for example via a USB
interface.
[0040] Logic to capture and process new/updated or different media formats, or
to interact with
new/different makes and models of UUT 304, may be dynamically loaded to the
PMFB 306 by the
CA 02740662 2011-05-19
Page 12
supervisor logic 308 or another device. Dynamic loading of logic to the PMFB
306 may be based
upon a determination of the make and/or model number of the L,ZIT 304.
[0041] A test platform employing features of the described test system
embodiment(s) may be
arranged in horizontal, vertical, and/or grid configurations, to name some of
the possibilities.
Implementations and Alternatives
[0042] Those having skill in the art will appreciate that there are various
logic implementations by
which processes and/or systems described herein can be effected (e.g..
hardware, software, and/or
firmware), and that the preferred vehicle will vary with the context in which
the processes are
deployed. "Software" refers to logic that may be readily readapted to
different purposes (e.g.
read/write volatile or nonvolatile memory or media). "Firmware" refers to
logic embodied in read-
only memories and/or media. Hardware refers to logic embodied in analog and/or
digital circuits. If
an implementer determines that speed and accuracy are paramount, the
implementer may opt for a
hardware and/or firmware vehicle; alternatively, if flexibility is paramount,
the implementer may
opt for a solely software implementation; or, yet again alternatively, the
implementer may opt for
some combination of hardware, software, and/or firmware. Hence, there are
several possible
vehicles by which the processes described herein may be effected, none of
which is inherently
superior to the other in that any vehicle to be utilized is a choice dependent
upon the context in
which the vehicle will be deployed and the specific concerns (e.g., speed,
flexibility, or
predictability) of the implementer, any of which may vary. Those skilled in
the art will recognize
that optical aspects of implementations may involve optically-oriented
hardware, software, and or
firmware.
[0043] The foregoing detailed description has set forth various embodiments of
the devices and/or
processes via the use of block diagrams, flowcharts, and/or examples. Insofar
as such block
diagrams, flowcharts, and; or examples contain one or more functions and/or
operations, it will be
understood as notorious by those within the art that each function and/or
operation within such
block diagrams, flowcharts, or examples can be implemented. individually
and/or collectively, by a
wide range of hardware, software, firmware, or virtually any combination
thereof. Several portions
of the subject matter described herein may be implemented via Application
Specific Integrated
Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal
processors (DSPs), or
other integrated formats. However, those skilled in the art will recognize
that some aspects of the
CA 02740662 2011-05-19
Page 13
embodiments disclosed herein, in whole or in part, can be equivalently
implemented in standard
integrated circuits, as one or more computer programs running on one or more
computers (e.g., as
one or more programs running on one or more computer systems), as one or more
programs
running on one or more processors (e.g., as one or more programs running on
one or more
microprocessors), as firmware, or as virtually any combination thereof, and
that designing the
circuitry and/or writing the code for the software and/or firmware would be
well within the skill of
one of skill in the art in light of this disclosure. In addition, those
skilled in the art will appreciate
that the mechanisms of the subject matter described herein are capable of
being distributed as a
program product in a variety of forms, and that an illustrative embodiment of
the subject matter
described herein applies equally regardless of the particular type of signal
bearing media used to
actually carry out the distribution. Examples of a signal bearing media
include, but are not limited
to, the following: recordable type media such as floppy disks, hard disk
drives, CD ROMs, digital
tape, and computer memory, and transmission type media such as digital and
analog
communication links using TDM or IP based communication links (e.g., packet
links).
[0044] In a general sense, those skilled in the art will recognize that the
various aspects described
herein which can be implemented, individually and/or collectively, by a wide
range of hardware,
software, firmware, or any combination thereof can be viewed as being composed
of various types
of "electrical circuitry." Consequently, as used herein "electrical circuitry"
includes, but is not
limited to, electrical circuitry having at least one discrete electrical
circuit, electrical circuitry
having at least one integrated circuit, electrical circuitry having at least
one application specific
integrated circuit, electrical circuitry forming a general purpose computing
device configured by a
computer program (e.g., a general purpose computer configured by a computer
program which at
least partially carries out processes and/or devices described herein, or a
microprocessor configured
by a computer program which at least partially carries out processes and/or
devices described
herein), electrical circuitry forming a memory device (e.g., forms of random
access memory),
and/or electrical circuitry forming a communications device (e.g., a modem,
communications
switch, or optical-electrical equipment).
[0045] Those skilled in the art will recognize that it is common within the
art to describe devices
and/or processes in the fashion set forth herein, and thereafter use standard
engineering practices to
integrate such described devices and/or processes into larger systems. That
is, at least a portion of
CA 02740662 2011-05-19
Page 14
the devices and/or processes described herein can be integrated into a network
processing system
via a reasonable amount of experimentation.
[0046] The foregoing described aspects depict different components contained
within, or connected
with, different other components. It is to be understood that such depicted
architectures are merely
exemplary, and that in fact many other architectures can be implemented which
achieve the same
functionality. In a conceptual sense, any arrangement of components to achieve
the same
functionality is effectively "associated" such that the desired functionality
is achieved. Hence, any
two components herein combined to achieve a particular functionality can be
seen as "associated
with" each other such that the desired functionality is achieved, irrespective
of architectures or
intermedial components. Likewise, any two components so associated can also be
viewed as being
"operably connected", or "operably coupled", to each other to achieve the
desired functionality.
