Hello,
I just wanted to share some trouble I had trying to create a pmt uniform
c32 vector in python, what I found as the fix, and hope to get some insight
as to why things are this way.
Here's an entry from my notes:
THIS CREATES A VECTOR, BUT NOT A UNIFORM OR C32 VECTOR:
testv = pmt.to_pmt([complex(1.0), complex(-1.0)]*50)
pmt.is_vector(testv) # True
pmt.is_uniform_vector(testv) # False
pmt.is_c32vector(testv) # False
THIS FAILS:
testv1 = pmt.make_c32vector(100, [complex(1.0), complex(-1.0)]*50)
THIS SUCCEEDS, but is a PITA:
testv1 = pmt.make_c32vector(100, complex(-1.0))
for i in range(pmt.length(testv)):
if i%2 == 0:
pmt.c32vector_set(testv, i, complex(1.0))
THIS IS THE CORRECT WAY TO DO IT:
testv2 = pmt.init_c32vector(100, [complex(1.0), complex(-1.0)]*50)
(SEE:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-04/msg00292.html )
So, it took me quite a while to figure this out. Why does
pmt.to_pmt(<python list of complex numbers>) return a vector, but fails
when tested under pmt.is_uniform_vector() or any pmt.is_XXXvector() (i.e.
c32 for XXX)?
Anyway, I'll just use pmt.init_c32vector(). I'm trying to create a data
payoad for a PDU to send from my custom block to a PDU to tagged stream
block such that large packets of samples
(tens-of-thousands-of-generated-samples) can be sent out with reliable
timing. I first looked into controlling a USRP sink with asynchronous
commands, but from what I read, that method has some variability on the
order of microseconds (which is still awesome, but I think it might not
work well enough). I'm probably going about this all wrong, but it's a
learning process, so let me know if there's a glaringly obvious method that
I'm overlooking. I first looked into eventstream, as described by the
oshearesearch website, but I think that's a bit too far into the deep end
for a beginner like myself so far.
- Richard
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
