[Discuss-gnuradio] Mutex lock error

[Usman Haider]

Hi,

Today while donig some random testing, I had this error in complex_to_mag
block.

"boost unique_lock has no mutex: Operation not permitted."

What could be the reason?


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

Re: [Discuss-gnuradio] DVB-S Receiver

[Ron Economos]

There are some DVB-S receivers. See:

https://github.com/EdmundTse/gr-dvb

http://www.pabr.org/radio/leandvb/leandvb.en.html

The leandvb project is current and based on gr-dvb. A good project might 
be to port leandvb back into GNU Radio.


It should be noted that GNU Radio has a high performance Viterbi decoder 
block as part of the DVB-T receiver blocks (DVB-S uses the same Viterbi 
FEC as DVB-T). A port of the leandvb Viterbi code with the high 
performance functionality from the DVB-T block added in would be 
interesting.


Other blocks like the Reed-Solomon and Deinterleaver can be reused 
without modification from the DVB-T blocks.


Note that my DVB-S transmitter repo https://github.com/drmpeg/gr-dvbs is 
no longer required. A DVB-S transmitter flow graph constructed from 
DVB-T blocks is available in GNU Radio at:


/share/gnuradio/examples/dtv/dvbs_tx.grc

Ron

On 11/13/2017 04:57 PM, sakthivel velumani wrote:

Hi all,

I am doing my master degree in wireless communication and new to 
GNUradio. I am very much interested to work with it and to contribute 
something. As far as I have searched there is no DVB-S receiver module 
built for GNUradio but there were repos for DVB-S transmitter. Is 
there a reason for it not built so far or is it just no one needs it?


Thank you,
Sakthivel




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

[Discuss-gnuradio] DVB-S Receiver

[sakthivel velumani]

Hi all,

I am doing my master degree in wireless communication and new to GNUradio.
I am very much interested to work with it and to contribute something. As
far as I have searched there is no DVB-S receiver module built for GNUradio
but there were repos for DVB-S transmitter. Is there a reason for it not
built so far or is it just no one needs it?

Thank you,
Sakthivel


Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC file sink data types

[Matt Ames]

Hi all,

I am currently using the File Sink in GNUradio Companion by connecting a
UHD USRP source to a File sink.

By default, the UHD source block produces and output of "Complex Float 32".
The File Sink has "Complex", "Float", "Int" available as input types.

If I set the output of the UHD source as Complex Int 16, then what should
the corresponding input type be on the file sink? type "Complex" doesn't
work, I assume it's because it's expecting FC32 by default, even though
it's not explicitly stated. Type "Int" works and the flowgraph runs, I
assume this is because it is just accepting the integer values as a raw
stream and writing them to the file, while ignoring that each even and odd
sample is actually an I/Q value.

What is the correct input type to use on the File Sink when using UHD
output of Complex int16?

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Dan CaJacob]

I suppose if you don't have 64 bit, you can just shift it to be 32-bit and
sacrifice the lost precision. There's probably other possibilities, but I
think the newer ARM stuff is going 64-bit anyhow.

On Mon, Nov 13, 2017 at 2:01 PM Marcus Müller  wrote:

> Ok, see your point. I was a bit hesitant at first because that will end
> up needing 64bit division (which might really not be much fun on many
> ARMs), but meh, it's not like someone should be pushing tags around as
> if they're samples.
>
> Cheers,
> Marcus
>
> On Sun, 2017-11-12 at 23:33 +, Dan CaJacob wrote:
> > Why not make the sub-second offset a uint64. That way you can express
> time to the atto second (I think). The precision is overkill, but uint32,
> which barely breaks a picosecond is underkill.
> >
> > On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller 
> wrote:
> > > Hi Eugene,
> > > yup, fully agree, the whole concept is slightly broken.
> > > So, first of all, I really think the key problem we're constantly
> working around is that tags have an integer offset – which leads to
> rounding errors, even in relatively benign scenarios.
> > > I'd propose we add a fractional part: that would only extend tag_t by
> another integer field, so existing blocks wouldn't break, and would allow
> non-1:1-sync blocks to properly rewrite tag positions.
> > > As you say, floating point is a bad idea when dealing with times (it
> always has been – see uhd::time_spec_t, where we're constantly paying off
> the technical debt of having floating point as "suggested" default
> representation of time, albeit underneath things should (and to some
> degree, are) counted in ticks). Thus, I'd imagine a tag_t like
> > > struct tag_t {
> > > uint64_t offset; //integer offset, as had
> > > uint32_t fractional_offset; //interpret as fractional part, i.e.
> ·2^{-32}
> > > pmt::pmt_t key;
> > > pmt::pmt_t tag;
> > > pmt::pmt_t srcid; // might as well drop this; maybe someone is
> using this, but I haven't met them
> > > std::vector marked_deleted;
> > > }
> > > Would the fractional offset solve the issues you're seeing, assuming
> that we add proper handling to all the existing resamplers?
> > > Best regards,
> > > Marcus
> > >
> > >
> > > On 09.11.2017 20:52, Eugene Grayver wrote:
> > > > There is a major problem with the way tags are propagated in blocks
> with non-integer relative rate. If the ratio is not a power of two, the
> numerical accuracy of the floating point will cause the output tags to
> diverge from the input tags.  Consider the fractional resampler. It
> accumulates the timing offset in the range of 0 to 1. However tag
> propagation multiplies the ratio by the sample number. As the sample number
> grows the LSB accuracy of the ratio gets scaled by the ever larger value.
> For a ratio of 1.001 we saw divergence of 1000s of samples over a few
> minutes at 10msps. I rewrote tag propagation for the resampler but did not
> rework the generic logic. I think the key point is to use the delta between
> read and written items to take out the large integer difference and then
> apply the scaling to a local delta within the current window.
> > > >
> > > > ___
> > > > Eugene Grayver, Ph.D.
> > > > Aerospace Corp., Sr. Eng. Spec.
> > > > Tel: 310.336.1274 <(310)%20336-1274>
> > > > 
> > > >
> > > >
> > > >
> > > > ___
> > > > 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
> >
> > --
> > Very Respectfully,
> >
> > Dan CaJacob
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Very Respectfully,

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

[Discuss-gnuradio] GSoC Ideas Page – please (for now) finalize!

[Marcus Müller]

Hey everyone,

as Felix (in his position as GNU Radio GSoC manager) has been telling
people through private channels over the last week, we're bringing our
GSoC ideas list [1] up to shape, so that we can attract a lot of
candidates, and make it easy for students to see how well they match
the requirements for any given project.

So, we plan to bring the list from its shape in the wiki [1] over to
something slightly more flashy. Thinking of a categorized list with
icons, directly integrating with the home page, or on a separate
domain.

In any case, that means that I'd like to ask /all/ of you to proof-read 
that list. If you have a project that's not on there AND feel like
you'd be an appropriate mentor, this would also be kind of the best
chance to make the project idea visible without jumping through many
hoops or making us jump.

Now, as my subject line tries to imply: Not all that is on that list
when we put it live is bound to be 100% identical to what the student
will do – that's why we have the proposal phase, where candidates are
encouraged to talk about what they think they'll be doing.
It's also pretty clear that there's a lot of "hot topics" on that list,
which are moving targets; if your idea belongs in that category, make
sure a candidate that applies next spring still gets a description that
we can at least easily correct to fit the problem to be solved at that
point.

Deadline's Thursday night (pacific time).

Best regards, and thanks for helping make sure we'll be among the GSoC
organizations once again,

Marcus

[1] https://wiki.gnuradio.org/index.php/GSoCIdeas

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Marcus Müller]

Ok, see your point. I was a bit hesitant at first because that will end
up needing 64bit division (which might really not be much fun on many
ARMs), but meh, it's not like someone should be pushing tags around as
if they're samples.

Cheers,
Marcus

On Sun, 2017-11-12 at 23:33 +, Dan CaJacob wrote:
> Why not make the sub-second offset a uint64. That way you can express time to 
> the atto second (I think). The precision is overkill, but uint32, which 
> barely breaks a picosecond is underkill.
> 
> On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller  
> wrote:
> > Hi Eugene,
> > yup, fully agree, the whole concept is slightly broken. 
> > So, first of all, I really think the key problem we're constantly working 
> > around is that tags have an integer offset – which leads to rounding 
> > errors, even in relatively benign scenarios.
> > I'd propose we add a fractional part: that would only extend tag_t by 
> > another integer field, so existing blocks wouldn't break, and would allow 
> > non-1:1-sync blocks to properly rewrite tag positions.
> > As you say, floating point is a bad idea when dealing with times (it always 
> > has been – see uhd::time_spec_t, where we're constantly paying off the 
> > technical debt of having floating point as "suggested" default 
> > representation of time, albeit underneath things should (and to some 
> > degree, are) counted in ticks). Thus, I'd imagine a tag_t like
> > struct tag_t {
> > uint64_t offset; //integer offset, as had
> > uint32_t fractional_offset; //interpret as fractional part, i.e. 
> > ·2^{-32}
> > pmt::pmt_t key;
> > pmt::pmt_t tag;
> > pmt::pmt_t srcid; // might as well drop this; maybe someone is using 
> > this, but I haven't met them
> > std::vector marked_deleted; 
> > }
> > Would the fractional offset solve the issues you're seeing, assuming that 
> > we add proper handling to all the existing resamplers?
> > Best regards,
> > Marcus
> > 
> > 
> > On 09.11.2017 20:52, Eugene Grayver wrote:
> > > There is a major problem with the way tags are propagated in blocks with 
> > > non-integer relative rate. If the ratio is not a power of two, the 
> > > numerical accuracy of the floating point will cause the output tags to 
> > > diverge from the input tags.  Consider the fractional resampler. It 
> > > accumulates the timing offset in the range of 0 to 1. However tag 
> > > propagation multiplies the ratio by the sample number. As the sample 
> > > number grows the LSB accuracy of the ratio gets scaled by the ever larger 
> > > value. For a ratio of 1.001 we saw divergence of 1000s of samples over a 
> > > few minutes at 10msps. I rewrote tag propagation for the resampler but 
> > > did not rework the generic logic. I think the key point is to use the 
> > > delta between read and written items to take out the large integer 
> > > difference and then apply the scaling to a local delta within the current 
> > > window.
> > >  
> > > ___
> > > Eugene Grayver, Ph.D.
> > > Aerospace Corp., Sr. Eng. Spec.
> > > Tel: 310.336.1274
> > > 
> > >  
> > > 
> > > 
> > > ___
> > > 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
> 
> -- 
> Very Respectfully,
> 
> Dan CaJacob
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] reg:- sampling rate in GRC

[Kyeong Su Shin]

Hello Rensi Sam:

If you set the sampling rate of your hardware source/sink block to
samp_rate, then it will generate or consume samples at that sampling rate.
Ex: if the sampling rate of your Osmocom source block is set to 1e6, that
block will generate 1e6 points per every second. In this case, the
capability of the radio device restricts the choice of the sampling rates
(Ex: USRP N2x0s can only take sampling rate of 100e6 / N (integer), where
4<= N <= 512).

Same thing will happen when you use a throttle block - a throttle block
with sampling rate = n will force your flowgraph to generate only n points
per each second. This is used to control the processing speed of GNU Radio
when you are not attaching a hardware. (you should not use the throttle
block when you are using hardware transmitters/receivers, as this will
cause a two-clock problem).

Other than that, the sampling rate variable is just there for conveniences
in calculations (so as you can think in Hz, not in -pi to pi).

Regards,
Kyeong Su Shin

On Mon, Nov 13, 2017 at 1:07 AM, Rensi Mathew  wrote:

> Hi
>
> I have a doubt regarding the sampling rate used in GNU radio.
>
> Is there any limit for the sampling rate (minimum/maximum) other than the
> Nyquist Criteria which should be used in GNU radio companion?
>
> Is there any difference  to the sampling rate (or limit to it) when we
> connect a hardware ?
>
> Thanking you all
>
> Rensi Sam, India
>
> ___
> 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] reg:- sampling rate in GRC

[Rensi Mathew]

Hi
I have a doubt regarding the sampling rate used in GNU radio.
Is there any limit for the sampling rate (minimum/maximum) other than the 
Nyquist Criteria which should be used in GNU radio companion?
Is there any difference  to the sampling rate (or limit to it) when we connect 
a hardware ?
Thanking you all
Rensi Sam, India___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio