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
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
