Re: [Discuss-gnuradio] constellation soft decoder
Thanks. Miklos On Tue, Dec 17, 2013 at 3:45 PM, Martin Braun wrote: > On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti > wrote: >> >> Can you guys add me to the list of developers (user name: mmaroti)? >> Then I can file the bug report. >> > > In case this wasn't the case, you now have access to the wiki. > > MB > > ___ > 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
Re: [Discuss-gnuradio] constellation soft decoder
On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti wrote: > Can you guys add me to the list of developers (user name: mmaroti)? > Then I can file the bug report. > > In case this wasn't the case, you now have access to the wiki. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] constellation soft decoder
Hi Tom, On Mon, Dec 16, 2013 at 7:27 PM, Tom Rondeau wrote: > On Mon, Dec 16, 2013 at 1:08 PM, Miklos Maroti > wrote: >> Hi Guys, >> >> Ok, I have sent a pull request. >> >> On a related note: I do not understand the scaling performed in the >> constellation constructor. Why are the constellation points scaled to >> have average 1.0 amplitude? It prevents me to do interesting stuff >> with constellations. Why cannot I set the d_scalefactor manually later >> (this is used in calc_soft_dec)? >> >> Miklos > > Miklos, > > You must have overlooked my email. I sent and already applied a patch > for this. I'm going to go ahead and close this bug. Sorry, I did not read then carefully. > The scaling is done to make our slicing easier to perform. It was a > design decision by the original author. I don't understand how this > prevents you from doing "interesting stuff" since it's just a scaling > factor. Unless floating point accuracy is really that big of a deal to > what you want to do. You would have a multiplier block just because your constellation is scaled (and you have to recompute the scaling factor manually just to compensate). > That having been said, we probably don't actually need to impose this > so strictly. We can probably add another argument to the constellation > constructor to pass this value in, default it to 0, and if it's 0, do > the autoscaling we currently do. That would be a nice to have. Miklos > > Tom > > > >> On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti >> wrote: >>> Hi Marcus, >>> Anyway, I think Miklos is right: There is an error in calc_soft_dec in using the pre_diff_code even in the case that it is not set or its application disabled. Miklos, would you be as nice as to file a bug for that? You're the one who successfully diagnosed that. >>> >>> Can you guys add me to the list of developers (user name: mmaroti)? >>> Then I can file the bug report. >>> >>> In the mean time, I might be able to put together a pull request, just >>> fixing the calc_soft_dec code. >>> (You may, btw, simply think of pre_diff_code simply as an index set of the constellation points) >>> >>> I do not understand. It is just an extra permutation of the >>> constellation points. If this is so, then why do you not just permute >>> the constellation points, which makes everything faster. Do you have >>> any use case where simply permuting the constellation vector would not >>> achieve the same result? >>> >>> I also worry about performance. Even for BPSK, QPSK and 8PSK the soft >>> decoding is not optimized, but could be much simpler than the general >>> algorithm. Same goes for QAM, but I have not looked those really >>> closely. >>> >>> Miklos >>> Greetings, Marcus On 16.12.2013 14:29, Philip Balister wrote: > On 12/16/2013 08:16 AM, Miklos Maroti wrote: >> Hi Marcus, >> >> Ok, that makes sense. It does not crash with QPSK, but it does >> with BPSK and 8PSK, and BPSK and 8PSK do not set the >> pre_diff_code. This explains why there is crash in one case and >> not the other. Although neither sets the apply_pre_diff_code, so >> even QPSK should not set pre_diff_code. > > I took a quick look in Coverity for issues in gr-digital. It flags > a bunch of uninitialized variables. I'll try and take a look at > these this week. > > There is an intermittent QA failure in some QA code and this might > be an explanation. > > Philip > >> >> I think the real problem is in constellation::calc_soft_dec. I >> does not check whether d_apply_pre_diff_code is set or not. >> >> (By the way, I do not understand the usefulness of pre_diff_code. >> Can you just permute the constellation points and get the same >> effect?) >> >> Miklos >> >> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller >> wrote: Well, after having a debug build and >> then adding a lot of "volatile"s into the code at the crashing >> function, it looks as if the d_pre_diff_code of the constellation >> has size 0; and thus, you can't access the 0. (read: first) >> element. How this could happen with a QPSK object is currently >> subject to my confusion. Stay tuned for more confusing facts as >> the code unfolds :). >> >> Greetings, Marcus >> >> On 16.12.2013 08:30, Miklos Maroti wrote: > Hi Marcus, > > I do not think it is a compiler bug, but something > uninitialized. Constellation_qpsk and > constellation_calcdist does not crash (I did not verify if > they work). However, if I generate the LUT for > constellation_qpsk, then it crashes. > > # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu > SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 > GNU/Linux > > # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 >>>
Re: [Discuss-gnuradio] constellation soft decoder
On Mon, Dec 16, 2013 at 1:08 PM, Miklos Maroti wrote: > Hi Guys, > > Ok, I have sent a pull request. > > On a related note: I do not understand the scaling performed in the > constellation constructor. Why are the constellation points scaled to > have average 1.0 amplitude? It prevents me to do interesting stuff > with constellations. Why cannot I set the d_scalefactor manually later > (this is used in calc_soft_dec)? > > Miklos Miklos, You must have overlooked my email. I sent and already applied a patch for this. I'm going to go ahead and close this bug. The scaling is done to make our slicing easier to perform. It was a design decision by the original author. I don't understand how this prevents you from doing "interesting stuff" since it's just a scaling factor. Unless floating point accuracy is really that big of a deal to what you want to do. That having been said, we probably don't actually need to impose this so strictly. We can probably add another argument to the constellation constructor to pass this value in, default it to 0, and if it's 0, do the autoscaling we currently do. Tom > On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti > wrote: >> Hi Marcus, >> >>> Anyway, I think Miklos is right: There is an error in calc_soft_dec in >>> using the pre_diff_code even in the case that it is not set or its >>> application disabled. >>> >>> Miklos, would you be as nice as to file a bug for that? You're the one >>> who successfully diagnosed that. >> >> Can you guys add me to the list of developers (user name: mmaroti)? >> Then I can file the bug report. >> >> In the mean time, I might be able to put together a pull request, just >> fixing the calc_soft_dec code. >> >>> (You may, btw, simply think of >>> pre_diff_code simply as an index set of the constellation points) >> >> I do not understand. It is just an extra permutation of the >> constellation points. If this is so, then why do you not just permute >> the constellation points, which makes everything faster. Do you have >> any use case where simply permuting the constellation vector would not >> achieve the same result? >> >> I also worry about performance. Even for BPSK, QPSK and 8PSK the soft >> decoding is not optimized, but could be much simpler than the general >> algorithm. Same goes for QAM, but I have not looked those really >> closely. >> >> Miklos >> >>> >>> Greetings, >>> Marcus >>> >>> On 16.12.2013 14:29, Philip Balister wrote: On 12/16/2013 08:16 AM, Miklos Maroti wrote: > Hi Marcus, > > Ok, that makes sense. It does not crash with QPSK, but it does > with BPSK and 8PSK, and BPSK and 8PSK do not set the > pre_diff_code. This explains why there is crash in one case and > not the other. Although neither sets the apply_pre_diff_code, so > even QPSK should not set pre_diff_code. I took a quick look in Coverity for issues in gr-digital. It flags a bunch of uninitialized variables. I'll try and take a look at these this week. There is an intermittent QA failure in some QA code and this might be an explanation. Philip > > I think the real problem is in constellation::calc_soft_dec. I > does not check whether d_apply_pre_diff_code is set or not. > > (By the way, I do not understand the usefulness of pre_diff_code. > Can you just permute the constellation points and get the same > effect?) > > Miklos > > On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller > wrote: Well, after having a debug build and > then adding a lot of "volatile"s into the code at the crashing > function, it looks as if the d_pre_diff_code of the constellation > has size 0; and thus, you can't access the 0. (read: first) > element. How this could happen with a QPSK object is currently > subject to my confusion. Stay tuned for more confusing facts as > the code unfolds :). > > Greetings, Marcus > > On 16.12.2013 08:30, Miklos Maroti wrote: Hi Marcus, I do not think it is a compiler bug, but something uninitialized. Constellation_qpsk and constellation_calcdist does not crash (I did not verify if they work). However, if I generate the LUT for constellation_qpsk, then it crashes. # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 Using latest master branch of gnuradio, hash 117058bac41c91, both CMAKE_BUILD_TYPE=Debug and Release produces the same behavior # gdb `which python` core Reading symbols from /usr/bin/python2.7...(no debugging symbols found)...done. warning: core file may not match specified executable file. [New LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 224
Re: [Discuss-gnuradio] constellation soft decoder
Hi Guys,
Ok, I have sent a pull request.
On a related note: I do not understand the scaling performed in the
constellation constructor. Why are the constellation points scaled to
have average 1.0 amplitude? It prevents me to do interesting stuff
with constellations. Why cannot I set the d_scalefactor manually later
(this is used in calc_soft_dec)?
Miklos
On Mon, Dec 16, 2013 at 5:18 PM, Miklos Maroti wrote:
> Hi Marcus,
>
>> Anyway, I think Miklos is right: There is an error in calc_soft_dec in
>> using the pre_diff_code even in the case that it is not set or its
>> application disabled.
>>
>> Miklos, would you be as nice as to file a bug for that? You're the one
>> who successfully diagnosed that.
>
> Can you guys add me to the list of developers (user name: mmaroti)?
> Then I can file the bug report.
>
> In the mean time, I might be able to put together a pull request, just
> fixing the calc_soft_dec code.
>
>> (You may, btw, simply think of
>> pre_diff_code simply as an index set of the constellation points)
>
> I do not understand. It is just an extra permutation of the
> constellation points. If this is so, then why do you not just permute
> the constellation points, which makes everything faster. Do you have
> any use case where simply permuting the constellation vector would not
> achieve the same result?
>
> I also worry about performance. Even for BPSK, QPSK and 8PSK the soft
> decoding is not optimized, but could be much simpler than the general
> algorithm. Same goes for QAM, but I have not looked those really
> closely.
>
> Miklos
>
>>
>> Greetings,
>> Marcus
>>
>> On 16.12.2013 14:29, Philip Balister wrote:
>>> On 12/16/2013 08:16 AM, Miklos Maroti wrote:
Hi Marcus,
Ok, that makes sense. It does not crash with QPSK, but it does
with BPSK and 8PSK, and BPSK and 8PSK do not set the
pre_diff_code. This explains why there is crash in one case and
not the other. Although neither sets the apply_pre_diff_code, so
even QPSK should not set pre_diff_code.
>>>
>>> I took a quick look in Coverity for issues in gr-digital. It flags
>>> a bunch of uninitialized variables. I'll try and take a look at
>>> these this week.
>>>
>>> There is an intermittent QA failure in some QA code and this might
>>> be an explanation.
>>>
>>> Philip
>>>
I think the real problem is in constellation::calc_soft_dec. I
does not check whether d_apply_pre_diff_code is set or not.
(By the way, I do not understand the usefulness of pre_diff_code.
Can you just permute the constellation points and get the same
effect?)
Miklos
On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller
wrote: Well, after having a debug build and
then adding a lot of "volatile"s into the code at the crashing
function, it looks as if the d_pre_diff_code of the constellation
has size 0; and thus, you can't access the 0. (read: first)
element. How this could happen with a QPSK object is currently
subject to my confusion. Stay tuned for more confusing facts as
the code unfolds :).
Greetings, Marcus
On 16.12.2013 08:30, Miklos Maroti wrote:
>>> Hi Marcus,
>>>
>>> I do not think it is a compiler bug, but something
>>> uninitialized. Constellation_qpsk and
>>> constellation_calcdist does not crash (I did not verify if
>>> they work). However, if I generate the LUT for
>>> constellation_qpsk, then it crashes.
>>>
>>> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu
>>> SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64
>>> GNU/Linux
>>>
>>> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
>>>
>>> Using latest master branch of gnuradio, hash
>>> 117058bac41c91, both CMAKE_BUILD_TYPE=Debug and Release
>>> produces the same behavior
>>>
>>> # gdb `which python` core Reading symbols from
>>> /usr/bin/python2.7...(no debugging symbols found)...done.
>>>
>>> warning: core file may not match specified executable file.
>>> [New LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248]
>>> [New LWP 2247] [New LWP 2239] [New LWP 2250]
>>>
>>> warning: Can't read pathname for load map: Input/output
>>> error. [Thread debugging using libthread_db enabled] Using
>>> host libthread_db library
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was
>>> generated by `python ./constellation_simulation.py'.
>>> Program terminated with signal 11, Segmentation fault. #0
>>> 0x7f98dbbe01a7 in
>>> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
>>> sample=..., npwr=) at
>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>>
>>>
>>>
>> 286for(int j = 0; j < k; j++) {
>>>
>>> i stack #0 0x7f98dbbe01a7 in
>>> gr::digital::constellation::calc_soft_dec (
>>> this=0x48321c0, sample=..., npwr=) at
>>> /home/mmarot
Re: [Discuss-gnuradio] constellation soft decoder
Hi Marcus,
> Anyway, I think Miklos is right: There is an error in calc_soft_dec in
> using the pre_diff_code even in the case that it is not set or its
> application disabled.
>
> Miklos, would you be as nice as to file a bug for that? You're the one
> who successfully diagnosed that.
Can you guys add me to the list of developers (user name: mmaroti)?
Then I can file the bug report.
In the mean time, I might be able to put together a pull request, just
fixing the calc_soft_dec code.
> (You may, btw, simply think of
> pre_diff_code simply as an index set of the constellation points)
I do not understand. It is just an extra permutation of the
constellation points. If this is so, then why do you not just permute
the constellation points, which makes everything faster. Do you have
any use case where simply permuting the constellation vector would not
achieve the same result?
I also worry about performance. Even for BPSK, QPSK and 8PSK the soft
decoding is not optimized, but could be much simpler than the general
algorithm. Same goes for QAM, but I have not looked those really
closely.
Miklos
>
> Greetings,
> Marcus
>
> On 16.12.2013 14:29, Philip Balister wrote:
>> On 12/16/2013 08:16 AM, Miklos Maroti wrote:
>>> Hi Marcus,
>>>
>>> Ok, that makes sense. It does not crash with QPSK, but it does
>>> with BPSK and 8PSK, and BPSK and 8PSK do not set the
>>> pre_diff_code. This explains why there is crash in one case and
>>> not the other. Although neither sets the apply_pre_diff_code, so
>>> even QPSK should not set pre_diff_code.
>>
>> I took a quick look in Coverity for issues in gr-digital. It flags
>> a bunch of uninitialized variables. I'll try and take a look at
>> these this week.
>>
>> There is an intermittent QA failure in some QA code and this might
>> be an explanation.
>>
>> Philip
>>
>>>
>>> I think the real problem is in constellation::calc_soft_dec. I
>>> does not check whether d_apply_pre_diff_code is set or not.
>>>
>>> (By the way, I do not understand the usefulness of pre_diff_code.
>>> Can you just permute the constellation points and get the same
>>> effect?)
>>>
>>> Miklos
>>>
>>> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller
>>> wrote: Well, after having a debug build and
>>> then adding a lot of "volatile"s into the code at the crashing
>>> function, it looks as if the d_pre_diff_code of the constellation
>>> has size 0; and thus, you can't access the 0. (read: first)
>>> element. How this could happen with a QPSK object is currently
>>> subject to my confusion. Stay tuned for more confusing facts as
>>> the code unfolds :).
>>>
>>> Greetings, Marcus
>>>
>>> On 16.12.2013 08:30, Miklos Maroti wrote:
>> Hi Marcus,
>>
>> I do not think it is a compiler bug, but something
>> uninitialized. Constellation_qpsk and
>> constellation_calcdist does not crash (I did not verify if
>> they work). However, if I generate the LUT for
>> constellation_qpsk, then it crashes.
>>
>> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu
>> SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64
>> GNU/Linux
>>
>> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
>>
>> Using latest master branch of gnuradio, hash
>> 117058bac41c91, both CMAKE_BUILD_TYPE=Debug and Release
>> produces the same behavior
>>
>> # gdb `which python` core Reading symbols from
>> /usr/bin/python2.7...(no debugging symbols found)...done.
>>
>> warning: core file may not match specified executable file.
>> [New LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248]
>> [New LWP 2247] [New LWP 2239] [New LWP 2250]
>>
>> warning: Can't read pathname for load map: Input/output
>> error. [Thread debugging using libthread_db enabled] Using
>> host libthread_db library
>> "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was
>> generated by `python ./constellation_simulation.py'.
>> Program terminated with signal 11, Segmentation fault. #0
>> 0x7f98dbbe01a7 in
>> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
>> sample=..., npwr=) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>
>>
>>>
>>
> 286for(int j = 0; j < k; j++) {
>>
>> i stack #0 0x7f98dbbe01a7 in
>> gr::digital::constellation::calc_soft_dec (
>> this=0x48321c0, sample=..., npwr=) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>
>>
>>>
>>
> #1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
>> this=0x48321c0, sample=...) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
>>
>>
>>>
>>
> #2 0x7f98dbbe94dc in
>> gr::digital::constellation_soft_decoder_cf_impl::work
>> (this=0x4fb11a0, noutput_items=8190, input_items=...,
>> output_items=...) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_d
Re: [Discuss-gnuradio] constellation soft decoder
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Phil, hi Miklos,
as far as I can tell, the default constructor of constellation doesn't
initialize d_pre_diff_code, which is correct (well, kind of correct)
considering that it does not set any constellation points, either.
So I guess both members are initialized with their default
constructor, i.e. empty std::vectors or , respectively.
I don't really know how to elegantly fix this. I don't know if one
should remove the default constructor (and modify the depending
constellation_Xpsk constructors), or if that will break even more
things. Maybe the way to go would be having a method that sets the
constellation and automatically sets the pre_diff_code automatically
with the index range, just to prevent that error. This might however
be wasteful, for larger codes. Maybe one would just add a delegator
that either returns d_pre_diff_code[i] or just i, depending on the
existence of the predifferential codebook.
Anyway, I think Miklos is right: There is an error in calc_soft_dec in
using the pre_diff_code even in the case that it is not set or its
application disabled.
Miklos, would you be as nice as to file a bug for that? You're the one
who successfully diagnosed that. (You may, btw, simply think of
pre_diff_code simply as an index set of the constellation points)
Greetings,
Marcus
On 16.12.2013 14:29, Philip Balister wrote:
> On 12/16/2013 08:16 AM, Miklos Maroti wrote:
>> Hi Marcus,
>>
>> Ok, that makes sense. It does not crash with QPSK, but it does
>> with BPSK and 8PSK, and BPSK and 8PSK do not set the
>> pre_diff_code. This explains why there is crash in one case and
>> not the other. Although neither sets the apply_pre_diff_code, so
>> even QPSK should not set pre_diff_code.
>
> I took a quick look in Coverity for issues in gr-digital. It flags
> a bunch of uninitialized variables. I'll try and take a look at
> these this week.
>
> There is an intermittent QA failure in some QA code and this might
> be an explanation.
>
> Philip
>
>>
>> I think the real problem is in constellation::calc_soft_dec. I
>> does not check whether d_apply_pre_diff_code is set or not.
>>
>> (By the way, I do not understand the usefulness of pre_diff_code.
>> Can you just permute the constellation points and get the same
>> effect?)
>>
>> Miklos
>>
>> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller
>> wrote: Well, after having a debug build and
>> then adding a lot of "volatile"s into the code at the crashing
>> function, it looks as if the d_pre_diff_code of the constellation
>> has size 0; and thus, you can't access the 0. (read: first)
>> element. How this could happen with a QPSK object is currently
>> subject to my confusion. Stay tuned for more confusing facts as
>> the code unfolds :).
>>
>> Greetings, Marcus
>>
>> On 16.12.2013 08:30, Miklos Maroti wrote:
> Hi Marcus,
>
> I do not think it is a compiler bug, but something
> uninitialized. Constellation_qpsk and
> constellation_calcdist does not crash (I did not verify if
> they work). However, if I generate the LUT for
> constellation_qpsk, then it crashes.
>
> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu
> SMP Tue Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64
> GNU/Linux
>
> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
>
> Using latest master branch of gnuradio, hash
> 117058bac41c91, both CMAKE_BUILD_TYPE=Debug and Release
> produces the same behavior
>
> # gdb `which python` core Reading symbols from
> /usr/bin/python2.7...(no debugging symbols found)...done.
>
> warning: core file may not match specified executable file.
> [New LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248]
> [New LWP 2247] [New LWP 2239] [New LWP 2250]
>
> warning: Can't read pathname for load map: Input/output
> error. [Thread debugging using libthread_db enabled] Using
> host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was
> generated by `python ./constellation_simulation.py'.
> Program terminated with signal 11, Segmentation fault. #0
> 0x7f98dbbe01a7 in
> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
> sample=..., npwr=) at
> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>
>
>>
>
286for(int j = 0; j < k; j++) {
>
> i stack #0 0x7f98dbbe01a7 in
> gr::digital::constellation::calc_soft_dec (
> this=0x48321c0, sample=..., npwr=) at
> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>
>
>>
>
#1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
> this=0x48321c0, sample=...) at
> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
>
>
>>
>
#2 0x7f98dbbe94dc in
> gr::digital::constellation_soft_decoder_cf_impl::work
> (this=0x4fb11a0,
Re: [Discuss-gnuradio] constellation soft decoder
On Mon, Dec 16, 2013 at 8:16 AM, Miklos Maroti wrote:
> Hi Marcus,
>
> Ok, that makes sense. It does not crash with QPSK, but it does with
> BPSK and 8PSK, and BPSK and 8PSK do not set the pre_diff_code. This
> explains why there is crash in one case and not the other. Although
> neither sets the apply_pre_diff_code, so even QPSK should not set
> pre_diff_code.
>
> I think the real problem is in constellation::calc_soft_dec. I does
> not check whether d_apply_pre_diff_code is set or not.
>
> (By the way, I do not understand the usefulness of pre_diff_code. Can
> you just permute the constellation points and get the same effect?)
>
> Miklos
Miklos,
Can you try to attached patch? I had made the assumption that
pre_diff_code was always set in the constellation objects.
And yes, the pre_diff_code is essentially a LUT for the permutation.
Tom
> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Well, after having a debug build and then adding a lot of "volatile"s
>> into the code at the crashing function, it looks as if the
>> d_pre_diff_code of the constellation has size 0; and thus, you can't
>> access the 0. (read: first) element. How this could happen with a QPSK
>> object is currently subject to my confusion. Stay tuned for more
>> confusing facts as the code unfolds :).
>>
>> Greetings,
>> Marcus
>>
>> On 16.12.2013 08:30, Miklos Maroti wrote:
>>> Hi Marcus,
>>>
>>> I do not think it is a compiler bug, but something uninitialized.
>>> Constellation_qpsk and constellation_calcdist does not crash (I
>>> did not verify if they work). However, if I generate the LUT for
>>> constellation_qpsk, then it crashes.
>>>
>>> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue
>>> Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
>>>
>>> Using latest master branch of gnuradio, hash 117058bac41c91, both
>>> CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
>>>
>>> # gdb `which python` core Reading symbols from
>>> /usr/bin/python2.7...(no debugging symbols found)...done.
>>>
>>> warning: core file may not match specified executable file. [New
>>> LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248] [New LWP
>>> 2247] [New LWP 2239] [New LWP 2250]
>>>
>>> warning: Can't read pathname for load map: Input/output error.
>>> [Thread debugging using libthread_db enabled] Using host
>>> libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> Core was generated by `python ./constellation_simulation.py'.
>>> Program terminated with signal 11, Segmentation fault. #0
>>> 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
>>> this=0x48321c0, sample=..., npwr=) at
>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>>
>>>
>> 286for(int j = 0; j < k; j++) {
>>>
>>> i stack #0 0x7f98dbbe01a7 in
>>> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
>>> sample=..., npwr=) at
>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>>
>>>
>> #1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
>>> this=0x48321c0, sample=...) at
>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
>>>
>>>
>> #2 0x7f98dbbe94dc in
>>> gr::digital::constellation_soft_decoder_cf_impl::work
>>> (this=0x4fb11a0, noutput_items=8190, input_items=...,
>>> output_items=...) at
>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
>>>
>>>
>> #3 0x7f98e1c5dd38 in gr::sync_interpolator::general_work (
>>> this=0x4fb11c0, noutput_items=, ninput_items=...,
>>> input_items=..., output_items=...) at
>>> /home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
>>>
>>> You should be able to reproduce the problem quite easily, but if
>>> needed I can provided a test program.
>>>
>>> Best, Miklos
>>>
>>> On Mon, Dec 16, 2013 at 7:59 AM, Marcus Müller
>>> wrote:
Could you post the whole backtrace (as a github gist, pastebin
etc)? That would be very helpful, along with information such
as: Compiler (Gcc (version), VC++, clang ...), Platform (Linux,
win, mac,...), architecture (x86(64), ARMv9, IBM S7390,...) and
GNU Radio source version.
Thanks and happy hacking, Marcus
On 12/16/2013 01:05 AM, Miklos Maroti wrote:
>
> Hi Guys,
>
> Constellation soft decoder crashes for constellation_bpsk()
> and constellation_8psk(). I could not find the cause of this
> problem, the back trace on my machine points to
>
> gnuradio/gr-digital/lib/constellation.cc:286 for(int j = 0; j <
> k; j++) {
>
> which does not make any sense. Any idea what could go wrong?
>
> Miklos
>
> ___
> Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo
Re: [Discuss-gnuradio] constellation soft decoder
On 12/16/2013 08:16 AM, Miklos Maroti wrote:
> Hi Marcus,
>
> Ok, that makes sense. It does not crash with QPSK, but it does with
> BPSK and 8PSK, and BPSK and 8PSK do not set the pre_diff_code. This
> explains why there is crash in one case and not the other. Although
> neither sets the apply_pre_diff_code, so even QPSK should not set
> pre_diff_code.
I took a quick look in Coverity for issues in gr-digital. It flags a
bunch of uninitialized variables. I'll try and take a look at these this
week.
There is an intermittent QA failure in some QA code and this might be an
explanation.
Philip
>
> I think the real problem is in constellation::calc_soft_dec. I does
> not check whether d_apply_pre_diff_code is set or not.
>
> (By the way, I do not understand the usefulness of pre_diff_code. Can
> you just permute the constellation points and get the same effect?)
>
> Miklos
>
> On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller wrote:
> Well, after having a debug build and then adding a lot of "volatile"s
> into the code at the crashing function, it looks as if the
> d_pre_diff_code of the constellation has size 0; and thus, you can't
> access the 0. (read: first) element. How this could happen with a QPSK
> object is currently subject to my confusion. Stay tuned for more
> confusing facts as the code unfolds :).
>
> Greetings,
> Marcus
>
> On 16.12.2013 08:30, Miklos Maroti wrote:
Hi Marcus,
I do not think it is a compiler bug, but something uninitialized.
Constellation_qpsk and constellation_calcdist does not crash (I
did not verify if they work). However, if I generate the LUT for
constellation_qpsk, then it crashes.
# uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue
Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
# gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Using latest master branch of gnuradio, hash 117058bac41c91, both
CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
# gdb `which python` core Reading symbols from
/usr/bin/python2.7...(no debugging symbols found)...done.
warning: core file may not match specified executable file. [New
LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248] [New LWP
2247] [New LWP 2239] [New LWP 2250]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled] Using host
libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python ./constellation_simulation.py'.
Program terminated with signal 11, Segmentation fault. #0
0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=..., npwr=) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
> 286for(int j = 0; j < k; j++) {
i stack #0 0x7f98dbbe01a7 in
gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
sample=..., npwr=) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
> #1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
this=0x48321c0, sample=...) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
> #2 0x7f98dbbe94dc in
gr::digital::constellation_soft_decoder_cf_impl::work
(this=0x4fb11a0, noutput_items=8190, input_items=...,
output_items=...) at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
> #3 0x7f98e1c5dd38 in gr::sync_interpolator::general_work (
this=0x4fb11c0, noutput_items=, ninput_items=...,
input_items=..., output_items=...) at
/home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
You should be able to reproduce the problem quite easily, but if
needed I can provided a test program.
Best, Miklos
On Mon, Dec 16, 2013 at 7:59 AM, Marcus Müller
wrote:
> Could you post the whole backtrace (as a github gist, pastebin
> etc)? That would be very helpful, along with information such
> as: Compiler (Gcc (version), VC++, clang ...), Platform (Linux,
> win, mac,...), architecture (x86(64), ARMv9, IBM S7390,...) and
> GNU Radio source version.
>
> Thanks and happy hacking, Marcus
>
> On 12/16/2013 01:05 AM, Miklos Maroti wrote:
>>
>> Hi Guys,
>>
>> Constellation soft decoder crashes for constellation_bpsk()
>> and constellation_8psk(). I could not find the cause of this
>> problem, the back trace on my machine points to
>>
>> gnuradio/gr-digital/lib/constellation.cc:286 for(int j = 0; j <
>> k; j++) {
>>
>> which does not make any sense. Any idea what could go wrong?
>>
>> Miklos
>>
>> ___
>> Discuss-gnuradio mailing list Discuss-gnuradio@gn
Re: [Discuss-gnuradio] constellation soft decoder
Hi Marcus,
Ok, that makes sense. It does not crash with QPSK, but it does with
BPSK and 8PSK, and BPSK and 8PSK do not set the pre_diff_code. This
explains why there is crash in one case and not the other. Although
neither sets the apply_pre_diff_code, so even QPSK should not set
pre_diff_code.
I think the real problem is in constellation::calc_soft_dec. I does
not check whether d_apply_pre_diff_code is set or not.
(By the way, I do not understand the usefulness of pre_diff_code. Can
you just permute the constellation points and get the same effect?)
Miklos
On Mon, Dec 16, 2013 at 1:34 PM, Marcus Müller wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Well, after having a debug build and then adding a lot of "volatile"s
> into the code at the crashing function, it looks as if the
> d_pre_diff_code of the constellation has size 0; and thus, you can't
> access the 0. (read: first) element. How this could happen with a QPSK
> object is currently subject to my confusion. Stay tuned for more
> confusing facts as the code unfolds :).
>
> Greetings,
> Marcus
>
> On 16.12.2013 08:30, Miklos Maroti wrote:
>> Hi Marcus,
>>
>> I do not think it is a compiler bug, but something uninitialized.
>> Constellation_qpsk and constellation_calcdist does not crash (I
>> did not verify if they work). However, if I generate the LUT for
>> constellation_qpsk, then it crashes.
>>
>> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue
>> Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>
>> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
>>
>> Using latest master branch of gnuradio, hash 117058bac41c91, both
>> CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
>>
>> # gdb `which python` core Reading symbols from
>> /usr/bin/python2.7...(no debugging symbols found)...done.
>>
>> warning: core file may not match specified executable file. [New
>> LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248] [New LWP
>> 2247] [New LWP 2239] [New LWP 2250]
>>
>> warning: Can't read pathname for load map: Input/output error.
>> [Thread debugging using libthread_db enabled] Using host
>> libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `python ./constellation_simulation.py'.
>> Program terminated with signal 11, Segmentation fault. #0
>> 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
>> this=0x48321c0, sample=..., npwr=) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>
>>
> 286for(int j = 0; j < k; j++) {
>>
>> i stack #0 0x7f98dbbe01a7 in
>> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
>> sample=..., npwr=) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>
>>
> #1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
>> this=0x48321c0, sample=...) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
>>
>>
> #2 0x7f98dbbe94dc in
>> gr::digital::constellation_soft_decoder_cf_impl::work
>> (this=0x4fb11a0, noutput_items=8190, input_items=...,
>> output_items=...) at
>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
>>
>>
> #3 0x7f98e1c5dd38 in gr::sync_interpolator::general_work (
>> this=0x4fb11c0, noutput_items=, ninput_items=...,
>> input_items=..., output_items=...) at
>> /home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
>>
>> You should be able to reproduce the problem quite easily, but if
>> needed I can provided a test program.
>>
>> Best, Miklos
>>
>> On Mon, Dec 16, 2013 at 7:59 AM, Marcus Müller
>> wrote:
>>> Could you post the whole backtrace (as a github gist, pastebin
>>> etc)? That would be very helpful, along with information such
>>> as: Compiler (Gcc (version), VC++, clang ...), Platform (Linux,
>>> win, mac,...), architecture (x86(64), ARMv9, IBM S7390,...) and
>>> GNU Radio source version.
>>>
>>> Thanks and happy hacking, Marcus
>>>
>>> On 12/16/2013 01:05 AM, Miklos Maroti wrote:
Hi Guys,
Constellation soft decoder crashes for constellation_bpsk()
and constellation_8psk(). I could not find the cause of this
problem, the back trace on my machine points to
gnuradio/gr-digital/lib/constellation.cc:286 for(int j = 0; j <
k; j++) {
which does not make any sense. Any idea what could go wrong?
Miklos
___
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
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSrvNkAAoJEAFxB7BbsDrLTuIIAKGc2OjoUYgV3L
Re: [Discuss-gnuradio] constellation soft decoder
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well, after having a debug build and then adding a lot of "volatile"s
into the code at the crashing function, it looks as if the
d_pre_diff_code of the constellation has size 0; and thus, you can't
access the 0. (read: first) element. How this could happen with a QPSK
object is currently subject to my confusion. Stay tuned for more
confusing facts as the code unfolds :).
Greetings,
Marcus
On 16.12.2013 08:30, Miklos Maroti wrote:
> Hi Marcus,
>
> I do not think it is a compiler bug, but something uninitialized.
> Constellation_qpsk and constellation_calcdist does not crash (I
> did not verify if they work). However, if I generate the LUT for
> constellation_qpsk, then it crashes.
>
> # uname -a Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue
> Nov 12 17:04:55 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>
> # gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
>
> Using latest master branch of gnuradio, hash 117058bac41c91, both
> CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
>
> # gdb `which python` core Reading symbols from
> /usr/bin/python2.7...(no debugging symbols found)...done.
>
> warning: core file may not match specified executable file. [New
> LWP 2249] [New LWP 2251] [New LWP 2240] [New LWP 2248] [New LWP
> 2247] [New LWP 2239] [New LWP 2250]
>
> warning: Can't read pathname for load map: Input/output error.
> [Thread debugging using libthread_db enabled] Using host
> libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `python ./constellation_simulation.py'.
> Program terminated with signal 11, Segmentation fault. #0
> 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
> this=0x48321c0, sample=..., npwr=) at
> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>
>
286for(int j = 0; j < k; j++) {
>
> i stack #0 0x7f98dbbe01a7 in
> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
> sample=..., npwr=) at
> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>
>
#1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
> this=0x48321c0, sample=...) at
> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
>
>
#2 0x7f98dbbe94dc in
> gr::digital::constellation_soft_decoder_cf_impl::work
> (this=0x4fb11a0, noutput_items=8190, input_items=...,
> output_items=...) at
> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
>
>
#3 0x7f98e1c5dd38 in gr::sync_interpolator::general_work (
> this=0x4fb11c0, noutput_items=, ninput_items=...,
> input_items=..., output_items=...) at
> /home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
>
> You should be able to reproduce the problem quite easily, but if
> needed I can provided a test program.
>
> Best, Miklos
>
> On Mon, Dec 16, 2013 at 7:59 AM, Marcus Müller
> wrote:
>> Could you post the whole backtrace (as a github gist, pastebin
>> etc)? That would be very helpful, along with information such
>> as: Compiler (Gcc (version), VC++, clang ...), Platform (Linux,
>> win, mac,...), architecture (x86(64), ARMv9, IBM S7390,...) and
>> GNU Radio source version.
>>
>> Thanks and happy hacking, Marcus
>>
>> On 12/16/2013 01:05 AM, Miklos Maroti wrote:
>>>
>>> Hi Guys,
>>>
>>> Constellation soft decoder crashes for constellation_bpsk()
>>> and constellation_8psk(). I could not find the cause of this
>>> problem, the back trace on my machine points to
>>>
>>> gnuradio/gr-digital/lib/constellation.cc:286 for(int j = 0; j <
>>> k; j++) {
>>>
>>> which does not make any sense. Any idea what could go wrong?
>>>
>>> Miklos
>>>
>>> ___
>>> 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSrvNkAAoJEAFxB7BbsDrLTuIIAKGc2OjoUYgV3Lw8SuarcCjb
awWSZUC+jGxiOs5meaDOcfVsR8Viv9D0G98s6Ck0U6uHkJ1GPvzLLkRbxonPEhcB
syFs4Uz4nhqYddfuiNTyG4LhWXPWC3i/rm53lngIO50zBRelrGwxWIg4y5VyKwfV
JZfQ3duH+4JBe81VNuUw9Cb6/xhxHORD65AhnwOQBYU4w1mIrP1kNokfsFkXK/WN
e55jg+inffiRAg47Bz5wl0SsYGFrlNRNq+JnEmCMCR74c5xNE8T3ZO/NfDGxEwjl
fqXhY3ZpWqcoFOnizepUs8qvdzosveaFYKF+R474IkoBGZxUMn0Q5d+GxNAhxj4=
=G4mf
-END PGP SIGNATURE-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] constellation soft decoder
Hi Marcus,
I do not think it is a compiler bug, but something uninitialized.
Constellation_qpsk and constellation_calcdist does not crash (I did
not verify if they work). However, if I generate the LUT for
constellation_qpsk, then it crashes.
# uname -a
Linux maroti-t410 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:04:55
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
# gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Using latest master branch of gnuradio, hash 117058bac41c91, both
CMAKE_BUILD_TYPE=Debug and Release produces the same behavior
# gdb `which python` core
Reading symbols from /usr/bin/python2.7...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New LWP 2249]
[New LWP 2251]
[New LWP 2240]
[New LWP 2248]
[New LWP 2247]
[New LWP 2239]
[New LWP 2250]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python ./constellation_simulation.py'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=..., npwr=)
at /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
286for(int j = 0; j < k; j++) {
i stack
#0 0x7f98dbbe01a7 in gr::digital::constellation::calc_soft_dec (
this=0x48321c0, sample=..., npwr=)
at /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
#1 0x7f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
this=0x48321c0, sample=...)
at /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
#2 0x7f98dbbe94dc in
gr::digital::constellation_soft_decoder_cf_impl::work (this=0x4fb11a0,
noutput_items=8190, input_items=..., output_items=...)
at
/home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation_soft_decoder_cf_impl.cc:68
#3 0x7f98e1c5dd38 in gr::sync_interpolator::general_work (
this=0x4fb11c0, noutput_items=, ninput_items=...,
input_items=..., output_items=...)
at
/home/mmaroti/workspace/gnuradio/gnuradio-runtime/lib/sync_interpolator.cc:67
You should be able to reproduce the problem quite easily, but if
needed I can provided a test program.
Best,
Miklos
On Mon, Dec 16, 2013 at 7:59 AM, Marcus Müller wrote:
> Could you post the whole backtrace (as a github gist, pastebin etc)?
> That would be very helpful, along with information such as:
> Compiler (Gcc (version), VC++, clang ...), Platform (Linux, win, mac,...),
> architecture (x86(64), ARMv9, IBM S7390,...) and GNU Radio source version.
>
> Thanks and happy hacking,
> Marcus
>
> On 12/16/2013 01:05 AM, Miklos Maroti wrote:
>>
>> Hi Guys,
>>
>> Constellation soft decoder crashes for constellation_bpsk() and
>> constellation_8psk(). I could not find the cause of this problem, the
>> back trace on my machine points to
>>
>> gnuradio/gr-digital/lib/constellation.cc:286
>> for(int j = 0; j < k; j++) {
>>
>> which does not make any sense. Any idea what could go wrong?
>>
>> Miklos
>>
>> ___
>> 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
Re: [Discuss-gnuradio] constellation soft decoder
Could you post the whole backtrace (as a github gist, pastebin etc)?
That would be very helpful, along with information such as:
Compiler (Gcc (version), VC++, clang ...), Platform (Linux, win, mac,...),
architecture (x86(64), ARMv9, IBM S7390,...) and GNU Radio source version.
Thanks and happy hacking,
Marcus
On 12/16/2013 01:05 AM, Miklos Maroti wrote:
Hi Guys,
Constellation soft decoder crashes for constellation_bpsk() and
constellation_8psk(). I could not find the cause of this problem, the
back trace on my machine points to
gnuradio/gr-digital/lib/constellation.cc:286
for(int j = 0; j < k; j++) {
which does not make any sense. Any idea what could go wrong?
Miklos
___
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
Re: [Discuss-gnuradio] constellation soft decoder
Seems like a strange error for C++. I usually get for loop errors with C
where you can't declare variables in the for loop. Perhaps try to declare j
outside the for loop.
AM KC3BBL
On Sun, Dec 15, 2013 at 7:05 PM, Miklos Maroti wrote:
> Hi Guys,
>
> Constellation soft decoder crashes for constellation_bpsk() and
> constellation_8psk(). I could not find the cause of this problem, the
> back trace on my machine points to
>
> gnuradio/gr-digital/lib/constellation.cc:286
> for(int j = 0; j < k; j++) {
>
> which does not make any sense. Any idea what could go wrong?
>
> Miklos
>
> ___
> 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
