Re: [Discuss-gnuradio] FOSDEM 2018: SDR Track CfP

[Martin Braun]

My apologies -- the SDR devroom is Sunday the 4th, not Saturday.

Regards,
Martin


On 10/06/2017 10:00 PM, Martin Braun wrote:
> Dear friends and fans of software defined radio and free/open source
> radio topics in general,
> 
> next year's FOSDEM (the free and open source developer's meeting in
> Brussels, Europe) will, once again, feature a  track on Software Defined
> Radio and other radio-related topics.
> Therefore, we invite developers and users from the free software radio
> community to join us for this track and present your talks or demos.
> 
> Software Radio has become an important tool to allow anyone access the
> EM spectrum. Using free software radio libraries and applications and
> cheap  hardware, anyone can now start hacking on wireless
> communications, remote sensing, radar or other applications. At FOSDEM,
> we hope to network all these projects and improve collaboration, bring
> new ideas forward and get more people involved.
> 
> The track's web site resides at:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FOSDEM
> 
> Here, we will publish updates and announcements. The final schedule will
> be available through Pentabarf and the official FOSDEM website.
> 
> ** Submit your presentations
> 
> To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM18
> and follow the instructions (you need an account, but can use your
> account from last year if you have one). You need to create an 'Event';
> make sure it's in the Software Defined Radio track! Lengths aren't
> fixed, but give a realistic estimate and please don't exceed 30 minutes
> unless you have something special planned (in that case, contact one of
> us). Also, don't forget to include time for Q
> We will typically go for 30-minute slots -- shorter talks, unless
> they're really short, usually tend to screw up the schedule too much.
> 
> You aren't limited to slide presentations, of course. Be creative.
> However, FOSDEM is an open source conference, therefore we ask you to
> stay clear of marketing presentations. We like nitty-gritty
> technical stuff.
> 
> Here's a list of topics that will most likely be included:
> - SDR Frameworks + Tools
> - Wireless security
> - Radio hardware
> - Ham radio related topics
> - Telecommunications
> - Random fun wireless hacks
> 
> We will reserve time for interactiveness, it won't all be talks.
> 
> ** Important Dates
> 
> FOSDEM is February 3rd and 4th, 2018.
> 
> * December 8th 2017: Submission Deadline
> * December 18th 2017: Announcement of final schedule
> * February 4th 2018: SDR Track (Sunday)
> 
> These dates are not set in stone. However, the least years we were
> always full to the brim with presentations, so if you want to present,
> please make sure to submit your abstracts soon!
> 
> ** Steering Committee
> 
> The track committee consists of:
> * Phil "Crofton" Balister (OpenEmbedded / OpenSDR)
> * Martin "mbr0wn" Braun (GNU Radio)
> * Sylvain "tnt" Munaut (OsmoCom)
> 
> Hope to hear from you soon! And please forward this announcement.
> 
> Martin
> 


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

[Discuss-gnuradio] FOSDEM 2018: SDR Track CfP

[Martin Braun]

Dear friends and fans of software defined radio and free/open source
radio topics in general,

next year's FOSDEM (the free and open source developer's meeting in
Brussels, Europe) will, once again, feature a  track on Software Defined
Radio and other radio-related topics.
Therefore, we invite developers and users from the free software radio
community to join us for this track and present your talks or demos.

Software Radio has become an important tool to allow anyone access the
EM spectrum. Using free software radio libraries and applications and
cheap  hardware, anyone can now start hacking on wireless
communications, remote sensing, radar or other applications. At FOSDEM,
we hope to network all these projects and improve collaboration, bring
new ideas forward and get more people involved.

The track's web site resides at:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FOSDEM

Here, we will publish updates and announcements. The final schedule will
be available through Pentabarf and the official FOSDEM website.

** Submit your presentations

To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM18
and follow the instructions (you need an account, but can use your
account from last year if you have one). You need to create an 'Event';
make sure it's in the Software Defined Radio track! Lengths aren't
fixed, but give a realistic estimate and please don't exceed 30 minutes
unless you have something special planned (in that case, contact one of
us). Also, don't forget to include time for Q
We will typically go for 30-minute slots -- shorter talks, unless
they're really short, usually tend to screw up the schedule too much.

You aren't limited to slide presentations, of course. Be creative.
However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. We like nitty-gritty
technical stuff.

Here's a list of topics that will most likely be included:
- SDR Frameworks + Tools
- Wireless security
- Radio hardware
- Ham radio related topics
- Telecommunications
- Random fun wireless hacks

We will reserve time for interactiveness, it won't all be talks.

** Important Dates

FOSDEM is February 3rd and 4th, 2018.

* December 8th 2017: Submission Deadline
* December 18th 2017: Announcement of final schedule
* February 3rd 2018: SDR Track (Saturday)

These dates are not set in stone. However, the least years we were
always full to the brim with presentations, so if you want to present,
please make sure to submit your abstracts soon!

** Steering Committee

The track committee consists of:
* Phil "Crofton" Balister (OpenEmbedded / OpenSDR)
* Martin "mbr0wn" Braun (GNU Radio)
* Sylvain "tnt" Munaut (OsmoCom)

Hope to hear from you soon! And please forward this announcement.

Martin

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

Re: [Discuss-gnuradio] SoCal gnuradio/SDR meetups

[Martin Braun]

James,

GRCon 2017 was in San Diego, and attracted a big crowd (lot of locals
too). So there's that.

In northern California, Balint hosts the Cyberspectrum meetups:
https://www.meetup.com/Cyberspectrum/

...but I see you already joined those.

-- M

On 10/05/2017 02:09 PM, James Wanga wrote:
> Hi folks. 
> Is anyone aware of any gnuradio or SDR meetups or hackerspaces in SoCal, or 
> elsewhere for that matter. I’d love to contribute to a physical community of 
> like-minded hackers. 
> 
> James Wanga
> ___
> 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] [USRP-users] Audio Control loop testing

[Benny Alexandar]

>>No. I'll stop contributing to this discussion now. The average sound card has 
>>a 25ppm clock accuracy, >>according to design specs of Texas Instrument audio 
>>ADC/DAC ICs. So, that's way, way better than >>your CPU clock, and even more 
>>better than your CPU clock sampled through a system call in a 
non->>realtime userland application.


>>I wish you the best with your application! I'm clearly not helping you, 
>>because I feel that you're still >>repeating things that I've already tried 
>>to explain

Actually I'm new to this field and learning new things in the past 10 months or 
so. My apologies for repeating things.

I'm still wondering how JACK server  and zita-ajbridge kind of audio 
applications are able to address this issue. Since they are addressing the same 
issues for audio streaming through network, why can't it be reused here ?

-ben

From: Benny Alexandar
Sent: Wednesday, October 4, 2017 10:39 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

>>Yeah. But that doesn't help at all, since clock recovery of any digital 
>>receiver will give you samples resampled to the transmitter's clock...
>>Anyway, notice how you say "roughly". Now, compare that "roughness" to the 
>>"roughly the same" transmitter and receiver audio clock.
>>You're at least in the same order of magnitude here, and my point is that by 
>>introducing yet another clock into this
>>(the abyssimal bad PC clock), you're making things way worse than they need 
>>be, and atop of that, unnecessarily complicated.


Actually there exist a resampler at the input as well. After clock recovery the 
base band samples are synchronized with transmitter.  Then the symbols which 
make the transmission frames are timestamped. At this point we are in sync with 
transmitter.

The conversion  error of clocks  should be negligible compared to audio  sample 
rate as we are dealing with
microseconds timer. If you read Fons paper again, you will find his paper uses 
*some* clock which can be CPU, or real-time or any clock.
According to him "The stability of the timer used to get timestamps on both the 
input and output streams of the resampler doesn't matter much,
it basically almost disappears from the equations. Any random variations will 
be smoothed by a DLL."


>> Again, I don't see where you see the audio device clock in your system.
>> I'd be very thankful if you could explain **that** to me, since well, 
>> there's no clock line between my sound card and my CPU.

One way to make a sound card clock is to use the callback from JACK or ALSA and 
count samples.
The code must be robust in the sense that at no time, must even a single sample 
be lost.
With JACK this should be possible, and the callback happens precisely when the 
number of samples
configured for the buffer is over.


>> nd we're stating the original problem again.
>> We don't know any of these rates relative to any other of these rates.

Now the audio decoded is synchronized to transmitter rate  and send to sound 
card. By using a resampler this audio clock is adjusted to sound card clock 
rate.


-ben

From: Benny Alexandar
Sent: Tuesday, October 3, 2017 11:18 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

By using the PC clock, and calling set time now with
the current PC time before scheduling streaming. This will make the USRP
tick counter roughly match the PC clock.

usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6));

Then use the Jack audio clock  and maps this audio clock to system one .

At the input side USRP decides the input rate, slave the audio to this rate.

-ben

From: Benny Alexandar
Sent: Friday, September 29, 2017 11:59 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing


>> you don't get the sound card clock anywhere in software. If you did, there 
>> would >> be no problem

Jack uses audio clock  and maps this audio clock to system one
with the use of DLL (delay locked loop).

-ben

From: Benny Alexandar
Sent: Wednesday, September 27, 2017 10:45 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing


>>Could you maybe elaborate how you're planning to solve all a),b),c) instead 
>>of asking for new feedback?


For a) & b) will use the sound card clock and using micro seconds timer.

And for c) run the decoded PCM through a FIFO buffer this is a local buffer 
which is not part of gnu-radio connect buffers,  between the SRC and the 
play-out stage. The trade-off for this approach of course is increased latency.
This way any variable work-load length is not going to affect and the local 
fifo will have fixed length.
Timing errors needs to be filtered using DLL which is  the same used in JACK.

-ben

Re: [Discuss-gnuradio] Checking that a flowgraph is done

[Andrej Rode]

Hi Gilad, 

On Fri, Oct 06, 2017 at 03:17:52PM +, Gilad Beeri (ApolloShield) wrote:
> I have a flowgraph used for simulations that uses a File Source with no
> repeat.
> I want to run some code after the flowgraph is done (-> when the source
> returns -1).
> How can I achieve that?

If you are ok with the flowgraph blocking your current thread you could
call `run()` on the top_block. Or you could continue doing other
calculations on your data after calling `start()` and then call `wait()`
on the top_block. `wait()` will either block until the flow graph is
done or return immediatly if the flowgraph was done already. In either
case you can be sure the flowgraph is done.

Cheers
Andrej

-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

[Discuss-gnuradio] Checking that a flowgraph is done

[Gilad Beeri (ApolloShield)]

I have a flowgraph used for simulations that uses a File Source with no
repeat.
I want to run some code after the flowgraph is done (-> when the source
returns -1).
How can I achieve that?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cheap sdr platform

[Marcus D. Leech]

On 10/06/2017 10:26 AM, Getz, Robin wrote:


Hi Marcus:

Yes – people need to understand the differences between SDR platforms 
and bench equipment, it a lot more than just weight and size.


Before connecting an SDR to an amplifier – the end user needs to 
understand what is really there (normally via bench equipment).


They also need to understand when they receive a signal, what’s 
actually there, and what is aliasing down in the RF side. It’s a super 
easy attack vector for misunderstood receivers.


Maybe I’m just too little sensitive to the noise floor  – I think 
there is a lot of invisible RF pollution, which is making everyone’s 
lives harder, and few realize it.


I'm a radio astronomer (part-time) myself.  RFI is a limiting factor 
nearly everywhere these days, including sites with "dark sky" RF conditions.


When I'm doing system design, you can bet that filters play a crucial 
role.  They are a necessary part of an engineered RF *system*.  Folks often
  tend to think of SDRs as an end-solution rather than a *component* in 
an overall engineered RF *system*.   Many complaints about RX peformance

  in particular tend to stem from this one mis-understanding



-Robin

For those interested - there is a good article at:

https://spectrum.ieee.org/telecom/wireless/electronic-noise-is-drowning-out-the-internet-of-things

*From:*Marcus Müller [mailto:muel...@kit.edu]
*Sent:* Friday, October 06, 2017 7:45 AM
*To:* Getz, Robin ; discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] cheap sdr platform

Hi Robin,

Yeah, I didn't mean to imply the Pluto was "worse" than others. It's 
really that as you, and I thought that was really great about your 
talk, showed that SDRs aren't "totally harmless toys". Indeed, I 
hadn't even noticed so far the different band-specific paths of the 
B2x0 were gone on the B200mini!


And yes, who am I to tell you that, but that's the price you pay for 
frequency-agile SDR: Either you spend a lot of money on dedicated 
filtering per band (E310, TwinRX), or you get the cheap flexibility at 
the expense of selectivity. That might be the reason why an R 
spectrum analyzer might be a tad more expensive then the average COTS 
SDR device that we're considering below.


But the fact that you need your own filters, in the end, is – in my 
experience – something that people building systems are very willing 
to accept, because you can use one and the same SDR device that you 
got to know intimately in products which you optimize for the bands 
that you'll actually use in that incarnation of your system by adding 
(relatively cheap) filters for exactly what you care about. That's why 
it makes sense for the B200mini to lack these filters – the form 
factor means it lends itself to systems integration. And that's also 
why it makes sense for the Pluto to not have filters – aside from the 
(extremely nice) price tag, hell, it's an experimentation platform, so 
the flexibility is more important than the raw signal quality.


So, yeah, my wording was misleading there – thank you for the response!

They also have ones that are 700 MHz - 2.6 GHz (which is super
weird – since any  3^rd harmonic of the LO created internally will
mix down anything at 2100 – 2600 into the 700 – 866 MHz bands).

Well, the Ettus B200 works pretty well, but switches between the three 
RX bands at 70MHz–2.2GHz, 2.2–4.0GHz and 4.0–6.0 GHz. I must admit I 
always wondered which black magic was involved to support the nearly 5 
(!) octaves that 70 to 2200 MHz covers on ADI's side.


Best regards,
Marcus

[1] 
https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L54-L60

On 10/06/2017 06:57 AM, Getz, Robin wrote:

Marcus:

It’s not only Pluto that does not have filters, I was trying to
make the point (maybe not effectively) at GRCon - it’s radios in
this “class”.

For example LimeSDR (sheet 5)


https://github.com/myriadrf/LimeSDR-USB/raw/master/hardware/plug/1v4/Project%20Outputs%20for%20LimeSDR-USB_1v4_LMS031pad/LimeSDR-USB_1v4_schematic_r7.PDF

Have Tx connectors which are spec’ed for 30MHz – 1.9 GHz – with no
filtering  - my guess they will blast out the same that I was
showing – if anyone starts looking. (I haven’t got one yet, so I
don’t know for sure).

The ones that do have filters (and will not be as bad), are
limited to 2.0 GHz – 2.6 GHz; or 700 MHz - 900 MHz ; but that is
super limiting to a general purpose platform.

They also have ones that are 700 MHz - 2.6 GHz (which is super
weird – since any  3^rd harmonic of the LO created internally will
mix down anything at 2100 – 2600 into the 700 – 866 MHz bands).

What we have on Pluto is (sheet 7)


https://wiki.analog.com/_media/university/tools/pluto/hacking/plutosdr_schematic_revb.pdf

Which is the same as what we initially did on the
Evaluation/prototyping board:

Re: [Discuss-gnuradio] cheap sdr platform

[Getz, Robin]

Hi Marcus:

Yes – people need to understand the differences between SDR platforms and bench 
equipment, it a lot more than just weight and size.

Before connecting an SDR to an amplifier – the end user needs to understand 
what is really there (normally via bench equipment).
They also need to understand when they receive a signal, what’s actually there, 
and what is aliasing down in the RF side. It’s a super easy attack vector for 
misunderstood receivers.

Maybe I’m just too little sensitive to the noise floor  – I think there is a 
lot of invisible RF pollution, which is making everyone’s lives harder, and few 
realize it.

-Robin


For those interested - there is a good article at:
https://spectrum.ieee.org/telecom/wireless/electronic-noise-is-drowning-out-the-internet-of-things


From: Marcus Müller [mailto:muel...@kit.edu]
Sent: Friday, October 06, 2017 7:45 AM
To: Getz, Robin ; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] cheap sdr platform


Hi Robin,

Yeah, I didn't mean to imply the Pluto was "worse" than others. It's really 
that as you, and I thought that was really great about your talk, showed that 
SDRs aren't "totally harmless toys". Indeed, I hadn't even noticed so far the 
different band-specific paths of the B2x0 were gone on the B200mini!

And yes, who am I to tell you that, but that's the price you pay for 
frequency-agile SDR: Either you spend a lot of money on dedicated filtering per 
band (E310, TwinRX), or you get the cheap flexibility at the expense of 
selectivity. That might be the reason why an R spectrum analyzer might be a 
tad more expensive then the average COTS SDR device that we're considering 
below.

But the fact that you need your own filters, in the end, is – in my experience 
– something that people building systems are very willing to accept, because 
you can use one and the same SDR device that you got to know intimately in 
products which you optimize for the bands that you'll actually use in that 
incarnation of your system by adding (relatively cheap) filters for exactly 
what you care about. That's why it makes sense for the B200mini to lack these 
filters – the form factor means it lends itself to systems integration. And 
that's also why it makes sense for the Pluto to not have filters – aside from 
the (extremely nice) price tag, hell, it's an experimentation platform, so the 
flexibility is more important than the raw signal quality.

So, yeah, my wording was misleading there – thank you for the response!
They also have ones that are 700 MHz - 2.6 GHz (which is super weird – since 
any  3rd harmonic of the LO created internally will mix down anything at 2100 – 
2600 into the 700 – 866 MHz bands).
Well, the Ettus B200 works pretty well, but switches between the three RX bands 
at 70MHz–2.2GHz, 2.2–4.0GHz and 4.0–6.0 GHz. I must admit I always wondered 
which black magic was involved to support the nearly 5 (!) octaves that 70 to 
2200 MHz covers on ADI's side.

Best regards,
Marcus

[1] 
https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L54-L60
On 10/06/2017 06:57 AM, Getz, Robin wrote:

Marcus:

It’s not only Pluto that does not have filters, I was trying to make the point 
(maybe not effectively) at GRCon - it’s radios in this “class”.

For example LimeSDR (sheet 5)
https://github.com/myriadrf/LimeSDR-USB/raw/master/hardware/plug/1v4/Project%20Outputs%20for%20LimeSDR-USB_1v4_LMS031pad/LimeSDR-USB_1v4_schematic_r7.PDF

Have Tx connectors which are spec’ed for 30MHz – 1.9 GHz – with no filtering  - 
my guess they will blast out the same that I was showing – if anyone starts 
looking. (I haven’t got one yet, so I don’t know for sure).

The ones that do have filters (and will not be as bad), are limited to 2.0 GHz 
– 2.6 GHz; or 700 MHz - 900 MHz ; but that is super limiting to a general 
purpose platform.
They also have ones that are 700 MHz - 2.6 GHz (which is super weird – since 
any  3rd harmonic of the LO created internally will mix down anything at 2100 – 
2600 into the 700 – 866 MHz bands).

What we have on Pluto is (sheet 7)
https://wiki.analog.com/_media/university/tools/pluto/hacking/plutosdr_schematic_revb.pdf

Which is the same as what we initially did on the Evaluation/prototyping board:
https://wiki.analog.com/_media/resources/eval/user-guides/ad-fmcomms3-ebz/ad-fmcomms3_reva.pdf

Which is what was done on the miniB200 (for space saving I imagine).
https://files.ettus.com/schematics/b200mini/b200mini.pdf

These class of radios expect additional filtering on the outside of the SMA 
connector. (for both Rx and Tx).


Radios which are not this that class – and can be connected in harsh 
environments, or directly to amps, are like:
https://files.ettus.com/schematics/e310/e310_db.pdf
Those complex filter banks on the Tx/Rx sides are not there because some over 
eager hardware developer. ☺

https://files.ettus.com/schematics/b200/b210.pdf
Uses 3 different baluns on the Rx side, and 2 

Re: [Discuss-gnuradio] cheap sdr platform

[Marcus D. Leech]

On 10/06/2017 07:45 AM, Marcus Müller wrote:


Hi Robin,

Yeah, I didn't mean to imply the Pluto was "worse" than others. It's 
really that as you, and I thought that was really great about your 
talk, showed that SDRs aren't "totally harmless toys". Indeed, I 
hadn't even noticed so far the different band-specific paths of the 
B2x0 were gone on the B200mini!


And yes, who am I to tell you that, but that's the price you pay for 
frequency-agile SDR: Either you spend a lot of money on dedicated 
filtering per band (E310, TwinRX), or you get the cheap flexibility at 
the expense of selectivity. That might be the reason why an R 
spectrum analyzer might be a tad more expensive then the average COTS 
SDR device that we're considering below.


But the fact that you need your own filters, in the end, is – in my 
experience – something that people building systems are very willing 
to accept, because you can use one and the same SDR device that you 
got to know intimately in products which you optimize for the bands 
that you'll actually use in that incarnation of your system by adding 
(relatively cheap) filters for exactly what you care about. That's why 
it makes sense for the B200mini to lack these filters – the form 
factor means it lends itself to systems integration. And that's also 
why it makes sense for the Pluto to not have filters – aside from the 
(extremely nice) price tag, hell, it's an experimentation platform, so 
the flexibility is more important than the raw signal quality.


So, yeah, my wording was misleading there – thank you for the response!


Don't see why you need filters.Analog components with 220dB of 
dynamic range ahead of  27-bit ADCs, and no filters required :)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] sh: .//top_block.py: Permission denied

[Mark Christiansen]

Dangit. I should have thought of that. The executable bit is not set on the
older version.

Thanks.
Mark.

On Fri, Oct 6, 2017 at 5:12 AM, Marcus Müller  wrote:

> Hi Mark,
>
> I can't find the commit right now, but there was a change where we enabled
> the setting of the executable bit for top_block files. Might have happened
> in between these two versions.
>
> Can you check (ls -l top_block.py) whether the 'x' bit for the owner is
> set?
>
> Best regards,
>
> Marcus
>
> On 10/06/2017 04:06 AM, Mark Christiansen wrote:
>
> Any ideas for the Permission denied errors below?
>
> I get the following error on one host running 3.7.6:
>
> $  grcc -e -d . test.grc
> >>> Warning: This flow graph may not have flow control: no audio or RF
> hardware blocks found. Add a Misc->Throttle block to your flow graph to
> avoid CPU congestion.
> sh: .//top_block.py: Permission denied
>
> The same test.grc runs fine on another host running 3.7.10:
>
> $ grcc -e -d . test.grc
> >>> Warning: This flow graph may not have flow control: no audio or RF
> hardware blocks found. Add a Misc->Throttle block to your flow graph to
> avoid CPU congestion.
>
> Thanks.
> Mark.
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Aim for brevity while avoiding jargon.
~ Edsger Dijkstra


Mark Christiansen
about.me/markwc

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

Re: [Discuss-gnuradio] cheap sdr platform

[Getz, Robin]

Streaming (not losing a sample) is different than just “observing” something.

I can capture a buffer of 2 million samples at 50MSPS (20 milliseconds), and 
stream that back slower – that’s longer than the PPDU (PLCP frame) size (5.484 
ms) of 802.11ac

I agree – that’s sub optimal if you want to capture 100s of frames at a time – 
but you can observe, and learn a lot without streaming. We test LTE10 and get 
performance metrics like that, so it can tell you a lot of what’s going on in 
the system.

-Robin

From: Kyeong Su Shin [mailto:kss...@uw.edu]
Sent: Friday, October 06, 2017 3:17 AM
To: Getz, Robin 
Cc: w xd ; GNURadio Discussion List 

Subject: Re: [Discuss-gnuradio] cheap sdr platform

Hello Robin Getz, and to whom it may concern:

Sorry, the number was not based on my experiences - When I said 4MS/s, I was 
referring to the spec sheet ( 
https://wiki.analog.com/university/tools/pluto/devs/specs ) and personal 
experiences from someone else. Maybe that was an outlier, however.

If it can do 10MS/s or higher, then maybe it can be used to observe some 10MHz 
LTE signals as well. Still a bit too slow for the typical 802.11 signals, but 
there are some 802.11 standards using lower bandwidths..

Regards,
Kyeong Su Shin

On Thu, Oct 5, 2017 at 9:01 PM, Getz, Robin 
> wrote:
Sorry for the delay – but there must be a host issue you are having – I can 
stream 8MSPS (no underflows/overflows), and others get higher (12 or so).

If you are only getting 4 – I would be interested in following up, and 
understanding why. It should be much higher.

-Robin

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+robin.getz=analog@gnu.org]
 On Behalf Of Kyeong Su Shin
Sent: Friday, September 29, 2017 9:56 PM
To: w xd >; GNURadio Discussion 
List >
Subject: Re: [Discuss-gnuradio] cheap sdr platform

To whom it may concern:

As Marcus Müller said, ADALM-PLUTO is too slow for LTE/WIFI, unless you can 
come up with clever FPGA-level hacks dedicated for your jobs, or you are okay 
with NOT receiving signals from actual LTE/WIFI transmitters. It can only 
stably stream ~4MS/s(!) of effective sampling rate over USB, and I believe that 
it does not support 8bit streaming mode. I am not sure why it can only do 
approx. 4MS/s - especially since other SDRs can stream faster even with the USB 
2.

I'd also recommend LimeSDR mini (shipping this December, but please be advised 
that it can be delayed further). If you need to get a unit soon, standard 
LimeSDR could be your best bet. Also, if you want to implement your own BTS, 
you may want to look for a device that you can attach a stable external clock 
source.

Regards,
Kyeong Su Shin

On Fri, Sep 29, 2017 at 9:04 AM, Vitt Benv 
> wrote:
Take a look also at LimeSDR... there is a "mini" version for about 150$.
If I recall right it's a fullduplex 12 bit ADC/DDC, ranging 1MHz / 6GHz with 20 
MSPS, with USB port.

https://www.crowdsupply.com/lime-micro/limesdr-mini#details-top

victor

Il 29 set 2017 10:21, "w xd" > 
ha scritto:
Hello guys,

  Have some suggestion on the cheaper SDR platform for us to 
use with the GNURADIO software? As a student, I cannot buy the expensive usrp 
,but I want to learn the knowledge by the hardware and software. Any recommend? 
For example,use the hardware to do some experiments about LTE/WIFI.



___
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] cheap sdr platform

[Marcus Müller]

Hi Robin,

Yeah, I didn't mean to imply the Pluto was "worse" than others. It's 
really that as you, and I thought that was really great about your talk, 
showed that SDRs aren't "totally harmless toys". Indeed, I hadn't even 
noticed so far the different band-specific paths of the B2x0 were gone 
on the B200mini!


And yes, who am I to tell you that, but that's the price you pay for 
frequency-agile SDR: Either you spend a lot of money on dedicated 
filtering per band (E310, TwinRX), or you get the cheap flexibility at 
the expense of selectivity. That might be the reason why an R spectrum 
analyzer might be a tad more expensive then the average COTS SDR device 
that we're considering below.


But the fact that you need your own filters, in the end, is – in my 
experience – something that people building systems are very willing to 
accept, because you can use one and the same SDR device that you got to 
know intimately in products which you optimize for the bands that you'll 
actually use in that incarnation of your system by adding (relatively 
cheap) filters for exactly what you care about. That's why it makes 
sense for the B200mini to lack these filters – the form factor means it 
lends itself to systems integration. And that's also why it makes sense 
for the Pluto to not have filters – aside from the (extremely nice) 
price tag, hell, it's an experimentation platform, so the flexibility is 
more important than the raw signal quality.


So, yeah, my wording was misleading there – thank you for the response!

They also have ones that are 700 MHz - 2.6 GHz (which is super weird – 
since any  3^rd harmonic of the LO created internally will mix down 
anything at 2100 – 2600 into the 700 – 866 MHz bands).
Well, the Ettus B200 works pretty well, but switches between the three 
RX bands at 70MHz–2.2GHz, 2.2–4.0GHz and 4.0–6.0 GHz. I must admit I 
always wondered which black magic was involved to support the nearly 5 
(!) octaves that 70 to 2200 MHz covers on ADI's side.


Best regards,
Marcus

[1] 
https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L54-L60

On 10/06/2017 06:57 AM, Getz, Robin wrote:


Marcus:

It’s not only Pluto that does not have filters, I was trying to make 
the point (maybe not effectively) at GRCon - it’s radios in this “class”.


For example LimeSDR (sheet 5)

https://github.com/myriadrf/LimeSDR-USB/raw/master/hardware/plug/1v4/Project%20Outputs%20for%20LimeSDR-USB_1v4_LMS031pad/LimeSDR-USB_1v4_schematic_r7.PDF

Have Tx connectors which are spec’ed for 30MHz – 1.9 GHz – with no 
filtering  - my guess they will blast out the same that I was showing 
– if anyone starts looking. (I haven’t got one yet, so I don’t know 
for sure).


The ones that do have filters (and will not be as bad), are limited to 
2.0 GHz – 2.6 GHz; or 700 MHz - 900 MHz ; but that is super limiting 
to a general purpose platform.


They also have ones that are 700 MHz - 2.6 GHz (which is super weird – 
since any  3^rd harmonic of the LO created internally will mix down 
anything at 2100 – 2600 into the 700 – 866 MHz bands).


What we have on Pluto is (sheet 7)

https://wiki.analog.com/_media/university/tools/pluto/hacking/plutosdr_schematic_revb.pdf

Which is the same as what we initially did on the 
Evaluation/prototyping board:


https://wiki.analog.com/_media/resources/eval/user-guides/ad-fmcomms3-ebz/ad-fmcomms3_reva.pdf

Which is what was done on the miniB200 (for space saving I imagine).

https://files.ettus.com/schematics/b200mini/b200mini.pdf

These class of radios expect additional filtering on the outside of 
the SMA connector. (for both Rx and Tx).


Radios which are not this that class – and can be connected in harsh 
environments, or directly to amps, are like:


https://files.ettus.com/schematics/e310/e310_db.pdf

Those complex filter banks on the Tx/Rx sides are not there because 
some over eager hardware developer. J


https://files.ettus.com/schematics/b200/b210.pdf

Uses 3 different baluns on the Rx side, and 2 different baluns on the 
Tx side to get some frequency selectivity/filtering.


At GRCon, I was trying to make the point that just because you are 
broadcasting (or receiving) at frequency X, and that looks good, 
doesn’t mean you aren’t broadcasting (or Receiving) on other 
frequencies at the same time (by accident, if you don’t understand the 
limitations/features of the hardware). These are the specs that folks 
(chip companies, or SDR manufactures) don’t talk about, since they are 
hard to understand for the non-hardware person (typically).


-Robin

*From:*Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+robin.getz=analog@gnu.org] *On 
Behalf Of *Marcus Müller

*Sent:* Friday, September 29, 2017 11:47 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] cheap sdr platform

Hi Ed,

as said about the general case, with the ADALM-Pluto's USB2 bandwidth, 
you can barely squeeze in one 20 MHz WiFi Channel if you're using 8 
bit samples, 

Re: [Discuss-gnuradio] cheap sdr platform

[Andrew Back]

On 06/10/17 05:57, Getz, Robin wrote:

> For example LimeSDR (sheet 5)
> 
> https://github.com/myriadrf/LimeSDR-USB/raw/master/hardware/plug/1v4/Project%20Outputs%20for%20LimeSDR-USB_1v4_LMS031pad/LimeSDR-USB_1v4_schematic_r7.PDF
> 
>  
> 
> Have Tx connectors which are spec’ed for 30MHz – 1.9 GHz – with no
> filtering  - my guess they will blast out the same that I was showing –
> if anyone starts looking. (I haven’t got one yet, so I don’t know for sure).

Just to note that this marking was associated with prototype boards and
needs to be updated.

> Radios which are not this that class – and can be connected in harsh
> environments, or directly to amps, are like:
> 
> https://files.ettus.com/schematics/e310/e310_db.pdf
> 
> Those complex filter banks on the Tx/Rx sides are not there because some
> over eager hardware developer. J

Indeed and I believe a low cost, add-on filter board the LimeSDR is also
planned.

Regards,

Andrew

-- 
Andrew Back
http://abopen.com

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

Re: [Discuss-gnuradio] sh: .//top_block.py: Permission denied

[Marcus Müller]

Hi Mark,

I can't find the commit right now, but there was a change where we 
enabled the setting of the executable bit for top_block files. Might 
have happened in between these two versions.


Can you check (ls -l top_block.py) whether the 'x' bit for the owner is set?

Best regards,

Marcus


On 10/06/2017 04:06 AM, Mark Christiansen wrote:

Any ideas for the Permission denied errors below?
I get the following error on one host running 3.7.6:
$  grcc -e -d . test.grc
>>> Warning: This flow graph may not have flow control: no audio or RF hardware 
blocks found. Add a Misc->Throttle block to your flow graph to avoid 
CPU congestion.

sh: .//top_block.py: Permission denied
The same test.grc runs fine on another host running 3.7.10:
$ grcc -e -d . test.grc
>>> Warning: This flow graph may not have flow control: no audio or RF hardware 
blocks found. Add a Misc->Throttle block to your flow graph to avoid 
CPU congestion.

Thanks.
Mark.



___
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] cheap sdr platform

[Kyeong Su Shin]

Hello Robin Getz, and to whom it may concern:

Sorry, the number was not based on my experiences - When I said 4MS/s, I
was referring to the spec sheet (
https://wiki.analog.com/university/tools/pluto/devs/specs ) and personal
experiences from someone else. Maybe that was an outlier, however.

If it can do 10MS/s or higher, then maybe it can be used to observe some
10MHz LTE signals as well. Still a bit too slow for the typical 802.11
signals, but there are some 802.11 standards using lower bandwidths..

Regards,
Kyeong Su Shin

On Thu, Oct 5, 2017 at 9:01 PM, Getz, Robin  wrote:

> Sorry for the delay – but there must be a host issue you are having – I
> can stream 8MSPS (no underflows/overflows), and others get higher (12 or
> so).
>
>
>
> If you are only getting 4 – I would be interested in following up, and
> understanding why. It should be much higher.
>
>
>
> -Robin
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+robin.getz=
> analog@gnu.org] *On Behalf Of *Kyeong Su Shin
> *Sent:* Friday, September 29, 2017 9:56 PM
> *To:* w xd ; GNURadio Discussion List <
> discuss-gnuradio@gnu.org>
> *Subject:* Re: [Discuss-gnuradio] cheap sdr platform
>
>
>
> To whom it may concern:
>
>
>
> As Marcus Müller said, ADALM-PLUTO is too slow for LTE/WIFI, unless you
> can come up with clever FPGA-level hacks dedicated for your jobs, or you
> are okay with NOT receiving signals from actual LTE/WIFI transmitters. It
> can only stably stream ~4MS/s(!) of effective sampling rate over USB, and I
> believe that it does not support 8bit streaming mode. I am not sure why it
> can only do approx. 4MS/s - especially since other SDRs can stream faster
> even with the USB 2.
>
>
>
> I'd also recommend LimeSDR mini (shipping this December, but please be
> advised that it can be delayed further). If you need to get a unit soon,
> standard LimeSDR could be your best bet. Also, if you want to implement
> your own BTS, you may want to look for a device that you can attach a
> stable external clock source.
>
>
>
> Regards,
>
> Kyeong Su Shin
>
>
>
> On Fri, Sep 29, 2017 at 9:04 AM, Vitt Benv  wrote:
>
> Take a look also at LimeSDR... there is a "mini" version for about 150$.
>
> If I recall right it's a fullduplex 12 bit ADC/DDC, ranging 1MHz / 6GHz
> with 20 MSPS, with USB port.
>
>
>
> https://www.crowdsupply.com/lime-micro/limesdr-mini#details-top
>
>
>
> victor
>
>
>
> Il 29 set 2017 10:21, "w xd"  ha scritto:
>
> Hello guys,
>
>
>
>   Have some suggestion on the cheaper SDR platform for us
> to use with the GNURADIO software? As a student, I cannot buy the expensive
> usrp ,but I want to learn the knowledge by the hardware and software. Any
> recommend? For example,use the hardware to do some experiments about
> LTE/WIFI.
>
>
>
>
>
>
> ___
> 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