Re: [Discuss-gnuradio] FSK Burst emission

[Jeff Long]

Two things I think would be a big win for GR are a clean interface with 
message-oriented sources/sinks and easier distributed deployment/remote 
control. Maybe that's three things.


On 03/29/2018 08:22 AM, Müller, Marcus (CEL) wrote:

That's actually an extensively great idea (though I admit it hadn't
crossed my mind so far)!

So, for this to make it upstream, first of all, it'd need an OK from
Tim, as that probably kinda reassigns copyright to the FSF (Ben would
be my go-to authority on that).

Then, I'd obviously have to play "grumpy mean old maintainer" a bit:
I know there's qa_es.py, but I think it's been written before we fixed
shutdown bugs, so, probably, there's a bit good functionality that's
not covered by tests. Seeing how much "fun" we've had after extending
runtime infrastructure (and that's what I'd consider eventstream), to
avoid regressions in the future, I'd have to insist on a few additional
tests. Don't know how they'd look like, which might be an indication
I'd need to invite Tim for a beer and talk about what should be tested.
Code coverage metrics alone do not make for good testing.

And: As cool as eventstream is, and as much as I like Tim's blog, we'd
obviously need formal documentation; right now, I can't find a docs/
folder in my gr-eventstream build directory, so at least the building
of API docs needs to be fixed. And: if we do gr-eventstream, we'd do it
properly, which means that someone needs to sit down and write a guide
that integrates with the tutorials. I'm afraid a simple copypasta from
Tim's block wouldn't do, but would need to be broken down for beginners
to understand the problem at hand first (which requires some GNU Radio
operational theory).

So, as I can't do that today, and probably not in the first two weeks
of April, either, I'd propose we make a GREP out of that. Want to
champion that? That way, we'd document a desire to improve GNU Radio at
its core, and give us a target.

Cheers,
Marcus

On Thu, 2018-03-29 at 00:44 +, Dan CaJacob wrote:

Speaking of gr-eventstream, Marcus: is there any intent to pull that or 
something like it into core in this new Gnuradio world?

On Wed, Mar 28, 2018 at 3:22 PM Müller, Marcus (CEL)  wrote:

Hi Samuel,
On Wed, 2018-03-28 at 14:54 +0200, samuel verdon wrote:

I forgot to say that my graph is connected to hardware (bladerf or limesdr) via 
osmocom block. This one give me the error that there is not enough data.


Jeff's mail recommending gr-eventstream was on-spot.

Best regards,
Marcus___
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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM TX/RX PAPR

[guillaume.tochou]

How do you reduce the PAPR with existing block in GRC ?

I've tried with Scrambler->Encoder CCSDS->Interleaver but it doesn't 
seems to work. I'm still not having any signal at the output of the OFDM 
receiver.


Guillaume


Le 27/03/2018 à 11:58, Ron Economos a écrit :
Yes, I think the whitener does the trick. If you plot the PAPR of band 
limited white noise, it's pretty much the same curve.


Ron

On 03/27/2018 02:36 AM, Müller, Marcus (CEL) wrote:

Oooh, that's a nice plot!
This is way better than I would have anticipated. Can I attribute that
to awesome whitening properties of the code itself and following
scramblers/interleavers?

Marcus
On Tue, 2018-03-27 at 02:31 -0700, Ron Economos wrote:
CCDF (Complementary Cumulative Distribution Function) is often used 
to show PAPR probability. Here's what the GNU Radio DVB-T2 
transmitter looks like at 32K (27841 active) carriers with an 
without tone reservation PAPR reduction.


Ron
On 03/27/2018 02:09 AM, Müller, Marcus (CEL) wrote:

On Fri, 2018-03-23 at 14:21 -0700, Martin Braun wrote:

If you've
increased the number of carriers, PAPR also goes up (a bit).

Yep, by the same factor as you increase the number of carriers (proof
idea: time-symbol with worst PAPR is the discrete dirac over the 
vector
of FFT length N. That has a PAPR of N/1 = N if freq domain samples 
were

amplitude-limited to 1.)

The probability to hit a PAPR that bad is, however, limited.
Considering an M-PSK modulation on the N subcarriers. Then there's a
total of M^N possible time-domain OFDM symbols, but only M·N of these
are worst-PAPR, so
P(worst PAPR for N carriers) = M·N/M^N = N / M^(N-1)
assuming equally likely symbols. Since M^N pretty certainly grows
faster than N, your likelihood of ending up in the "worst PAPR"
scenario actually drops with N.

The story looks a bit different if you're not interested in the worst-
PAPR-symbol, but in all symbols that have a PAPR worse than some
threshold, e.g. 20dB. Especially for LTE, there's a lot of
simulative/monte carlo PAPR>threshold curves, as things like trading
clipping for amplifier efficiency plays a very commercially relevant
role there.

Best regards,

Marcus


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



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



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

Re: [Discuss-gnuradio] Dropping samples "D" when CPU at 60%

[CEL]

Hi Bakshi,On Wed, 2018-03-28 at 21:37 +, Bakshi, Arjun wrote:
> 1--- The divider(blue) simply tells me when the signal(orange) power has 
> increases more than X times w.r.t. older samples. It isn't exact, but good 
> enough.

No, that's not really the whole picture: it much more tells you about when the 
older samples were *really* low. y/x grows arbitrarily fast for x->0, but only 
linearly for increasing y. I've tried to explain why this is a bad idea in my 
opinion.
> 2--- However, the divider output is unbounded, so I threshold it (green). 

notice that lack of boundedness is definitely a sign of lost information, and 
you throw away even more by thresholding.
> 3--- The threshold block's output holds at 1 until the input drops below a 
> value, and doesn't give an impulse(green).
> 

It gives a step. A step contains all frequencies. Especially, a step after your 
[1,-1] filter gives you an impulse.
> 
> 4--- So I do the delay and subtract so that only transition points have 
> non-zero values(red).

Exactly!
> 
> 5--- Of which I want the 1st transition only, which is why I threshold again.

Why threshold? sounds like you want something that has a temporal behaviour, 
not a value amplitude-dependent behaviour
> It isn't exact, but gets the job done. 

I think I've clearly laid out my feelings about that!
Best regards,Marcus
> 
> 

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] spectrum monitoring / very wide band scanning

[CEL]

The 450 ms are indeed a generous upper boundary for tune duration –
however, since the B200 can't sample-time analog tunes, you'd do well
not to calculate much less; the B200 is generally much faster at
tuning, but when crossing certain frequency span boundaries, there's a
single tune that might take that long. You can probably test your
tuning sequence once and identify the tune step that takes that long,
and wait much shorter on all the other tunes.

Regarding RTL dongles: Same problem as B200, no possibility to know at
which sample a tune happened, exactly, so you need some safety margin.
Considering the cost, and the low bandwidth, and the low filter
fidelity, I'd argue, however, that you'd probably want even number of
RTL dongles to receive simultaneously, so that you can tune one half
while the other half generates "valid" signal.

You might want to do some hacks with the RTL dongles to share an
oscillator, so that they don't randomly differ in understanding of
frequency and in sample rate.

Best regards,
Marcus

On Thu, 2018-03-29 at 14:00 +1100, Balthasar Indermuehle wrote:
> Thanks Marcus, indeed I'm using B200's for this project. X300's are slightly 
> over my budget unfortunately... but I'm also interested in doing the same 
> with RTL dongles.
> You mention 450ms for tuning a B200 - that seems rather longish?
> 
> Cheers
> 
> - Balt
> 
> On 29 March 2018 at 06:04, Müller, Marcus (CEL)  wrote:
> > so, 60 steps in 3 Minutes… sounds absolutely doable with the Ettus B200
> > (you asked about UHD drivers, so I presume you mean USRPs – the RTL
> > dongle has nothing to do with UHD) and the usrp_spectrum_sense.py
> > script that comes with GNU Radio. Even if I do not endorse the
> > architecture of that script, and would recommend you reserve up to
> > 450ms for tuning, as the B200 can take a bit of time to tune over some
> > larger steps.
> > With the other USRPs, you'd be faster. With a X300+TwinRX, you'd be
> > able to do 80 MHz on each channel at once, and can tune the channels
> > independently, so that you can actually even interleave tuning and
> > receiving operation; realistically, that'd imply an effective
> > observable bandwidth of always at least 120 MHz; 3000 / 120, meaning
> > you only need 24 steps to cover all that bandwidth. With tuning delays
> > in single milliseconds (too lazy to look this up right now, so let's
> > say 1ms), that'd be 25ms tuning, roughly 2.999583 minutes of spectrum
> > observation for 3 minutes of operation.
> > 
> > Stitching that together to a full spectrum is more of a challenge here,
> > but assuming you control the frequency hopping with commands to the
> > USRP Source block, and hence are in control of when which band appears
> > on the sample streams:
> > You could do something like have a fixed 13-frequency sequence that
> > each of the two receive channels hop along in fixed time intervals.
> > Convert to vectors of interval length, FFT+magnitude-square these, and
> > reassemble to a full spectrum vector (if your frequency sequence is
> > strictly ascending, and non-overlapping, then just leave them in the
> > order they are – all frequency bins should now be equidistantly
> > spaced).
> > 
> > Best regards,
> > Marcus
> > 
> > On Wed, 2018-03-28 at 12:19 +1100, Balthasar Indermuehle wrote:
> > > At my work we're using R EB500s for continuous spectrum monitoring at 
> > > our sites of interest. These machines step through the frequencies 70 - 
> > > 3000 MHz in about 3 minutes in chunks of 50 MHz (from memory), and then 
> > > assemble the fragments into a contiguous waterfall display.
> > >
> > > Is anyone aware of a wide band scanner software (that may or may not be 
> > > GNUradio based) that works with RTL-SDR dongles and with UHD drivers and 
> > > would allow to create a wide band spectrum sweep?
> > >
> > > I've built a raw IQ recorder that does just that, but it needs to be 
> > > wrapped into a decent GUI, showing some nice waterfall displays and needs 
> > > to be made pretty. Before I'm investing the time to build this I thought 
> > > I'd check if that's not effort already done and shared by someone else. 
> > > Google thinks no... anyone know differently?
> > >
> > > - Balt
> > > ___
> > > 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

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] FSK Burst emission

[CEL]

That's actually an extensively great idea (though I admit it hadn't
crossed my mind so far)!

So, for this to make it upstream, first of all, it'd need an OK from
Tim, as that probably kinda reassigns copyright to the FSF (Ben would
be my go-to authority on that). 

Then, I'd obviously have to play "grumpy mean old maintainer" a bit:
I know there's qa_es.py, but I think it's been written before we fixed
shutdown bugs, so, probably, there's a bit good functionality that's
not covered by tests. Seeing how much "fun" we've had after extending
runtime infrastructure (and that's what I'd consider eventstream), to
avoid regressions in the future, I'd have to insist on a few additional
tests. Don't know how they'd look like, which might be an indication
I'd need to invite Tim for a beer and talk about what should be tested.
Code coverage metrics alone do not make for good testing.

And: As cool as eventstream is, and as much as I like Tim's blog, we'd
obviously need formal documentation; right now, I can't find a docs/
folder in my gr-eventstream build directory, so at least the building
of API docs needs to be fixed. And: if we do gr-eventstream, we'd do it
properly, which means that someone needs to sit down and write a guide
that integrates with the tutorials. I'm afraid a simple copypasta from
Tim's block wouldn't do, but would need to be broken down for beginners
to understand the problem at hand first (which requires some GNU Radio
operational theory).

So, as I can't do that today, and probably not in the first two weeks
of April, either, I'd propose we make a GREP out of that. Want to
champion that? That way, we'd document a desire to improve GNU Radio at
its core, and give us a target.

Cheers,
Marcus

On Thu, 2018-03-29 at 00:44 +, Dan CaJacob wrote:
> Speaking of gr-eventstream, Marcus: is there any intent to pull that or 
> something like it into core in this new Gnuradio world?
> 
> On Wed, Mar 28, 2018 at 3:22 PM Müller, Marcus (CEL)  wrote:
> > Hi Samuel,
> > On Wed, 2018-03-28 at 14:54 +0200, samuel verdon wrote:
> > > I forgot to say that my graph is connected to hardware (bladerf or 
> > > limesdr) via osmocom block. This one give me the error that there is not 
> > > enough data.
> > 
> > Jeff's mail recommending gr-eventstream was on-spot.
> > 
> > Best regards,
> > Marcus___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> -- 
> Very Respectfully,
> 
> Dan CaJacob

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] gnuradio.org feeds broken

[Derek Kozel]

Hi Kevin,

Thanks for letting us know. It may have to do with us doing the switch over
to a static website at the moment. When we get the new site up I'll make a
note to check on those feeds.

Derek

On Thu, Mar 29, 2018 at 2:16 AM, Kevin Reid  wrote:

> The two feeds linked at https://gnuradio.org/rss-feed/ both return a HTTP
> 403 error. I think this has been going on for some time.
>
> (I couldn't find an address more suitable for reporting problems with the
> gnuradio.org web site; sorry to bother everyone else.)
>
> ___
> 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] How can I do 64QAM modulation using Trellis and Viterbi algorithm?

[Elkin Ducuara]

Hi everybody.


I am trying to send and receive data using OFDM - MIMO, but to do it I have
to use *.fsm files chord the modulation type, For example I use the file
named "awgn1o2_16.fsm" for transmit in QPSK modulation or the file
"awgn2o4_4.fsm" for 16QAM. So I have the next questions:

1.) How can I use the current files located in
"usr/local/share/gnuradio/examples/trellis/fsm_files/" for execute a
modulation with more points of constellation such as 64QAM?

2.) How can I do a *.fsm file for generate a finite state machine that work
with 64QAM modulation?

3.) If possible, I want to know how the files called "awgn2o4_4.fsm" or
"awgn2o3_16.fsm" was build for later I can create a file compatible with
64QAM modulation.

Next, I append a file that I made (called "awgn3o6_8.fsm") but it does not
work correctly, however it is able to generate constellation points in
64QAM.


Thank you all, I hope you understood me and excuse me for my poor english.


awgn3o6_8.fsm
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] spectrum monitoring / very wide band scanning

[U L]

At my former employer we were using the HackRF in sweep mode to do I think
100 MHz to 6 GHz sweeps at 1 Hz (i.e. almost 6 GHz scanned each second).
For contiguous sweeps I think it used a non-configurable 7.5 MHz (RF tuned)
step or something like that, but gave you much better frequency resolution
as the waterfall was the output of a some FFT which was somewhat
configurable (so you could sort of set the resolution BW).  We did make use
of QSpectrumAnalyzer mentioned in a previous post and in combination with
the hackrf sweep-mode worked quite well.  I think the HackRF uses the same
driver as rtl-sdrs but a typical rtl does not support the sweep-mode of
operation.

On Wed, Mar 28, 2018 at 8:00 PM, Balthasar Indermuehle 
wrote:

> Thanks Marcus, indeed I'm using B200's for this project. X300's are
> slightly over my budget unfortunately... but I'm also interested in doing
> the same with RTL dongles.
> You mention 450ms for tuning a B200 - that seems rather longish?
>
> Cheers
>
> - Balt
>
> On 29 March 2018 at 06:04, Müller, Marcus (CEL)  wrote:
>
>> so, 60 steps in 3 Minutes… sounds absolutely doable with the Ettus B200
>> (you asked about UHD drivers, so I presume you mean USRPs – the RTL
>> dongle has nothing to do with UHD) and the usrp_spectrum_sense.py
>> script that comes with GNU Radio. Even if I do not endorse the
>> architecture of that script, and would recommend you reserve up to
>> 450ms for tuning, as the B200 can take a bit of time to tune over some
>> larger steps.
>> With the other USRPs, you'd be faster. With a X300+TwinRX, you'd be
>> able to do 80 MHz on each channel at once, and can tune the channels
>> independently, so that you can actually even interleave tuning and
>> receiving operation; realistically, that'd imply an effective
>> observable bandwidth of always at least 120 MHz; 3000 / 120, meaning
>> you only need 24 steps to cover all that bandwidth. With tuning delays
>> in single milliseconds (too lazy to look this up right now, so let's
>> say 1ms), that'd be 25ms tuning, roughly 2.999583 minutes of spectrum
>> observation for 3 minutes of operation.
>>
>> Stitching that together to a full spectrum is more of a challenge here,
>> but assuming you control the frequency hopping with commands to the
>> USRP Source block, and hence are in control of when which band appears
>> on the sample streams:
>> You could do something like have a fixed 13-frequency sequence that
>> each of the two receive channels hop along in fixed time intervals.
>> Convert to vectors of interval length, FFT+magnitude-square these, and
>> reassemble to a full spectrum vector (if your frequency sequence is
>> strictly ascending, and non-overlapping, then just leave them in the
>> order they are – all frequency bins should now be equidistantly
>> spaced).
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2018-03-28 at 12:19 +1100, Balthasar Indermuehle wrote:
>> > At my work we're using R EB500s for continuous spectrum monitoring at
>> our sites of interest. These machines step through the frequencies 70 -
>> 3000 MHz in about 3 minutes in chunks of 50 MHz (from memory), and then
>> assemble the fragments into a contiguous waterfall display.
>> >
>> > Is anyone aware of a wide band scanner software (that may or may not be
>> GNUradio based) that works with RTL-SDR dongles and with UHD drivers and
>> would allow to create a wide band spectrum sweep?
>> >
>> > I've built a raw IQ recorder that does just that, but it needs to be
>> wrapped into a decent GUI, showing some nice waterfall displays and needs
>> to be made pretty. Before I'm investing the time to build this I thought
>> I'd check if that's not effort already done and shared by someone else.
>> Google thinks no... anyone know differently?
>> >
>> > - Balt
>> > ___
>> > 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