On Fri, Jun 27, 2014 at 11:24 PM, Hoang Ngo Khac <hoangnk...@vnu.edu.vn>
wrote:
> Thank you Tom.
> I've modified the Decode CCSDS 27. In particular, I changed the code in
> implementation file (.cc):
>
> Existing code:
>
>> const float *in = (const float *)input_items[0];
>> unsigned char *out = (unsigned char *)output_items[0];
>>
>> for (int i = 0; i < noutput_items*16; i++) {
>> // Translate and clip [-1.0..1.0] to [28..228]
>> float sample = in[i]*100.0+128.0;
>> if (sample > 255.0)
>> sample = 255.0;
>> else if (sample < 0.0)
>> sample = 0.0;
>> unsigned char sym = (unsigned char)(floor(sample));
>>
>> d_viterbi_in[d_count % 4] = sym;
>> if ((d_count % 4) == 3) {
>> // Every fourth symbol, perform butterfly operation
>> viterbi_butterfly2(d_viterbi_in, d_mettab, d_state0, d_state1);
>>
>> // Every sixteenth symbol, read out a byte
>> if (d_count % 16 == 11) {
>> // long metric =
>> viterbi_get_output(d_state0, out++);
>> // printf("%li\n", *(out-1), metric);
>> }
>> }
>>
>> d_count++;
>> }
>>
> My code:
>
>> unsigned char *in = (unsigned char *)input_items[0];
>> unsigned char *out = (unsigned char *)output_items[0];
>>
>>
>> int ni = 0;
>>
>> unsigned char byte = 0x0;
>>
>> while (ni < noutput_items*16)
>> {
>> byte = in[ni];
>> d_viterbi_in[d_count % 4] = byte;
>> if ((d_count % 4) == 3) {
>> // Every fourth symbol, perform butterfly operation
>> viterbi_butterfly2(d_viterbi_in, d_mettab, d_state0, d_state1);
>>
>> // Every sixteenth symbol, read out a byte
>> if (d_count % 16 == 11) {
>> // long metric =
>> viterbi_get_output(d_state0, out++);
>> // printf("%li\n", *(out-1), metric);
>> }
>> }
>>
> ni ++;
>> d_count++;
>> }
>>
>
> I also modify the header file, xml file. Now the new block appear in GRC.
> I build a flow graph (see in attachment) to test this block. When I run
> this flowgraph, I got this error:
>
> init::console_sink_bb
> Traceback (most recent call last):
> File "/home/khachoang/GNU_Radio/Test GRC/top_block.py", line 58, in
> <module>
> tb = top_block()
> File "/home/khachoang/GNU_Radio/Test GRC/top_block.py", line 43, in
> __init__
> self.connect((self.fec_encode_ccsds_27_bb_0, 0),
> (self.fec_decode_ccsds_27_bb_0, 0))
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 130, in connect
> self._connect(points[i-1], points[i])
> File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
> line 142, in _connect
> dst_block.to_basic_block(), dst_port)
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
> 4100, in primitive_connect
> return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
>
>
> *ValueError: itemsize mismatch: encode_ccsds_27_bb0:0 using 1,
> decode_ccsds_27_bb0:0 using 4*
> Is my code correct? How could I fix this bug?
>
> Thanks
> *,*
> Hoang
>
First, I'd say in the long run, you're still better off looking into the
FEC API. Right now, you'll have to build the new manual yourself as we
don't have it published yet online, but the Forward Error Correction
section in the new manual explains how you could build a deployment to use
the FEC codes you need. Then, you wouldn't have to have a patch on an
existing block.
That having been said, the FEC API is brand new, so there's not much more
help or examples than what's in the manual and in the code right now. So we
should at least be able to get you going with where you are now.
Most likely, the problem is in the constructor of the block you're editing.
Look for the io_signature line. You'll see a 'sizeof(float)' there. Change
that to 'sizeof(char)' and that should work for you.
Tom
> On Wed, Jun 25, 2014 at 8:55 PM, Tom Rondeau <t...@trondeau.com> wrote:
>
>> On Wed, Jun 25, 2014 at 5:27 AM, Hoang Ngo Khac <hoangnk...@vnu.edu.vn>
>> wrote:
>>
>>> Thank you Marcus.
>>>
>>> I've checked out gr-fec. The problem is that Decode CCSDS 27 block takes
>>> float input while my data to feed it is in byte.
>>>
>>
>> If you've built the documentation of the latest version of GNU Radio,
>> look at the Forward Error Correction page for a description of the new FEC
>> API. It's designed with exactly your issue in mind. You would write a new
>> deployment for the FEC of your choice to handle the data type conversions.
>> In fact, the current CC decoder actually takes in bytes but the deployment
>> takes in floats. The floats are intended to be soft symbols, and the
>> decoder deployment converts from the soft symbol floats to a quantized soft
>> symbol byte that floats at a particular level.
>>
>> Tom
>>
>>
>>
>>> On Wed, Jun 25, 2014 at 3:23 PM, Marcus Müller <marcus.muel...@ettus.com
>>> > wrote:
>>>
>>>> Hi Hoang,
>>>>
>>>> GNU Radio 3.7 has the gr-fec framework, and recent updates brought more
>>>> performance and some features, so if that matches your use case, go ahead
>>>> and try it out!
>>>>
>>>> Greetings,
>>>> Marcus
>>>>
>>>>
>>>> On 25.06.2014 09:54, Hoang Ngo Khac wrote:
>>>>
>>>> Deal all,
>>>>
>>>> Does anyone update the Channel Coding
>>>> (https://www.cgran.org/wiki/chancoding)
>>>> toolbox so that it can work in Gnuradio 3.7.0?
>>>>
>>>> I did try to install this toolbox. The installation was done but it do not
>>>> appear in Gnuradio Companion interface.
>>>>
>>>> Thanks,
>>>> Hoang
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing
>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
