European GNU Radio Days submission deadline 1 week away

[jean-michel.fri...@femto-st.fr]

A short note to remind potential contributors that the European GNU Radio Days 
2021
submission deadline is 1-week away: https://gnuradio-eu-21.sciencesconf.org/

Best, JM

GNU Radio sink question

[jean-michel.fri...@femto-st.fr]

I have just completed gr-rpitx a GNU Radio sink block for emitting
from Raspberry Pi's GPIO output thanks to F5OEO's librpitx 
(https://github.com/jmfriedt/gr-rpitx) and the dataflow is well scheduled 
as shown with the short movie 
https://github.com/jmfriedt/gr-rpitx/tree/main/examples/gr-rpitx_demo.mp4

However in this implementation, GNU Radio Companion complains that I have
not included a Throttle block since it does not know that the sink is clocked
by hardware. How can I tell GNU Radio that the stream data rate will be defined
by this hardware sink ?

Thanks, JM

Re: B200 clock and pulse timing

[jean-michel.fri...@femto-st.fr]

https://files.ettus.com/schematics/b200/b210.pdf first page U101 is a x4 PLL
that converts the incoming 10 MHz to 40 MHz to feed U2 the AD9361.

JM

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

April 7, 2021 1:17 AM, "Mike"  wrote:

> Hello,
> 
> I’d like to better understand the clock in the B200/B210.
> 
> First, what is the actual resolution of the clock? Is it any more precise 
> than the 100 nanoseconds
> a 10 MHz external reference provides? When the USRP timing is set to 
> external, does the 10 MHz
> directly increment the clock or is the on-board oscillator still involved 
> somehow?
> 
> I’d also like to confirm that my approach to using the B200 clock is correct.
> 
> I'm using a B200 and UHD 3.15.0 under Ubuntu 20.04 and am employing the PPS 
> port as a trigger,
> trying to collect a set number of samples as soon after the a pulse is 
> received on the PPS port as
> possible. I have an external 10 MHz reference feeding the B200, although my 
> understanding is that
> it shouldn’t matter since I’m using the same clock for relative comparisons 
> as described below.
> 
> My software begins streaming samples from the B200 at a fixed rate.
> 
> Inside a loop I call uhd_rx_streamer_recv () and use the associated metadata 
> timestamp to note the
> time the first sample in the read buffer arrived. Obviously the read buffer 
> has a fixed length and
> therefore represents a fixed amount of time at my sample rate; the software 
> uses this value in the
> processing below.
> 
> Also in that loop, the software calls get_time_last_pps() and compares the 
> result to a previous
> get_time_last_pps() call to determine if a pulse arrived on the PPS port.
> 
> Prior to receiving a PPS pulse, this loop continues, discarding the sample 
> buffer after the PPS
> comparison.
> 
> When a pulse arrives, the software compares the sample buffer metadata 
> timestamp to the last PPS
> timestamp. The software uses that time difference to determine if the sample 
> buffer should be
> discarded; the goal is to discard all of the samples that arrived prior to 
> the PPS pulse. If the
> difference between the sample buffer timestamp and the PPS timestamp is 
> greater than the buffer
> length time, the sample buffer is discarded and the uhd_rx_streamer_recv() is 
> called again to read
> the next set of samples.
> 
> When the difference between the most recently read sample buffer timestamp 
> and the PPS timestamp is
> less than the buffer length time, the software drops the first part of the 
> sample buffer
> corresponding to that difference, in essence dropping the samples that 
> arrived prior to the exact
> PPS time. The software then calls uhd_rx_streamer_recv () repeatedly, 
> appending new samples to the
> first partial sample buffer until the desired total number of samples are 
> collected.
> 
> Does this method make sense to achieve my goal of collecting samples 
> immediately after a PPS
> trigger pulse? Is there an easier way to achieve this goal?
> 
> Testing this method has shown that the number of sample buffers returned via 
> the recv() call
> relative to the PPS pulse varies, sometimes significantly. On average, 
> discarding two or three
> sample buffers brings the subsequent sample timestamp to within the fixed 
> buffer length (time) of
> the last PPS pulse.  However, there are circumstances when dozens or even a 
> hundred sample buffers
> need to be discarded because their metadata timestamps are all prior to the 
> PPS timestamp.
> 
> Is it reasonable that the sample buffer timestamp could be so far behind the 
> PPS pulse time on
> occasion?
> 
> Thanks!

Re: Transport stream source

[jean-michel.fri...@femto-st.fr]

Without claiming the in-depth knowledge or the quality of Marcus' scheduler 
presentation,
I just happened to have recorded the first introductory tutorial for 2021 
European GNU
Radio Days at https://www.youtube.com/watch?v=_0xF_eQoSGA

Not sure if it will answer "please direct me to the documentation where the 
basic 
principle of how GNU Radio works is explained" ... 0-MQ and streaming will be 
next but
not (yet) recorded. Any feedback/comments welcome of course for improving the 
material.

JM

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

April 4, 2021 3:13 PM, "Marcus D. Leech"  wrote:

> On 04/04/2021 03:53 AM, Ralf Gorholt wrote:
> 
>> Hi Marcus,
>> 
>> as I have written, I have tried to use a UDP source (and to connect it
>> to a UDP sink with a different IP address and port) but it does not seem
>> to work. As I am quite new to GNU radio, I have certainly made a mistake
>> somewhere. If I only needed a TS source (no matter which one) I could
>> stick with a file. I have already done that and it worked.
>> 
>> Could somebody please direct me to the documentation where the basic
>> principle of how GNU Radio works is explained? I know that there are
>> blocks that you can connect together but there must be a "controller"
>> somewhere and I would like to understand how this controller works and
>> how the blocks are called. What I have read until now does not answer my
>> questions :-)
>> 
>> Happy Easter,
>> 
>> Ralf
> 
> The "controller" that you're talking about in Gnu Radio is called the 
> "scheduler".
> 
> Here's a talk by Marcus Mueller on the subject:
> 
> http://jmfriedt.org/slides_gnuradiodays2019/18h00 MM GR scheduler.pdf
> 
> But I'd also suggest spending time at the gnuradio.org website in the 
> documentation and tutorials
> section. But also, there's the source
> code.

European GNU Radio Days: call for contributions @ https://gnuradio-eu-21.sciencesconf.org/

[jean-michel.fri...@femto-st.fr]

The European GNU Radio Days will be held *virtually* from June 24 to 26, 2021 
with
the core organizers located in Poitiers, France. The objective of the meeting 
is to
foster collaboration between GNU Radio users, developers, hackers and 
enthusiasts
*from all around the world* thanks to the virtual format.

As such, you are welcome to submit a presentation proposal: due to the virtual 
format,
presentations will be recorded and broadcast with hopefully some live 
interaction with
the speakers at the end of the presentation (similar to those who attended 
FOSDEM,
but with humans and not a robot stopping abruptly at the end of the schedule). 
Demonstrations
of practical use cases of GNU Radio would be favored. 

Registration and proposal submission (deadline: *April 15*): 
https://gnuradio-eu-21.sciencesconf.org/

The tentative set of tutorials is scheduled and described at
https://gnuradio-eu-21.sciencesconf.org/resource/page/id/2

The third day (Saturday) will be a joint meeting with the German Software 
Defined Radio
Academy (SDRA) with our contribution focusing on using GNU Radio for ham radio 
applications.
Again contributions in this field will be broadcast during this joint meeting.

We favor complementing the oral presentation demo with a proceeding manuscript 
to be uploaded
to pubs.gnuradio.org if complying with the GRCon template found at 
https://www.gnuradio.org/grcon.tar.gz

For the European GNU Radio organization committee,
looking forward to meeting you virtually in June, JM

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

GNU Radio on buildroot: FOSDEM proceeding now available

[jean-michel.fri...@femto-st.fr]

If anyone is interested, I just managed to meet the deadline of
translating the tutorial on GNU Radio port to Buildroot prior to
the SDR session at FOSDEM: the manuscript is at
http://jmfriedt.free.fr/hackable_buildroot_eng.pdf

The French speaking audience will have to wait for the April issue
of Hackable Magazine for the printed version.

Best, JM

Re: Jamming the WiFi channel

[jean-michel.fri...@femto-st.fr]

We might hide or we might discuss ... jamming systems are less than 10 euros on 
amazon [0]
for any script-kiddie to play with including myself [1]. Why anyone one would 
want to 
implement this in SDR rather than a NE555+VCO is beyond my understanding by why 
not ...
we even got to reverse engineer such a device to check its performance. The 
military
will pay you for doing this [2] (and a bit more) so rather than hiding from the 
real 
world we might as well face it and educate users.

My (useless) 2 cents, but thank you for the most informative reference and its 
introductory 
citation
JM

[0] 
https://www.amazon.fr/IrahdBowen-Bloqueur-Bouclier-Brouilleur-Disjoncteur/dp/B07KSC5LLD
[1] http://jmfriedt.free.fr/misc_deleurrage.pdf [in French] on GPS jamming and 
jamming cancellation
[2] 
https://www.defense.gouv.fr/aid/appels-a-projets/appel-a-projets-pour-une-mini-charge-utile-d-appui-electronique-sur-drones
 [in French]

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

January 17, 2021 6:24 PM, "Aditya Arun Kumar"  
wrote:

> Hi Derek,
> Yeah, I accept all the things, after all, I have to, as I tend to wireless 
> systems and their
> security and some more stuff with regards to radios and SDR and things. But 
> what I suggest is that
> we guys start a separate application/discussion area for these kinds of 
> things (because I
> personally as well to some extent historically believe[ 
> https://doi.org/10.1080/03071847709428739
> ]) that this must be an integral part of the ecosystem. I accept the part 
> where one needs to have
> proper RF enclosures or a SCIF to conduct these emission experiments (unless 
> it a wide range of
> open testing).
> 
> I propose that we have a separate discussion for things like this, just for 
> educational purposes,
> because I feel that there is too much "Telecommunications" research 
> happening, but very quiet a
> limited discussion regarding "What is the best way to build a signal for a 
> jammer from its spectra"
> or "What happens in spatial resolution compromise in a RADAR system and how 
> this can be a problem".
> Basically, I am trying to say let's break the taboo about the discussion 
> about EW and SIGINT and
> ELINT using SDR and GRC. After all, radios are fun.
> 
> This part goes to Mr.Robert
> In my humble opinion sir, I don't agree with you not one bit. Technology is a 
> dual-edged sword, and
> radio is a knife with jagged and pointy edges everywhere. There is no concept 
> of morality (at least
> it cannot be quantified by any metric). EW is an integral part of our life 
> now. And people who are
> into it can and should be able to learn it, no matter what, no matter the 
> cost. This is knowledge
> and as I can say GRC taught me a lot, in terms of learning and sharing their 
> knowledge be it in
> blogs or conferences or this mail list. In fact, this kind of question needs 
> to be encouraged but
> with significant warning labels around them.
> 
> On Sun, Jan 17, 2021 at 9:32 PM Robert Heerekop  
> wrote:
> 
>> To my humble opinion, this is simply not allowed and must therefore from a 
>> moral point-a-view not
>> be promoted.
>> 
>> Op zo 17 jan. 2021 16:29 schreef Aditya Arun Kumar 
>> :
>> 
>>> On a serious note, I know that all of us know how to build a jammer, in 
>>> case of questions like this
>>> how do we deal with it?
>>> I mean I can do both sides, in the spirit of sharing the knowledge I think 
>>> that someone should tell
>>> the person who is doing it on how to build a jammer (in this case) or 
>>> should we not help the
>>> person?
>>> Or should we condemn these acts?
>>> 
>>> On Sun, Jan 17, 2021 at 10:15 AM Doug McGarrett  
>>> wrote:
>>> 
 On 1/16/21 10:58 PM, paulles...@mailo.com wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Mailo *1 fichier disponible au téléchargement*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> * hackrf2.png (35 Ko)
> 
> Vous pouvez télécharger ce fichier en cliquant sur ce lien ou en le
> copiant dans la barre d'adresse de votre navigateur
> 
 
> 
> 
 https://www.mailo.com/attachlinks.php?id=MTg2NDQuPGVhLW1pbWUtNjAwM2I1Y2ItMTRjNS0yN2Q0OGNlZUB3d3ctMS5
 YWlsby5jb20%2b
> 
> Ce lien restera valable pendant 30 jours.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hello, I have build a VCO jammer 

Re: trying to play two radio stations simultaneously

[jean-michel.fri...@femto-st.fr]

First of all, thank you for the feedback and letting me know that someone has 
watched
the video :)

I believe the issue with your flowgraph is that the second channel is too far 
from the
center frequency: with 800 kHz offset with respect to the center frequency and 
a span
of 1.536 MHz (spectrum spanning from -768 kHz to +768 kHz) you are looking at 
the alias
at -736 kHz (768-(800-768)). If you don't have two stations closer than 800 
kHz, then
I would select a center frequency (OsmoSDR source) in between the two stations, 
and shift one
station by +400 kHz and the other by -400 kHz. Both stations will fit nicely 
within
the available bandwidth of 1.536 MHz with no risk of aliasing with one station 
being
at the very limit of the spectrum with its boundary at the Nyquist frequency 
(half the sampling
rate).

As I had received another request this morning, I am trying to upload my 
flowgraphs (GRC 3.8)
at http://jmfriedt.free.fr/, hitting on the left menu "Licence 3 EEA" and 
scrolling down to the
video links, but I only saved some of the more complex flowgraphs (RDS 
decoding, phase synchronization
simulation and POCSAG decoding at the moment). I must re-generate the other 
flowgraphs by watching
my own video and remembering what I said ! This is excellent feedback though to 
improve teaching
material, thank you.

JM

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

January 11, 2021 6:13 PM, "Chris Gorman"  wrote:

> Hello All,
> 
> I'm trying out jean-michel.friedt's course on digital communications
> and have a problem with getting two radio stations to play
> simultaneously. I have tried to follow jean-michel's example, but am
> getting caught somewhere. I get one radio station and hiss on the
> other.
> 
> I've tried a few combinations, but haven't got a logical successful
> solution. I am choosing two local radio stations and can tune them
> independently. The first radio station is the osmocom source ch0
> frequency. This station I can tune without trouble. The second
> station is determined by s frequency translating filter and I make the
> center frequency a negative difference between the ch0 frequency and
> it's nearest neighbour. In this case I'm choosing ch0 frequency
> 90.7e6 and center frequency -800e3. (For a radio station at 91.5
> MHz.) Somewhere here I am getting into trouble. This station can be
> heard but is mostly hiss.
> 
> I'm including my grc file and a screenshot of my flow graph with the
> hope that someone can point me to my error. Thanks in advance.
> 
> Chris

digital communication undergraduate course

[jean-michel.fri...@femto-st.fr]

Dear GNU Radio community,
due to lockdown restricted access of students to universities, I have recorded
videos for the undergraduate course on Digital Communication. As I try to 
illustrate
most concepts of discrete time digital signal processing with GNU Radio (and 
GNU/Octave
when needed for post-processing), I thought this community might be interested. 
Please
remember that as a physicist by training, I have no basic knowledge on digital 
communication or SDR other than my own experience, so some topics might be 
either wrong 
or misrepresented, or both. This year's work has been to shift all (most ?) 
slides
and demonstrations to GNU Radio 3.8. Feedback, comments and error reports are 
of course
welcome. All videos are at http://jmfriedt.free.fr/ under "Licence 3 EEA" 
(bachelor
degree -- electronics engineering):

http://jmfriedt.free.fr/TI2020_1.mp4 (1.5 h) -- Introduction, hardware, AM 
(aeronautical communication)

http://jmfriedt.free.fr/TI2020_2.mp4 (1.5 h) -- Modulations (FM, PM) -- 
application 
to broadcast commercial FM and NOAA LEO satellite reception

http://jmfriedt.free.fr/TI2020_3.mp4 (1.0 h) -- Division Multiple Access, 
application to receiving multiple FM stations and POCSAG decoding using 
external 
software

http://jmfriedt.free.fr/TI2020_4.mp4 (1.43 h) -- CDMA and GPS decoding. I 
forgot to mention the link http://jmfriedt.org/gps/gps_lab.tar.gz 
with datasets collected with a RTL-SDR DVB-T dongle at 1.57542 GHz carrier 
frequency 
and a rate of 1.023 MS/s fitted with an active GPS antenna polarized by a 5-V 
bias T.

http://jmfriedt.free.fr/TI2020_5.mp4 (45 min) -- pulse compression and link 
budget

http://jmfriedt.free.fr/TI2020_6.mp4 (1h40) -- antenna basics

http://jmfriedt.free.fr/TI2020_7.mp4 (45 min) -- channel capacity, Shannon 
theorem

http://jmfriedt.free.fr/TI2020_8.mp4 (1h40) -- synchronization and digital 
processing 
of radiofrequency signals 

Hoping that someone might find these useful and provide feedback,
best, JM

Re: GNU Radio on Raspberry Pi 4?

[jean-michel.fri...@femto-st.fr]

The benchmark on volk/64 bit kernel v.s 32 bit Raspbian is at 
https://pubs.gnuradio.org/index.php/grcon/article/view/73/55
last page. I get 3 to 7-fold improvement by volk_config on a dedicated
toolchain for 64-bit CPU.

JM

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

December 17, 2020 10:28 AM, "Kristoff"  wrote:

> HI all,
> 
> I also have a RPi4 (*).
> Some follow-up question.
> 
> What OS would be the best for this?
> Would running 64 bit make a difference?
> 
> I don't know to what degree this is related, but I did a test running 
> WebGL (**) on that pi, and I got about 1/3 of the frames per second on 
> my RPi4 compared to my laptop (which only has a UHD Graphics 630 Mobile, 
> so not the  best or latest neither)
> Is the GPU in the Pi4 good enough to run many GUI elements in GNU Radio 
> at the same time?
> 
> Kr.
> 
> (*) RPi4B 8 GB, 120 SSD
> 
> (*) https://webglsamples.org
> 
> On 16/12/2020 11:10 p.m., Dan Romanchik KB6NU wrote:
> 
>> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased
>> an RTL-SDR dongle and thought it would be fun to experiment a little
>> with GNU Radio and learn something about SDR.
>> 
>> A couple of days ago, I fired up GNU Radio, and after having some
>> trouble figuring out how to get the audio sink to talk to the Pi, I
>> downloaded VE6EY's FM receiver flow graph. The flow graph runs, but
>> the Pi 4 just doesn't seem to have enough horsepower to run it in real
>> time. The audio is slow and distorted.
>> 
>> Thinking that it might be the WX widgets slowing down the program, I
>> first deleted the FFT display widgets, then converted the WX slider
>> controls to QT range controls. Neither had any effect on how well the
>> flow graph ran.
>> 
>> GQRX and CubicSDDR seem to work just fine. At least with both of them,
>> I'm able to receive FM broadcast and NOAA weather station. But, maybe
>> the PI4 just doesn't have enough horsepower to run GNU Radio? If so,
>> that's kind of disappointing.
>> 
>> 73! <—ham radio lingo for “best regards"
>> 
>> *Dan KB6NU*
>> CW Geek, Ham Radio Instructor
>> Author of the "No Nonsense" amateur radio license study guides
>> Read my ham radio blog at http://www.kb6nu.com

Re: GNU Radio on Raspberry Pi 4?

[jean-michel.fri...@femto-st.fr]

Forgot to Cc: the mailing list for the record:

> You will find at http://jmfriedt.free.fr/projetM1_2020_2.pdf the description
> of our use of the sound card of the Pi4 on slide 4. Prior to running the 
> sound card
> with GNU Radio, we tested with the speaker-test application by
> 1/ activating the sound card by adding in config.txt of the first VFAT 
> partition
> the option dtparam=audio=on
> 2/ when booting, the dmesg must display 
> bcm2835_audio bcm2835_audio: card created with 8 channels
> 3/ in buildroot, alsa-utils in Target packages -> Audio and video 
> applications provides
> speaker test and executing
> speaker-test -t sine -f 440
> should play a tone on the speaker output.
> 
> JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
> France
> 
> December 16, 2020 11:40 PM, "Dan Romanchik KB6NU"  wrote:
> 
>> Has anyone successfully run GNU Radio on a Pi 4? I recently purchased an 
>> RTL-SDR dongle and thought
>> it would be fun to experiment a little with GNU Radio and learn something 
>> about SDR.
>> 
>> A couple of days ago, I fired up GNU Radio, and after having some trouble 
>> figuring out how to get
>> the audio sink to talk to the Pi, I downloaded VE6EY's FM receiver flow 
>> graph. The flow graph runs,
>> but the Pi 4 just doesn't seem to have enough horsepower to run it in real 
>> time. The audio is slow
>> and distorted.
>> 
>> Thinking that it might be the WX widgets slowing down the program, I first 
>> deleted the FFT display
>> widgets, then converted the WX slider controls to QT range controls. Neither 
>> had any effect on how
>> well the flow graph ran.
>> 
>> GQRX and CubicSDDR seem to work just fine. At least with both of them, I'm 
>> able to receive FM
>> broadcast and NOAA weather station. But, maybe the PI4 just doesn't have 
>> enough horsepower to run
>> GNU Radio? If so, that's kind of disappointing.
>> 
>> 73! <—ham radio lingo for “best regards"
>> 
>> Dan KB6NU
>> CW Geek, Ham Radio Instructor
>> Author of the "No Nonsense" amateur radio license study guides
>> Read my ham radio blog at http://www.kb6nu.com

European GNU Radio Days conference -- Poitiers (France) & virtual -- 24 to 26 June, 2021: call for contributions

[jean-michel.fri...@femto-st.fr]

The European GNU Radio Days is a conference to be held in Poitiers (France) 
aimed
at promoting the exchange of development results, experience and tutorials using
the GNU Radio framework. It will be held from June 24th to 26th, 2021. Under 
the 
assumption of lockdown restrictions to still limit gatherings and travels, a 
strong 
emphasis on virtual events is considered, most significantly with a shared 
session on
Saturday with the Software Defined Radio Academy (SDRA) in Friedrichshafen 
focusing
on presentations targeting the ham radio community. Thus, oral presentations 
will
be streamed while participants are encouraged to interact through a discussion 
forum
in complement to the tentative live meeting in Poitiers.

The call for contributions is open at https://gnuradio-eu-21.sciencesconf.org

The first day of the conference is dedicated to oral and poster presentations
as well as technical demonstrations. The second day is dedicated to tutorials, 
whose
tentative program is shared at 
https://gnuradio-eu-21.sciencesconf.org/resource/page/id/2
The third day will focus on ham radio applications of GNU Radio with a joint 
session
with SDRA.

The call for contribution deadline is April 15, 2021. While attending the
conference is free of charge, subscription is mandatory for organization
requirements: the deadline for registering is May 1st, 2021.

Web site of the conference: https://https://gnuradio-eu-21.sciencesconf.org//

Hoping to meet many of you -- virtually or live -- during the summer in 
Poitiers.

Jean-Michel, for the European GNURadio Day's organization committee

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, 
France

Re: GNURADIO doesn't find USRP B205

[jean-michel.fri...@femto-st.fr]

you forgot to highlight in your message the answers given by libuhd:

> Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow the 
> below instructions to
> download the images package.
> 
> Please run:
> 
> "/usr/lib/arm-linux-gnueabihf/uhd/utils/uhd_images_downloader.py"
 
JM

Re: aliasing with X310 BasicRX (higher order Nyquist zone) ?

[jean-michel.fri...@femto-st.fr]

Thank you for pointing out the inconsistency of my analysis: the considered 
Nyquist
zone is during sampling, and not during decimation. Setting LO to 56.95 MHz 
works
perfectly, thank you.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

July 20, 2020 5:43 PM, "Brian Padalino"  wrote:

> On Mon, Jul 20, 2020 at 11:32 AM jean-michel.fri...@femto-st.fr 
> 
> wrote:
> 
>> Indeed second Nyquist zone before decimation.
>> My thought was
>> 143.05 MHz -> transpose by 100 MHz using the DDC (NCO at 100 MHz considering 
>> the
>> 200 MHz sampling rate) to reach 43.05, and after transposition, decimating 
>> to reach
>> 8 MS/s (I do have Epcos B3607 SAW filters 140+/-3 MHz frontend to select 
>> only the
>> signal I am interested in).
>> It is in the decimation process that I was thinking of being in the third
>> Nyquist zone after decimation, which is incorrect because 8 MS/s is -4 to 
>> +4, so that
>> 43.05 is in the 6th Nyquist zone after decimation (\in[36:44] MHz).
> 
> This seems weird.
> 
> Sampling 143.05MHz at 200MHz real will produce the desired signal at 56.95MHz 
> and conjugated, won't
> it? Since it's real, it'll appear at both positive and negative frequencies, 
> with the negative
> component being conjugated.
> So if you mix with 56.95MHz, it will take the conjugated negative signal of 
> the conjugated desired
> signal and mix it to 0Hz. Then you can go through the decimation filtering 
> however you want and
> everything is centered at 0Hz.
> 
> Right?
> 
> Brian

Re: aliasing with X310 BasicRX (higher order Nyquist zone) ?

[jean-michel.fri...@femto-st.fr]

Indeed second Nyquist zone before decimation.
My thought was
143.05 MHz -> transpose by 100 MHz using the DDC (NCO at 100 MHz considering 
the 
200 MHz sampling rate) to reach 43.05, and after transposition, decimating to 
reach 
8 MS/s (I do have Epcos B3607 SAW filters 140+/-3 MHz frontend to select only 
the 
signal I am interested in). 
It is in the decimation process that I was thinking of being in the third 
Nyquist zone after decimation, which is incorrect because 8 MS/s is -4 to +4, 
so that
43.05 is in the 6th Nyquist zone after decimation (\in[36:44] MHz).

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

July 20, 2020 5:20 PM, "Marcus D. Leech"  wrote:

> On 07/20/2020 07:37 AM, jean-michel.fri...@femto-st.fr wrote:
> 
>> I'd like to analyze a higher Nyquist zone with a X310 fitted with a BasicRX:
>> trying to listen at 143.5 MHz (GRAVES), I can transpose by 100 MHz but am 
>> still
>> far from the ~8 MS/s sampling I can use on the Gb Ethernet interface. Since 
>> the
>> signal is only in the third Nyquist zone, I'd like to tell the BasicRX/DDC 
>> *not*
>> to anti-alias (CIC filter ?) the received signal. It tried playing with the
>> Bandwidth parameter of the USRP Sink but no improvement there.
>> 
>> Is there a way to alias on purpose the signal with X310+BasicRX ?
>> 
>> Thanks, JM
>> 
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>> 25000 Besancon, France
> 
> The X310 has a 200MHz ADC clock by default, so 143.5MHz would be in the 2nd 
> Nyquist zone, would it
> not?

aliasing with X310 BasicRX (higher order Nyquist zone) ?

[jean-michel.fri...@femto-st.fr]

I'd like to analyze a higher Nyquist zone with a X310 fitted with a BasicRX:
trying to listen at 143.5 MHz (GRAVES), I can transpose by 100 MHz but am still
far from the ~8 MS/s sampling I can use on the Gb Ethernet interface. Since the
signal is only in the third Nyquist zone, I'd like to tell the BasicRX/DDC *not*
to anti-alias (CIC filter ?) the received signal. It tried playing with the
Bandwidth parameter of the USRP Sink but no improvement there.

Is there a way to alias on purpose the signal with X310+BasicRX ?

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

Re: GPIO lines on RPi4

[jean-michel.fri...@femto-st.fr]

To complete this demonstration of running a TCP server from within the 
GNU Radio Companion flowchart without modifying the generated Python code,
and correcting a mistake in the post below so that I can also update the Signal
Source frequency, I have uploaded
 
http://jmfriedt.org/2020-07-17-140636_2704x1050_scrot_ann.png 

(and removed the erroneous screenshots cited in the previous messages).

Gwenhael Goavec explained to me the mistake I was doing: when calling tt=t.t()
(since t is the Id of the flowchart) from the thread, I was creating a new 
instance of the whole flowchart, whose frequency variable did not match the 
one defining the frequency source signal that was being displayed.
Instead of creating a new instance of the flowchart in the thread, the argument 
"self"
must be provided when creating the thread. Then, the variables and methods from 
the
calling class can be accessed and indeed, changing the signal source frequency 
does
lead to a change in the displayed spectrum.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 30, 2020 10:10 AM, jean-michel.fri...@femto-st.fr wrote:

> Thanks to this comment, I ended up finding a solution to call a thread
> running a TCP/IP server able to control the variables from the main
> processing flowchart, without modifying manually the generated Python for a Qt
> application.
> A screenshot, which I hope is self-explanatory, illustrating this process is 
> at
> http://jmfriedt.org/2020-06-30-083722_2704x1050_scrot.png
> 
> However I am facing a surprising result.
> I initially (see above) created a signal source, set its frequency to a 
> variable flo, 
> checked with a slider that changing flo did change the output frequency, 
> removed the 
> slider and set the signal source flo from my server. No change in the 
> frequency output.
> 
> So I went back to my initial setup in which I change not only the source 
> signal
> frequency but also the receiver hardware LO frequency of the B210, keeping 
> the TX LO
> fixed. And surely enough both a spectrum analyzer and the coupled output from 
> the
> B210 TX to the RX show the signal shifting.
> 
> Screenshots at
> http://jmfriedt.org/2020-06-30-095336_2704x1050_scrot.png show that the 
> callback function
> for the source frequency or LO frequency are exactly the same and so are the 
> server handling
> functions, while
> http://jmfriedt.org/2020-06-30-095712_2704x1050_scrot.png shows that the B210 
> TX frequency
> only changes when tuning the hardware LO, not the signal source LO.
> 
> Is there some signal that needs to be sent to the signal source beyond
> self.analog_sig_source_x_0.set_frequency(self.flo)
> to tell it to change frequency ?
> 
> Thanks, JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
> 
> June 22, 2020 1:25 PM, "Marcus Müller"  wrote:
> 
>> It gets even better:
>> 
>> We've launched a feature in 3.8.1.0 (and on master before that, as we do
>> with any feature that ends up in a maintenance release) that we hope
>> doesn't come back to bite us due to enabling unclean design. But, we
>> must build best practices so that it doesn't go unused, either, so:
>> 
>> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
>> something), you can make use of the "Python Snippets" in GRC.
>> 
>> Cheers,
>> Marcus
>> 
>> On 18/06/2020 23.17, Marcus D. Leech wrote:
>> 
>>> On 06/18/2020 03:54 PM, jean-michel.fri...@femto-st.fr wrote:
>> 
>> My approach:
>> * build your grc chart from GNU Radio Companion and generate the .py file
>> * edit the py file and import pygpio
>> * play with the RPi4 GPIO in your python script.
>> 
>> See attached script, with a python server included in the Python script
>> to control an RF switch from a GNU Octave TCP/IP client talking to the
>> Python
>> TCP/IP server.
>> 
>> I am presenting this approach to hardware control at
>> http://jmfriedt.free.fr/sdra_radar.pdf
>> 
>> JM
>>> If you use "Python Module" block, you can write a lot of
>>> non-GnuRadio-esque python, import anything you want, etc, etc. No editing
>>> of the output python required, necessarily.
>> 
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>> 25000 Besancon, France
>> 
>> June 18, 2020 9:40 PM, "Da Fy"  wrote:
>>> Hi All, does anyone have an example of how to control GOIO lines on
>>> the RPi4 from within a GRC
>>> flowgraph. I’m guessing it’s an OOT module.
>>> 
>>> I need to generate a signal of a few 100Hz & control GPIO lines at
>>> various points though the cycle.
>>> 
>>> Alternatively, I could generate the signal & lines with external
>>> hardware & read them with
>>> GnuRadio.
>>> 
>>> Tnx, Dave

Re: Making C++ OOT module and wish to set up a parameter with different choices!

[jean-michel.fri...@femto-st.fr]

I do not claim to cover all aspect of OOT blocks but I tried to document the 
basics of 
passing parameters and public/private variables at 
http://jmfriedt.free.fr/gr_oscilloscope_eng.pdf

Unfortunately this document only covers GNU Radio 3.7: while the French version 
was extended to
GNU Radio 3.8, the English version was not extended accordingly but I'd be 
happy to do so if there
is any interest.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 30, 2020 7:06 PM, "George Edwards"  wrote:

> Hello,
> 
> I am making a C++ OOT module and wish to have an input parameter 
> "frame_length" with different
> choices. I would like to provide short, medium and long frames with a value 
> attached to each. Based
> on the OOT syntax, I can enter "frame_length" as an input argument to the 
> model. Now, how can I set
> up the inners of the *.cc file so that when the module is built into a 
> Gnuradio block, I can simply
> click on 'frame_length' to see the choices and select one?
> 
> Thanks for the help.
> 
> Regards,
> George

Re: GPIO lines on RPi4

[jean-michel.fri...@femto-st.fr]

Thanks to this comment, I ended up finding a solution to call a thread
running a TCP/IP server able to control the variables from the main
processing flowchart, without modifying manually the generated Python for a Qt
application.
A screenshot, which I hope is self-explanatory, illustrating this process is at
http://jmfriedt.org/2020-06-30-083722_2704x1050_scrot.png

However I am facing a surprising result.
I initially (see above) created a signal source, set its frequency to a 
variable flo, 
checked with a slider that changing flo did change the output frequency, 
removed the 
slider and set the signal source flo from my server. No change in the frequency 
output.

So I went back to my initial setup in which I change not only the source signal
frequency but also the receiver hardware LO frequency of the B210, keeping the 
TX LO
fixed. And surely enough both a spectrum analyzer and the coupled output from 
the
B210 TX to the RX show the signal shifting.

Screenshots at
http://jmfriedt.org/2020-06-30-095336_2704x1050_scrot.png show that the 
callback function
for the source frequency or LO frequency are exactly the same and so are the 
server handling
functions, while
http://jmfriedt.org/2020-06-30-095712_2704x1050_scrot.png shows that the B210 
TX frequency
only changes when tuning the hardware LO, not the signal source LO.

Is there some signal that needs to be sent to the signal source beyond
self.analog_sig_source_x_0.set_frequency(self.flo)
to tell it to change frequency ?

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 22, 2020 1:25 PM, "Marcus Müller"  wrote:

> It gets even better:
> 
> We've launched a feature in 3.8.1.0 (and on master before that, as we do 
> with any feature that ends up in a maintenance release) that we hope 
> doesn't come back to bite us due to enabling unclean design. But, we 
> must build best practices so that it doesn't go unused, either, so:
> 
> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release 
> something), you can make use of the "Python Snippets" in GRC.
> 
> Cheers,
> Marcus
> 
> On 18/06/2020 23.17, Marcus D. Leech wrote:
> 
>> On 06/18/2020 03:54 PM, jean-michel.fri...@femto-st.fr wrote:
>>> My approach:
>>> * build your grc chart from GNU Radio Companion and generate the .py file
>>> * edit the py file and import pygpio
>>> * play with the RPi4 GPIO in your python script.
>>> 
>>> See attached script, with a python server included in the Python script
>>> to control an RF switch from a GNU Octave TCP/IP client talking to the
>>> Python
>>> TCP/IP server.
>>> 
>>> I am presenting this approach to hardware control at
>>> http://jmfriedt.free.fr/sdra_radar.pdf
>>> 
>>> JM
>> 
>> If you use "Python Module" block, you can write a lot of
>> non-GnuRadio-esque python, import anything you want, etc, etc.  No editing
>> of the output python required, necessarily.
>> 
>>> --
>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>>> 25000 Besancon, France
>>> 
>>> June 18, 2020 9:40 PM, "Da Fy"  wrote:
>> 
>> Hi All, does anyone have an example of how to control GOIO lines on
>> the RPi4 from within a GRC
>> flowgraph. I’m guessing it’s an OOT module.
>> 
>> I need to generate a signal of a few 100Hz & control GPIO lines at
>> various points though the cycle.
>> 
>> Alternatively, I could generate the signal & lines with external
>> hardware & read them with
>> GnuRadio.
>> 
>> Tnx, Dave

Re: GPIO lines on RPi4

[jean-michel.fri...@femto-st.fr]

I am definitely not knowledgeable about Python so I might be missing
the basics: as I want to include a TCP server for tuning the acquisition
parameters, it seems to me (but I might be wrong) that the Python Module
is more appropriate than the Python Snippet which seems to add a piece
of code to the main() Python flowgraph function.
The TCP server in the Python Module I have written must change the USRP LO
frequency so in my Python Module I
import t
since t is my GRC flowchart name and I create tt=t.t() which allows me to
change e.g. the LO frequency variable f with tt.f=tt.f+1 or change the
LO frequency itself by calling tt.set_f(tt.f). This is all good in a CLI 
application
as the one running on the RPi4, and working nicely.
However for educational purposes I wanted to demonstrate the same principle with
a Qt Application and in this case I get the error message
QWidget: Must construct a QApplication before a QWidget
which I assume is due to the definition of the class
class t(gr.top_block, Qt.QWidget):
requiring a Qt.QWidget when I define tt=t.t() which is not yet defined as
Qt.QApplication.setGraphicsSystem(style)
qapp = Qt.QApplication(sys.argv)

Is there a proper way of accessing the variables and the functions of the main 
GRC
flowchart from my Python Module, also applicable in the case of a Qt 
Application ?

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 22, 2020 1:25 PM, "Marcus Müller"  wrote:

> It gets even better:
> 
> We've launched a feature in 3.8.1.0 (and on master before that, as we do 
> with any feature that ends up in a maintenance release) that we hope 
> doesn't come back to bite us due to enabling unclean design. But, we 
> must build best practices so that it doesn't go unused, either, so:
> 
> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release 
> something), you can make use of the "Python Snippets" in GRC.
> 
> Cheers,
> Marcus
> 
> On 18/06/2020 23.17, Marcus D. Leech wrote:
> 
>> On 06/18/2020 03:54 PM, jean-michel.fri...@femto-st.fr wrote:
>>> My approach:
>>> * build your grc chart from GNU Radio Companion and generate the .py file
>>> * edit the py file and import pygpio
>>> * play with the RPi4 GPIO in your python script.
>>> 
>>> See attached script, with a python server included in the Python script
>>> to control an RF switch from a GNU Octave TCP/IP client talking to the
>>> Python
>>> TCP/IP server.
>>> 
>>> I am presenting this approach to hardware control at
>>> http://jmfriedt.free.fr/sdra_radar.pdf
>>> 
>>> JM
>> 
>> If you use "Python Module" block, you can write a lot of
>> non-GnuRadio-esque python, import anything you want, etc, etc.  No editing
>> of the output python required, necessarily.
>> 
>>> --
>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>>> 25000 Besancon, France
>>> 
>>> June 18, 2020 9:40 PM, "Da Fy"  wrote:
>> 
>> Hi All, does anyone have an example of how to control GOIO lines on
>> the RPi4 from within a GRC
>> flowgraph. I’m guessing it’s an OOT module.
>> 
>> I need to generate a signal of a few 100Hz & control GPIO lines at
>> various points though the cycle.
>> 
>> Alternatively, I could generate the signal & lines with external
>> hardware & read them with
>> GnuRadio.
>> 
>> Tnx, Dave

Re: Radar Project - BladeRF2.0

[jean-michel.fri...@femto-st.fr]

SDR based RADAR will be discussed at 6:30 PM European time as
announced at https://2020.sdra.io/pages/programme.html

The slides are at http://jmfriedt.free.fr/sdra_radar.pdf

RThe reference on slide 17 explains how to switch LO frequency without
stopping the data stream when using osmosdr. Not sure how it is applicable
to the BladeRF.

JM 

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 24, 2020 3:04 PM, "Dionísio de Carvalho"  wrote:

> hi everybody
> This is my fisrt message here. I am pretty new in the SDR world.
> 
> I am intended to develop a Radar with BladeRF2.0 from Nuand.
> Is anybody in this boat?
> 
> I have some start questions that I will be grateful for any help:
> 
> - How can I sweep the Frequency at osmocom-sink? any idea?
> - How can I figure out the TX power? I am trying to measure an antenna S21 
> parameter!
> 
> thanks for any help
> 
> Att
> 
> Dionisio Carvalho
> Sao Paulo University - Brazil

Re: GPIO lines on RPi4

[jean-michel.fri...@femto-st.fr]

The envisioned application is event driven: send a control word from a client,
wait for the even to complete (e.g. move antenna to target position), start
streaming data for a given amount of time, and when enough data is collected 
move
to new position. Of course timing cannot be relied on with a non-real time 
multitasking
operating system whose load is not predictable.

I did use successfully Python Module to implement the server and tune the UHD 
parameters
during the week end without editing the Python code (why the Python Module must 
be entered
through the GRC Python editor and not externally for the updates not to be lost 
is still
not yet understood). Will have a look at this new Python Snippet feature.

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 22, 2020 2:05 PM, "Albin Stigö"  wrote:

> It might be difficult to control GPIO with precise timing on raspberry pi 
> depending on what you
> want to do... A few hundred khz might be ok though. libgpiod is the new 
> better Linux GPIO API.
> 
> --Albin
> 
> On Mon, Jun 22, 2020, 13:25 Marcus Müller  wrote:
> 
>> It gets even better:
>> 
>> We've launched a feature in 3.8.1.0 (and on master before that, as we do
>> with any feature that ends up in a maintenance release) that we hope
>> doesn't come back to bite us due to enabling unclean design. But, we
>> must build best practices so that it doesn't go unused, either, so:
>> 
>> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
>> something), you can make use of the "Python Snippets" in GRC.
>> 
>> Cheers,
>> Marcus
>> 
>> On 18/06/2020 23.17, Marcus D. Leech wrote:
>>> On 06/18/2020 03:54 PM, jean-michel.fri...@femto-st.fr wrote:
>>>> My approach:
>>>> * build your grc chart from GNU Radio Companion and generate the .py file
>>>> * edit the py file and import pygpio
>>>> * play with the RPi4 GPIO in your python script.
>>>> 
>>>> See attached script, with a python server included in the Python script
>>>> to control an RF switch from a GNU Octave TCP/IP client talking to the
>>>> Python
>>>> TCP/IP server.
>>>> 
>>>> I am presenting this approach to hardware control at
>>>> http://jmfriedt.free.fr/sdra_radar.pdf
>>>> 
>>>> JM
>>> If you use "Python Module" block, you can write a lot of
>>> non-GnuRadio-esque python, import anything you want, etc, etc. No editing
>>> of the output python required, necessarily.
>>> 
>>> 
>>>> 
>>>> --
>>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>>>> 25000 Besancon, France
>>>> 
>>>> June 18, 2020 9:40 PM, "Da Fy"  wrote:
>>>> 
>>>>> Hi All, does anyone have an example of how to control GOIO lines on
>>>>> the RPi4 from within a GRC
>>>>> flowgraph. I’m guessing it’s an OOT module.
>>>>> 
>>>>> I need to generate a signal of a few 100Hz & control GPIO lines at
>>>>> various points though the cycle.
>>>>> 
>>>>> Alternatively, I could generate the signal & lines with external
>>>>> hardware & read them with
>>>>> GnuRadio.
>>>>> 
>>>>> Tnx, Dave
>>> 
>>>

Re: GPIO lines on RPi4

[jean-michel.fri...@femto-st.fr]

My approach:
* build your grc chart from GNU Radio Companion and generate the .py file
* edit the py file and import pygpio
* play with the RPi4 GPIO in your python script.

See attached script, with a python server included in the Python script
to control an RF switch from a GNU Octave TCP/IP client talking to the Python
TCP/IP server.

I am presenting this approach to hardware control at
http://jmfriedt.free.fr/sdra_radar.pdf

JM


--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 18, 2020 9:40 PM, "Da Fy"  wrote:

> Hi All, does anyone have an example of how to control GOIO lines on the RPi4 
> from within a GRC
> flowgraph. I’m guessing it’s an OOT module.
> 
> I need to generate a signal of a few 100Hz & control GPIO lines at various 
> points though the cycle.
> 
> Alternatively, I could generate the signal & lines with external hardware & 
> read them with
> GnuRadio.
> 
> Tnx, Dave


s.py
Description: Binary data

Re: Compiling/installing GNURadio for the STM32MP157C-EV1 board (STM32MP1 processor)

[jean-michel.fri...@femto-st.fr]

I have been using the PlutoSDR as a broadband "noise" generator for 
radar measurements lately (pseudo-random phase modulation) and have  
not been able to achieve more than 2.3 MS/s, after which I observe 
discontinuous emission on the spectrum analyzer (either from laptop
or from a RPi4). So your 4.5 MS/s is already well above what I could achieve.

The example provided by Gwenhael Goavec at 
https://github.com/oscimp/oscimpDigital/tree/master/doc/tutorials/plutosdr/2-PRN_on_PL
keeps the compatibility with GNU Radio when adding his custom processing
block as it splits the datastream at the output of the AD9834 IP to run the
PRN correlator for GPS acquisition on the PL of the Zynq. The original gr-iio
datastream remains available while a custom communication interface allows for
fetching the results of the correlation, after frequency transposition
to compensate for Doppler, with a given PRN (the PlutoSDR Zynq is not large 
enough
to run all PRN correlators in parallel). Running a threshold detector on this 
datastream and timestamping the event on a free running counter inside the 
PlutoSDR 
should not be too complex I believe. Synchronizing the multiple PlutoSDR is 
another 
issue though.

I was not aware that cosmic rays would create radiofrequency events. That is a 
fascinating topic of investigation, especially if accessible to amateur 
radioastronomers.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 4, 2020 11:35 PM, "Glen I Langston"  wrote:

> Hello Jean-Michel,
> 
> Thanks for your description of the cross compiling. Excellent example.
> 
> We’re working on an “Event Capture” code and would like to use as wide
> 
> a bandwidth as possible, but only rarely capture data (once every few
> 
> minutes.)
> 
> So on the PlutoSDR we’d like 20 MHz samples, but somehow transfer
> 
> the data to the host, at a very low data rate. We already have a
> 
> design that does this external to the SDR, on a Raspberry Pi 4.
> 
> (But it has a GUI we’d have to remove.) The maximum data
> 
> rate the Pi, with PlutoSDR will support is 4.5 MHz due to
> 
> dropped packets in transmission to the Pi.
> 
> With a 6 MHz bandwidth Airspy and a raspberry pi we can
> 
> easily capture noise in the device, when the noise level is
> 
> set sufficiently low.
> 
> Our software centers the event in the time window.
> 
> We’d like to have this run entirely inside a PlutoSDR, but without the GUI.
> 
> One problem we’ve had is that installing custom firmware disables Gnuradio 
> compatibility.
> 
> We can probably live with this, but it would be nice if we could have the 
> test Gnuradio internal
> 
> to the PlutoSdr not disable the use for communication to the host.
> 
> The science reason for this is to detect radio transient events. We have 4 
> horns that are all
> looking
> 
> for cosmic ray flashes, created when ultra-high-energy cosmic rays hits the 
> earths atmosphere.
> These flashes cover a small area, about 100 meters in diameter. So a few horn 
> telescopes
> in a small area have a unique look at ultra high energy cosmic rays, 
> depending on their location.
> 
> We’ve seen long (10 to 50 micro-second) flashes and short, < 2 microsecond 
> duration flashes.
> Pictures show these flashes. This is all done inside Gnuradio.
> 
> The pictures show the 4 horns, plus two events. There are two plots of each
> event, one for the entire time range recorded and the other zooming in on the 
> event.
> 
> The time tags are hours minutes seconds and after the _ milliseconds, i.e. 
> HHMMSS_micro.
> 
> We think these are outside the electronics because for the long events all 4 
> horns have
> long events, and for short, all 4 horns see short events. We’d like faster 
> time
> sampling, up to 40 Mega samples per second. We also need better time, but
> that’s a different problem.
> 
> We have not been able to get better timing accuracy on the Pis
> than about +/- 30 milliseconds. I now think this is due to circular buffers 
> in Gnuradio.
> (still to be determined).
> 
> So, to conclude this long email, it would be fantastic to learn how to use 
> Buildroot to figure out
> how
> to program Gnuradio on the PlutoSDR. There are some fantastic applications!
> 
> Best regards
> 
> Glen
> 
>> On Jun 4, 2020, at 3:49 AM, jean-michel.fri...@femto-st.fr wrote:
>> 
>> I have followed
>> https://bootlin.com/blog/building-a-linux-system-for-the-stm32mp1-basic-system/
>> to generate the STM32MP157 cross-compilation framework. Once the Buildroot
>> environment is functional, you can follow
>> https://github.com/oscimp/PlutoSDR/tree/master/doc
>> to add GNU Radio support i

Re: Compiling/installing GNURadio for the STM32MP157C-EV1 board (STM32MP1 processor)

[jean-michel.fri...@femto-st.fr]

I have followed
https://bootlin.com/blog/building-a-linux-system-for-the-stm32mp1-basic-system/
to generate the STM32MP157 cross-compilation framework. Once the Buildroot
environment is functional, you can follow
https://github.com/oscimp/PlutoSDR/tree/master/doc
to add GNU Radio support including libuhd/B2xx support. 

At the moment we are stuck with rpmsg communication as we would like to use
the M4 as pre-processor for the datastream feeding a GNU Radio source, but that
is beyond your scope I believe.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 4, 2020 9:44 AM, "Henrique Do Carmo Miranda" 
 wrote:

> Hi all,
> 
> I would like to install and test GnuRadio on the STM32MP157C-EV1 processor 
> evaluation board for the
> STM32MP1 processor
> (https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eva
> -tools/stm32-mcu-mpu-eval-tools/stm32-eval-boards/stm32mp157c-ev1.html), 
> along with the USRP
> B205mini.
> 
> Do any of you know if compiling and installing GNURadio on this platform has 
> been attempted before,
> and if so do you have any pointers that can guide me through that process - 
> could not find any info
> on it (just wondering if compiled images might be out there)?
> 
> If not, setting up a Linux machine with all the tools to cross-compile 
> GNUradio for the STM32MP1
> target would be the way to go here?
> Would https://wiki.gnuradio.org/index.php/Embedded_Development_with_GNU_Radio 
> be the best guide to
> this process?
> 
> Thanks much for your help,
> Henrique

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[jean-michel.fri...@femto-st.fr]

apologies to the list then, I was not aware of the use of RPi as 
desktop computer, and have always been obsessed with optimization
of resources for embedded systems. Most probably for a desktop use,
a sub-optimal binary distribution such as Raspbian is best suited indeed,
as we find daily on our personal computers.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

May 29, 2020 4:56 PM, "Glen Langston"  wrote:

> Thanks for your explanation.
> 
> ssh-ing in as root did work fine.
> 
> I find that the rtl_ programs do work, like rtl_fm.
> 
> I also understand your approach to embedded real-time applications.
> 
> This probably works particularly well for the PlutoSDR. 
> 
> My goal is for student use, where they are particularly graphical
> user interface aware.
> 
> Best regards
> 
> Glen
> 
>> On May 29, 2020, at 1:57 AM, jean-michel.fri...@femto-st.fr wrote:
>> 
>> It is indeed my belief that there is no point in running a graphical user
>> interface on an embedded system, much less a windowing system. If an embedded
>> board is supposed to interact with a user, a Qt5 or SDL dedicated interface
>> will be much lighter and efficient than a X-Window server and a window 
>> manager
>> client.
>> 
>> This is the reason for providing the examples at the end of the tutorial
>> where a Non GUI flowgraph is generated, the resulting Python script sent to
>> the embedded board and running there, possibly streaming the output (in my
>> example 0-MQ) to a client. In the case of gr-acars, I just fetch periodically
>> the log-file from the RPi4 to the host computer for analysis.
>> 
>> Nevertheless if you want to go in the windowing system direction, Buildroot
>> seems to provide Xorg support:
>> 
>> make menuconfig
>> Target packages -> Graphic libraries and applications -> X.org X Window 
>> System
>> 
>> I have never used nor tested, so I have no idea how much space/how long it 
>> takes
>> to compile.
>> 
>> There is no binary package management system with buildroot: the whole 
>> point, which
>> makes is different from OpenEmbedded/Yocto, is to generate a custom minimal
>> image with only the needed tools and not compile all possible binary packages
>> (the disk size difference being about 10-fold, with about 8 GB needed for
>> buildroot when my attempt at completing the OpenEmbedded system ended at 
>> about
>> 80 GB and many unnecessary binary packages).
>> 
>> The default network configuration is to fetch the IP address from a DHCP 
>> server.
>> Otherwise add an etc/network/interfaces entry in the output/target directory
>> of buildroot with the static IP configuration, and
>> make
>> to re-generate sdcard.img including this configuration file. Similarly if the
>> usr/share/uhd/images binary files are needed: copy in output/target and make.
>> 
>> JM
>> 
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>> 25000 Besancon, France
>> 
>> May 29, 2020 3:33 AM, "Glen Langston"  wrote:
>> 
>>> Hi
>>> 
>>> Thanks for your help.
>>> 
>>> I’ve written the image to an SDCARD and the PI4 boots to
>>> the command line prompt. The password is accepted and
>>> I’ve looked around.
>>> 
>>> Gnuradio seems to be installed, but not the xwindow system.
>>> 
>>> How do you use gnuradio-companion etc?
>>> 
>>> I could not find “xstartup” or some such program.
>>> 
>>> Thanks
>>> 
>>> Glen
>> 
>> On May 24, 2020, at 3:59 PM, jean-michel.fri...@femto-st.fr wrote:
>> 
>> I have uploaded http://jmfriedt.org/sdcard.img
>> my Buildroot image generated for RPi4 that I have been
>> using daily for the last 2 months, so pretty sure it is
>> working. Actually it is 1.1 GB because of lapack needed
>> for gnss-sdr but GNU Radio 3.8/Python3 will only require
>> about 500 MB.
>> Gwenhael Goavec-Merou ported all GNU Radio related software/libraries
>> to Buildroot: the missing parts for gnss-sdr are found at
>> https://github.com/oscimp/PlutoSDR in the for_next branch.
>> 
>> root passwd=root, no user account, USRP FPGA images to be added
>> in usr/share/uhd/images manually if libuhd is needed. Tested with
>> RTL-SDR DVB-T dongle, PlutoSDR (gr-iio) and B210.
>> 
>> JM
>> 
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>> 25000 Besancon, France
>> 
>> M

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[jean-michel.fri...@femto-st.fr]

It is indeed my belief that there is no point in running a graphical user
interface on an embedded system, much less a windowing system. If an embedded
board is supposed to interact with a user, a Qt5 or SDL dedicated interface
will be much lighter and efficient than a X-Window server and a window manager
client.

This is the reason for providing the examples at the end of the tutorial
where a Non GUI flowgraph is generated, the resulting Python script sent to 
the embedded board and running there, possibly streaming the output (in my
example 0-MQ) to a client. In the case of gr-acars, I just fetch periodically
the log-file from the RPi4 to the host computer for analysis.

Nevertheless if you want to go in the windowing system direction, Buildroot
seems to provide Xorg support: 

make menuconfig
Target packages -> Graphic libraries and applications -> X.org X Window System

I have never used nor tested, so I have no idea how much space/how long it takes
to compile.

There is no binary package management system with buildroot: the whole point, 
which
makes is different from OpenEmbedded/Yocto, is to generate a custom minimal
image with only the needed tools and not compile all possible binary packages
(the disk size difference being about 10-fold, with about 8 GB needed for
buildroot when my attempt at completing the OpenEmbedded system ended at about
80 GB and many unnecessary binary packages).

The default network configuration is to fetch the IP address from a DHCP server.
Otherwise add an etc/network/interfaces entry in the output/target directory
of buildroot with the static IP configuration, and
make
to re-generate sdcard.img including this configuration file. Similarly if the
usr/share/uhd/images binary files are needed: copy in output/target and make.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

May 29, 2020 3:33 AM, "Glen Langston"  wrote:

> Hi
> 
> Thanks for your help.
> 
> I’ve written the image to an SDCARD and the PI4 boots to
> the command line prompt. The password is accepted and
> I’ve looked around.
> 
> Gnuradio seems to be installed, but not the xwindow system.
> 
> How do you use gnuradio-companion etc?
> 
> I could not find “xstartup” or some such program.
> 
> Thanks
> 
> Glen
> 
>> On May 24, 2020, at 3:59 PM, jean-michel.fri...@femto-st.fr wrote:
>> 
>> I have uploaded http://jmfriedt.org/sdcard.img
>> my Buildroot image generated for RPi4 that I have been
>> using daily for the last 2 months, so pretty sure it is
>> working. Actually it is 1.1 GB because of lapack needed
>> for gnss-sdr but GNU Radio 3.8/Python3 will only require
>> about 500 MB.
>> Gwenhael Goavec-Merou ported all GNU Radio related software/libraries
>> to Buildroot: the missing parts for gnss-sdr are found at
>> https://github.com/oscimp/PlutoSDR in the for_next branch.
>> 
>> root passwd=root, no user account, USRP FPGA images to be added
>> in usr/share/uhd/images manually if libuhd is needed. Tested with
>> RTL-SDR DVB-T dongle, PlutoSDR (gr-iio) and B210.
>> 
>> JM
>> 
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>> 25000 Besancon, France
>> 
>> May 24, 2020 9:51 PM, "Glen I Langston"  wrote:
>> 
>>> Hello
>>> 
>>> I’ve been a great proponent of gnuradio, but I’m finding in
>>> increasing difficult to do anything new, as installation of 3.8 is
>>> essentially impossible for most people.
>>> 
>>> I’ve written and built my own python modules and C++ blocks.
>>> 
>>> However, despite months of trying now, I can not get 3.8 to install
>>> on a raspberry pi.
>>> 
>>> Has anyone achieved 3.8 on a raspberry pi?
>>> 
>>> If so can you please save the entire OS, gzip compressed and put it
>>> online somewhere. It will probably be about 3 GB compressed.
>>> 
>>> Thanks
>>> 
>>> Glen
>>> 
>>> Note that there are many many (too many) different guides on line
>>> 
>>> 1) apt-get
>>> 
>>> 2) pybombs
>>> 
>>> 3) git clone then build
>>> 
>>> each one fails in a different way.

Gnuradio 3.8 on embedded [ARM] systems

[jean-michel.fri...@femto-st.fr]

As I am annoyed by the constant reminder of compiling such a complex
piece of software as GNU Radio and associated libraries on the target 
embedded ARM system (lack of optimization of the binary distribution 
tuned for the lowest performance target, damaging the mass-storage SD 
card medium, inefficiency of using a low performance system for a 
computationally intensive task), we have put together a short documentation
on using Buildroot to generate an image supporting GNU Radio including
Osmosdr DVB-T source, USRP (libuhd) sources and Pluto-SDR (gr-iio) and yet
optimized for the target system: the document is available at

https://github.com/oscimp/PlutoSDR/blob/master/doc/gnuradio_on_RPi.pdf

This documentation focuses on the Raspberry Pi{3,4} as it was the topic of the
latest discussion, but was tested on the PlutoSDR and Redpitaya Zynq processors
(to only name a few of the best known ARM-based platforms we are using).
Basically all platforms supported by Buildroot should be applicable (PlutoSDR
being obviously the most attractive but the most annoying with its eMMC 
storage). 
The practical demonstration (0-MQ streaming of broadcast FM from target to 
host) 
is still being fine tuned.

Feel free to comment/correct (all but Phil Balister who will tell us how
superior Yocto/OpenEmbedded is and start a troll because I would argue in
favor of Buildroot ;)

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[jean-michel.fri...@femto-st.fr]

I have uploaded http://jmfriedt.org/sdcard.img
my Buildroot image generated for RPi4 that I have been
using daily for the last 2 months, so pretty sure it is
working. Actually it is 1.1 GB because of lapack needed
for gnss-sdr but GNU Radio 3.8/Python3 will only require
about 500 MB.
Gwenhael Goavec-Merou ported all GNU Radio related software/libraries
to Buildroot: the missing parts for gnss-sdr are found at
https://github.com/oscimp/PlutoSDR in the for_next branch.

root passwd=root, no user account, USRP FPGA images to be added
in usr/share/uhd/images manually if libuhd is needed. Tested with
RTL-SDR DVB-T dongle, PlutoSDR (gr-iio) and B210.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

May 24, 2020 9:51 PM, "Glen I Langston"  wrote:

> Hello
> 
> I’ve been a great proponent of gnuradio, but I’m finding in
> increasing difficult to do anything new, as installation of 3.8 is
> essentially impossible for most people.
> 
> I’ve written and built my own python modules and C++ blocks.
> 
> However, despite months of trying now, I can not get 3.8 to install
> on a raspberry pi. 
> 
> Has anyone achieved 3.8 on a raspberry pi?
> 
> If so can you please save the entire OS, gzip compressed and put it
> online somewhere. It will probably be about 3 GB compressed.
> 
> Thanks
> 
> Glen
> 
> Note that there are many many (too many) different guides on line
> 
> 1) apt-get
> 
> 2) pybombs 
> 
> 3) git clone then build
> 
> each one fails in a different way.

Re: Sound card input & output synchronization ?

[jean-michel.fri...@femto-st.fr]

Thank you Sylvain:
as this is a new computer, I had not installed pulseaudio. It seems
the "default" Alsa backend indeed drops frames. I installed pulseaudio
and running in debug mode (-) I cannot see frame size updates but most
importantly my records are now continuous, problems solved.

Furthermore, the connection that used to be "forbidden" between the signal
feeding the sink and the source output is now working properly and not
generating the discoutinuous output I used to see.

Thank you, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

May 19, 2020 2:52 PM, "Sylvain Munaut" <246...@gmail.com> wrote:

> What audio backend are you using ?
> 
> I know Pulse Audio / Alsa can just drop / duplicate samples. They try
> to reduce latency by adjusting some buffer size dynamically but those
> adjustments will cause discontinuities.
> You can for instance run pulse audio in debug mode and you'll see if /
> when it does those and if it matches with what you see.
> 
> Cheers,
> 
> Sylvain

GNU Radio on Android

[jean-michel.fri...@femto-st.fr]

Since I have little else to do at the moment than playing with my phone,
I debugged the USB OTG port of my Sony Z5, which led me to install the
rtl-sdr driver, which led me to install some non-GNU Radio application
to test the SDR capability of the phone, and it works. I haven't learnt
anything in the process.

I do have Tom's detailed description on compiling GNU Radio but I am afraid
the 2017 flowchart for 3.7 is no longer valid, and I have Bastian's video 
showing off GNU Radio 3.8 on android which also does not teach me much other
than making me envious.

Is there some documentation on getting started, considering I have absolutely
no clue on how to cross compile to Android ?

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

Re: USRP LO stabilization time ?

[jean-michel.fri...@femto-st.fr]

For the record ... thanks to the excellent reference provided in this answer,
I became convinced that the timing issue does not lie with the B210/libuhd but 
with
the PlutoSDR. After reading
https://ez.analog.com/adieducation/university-program/f/q-a/91477/adalm-pluto-how-to-change-settings-with-quick-settling/199287#199287
and porting the single_param function updated by Travis Collins to the GNU 
Radio 3.8 
port of gr-iio, I get sub-millisecond stabilization time by changing *only* the
out_altvoltage1_TX_LO_frequency parameter and not the full set of settings as 
done
with the defaut Pluto Sink function set_params. Now my sweep time is limited by 
data 
transfer and no longer by LO settling time, but that is another issue for me to 
solve.

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

April 14, 2020 2:22 PM, "Sebastian Sahlin"  wrote:

> Hi,
> 
> I believe the following paper may be of interest:
> https://pubs.gnuradio.org/index.php/grcon/article/view/2
> 
> It is indicated that the B210 needs around 3.3 milliseconds minimum to settle 
> and it is, as you
> say, due to the hardware frontend. What is causing the extra delay I can only 
> guess but perhaps
> communication overhead is the culprit.
> 
> Regards,
> Sebastian
> 
> Den tis 14 apr. 2020 kl 13:40 skrev jean-michel.fri...@femto-st.fr
> :
> 
>> I am considering frequency sweeping a PlutoSDR and a B210, both fitted with
>> AD936x RF frontends.
>> As I was writing the application and reading the libuhd documentation, I read
>> at https://files.ettus.com/manual/page_general.html
>> "After tuning, the RF front-end will need time to settle into a usable state.
>> Typically, this means that the local oscillators must be given time to lock
>> before streaming begins. Lock time is not consistent; it varies depending 
>> upon
>> the device and requested settings. After tuning and before streaming, the 
>> user
>> should wait for the lo_locked sensor to become true or sleep for a 
>> conservative
>> amount of time (perhaps a second)."
>> ... and surely enough, I can see that if I wait less than a second after 
>> programming
>> the LO, I get inconsistent results because my LO has not stabilized. That is 
>> also
>> true with the USRP GNU Radio source block.
>> Unfortunately I want to sweep a few hundred frequencies (in several 100 MHz 
>> range,
>> so no option of playing with the I/Qs while keeping the same LO setting), 
>> meaning
>> that the current measurement takes forever (up to 5 min) only waiting for 
>> the time to
>> settle since data communication delay is at the moment negligible.
>> 
>> 1/ What is the cause of this settling delay ? is it libuhd communication (in 
>> my
>> case over USB with a B210) or the Analog Devices frontend hardware ?
>> 2/ is there some "setting rule" that might lower the settling time (e.g. 
>> programming
>> a multiple of some magic frequency that might take less time to settle) ? 
>> Currently
>> I sweep with 1 MHz steps, ie a fraction of the sampling frequency, for 
>> spectra to overlap,
>> but that frequency step was selected randomly and could be any better value 
>> if that
>> could help LO stabilize "quickly".
>> 
>> Thanks, JM
>> 
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>> 25000 Besancon, France

USRP LO stabilization time ?

[jean-michel.fri...@femto-st.fr]

I am considering frequency sweeping a PlutoSDR and a B210, both fitted with
AD936x RF frontends.
As I was writing the application and reading the libuhd documentation, I read
at https://files.ettus.com/manual/page_general.html
"After tuning, the RF front-end will need time to settle into a usable state. 
 Typically, this means that the local oscillators must be given time to lock 
 before streaming begins. Lock time is not consistent; it varies depending upon 
 the device and requested settings. After tuning and before streaming, the user 
 should wait for the lo_locked sensor to become true or sleep for a conservative
 amount of time (perhaps a second)."
... and surely enough, I can see that if I wait less than a second after 
programming
the LO, I get inconsistent results because my LO has not stabilized. That is 
also
true with the USRP GNU Radio source block. 
Unfortunately I want to sweep a few hundred frequencies (in several 100 MHz 
range, 
so no option of playing with the I/Qs while keeping the same LO setting), 
meaning 
that the current measurement takes forever (up to 5 min) only waiting for the 
time to
settle since data communication delay is at the moment negligible.

1/ What is the cause of this settling delay ? is it libuhd communication (in my
case over USB with a B210) or the Analog Devices frontend hardware ?
2/ is there some "setting rule" that might lower the settling time (e.g. 
programming
a multiple of some magic frequency that might take less time to settle) ? 
Currently
I sweep with 1 MHz steps, ie a fraction of the sampling frequency, for spectra 
to overlap,
but that frequency step was selected randomly and could be any better value if 
that
could help LO stabilize "quickly".

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

RFC: clock synchronization on AFSK modulated signal

[jean-michel.fri...@femto-st.fr]

Thanks to the help I received during the week end, I completed the update
on gr-acars. One thing I realized when working on PSK modulations (e.g RDS)
is the importance of bitrate clock synchronization.

After investigating the M algorithm, possibly because of my misunderstanding
of its implementation targeted at identifying zero-crossing of the difference
of the soft bit and estimated hard bit symbol, I have attempted a very naive
clock-rate synchronization on AFSK using maximum likelihood on single bits 
framed by
different bit states (since similar successive bits are hardly affected by 
synchronization issues). I wanted to avoid differentiating the AFSK output
since derivate is prone to noise and might make the zero-crossing identification
unstable (correct ?). I would be quite interested in comments or corrections
to http://jmfriedt.org/acars_clock.pdf or directions to existing literature on
this issue which is far from my field of expertise.

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

Re: looking for a mode-S ADS-B recorded signal

[jean-michel.fri...@femto-st.fr]

luckily for you I was just saving some ADS-B records for direction of arrival
measurement. The data was collected April 2nd so already very few planes over 
French airspace. A short sample has just been uploaded to
http://jmfriedt.org/adsb_2000kSps2_1uint8_10Msamples.bin
in unsigned char complex (interleaved real / imag) as needed by dump1090 for 
decoding. You can check with
dump1090 --ifile adsb_2000kSps2_1uint8_10Msamples.bin 
that the file is valid.  If needed, you can also generate your own ADS-B 
sentences 
using https://github.com/lyusupov/ADSB-Out

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

April 6, 2020 11:36 AM, "Christophe Seguinot"  
wrote:

> Dear all
> 
> I'm using GNURadio for my distance learning class an intend to demonstrate 
> demodulating ASK with
> ADS-B signal. At present, they are only 3 planes 80 km away from my home. I 
> was not able to find
> any recorded ADS-B signal on the internet.
> 
> Could someone provide me with a ADS-B signal to make an experiment using the 
> GRC  "filesource" ?
> 
> Regards. Christophe

Re: linking with GNU Radio FFT library

[jean-michel.fri...@femto-st.fr]

works like a charm with these, had missed the update in the lib/
configuration file.

Thanks a lot, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

April 5, 2020 3:29 PM, "Sylvain Munaut" <246...@gmail.com> wrote:

> Hi JM,
> 
> In CMakeList.txt:
> find_package(Gnuradio "3.8" REQUIRED COMPONENTS fft)
> 
> In lib/CMakeList.txt :
> target_link_libraries(your-oot-name gnuradio::gnuradio-fft)
> 
> Cheers,
> 
> Sylvain

linking with GNU Radio FFT library

[jean-michel.fri...@femto-st.fr]

gr-acars is working very well with GNU Radio 3.8, all good. Now I'd like
to add two improvements: being able to run multiple processing blocks in
parallel (on multiple channels, which libfftw seems hardly able to do due to
the non-threadable plan creation) and getting rid of the external FFTW 
dependency
since GNU Radio provides its own FFT wrapper around libfftw3.

So I converted all fftw calls to internal GNU Radio calls, the software 
compiles fine
 and now I am stuck with executing since any call to 
 fft::fft_complex* plan_2400 = new fft::fft_complex(N, true);
leads to
 AttributeError: module 'acars' has no attribute 'acars'
when executing in GNU Radio Companion, which I attribute to a missing library 
dependency.

I have tried to follow 
https://wiki.gnuradio.org/index.php/OutOfTreeModulesConfig 
but the documentation seems outdated since it refers the 3.7.0 requirements.
I tried following 
https://raw.githubusercontent.com/gnuradio/gnuradio/master/cmake/Modules/GrComponent.cmake
as used in https://github.com/gnuradio/gnuradio/tree/master/gr-qtgui but that
too seems a dead end.

1/ is the CMakeLists configuration

include(GrComponent)
GR_REGISTER_COMPONENT("gr-acars" ENABLE_GNURADIO_RUNTIME ENABLE_GR_FFT)
find_package(Gnuradio "3.8" REQUIRED)

the correct way of linking with the FFT library ?
2/ is there a basic example of a simple OOT block linking on such a library 
somewhere ?

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

Re: accumulating samples for processing ?

[jean-michel.fri...@femto-st.fr]

beautiful, thanks: adding
#define CHUNK_SIZE 1024   
set_output_multiple(CHUNK_SIZE);
to the constructor yields resonable results
N=1024: _N is zero
N=1024: _N is zero
N=1024: _N is zero
N=1024: _N is zero

Still not sure why my original option was not working, but this is
definitely a fine solution. I had forgotten you previous post on the topic,

Thanks, JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

April 5, 2020 10:58 AM, "Ron Economos"  wrote:

> I would use set_output_multiple() instead. See my previous e-mail for an 
> example.
> 
> https://lists.gnu.org/archive/html/discuss-gnuradio/2019-08/msg00188.html
> 
> Ron
> 
> On 4/5/20 01:36, jean-michel.fri...@femto-st.fr wrote:
> 
>> I am using the opportunity of porting gr-acars to GNU Radio 3.8 to
>> re-write the processing algorithm. As part of this reorganization,
>> I want to analyze the baseline standard deviation and detect the AM
>> modulated message as a rise in standard deviation (ie custom squelch).
>> Since there is hardly any plane flying over France at the moment, I run
>> the analysis from a recorded file, in which case the scheduler provides
>> few samples at each batch. So I want to accumulate a statistically relevant
>> length of samples before assessing the variance. Rather than implementing
>> a custom circular buffer, I want to benefit from the GNU Radio scheduler
>> as explained slide 7 of http://jmfriedt.org/slides_gnuradiodays2019/18h00 MM 
>> GR scheduler.pdf
>> 
>> "not forced to consume all input -- can consume less at single-item 
>> granularity
>> “leftovers” beginning of next call’s input_items"
>> 
>> So the work function of my sink block (no output item) is
>> 
>> {_N+=noutput_items;
>> printf("N=%d ",_N);
>> if (_N>1000)
>> {consume_each (_N);
>> _N=0;
>> printf("_N is zero\n");// make sure counter is reset
>> }
>> else consume_each (0); // accumulate more samples
>> return 0; // noutput_items;
>> }
>> 
>> and I am confused by the output of this block which states
>> 
>> N=170 N=340 N=510 N=680 N=850 N=1020 _N is zero
>> N=15534 _N is zero
>> N=170 N=340 N=510 N=680 N=850 N=1020 _N is zero
>> N=15534 _N is zero
>> 
>> so indeed once out of two sequences we accumulate up to 1000 samples,
>> detect the targeted number of samples is reached, consume the buffer and
>> reset the counter. But after resetting the counter, I get 15534 samples.
>> Is this indeed a behavior of the scheduler or a mistake on my side of 
>> handling
>> the counter ? (can hardly do anything wrong with such a simple example it
>> seems).
>> 
>> Is this the correct way of accumulating a minimum number of samples before
>> processing each batch ?
>> 
>> Thanks, Jean-Michel

accumulating samples for processing ?

[jean-michel.fri...@femto-st.fr]

I am using the opportunity of porting gr-acars to GNU Radio 3.8 to 
re-write the processing algorithm. As part of this reorganization,
I want to analyze the baseline standard deviation and detect the AM
modulated message as a rise in standard deviation (ie custom squelch).
Since there is hardly any plane flying over France at the moment, I run
the analysis from a recorded file, in which case the scheduler provides
few samples at each batch. So I want to accumulate a statistically relevant
length of samples before assessing the variance. Rather than implementing
a custom circular buffer, I want to benefit from the GNU Radio scheduler
as explained slide 7 of 
http://jmfriedt.org/slides_gnuradiodays2019/18h00%20MM%20GR%20scheduler.pdf

"not forced to consume all input -- can consume less at single-item granularity
 “leftovers” beginning of next call’s input_items"

So the work function of my sink block (no output item) is

{_N+=noutput_items;
 printf("N=%d ",_N);
 if (_N>1000)
   {consume_each (_N);
_N=0;
printf("_N is zero\n");// make sure counter is reset
   }
   else consume_each (0);  // accumulate more samples
 return 0; // noutput_items;
}   

and I am confused by the output of this block which states

N=170 N=340 N=510 N=680 N=850 N=1020 _N is zero
N=15534 _N is zero
N=170 N=340 N=510 N=680 N=850 N=1020 _N is zero
N=15534 _N is zero

so indeed once out of two sequences we accumulate up to 1000 samples,
detect the targeted number of samples is reached, consume the buffer and
reset the counter. But after resetting the counter, I get 15534 samples.
Is this indeed a behavior of the scheduler or a mistake on my side of handling
the counter ? (can hardly do anything wrong with such a simple example it
seems).

Is this the correct way of accumulating a minimum number of samples before
processing each batch ?

Thanks, Jean-Michel

European GNU Radio Days: contribution submission

[jean-michel.fri...@femto-st.fr]

The initial deadline for contributing to the European GNU Radio Days conference
https://gnuradio-eu-20.sciencesconf.org/ is supposed to be today. 

In these uncertain times, some might be hesitant to spend time summarizing 
the result of their work: since no official guideline has been issued for 
events planned for end of June, we are still planning on holding the event 
*assuming* some contributions are provided. At worst, me might consider
virtualizing the conference, which we hope to avoid, but at least that might 
provide some framework in which to share results. Feel free to submit at
https://gnuradio-eu-20.sciencesconf.org/registration in case you have completed 
work to present (or let me know if you plan on doing so).

Best wishes, Jean-Michel

Re: Accurate GPIO Clock

[jean-michel.fri...@femto-st.fr]

welcome to the field of real time operating systems. There are a few thousand 
pages about the latencies introduced by the scheduler in non-real time OS, the 
first google hit being
https://www.veterobot.org/2012/04/precise-pwms-with-gpio-using-xenomai.html
A few microseconds is not too bad actually. Unless you shift the hard real time
task to hardware (FPGA), I am not sure you can get any better.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

March 1, 2020 12:57 PM, "Till Hülder"  wrote:

> Hello,
> 
> i want to build a accurate GPIO Clock . I wrote a wait function :
> 
> void sleepus(int n)
> {
> clock_t end=clock()+n*CLOCKS_PER_SEC/100;
> while(clock() < end) continue;
> }
> 
> And wait until the value of the bits change .I recognized that the time of 
> these wait time is not
> constant. It differs by a few microseconds.
> 
> Is there are another way to get a more accurate clock ?
> 
> Best regards ,
> 
> Till

European GNU Radio Days call for paper: 1 month left

[jean-michel.fri...@femto-st.fr]

The submission site for contributing to the European GNU Radio Days, to be held
in Poitiers (France) June 22nd & 23rd, is now open. A two-page abstract will 
help 
the organizing committee select between oral presentation, poster presentation 
or demonstration.
The deadline for contribution submission is set to April 1st, or 1 month from 
today.

A tentative program is given on the conference web site at 
https://gnuradio-eu-20.sciencesconf.org/

Looking forward to meeting you at the conference,
for the European GNU Radio conference organizing committee,
Jean-Michel

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

Re: quantization noise demonstration ?

[jean-michel.fri...@femto-st.fr]

My mistake ... my noise level was far too high. Additionnally, the noise
with amplitude lower than LSB must be added to a full-scale range sine wave 
to be dithered amongst the various quantization bins. If anyone is interested,
I updated http://jmfriedt.org/quantization.pdf which (I believe) demonstrates 
the impact of quantization on the noise floor.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

February 16, 2020 5:36 PM, "jmfriedt"  wrote:

> I wanted to demonstrate quantization noise (V_q^12/12/fs noise floor)
> with GNU Radio and somehow my demonstration is failing. I am trying
> http://jmfriedt.org/untitled.png (or http://jmfriedt.org/untitled.grc)
> following the chart of the Quantizer. Somehow I had already noticed
> that the Qt Freq Sync is displaying a spectral density (because keeping
> 1:N will not raise the noise floor by N as would be expected from aliasing), 
> but here the noise is obviously quantized (see time domain) but the
> spectral density in the frequency domain does not show the impact of
> quantization.
> Is this expected ?
> 
> Thanks, JM
> 
> -- 
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France

Re: UHD: USRP source issue when using 2 channels

[jean-michel.fri...@femto-st.fr]

I confirm that with the current git (GNU Radio 3.9.0) the issue seems solved.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

November 21, 2019 11:14 AM, "Müller, Marcus"  wrote:

> I'm s close to shouting out "ha-ha! Integer signedness error!", but
> I think chances are this was fixed on master in
> 8eb1a354c0b5126b6c0b7d55b68963a155088b3a.
> 
> On Thu, 2019-11-21 at 01:57 -0800, Ron Economos wrote:
> 
>> I have the same issue, but the error message is different.
>> 
>> Traceback (most recent call last):
>> File "/home/re/xfer/uhdrx.py", line 213, in 
>> main()
>> File "/home/re/xfer/uhdrx.py", line 191, in main
>> tb = top_block_cls()
>> File "/home/re/xfer/uhdrx.py", line 97, in __init__
>> self.uhd_usrp_source_0.set_center_freq(center_freq, 1)
>> File
>> "/opt/gnuradio-3.7.12git/lib/python3.6/dist-packages/gnuradio/uhd/uhd_swig.py",
>> line 3600, in set_center_freq
>> return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args)
>> RuntimeError: LookupError: IndexError: multi_usrp: RX channel
>> 140641462873248 out of range for configured RX frontends
>> 
>>>>> Done (return code 1)
>> 
>> Ron
>> 
>> On 11/21/19 00:43, jean-michel.fri...@femto-st.fr wrote:
>> Am I the only one facing an issue with fetching data from 2 channels of a 
>> B210 receiver ?
>> When addressing a single channels (USRP Source -> file sink) all goes well, 
>> but
>> whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get 
>> an error message
>> 
>> tb = top_block_cls()
>> File "/tmp/GPS.py", line 103, in __init__
>> self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0))
>> File 
>> ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", 
>> line 48, in wrapped
>> func(self, src, src_port, dst, dst_port)
>> File 
>> ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", 
>> line 111, in connect
>> self.primitive_connect(*args)
>> File 
>> ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", 
>> line 5461, in
>> primitive_connect
>> return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
>> RuntimeError: port number 1 exceeds max of 0
>> 
>> whatever sink (file, null) is attached to the UHD output. I am facing the 
>> issue
>> with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0
>> (Python 3.7.5) versions of GNU Radio Companion.
>> 
>> The flowchart with the issue is at http://jmfriedt.org/GPS.pdf
>> 
>> Thanks, JM

UHD: USRP source issue when using 2 channels

[jean-michel.fri...@femto-st.fr]

Am I the only one facing an issue with fetching data from 2 channels of a B210 
receiver ?
When addressing a single channels (USRP Source -> file sink) all goes well, but
whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get an 
error message

tb = top_block_cls()
File "/tmp/GPS.py", line 103, in __init__
self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0))
File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 48, in wrapped
func(self, src, src_port, dst, dst_port)
File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 111, in connect
self.primitive_connect(*args)
File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 5461, in
primitive_connect
return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
RuntimeError: port number 1 exceeds max of 0

whatever sink (file, null) is attached to the UHD output. I am facing the issue 
with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 
(Python 3.7.5) versions of GNU Radio Companion.

The flowchart with the issue is at http://jmfriedt.org/GPS.pdf

Thanks, JM

European GNU Radio Days 2020 (June 22-23, 2020): call for contributions

[jean-michel.fri...@femto-st.fr]

Dear GNU Radio community members,

we are organizing the third edition of the European GNU Radio Days 2020, 
to be held in Poitiers (France) June 22 & 23rd, 2020. 

We are seeking contributions: oral presentations, posters, demonstrations, 
tutorials.
A two-page abstract would allow us to select proposals relevant to the 
conference and
share with the attendees the highlights of the developments. 

Amongst the most relevant topics we have identified:
* Cognitive Radio, Digital Communication and Agile Spectrum Sharing
* RADAR systems and specifically passive radar
* Front-end analog characterization
* Design of Signal Processing algorithms as GNU Radio blocks
* Identification and decoding of signals, including satellite communication 
systems
* Security aspects of Radiocommunications
* Coupling GNU Radio to Soc FPGA (running GNU Radio on the embedded system, 
front end signal
processing)
* Various physical measurements (GNSS, Radioastronomy)

The web site describing the conference scope and for submitting proposales is at
https://gnuradio-eu-20.sciencesconf.org

See you maybe there, Jean-Michel

Re: [Discuss-gnuradio] Building GNU Radio on Fedora 30 with pybomb to get a 3.8 installation

[jean-michel.fri...@femto-st.fr]

> pybombs prefix init ~/gnuradio -R gnuradio-default

gnuradio-default.lwr recipe is 3.7. Edit the recipe in 
.pybombs/recipes/gr-recipes
and replace gnuradio with (in order to call gnuradio38.lwr)
depends:
- gnuradio38

and in gnuradio38.lwr
gitbranch: master -> gitrev: v3.8.0.0
(since master is now 3.9)

JM

> 
> I am seeing failures. It seems that the build wants to use python2 packages
> which it did not install. I have been making progress by installing the
> missing packages.
> 
> dnf install python2-lxml python2-numpy
> pip2 install --user mako
> pip3 install --user mako
> 
> After that The build completed. But its a 3.7.13.5 build not the 3.8 I was 
> hoping for.
> 
> What is the recommended way to build gnu radio 3.8 in Fedora?
> (I see that its not package for Fedora yet, even in rawhide).
> 
> Barry
> 
> ___
> 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] CMake macros & definitions for GR 3.8

[jean-michel.fri...@femto-st.fr]

since the name of the original author sounds French, a manuscript being 
finalized
on writing OOT block including porting to GNU Radio 3.8 or native gr_modtool 
for GR3.8
is at http://jmfriedt.free.fr/gr_oscilloscope.pdf [in French, draft version].
I will translate to English once finalized and submitted for publication to 
GNU/Linux
Magazine France.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

August 20, 2019 5:06 PM, "Emmanuel Blot"  wrote:

> On 20 Aug 2019, at 15:00, Müller, Marcus wrote:
> 
>> Hi Emmanuel,
>> 
>> so, with 3.8 we're switching to the more modular modern CMake.
> 
> Great - and good to know.
> 
>> I assume you've created an out-of-tree module using `gr_modtool
>> newmod`
>> (if you haven't, try it; you get a useful stub!).
> 
> I tried it, but I failed to locate the proper way to use it, it seems
> :-)
> 
> I wanted to rebuild GQRX w/ PlutoSDR support for macOS targets, and get
> rid of Python 2.7.
> It has always been difficult, but thanks to GR 3.8 and a couple of
> patches, it now works.
> 
> I was missing the way to do a proper link w/ 3.8.
> Thanks a lot for your help!
> 
>> find_package(Gnuradio "3.8" REQUIRED COMPONENTS blocks analog)
> 
> This is the part that I actually missed ^^^
> 
>> https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide
> 
> Thanks for the link.
> 
> BR,
> Emmanuel.
> 
> ___
> 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] OpenCL FFT synchronization question

[jean-michel.fri...@femto-st.fr]

As I am investigating GPU and OpenCL for acceerating correlation computations, 
I thought
I'd give OpenCL-Enabled FFT block in GNU Radio Companion (still version 
3.7.13.4) a try to 
see if I can see any performance change.
When I run signal source -> throttle -> OpenCL FFT -> time sink, all goes well, 
the spectrum
*looks* similar to the GNU Radio FFT (CPU) output. So far so good.
If I now run the correlation graph found at 
http://jmfriedt.org/opencl/opencl_xcorr_grc.png
the correlation surprisingly is non existent as seen at 
http://jmfriedt.org/opencl/nosubtract.png
(top chart is CPU computation of the correlation as 
iFFT(FFT(signal).FFT(delayed signal)^* with
a fine correlation peak on the right, and bottom chart is the same through the 
OpenCL FFT).
Running the same chart but fed with a periodic signal (square wave) does show a 
set of correlation
peaks spaced by the square wave period as shown at 
http://jmfriedt.org/opencl/nosubstract_square.png
hinting at a synchronization issue with the two OpenCL blocks being fed random 
sequences sampled at
different time.
Trying to display the difference between the two correlations (output of the 
complex conjucate 
multiplication) actually seems to solve the issue as seen at 
http://jmfriedt.org/opencl/withsubtract.png 
where the correlation peak suddenly appears after a fraction of a second of 
running the flowchart, 
so the GNU Radio scheduler seems to be affected by this new subtraction chain. 
Yet, notice that 
the subtraction between the two correlation processing chains (top chart) is 
not 0, unlike running 
the same flowchart with subtraction on the periodic square wave 
(http://jmfriedt.org/opencl/withsubstract_square.png) which does show a null 
error.

I don't have an explanation, not even sure there is an obvious one, but at 
least wanted to share 
these observations with the community.

JM

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

Re: [Discuss-gnuradio] [VOLK][announcement] VOLK release impeding

[jean-michel.fri...@femto-st.fr]

> It took about eight hours total.

I would hope this list would stop promoting building on the target
embedded system.

Embedded system development should never, ever, attempt compiling
on the low power target but rather figure out how to cross-compile
from the powerful host for generating binaries targeted to the low
power embedded board using appropriate tools (e.g. buildroot, Yocto or
OpenEmbedded).

Unfortunately having an HDMI connector for a display and a USB port for
the keyboard with a ready-to-use distribution such as Raspbian makes RPi 
users believe that they have a full computer available and forget
proper embedded system development practices as I see daily from most
students. Would anyone consider running gcc on a low-power STM32 or MSP430
for compiling the firmware ?

JM

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

[Discuss-gnuradio] European GNU Radio Days videos

[jean-michel.fri...@femto-st.fr]

The videos of the European GNU Radio Days oral presentations and tutorials
are now available online:

Marcus' keynote presentation:
https://mediacenter.ens2m.fr/videos/?video=MEDIA190710141050023

First day oral presentations (morning):
https://mediacenter.ens2m.fr/videos/?video=MEDIA190710142940080

First day oral presentations (afternoon):
https://mediacenter.ens2m.fr/videos/?video=MEDIA190710152118683

Second day tutorials (morning):
https://mediacenter.ens2m.fr/videos/?video=MEDIA190710161134144

Second day tutorials (afternoon):
https://mediacenter.ens2m.fr/videos/?video=MEDIA190712143435133

The program is at https://gnuradio-fr-19.sciencesconf.org/program and
the book of abstracts at 
https://gnuradio-fr-19.sciencesconf.org/data/pages/book_gnuradio_fr_19_en.pdf

JM

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

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[jean-michel.fri...@femto-st.fr]

reading your email more closely:
* the sound card generates real data with an even spectrum with components at w 
and -w
* you transfer from VLF band to baseband by multiplying by a complex NCO 
exp(-jwt) with t=[0:length(samples)]/fs
when sampling at fs
* the -w component is shifted to -2w that you filter our before decimation
* after transposition and decimation, you end up with the complex I/Q 
components you are familiar with.

You can also multiply with cos(wt) instead of exp(jwt) but then you create all 
the spectral components
at +/-2wt which might be more annoying to filter out, so you might as well work 
with a complex NCO from the
beginning.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

May 2, 2019 10:24 PM, "Brad Hein" mailto:linuxb...@gmail.com?to=%22Brad%20Hein%22%20)> 
wrote:
I took a Raspberry Pi and attached a 48KHz USB sound card, with a big magnetic 
loop antenna fed into the mic. A little cheesy? yes! But I'd like to try and 
see if I can receive VLF. It's in a remote location with little to no 
interference so I'm thinking my chances should be good. The challenge I'm 
facing is that I need to write the SDR logic to "tune" throughout the 0-24KHz 
tuning range. 
My question is, being that a sound card source presents samples in float and 
not the usual complex data type, can I still apply the same SDR logic that we 
use for SSB/FM/AM demodulation such as those presented in the Gnuradio 
tutorials (eg. 
http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf 
(http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf)) and if 
not, how do I go about translating the float input into something I can use to 
feed existing AM/FM/SSB demodulator flowgraphs? 
I run many other flowgraphs on Raspberry Pi's remotely so the networking and 
remote aspect of the project will be easy for me. I really just need some 
initial guidance knowing which direction to go in terms of tuning. 
Thanks! 
Brad
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[jean-michel.fri...@femto-st.fr]

https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1002/2017RS006420
or
http://jmfriedt.free.fr/agu_dcf77.pdf
We are currently working on simultaneously decoding (e)LORAN/MSF, TDF & DCF77 
v.s GPS
with a sound card.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

May 2, 2019 10:24 PM, "Brad Hein"  wrote:

> I took a Raspberry Pi and attached a 48KHz USB sound card, with a big 
> magnetic loop antenna fed
> into the mic. A little cheesy? yes! But I'd like to try and see if I can 
> receive VLF. It's in a
> remote location with little to no interference so I'm thinking my chances 
> should be good. The
> challenge I'm facing is that I need to write the SDR logic to "tune" 
> throughout the 0-24KHz tuning
> range.
> 
> My question is, being that a sound card source presents samples in float and 
> not the usual complex
> data type, can I still apply the same SDR logic that we use for SSB/FM/AM 
> demodulation such as
> those presented in the Gnuradio tutorials (eg.
> http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf) and if 
> not, how do I go
> about translating the float input into something I can use to feed existing 
> AM/FM/SSB demodulator
> flowgraphs?
> 
> I run many other flowgraphs on Raspberry Pi's remotely so the networking and 
> remote aspect of the
> project will be easy for me. I really just need some initial guidance knowing 
> which direction to go
> in terms of tuning.
> 
> Thanks!
> Brad

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

[Discuss-gnuradio] gr_zeromq on MS-Windows ?

[jean-michel.fri...@femto-st.fr]

When running a GNU/Linux VirtualBox on MS-Windows, I whish to make GNU Radio 
running
on the guest OS (GNU/Linux) communicate with GNU Radio running on the host OS 
(MS-Windows)
through ZeroMQ. Has anyone tested the proper operation of the ZeroMQ libraries 
provided
with the MS-Windows port [1] of GNU Radio ?
We get DLL loading errors upon importing _zeromq_swig:

Traceback (most recent call last):
File "", line 1, in 
File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\__init__.py", line 40, in

from zeromq_swig import *
File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py", line 19, 
in

_zeromq_swig = swig_import_helper()
File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py", line 18, 
in
swig_import_helper
return importlib.import_module('_zeromq_swig')
File "C:\Program Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", 
line 41, in
import_module
__import__(name)
ImportError: DLL load failed: Le module spÚcifiÚ est introuvable.
^^^ French for "The specified module cannot be found"

Thanks, JM

[1] 
http://www.gcndevelopment.com/gnuradio/downloads/installers/v1.5.0/gnuradio_3.7.13.4_win64.msi



--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

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

[Discuss-gnuradio] European GNU Radio Days contribution deadline (March 21st)

[jean-michel.fri...@femto-st.fr]

The European GNU Radio Days contribution deadline is getting close (set to
March 21st). Please consider contributing if you wish to share the results
of your work either as oral presentation, demonstration or tutorial.

The template and submission site are available at 
https://gnuradio-fr-19.sciencesconf.org/
Contributions will be published on the GRCon Proceeding web site at
https://pubs.gnuradio.org

See you there, Jean-Michel

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

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