Actually I have to test it in a interference limited environment, I guess
the soft demodulate will be needed. I saw your blog post about how you
cleverly used your won constellations https://www.bastibl.net/constellation-
objects/
However when I try doing something like that, I get errors.
For example, I defined my own function decision_maker_soft inside
constellations_impl.h as follows
class constellation_bpsk_impl : public constellation_bpsk
{
public:
constellation_bpsk_impl();
~constellation_bpsk_impl();
unsigned int decision_maker(const gr_complex *sample);
*float decision_maker_soft(const gr_complex *sample);*
};
and then defined it in constellation_impl.cc as
float
constellation_bpsk_impl::decision_maker_soft(const gr_complex *sample) {
return (-4*real(*sample));
}
But when I call my function like this
mod->decision_maker_soft from ls.cc (least square equalizer cc file), it
says mod object has no member decision_maker_soft
Why does *mod* object not look my decision_maker_soft as it is a method of
constellation_bpsk_impl ??
What am I missing here ?
I thought that mod object is looking your decision_maker inside
constellations_impl, it shud see mine too...
On 18 January 2018 at 15:22, Bastian Bloessl <[email protected]> wrote:
> I'm not sure if I understand you correctly, but you have to differentiate
> what performance you mean. IT++ might have better decoding performance
> (since it's using soft-bits), but the SIMD implementation has better
> computational performance (i.e., needs less CPU).
>
> To be honest, I didn't do a lot of testing between IT++ and the current
> version. (I think I've seen a paper that compared soft-bits vs. hard-bits
> and there was a 2-3dB improvement, but you have to check). Since the
> decoder was a CPU bottleneck, I was more than happy to merge the SIMD
> implementation, which was developed by Gonzalo Arcos based on the gr-dtv
> decoder. See here
>
> http://www.ccs-labs.org/bib/arcos2016accelerating/
>
> Best,
> Bastian
>
> On 1/18/2018 13:41, sumit kumar wrote:
>
>> Thanks for confirming. I believe that IT++ version will work with
>> corresponding GNU Radio version.
>>
>> Also what do you think (since you have developed the code for long time
>> :) ) : IT++ version will be as efficient as the current one? I mean the
>> current version uses SIMD for Viterbi.
>> I have tested the current version for success rate. I can share the
>> results(attached). Success rate mentioned is nothing but ratio of received
>> to transmitted frame per second using a R&H VSG. The test was done over the
>> air.
>>
>>
>>
>> On 18 January 2018 at 13:06, Bastian Bloessl <[email protected] <mailto:
>> [email protected]>> wrote:
>>
>> Hi,
>>
>> you are right. The current implementation does not use soft-bits but
>> feeds hard bits into the decoder.
>>
>> In 2013, I used the soft-input Viterbi decoder from the IT++ library.
>>
>> http://itpp.sourceforge.net/4.3.1/convcode.html
>> <http://itpp.sourceforge.net/4.3.1/convcode.html>
>>
>> Best,
>> Bastian
>>
>> On 01/17/2018 11:36 AM, sumit kumar wrote:
>>
>> Hi,
>>
>> I am doing some proof of concept using gr-ieee 802.11.
>> The paper by author [1] says that it uses softbits, however in
>> the method
>>
>> *constellation::decision_maker(const gr_complex *sample)*, I see
>> outputs as hardbits.
>> Am I missing something here i.e. any particular commit or branch
>> where the softbits implementation is there.
>>
>> Its very important for my algorithm to use softbits :-/
>>
>> [1]
>> https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf
>> <https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf>
>>
>> Sumit
>>
>>
>>
>>
>> --
>> Sumit Kumar
>>
>>
>>
--
Sumit Kumar
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
