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

[address@hidden]

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" <glen.i.langston@gmail.com> 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.friedt@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 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" 
>> <hmiranda@alumni.stanford.edu> 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