Hi Tom,
On Mon, Dec 16, 2013 at 7:27 PM, Tom Rondeau <t...@trondeau.com> wrote:
> On Mon, Dec 16, 2013 at 1:08 PM, Miklos Maroti <mmar...@math.u-szeged.hu>
> 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 <mmar...@math.u-szeged.hu>
>> 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
>>>>>> <mar...@hostalia.de> 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
>>>>>>>>> 0x00007f98dbbe01a7 in
>>>>>>>>> gr::digital::constellation::calc_soft_dec ( this=0x48321c0,
>>>>>>>>> sample=..., npwr=<optimized out>) at
>>>>>>>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>>>>
>>>> 286 for(int j = 0; j < k; j++) {
>>>>>>>>>
>>>>>>>>> i stack #0 0x00007f98dbbe01a7 in
>>>>>>>>> gr::digital::constellation::calc_soft_dec (
>>>>>>>>> this=0x48321c0, sample=..., npwr=<optimized out>) at
>>>>>>>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:286
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>>>>
>>>> #1 0x00007f98dbbe0f7e in gr::digital::constellation::soft_decision_maker (
>>>>>>>>> this=0x48321c0, sample=...) at
>>>>>>>>> /home/mmaroti/workspace/gnuradio/gr-digital/lib/constellation.cc:355
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>>>>
>>>> #2 0x00007f98dbbe94dc 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 0x00007f98e1c5dd38 in gr::sync_interpolator::general_work (
>>>>>>>>> this=0x4fb11c0, noutput_items=<optimized out>,
>>>>>>>>> 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
>>>>>>>>> <mar...@hostalia.de> 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
>>>>>>
>>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.15 (GNU/Linux)
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>
>>>> iQEcBAEBAgAGBQJSrwVRAAoJEAFxB7BbsDrLhd8H/0q7o3KX9iCShBn/X7VehxF2
>>>> LdR1peDL2VSqbGTmKnm6CltUs1yP7+bCAp+s6/TqTun7ticxDBSnh/0Drsc1jO2d
>>>> 5E0UUKjjvuhdqKXfxbC/MGGSXlJ1Q1yGkkhmFvPS9ztQTT/Q3iLD8tFNshXdXlKc
>>>> FmPpyDWFDDD741AnqM4R5cXPnwUJkPV7aIvevYyrfYbjpSiK0t4yED0LVOZywnjs
>>>> aP2YB49qmWLpLYFAaIytcJF8cFkfumziPNQwpgndaZl8tuvwvUm7COHxXmBTdaqI
>>>> 2IrB8gns+hR05uU9UAJdwaVI2gKGRB1hmP0MaHUxPd80ODfscTd5TAMxasBDWmE=
>>>> =HkF/
>>>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> 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
