Re: [Discuss-gnuradio] Fractional resampler eats stream tags on changes on the "ratio" input

[Piotr Krysik]

W dniu 07.06.2016 o 13:30, Piotr Krysik pisze:
> W dniu 01.10.2015 o 14:46, Piotr Krysik pisze:
>> W dniu 25.09.2015 o 23:23, Tom Rondeau pisze:
>>
>>
>>
>> Looking at the block, I was hoping it was as easy as putting a
>> set_relative_rate call in the set_resamp_rate to adjust how the tags
>> are being propagated. But it's not that simple. See Issue #846
>> (http://gnuradio.org/redmine/issues/846) for details on the problem.
>>
>> Tom
>>  
>>
> Hi,
>
> I'm writing to let everyone know that resampling blocks after changing
> the resampling rate in the run-time is still eating stream tags. This
> makes some designs impossible to implement currently.
>
> For example - it would be great if it was possible to implement a clock
> offset frequency correction like I have drawn on the attached image:
> -there are two blocks that do the correction: resampler and frequency
> shifting block,
> -they change their parameters (resamp_rate, frequency_shift) on stream tags,
> -there is a block that does clock frequency offset measurements that is
> connected at the end (putting it in different place is not practical in
> many circumstances),
> -these measurements are sent to frequency offset control block which
> turns them into control messages addressed for both resampler and
> frequency shifter,
> -msg to tag blocks adds a tag containing a control message to a stream,
> -the information about changes of settings of the resampler and rotator
> are interpreted also by the measurement block, that adjusts measurements
> based on this information.
>
> But currently it not possible to do this due to the issue with the
> resampling blocks.
>
> Did you Tom or anyone found the source of the problem?   
>
>
Hi Tom and others,

I implemented fractional resampling block that can have resampling rate
changed.

When doing this I learned what is the source of the issue #846. The
mistake is following:

transformation of tag offset by resampling block that changes its
resample rate is not a linear function, so in this case you can't use
such simple linear conversion, like it is done in GNU Radio's runtime:
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L143

However, transformation is linear from one resample rate change to
another. So if you know input and output sample number for which
resample rate was the same as for the moment when a tag came - you can
use this as reference point to compute the tag's offset at the output of
the resampling block.


My proposed solution: modification of tags offsets processing in
gnuradio runtime so it includes case when you have resampling blocks
with dynamically changing resample rate doesn't seem resonable. If would
complicate things too much because the runtime would have to track
resample rate changes inside of every block that can do that. Resampling
blocks that can have resample rate changed dynamically should implement
tags propagation themselves.

Current fractional resampler block doesn't do that and it is incorrect.
The input for dynamic resample rate control should be removed as it can
cause problems to the users OR users should be warned that if they use
this input they shouldn't expect tags to work correctly.

The block implemented by me is available here:
https://github.com/ptrkrysik/gr-gsm/blob/master/lib/misc_utils/controlled_fractional_resampler_cc_impl.cc

It uses a pmt pair ("set_resamp_ratio",value) tag to set resample ratio
precisely at the moment of tag occurrence.
It wasn't tested in all possible conditions yet, so I'm still a bit
cautious regarding it. But it presents how such a block can be
implemented and in tests performed by me it worked (it is also now used
to correct sample frequency offset in gr-gsm).

Best Regards,
Piotr Krysik

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Marcus Müller]

Well, having wasted a couple of hours of sleep time on this, maybe you
shouldn't do the logarithmic storage... at its core its the same idea as
storing floating point, but with a fixed mantissa.

The mathematical effects of the "rounding to the nearest exponential
step" on superimposed sinusoids of different amplitude are … funky.

Best regards,

Marcus


On 16.07.2016 21:57, Juha Vierinen wrote:
> Can you reduce the number of bits that you are using?
>
> With radar signals, the receiver noise most of the time excites only
> about 8 bits out of 16. Ground clutter or meteor echoes excite nearly
> all of the bits occasionally, so I can't just truncate to 8 bits. In
> this case, bzip2 actually does a pretty good job of getting rid of the
> 8/16 most significant bits that are zero most of the time. Thus, I get
> a compression ratio close to 50% when using sc16. pbzip2 is a good
> tool for doing parallel compression on files. 
>
> juha
>
> On Sat, Jul 16, 2016 at 3:59 AM, Dave NotTelling  > wrote:
>
> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data
> through a compression tool and then to disk?  I'd like to be able
> to take really wide band snaps for several minutes.  Currently
> that would take up 16 * 2 * SAMP_RATE bits per second.  So, for
> 200 MSPS that would end up being 800 MBytes/s.  That rate eats up
> a hard drive pretty quickly.  Running it through gzip by way of
> pigz was my first thought, but even on an 8 core Intel machine
> pigz just can't keep up.  I can sustain maybe 300 MBytes/s but
> that's it.  And I know it's not a hard disk limitation as the M.2
> drive I am using can easily sustain 800 MBytes/s of uncompressed
> data.
>
> Thoughts?
>
> Thank you!
>
>
> -Dave
>
> ___
> 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] gr-cdma

[Achilleas Anastasopoulos]

Hi Elisabeta,

could you please post some more info:

what os are you working with
what is your gnuradio prefix
post the entire cdma_parameters.py file
also is this the latest version of gr-cdma from github?

thanks
Achilleas







On Sun, Jul 17, 2016 at 4:26 AM, Elisabetta . 
wrote:

> Dear Achilleas Anastasopoulos,
>
> I have read your discussion with Frank Pinto and I think I have a similar
> problem. When I open a python session and do
>
>
> >>> from cdma import cdma_parameters
>
> It tells me:
>
> CDMA PARAMETERS : for adaptive coded modulation
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34,
> in 
> import cdma_parameters
>   File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py",
> line 110, in 
> local_header_obj =
> cdma.packet_header2(bits_per_header,length_tag_name,num_tag_name,
> header_mod.bits_per_symbol(),tcm_type_selector_default, "tcm_type")
> *AttributeError: 'module' object has no attribute 'packet_header2*'
>
>
> How can I fix the problem?
>
> I am using GNU Radio 3.7.5
>
> Thank you.
>
> Elisabetta Sciacca
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] License for libs linked in OOT

[Forest Crossman]

Jan,

If your OOT module uses GNU Radio data structures or function calls
(i.e., the API), then it can only be distributed under the GPL. This
is because the work is "based on" GNU Radio[1]. Since a work "based
on" a GPL'd work can only be distributed under the same license[2],
your OOT module would have to be licensed under the GPLv3+. It works
the same way in Wireshark, where any plugins developed for it can only
be distributed under the GPLv2+ or the GPLv3+.

Of course, you can release any code not based on GNU Radio (i.e.,
implementations of algorithms that could operate independently of GNU
Radio) under any license you want, so in essence you would be
dual-licensing a portion of the OOT module, but that could get legally
tricky very quickly.

To be clear, I'm not a lawyer, and I could be wrong, so don't take any
of this as legal advice. For that, I would consult the Software
Freedom Law Center[3]. If you want more non-lawyer advice, #fsf on
Freenode could probably give you some more pointers.

On a more cynical note, none of this license stuff really matters if
nobody sues you, so if you were to technically violate the GPL but do
it in a way that didn't make anyone too angry, you could probably get
away with it.

[1]: "To 'modify' a work means to copy from or adapt all or part of
the work in a fashion requiring copyright permission, other than the
making of an exact copy. The resulting work is called a 'modified
version' of the earlier work or a work 'based on' the earlier work."
[2]: "You may convey a work based on the Program, or the modifications
to produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these
conditions: ... You must license the entire work, as a whole, under
this License to anyone who comes into possession of a copy."
[3]: https://softwarefreedom.org

On Fri, Jul 8, 2016 at 2:08 PM, Jan Krämer  wrote:
> Hey everyone,
>
> thanks for your answers guys, I think you clarified pretty much everything.
> Now all I can do is wait for an answer from management.
>
> Cheers,
> Jan
>
> 2016-07-07 19:02 GMT+02:00 Martin Braun :
>>
>> Jan,
>>
>> also, don't forget, code you write is yours. You can even have multiple
>> licenses for the same code (at least for modules and parts that don't
>> use GNU Radio or other GPL'd libraries).
>>
>> Cheers,
>> Martin
>>
>> On 07/07/2016 06:18 AM, Jan Krämer wrote:
>> > Thanks Michael, now fingers crossed that I am allowed to publish the
>> > code under one of those licenses.
>> >
>> > Cheers,
>> > Jan
>> >
>> > 2016-07-07 12:18 GMT+02:00 Michael Dickens > > >:
>> >
>> > __
>> > What Sylvain wrote is correct: if you publish your GR OOT module,
>> > then you have to choose GPLv3 or a compatible FOSS license. I
>> > believe that by default the license is GPLv3, since that's what GR
>> > is. See also < http://www.gnu.org/licenses/license-list.html > for a
>> > list of compatible (and incompatible) licenses. - MLD
>> >
>> > ___
>> > 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
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Forest Crossman

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [Re: BER value]

[ANTONIO TAMAYO]

Hello Martin,

Thank you for your response.
Could you tell me how can I solve the problem with the offset between the
DPSK mod and demod?
In the same way, how can I garantee that I am comparing the correct bits?
Using another block?
Likewise, as you say, I am using a packet-based transmission. For this
reason I need to perform more sophisticated comparisons to calculate the
BER, what do you recommend me to calculate BER?

Thank you all,

Antonio

On 06/13/2016 09:46 AM, MARTIN BRAUN wrote:
>Antonio,
>
>I'm not sure why it's telling you 'no BER', but your setup is not
>suitable to test BER anyway. Your DPSK demod will always be offset w.r.t
>the DPSK mod input (because of sync delays etc.).
>
>Such BER measurements only work well if you can guarantee you're
>comparing the right bits.
>
>Since you're doing packet-based transmission, you'll need to come up
>with something more sophisticated comparison.
>
>Cheers,
>Martin
>
>On 06/12/2016 12:22 PM, ANTONIO TAMAYO wrote:
>> Hello all,
>>
>> I'm trying to calculate de BER value of the comunications system of the
>> image attached. I'm using a DQPSK modulator and demodulator. I think
>> that I have made mistakes in the configuration of my sistem because the
>> BER value always is "none", but I can't solve them. Somebody could help
me?
>>
>> Regards,
>>
>> Antonio.
>>
>>
>> ___
>> 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] License for libs linked in OOT

[Marcus Müller]

Hi Forest,

I'm pretty sure it's not quite like that:

It does exchange data structures and calls into GR/gets called from GR,
so it needs a GPLv3-compatible license, but not necessarily the GPLv3
itself.

In essence, fully agree with Sylvain's POV.

Cheers,
Marcus

On 17.07.2016 21:32, Forest Crossman wrote:
> Jan,
>
> If your OOT module uses GNU Radio data structures or function calls
> (i.e., the API), then it can only be distributed under the GPL. This
> is because the work is "based on" GNU Radio[1]. Since a work "based
> on" a GPL'd work can only be distributed under the same license[2],
> your OOT module would have to be licensed under the GPLv3+. It works
> the same way in Wireshark, where any plugins developed for it can only
> be distributed under the GPLv2+ or the GPLv3+.
>
> Of course, you can release any code not based on GNU Radio (i.e.,
> implementations of algorithms that could operate independently of GNU
> Radio) under any license you want, so in essence you would be
> dual-licensing a portion of the OOT module, but that could get legally
> tricky very quickly.
>
> To be clear, I'm not a lawyer, and I could be wrong, so don't take any
> of this as legal advice. For that, I would consult the Software
> Freedom Law Center[3]. If you want more non-lawyer advice, #fsf on
> Freenode could probably give you some more pointers.
>
> On a more cynical note, none of this license stuff really matters if
> nobody sues you, so if you were to technically violate the GPL but do
> it in a way that didn't make anyone too angry, you could probably get
> away with it.
>
> [1]: "To 'modify' a work means to copy from or adapt all or part of
> the work in a fashion requiring copyright permission, other than the
> making of an exact copy. The resulting work is called a 'modified
> version' of the earlier work or a work 'based on' the earlier work."
> [2]: "You may convey a work based on the Program, or the modifications
> to produce it from the Program, in the form of source code under the
> terms of section 4, provided that you also meet all of these
> conditions: ... You must license the entire work, as a whole, under
> this License to anyone who comes into possession of a copy."
> [3]: https://softwarefreedom.org
>
> On Fri, Jul 8, 2016 at 2:08 PM, Jan Krämer  wrote:
>> Hey everyone,
>>
>> thanks for your answers guys, I think you clarified pretty much everything.
>> Now all I can do is wait for an answer from management.
>>
>> Cheers,
>> Jan
>>
>> 2016-07-07 19:02 GMT+02:00 Martin Braun :
>>> Jan,
>>>
>>> also, don't forget, code you write is yours. You can even have multiple
>>> licenses for the same code (at least for modules and parts that don't
>>> use GNU Radio or other GPL'd libraries).
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 07/07/2016 06:18 AM, Jan Krämer wrote:
 Thanks Michael, now fingers crossed that I am allowed to publish the
 code under one of those licenses.

 Cheers,
 Jan

 2016-07-07 12:18 GMT+02:00 Michael Dickens >>> >:

 __
 What Sylvain wrote is correct: if you publish your GR OOT module,
 then you have to choose GPLv3 or a compatible FOSS license. I
 believe that by default the license is GPLv3, since that's what GR
 is. See also < http://www.gnu.org/licenses/license-list.html > for a
 list of compatible (and incompatible) licenses. - MLD

 ___
 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
>>
>>
>> ___
>> 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] [Re: BER value]

[Marcus Müller]

Hi Antonio,

> Could you tell me how can I solve the problem with the offset between
> the DPSK mod and demod?
Use a BER analysator with some kind of large window. In effect, I'd just
write the raw send symbol stream to a file, do the same with the receive
symbol stream, and calculate the error offline, if I hadn't had packets.

> Likewise, as you say, I am using a packet-based transmission.
That makes BER a bit of a "secondary issue", doesn't it? Packets have
checksums, and for all packets that contain bit errors, there's
(hopefully) a high probability the checksum will be wrong, and the whole
packet needs to be considered lost. Also, assuming symbol errors are
equally likely for all symbols in a packet, you should be able to derive
a PDF for the number of wrong bits per wrong packet, based on AWGN –
yeah, it's that stuff from digital comm basics :)

Anyway, having packets makes the whole measuring a lot easier; you'll
need to write a block that buffers both the send packets and the receive
packets. I don't know your packet format, but it possibly has a packet
number. Use that packet number to delete received packets from the send
packet buffer. If a packet is broken, reconstruct its number from the
next/previous successfully received packet. Note down the correct
received packets as successfull bits, and count the missing and broken
packets.

Best regards,
Marcus

On 17.07.2016 21:33, ANTONIO TAMAYO wrote:
> Hello Martin,
>
> Thank you for your response. 
> Could you tell me how can I solve the problem with the offset between
> the DPSK mod and demod?
> In the same way, how can I garantee that I am comparing the correct
> bits? Using another block?
> Likewise, as you say, I am using a packet-based transmission. For this
> reason I need to perform more sophisticated comparisons to calculate
> the BER, what do you recommend me to calculate BER?
>
> Thank you all,
>
> Antonio
>
> On 06/13/2016 09:46 AM, MARTIN BRAUN wrote:
> >Antonio,
> >
> >I'm not sure why it's telling you 'no BER', but your setup is not
> >suitable to test BER anyway. Your DPSK demod will always be offset w.r.t
> >the DPSK mod input (because of sync delays etc.).
> >
> >Such BER measurements only work well if you can guarantee you're
> >comparing the right bits.
> >
> >Since you're doing packet-based transmission, you'll need to come up
> >with something more sophisticated comparison.
> >
> >Cheers,
> >Martin
> >
> >On 06/12/2016 12:22 PM, ANTONIO TAMAYO wrote:
> >> Hello all,
> >>
> >> I'm trying to calculate de BER value of the comunications system of the
> >> image attached. I'm using a DQPSK modulator and demodulator. I think
> >> that I have made mistakes in the configuration of my sistem because the
> >> BER value always is "none", but I can't solve them. Somebody could help me?
> >>
> >> Regards,
> >>
> >> Antonio.
> >>
> >>
> >> ___
> >> 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