Re: Gnuradio 3.8 on embedded [ARM] systems

[jean-michel . friedt]

>> https://github.com/oscimp/PlutoSDR/blob/master/doc/gnuradio_on_RPi.pdf
> 
> That link didn't work for me;
> https://raw.githubusercontent.com/oscimp/PlutoSDR/master/doc/gnuradio_on_RPi_English.pdf
> does.

Indeed apologies for changing the tree structure: we decided to split
our local Buildroot BR2_EXTERNAL package repository from the PluotSDR
dedicated repository. The BR2_EXTERNAL is now at
https://github.com/oscimp/oscimp_br2_external which includes all the
Buildroot packages (including White Rabbit support for the Compute
Module 4, XTRX SDR running with the CM4 or rpitx libraries) and the
documentation is hence
https://github.com/oscimp/oscimp_br2_external/tree/master/doc

Unfortunately
https://github.com/oscimp/PlutoSDR/blob/master/doc/gnuradio_on_RPi_English.pdf
is still in PlutoSDR and should be moved as well.

As you mention, the investment in becoming familiar with BR extends
well beyond the RPi and will be valuable to most embedded boards.

Best, JM

Re: [Discuss-gnuradio] "gnuradio challenges" (for learning GNU Radio)

[Jean-Michel FRIEDT]

if there can be any interest, I try to gradually go from basics (using
GNU Radio to introduce such topics as decimating, aliasing and the need
for low pass filtering) to more applied topics (of course FM radio  
demodulation,

then POCSAG) and BPSK demodulation (Costas loop) and finally multichannel
analysis (Xlating FIR) in my lab sessions at
http://jmfriedt.free.fr/tp_sdr_eng.pdf
(or for the French speaking part of Belgium,  
http://jmfriedt.free.fr/tp_sdr.pdf)


More challenging signal demodulations such as GPS and RDS are discussed
separately (eg http://jmfriedt.free.fr/lm_rds_eng.pdf &
http://jmfriedt.free.fr/sdr_gps_eng.pdf)

JM


Hi all,


After the GNU Radio workshop at hsbxl two weeks ago, a number of  
people of the Belgian amateur-radio community who where at the  
workshop have shown interest in continuing to learn more about GNU  
Radio.


However, one of the main issues we have noticed that we kind-of lack  
a good "application" to use GNU Radio for, and -as we all known- you  
only learn something by using it.



So, based on the idea used in cybersecurity training, I would like  
to see if it not possible to create a number of "GNU Radio  
challenges", either decoding radio-signals or creating an encoder  
that produces a desired signal.



I know Ben Hilburn created the challenge (found on the GNU Radio  
website) but that one is way above what most people are able to  
decode (let alone people just starting out with GNU Radio).
Again, looking at the cybersecurity-scene: If you look at a website  
like "root me" (https://www.root-me.org/?lang=en), it provides a  
number of challenges with an increasing degree of difficulty, which  
allow people to build up their skills step by step. And -as I see  
it- this "step by step" approach is the most important element in a  
educational project.


So, does anybody know if there are, or is anybody interested to help  
create, more GNU Radio challenges that can be used for an  
educational purpose, to provide people with a "learning path" to  
really start to learn and use GNU Radio?


Are there people who use GNU Radio as part of teaching  
radio-communication? What topics do you teach and in what order? How  
do you get the students to understand radio-communication and GNU  
Radio?


Cheerio! Kr. Bonne.



___
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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] European GNU Radio Days conference: call for contribution & registration deadline

[Jean-Michel FRIEDT]

The European GNU Radio Days is a conference organized in Besancon (France)
June 17th & 18th (2019) aimed at fostering interaction between users and
developers of the GNU Radio digital signal processing framework.

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,
including a practical presentation of software defined radio and discrete time
digital  signal processing centered on the PlutoSDR by Analog Devices.

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

Web site of the conference: https://gnuradio-fr-19.sciencesconf.org/

I will be attending the FOSDEM Free Software Radio devroom: for those coming
to Brussels, feel free to reach me for further information.

Hoping to see many of you during the summer in Besancon (with a hopefully
fine weather for the first day's evening BBQ)
Jean-Michel, for the GNURadio Day's organization committee

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





This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] GRCon2017 program and presentations ?

[Jean-Michel FRIEDT]

I had bookmarked www.gnuradio.org/grcon-2017/program/grcon17-presentations for
accessing the GNURadio conference 2017 program and I believe slides of  
the presentations.
This page is gone, and I cannot find an alternative: is there a place  
where these documents might

still be found ?

Thanks, JM


This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] gr-fec Viterbi example

[Jean-Michel FRIEDT]

I tried building this program on Windows and failed. Since it's
missing in viterbi/CmakeLists.txt, I fail to see it's built by
default. How did you compile it? Are you sure it wasn't written
on a big-endian machine?


under GNU/Linux
g++ -c encode.cc
gcc -c viterbi.c
gcc -c tab.c
gcc -c metrics.c
gcc -o encode encode.o viterbi.o tab.o metrics.o -lm
g++ -c decode.cc
gcc -o decode decode.o viterbi.o tab.o metrics.o -lm
compiles flawlessly.
I then
$ echo "123400" | ./encode  > t
$ cat t | ./decode

that used to work nicely with the original code (it did not comply with
my understanding of Viterbi encoding, which has since improved a bit since I
can decode full sentences of Meteor M2 so I must not be completely wrong) but
after swapping POLYA and POLYB the above demonstration (encoding followed
by decoding) no longer works. I am afraid I broke the assumption given in
the comments

 * The code polynomials are assumed to have 1's on both ends. Given a
 * function encode_state() that returns the two symbols for a given
 * encoder state in the low two bits, such a code will have the following
 * identities for even 'n' < 64:

Thanks, JM


On Windows at least, the viterbi.h + decode.cc + encode.cc are
not up-to-date. Missing proper dllexport, setmode(fd,O_BINARY)
etc. etc.

Anyway, with some patching I was able to link and run them.
But I have no data to test the Viterbi encoder/decoder with.
Could you please ship some files to me?


I am unable to encode the sync word 0x1ACFFC1D to the expected result
0xfc 0xa2 0xb6 0x3d 0xb0 0x0d 0x97 0x94 as explained at
https://www.teske.net.br/lucas/2016/11/goes-satellite-hunt-part-3-frame-decoder/
I know this encoded sync word is correct because cross-correlating the
METEOR stream (after proper constellation rotation) with this word gives
a correlation peak every 16384 samples (=1024 byte sentence * 8  
bits/byte * 2

bits/Viterbi encoder).

I am doing (word.bin was generated with Octave's fwrite function)
$ xxd word.bin
: 1acf fc1d    ..
and then
$ cat word.bin | ./viterbi/encode > t.bin
but
$ xxd t.bin
:    0101 0001 0001 0101 0001  
0010: 0001  0100 0001 0101   0100  
0020: 0001  0101 0101 0101 0101  0100  
0030: 0001 0100 0100  0001 0100 0100 0101  
0040:  0001 0001 0101 0001 0101    
does not match the expected bit sequence which should be
word=[1 1 1 1 1 1 0 0 ... %  fc
  1 0 1 0 0 0 1 0 ... %  a2
  1 0 1 1 0 1 1 0 ... %  b6
  0 0 1 1 1 1 0 1 ... %  3d
  1 0 1 1 0 0 0 0 ... %  b0
  0 0 0 0 1 1 0 1 ... %  0d
  1 0 0 1 0 1 1 1 ... %  97
  1 0 0 1 0 1 0 0 ... %  94


I had no lock with 'xxd -revert' to check your results here
I used the attached hex2bin.c instead.

And BTW, my patches also attached.

--
--gv







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



This message was sent using IMP, the Internet Messaging Program.

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

Re: [Discuss-gnuradio] gr-fec Viterbi example

[Jean-Michel FRIEDT]

#define POLYA   0x6d
#define POLYB   0x4f


If I modify viterbi.c in gr-fec/viterbi (swapping the polynomial coefficients)
#define POLYB   0x6d
#define POLYA   0x4f
then
$ xxd word.bin
: 1acf fc1d    
and
$ cat word.bin | ./encode > t
then t is
 0011 0101 1101 0100 1001 1100 0010 0100   0010 0110 1000 0110
  035D49C24FF2686...
=-0xfca2b63db00d9794
so while I am not sure I understand why ones and zeros are swapped using this
encoding, it does seem to me that the two polynomial coefficients of the
LRPT code are swapped in this example.

JM


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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] gr-fec Viterbi example

[Jean-Michel FRIEDT]

I am currently investigating LRPT (as used by METEOR-M2) and am
stuck with the Viterbi decoder. While trying to use
https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/viterbi/decode.cc
which implements

/* The two generator polynomials for the NASA Standard K=7 code.
 * Since these polynomials are known to be optimal for this constraint
 * length there is not much point in changing them. But if you do, you
 * will have to regenerate the BUTTERFLY macro calls in viterbi()
 */
#define POLYA   0x6d
#define POLYB   0x4f

I am unable to encode the sync word 0x1ACFFC1D to the expected result
0xfc 0xa2 0xb6 0x3d 0xb0 0x0d 0x97 0x94 as explained at
https://www.teske.net.br/lucas/2016/11/goes-satellite-hunt-part-3-frame-decoder/
I know this encoded sync word is correct because cross-correlating the
METEOR stream (after proper constellation rotation) with this word gives
a correlation peak every 16384 samples (=1024 byte sentence * 8 bits/byte * 2
bits/Viterbi encoder).

I am doing (word.bin was generated with Octave's fwrite function)
$ xxd word.bin
: 1acf fc1d    ..
and then
$ cat word.bin | ./viterbi/encode > t.bin
but
$ xxd t.bin
:    0101 0001 0001 0101 0001  
0010: 0001  0100 0001 0101   0100  
0020: 0001  0101 0101 0101 0101  0100  
0030: 0001 0100 0100  0001 0100 0100 0101  
0040:  0001 0001 0101 0001 0101    
does not match the expected bit sequence which should be
word=[1 1 1 1 1 1 0 0 ... %  fc
  1 0 1 0 0 0 1 0 ... %  a2
  1 0 1 1 0 1 1 0 ... %  b6
  0 0 1 1 1 1 0 1 ... %  3d
  1 0 1 1 0 0 0 0 ... %  b0
  0 0 0 0 1 1 0 1 ... %  0d
  1 0 0 1 0 1 1 1 ... %  97
  1 0 0 1 0 1 0 0 ... %  94
If I encode a random word with the Viterbi encoder and then decode it, the
result is correct, so the implementation of Viterbi seems correct. I was
first thinking the polyomial coefficients might have been swapped but seems
not to be the case. Any idea what might be wrong ?

Thanks, JM

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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] sound card output issue

[Jean-Michel FRIEDT]

Indeed I have since checked any source of crosstalk and removed all links from
source to audio sink but the one going to input number 3 and still the same
issue is observed. However remplacing 9 Hz output (at 192000 Hz sampling
rate) with 9.1 Hz solves the issue of the unexpected shape at the output
of the sound card. It seems to me we have a strange relation when incrementing
the NCO phase, but I fail to identify the cause of the problem, and why
moving the frequency as the flowgraph is running solves the output shape.
I thought that incrementing and decrementing the frequency defined as a
floating point number might lead me to a value slightly different from  
90.0 kHz,

but at least printf displays exacly 90 kHz.

The sound card is indeed nice for VLF. The documentation claims
(https://uk.focusrite.com/usb-audio-interfaces/scarlett-18i8/specifications)
103 dBFS or 17 useful bits. From eastern France I collect TDF, DCF (and time
the signals with respect to GPS 1 PPS) but the British eLORAN station is too
far. I have not (yet) tried MSF.

JM


I see a lot of inputs to the sound card sink in the flowgraph.. could the
signal be getting mixed with itself among the many inputs to the card and
causing new frequency components as it gets mixed? Can you try sending the
flow graph signal to just one sink input at a time (perhaps using a
constant source on the others if needed) to try and rule out this
possibility?

Also this looks like a good card for vlf, hows the noise floor?



[Sent from mobile device]

On Thu, Jul 19, 2018, 4:49 AM Jean-Michel FRIEDT <
jean-michel.fri...@femto-st.fr> wrote:


I have a funny problem with the output of a sound card fed from a signal
source.
The hardware setup is a Scarlett 18i8 sound card sampled at 192 kHz (for
VLF
   signal analysis) with the signal generated from the front output number
1
   (channel number 3 in the GNURadio audio sink).
The sound card is controlled from ALSA.
   gr::log :INFO: audio source - Audio sink arch: alsa
The minimalistic flowgraph to reproduce the problem is at
   jmfriedt.org/untitled_grc.png
When first launched with an output frequency set to 90 kHz, the sound card
output looks like jmfriedt.org/snd1.png, ie with some spectral component
around 6 kHz whose origin I am unable to identify. If, using the slider, I
change the frequency and set it back to its original value of 90 kHz, I get
the fine output of jmfriedt.org/snd2.png which looks as good as I can
expect from an output frequency so close to the Nyquist frequency.

Since I want to automate data acquisition over a long duration (ie launch
the python script, collect a few seconds of data, kill the script and
launch
it again a few minutes later, and repeat for a few months or years) the
option
of manually setting the frequency is not acceptable. I cannot think of a
way
to start debugging the problem, whether on ALSA source or the signal
generator
side. Both seem reasonable

Any hint at which block could be the cause of the issue (there's only
two of them left in the minimalistic GRC graph !). I've read both source
codes and cannot see the difference between the initialization and the
callback function when changing the frequency.

Thanks, JM

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


This message was sent using IMP, the Internet Messaging Program.


___
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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] sound card output issue

[Jean-Michel FRIEDT]

I have a funny problem with the output of a sound card fed from a signal
source.
The hardware setup is a Scarlett 18i8 sound card sampled at 192 kHz (for VLF
  signal analysis) with the signal generated from the front output number 1
  (channel number 3 in the GNURadio audio sink).
The sound card is controlled from ALSA.
  gr::log :INFO: audio source - Audio sink arch: alsa
The minimalistic flowgraph to reproduce the problem is at
  jmfriedt.org/untitled_grc.png
When first launched with an output frequency set to 90 kHz, the sound card
output looks like jmfriedt.org/snd1.png, ie with some spectral component
around 6 kHz whose origin I am unable to identify. If, using the slider, I
change the frequency and set it back to its original value of 90 kHz, I get
the fine output of jmfriedt.org/snd2.png which looks as good as I can
expect from an output frequency so close to the Nyquist frequency.

Since I want to automate data acquisition over a long duration (ie launch
the python script, collect a few seconds of data, kill the script and launch
it again a few minutes later, and repeat for a few months or years) the option
of manually setting the frequency is not acceptable. I cannot think of a way
to start debugging the problem, whether on ALSA source or the signal generator
side. Both seem reasonable

Any hint at which block could be the cause of the issue (there's only
two of them left in the minimalistic GRC graph !). I've read both source
codes and cannot see the difference between the initialization and the
callback function when changing the frequency.

Thanks, JM

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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] Changing delay block value over time

[Jean-Michel FRIEDT]

possibly an ugly hack, but I use the Function Probe plugged to a Signal
Source to tune the variable delay between two signals. An example is at
http://jmfriedt.sequanux.org/xcorrdemo.grc.

JM


I'd recommend that, yes :) But then again, the delay block you're
referring to only allows for full samples in delay; maybe you much
rather want an adjustable interpolator? What is the purpose of all this
(kind of a recurring theme, me asking *why* people want to do
something, so that we can help them)?

Best regards,
Marcus

On Thu, 2018-05-24 at 10:00 +, Yeo Jin Kuang Alvin (IA) wrote:

Hi all,

Is there a way to implement control of delays over time? Type out own code?

Thank you in advanced!

-Original Message-
From: Müller, Marcus (CEL) [mailto:muel...@kit.edu]
Sent: Thursday, 24 May 2018 5:58 PM
To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Changing delay block value over time

No.

Best regards,
Marcus
On Thu, 2018-05-24 at 09:22 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi all,
>
> Am I able to change the value of the delay block automatically in  
GRC over time when the flowgraph is running?

>
> Thank you in advanced!
> ___
> 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



This message was sent using IMP, the Internet Messaging Program.

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

Re: [Discuss-gnuradio] VCO

[Jean-Michel FRIEDT]

I would like to ask about the VCO in GRC. What's the function of the  
sensitivity? If I connect a signal source (Saw Tooth) into VCO, and  
I want a bandwidth of 2MHz. I only can achieve it by setting the  
Sentivity = 2e6 *(2*3.1416) . Can anyone explain the theory behind  
this?


may the source be with you:
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/vco_c_impl.cc

The VCO block generates a sincos output at a rate of  
sensitivity/sampling_rate,

so that the phase increments by 2pi (one cycle rotation) every
sampling_rate/sensitivity samples. This is also what is given in
http://www.ece.uvic.ca/~elec350/grc_doc/ar01s02s05.html stating that the
sensitivity is in rad/sec*V.

JM

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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] VCO

[Jean-Michel FRIEDT]

I would like to ask about the VCO in GRC. What's the function of the  
sensitivity? If I connect a signal source (Saw Tooth) into VCO, and  
I want a bandwidth of 2MHz. I only can achieve it by setting the  
Sentivity = 2e6 *(2*3.1416) . Can anyone explain the theory behind  
this?


may the source be with you:
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/vco_c_impl.cc

The VCO block generates a sincos output at a rate of  
sensitivity/sampling_rate,

so that the phase increments by 2pi (one cycle rotation) every
sampling_rate/sensitivity samples. This is also what is given in
http://www.ece.uvic.ca/~elec350/grc_doc/ar01s02s05.html stating that the
sensitivity is in rad/sec*V.

JM

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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] reminder: French GNURadio days -- deadline approaching

[Jean-Michel FRIEDT]

A quick reminder, for those interested to meet to discuss the latest
developments related to GNURadio in France and Europe, that the deadline
for submission and registration for the French GNURadio days is approaching
(May 20).
The web site with the program, template and registration is at
https://gnuradio-fr-18.sciencesconf.org/

Jean-Michel

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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] Fwd: RTL-SDR for GPS/Galileo signal reception

[Jean-Michel FRIEDT]

at least your fc in the Matlab script is incorrect: removing the
carrier frequency has been taken care of by the RF frontend (R820T2).
You are only left with the offset between the GPS carrier and the frontend
carrier + Doppler shift. Doppler is in the +/5 kHz range, but offset can
be up to +/-100 kHz for the cheap DVB-T dongles, so squaring the signal
(also done in one possible implementation of the Costas loop) will give
you a rough estimate of the offset to which the Doppler is added
by sweeping fc with typically 100 to 500 steps.

JM


Thanks for the useful info but I am stuck after trying all the
possibilities which I could possibly understand from the internet. Here is
what I am doing:

I am taking signal of 1ms from RTL-SDR using GNURadio Companion at
Samp_rate 2.048M, and the flow graph is attached. after receiving the data
(I and Q complex samples) the shape of the signal is shown in the figure
attached.

Since it is the complex IQ data, so for demodulation I used complex
exponential function (exp(j*2*pi*fc*ts)). And after that I am doing the
acquisition using 'Parallel Code Phase Search Acquisition' algorithm. But I
am not getting the required result, instead I am getting some random peaks
of correlation (very low amplitude) for every satellite PRN's. I am also
attaching the MATLAB code for acquisition and example plot for one PRN.

Even after reading so many articles online, I couldn't find the solution
for that. I am not getting that what mistake am I doing in this whole
process of acquisition?

One problem that according to my understanding is that, may be the signal I
am getting is very weak, or it's just Noise. because I have tried all the
possible solutions, but couldn't find the good correlation peak for any
satellite.

And I am also getting two type of complex data from RTL-SDR, when I just
plug-in my dongle, I am getting a complex signal of random amplitude, but
when I take the data after some time then I am getting the data of constant
amplitude. I don't know which of them is correct, so I tried processing
both of them but results are same.

Any help would be highly appreciated.

Thank you
Priyanka



On Thu, Apr 19, 2018 at 8:14 AM, Jean-Michel FRIEDT <
jean-michel.fri...@femto-st.fr> wrote:


I am collecting from the RTL-SDR dongle has amplitude in range

of 0.04(peak to peak). Can we be sure of having GPS signal it and is such
low strength of signal okay for GPS acquisition or not?



that's the beauty of spectrum spreading and pulse compression: despite
the signal being below thermal noise level, pulse compression by 1024-fold
(1.024 Mb/s and 1 ms code repetition rate) will increase signal to noise
ratio by 10 bits. So even a single-bit A/D converter (comparator) is enough
to collect GPS data. You cannot see GPS unless you compress the pulse
(either
by squaring the signal to get rid of BPSK, or correlating with the local
copy of the Doppler shifted PRN).

JM


--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Ep
<https://maps.google.com/?q=SeOR,+26+rue+de+l'Ep=gmail=g>itaphe,
25000 Besancon, France


This message was sent using IMP, the Internet Messaging Program.








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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] Fwd: RTL-SDR for GPS/Galileo signal reception

[Jean-Michel FRIEDT]

I am collecting from the RTL-SDR dongle has amplitude in range
of 0.04(peak to peak). Can we be sure of having GPS signal it and is such
low strength of signal okay for GPS acquisition or not?


that's the beauty of spectrum spreading and pulse compression: despite
the signal being below thermal noise level, pulse compression by 1024-fold
(1.024 Mb/s and 1 ms code repetition rate) will increase signal to noise
ratio by 10 bits. So even a single-bit A/D converter (comparator) is enough
to collect GPS data. You cannot see GPS unless you compress the pulse (either
by squaring the signal to get rid of BPSK, or correlating with the local
copy of the Doppler shifted PRN).

JM

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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] Fwd: RTL-SDR for GPS/Galileo signal reception

[Jean-Michel FRIEDT]

If you want to make sure that your collected data include GPS signals, get
rid of the BPSK modulation by squaring the complex signal, see
http://jmfriedt.free.fr/trans_num_l3_1_eng.pdf
slides 37-38.

I tried to do my best to describe the demodulation process in
http://jmfriedt.free.fr/sdr_gps_eng.pdf

JM


I want to acquire first the GPS L1 signal to get a basic idea of how
acquisition works and then move to Galileo E1 signal, but I am facing some
problems.

1. I am using RTL-SDR Dongle, with Rafael R820T Tuner, and I want to
acquire GPS L1 signal with that.

2. I am using GNURadio to receive the data. In GNURadio, in the RTL-SDR
Block, I am giving my sample rate of 2.048 Msps.

3. Incoming L1 signal has frequency of 1575.42 MHz and I am using GPS
active antenna with 40 db gain.

4. In RTL-SDR dongle, it will be down-converted to IF (that is unknown to
me), through local oscillator. and after the down-conversion, it will be
passed to ADC.

5. In some articles, I have studied that RTL-SDR dongle that I am using has
IF= (3.57 MHz or 4.57 MHz). (*http://superkuh.com/rtlsdr.html
)*

6. Now my question is that if it is true, then the signal going into the
ADC has frequency of (3.57 MHz or 4.57 MHz) , and my sample rate is 2.048
Msps, that is below the frequency of the incoming signal, then it is not
following the Nyquist Criterion. Also, according to this, the incoming
signal must be at (3.57 MHz-2.048 MHz= 1.652 MHz). Is it Right? (screenshot
attached for reference)

7.The samples coming out of RTL-SDR are complex (I & Q). In one articles I
have studied that the I-part are the C/A codes and the Q-part are P-Codes
and these samples are at Baseband(zero-frequency).  If I just want to
acquire C/A code, then shall I need to just take I-part of the output
samples coming out of the RTL-SDR? Or what should be my data on which I
need to do the further DSP?

These are my problems till now. I have studied dozens of web-pages and
articles, but couldn't find the fruitful answer. I shall be very thankful
for any help.

Thanks a lot for your time.

Regards,
Priyanka





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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] Announcement: French GNU Radio days, July 2-3 2018

[Jean-Michel FRIEDT]

Call for contribution: First French GNU Radio days
--

It is our pleasure to announce the first meeting centered around the GNU Radio
framework held in France (Lyon). This workshop targets French and European
GNU Radio users and developers. Contributions are sought in French or
(preferably) English. The workshop will take place on the 2nd and 3rd of July,
2018, at INSA Lyon (France).

GNU Radio is an increasingly popular framework for Software Defined Radio
components and Digital Signal Processing prototyping. As such our goals are as
follows:

- Bring together active French and European GNU Radio users, coming from a
scientific, technical, amateur or hacker background
- Foster interaction between GNU Radio users
- Share knowledge about GNU Radio development through tutorials, seminars and
demos
- Bridge the gap between technical/engineering and scientific/research points
of view on topics related to applied research with GNU Radio. Such topics
include:
   - Software Defined Radio, radio prototyping,
   - RF design,
   - RADAR design
   - Signal processing in embedded systems,
   - GNU Radio development environment,
   - New platforms

Contributions might for instance address the following topics (but not limited
to):
   - 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 GNURadio to Soc FPGA
   - Various physical measurements (GNSS, Radioastronomy)
   - ... Your own favorite field here


GNU Radio users and developers are invited to present their experiments and
activities. The first day (2nd of July) will be devoted to oral presentations,
posters and demonstrations. The second day (3rd of July) will be dedicated to
tutorials and hands-on sessions.

Contributions will be selected according to:
   - Originality
   - Quality of the experimental process
   - Reproducibility of the experiments and learning potential for other users
   - A live demonstration or video is highly appreciated

Submissions of contributions:
   - One to two page extended abstract (PDF format), describing the
contribution itself and the desired presentation format (oral, poster and/or
demo) following this template.
   - Deadline: May 20
   - Submission via the website: https://gnuradio-fr-18.sciencesconf.org/

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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] gr-paint and FM capture: review request

[Jean-Michel FRIEDT]

I have just completed a text summarizing my latest investigation on
painting on the radiofrequency spectrum (i.e. gr-paint) and the
impact of the FM capture effect from a nearby interfering signal, including
the justification of using AM modulation in aeronautical communications. Since
these are rather new topics for me, I am seeking review/corrections
of this text, available at

http://jmfriedt.free.fr/lm_fmcapture_eng.pdf

Any comments/corrections welcome.

Thank you, Jean-Michel

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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] Getting signal from a LEO Satellite? ( Doppler shift handling)

[Jean-Michel FRIEDT]

costas will do the job as long as your measurement bandwidth includes
twice the expected frequency offset, see http://jmfriedt.free.fr/efts_gps.pdf
slide 13.

JM


I am planning to track a signal from a LEO Satellite which transmits
approx. 100 kbps BPSK.
I wonder which blocks should I use since the carrier offset ranges are:
around -50 kHz (beginning of the pass)
around +50 kHz (at the endof the pass)

Possible blocks are:

PLL Carrier Tracking
Costas Loop (using the frequency output port to get the carrier freq. error)

Any other suggestions- Examples?

Please don't offer manually shifting the frequency.(Using Gpredict)





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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] FFT normalization issue: noise aliasing

[Jean-Michel FRIEDT]

PS: the fact that reducing by 10 the number of samples in the FFT rises the
noise level by 10 dB definitely hints at dB/Hz rather than dB as Y-axis unit.

JM


This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] FFT normalization issue: noise aliasing

[Jean-Michel FRIEDT]

Shouldn't my aliasing experiment raise the noise floor rather than keep it
constant ?


By taking only every 10th sample, you also reduce the sample rate
by a factor of 10. So you have the same power in 1/10th of the
original bandwidth. In other words, noise power per Hz has
increased by a factor of 10. This noise density (compared to
signal power) is what matters in e.g. demodulation.


which brings me back to my question indeed: is the FFT sink displaying
dB or dB/Hz (or dB/sqrt(Hz) for voltages) ? In the latter case I agree
with your statement.

Marcus: I see that I will have no other choice than to start learning the
Qt interface ... I was so used to the WX one that I never bothered. I just
checked, the result is the same on both GUI so they are consistent.

Thanks, JM

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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] FFT normalization issue: noise aliasing

[Jean-Michel FRIEDT]

I want to demonstrate how aliasing rises the noise level upon decimation.
I have a trivial flow graph with a noise source, whose bandpass I  
limit to make

sure I know its spectral characteristics, and I compare the spectral power
with and without decimation. The decimation FIR is 1 so I believe no filtering
should be performed. I expect the noise level to rise 10-fold upon a  
decimation

by 10 through aliasing. That does not happen: the spectral density remains the
same, with and without decimation.
http://jmfriedt.sequanux.org/aliasing_noise_png.png for the flowchart, and
http://jmfriedt.sequanux.org/noise1.png for the spectra.
Is this the expected behavior ? I do not expect to be so, and I wonder if the
normalization coefficient is correct.
GNU/Octave does not help me much on the issue: generating a random sequence
and comparing the fft of the sequence or fft of one in every 10 sample *drops*
the level 10 fold, as summarised in jmfriedt.sequanux.org/aliasing_octave.pdf.

Of course we all want ifft(fft(signal)) to be equal to signal, but I have seen
all sorts of normalization (1/N on the FFT and none on iFFT, 1/N on iFFT and
none on FFT, 1/sqrt(N) on both FFT and iFFT with N the number of samples on
which the FFT is computed).
Shouldn't my aliasing experiment raise the noise floor rather than keep it
constant ?

Thanks, JM


This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] RDS decoding

[jean-michel . friedt]

I have just completed the translation to English of my description of
RDS decoding. It is now available at 

http://jmfriedt.free.fr/lm_rds_eng.pdf

Corrections welcome, both on the content (not familiar enough with error
correcting codes and bitrate synchronization to be sure I did't make
mistakes in describing my experiments) and the spelling.

JM

> 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] Request for volunteers: FOSDEM Videos (even if you're not going to FOSDEM!)

[jean-michel . friedt]

I will be attending the whole session and will be available any time I
am needed to help with checking the video/audio (from last year, I am
still not sure I know what to do in case of failure).

JM

> First of all, thanks Sylvain for volunteering.
> 
> But, it's still only Sylvain and myself, so a few extra hands/eyes
> would be cool. Rest assured, if you volunteer, eternal hacker fame
> and maybe a beer will be your reward.
> 
> As Martin said, you can also help if you are not coming to FOSDEM by
> helping us with the video cutting!
> 
> In any case, hope to see lots of you guys in Brussels!
> 
> Cheers,
> Jan
> 
> 2016-12-26 8:29 GMT+01:00 Sylvain Munaut <246...@gmail.com>:
> 
> > Hi,
> >  
> > >
> > > Jan Krämer (cc'd) is in charge of our A/V setup, so if you're
> > > interested, please let him know.  
> >
> > I can help cut the video. And I can help looking after the feeds on
> > the day.
> >
> > Cheers,
> >
> >Sylvain
> >  



-- 
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] FOSDEM videos

[jean-michel . friedt]

The videos of the FOSDEM talks are now available at
https://video.fosdem.org/2016/aw1125/

Status:
OK: 'Building Self-Optimizing Radios using DEAP'
OK: 'Embedded SDR'
OK: 'News from the OAI Community'
OK: 'Prototyping the 5G Air Interface in GNU Radio: An FBMC Primer'
OK: 'Radio Machine Learning with FOSS'
OK: 'RFNoC -- Evolving SDR toolkits to the FPGA platform'
OK: 'SDR Track Panel'
OK: 'srsUE: A high-performance software radio LTE UE'
OK: 'Synchronization in distributed SDR for localization applications'
OK: 'The GNU Radio Companion Changelog'
OK: 'The rad1o badge'
OK: 'Using Red Pitaya for radio applications (from LF to HF)'
OK: 'Wideband measurement strategies: from RADAR to passive wireless
sensors' 
PARTIAL: (no slides) 'Introduction to the SDR Track'
PARTIAL: (no slides) 'The GNU Radio Toolkit'
PARTIAL: 'Signal Intelligence Challenges'

JM

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

Re: [Discuss-gnuradio] gr-osmosdr issues ?

[Jean-Michel FRIEDT]

Thanks for the answers. All sampling rates are in the 1.5-2.5 MHz range,
namely 11025*128=1.4112 MHz when decoding POCSAG, or 48000*32=1.536 MHz when
decoding commercial FM (for these trivial tests). The issue about
synchronization only arises when an audio sink is used: sending the data to
a named pipe or scope sink displays the "PLL not locked" message but the
decoding/display look fine. I should emphasize that
rtl_fm -f 104.4e6 -M wbfm -s 20 -r 48000 - | aplay -r 48k -f S16_LE
(running a friend's computer) works perfectly well, hence my concern about
gr-osmosdr at opposed to the RTL libs.

JM


It's hardly a trivial report; RTL devices with gr-osmosdr are a very
commonly used platform.

I've seen similar messages from gqrx, but sound quality has not been
impacted. My guess is that this may be related to rapid retuning for
rtl devices, which basically involves not waiting for the PLL to lock.

Does osmosdr-->nullsink display the same message?
What about rtl_sdr ... > /dev null?
Does this only happen at certain sample rates or at any rate? And are
you using a supported sample rate?
https://github.com/csete/gqrx/commit/d805c426f24f987cdb16e37bbab564d30da473c2

On Mon, Jan 11, 2016 at 11:16 AM, jmfriedt
 wrote:
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




--
GDB has a 'break' feature; why doesn't it have 'fix' too?





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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] gr-osmosdr issues ?

[Jean-Michel FRIEDT]

Thanks for the answers. All sampling rates are in the 1.5-2.5 MHz range,
namely 11025*128=1.4112 MHz when decoding POCSAG, or 48000*32=1.536 MHz when
decoding commercial FM (for these trivial tests). The issue about
synchronization only arises when an audio sink is used: sending the data to
a named pipe or scope sink displays the "PLL not locked" message but the
decoding/display look fine. I should emphasize that
rtl_fm -f 104.4e6 -M wbfm -s 20 -r 48000 - | aplay -r 48k -f S16_LE
(running a friend's computer) works perfectly well, hence my concern about
gr-osmosdr at opposed to the RTL libs.

JM


It's hardly a trivial report; RTL devices with gr-osmosdr are a very
commonly used platform.

I've seen similar messages from gqrx, but sound quality has not been
impacted. My guess is that this may be related to rapid retuning for
rtl devices, which basically involves not waiting for the PLL to lock.

Does osmosdr-->nullsink display the same message?
What about rtl_sdr ... > /dev null?
Does this only happen at certain sample rates or at any rate? And are
you using a supported sample rate?
https://github.com/csete/gqrx/commit/d805c426f24f987cdb16e37bbab564d30da473c2

On Mon, Jan 11, 2016 at 11:16 AM, jmfriedt
 wrote:
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




--
GDB has a 'break' feature; why doesn't it have 'fix' too?





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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] detecting covert RFID scans

[jean-michel . friedt]

I'll discuss a bit of passive RFID at FOSDEM ... I think there are two
parts to the question: detecting RFID measurement attempts on the one
hand, and decoding the backscattered signal on the other hand. Detecting
RFID is, imho, obvious: because the backscattered signal decays as
1/d^6 for an inductive coupling, and because of the inefficiency of
the rectifier diode when considering silicon based RFID, the emitted
power must be very strong, and making a simple carrier detection of a
10-W emitter is very simple (since the emitted carrier power decays as
1/d^2). Getting the backscattered (amplitude modulated) signal is a
different story, with an efficient signal to noise ratio requiring the
removal of the carrier, which I cannot think of an obvious strategy if
the emitted carrier is not recorded as well for a coherent demodulation.

JM

> On 27/12/15 19:03, Marcus Müller wrote:  
> > The problem is that technically, the energy sent out by an RFID
> > reader isn't big enough to detect readers from afar; they are
> > near-field devices, as opposed to the typical far-field antenna
> > based radio transmitters.
> > 
> 
> If the sniffer was carried in close proximity to the card itself (e.g.
> the card and sniffer in a backpack) and the backpack passed a hidden
> RFID scanner at the entrance to a shop, would the sniffer be able to
> detect the communication?

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

Re: [Discuss-gnuradio] R820T2/RTL2838U

[Jean-Michel FRIEDT]

these are two chips of the same device (RF front end and ADC to USB converter)
and yes, they do work well with the osmosdr source of gnuradio.

JM


Please, does someone know if these two RTL devices (R820T2 and RTL2838U)
work fine with Gnuradio? Which is better?

Thanks a lot.

Cheers,
Antony

--
Posted via http://www.ruby-forum.com/.

___
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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] multiple sources synchronization ?

[jean-michel . friedt]

 There's nothing in your system that would make both RTL dongles and the 
 soundcard start sampling at the same time, so naturally there's a large 
 time offset between these. You will need to time align these signals 
 first, before you can use the sound card signal to determine in which 
 state (reference or unknown signal) your switch is; this is at least as 
 hard as the problem of aligning the RTL dongles themselves.
 To be honest, I'd rather write an estimator that tells me, only from the 
 signal, whether each RTL dongle is observing the reference or the signal.

right, this is what I ended up doing yesterday: since the reference and measured
signals exhibit different power, I am recording the phase difference as well as 
the magnitude from the dongle connected to the switch, and use the magnitude 
information to differentiate the two states of the switch.

 How do you frequency-synchronize both dongles? Have you modified them to 
 use a common oscillator, or do you also plan to do that based on the 
 observation of the 50MHz tone?

Yes I removed the quartz from one dongle and am using the 28 MHz output from
the other dongle to clock the former. I believe that the slow phase slip is not
important for passive radar applications since the cross-correlation 
reinitializes
the phase, but for my interferometric measurement I need the long term phase 
drift information.

Thanks for the answer, JM


 
 Best regards,
 Marcus
 
 On 22.07.2015 09:51, jean-michel.fri...@femto-st.fr wrote:
  Possibly a stupid question, but might help me better understand how the 
  gnuradio scheduler works:
 
  my objective is to make a low cost phase-referenced radiofrequency 
  interferometer using two DVB-T dongles.
  Since I have observed that the PLL inside each dongle induces slow phase 
  drift, I want to use an external
  RF switch to monitor a known (50 MHz) reference oscillator feeding both 
  dongles, and then monitor the
  unknown signal. Current switching rate is about 50 Hz triggered by an 
  external generator (which also
  synchronizes other events of the experiment, not relevant to this post). My 
  idea for synchronizing the
  post-processing of phase extraction was to record on the one hand the two 
  DVB-T dongle data flow
  (this I know works), and on the other hand the sound card microphone 
  connected to the switch trigger
  signal. This process is summarized in the grc flowchart at 
  http://jmfriedt.sequanux.org/damien_grc.png
 
  However, the sound card output shows a result completely out of sync with 
  the phase measurements. I
  understand that the sound card and DVB-T dongles do not share the same 
  clock sources, but considering
  the huge decimation factor (48*32 kHz for the DVB-T, 48 kHz for the sound 
  card, and a phase output recorded
  at about 0.5 to 5 kHz, not shown on this grc chart), I would have expected 
  the trigger signal to be more or
  less synchronized with the DVB-T outputs, which is not at all the case.
 
  Is the gnuradio scheduler unable to interleave two data sources as 
  different as a sound card and the
  USB data flow from the two DVB-T dongles ? Is there a way I might tune my 
  flowchart to achieve
  the expected result ?
 
  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] multiple sources synchronization ?

[jean-michel . friedt]

Possibly a stupid question, but might help me better understand how the 
gnuradio scheduler works:

my objective is to make a low cost phase-referenced radiofrequency 
interferometer using two DVB-T dongles. 
Since I have observed that the PLL inside each dongle induces slow phase drift, 
I want to use an external
RF switch to monitor a known (50 MHz) reference oscillator feeding both 
dongles, and then monitor the
unknown signal. Current switching rate is about 50 Hz triggered by an external 
generator (which also
synchronizes other events of the experiment, not relevant to this post). My 
idea for synchronizing the
post-processing of phase extraction was to record on the one hand the two DVB-T 
dongle data flow
(this I know works), and on the other hand the sound card microphone connected 
to the switch trigger
signal. This process is summarized in the grc flowchart at 
http://jmfriedt.sequanux.org/damien_grc.png

However, the sound card output shows a result completely out of sync with the 
phase measurements. I 
understand that the sound card and DVB-T dongles do not share the same clock 
sources, but considering 
the huge decimation factor (48*32 kHz for the DVB-T, 48 kHz for the sound card, 
and a phase output recorded
at about 0.5 to 5 kHz, not shown on this grc chart), I would have expected the 
trigger signal to be more or 
less synchronized with the DVB-T outputs, which is not at all the case.

Is the gnuradio scheduler unable to interleave two data sources as different as 
a sound card and the
USB data flow from the two DVB-T dongles ? Is there a way I might tune my 
flowchart to achieve
the expected result ?

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] Regular FM radio fine, POCSAG horrible

[jean-michel . friedt]

If it can be of any help, I use POCSAG to illustrate one of the SDR labs I
teach: the flowcharts are pp.4 and 5 of http://jmfriedt.free.fr/tp_sdr.pdf 
(don't
mind the text in French, only look at the pictures) and the associated videos
are at http://jmfriedt.free.fr/ (first two ones from the top).

JM

  I am sure GR can do that, but I can't ;-)
 I can't help but propose you change that ;) No, seriously,
 cross-compiling GNU Radio for an ARM sounds more complicated than doing
 non-coherent binary FSK demod, but then again, that might just be me :D.
 
 In fact, you're absolutely right: getting a solid signal quality before
 attempting decoding might be a good idea. However, most probably pagers
 don't need awesome SNR, so somewhat noisy might still be ok.
 
 so how do you get the samples into GNU Radio?
 I guess you use the gr-osmosdr source? which sampling rate? Where in
 your base band are your carriers?
 What does your flow graph look like?
 
 Generally: If you have a RF recording, [1] might just profit from one
 more entry, and we'd have something more tangible to talk about :)
 
 I'll outline the steps I'd do to try to achieve better signal:
 
  1. Record a signal and test with that -- doing everything live makes
 things complicated and hard to reproduce.
  2. Use a xlating FIR filter to move a single 12.5kHz channel to 0Hz, so
 that either symbol is +- 4.5kHz
  1. this will require that you design a filter. Don't worry, that's
 relatively easy:
  1. run gr_filter_design
  2. select low pass, enter your source's sampling rate, set the
 end of the pass band to let's say 5kHz and the start of the
 stop band to 7.5kHz (If I understand wikipedia correctly,
 channel spacing is 12.5kHz, and symbol deviation is
 +-4.5kHz, so from the center of the lower channel to the
 lower bit of the upper channel it's 12.5kHz - 4.5kHz = 8kHz).
  3. You'll notice that if you start with a high sampling rate,
 your filter gets ridiculously long. If that's the case, you
 might want to reduce the sampling rate of your signal
 source, or add a stage of half- or quarter bandwidth FIR
 decimation (with a decimation factor of 2 or 4, respectively)
  2. set the decimation of that xlating FIR to something reasonable,
 so that rate_in/decimation  12.5kHz/2, but not .
  1. this way, you'll get just enough rate at the output. 
  3. set the center frequency to the middle of your two symbol
 frequencies in the input spectrum
  3. add visualization sinks here and there, and verify :)
  4. add a real high-pass filter
  1. Your single-channel spectrum looks something like [1] with 0 Hz
 in the middle.  Since we've filtered away stuff above 5kHz, we'd
 now concern ourselves with filtering away everything below 4kHz.
  2. Same procedure as for the xlating fir, but use the reduced
 sampling rate and a 4 kHz high-pass with a 2kHz stop band or
 something. The closer the stop band is to pass band, the longer
 your filter gets.
  3. In principle, a 4-5 kHz real-tapped bandpass xlating fir would
 have done the same, but doing this step by step reduces error
 probability.
  5. repeat add visualizations :)
  6. You should now have a clean signal with only two peaks in your
 spectrum at +-4.5kHz; does your external decoder deal well with that?
 
 In principle, you're extremely close to having your own decoder by now.
 Non-coherent BFSK decoding would simply do the same as step 2, but with
 two filters, each centered on either symbol frequency, baudrate-wide
 passband, decimating to the baudrate, followed by a
 complex-to-magnituded-squared conversion each, then something like
 division of the 1-filter magsquared by the 0-filter magsquared, followed
 by a threshold decision (threshold=1). You'd then be getting a raw
 POCSAG bitstream :D
 
 Best regards,
 Marcus
 
 
 [1] from http://edge.rit.edu/edge/P09141/public/FSK.pdf ,
 Watkins-Johnson Company Tech-notes Vol. 7 No. 5 September/October 1980:
 FSK: Signals and Demodulation, p. 8 FSK spectrum
 http://edge.rit.edu/edge/P09141/public/FSK.pdf
 
 On 06/02/2015 12:04 AM, Stephan van Beerschoten wrote:
 
  I am sure GR can do that, but I can't ;-)
  Also, I don't have a good waterfall at all of the pocsag broadcast,
  which is probably part of why I can't make it out with my ears either.
  Yes, I think I have too much noise.
  I hope it can be overcome with the right settings and filters.
 
  I'll try to capture a screenshot of what I see. It's nothing like the
  screenshots in Wikipedia.
 
  On Jun 1, 2015 5:47 PM, Marcus Müller marcus.muel...@ettus.com
  mailto:marcus.muel...@ettus.com wrote:
 
  Hi!
  I personally think the soundbite from wikipedia is broken, since
  it's 11kHz sampling rate violates Nyquist ;)
  Well, I must admit that 

[Discuss-gnuradio] dual receiver setup for interferometry measurements

[jean-michel . friedt]

I have a question concerning connecting two DVB-T dongles on the same clock
source for interferometric (or passive radar) measurements, as described at
http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
I have assembled the same system with one dongle used as oscillator on a 28.8 
MHz resonator
and the second one as a slave to this clock. All works fine, solved the issue
when the oscillator would not start, now I have a reliable source of 
measurements.

Initial tests (these are R820T-based dongles) exhibits significant random phase 
drift
which I attributed to heating of the chips (they get above 50 degC when running 
continuously),
so after gluing two heat sink with heat-conducting epoxy, I more or less 
managed to
get a stable phase measurement when recording a same oscillator (200 MHz) with 
the
two dongles and displaying the phase as angle(conjugate(signal1)*signal2).

The question is as follows: at http://jmfriedt.sequanux.org/ph_tout.pdf I have 
shown one
graph, quite representative of all my experiments, displaying the evolution of 
the phase
difference between both dongles connected to the same 200 MHz oscillator. I 
*always* 
start with a quite stable phase difference (red curve -- inset in a zoom of 
this particular
measurement) after plugging in my USB hub fitted with the two dongles and 
starting gnuradio-companion
for recording the dongle I/Q stream (notice the abscissa sampling rate of 10 Hz 
= the full
graph is about 1-hour long). After about an hour, I stop recording the red 
curve, and
all I do is switch off gnuradio-companion and start it back = green curve with 
a quickly falling
phase. Switch off again, disconnect-reconnect USB hub, restart an acquisition 
= blue curve.
Same procedure = magenta curve.

Can anyone hint at an explanation as to why I always start with a reasonably 
stable phase
difference (yet not constant -- is the phase fluctuation indeed due to heating 
of the fractional
PLL in each RF frontend, drifting below the feedback loop time constant ?), but 
more worrisome
why I always get this huge drift after launching a new acquisition ? The fact 
that I always
get the same slope hints at a sofware/hardware communication issue, but how it 
is possible
since both dongles are clocked by the same source and receive the same commands 
from the
software ?

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] dual receiver setup for interferometry measurements

[jean-michel . friedt]

Thanks for your reply. Indeed designing phase coherent receivers is my daily
job activity (partly), but the fun of hacking DVB-T receivers is to find ways 
of using 
these for applications they were never intended for. I have indeed read your 
posts 
concerning the difficulties in reproducing interferometric measurements, a great
source of inspiration. At the moment we are considering quantifying the phase
drift (switching from a reference oscillator to the unknown signal), but I 
wonder
nevertheless why some have achieved excellent coherence and some (including 
myself)
are failing. Nevertheless I'd like to actually identify the source of the drift
(PLL bandpass, temperature-related setpoint drift, software configuration ?).

Thanks, JM

 This is largely because this $10.00-apiece hardware was never designed
 for this class of application. When you're doings things that require
 phase-coherence, you have to design your radios to support it. 
 
 There are at least two PLLs involved here--one on the R820T chip, and
 another, as far as I can tell, in the RTL2832U chip, which does the
 conversion to baseband from the low-IF of the R820T. 
 
 I was never able to get my RTL receivers to be phase-coherent in any
 useful way, there was always a slow phase drift, that was unpredictable.
 
 
 On 2015-05-28 14:18, jean-michel.fri...@femto-st.fr wrote: 
 
  I have a question concerning connecting two DVB-T dongles on the same clock
  source for interferometric (or passive radar) measurements, as described at
  http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html [1]
  I have assembled the same system with one dongle used as oscillator on a 
  28.8 MHz resonator
  and the second one as a slave to this clock. All works fine, solved the 
  issue
  when the oscillator would not start, now I have a reliable source of 
  measurements.
  
  Initial tests (these are R820T-based dongles) exhibits significant random 
  phase drift
  which I attributed to heating of the chips (they get above 50 degC when 
  running continuously),
  so after gluing two heat sink with heat-conducting epoxy, I more or less 
  managed to
  get a stable phase measurement when recording a same oscillator (200 MHz) 
  with the
  two dongles and displaying the phase as angle(conjugate(signal1)*signal2).
  
  The question is as follows: at http://jmfriedt.sequanux.org/ph_tout.pdf [2] 
  I have shown one
  graph, quite representative of all my experiments, displaying the evolution 
  of the phase
  difference between both dongles connected to the same 200 MHz oscillator. I 
  *always* 
  start with a quite stable phase difference (red curve -- inset in a zoom of 
  this particular
  measurement) after plugging in my USB hub fitted with the two dongles and 
  starting gnuradio-companion
  for recording the dongle I/Q stream (notice the abscissa sampling rate of 
  10 Hz = the full
  graph is about 1-hour long). After about an hour, I stop recording the red 
  curve, and
  all I do is switch off gnuradio-companion and start it back = green curve 
  with a quickly falling
  phase. Switch off again, disconnect-reconnect USB hub, restart an 
  acquisition = blue curve.
  Same procedure = magenta curve.
  
  Can anyone hint at an explanation as to why I always start with a 
  reasonably stable phase
  difference (yet not constant -- is the phase fluctuation indeed due to 
  heating of the fractional
  PLL in each RF frontend, drifting below the feedback loop time constant ?), 
  but more worrisome
  why I always get this huge drift after launching a new acquisition ? The 
  fact that I always
  get the same slope hints at a sofware/hardware communication issue, but how 
  it is possible
  since both dongles are clocked by the same source and receive the same 
  commands from the
  software ?
  
  Thanks, JM
  
 
 Links:
 --
 [1] http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
 [2] http://jmfriedt.sequanux.org/ph_tout.pdf


-- 
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] R820T frequency tuning issue

[jean-michel . friedt]

As a quick followup to my previous post, I confirm that the R820T is well 
suited for GPS
signal decoding. I was not expecting the huge frequency offset ( 100 kHz at 
1.57 GHz) and
was not searching far enough from the expected carrier frequency during the 
acquisition phase.
However these results were acquired by runnig rtl_sdr -s ... -f ... while 
gnuradio-companion
running gr-osmosdr is unable to lock at 1.57 GHz and barely locks (for a few 
seconds !) at
1.56 GHz. I have analyzed the various version of librtlsdr (used by rtl_sdr and 
by gr-oscmocom)
as well as the set_frequency functions and am unable to track any difference 
between the two
codes (so far).

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] R820T frequency tuning issue

[jean-michel . friedt]

 Your results are consistent with what I've heard about the R820T above 
 1500MHz or so.  It starts to become
deaf, and then as you move higher, the PLL won't lock at all.

I loose 10 dB sensitivity from 1.50 GHz to 1.575 GHz ! At 1.5 GHz the R820T was 
more sensitive
than the E4k, but now I'll have to review this statement at 1.57 GHz !

Thanks for the help, 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] feedback loop for bpsk carrier recovery ?

[jean-michel . friedt]

For educational purposes, I am investigating a carrier recovery scheme for BPSK 
demodulation.
I have synthesized a BPSK modulated signal, assembled a hardware carrier 
recovery scheme which
works well (squaring the modulated signal, bandpass filtering and dividing, aka 
Costas loop) which
I now want to implement as SDR in GNURadio. To do so, I acquire the BPSK 
modulated signal, extract
the carrier by squaring the I/Q data flow and bandpass filtering, all this work 
fine. Before squaring
the signal, I insert a Xlating FIR filter whose NCO frequency will act as the 
tunable VCO in the
hardware version of the carrier tracking circuit.

Question: how can I feedback the output of the lowpass filter (ie error signal 
of the PLL) to the
NCO of the Xlating FIR Filter ?

(I have found, following 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_PSK_Demodulation
the Costas loop block which works very well with my real signal, but I'd like 
to implement it
manually -- or can't gnuradio-companion close a feedback loop ?)

Additional question: since gnuradio-companion 3.7.5 I see a grey freq tab in 
the Xlating FIR
filter block, but cannot find any associated documentation or what the use of 
this input is. Is
this the functionality I am looking for ?

Thank you, 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] git access to UHD through http ?

[Jean-Michel FRIEDT]

not sure if this issue is relevant to the mailing list:
while running the tutorial at https://github.com/balister/oe-gnuradio-manifest
which aims at recovering all tools needed to build an image for an embedded
architecture, intensive requests to git are performed to fetch all the source
codes.
Although it all works fine from home,  I am now building this image from a
computer at work which is behind a firewall only allowing http and https
request,  no ftp:// nor git://
Most, if not all, git requests could be satisfied by converting the git://
and ftp:// requests to https:// through the insteadOf option of git. All
but one, hence my request to this list: uhd-1_3.5.3-r3.0 seems only accessible
by git request, while http or https requests fail with a login/password prompt
(eg http://ettus.sourcerepo.com/ettus/uhd.git or the same url with  
https request).

Is there a way to recover this archive without a git:// request ?

Thanks, JM


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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] GNURadio on Zync: thanks for the excellent tutorial

[Jean-Michel FRIEDT]

Damn I missed all these replies to my initial post due to not being familiar
with our webmail interface and not having access to the lab for the last
8 days. I hope I have not done anything stupid by not taking into account
the comment about having to wait for the OE update: I have tried to add my
own comments to the Zynq wiki page but not being familiar at all with OE, some
of these comments might be overly naive (I believe not wrong, since these are
the steps I took to get to the point of compiling the FIR on FPGA example).
Some knowledgeable person should definitely review these updates to the wiki
page.

At the moment, I am stuck with two issues:
1/ eth0 will not start when booting linux on the Zynq with the current kernel,
so no git/opkg install from the web at the moment (makes the software update a
bit complex by keeping on putting the SD card back in the PC connected to the
internet)
2/ cmake does not find gnuradio-runtime: I am pretty sure this is an issue
with the outdated FindGnuradioRuntime.module issue but I have not yet managed
to get gr_modtool to run ... still working on it.

I assume my addition to the wiki on the installation of cmake is not  
erroneous,

but should be checked as well.

JM


On 12/27/2013 03:38 AM, Vanush Vaswani wrote:

Is there any difference in using this stack compared to say, the
Ubuntu distribution available on www.armhf.com, and compiling gnuradio
from source?


Compiling GNU Radio from source on an embedded board takes much longer
than using a cross compiler. Also, during the compile on a low memory
embedded board, parts of the com[ile takes lots of memory and you may
need to nurse the build during this part of the build.

My i7 builds gnuradio loads faster than even a quad A15.

Both approaches work, I just do not like to wait :)

Philip



Vanush

On Fri, Dec 27, 2013 at 2:31 AM, Philip Balister  
phi...@balister.org wrote:

On 12/26/2013 02:28 AM, Jean-Michel FRIEDT wrote:

I have used the opportunity of the more relaxed days of this Christmas
period to try and run the tutorial at
http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq


We need to update the OE section of this page to use:

https://github.com/balister/oe-gnuradio-manifest

for managing the OE layers. I'd suggest not starting a new checkout if
you have something working until after I update UHD to 3.6.2 though :)

Also, https://github.com/balister/meta-sdr/wiki/CrossCompile has
instructions for cross compiling GNU Radio and testing the result. We
need to verify this approach works for OOT module development also.

Merry Christmas,

Philip



Wonderful page, works nearly perfectly, thanks a lot.

A few minor comments to the author or useful to other readers of the
mailing
list:
1/ using a brand new Debian/testing installation, it seems that the latest
version of tar will not accept both -c and -s options in its command line.
I hence edited all entries of openembedded-core/meta/lib/oe/ and replaced
the -ps option of tar with -p. Same for the meta/classes entries.
Apparently
this has been patched in the latest release of openembedded, but  
indeed the

zync script will not run out of the box on the latest openembedded release
and, as advised on the web page, I git commited against a given older
release,
2/ the note about Xilinx tools to Ubuntu users concerning gmake should
be in
bold, huge size, blinking fonts ;)  I spent a while being concerned about
licensing issues when the FPGA synthesis tool would not run. No
seriously, just
learning to read did the trick. As a side note, it all ran smoothly with
the
14.7 release of ISE on a 32-bit x86 architecture. I believe there is a
minor
trivial error in the PATH to ISE in which xtclsh should not be included in
the PATH definition.

Anyway, thanks for the tutorial, just need to now understand what I did,
but
at least the whole thing is running smoothly.

Best wishes for the new year, 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



This message was sent using IMP, the Internet Messaging Program.


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

[Discuss-gnuradio] GNURadio on Zync: thanks for the excellent tutorial

[Jean-Michel FRIEDT]

I have used the opportunity of the more relaxed days of this Christmas
period to try and run the tutorial at
http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq

Wonderful page, works nearly perfectly, thanks a lot.

A few minor comments to the author or useful to other readers of the mailing
list:
1/ using a brand new Debian/testing installation, it seems that the latest
version of tar will not accept both -c and -s options in its command line.
I hence edited all entries of openembedded-core/meta/lib/oe/ and replaced
the -ps option of tar with -p. Same for the meta/classes entries. Apparently
this has been patched in the latest release of openembedded, but indeed the
zync script will not run out of the box on the latest openembedded release
and, as advised on the web page, I git commited against a given older release,
2/ the note about Xilinx tools to Ubuntu users concerning gmake should be in
bold, huge size, blinking fonts ;)  I spent a while being concerned about
licensing issues when the FPGA synthesis tool would not run. No  
seriously, just

learning to read did the trick. As a side note, it all ran smoothly with the
14.7 release of ISE on a 32-bit x86 architecture. I believe there is a minor
trivial error in the PATH to ISE in which xtclsh should not be included in
the PATH definition.

Anyway, thanks for the tutorial, just need to now understand what I did, but
at least the whole thing is running smoothly.

Best wishes for the new year, JM

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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] BESOIN D'AIDE GNURADIO

[Jean-Michel FRIEDT]

 je réalise une radio logicielle sous GNU RADIO mais seulement je ne  
maitrise pas très bien le role des blocs. en fait j'ai besoin d'un  
amplificateur à gain variable et un démodulateur I/Q. j'arrive pas à  
retrouver ces bloc sous GNURADIO. si quelqu'un peut me venir en aide  
je serai très honoré.


Translation:
I am designing a software defined radio running with GNURadio and not being
familiar with the processing blocks, I am looking for a VGA and I/Q  
demodulator

blocks which I am unable to find. Can anyone help.

Reponse: je peux fournir le bloc I/Q form'e d'un NCO et d'un multiplieur,
il suffit de placer le filtre passe bas a sa suite. Le VGA est  
disponible comme

block GNURadio.

JM


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



This message was sent using IMP, the Internet Messaging Program.

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

Re: [Discuss-gnuradio] How to use USRP to detect and collect weak satellite signals

[Jean-Michel FRIEDT]

apparently someone else was at OHM ...
i had not seen the trick of squaring the GPS signal to get rid of the
phase modulation and hence the spread spectrum to only recover the doppler
shift elsewhere: looks like a great trick to validate the reception of a GPS
signal even below thermal noise levels.


What is the difference between the receiver tech in something like a CSR
chip vs USRP?


On Wed, Sep 4, 2013 at 9:25 PM, Ralph A. Schmid, dk5ras  
ra...@schmid.xxxwrote:



 I've actually seen it without de-spreading during a presentation
recently. Of
 course it had been received with a 25 m dish or so :)

Yep, brute forced it should be possible :-) Not really the same like with
UMTS or LTE...

Ralph.


___
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



This message was sent using IMP, the Internet Messaging Program.


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

Re: [Discuss-gnuradio] Doppler Radar Processing

[Jean-Michel FRIEDT]

in case you are interested in such a related topic
http://jmfriedt.free.fr/poster_12906.pdf
I have not made an archive of all the related boxes and GRC graphs but this
might be an opportunity to do so.

JM


Has anybody done Doppler Radar Processing in GNU Radio Companion?
Currently, I am just saving off the data and then processing it in  
Octave/Matlab. It would be nice to have a display of the  
range/Doppler map that is updated periodically within GRC.  This  
would give me a good indication that everything is working without  
me having to save off the data and load it into matlab.  I am fairly  
new to GNU Radio and the GRC and it is the plots that I really don't  
know how to do.  So, does anyone have something like a 2D Mesh plot  
in QT that I could update semi-real time?


Thanks,
Frank Wallace





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



This message was sent using IMP, the Internet Messaging Program.


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