Re: VOR DEMODULATION

[jmfriedt]

The article is in French but GNU Radio's flowcharts are international
(bottom of page 1 for AM, Fig 6 for AM and FM): 
http://jmfriedt.free.fr/hackable_vor.pdf
I can translate to English if interested (or ask a chatbot to translate
since this seems to be the trend now).

Best, JM

> I am working on vor signal reception using USRP N210 in GNU Radio
> Companion, Could you please help me how to do its demodulation
> (suggest me some blocks) as it has both AM and FM modulated signal. I
> am doing this on Windows 10, it is possible to do phase comparison
> without using python block.
> 
> I would greatly appreciate any guidance or suggestions you can
> provide to help me.
> 
> Thank you for your assistance.
> 
> Best regards,
> 
> Muhammad Anas



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

Re: VOR DEMODULATION

[jmfriedt]

I should have acknowledged that the article I wrote is derived from the
presentation of Antoine Blais from the French Civial Aviation University
at https://www.youtube.com/watch?v=apf5fvGSYHc=201s
who does not share GNU Radio flowgraphs but all the underlying
principle of angle of arrival measurement in his excellent presentation.

Best, JM

> The article is in French but GNU Radio's flowcharts are international
> (bottom of page 1 for AM, Fig 6 for AM and
> FM): http://jmfriedt.free.fr/hackable_vor.pdf I can translate to English if 
> interested (or ask a chatbot to translate
> since this seems to be the trend now).
> 
> Best, JM
> 
> > I am working on vor signal reception using USRP N210 in GNU Radio
> > Companion, Could you please help me how to do its demodulation
> > (suggest me some blocks) as it has both AM and FM modulated signal.
> > I am doing this on Windows 10, it is possible to do phase comparison
> > without using python block.
> > 
> > I would greatly appreciate any guidance or suggestions you can
> > provide to help me.
> > 
> > Thank you for your assistance.
> > 
> > Best regards,
> > 
> > Muhammad Anas  
> 
> 
> 



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

Re: B2xx round trip delay

[jmfriedt]

In https://www.youtube.com/watch?v=B_fs9fWPTWw I discuss time of flight
measurement referenced to a local loopback channel (B210 for coherent
dual input receiver) to get rid of the data transfer and general purpose
computation time and only consider the communication delay. The
correlation phase can improve the resolution but oversampling the
correlation peak already strongly improves the resolution by a factor
equal to the SNR.

Best, JM

> By the way, if instead of time, we concentrate on the phase change on
> the correlation peaks,
> can we get to a better measure to relate it to RTD? For instance, we
> can send two sequences
> of the same type and track the correlation peaks phase change and
> relate it to the RTD?
> Thank you!
> 
> On Sun, Aug 13, 2023 at 8:15 AM Marcus D. Leech
>  wrote:
> 
> > On 13/08/2023 00:36, Ali G. Dezfuli wrote:
> > > Hi all,
> > > I'd like to measure the round-trip delay (RTD) between two B200
> > > USRPs. For that, I send a raised-cosined-filtered, BPSK modulated
> > > PN-sequence, and as soon as
> > > I get this signal at the receiver, send back the same sequence
> > > from the Rx to the Tx, and by correlation, I find the RTD.
> > > The question is that the measured RTD is not fixed. I wonder how
> > > can I make it fixed when the distance between the two USRPs is
> > > fixed. After that (A -> B -> A) I want to do that in reverse
> > > order (B -> A -> B) and expect to have the same RTD.
> > > Thanks
> > In your scenario, the latency will necessarily be variable--after
> > all your samples are entering a computer program where those
> >samples are processed and then sent back in the other direction.
> > Since computer software on a general-purpose operating
> >system cannot have fixed latency at fine-grained levels, this is
> > completely expected.
> >
> > This document may help:
> >
> > https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
> >
> >
> >
> >



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

Re: File Sink Block

[jmfriedt]

At https://github.com/jmfriedt/active_radar/ you will find the solution 
I have been using for Synthetic Aperture RADAR using GNU Radio. In this
application I wish to collect coherent measurements from both reference
(transmitted pattern) and surveillance (reflected signal) channels when
the antenna location is stable. The GNU Radio part is 
https://github.com/jmfriedt/active_radar/blob/master/zeromq_demo_rev1.py
is continuously streaming data using a UDP-like datagram flow based on
0MQ Publish. I selected this approach to make sure any
desynchronization between channels (e.g. using RTL-SDR dongles) remains
constant during the whole measurement and not restarting acquisition
with a random delay for each antenna position.
The antenna position is driven by an external piece of software -- I
like GNU Octave but feel free to use Python -- where event are
triggered in the GNU Radio flowgraph, e.g. moving the antenna, then a
0MQ socket is opened, the processing software fetches the number of
samples needed (here correlation), and then continue to the next
position
https://github.com/jmfriedt/active_radar/blob/master/zeromq_demo_rev1.m

Closing/opening the 0MQ socket is not elegant but is the only way I
found to make sure I fetch the latest data from the new antenna
position and not some leftover data from a previous position.

Best, JM

> I'm forwarding this to the mailing list, so that others can have a
> look at it as well! Let me quickly address a few things:
> 
> On 08.08.23 21:32, Henry Powell wrote:
> > The flow graph starts. I collect data and save it to a file with
> > file_sink. I read the file and get the maximum value from the file
> > (differently, I can do this with keep 1 in n, but I would be happy
> > if we proceed through the current situation), then I am saving the
> > maximum value in a list from the data I have saved in the file. I
> > reset the file with the file_sink open and close commands.   
> 
> Interesting! How do you know when to open / close? I ask because this
> sounds a bit difficult, as, depending on the blocks with which you
> capture and process your data, there might still be samples "in
> flight" after your collection finishes.
> 
> > I repeat this maybe 2000 times, varying from 
> > measurement to measurement. After recording all the maximum values
> > in a list, the flow graph terminates itself.
> > 
> > Writing data to a file and reading from there makes me lose speed.
> > I am looking for an alternative solution to it.  
> 
> Ah, what about this concept:
> 
> ┌───┐
>┌┐┌──┐   │Make Chunks│┌─┐
> ┌──┐┌─┐ │││  │   │of
> constant││Find max-││ Head ││ │ │Data
> Capture│───►│Processing│──►│ "single-  │───►│imum per │───►│
> │───►│File Sink│ │││  │   │experiment"││
> chunk  ││N=2000││ │ └┘└──┘
> │   size│└─┘└──┘└─┘ └───┘
> 
> 
> Instead of "taking the data out of GNU Radio" in an asynchronous
> manner, you could look for the maximum within the framework of GNU
> Radio itself. That solves all the file handling overhead.
> 
> You can also still save all your experimental data to a file for
> later analysis (just add *another* File Sink, after "Processing" in
> parallel with "Make Chunks…").
> 
> > If you're saying that I can do it with a vector sink block, I'm
> > trying it right now. I will let you know the results tomorrow.  
> 
> Well, the Vector Sink would be easier than the File Sink, but as
> sketched above I think a different solution might be preferable.
> 
> > Thank you for your reply. Have a nice day.  
> You have good days, as well!
> 
> Marcus
> 
> > Marcus Müller  > <mailto:mmuel...@gnuradio.org>>, 8 Ağu 2023 Sal, 11:55 tarihinde
> > şunu yazdı:
> > 
> > Hi Henry,
> > 
> > that sounds like the description of the Vector Sink block!
> > 
> > But in all honesty, maybe you want to take a different approach
> > altogether; really depends
> > on when during the life cycle of a flow graph you need that
> > data. Could you maybe describe
> > how often and when you want to get data from your GNU Radio
> > flowgraph?
> > 
> > Best regards,
> > Marcus
> > 
> > On 08.08.23 07:26, Henry Powell wrote:  
> >  > Hello, at the end of my grc I use file sink and then, I read
> >  > the data from the file. I repeat this process so many times.
> >  > My problem is that writing to files and readi

European GNU Radio Days 2023: March 29-30 in Paris, France

[jmfriedt]

Dear GNU Radio community,
the 2023 edition of the European GNU Radio Days will be held in
France, hosted by the SYRTE laboratory of the Paris Observatory,
March 29 & 30, 2023.

The call for participation is hosted at
https://gnuradio-eu-23.sciencesconf.org 
with some preliminary program by organizers. 

The call for contribution is open under the keyword "Synchronization"
applied to all layers of the GNU Radio framework, from radiofrequency
signal sampling (MIMO) to symbol or OFDM synchronization, to packet
transfer. Of course GNU Radio is the common framework we wish to share
our experience with during this conference.

If unable to attend, the presentations will be shared after the
conference on the European GNU Radio YouTube channel
https://www.youtube.com/channel/UCFzddPoztcHLuwFWRPJTNrQ
but will *not* be live streamed so please join us to participate to
the discussions or the Q sessions.

Best wishes, hoping to see you at the meeting, 
for the European GNU Radio Days committee, JM



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

Re: Time Partitioned FFT

[jmfriedt]

I hope I am not stating the obvious ... but time is only defined at the
ADC sampling time, everything afterward is asynchronous and indexed
with sample number.

So you have sampled the I+jQ stream x(n), n\in\mathbb{N} at sampling
rate fs, and now want to FFT every 40 ms. The number of samples in 40
ms is P=fs*40e-3 and wisely selecting fs will make this integer as well.

fft1=fft(x(1:Q)) with Q the number of samples in the FFT defined by the
frequency resolution of the FFT bin fs/Q (related to the number of
symbols in the FSK modulation, their frequency spacing and of course fs)

fft2=fft(x(P+1:P+Q))
fft3=fft(x(2*P+1:2*P+Q))
fft4=fft(x(3*P+1:3*P+Q))

whill provide the FFT outputs separated with starting times every 40 ms.
In a multithreaded environment such as GNU Radio (and unlike
GNU/Octave), these FFT will all be running in parallel and provide the
output "simultanously".

The only "problem" left is accumulating enough samples in the work
function of the OOT block to make sure all samples indexed from 3*P+1
to 3*P+Q exist, which is best handled by the GNU Radio scheduler.

Best, JM

> I am attempting to see if I can implement a particular communications
> application called FT8 in GNU radio.
> 
> FT8 uses FFTs in the manner I described to decode the data which
> appears as 160 ms symbols encoded as 8 tones. If I understand the
> protocol correctly, 4 FFTs run concurrently. When 160 ms has
> completed, the 5th FFT is starting.
> 
> My questions at this point boil down to how do you start and stop an
> FFT? How do you implement a delay in starting the FFT? Is what I am
> trying even feasible with GNU Radio?
> 
> Jim
> 



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

Re: wrong antenna mode

[jmfriedt]

Salut Maxime,
a lot of arguments seem to have changed with UHD4. In the
UHD: USRP Source, go to RF Options and for each board define
Ch i: Antenna
manually, replacing the TX/RX tab entry with your own. 
I use "A" setting.

Probably your Subdev Spec that might have been defined with UHD3
is no longer valid as well: in the General menu of UHD Source I had
to set
A:0 B:0
under Mb0: Subdev Spec.
Not sure how this setting relates to
https://files.ettus.com/manual/page_dboards.html
and the description that
Antenna Mode A: real signal from antenna RXA
Antenna Mode B: real signal from antenna RXB
for the BasicRX.

Best, JM

> I am using a X310 under uhd4.1.0.5, gnuradio 3.8 and rfnoc.
> Whenever I use an antenna mode with either usrp sink or source, I get
> an error stating: invalid antenna mode: RX/TX
> 
> python error is:
> return_uhd_swig.usrp_source_sptr_set_antenna(self, ant, chan)
> 
> How to solve this?
> 
> Thanks in advance,
> Maxime DUPONT
> 
> 



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

Re: Gnuradio-companion as a network relay

[jmfriedt]

> I am wondering if it is possible to reliably make another gnuradio
> instance on a low powered computer (like a intel minipc or raspberry
> pi) to interface with the SDR and be connected to the high end cpu
> laptop via a lan cable. This would allow the laptop to be placed far
> away easing physical constraints and also allow easier management.
> 
> Could someone point me at flowgraphs that would allow this?

I try to show at https://www.youtube.com/watch?v=M8dqgqO4TuI starting
at 9:30 how to stream data from GNU Radio using ZeroMQ
publish/subscribe, in my case to external Python software which could
very well be remote if the IP address is not 127.0.0.1, but will be
even easier to implement if the client is another GNU Radio flowchart.
I am currently doing exactly that: recording on a Raspberry Pi and
streaming to a more powerful computer for processing (again from a
dedicated Python script rather than another GNU Radio instance, e.g
around 45 min of that video).

Best, JM

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

Re: OOT Binding problem

[jmfriedt]

GNU Radio 3.9 is now available for embedded boards (including Raspberry
Pis) in the BR2_EXTERNAL repository at 
https://github.com/oscimp/oscimp_br2_external
and has been tested (on Raspberry Pi 4) with the 3.9 port of gr-acars
and gr-rpitx as will be presented at FOSDEM. Of course further testing
is needed to make sure all operational conditions are met until 3.9
becomes the official GNU Radio release by Buildroot.

Best, JM

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

Re: Synchronization: PPS and Tx signal in a USRP N200

[jmfriedt]

If it can be of any help, we discussed generating a GPS-aligned 1-PPS
in http://jmfriedt.free.fr/ifcs2021.pdf and the oral presentation at
http://jmfriedt.free.fr/ifcs2021_presentation_jmfriedt.mp4 prepared
for the International Frequency Control Symposium (IFCS).

What we realized when working on this topic is that the only place
where time is known in an SDR processing sequence is at the ADC sample
acquisition step, since all subsequent processing and data transfer
afterwards are asynchronous, including the multitasking non-real time
operating system GNU Radio is running on. Hence, the control on the
1-PPS alignement can only be achieved at the FPGA level clocking the
ADC: the host clock is irrelevant since we do not know how much time
was needed to transfer and process data. Luckily, GNU Radio provides a
timestamp on each sample, assuming no data was lost since streaming
started, so the control signal can be fed back to the SDR clock if the
delay between reference and generated 1-PPS is measured using the same
time reference of the ADC clock.

Best, JM

> > On 2021-12-10 17:25, isaac mario tupac davila wrote:  
> > > Hello everyone!
> > >
> > > My name is Isaac. I have a curious situation here... I've
> > > generated a pulsed signal per second. I've saved one second
> > > period in a .h5 file, so that I'm sure I'm having a fixed signal
> > > per second, and then repeat it in my GRC flowgraph. .
> > >
> > > To use this signal as Tx I'm trying to synchronize a USRP N200 and
> > > a trimble in GRC. After run my flowgraph, this is what I see:
> > >
> > > imagen.png
> > >
> > > imagen.png
> > >
> > > The yellow signals are the PPS of my trimble and my purple signals
> > > are my tx signal per second. They are periodic in time but when
> > > you see it deeper, the difference between the timble PPS and my Tx
> > > signal is approx 97 ms. I think this difference should be close to
> > > cero, as my USRP and trimble are synchronized. ¿What is happening
> > > here? ¿Is this a normal behavior? I'm using unknown PPS to
> > > configure my UHD:USRP sink in GRC
> > >
> > > I'll appreciate any help to clarify this behavior
> > >
> > > Regards
> > > Isaac T.
> > >  
> > Your flow-graph made very little sense to me.  If you want to 
> > synchronize your TX, you have to take explicit measures to ASK the
> > USRP to schedule your transmits at specific times.
> >    The 1PPS signal only synchronizes an internal time-stamp clock in
> > the unit.  It has NO WAY of knowing what the *meaning* of your
> > samples are, so it can't possibly
> >    synchronize some arbitrary event in your continuous sample stream
> > to 1PPS without you explicitly asking for when your bursts need to
> > be sent.
> > 
> > https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
> >   
> 
> 
> 



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

Re: reentrant values?

[jmfriedt]

I am sure there are many great ways of interacting between a client and
a GNU Radio flowchart, but my knowledge of IP networking stopped at
TCP/UDP/rawIP and I was only introduced in 2017 to 0MQ, so all these
complex XML/JSON communication schemes are too abstract for me, hence my
interest in a basic TCP server that I could call from telnet. So I am
sorry but no, I have never experienced with xmlrpc.

Apologies, JM

> Michel this is a great talk, I had been meaning to watch it. On the
> topic of parameter control from external software, have you
> experimented with xmlrpc in GNURadio? That’s how I control most of my
> flowgraphs when i need to automate parameter control, for example on
> a loose timer. I think the internal Python module and snippets are
> more compact though. 
> 
> 
> 
> > On Aug 11, 2021, at 12:40, jmfriedt
> >  wrote:
> > 
> > I think I have been trying to address this topic in
> > https://www.youtube.com/watch?v=M8dqgqO4TuI
> > with complementing 0MQ streaming (target to host) with a TCP-server
> > thread running next to the GNU Radio Python flowgraph, accepting
> > commands (host to target) to tune flowchart parameters.
> > 
> > Best, JM
> > 
> > --
> > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
> > Besancon, France
> > 
> > August 11, 2021 6:27 PM, "GNU Radio, the Free & Open-Source Toolkit
> > for Software Radio"  wrote:
> > 
> > 
> > 
> >Hello gnuradio citizens.
> > Hope this day finds you well.
> > 
> > will attempt to keep my myriad questions succinct.
> > 
> > sin/cos feeding flow graph via udp.
> > 
> > logically, these are the values painted thusly:
> > 
> > to make i/q "proper", using the poor Arduino to do some math,
> >looses a bit in translation :) 
> > sure would be nice to do the math inside gr...
> > 
> > question 2: how can use an value via virtual source or network
> >value as parameter or value to feed say, adjust tuning? such as
> > one can do with the qt slider. does such require an module? control
> >port? think i was gone that day :) 
> > is there some dependency graph or other? - ever amazed how all
> > the various packages are stitched let make this all happen...
> > 
> > thank you.
> > --If something is requisite, how can it possibly be,
> > prerequisite? 
> > 
> > vanitas vanitatum omnia vanitas
> > later, steve
> > http://umn.edu/~barbo
> > 
> > 
> > 
> > -- 
> > JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
> > Besancon, France
> >   



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

Re: reentrant values?

[jmfriedt]

I think I have been trying to address this topic in
https://www.youtube.com/watch?v=M8dqgqO4TuI
with complementing 0MQ streaming (target to host) with a TCP-server
thread running next to the GNU Radio Python flowgraph, accepting
commands (host to target) to tune flowchart parameters.

Best, JM

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

August 11, 2021 6:27 PM, "GNU Radio, the Free & Open-Source Toolkit for
Software Radio"  wrote:



Hello gnuradio citizens.
 Hope this day finds you well.
 
 will attempt to keep my myriad questions succinct.
 
 sin/cos feeding flow graph via udp.
 
 logically, these are the values painted thusly:
 
 to make i/q "proper", using the poor Arduino to do some math,
looses a bit in translation :) 
 sure would be nice to do the math inside gr...
 
 question 2: how can use an value via virtual source or network
value as parameter or value to feed say, adjust tuning? such as one
can do with the qt slider. does such require an module? control
port? think i was gone that day :) 
 is there some dependency graph or other? - ever amazed how all the
various packages are stitched let make this all happen...
 
 thank you.
 --If something is requisite, how can it possibly be, prerequisite? 
 
 vanitas vanitatum omnia vanitas
 later, steve
 http://umn.edu/~barbo



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

European GNU Radio Days: 2 days left before the big event !

[jmfriedt]

Dear GNU Radio enthusiasts,

the European GNU Radio Days will start in two days: those who wish to
attend can connect to the video streams since the whole conference is
held virtually.

The program is now final and a few schedules have been subject to minor
adjustements: please check
https://gnuradio-eu-21.sciencesconf.org/program. You might also enjoy
the joint Software Defined Radio Academy session whos final program is
now at https://2021.sdra.io/pages/programme.html

All conferences will be streamed on YouTube:

* the oral presentations will take place on Thursday June 24 starting
  at 1:30 PM Central European Summer Time (UTC+2) and streamed on
  https://youtu.be/iXshTqIpgKk

Please feel free to ask questions through the YouTube chat service and
they will be aggregated by the moderator to be shared with the speaker
at the end of the talk or during the coffee break.

* the tutorials will be streamed on Friday, June 25, on YouTube as
  well, starting a bit eariler at 9:25 AM (CEST) with

https://youtu.be/NAIzz4oLWz8 for the basic tutorials and

https://youtu.be/fWDbHHkz42k for the advanced tutorials

These recorded tutorials will be accompanied with live interactions
with the speakers through a Big Blue Button service for registered
participants. Registration is possible until the last minute by
following the instructions in each channel description.

Looking forward to meeting you virtually,
for the European GNU Radio Days organizing committee, JM

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

European GNU Radio Days program and broadcast

[jmfriedt]

Dear GNU Radio enthusiasts,
the program of the European GNU Radio Days is being finalized and is now
published at https://gnuradio-eu-21.sciencesconf.org/program. 
Please expect a few minor adjustements as videos are being uploaded but
the coarse schedule is completed and available. The oral presentations 
including live interaction with the presenting speakers will be
broadcast on https://youtu.be/iXshTqIpgKk June 24th starting at 1:30 PM 
Central European Summer Time (UTC+2) to accomodate most participant
timezones, and will conclude around 6PM with an amazing description
of the challenge solution by the first winner of the prize that you
will no want to miss. 

The tutorials will be broadcast on https://youtu.be/NAIzz4oLWz8 for the
introductory tutorials and https://youtu.be/fWDbHHkz42k for the
advanced tutorials during June 25th. The videos of the tutorials are
being uploaded on the European GNU Radio Days YouTube channel at
https://www.youtube.com/channel/UCFzddPoztcHLuwFWRPJTNrQ 

Finally, a joint session with the Software Defined Radio Academy (SDRA)
during June 26th will highlight the connections between the fields of
software defined radio and ham radio in fabulous presentations
ranging from long range IoT communication to direction of arrival (DoA)
phase analysis and light digital communication. Please check the SDRA
announcements for the YouTube channel url. 

Best wishes, JM

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

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

[jmfriedt]

For what it is worth, slide 10 of 
https://archive.fosdem.org/2020/schedule/event/fsr_software_defined_radio_based_scientific_instrumentation/attachments/slides/3895/export/events/attachments/fsr_software_defined_radio_based_scientific_instrumentation/slides/3895/fosdem2020_instrumentation.pdf
shows how phase between two inputs of a B210 is measured as the ratio
of the FFT (Aexp(jwt+phi1)/Aexp(jwt+phi2)~exp(j(phi1-phi2) even if a LO
offset w remains, here with respect to an exteral acousto-optical
modulator oscillator) and I have hidden from that discussion the need to
heterodyne digitally the signal using a Xlating FIR for weak signals as
shown on slide 24 of http://jmfriedt.free.fr/ifcs2021_tutorial.pdf
That would be most convenient for CW signals as illustrated on slide 17 
of that same presentation, otherwise phase of the cross correlation
indeed for broadband signals (slide 10 only shows the magnitude but
replace Complex to Mag with Complex to Arg),

JM

> On 06/13/2021 04:02 PM, Skyvalakis Konstantinos wrote:
> > Agreed. The compensation part is not the one I worry about. What 
> > worries me the most is the angle-in-radians part.
> >
> > Let's say that from the time sink plot I observe that I have pi/2 
> > radians phase offset between channel 1 and channel 2. How do I know 
> > it's pi/2 radians and not -3pi/2?
> >
> > To be precise, I am also dumping the 2 channels complex data to 2
> > file sinks, which I then import on matlab for easier and faster 
> > experimentation.
> >
> > In other words, how can I precisely calculate the 4 discrete phase 
> > shifts I am observing in my application?
> >
> > Should I use cross correlation?
> >
> > Should I use Hilbert transform?
> >
> > I don't have a very noisy application, in case that plays a very 
> > crucial role.
> >
> > Thanks.
> If you consult the "uhd_fft" app within the gnuradio/gr-uhd source
> tree, you'll see that it has a mode where it will display the
>relative phases of two channels when you have a two-channel input.
> It also has a bunch of different synchronization options,
>so you can glean a lot of technique info from that.
> 
> Also, there's a fair amount of "stuff" out there on phase
> measurements with Gnu Radio--this is just the first one that popped up
>in a Google search:
> 
> https://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
> 
> 
> >
> > On Jun 13, 2021 22:06, Marcus D Leech 
> > wrote:
> >
> > Phase *correction* is easy once you know what that correction
> > should be. Just a complex multiply-const by
> >
> > Complex(math.cos(angle-in-radians),math.sin(angle-in-radians))
> >
> > Or the equivalent in complex exponential notation.
> >
> >
> >
> > Sent from my iPhone
> >
> > On Jun 13, 2021, at 1:52 PM, Skyvalakis Konstantinos
> >  wrote:
> >
> > 
> > Understandable. However, if you eventually hear anything
> > about it please let me know.
> >
> > Can I contact you again tomorrow for some questions I have
> > about the phase correction block I need to make? (I mean
> > through discuss-gnuradio)
> >
> > Thank you very much.
> >
> > On Jun 13, 2021 19:37, Marcus D Leech
> >  wrote:
> > I haven’t heard fro R on it. Part of the problem is the
> > N200 was designed over a decade ago, and the original engineering
> > team have long since departed…
> >
> > Sent from my iPhone
> >
> > On Jun 13, 2021, at 6:25 AM, Skyvalakis Konstantinos
> >  wrote:
> >
> > 
> > Hi Marcus and sorry for bothering you again, but I'd
> > like to ask if you have any news regarding my problem.
> >
> > Thank you.
> >
> > On Jun 11, 2021 16:15, Skyvalakis Konstantinos
> >  wrote:
> >
> > ​Yes it kind of helps, because if I manage to apply a
> > phase shifting/correction technique, then all 4
> > scenarios could produce sensible data.
> >
> >
> > I am trying to build a phase correction block now, that
> > will compare the 2 received signals, to see which phase
> > shift out of the possible 4, minimizes the absolute
> > phase difference between the 2 channels.
> >
> >
> > After I figure out which phase offset is the correct
> > one, out of all 4, then I can run the rest of my
> > DoA application. It is a bit of a pain in the a**, but
> > it will have to do in case it never gets fixed.
> >
> >
> > Let me know if you have any news from Ettus.
> >
> >
> > Thanks again.
> >
> >
> > 
> > 
> > *From:* Marcus D Leech 
> > *Sent:* Friday, June 11, 2021 4:05 PM
> > *To:* Skyvalakis Konstantinos
> > *Subject:* Re: Phase Synchronize 2 USRP 

European GNU Radio Days contest for winning a B205mini

[jmfriedt]

Dear GNU Radio enthusiasts,
as part of the virtual event European GNU Radio Days to be held June
24--26, 2021 as a joint meeting with the Software Defined Radio Academy
for the Saturday session, our generous sponsor NI is donating two
B205mini. A challenge has been set to select the winners amongst the
participants, as provided at
https://gnuradio-eu-21.sciencesconf.org/resource/page/id/3

The first two best entries will be offered the B205mini units selected
on the provided answers.

Best wishes and good luck, 
for the European GNU Radio Days organizing committee, JM

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

Re: tag offset question

[jmfriedt]

That makes sense indeed, thank you for your help and advice which
allowed me to track the issue, if not find the solution.

The long answer: I am trying to propagate a tag in gnss-sdr. When the
FPGA detects a condition it introduces a given sequence in the IQ stream
detected by the Source block. This tag is properly propagated along the
processing chain as long as no decimation occurs, which allowed me to
understand that get_tags_in_window() provides an offset information
in *absolute* index (and not relative as the search window), which is 
indeed documented but I was not reading properly.
The problem seems to arise when gnss-sdr tracks the GPS signal in a
gr_sync_decimator whose noutput_items is equal to 1 in the work
function, so that the tag must be lost or the decimation factor so
large that the tagged sample is dropped (which makes sense because at 
this point we convert the 1.023 Mb/s CDMA to the 20 bps NAV payload).

So back to the drawing board, tag propagation seems not the way to go
in this application.

Thanks, JM

> It is possible that one of the blocks in the middle of your flowgraph
> is not handling the tags properly. What is between the sender and
> receiver?
> 
> On Mon, May 17, 2021 at 11:17 AM Jeff Long 
> wrote:
> 
> > When there is a rate change, tag offsets are adjusted to match.
> > Otherwise, the tag spacing should stay the same, taking into
> > account that the tags may end up in different calls to work().
> >
> > On Mon, May 17, 2021 at 11:07 AM jmfriedt
> >  wrote:
> >  
> >> I am trying to get an accurate timing of a given sample (1-PPS
> >> transition). To do so, a marker is injected in the AD9831
> >> datastream in the B210 FPGA. When this tag is detected in the UHD
> >> source block, a tag is created in the stream:
> >>
> >> for (item=0;item >>{if (ch==0)  // check if channel 0
> >>   {if (in[item]==_tag_pps_int)  // check marker
> >> detection {add_item_tag(0, // Port number
> >> nitems_written(0) + item,   // Offset
> >> pmt::string_to_symbol("1PPS"),  // Key
> >> pmt::from_double(3.14159)); // Value
> >>  ...
> >>
> >> Displaying the item number when the marker is detected, I get
> >> things like 444331/524288 or 364347/524288 (item/noutput_items)
> >> which seems realistic.
> >>
> >> Downstream the flowchart, after many other processing blocks, I
> >> check for the tag in the window of samples that were just
> >> transferred std::vector PPS_tag;
> >>   get_tags_in_window(PPS_tag,0,
> >>  0, // abs_start,
> >>  noutput_items, // uint64_t abs_end);
> >>  pmt::string_to_symbol("1PPS")) ;
> >>   if (PPS_tag.size() != 0)
> >>  { printf("\n** PPS_tag received: %ld (%ld/%d):
> >>   message=%.9f",PPS_tag.size(), noutput_items,
> >>   to_double(PPS_tag[0].value));
> >> ...
> >> and there I *always get* PPS_tag.offset=1.
> >>
> >> If on the emitter side I create two tags separated by 42 i.e.
> >> add_item_tag(0,
> >> nitems_written(0) + item,
> >> pmt::string_to_symbol("1PPS"),
> >> pmt::from_double(3.14159));
> >> add_item_tag(0,
> >> nitems_written(0) + item + 42,
> >> pmt::string_to_symbol("1PPS"),
> >> pmt::from_double(3.14159));
> >> then the receiver indeed detects PPS_tag.size() = 2 but still
> >> both PPS_tag[0].offset and PPS_tag[1].offset are equal to 1 !
> >> I am obviously misunderstanding the behviour of tag.offset: can
> >> anyone enlighten me on how to identify the index of the sample
> >> carrying the tag ?
> >>
> >> Thanks, JM
> >>
> >>  



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

tag offset question

[jmfriedt]

I am trying to get an accurate timing of a given sample (1-PPS
transition). To do so, a marker is injected in the AD9831 datastream in
the B210 FPGA. When this tag is detected in the UHD source block, a tag
is created in the stream:

for (item=0;item PPS_tag;
  get_tags_in_window(PPS_tag,0,
 0, // abs_start,
 noutput_items, // uint64_t abs_end);
 pmt::string_to_symbol("1PPS")) ;
  if (PPS_tag.size() != 0)
 { printf("\n** PPS_tag received: %ld (%ld/%d):
  message=%.9f",PPS_tag.size(), noutput_items,
  to_double(PPS_tag[0].value));
...
and there I *always get* PPS_tag.offset=1.

If on the emitter side I create two tags separated by 42 i.e.
add_item_tag(0,
nitems_written(0) + item,   
pmt::string_to_symbol("1PPS"),  
pmt::from_double(3.14159)); 
add_item_tag(0,
nitems_written(0) + item + 42,
pmt::string_to_symbol("1PPS"), 
pmt::from_double(3.14159)); 
then the receiver indeed detects PPS_tag.size() = 2 but still
both PPS_tag[0].offset and PPS_tag[1].offset are equal to 1 !
I am obviously misunderstanding the behviour of tag.offset: can anyone
enlighten me on how to identify the index of the sample carrying the
tag ?

Thanks, JM

Re: Capture and Record all signal data with the same number of samples

[jmfriedt]

head is your friend. See attached.

JM

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

> May 8, 2021 12:58 AM, "Muhammed Sefa KOÇAKOĞLU"
>  (mailto:msefakocako...@gmail.com?to=%22Muhammed%20Sefa%20KO%C3%87AKO%C4%9ELU%22%20)>
> wrote: Hi Everyone, I'm recording a signal with File Sink. I will
> catch many signals. I want the sample numbers of all of them to be
> the same. (Regarding Wi-Fi signals in 2.4 GHz bands ...) For example,
> I want to see 15 million samples when I read each signal I capture in
> matlab. (We can limit the sample number on matlab, I know but I want
> to make GNU Radio directly.) For this, I thought to record for equal
> time. but I could not fully provide.
> 
> In summary, how can I ensure that all the signals I have captured are
> in the same sample number?
> 
> Best Regards...
> --Muhammed Sefa KOÇAKOĞLU



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


d.pdf
Description: Adobe PDF document


d.grc
Description: application/gnuradio-grc

quantization noise demonstration ?

[jmfriedt]

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

[Discuss-gnuradio] B210 RX bandwidth setting from gnuradio-companion ?

[jmfriedt]

I am characterizing a weak (-80..-60 dBm) signal next (5 MHz away) to a
strong (-30..-40 dBm) carrier interfering with my measurement. I am
looking at power and phase (these are CW signals), and hit the issue
that the interfering carrier affects the sideband power measurement.

To demonstrate the effect, I mix a 295 MHz +7 dBm LO input (-45 dBm
output from the mixer isolation) with a -64 dBm RF intput at 5 MHz,
creating a strong carrier at 295 MHz and a weak sideband at 300 MHz
with -70 dBm power (due to mixer conversion efficiency of -6 dB).

As mentioned at https://files.ettus.com/manual/page_usrp_b200.html

---
The analog frontend has a seamlessly adjustable bandwidth of 200 kHz to
56 MHz.

Generally, when requesting any possible master clock rate, UHD will
automatically configure the analog filters to avoid any aliasing (RX)
or out-of-band emissions whilst letting through the cleanest possible
signal.

If you, however, happen to have a very strong interferer within half
the master clock rate of your RX LO frequency, you might want to reduce
this analog bandwidth. You can do so by calling
uhd::usrp::multi_usrp::set_rx_bandwidth(bw).
---

so obviously I'd like to reduce RX bandwidth to reject the interfering
carrier. The question is: how do I do that from the UHD USRP block in
gnuradio-companion. Since the RX bandwidth in the RF settings seem to
have no impact on the B210 RX characteristics (I tried a RX bandwidth
of 200 kHz with no effect on the impact of the carrier 5-MHz away), I
did follow https://files.ettus.com/manual/page_configuration.html
and set master_clock_rate=5.12 MHz (my sampling rate is 512 kS/s) which
indeed allows me to reject the interfering carrier (further away than
5.12/2=2.56 MHz) and get a clean phase and power measurement on the 
sideband whatever the carrier power.

Questions:
1/ what is the impact of master_clock_rate, i.e. what parameter am I
modifying by doing this ? The experiment is a physics experiment (ie
digital lock-in amplifier) and not digital communication, so I do not
care about bandwidth but I'd like to understand the impact of this
master_clock_rate.
2/ I am not too happy about changing a clock where I try to set a
filter. What could be the proper argument to the UHD USRP block to set
the receiver bandwidth to a sub-5 MHz value ?

Thanks, 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

Re: [Discuss-gnuradio] gr_zeromq on MS-Windows ?

[jmfriedt]

Thank you for your reply which helped me find a (temporary at least)
solution to my problem: indeed you reminded me that we had been
streaming data from GNU Radio to a MS-Windows computer running ZeroMQ
on its GNU Radio flowgraph and that was working well last
december/january. So downgrading to 3.7.12 solved my short term problem
of getting GNU Radio+ZMQ running on MS-Windows. Unfortunately I am
not able to identify the name mismatch you state in your email: I did
find some name mismatch with vc140 sentences for the boost library but
not for ZeroMQ.

Thanks for the support,
Jean-Michel

> There is a problem with the latest installer related to the changes
> in the way libzmq's build process works.
> So the libraries are misnamed.
> Rename the zmq library to libzmq.dll (it'll be something like
> libzmq_v140_mt_something.dll currently) and see if that resolves the
> issue.
> 
> Geof
> 
> On Wed, Apr 17, 2019 at 12:30 PM Andrej Rode  wrote:
> 
> > Hi Jean-Michael,
> >
> > On Wed, 17 Apr 2019 15:34:21 +
> > "jean-michel.fri...@femto-st.fr" 
> > wrote: 
> > > 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"  
> >
> > This usually indicates that `_zeromq_swig.(so|dll)` was found, but
> > contains unresolvable dynamic linking. Maybe libzmq is missing in
> > the library_path/dll_path.
> >
> > On a Linux host I'd go here: "C:\Program
> > Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\" and look at
> > the `_zeromq_swig.so` with `ldd`. I don't know what the tool of
> > choice on a Windows platform is for looking up the dynamic linking
> > of a library, but certainly that information will help you locate
> > the missing pieces.
> >
> > Cheers
> > Andrej
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >  



-- 
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

Re: [Discuss-gnuradio] GNU RADIO on Ubuntu Server

[jmfriedt]

> Radio as you need; so, no GRC, no gr-qtgui, hence no GTK, QT, …). I'd
> expect that to easily fit in 4 GB.

we have GNU/Linux + python + GNU Radio in less than 32 MB on the PlutoSDR :)
https://github.com/oscimp/PlutoSDR

JM

-- 
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

Re: [Discuss-gnuradio] [GSoC2018] Adding Passive radar and multiple device support to gr-radar toolbox

[jmfriedt]

> All in all, this is pretty ambitious, but exciting!
> How will you tackle the OFDM signal recovery? I think your reference
> [2] is really much to be completely done in one GSoC, so it would be
> totally OK to say you just picked a reduced approach. Still, if you
> want to do that in all its glory, that would be cool, too, but I'd ask
> Martin how much work he'd expect that to be, and if necessary, reserve
> more time for the algorithmic part alone. I'm also including Jean-
> Michel Friedt of low-cost passive radar fame[A], as I hope he might
> have a moment to read and comment on your proposal.

I am not sure I can provide useful comments on the proposal, whose
various iterations I have been reading as they were being updated. Real
time passive radar processing seems challenging to me, and I would
advise looking at alternatives to the brute force cross correlation of
the Doppler shifted signal. You might want to have a look at 
https://www.researchgate.net/publication/279069212_Batches_algorithm_for_passive_radar_A_theoretical_analysis
and especially its Table I which lists computational complexity of
various algorithms. An updated version of the document cited by Marcus
is at http://jmfriedt.free.fr/dvbt_hardware.pdf (submitted for
publication but not yet accepted): beyond the improved batches
algorithm allowing for much faster computation, we also address using
multiple receivers in parallel, each tuned to different carrier
frequencies.

JM

-- 
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

Re: [Discuss-gnuradio] QPSK demodulation: Constellation Soft Decoder question

[jmfriedt]

after a few more experiments with synthetic signals, I figured out that
the Constellation Decoder output is already the set of bit pairs
expected from the QPSK constellation, not the families themselves. So
as expecter -1-j->00, -1+j->01, 1+j->11 and 1-j->10, it all makes
sense with an output rate twice the input rate in the case of QPSK.

JM

> I am investigating Meteor M2 decoding. So far I had tackled BPSK
> decoding (RDS, GPS) and it is the first time I analyze QPSK signals.
> Based on github.com/otti-soft/meteor-m2-lrpt.git, decoding works
> fantastically well, but I don't understand why. Costas and MM Clock
> recovery are understood, but it is the first time I meet the
> Constellation Soft Decoder. I am unable to find any information on its
> output and operating principle, but most worrying to me is that I
> believed that the real output would exhibit four levels following the
> decision of which bit pair was the most probable, but when displaying
> on a scope the output of the Constellation Soft Decoder I only see two
> well defined levels.
> Can anyone bring some insight on this processing block, which would
> help me understand the structure of the resulting file and hence start
> tackling the digital decoding part of the protocol. 
> The flowgraph I use in this investigation is visible at
> http://jmfriedt.sequanux.org/airspy_m2_lrpt_rxtest.png with an input
> file containing complex I/Q samples collected during a Meteor M2 pass.
> 
> Thanks, JM
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
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] QPSK demodulation: Constellation Soft Decoder question

[jmfriedt]

I am investigating Meteor M2 decoding. So far I had tackled BPSK
decoding (RDS, GPS) and it is the first time I analyze QPSK signals.
Based on github.com/otti-soft/meteor-m2-lrpt.git, decoding works
fantastically well, but I don't understand why. Costas and MM Clock
recovery are understood, but it is the first time I meet the
Constellation Soft Decoder. I am unable to find any information on its
output and operating principle, but most worrying to me is that I
believed that the real output would exhibit four levels following the
decision of which bit pair was the most probable, but when displaying
on a scope the output of the Constellation Soft Decoder I only see two
well defined levels.
Can anyone bring some insight on this processing block, which would
help me understand the structure of the resulting file and hence start
tackling the digital decoding part of the protocol. 
The flowgraph I use in this investigation is visible at
http://jmfriedt.sequanux.org/airspy_m2_lrpt_rxtest.png with an input
file containing complex I/Q samples collected during a Meteor M2 pass.

Thanks, JM

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

Re: [Discuss-gnuradio] Doppler detection

[jmfriedt]

I am also unable to understand what you aim (or problem) is but if it can be of
any use to you, a small movie of 24 hour of GRAVES radar recording is available 
at
http://jmfriedt.free.fr/1707_graves_36h.ogg
Horizontal axis is Doppler shift in Hz (df=2*v/c*143.05 MHz, or a velocity of 
750 km/h
for a 200 Hz Doppler shift, consistent will plane velocity): all the horizontal 
lines are
nearby planes. I do not have the sensitivity for detecting satellites. If it 
can be of any 
help, since I struggled initially to figure out how to save spectra for 
post-processing (as 
opposed to the raw signals which would have taken too much disk space), my 
gnuradio flowchart 
is at http://jmfriedt.sequanux.org/170828_grc.png (the trick was to use to 
stream to vector, 
which I had not investigated prior to this project, and inform the filesink of 
the vector 
length at the output of the FFT).

JM

> Ok like the primary radar I have spent 7 years working on 
> 
> How do I pull out doppler shifted signal from a waterfall spectrum
> 
> The doppler shift is slow though
> 
> Not a chirp but a slow 5 minute chirp
> 
> Andrew
> 
> 
> 
> Sent from my iPhone
> 
> > On 23 Aug 2017, at 8:05 pm, Marcus Müller  wrote:
> > 
> > So, adapt the scale with which you look at things.
> > 
> > I think your question could actually use a lot of "describe the problem 
> > that you're actually having".
> > 
> > The point is that you don't really seem to understand how you'd "pull the 
> > doppler signals" out of a combination of signals. Now, we all love to help 
> > each other, but with this, I'm really stuck with "I don't know what Andrew 
> > needs help with". My gut feeling is that you haven't got a firm grip on 
> > what Doppler estimation really is, or how you can do it:  
> >> I guess this would require some sort of processing ?  
> > GNU Radio can help you /implement/ that, but at least the basic principles 
> > are universal. I'd have done very much the same as Chris: point you to 
> > references, which will allow you to recognize the math behind Doppler 
> > estimation from actual implementation. 
> > Best regards,
> > 
> > Marcus  
> >> On 08/23/2017 07:42 AM, Andrew Rich wrote:
> >> Sorry you misunderstood my question 
> >> 
> >> I want the doppler shift of the satellites to be very distinct from the 
> >> station with no doppler shift 
> >> 
> >> Much like doppler shift radar perhaps 
> >> 
> >> But the change in frequency can be minutes long for the satellite pass
> >> 
> >> Andrew 
> >> 
> >> 
> >>   
> >>> On 23 Aug 2017, at 3:26 pm, Chris Kuethe  wrote:
> >>> 
> >>> https://github.com/wnagele/gr-gpredict-doppler
> >>> https://github.com/daniestevez/doppler
> >>> 
> >>> might be helpful or at least inspirational.
> >>>   
>  On Tue, Aug 22, 2017 at 9:58 PM, Andrew Rich  
>  wrote:
>  Sorry this is new to me
>  
>  I have just worked out I can see satellites in a waterfall display due 
>  to their doppler shift
>  
>  I think that lends itself to meteor shower
>  
>  Can gnu radio be used to assist pulling out the 
>  doppler signals from the non doppler ones ?
>  
>  I guess this would require some sort of processing ?
>  
>  Andrew
>  
>  Sent from my iPhone
>  
>  ___
>  Discuss-gnuradio mailing list
>  Discuss-gnuradio@gnu.org
>  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> GDB has a 'break' feature; why doesn't it have 'fix' too?  
> >> 
> >> 
> >> 
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio  
> >   


-- 
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

Re: [Discuss-gnuradio] multi-rtl phase synchronization

[jmfriedt]

> The I/Q plot show complex cross-correlation between two noise signals at
> 100 MHz center frequency (2.4 MHz bandwidth noise). The phase of the signal
> can be converted into time and Allan deviation, but I never did. I was just
> happy to see a straight line.

I continued the measurement this morning after having the temperature of the 
dongles 
stabilized overnight: I gain a factor 10 stability on a 2 hour measurement: 
http://jmfriedt.sequanux.org/3allan.pdf

Actually I just discovered something fascinating: I was contemplating which 
radio
source would be best suited for the passive radar experiment. Not being able to
find any suitable source while scanning the environment with a yagi antenna, I 
decided
to tune to the 143.05 MHz frequency of the GRAVES [1] bistatic emitter which 
happens not to
be too far away. To my great surprise, after replacing the quartz (drifting far 
too much)
with a hydrogen maser referenced synthesized tuned to 28.8 MHz, I get amazing 
doppler
shifted traces of reflectors between the emitter and my receiver. I didn't 
expect
such a low quality receiver to be able to extract this signal: example of a 
waterfall trace
at http://jmfriedt.sequanux.org/graves.pdf

JM

[1] https://en.wikipedia.org/wiki/Graves_%28system%29

-- 
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] multi-rtl phase synchronization

[jmfriedt]

I am tackling again the coherence issue with multi-RTL dongles for 
interferometric measurements.
I have two R820T2 based DVB-T dongles connected to the same USB bus (USB hub) 
and am feeding
both dongles with a high quality 100-MHz source (-34 dBm output of a 
Rohde SML03 synthesizer,
30 dB gain on the RF frontend of the dongles) -- setup shown at 
http://jmfriedt.sequanux.org/DSC06032.JPG. 

I am trying to reproduce the graph "IQ plot of the z_1/z_2 relative phase 
signal over ~6000 seconds at 
1 Hz sample rate" from 
http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
Actually I notice that this graph shows something in units in the tens of 
thousands: what is
"Z1/Z2 relative phase" ? How can I convert this axis to angle in degrees ?

I have manually applied the patch described at 
http://www.rtl-sdr.com/forum/viewtopic.php?f=1=531 to
turn off dithering (I have checked that the function is called when starting 
gr-osmosdr -- whether 
dithering is actually disabled is challenging to assess). The resulting phase 
measurement -- recording 
either with multi-rtl source or two osmosdr sources, multiplying one output by 
the complex conjugate 
of the other, complex to phase and saving the resulting phase at 200 Hz rate, 
is at
http://jmfriedt.sequanux.org/allan.pdf (left is time domain plot, right is 
Allan deviation). On the
short term we have sub-degree stability, on the long term several degree drift. 
I have checked that
thermal transfer between the two dongles is of utmost importance: if I cool one 
of the dongles and keep
the other at room temperature, I observe phase rotations of several tens of 
degrees. I believe such
long term phase instability is of little concern for passive radar measurements 
where coherence over
several ms only is needed, but I find conflicting conclusions on long term 
phase stability.

Can other experimenters on this topic comment and assess whether 
http://jmfriedt.sequanux.org/allan.pdf
can be improved, or if is in line with the expected behaviour of these dongles ?

Thanks, 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

Re: [Discuss-gnuradio] cross correlation in the time domain and through Fourier tranform ?

[jmfriedt]

as a followup to my own post, some simulation with a smaller FFT size
and synthetic data (as opposed to records from the sound card) do yield
the expected behavior of an FFT analyzer used in cross-correlation
mode: jmfriedt.sequanux.org/test_vector.grc generates a
cross-correlation peak every N samples, here with N=256. At 10 kHz,
that makes for a cross correation peak every 25.6 ms.

JM 

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

[Discuss-gnuradio] cross correlation in the time domain and through Fourier tranform ?

[jmfriedt]

I am trying to understand how to use the output of FFT vectors for computation,
rather than just displaying spectra (FFT Sink). I have assembled a pseudo-random
generators (linear feedback shift registers) which output two identical 
pseudo-random
sequences (PRN) when clocked by the sound card output at different rates. This 
all works very 
well. My objective is to demonstrate fine time stamping by cross-correlating 
these two 
streams.

In http://jmfriedt.sequanux.org/xcorr_grc.png, recording the PRN sequence 
(Audio source)
as the two PRNs are generated at slightly different clock frequencies (here 
20.0 and 20.2 kHz)
and multiplying one sequence with the other (ie cross-correlating) generates 
the periodic
cross correlation peaks, all is fine (http://jmfriedt.sequanux.org/xcorr1.png or
http://jmfriedt.sequanux.org/xcorr2.png bottom chart). The frequency offset 
between the two
7-bit long PRN is 200 Hz, so the delay between cross correlation peaks is 127*5 
ms=635 ms
as observed, all is good.

However I'd like to demonstrate the same effect when going through the Fourier 
domain. I convert
the stream to vector (4096 sample long is much more than the about 256-sample 
long PRN), multiply
one vector with the complex conjugate of the other, iFFT the result, making 
sure I don't swap
quadrants (I checked that FFT -> iFFT without swapping creates the same 
original signal), back to stream
and display the result -> same pictures as above, top graphs.
1. is this the correct way of processing Fourier transforms of incoming signals
2. why are the cross-correlation peaks generated in the Fourier domain not 
located at the exact same time
than those generated in the time domain ? I could understand some lag due to 
the low pass filter or 
accumulating the data in the vector, but here I get a bit of jitter of cross 
correlation peaks generated
through the Fourier transform wrt those generated in the time domain.

Obvisouly this should all end up in a passive radar measurement: I can live 
with time-domain 
cross-correlation calculation, but this is the first time I am using the stream 
-> vector 
functionality so I'd like to understand the consequences.

Thanks, JM

-- 
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] RDS decoding

[jmfriedt]

As briefly mentioned at FOSDEM, I have been investigating RDS since last 
christmas, trying to
tackle each issue step by step from LO synchronization for BPSK demodulation, 
bit decoding,
sentence synchronization, station name and free text extraction, error 
correcting code implementation
and finally transferred time analysis. My objective was of course not to 
compete with gr_rds, used
as a reference, but to acquire a detailed understanding of each step. Since I 
protoype with GNU/Octave,
I wanted to convert most digital signal processing from LFSR to linear algebra 
(matrix). I think I 
pretty much understand now the whole process, despite designing the error 
correcting code being still 
beyond my capability. An internal lab presentation on the topic is now 
available at 
http://jmfriedt.free.fr/slides_rds.pdf
and for the French speaking audience, accompanying article (in French at the 
moment, will be translated 
ASAP to English, as soon as I have completed RDS v.s GPS time comparisons) at 
http://jmfriedt.free.fr/lm_rds.pdf

I am well aware of Tom Rondeau's sponsoring Polyphase clock recovery, but at 
the moment I could
only figure out how to use MM-Clock recovery and MPSK, which worked quite well 
for my purpose.

Any feedback welcome,
JM

-- 
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

Re: [Discuss-gnuradio] sound card as complex source ?

[jmfriedt]

anwering my own question ... just found the answer at
http://www.ece.uvic.ca/~elec350/grc_doc/ar01s05s04.html
that the number of outputs defines the number of input channels (I mistakenly
thought they would be duplicates of the same stream).

JM

> Am I missing an option of the audio source block of
> gnuradio-companion for using both channels of the stereo microphone
> input of my sound card ? I'd like to time-stamp, using a GPS 1PPS
> signal, samples recorded from the sound card and use for that purpose
> the second channel of the microphone input, but I cannot figure out
> how to convince gnuradio-companion to provide both channels of the
> sound card (ie provide a complex output rather than a float).
> 
> Thanks, JM
> 


-- 
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] sound card as complex source ?

[jmfriedt]

Am I missing an option of the audio source block of gnuradio-companion for using
both channels of the stereo microphone input of my sound card ? I'd like to 
time-stamp,
using a GPS 1PPS signal, samples recorded from the sound card and use for that 
purpose
the second channel of the microphone input, but I cannot figure out how to 
convince
gnuradio-companion to provide both channels of the sound card (ie provide a 
complex output
rather than a float).

Thanks, JM

-- 
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] gr-osmosdr issues ?

[jmfriedt]

My apologies for such a trivial bug report, but has anyone experienced issues 
with gr-osmosdr
"lately" (not sure when the problem started) about "PLL not locked" and data 
flow rate mismatch
in gnuradio data flows ?

I have a couple dozen RTL2832U based dongles used for various SDR activities 
which have been
working quite flawlessly until this summer at least. Being currently in the 
process of preparing
the new teaching semester, I just discovered that *all* dongles (E4k, R820T or 
R820T2) experience
the same lack of PLL locking and data flow rate mismatch when connected to USB 
ports *on laptops* 
(tested on four different laptop models, yet all running Debian/GNU Linux 
distributions, testing
and sid releases). The audio output in such a simple decoding stream as Osmosdr 
Source - Low pass
filter - WBFM decoder - audio output is not continuous and of very bad quality. 
The *same* dongles 
connected to desktop setups with the same Debian/GNU Linux distribution exhibit 
no issue: stream 
rate is consistent and sound quality excellent. Of course searching on the web 
for "PLL not locked"
yields a couple of million hits explaining that the tuned frequency range is 
not within the
bandwidth of the dongle VCO, which is not the case here.

Has anyone seen reports of this issue before ?

Thanks, JM

-- 
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

Re: [Discuss-gnuradio] GPS Signals recorded IQ samples file

[jmfriedt]

GPS data records and processing scripts for GNU/Octave are available at
http://jmfriedt.free.fr/efts_archive.tar.gz. The tutorial I presented on this
topic during the EFTS seminar is summarized at 
http://jmfriedt.free.fr/sdr_gps_eng.pdf

JM

 You may try this GPS signal simulator to generate IQ samples for testing.
 
 http://github.com/osqzss/gps-sdr-sim
 
 
 
 --
 Wang Kang
 Blog: http://scateu.me
 Fingerprint: 011F 0492 97D6 5D75 8AC4  6458 D43F 3CE2 3353 B7BD
 
 On Wed, 19 Aug 2015, Francisco Albani wrote:
 
  Hi!
 
  After googling a lot and searching in this lists archive, I couldn't find
  any recording of IQ samples from GPS signals.
 
  I'm trying to record one myself, with no luck so far because (I suspect) of
  a malfunctioning active antenna.
 
  Would anybody with the right equipment be so kind to record some minutes of
  4 MHz around 1.57542 GHz and share the recorded iq samples file?
 
  Many thanks in advance!
 
  Francisco.
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


-- 
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

Re: [Discuss-gnuradio] R820T frequency tuning issue

[jmfriedt]

 As briefly mentioned on the #gnuradio IRC mailing list, I am facing an issue 
 with tuning a R820T

  channel

[...]

 I have completed the following experiment:
 * a frequency synthesizer (Rohde  Schwartz SMA100) is set to 1570 MHz, 
 output power of -10 dBm,
 lab-made antenna (ie, dangling wire)
 * R820T DVB-T located next to the synthesizer
 * either running rtl_sdr -f 157000 -n 10 file.bin and plotting the 
 resulting log in GNU/Octave
 (f=fopen('file.bin');d=fread(f,inf,'uchar');plot(abs(fftshift(fft(d) ...
  ^
 d=d(1:2:end)+i*d(2:2:end)

sorry for the mistakes.

JM

-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

[Discuss-gnuradio] fftw3 thread safety ?

[jmfriedt]

I am facing an issue with one of my decoding blocks in which I call
manually FFTW3 (ie *not* going through the gnuradio-fftw3
implementation since I have not (yet) understood how it operates). If I
call a processing chain with a single appearance of my processing
block, all goes fine. If I add a second decoding block (for example for
decoding a second channel), gnuradio crashes after a couple of seconds.
I tracked the issue to the fftw3 thread safety and apparently some
global variable shared by all task planners. Can someone point me to
the way gnuradio solves this thread safety issue (which must be solved
since I can use as many FFT display blocks I want) ? The semaphore
solution is not really satisfactory since I'd like not to ask my block
to wait for all other data processing to be completed before I can
complete its own task.

Thanks, JM

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

Re: [Discuss-gnuradio] New GR Tutorials Posted

[jmfriedt]

I am completing a summary of this summer's experiments including
* decoding weather satellite and the opportunity to introduce
channelized decoding (Frequency Xlating FIR Filter)
* since satellites are not often visible at my latitude, application
to POCSAG which is easier to grab, and most significantly using the 
pipe output to another decoding program as shown on YouTube by A. Csete,
* understanding the processing load of the firdes tap generating
function and comparison of the generated FIR coefficients with those
provided by GNU/Octave (firls function),
* comparison of the sensitivity of the various DVB-T receivers (at the
moment still quite qualitative -- I should find a protocol to quantify
this sensitivity in the lab -- any advice would be welcome).

This is all on the receiver side, no transmission/signal generation
other than simulation using the noise source.

At the moment the draft is still in French (if any French speaking
audience wants to have a quick look: jmfriedt.free.fr/sdr2.pdf). This
is still ongoing work targeted to be completed by beginning of October,
by which time I'll have translated it to English.

JM

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

Re: [Discuss-gnuradio] Beamforming with GNU Radio and USRPs

[jmfriedt]

I am not aware of the details of the GPSDO implementation but your sources must
be phase locked, not only synchronized through the GPS signal. The GPS control 
loop
on the LO only has a finite bandwidth above which each oscillator is free to 
drift
at will. Under such conditions, the interference pattern will be fluctuating 
because
the PLL bandwidth is necessarily much lower than the carrier frequency.

JM

 I am currently trying to get 2 N210 to transmit coherently to a third N210.
 
 All devices have GPSDO kits and the gps_locked status is on locked,
 there is no MIMO cable in the setup.
 
 I am currently doing some preliminary tests where I feed both sinks with
 the same signal i.e a complex sine wave using the signal source from GNU
 Radio and I observe the signal received by the third USRP. I made sure that
 both transmitted signals are received with the same amplitude when taken
 independently.
 
 My understanding is that if both transmitters are locked to the GPS there
 should be no frequency  offset between them and there should only be a
 constant phase offset between them which would give me a somewhat constant
 amplitude signal at the receiver.
 
 On the receiver, I observe the signal with both a time sink and a frequency
 sink.
 My problem is that the received signal seems to be varying a lot in
 amplitude, it looks like a slow AM modulation which is something I would
 get if both transmitters weren't perfectly aligned in frequency.
 
 Changing the frequency of one of the transmitters makes the problem worse.
 
 Does anyone have prior experience with this kind of setup and experienced
 the same issues?
 
 Thanks in advance,
 Jawad


-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

[Discuss-gnuradio] GNURadio on Zynq: radiomodem and fast ADC sources, processing on the PL

[jmfriedt]

I wish to inform the GNURadio community on some of the latest results on the 
use of the Xilinx Zynq platform
for real time radiofrequency signal processing aimed at making the best use of 
the PS/PL architecture.
Let me emphasize that although I am writing this email, all the technical work 
has been achieved by Guillaume Bres-Saix,
in Cc of this email, who has been working full time on this topic since the 
beginning of the year, with the help
of Gwenhael Goavec-Merou (also in Cc) who attended FOSDEM this year with me.

As discussed during the FOSDEM meeting in Brussels last february, we are 
interested in interfacing custom
hardware for radiofrequency signal processing, in which the Zynq platform seems 
most appropriate. The two
targeted hardware interfaces are an RF frontend (Semtech SX1255, operating in 
the 400-500 MHz range, providing
separate frequency sources for the output and input signals), and fast A/D 
converters (mostly for RADAR 
applications). In this context, I believe that sending the datastream to the 
CPU before using the FPGA as
a coprocessor is inefficient, and I consider and architecture made of two 
separate processing blocks, one 
including the data source and fast pre-processing steps using basic functions 
such as decimation, FIR or
auto/cross-correlation to be implemented in the PL, followed by more complex 
processing steps best handled by the 
CPU (PS), in our case WFM demodulation and graphical display (through the 
exported X client). In such an
architeture, only one data transfer occurs between PL and PS, namely the 
pre-processed data leave the
FPGA memory when fetched by the linux kernel before being transfered to 
userspace when the GNURadio source
scheduler requests data. At the moment this data transfer is performed in 
polling mode, although DMA
transfer has been demonstrated in another context.

Guillaume has documented these applications: I believe the most impressive 
result is shown in the video at
http://guillaumebres.wix.com/eportfolio#!zedboard1/c171q and 
https://www.youtube.com/watch?v=P-XzTaRDNxg
In this example, the I/Q stream from the RF frontend is decimated, transfered 
to the GNURadio source and
processed by displaying the Fourier transform of the recorded signal, 
demonstrating that the data
transfer is sound and the data processing is consistent with expectations. The 
modulated signal source
is a sine wave modulating a FM-modulated radiomodem, and the Fourier transform 
indeed exhibits the
sidebands at a frequency offset from the carrier equal to the emitted sine wave 
frequency. The continuity
of the datastream and no loss of data is demonstrated in the second half of the 
video in which an audio
signal modulates the radiomodem, and the WFM demodulation block of GNURadio 
feeding the sound card output
generates a proper *continuous* signal, hence demonstrating that no sample has 
been lost in the transfer process.

The second demonstration of a radiofrequency source made of fast A/D converters 
is presented at
http://guillaumebres.wix.com/eportfolio#!zynqadc/c3pa
and its application to RADAR measurements is illustrated at 
http://guillaumebres.wix.com/eportfolio#!zynqradar/coj3

I believe these are fascinating demonstrations of the flexibility of the Zynq 
based SDR platform with
minimal money investment but huge technical and scientific opportunities with 
the close ties of the PS/PL
architecture. Beyond these technical demonstrations, one issue we are now 
facing is the integration of
the PL in the GNURadio(-companion) framework. I believe the solution is easier 
since I have decided to
keep all the FPGA part in the initial (fast) processing steps and high level 
software processing once
the datastream has been decimated. At the moment, one /dev/ entry is needed for 
each functionality
in the FPGA so a GNURadio-companion block allows for the reconfiguration of the 
associated functionality.
How the gnuradio processing stream is kept consistent with the bitstream 
configuring the FPGA remains
an open question and at the moment the developer must provide this consistency.

All this work must still be properly documented and shared with the community 
with a properly accessible
repository: if interested in getting preliminary access to these source codes 
while all the files
are being organized, let me know by email and we will try to make a usable 
archive.

JM

-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

[Discuss-gnuradio] sound card sampling rate question

[jmfriedt]

I am facing a funny issue: I want to use the sound card for analyzing the 
spectral response
of a quartz tuning fork at 32768 Hz. I just happened to discover that my laptop 
(Panasonic CF-19)
has a sound card able to sample a signal at 192 kHz. I checked with audacity 
(Generate - Tone at
32768 Hz and a frequency counter gives the right output frequency while an 
oscilloscope displays
a clean sine wave).
Now I want to do the same with gnuradio-companion: Signal Source sampled at 192 
kHz, output frequency
at 32768 Hz, directly connected to the audio sink manually set to 192 kHz. To 
make a long story short:
at low frequency (20 kHz output) the output is at the right frequency, so the 
sampling rate is
properly understood. Above 24 kHz I get a clean sine wave output at f-24 kHz, 
so it looks like an
aliasing effect with a sampling frequency of 48 kHz, which is not consistent 
with my first observation.
And setting an output frequency of 24.xx kHz (xx=300 or 400 Hz) generates on 
the oscilloscope a funny
low frequency beat signal which must be related to the antialiasing filters of 
the card.

What I cannot understand is where gnuradio fails to initialize the sound card 
the way audacity does.
Reading the source code, I find in gr-audio/lib/alsa/alsa_sink.cc the following 
intialization

  // sampling rate
  unsigned int orig_sampling_rate = d_sampling_rate;
  if((error = snd_pcm_hw_params_set_rate_near(d_pcm_handle, d_hw_params,
  d_sampling_rate, 0))  0)
bail(failed to set rate near, error);

  if(orig_sampling_rate != d_sampling_rate) {
fprintf(stderr, audio_alsa_sink[%s]: unable to support sampling rate 
%d\n,
snd_pcm_name(d_pcm_handle), orig_sampling_rate);
fprintf(stderr,   card requested %d instead.\n, d_sampling_rate);
  }

which does not seem to test whether the sampling rate is above or below 48 kHz 
(as found in the
pull down menu of the Audio Sink block of gnuradio-companion), and I get no 
error message when
running my application.
Any idea what could be going wrong ?

Thanks, JM

-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

Re: [Discuss-gnuradio] sound card sampling rate question

[jmfriedt]

that was it indeed: selecting out of the aplay -L options the default setup
yields the behaviour I described in my email, while selecting hw as shown in
the output of aplay -L

hw:CARD=PCH,DEV=0
HDA Intel PCH, ALC269VC Analog
Direct hardware device without any conversions

allows me to generate a clean 32768 Hz sine wave.

Thanks, JM

 guessing in the dark: You are likely running a modern linux
 distribution. Many of these tend to emulate an Alsa device, which in
 fact is but an Pulseaudio server, which in turn speaks to the real
 device. They set that as the default audio device in the system.
 Have you tried using the explicit device name (aplay -L) of your
 physical device in the audio sink?
 
 Greetings,
 Marcus
 
 On 25.06.2014 10:40, jmfriedt wrote:
  I am facing a funny issue: I want to use the sound card for analyzing the 
  spectral response
  of a quartz tuning fork at 32768 Hz. I just happened to discover that my 
  laptop (Panasonic CF-19)
  has a sound card able to sample a signal at 192 kHz. I checked with 
  audacity (Generate - Tone at
  32768 Hz and a frequency counter gives the right output frequency while an 
  oscilloscope displays
  a clean sine wave).
  Now I want to do the same with gnuradio-companion: Signal Source sampled at 
  192 kHz, output frequency
  at 32768 Hz, directly connected to the audio sink manually set to 192 kHz. 
  To make a long story short:
  at low frequency (20 kHz output) the output is at the right frequency, so 
  the sampling rate is
  properly understood. Above 24 kHz I get a clean sine wave output at f-24 
  kHz, so it looks like an
  aliasing effect with a sampling frequency of 48 kHz, which is not 
  consistent with my first observation.
  And setting an output frequency of 24.xx kHz (xx=300 or 400 Hz) generates 
  on the oscilloscope a funny
  low frequency beat signal which must be related to the antialiasing filters 
  of the card.
 
  What I cannot understand is where gnuradio fails to initialize the sound 
  card the way audacity does.
  Reading the source code, I find in gr-audio/lib/alsa/alsa_sink.cc the 
  following intialization
 
// sampling rate
unsigned int orig_sampling_rate = d_sampling_rate;
if((error = snd_pcm_hw_params_set_rate_near(d_pcm_handle, d_hw_params,
d_sampling_rate, 0))  0)
  bail(failed to set rate near, error);
 
if(orig_sampling_rate != d_sampling_rate) {
  fprintf(stderr, audio_alsa_sink[%s]: unable to support sampling 
  rate %d\n,
  snd_pcm_name(d_pcm_handle), orig_sampling_rate);
  fprintf(stderr,   card requested %d instead.\n, d_sampling_rate);
}
 
  which does not seem to test whether the sampling rate is above or below 48 
  kHz (as found in the
  pull down menu of the Audio Sink block of gnuradio-companion), and I get no 
  error message when
  running my application.
  Any idea what could be going wrong ?
 
  Thanks, JM
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

Re: [Discuss-gnuradio] Google Summer of Code: We're in!

[jmfriedt]

most enthusiastic about this development: I was disappointed not to get the 
current 
http://www.gnss-sdr.org/documentation/gnss-sdr-operation-realtek-rtl2832u-usb-dongle-dvb-t-receiver
running on my dongle and am really looking forward to some demo on this topic.

JM


 Congratulations for the acceptance in GSoC! I'm happy to announce that
 GNSS-SDR (an open source GNSS receiver based on GNU Radio) has been also
 accepted as well as a mentoring organization this year:
 http://www.google-melange.com/gsoc/org/google/gsoc2013/gnss_sdr
 
 Students: get ready to have fun this summer! :-)
 
 Best regards,
 Carles
 
 
 
 
 On Tue, Apr 9, 2013 at 2:15 AM, Tom Rondeau t...@trondeau.com wrote:
 
  Nice work, Martin.
 
  Tom
 
 
 
  On Mon, Apr 8, 2013 at 5:36 PM, Martin Braun (CEL) martin.br...@kit.edu
  wrote:
   Hi everyone!
  
   I'm happy to say we've been accepted for GSoC 2013!
  
   Our GSoC page is up and running at
   http://www.google-melange.com/gsoc/org/google/gsoc2013/gnuradio.
  
   We'll be adding details soon. Students, how about making some $$$
   writing code for the community? Check out our ideas page.
  
   Cheerio,
   MB
   --
   Karlsruhe Institute of Technology (KIT)
   Communications Engineering Lab (CEL)
  
   Dipl.-Ing. Martin Braun
   Research Associate
  
   Kaiserstraße 12
   Building 05.01
   76131 Karlsruhe
  
   Phone: +49 721 608-43790
   Fax: +49 721 608-46071
   www.cel.kit.edu
  
   KIT -- University of the State of Baden-Württemberg and
   National Laboratory of the Helmholtz Association
  
   ___
   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
 


-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

[Discuss-gnuradio] FM demodulation block performance ?

[jmfriedt]

I am still trying to receive NOAA APT signals using the RTL-SDR DVB dongle. 
What I did
so far:
1/ using a wideband discone antenna, I receive the NOAA APT characteristic 
signal during passes
on a AOR3000 scanner. I know the NFM mode of the AOR3000 is too narrow for full 
decoding of the
image (saturated whites), but at least I know my antenna is good enough to 
recover an audible and
usable signal,
2/ on the antenna I put a splitter (Minicircuits ZFDC-10-5) with 10 dB loss on 
the coupled output
(to the AOR3000) and 1.5 dB loss on the direct path (to the DVB receiver).
3/ I use http://picasaweb.google.com/lh/photo/2QDS5vwPra5Q7yQbSdUOng as an 
example of NBFM receiver
usage (extending the demodulation bandwidth to 30 kHz instead of the 5 kHz in 
the example), or I 
try a WBFM receiver module with a 30 to 40 kHz bandwidth, both of which were 
preceded by a 100-kHz
low-pass filter (either as in the screenshot using the FIR coefficients in a 
Xlating block,
or using the LPF block)

In all cases I get a clear signal on the AOR scanner (even after the 10 dB loss 
on the coupler) while
I cannot recover any usable signal on the DVB receiver, with RF gains in the 33 
to 39 dB range and
IF gains in the 25 to 40 dB range. A friend of mine got usable signals using 
the NFM demodulator from
SDRSharp (which I have not yet managed to get running) with the DVB dongle.

Any idea whether the FM demodulation blocks require some minimum signal to 
noise ratio to lock ?
more generally is there any other description/documentation on the blocks other 
than the doxygen
generated information and source codes ?

Thank you, Jean-Michel

-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

[Discuss-gnuradio] ohm2013 ?

[jmfriedt]

Is anyone planning on attending the OHM2013 conference 
(https://ohm2013.org/site/) in the 
nederlands this summer ? I'd like to submit a talk about GNURadio/rtl-sdr and 
signal processing
prototyping using this tool/sound card (oriented towards digital mode reception 
and time  frequency
characterization of oscillators since it is more related to by job), but  would 
rather not compete 
with available sessions with a more competent speaker.

JM

-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

[Discuss-gnuradio] GNURadio bloc design tutorial

[jmfriedt]

For what it is worth, some might (or might not) be interested in the 
tutorial document I wrote concerning the implementation of some decoding blocs
for GNURadio, from signal processing prototyping using GNU/Octave on recorded 
signals
to the actual bloc http://jmfriedt.free.fr/en_sdr.pdf

For the French speaking audience, this document is a translation to English of 
the 
article in French published in GNU/Linux Magazine France available at 
http://jmfriedt.free.fr/lm_sdr.pdf, translation performed following some 
requests
received after the Physics for Development Conference 
(http://www.epsphysicsfordevelopment.org/) 
held last October in Brussels (Belgium). As an extension of this document, I am 
currently
completing an extension towards the implementation of some time and frequency 
analysis 
algorithms targetted at using GNURadio and the sound card interface as signal
generator and acquisition (network analyzer application, frequency counter, 
phase measurement)
for teaching and hobby applications.

Any comment or correction is welcome, these documents are not aimed at being 
static but to
evolve depending on the feedback I might receive.

JM

-- 
JM Friedt, FEMTO-ST Time  Frequency/SENSeOR, 32 av. observatoire,
25044 Besancon, France

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