Qa_atsc.py type question

GNU Radio
1

Hello everyone,

I have a question regarding a few lines in qa_atsc.py .

In test_loopback_000, we have:
src = vector_source_ts(src_data)
rand = atsc.randomizer()
and skipping a few lines:
self.tb.connect(src, rand, derand, dst)

The definition of vector_source_ts:

class vector_source_ts(gr.hier_block2):
“”"
MPEG Transport stream source for testing.
“”"
def init(self, ts):
“”"
Pad tranport stream packets to 256 bytes and reformat
appropriately.

    @param ts: MPEG transport stream.
    @type  ts: sequence of ints in [0,255]; len(ts) % 188 == 0
    """

    src = gr.vector_source_b(pad_transport_stream(ts))
    s2v = gr.stream_to_vector(gr.sizeof_char,

atsc.sizeof_atsc_mpeg_packet)

gr.hier_block2.init(self, “vector_source_ts”,
gr.io_signature(0, 0, 0),
s2v.output_signature())
self.connect(src, s2v, self)

=================================
It is clear that in “src = vector_source_ts(src_data)”,
src_data is a tuple of integers, and src is a gnuradio_vector datatype
with elements guradio_characters and each vector length is
atsc.sizeof_atsc_mpeg_packet

That is, “src = vector_source_ts(src_data)” does not create any
atsc_mpeg_packet type data, as required by atsc_randomizer.

In other words, I am claiming that in test_loopback_000() of qa_atsc.py,
the input to atsc.randomizer() is not atsc_mpeg_packet, but rather a
gnuradio_vector data type. Notice that no special atsc.pad() is being
run
(which converts a gnuradio_vector/stream(?) into an atsc_mpeg_packet).

I originally believed some casting was being done, but atsc_mpeg_packet
is
not easy to convert to and fro, it contains numerous data arrays, and
variables.

Can someone please explain the input/output datatypes in
test_loopback_000() in qa_atsc.py?

Thanks very much,
Jonathan

2

On Sat, Jul 31, 2010 at 06:35:18PM -0400, Jonathan wrote:

The definition of vector_source_ts:
@type ts: sequence of ints in [0,255]; len(ts) % 188 == 0

=================================
It is clear that in “src = vector_source_ts(src_data)”,
src_data is a tuple of integers, and src is a gnuradio_vector datatype
with elements guradio_characters and each vector length is
atsc.sizeof_atsc_mpeg_packet

That is, “src = vector_source_ts(src_data)” does not create any
atsc_mpeg_packet type data, as required by atsc_randomizer.

The runtime only checks that the datatypes have the same size. Since
the blocks’ work methods cast their input and output buffers from (void
*)
to the type that they require, everything works out OK.

Eric

3

The runtime only checks that the datatypes have the same size. Since
the blocks’ work methods cast their input and output buffers from (void *)
to the type that they require, everything works out OK.

Eric

Eric, and others,

All the below refers to qa_atsc.py, function test_loopback_000.
I realized casting is involved. I do believe we are walking on a very
dangerous and tight rope because we are casting from an unsigned char
array to a class containing unsigned char array and other datatypes.
It
just so happens that the unsigned char array overlaps - this might not
always happen.

Finally, at the end of test_loopback_000, another casting is involved,
this one is even riskier than the first. It casts from a class to a
unsigned char array.

What I’m trying to say is perhaps qa_atsc.py should use atsc.pad and
atsc.depad, which are blocks specifically designed to convert unsigned
char arrays (from vector_source/sink) to and fro mpeg_atsc class
objects.

Jonathan Shan