On 03/11/2014 03:30 PM, David Halls wrote:
> Thanks Martin, this is clear and makes sense. I should have read the
> numpy data types more thoroughly and worked it out. Anyway...
>
> My collaborators are writing their Wireless Network Coding bits in
> Python. Once I get this block working, I can combined it with the relay
> work I was doing and we will have a pretty exciting setup to report!! :)
That is very interesting to hear -- I hope you'll be publishing some
papers and code around network coding!
> I have one more problem though...
>
> I have
>
> "out_bA1 = output_items[0]
>
> ...
> ...code
> ...
>
> out_bA1[0:len(est_bA1m)] = est_bA1m"
>
> where
>
> out_bA1.shape = (1,)
> est_bA1m.shape = (3840,)
>
> I get the error " output operand requires a reduction, but reduction is
> not enabled"
>
> *Sometimes* I get
>
> out_bA1.shape = (2,)
> est_bA1m.shape = (3840,)
>
> and I get the error "operands could not be broadcast together with
> shapes (2) (3840)"
>
> I wondered if the problem is with 'forecast' (which I have not changed
> since the template was created by gr_modtool) or having to
> set_output_multiple? The scheduling aspect of GNU radio seems complex.
This is a Python error, basically it's saying that the arrays have the
wrong shapes.
Note that in your example, out_bA1 has a limited size before you do any
assigning. Make sure you stay within valid index ranges.
If you want to do it very fool-proof (albeit ugly), try:
for i in range(len(out_bA1)):
out_bA1[i] = # whatever
if i (matches whatever condition):
break
> If I use
>
> " out_bA1 = est_bA1m"
>
> Then it *runs* OK, but the output of the block i.e. output_items[0] is
> then no longer altered and 0's are output.
That's because you're rebinding out_bA1, and the original buffer is not
written to.
MB
>
> Many thanks,
>
> David
>
>
> -----Original Message-----
> From: discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org
> <mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org>
> [mailto:discuss-gnuradio-bounces+david.halls=toshiba-trel....@gnu.org]
> On Behalf Of Martin Braun
> Sent: 11 March 2014 08:33
> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
> Subject: Re: [Discuss-gnuradio] Python block, itemsize mismatch
>
> On 03/11/2014 02:06 AM, David Halls wrote:
>> You're a genius! It works.
>>
>> Interestingly for a float it requires numpy.float32 or a similar error
>> occurs.
>
> Yes, in GNU Radio we consistently use 32-bit floats. A complex value
> consists of two of these, hence the 64 bits.
>
> Note that this is just for buffers. A lot of blocks use double
> internally (i.e. 64-bit float, or 128-bit complex) for accuracy reason.
> However, for signals, it's just a waste of bandwidth (most of time, SNR
> will trump quantization noise anyway).
>
> M
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ________________________________
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl
> <http://www.toshiba.eu/research/trl>
>
>
> ------------------------------------------------------------------------
> This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.com
> ------------------------------------------------------------------------
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
