Qa_atsc.py type question

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

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

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs