(python) resources for "offline" signal processing ?

[Kristoff]

Hi all,

Does anybody have a list of good python resources for "non-real-time" 
signal-processing of radio-signals.
("non-real time" as in "an iq-file of prerecorded dataframe", in 
contrast a continuous stream like a GR flowgraph)




Say you start with the IQ-file of a HFDL-packet and you would want to 
analyse and visualize it, take it apart, demodulate and decode it, etc.



I've come across libraries like numpy, scipy-signal and commpy, 
visualization-tools like matplotlib and seaborn and others.


For audio, there is off course audacity.
For quick-and-dirty visualization of radio-packets, I have used inspectrum.


So there does not seams to be a lack of tool, .. perhaps there are to 
many of them :-)


It would be nice to have a overview of what tools/libraries are 
available to do what, and what would the good method to build a 'flow' 
to -say- build a GR block for a HFDL packet decoder.




I have already found pysdr.org to be an interesting resource.

Anybody an idea of other resources?

Re: Working Narrowband FM examples?

[Kristoff]

Hi Nathan,



firdes.low_pass(1, 8e6, 5000, 1700)


Oefti! .. that is a very narrow filter!

Keep in mind that in DSP, the more narrow a filter, the more 
computational expensive it is.
And 'narrow' is related to the passband of the filter compared to the 
samplerate..


5000 Hz compared to 8 MHz, that is very narrow. I'm surprised that you 
can actually do this.



What I usually do (but other people might have do it differently) is to 
take down the sampling-rate in multiple steps.


- Start with the xlating FIR filter (to correct the frequency-offset) 
and do a decimation of 8, so to take the 8 Msps down to 1 Msps

The taps are:
firdes.low_pass(1, samp_rate, samp_rate/(2*decim), transition_bw)

- Next add a 'rational resampler' to down the samplerate even further, 
e.g. 'interpolate 1, decimate 20 to go down to 50 KHz


- then add your low-pass filter of 5 KHz/1700 Hz.

In this case, your filter is 5 Khz compared to 50 Khz, which is a 1/10 
ratio.



Another option is to use a low-passfilter and do decimation at the same 
time. The low-pass filter block has a parameter 'decimation'.



One more thing:

I think that a NBFM channel is actually wider (on RF) then the 5 KHz you 
mention: 10 KHz to 20 KHz, depending on the FM modulation index.
If there are no other stations on the neighboring channel, 20 KHz will 
probably be fine. If you have adjacent-channel interference, you can 
reduce the filter.


I propose you first use an sdr-tool like gqrx, cubesdr or sdr++ and 
visually inspect what the radio-signal looks like you want to receive.



Note. Another option to get help from the GNU Radio community is to use 
the matrix chat-server.

(Matrix is an open-source distributed and federated IM/voip/video service).

If you do not yet have an account on a matrix service, you can create 
one (e.g.) here:

https://chat.gnuradio.org/

The main chat-room for GNU radio is here:
#gnuradio:gnuradio.org

There are also some other (more specialized) GNUradio-related rooms, 
like for amateurradio and for the documentation sub-project.



IMHO, IM / chat is more suited to quick issues, while mail is usually 
better for more indepth discussions.


Matrix does offer the ability to share files, screen-dumps or even voice 
or video-conference, which can also be useful tools.



Kristoff (on1arf)


On 11.08.21 07:49, Nathan Van Ymeren wrote:

Hi Gary,

Thanks for the reading list.  I’m an engineer, so I have multivariate calculus 
under my belt, but I’m not an electrical engineer, so sometimes when texts get 
too down in the weeds my eyes roll back in my head and I start foaming at the 
mouth, haha.

As for hardware, I mentioned in my opening post to the list that it’s a hackRF. 
 It *should* be capable of up to 20MS/s all the way from 1MHz to 6GHz.  I’ve 
ordered one of those RF shielding kits to hopefully address the noise problem.  
Or at least, I’m not aware of any limitations on the hackrf’s sampling rate 
other than the 20MHz upper limit (but I’m still digging!)

For the low pass filter in the Xlating block I’m calling out to firdes:

firdes.low_pass(1, 8e6, 5000, 1700)




On Aug 9, 2021, at 17:05, Gary Schafer  wrote:

Several points:

1) Further reading: "Digital Signal Processing" by Steven Smith and "Understanding Digital Signal 
Processing" by Rick Lyons. Smith makes his book available for download at https://www.dspguide.com/. Lyons has 
many of his stuff scattered around "DSPRelated.com" (https://www.dsprelated.com/). Unlike your usual 
textbooks, these books actually *EXPLAIN* stuff, not just throw some math proofs at you and say, "See how easy it 
is to understand?"

2) What hardware are you actually using? USRP? RTL-SDR? HackRF? Something else? 
I've found that the HackRF, while it covers a huge frequency range relative 
to most other inexpensive SDRs, it also has a much worse noise figure.

3) 384k wasn't too *low*. I was guessing it was just *outside* of what the hardware can 
handle. If the hardware *could* handle it, then you would not have had the issue you did. 
The RTL-SDR, for example, can only handle sample rates between 200 kHz - 300 kHz, then 
jumps to 0.9 - 3.2 MHz. Anything outside of that range gets pushed to the closest sample 
rate the device can handle. The few times I've managed to play with a USRP, I've found 
that it can only handle sample rates that are values of 100 MHz / N, where "N" 
is an integer. As you discovered with whatever hardware you're actually using, if you use 
a sample rate that will work with the hardware, you can change it in Gnu Radio to 
whatever you *need* it to be.

4) I'm game for a comparison between GQRX and Gnu Radio. We need to make sure we have similar 
settings between them. I don't think the sample rate is the problem. So long as you're within the 
parameters that the particular SDR wants, AND you are meeting Nyquist, you sh

Re: taps for a Raised Cosine function

[Kristoff]

Hi gary, Fabian, all,


Small note:


The first tests seems to indicate the the rrc-filter works! Yes!

- I can decode large chunks of data with valid Manchester-encoding. 
However, from time to time, I do get large blocks of data (10 to 20 
seconds) with errors.
- Changing the value of alpha does not appears to have that much of an 
influence.



I'll record a large audio-file of a couple of hours and so that I can do 
a multiple tests all based on the same "reference" signal before making 
a final statement about this.



I did notice that the costas-loop (in front of the polyphase clock-sync) 
acts strange.


In this system, the phase-shift of the carrier is not shifted 180 
degrees (as most PSK systems) but only 45 degrees (i.e., +- 22.5 degrees 
compared a central reference). It looks like the costas-loops has issues 
with that.
Sometimes, the points on the constellation-plot are on the right side of 
the graph (i.e. above and below 0 degrees); and somethings they hover 
above and below the 180 degrees point (on left side of the constellation 
graph).

And this changes randomly.

I also have the impression that the polyphase clock-sync block is able 
to do a better job when the constellation-points are around 180 degrees 
then when they hover around 0 degrees as I see a lot more biterrors when 
the points on the constellation-graph are on the right side of the graph.



I think we've got some more experimentation to do! :-)



Thanks for the help!


Kristoff


On 10.08.21 22:36, Gary Schafer wrote:

Kr,

That pulse shaping is *identical* to that for a RDS signal. I'm able 
to demodulate the RBDS signal using a RRC filter in a "Polyphase Clock 
Sync" block. Adjusting the parameters from the RDS signal to that of 
your BBC signal (1187.5 Hz bit rate to 25 Hz bit rate), you'd get the 
following parameters for the various blocks:


Polyphase Clock Sync:
Samples/symbol: 50
Loop bandwidth: 2*pi/100
Taps: rrc_taps_rx
Filter size: 50
Initial phase: 1
Maximum rate deviation: 1.5
Output SPS: 1

RRC Filter Taps:
Id: rrc_taps_rx
Gain: 1
Sample rate: 1250
Symbol rate: 25
Excess BW: 0.35
Num Taps: 550

At the very least, if my hypothesis is correct, that *should* get you 
a constellation that is roughly a donut (as opposed to a big ball of 
dots).


Hope this helps.

Gary

**

Hi all,


I am playing around with PSK demodulation, now doing a small project 
trying to decode the slow-speed PSK data on the 198 KHz carrier of BBC 
radio 4.



The specs are here:
http://downloads.bbc.co.uk/rd/pubs/reports/1984-19.pdf

According the document (page 2 of the document, page 8 of the PDF), 
the system uses a shaping-filter of cos(pi * f * Td / 4).


(with Td = 50)

If I am correct, this is in fact a raised-cosine filter with beta = 1.
https://en.wikipedia.org/wiki/Raised-cosine_filter

So the document seems to specify a raised-cosine filter, both on the 
transmit and receive side; so not a ROOT raised-cosine as is used in 
most PSK systems.



Question:|

How do I create the filter-taps for the Polyphase clock sync block for 
a raised-cosine filter?



I found a function firdes.root_raised_cosine, but no 
firdes.raised_cosine?


Is there a way to easily convert the taps of a RRC filter to those of 
a RC filter? (RC = RRC^2, so square the value of all taps?)





Any other ideas?

- put an additional RRC low-pass filter in front of the Polyphase 
clock-sync block?


- use firdes.pm_remez() ?



Thanks in advance,


Kr.

Re: taps for a Raised Cosine function

[Kristoff]

Hallo Gary,



OK, I based my assumption on the graph of the RC on wikipedia  (*)

Perhaps I got it wrong and is the frequency-response indeed a RRC, not a RC.
If yes, this would make things a lot easier.

(Perhaps I got confused by the fact that amateur-radio PSK31 uses RC 
instead of RRC, so perhaps there is a reason this was also the case here)



Question.
On what do you base the excess BW value of 0.35?

Is it based on the math of the specification, or experimentation?


I'll try the values you propose and -just for the fun- also try some 
other values.
One of the advantages of manchester-encoding is errors are a pretty to 
detect and to count, so that should provide a basis to measure the BER :-)




(*) 
https://en.wikipedia.org/wiki/Raised-cosine_filter#/media/File:Raised-cosine_filter.svg



Kristoff


On 10.08.21 22:36, Gary Schafer wrote:

Kr,

That pulse shaping is *identical* to that for a RDS signal. I'm able 
to demodulate the RBDS signal using a RRC filter in a "Polyphase Clock 
Sync" block. Adjusting the parameters from the RDS signal to that of 
your BBC signal (1187.5 Hz bit rate to 25 Hz bit rate), you'd get the 
following parameters for the various blocks:


Polyphase Clock Sync:
Samples/symbol: 50
Loop bandwidth: 2*pi/100
Taps: rrc_taps_rx
Filter size: 50
Initial phase: 1
Maximum rate deviation: 1.5
Output SPS: 1

RRC Filter Taps:
Id: rrc_taps_rx
Gain: 1
Sample rate: 1250
Symbol rate: 25
Excess BW: 0.35
Num Taps: 550

At the very least, if my hypothesis is correct, that *should* get you 
a constellation that is roughly a donut (as opposed to a big ball of 
dots).


Hope this helps.

Gary

**

Hi all,


I am playing around with PSK demodulation, now doing a small project 
trying to decode the slow-speed PSK data on the 198 KHz carrier of BBC 
radio 4.



The specs are here:
http://downloads.bbc.co.uk/rd/pubs/reports/1984-19.pdf

According the document (page 2 of the document, page 8 of the PDF), 
the system uses a shaping-filter of cos(pi * f * Td / 4).


(with Td = 50)

If I am correct, this is in fact a raised-cosine filter with beta = 1.
https://en.wikipedia.org/wiki/Raised-cosine_filter

So the document seems to specify a raised-cosine filter, both on the 
transmit and receive side; so not a ROOT raised-cosine as is used in 
most PSK systems.



Question:|

How do I create the filter-taps for the Polyphase clock sync block for 
a raised-cosine filter?



I found a function firdes.root_raised_cosine, but no firdes.raised_cosine?

Is there a way to easily convert the taps of a RRC filter to those of 
a RC filter? (RC = RRC^2, so square the value of all taps?)





Any other ideas?

- put an additional RRC low-pass filter in front of the Polyphase 
clock-sync block?


- use firdes.pm_remez() ?



Thanks in advance,


Kr.

Re: taps for a Raised Cosine function

[Kristoff]

Hi Fabian,

Thanks, i'll try both options and compair them.


I remember from my books on DSP it is possible to combine multiple 
consecutive FIT filters into one, so I did a little bit of more research 
on this.



I found (*) that -as convolution as associative- this implies this:

(( f * h1) * h2) = f * (h1 * h2)



So I guess I just use firdes.root_raised_cosine to calculate the RRC and 
then "numpy.convolute()" it with itself, I should get the RC.


Feel free to correct me if I am wrong. :-)



(*) 
https://dsp.stackexchange.com/questions/20194/concept-of-combining-multiple-fir-filters-into-1-fir-filter



Kristoff



On 10.08.21 21:01, Fabian Schwartau wrote:

Hi Kristoff,
You can just put an additional RRC in front of it or you can calculate 
the tabs by folding die tabs of the RRC with themself. There is 
probably a numpy function to do that. Have not tested any of that, but 
both ways should do the trick.


Fabian

Am 10. August 2021 20:44:05 MESZ schrieb Kristoff :

Hi all,


I am playing around with PSK demodulation, now doing a small project
trying to decode the slow-speed PSK data on the 198 KHz carrier of BBC
radio 4.

The specs are here:
http://downloads.bbc.co.uk/rd/pubs/reports/1984-19.pdf  
<http://downloads.bbc.co.uk/rd/pubs/reports/1984-19.pdf>

According the document (page 2 of the document, page 8 of the PDF), the
system uses a shaping-filter of cos(pi * f * Td / 4).
(with Td = 50)

If I am correct, this is in fact a raised-cosine filter with beta = 1.
https://en.wikipedia.org/wiki/Raised-cosine_filter  
<https://en.wikipedia.org/wiki/Raised-cosine_filter>

So the document seems to specify a raised-cosine filter, both on the
transmit and receive side; so not a ROOT raised-cosine as is used in
most PSK systems.

Question:|
How do I create the filter-taps for the Polyphase clock sync block for a
raised-cosine filter?

I found a function firdes.root_raised_cosine, but no firdes.raised_cosine?

Is there a way to easily convert the taps of a RRC filter to those of a
RC filter? (RC = RRC^2, so square the value of all taps?)



Any other ideas?
- put an additional RRC low-pass filter in front of the Polyphase
clock-sync block?
- use firdes.pm_remez() ?



Thanks in advance,


Kr.

taps for a Raised Cosine function

[Kristoff]

Hi all,


I am playing around with PSK demodulation, now doing a small project 
trying to decode the slow-speed PSK data on the 198 KHz carrier of BBC 
radio 4.


The specs are here:
http://downloads.bbc.co.uk/rd/pubs/reports/1984-19.pdf

According the document (page 2 of the document, page 8 of the PDF), the 
system uses a shaping-filter of cos(pi * f * Td / 4).

(with Td = 50)

If I am correct, this is in fact a raised-cosine filter with beta = 1.
https://en.wikipedia.org/wiki/Raised-cosine_filter

So the document seems to specify a raised-cosine filter, both on the 
transmit and receive side; so not a ROOT raised-cosine as is used in 
most PSK systems.


Question:|
How do I create the filter-taps for the Polyphase clock sync block for a 
raised-cosine filter?


I found a function firdes.root_raised_cosine, but no firdes.raised_cosine?

Is there a way to easily convert the taps of a RRC filter to those of a 
RC filter? (RC = RRC^2, so square the value of all taps?)




Any other ideas?
- put an additional RRC low-pass filter in front of the Polyphase 
clock-sync block?

- use firdes.pm_remez() ?



Thanks in advance,


Kr.

Re: Working Narrowband FM examples?

[Kristoff]

 the same samplerate.
Say you have an QT time-sink block with two inputs and the sample-rate 
at one is 1/5 of the sample-rate of the other input, add a 'repeat 5' 
block in front of that input to correct this!!!



Kristoff (on1arf)



(*1) https://greenteapress.com/wp/think-dsp/
(*2) https://pysdr.org/
(*3) 
https://www.youtube.com/playlist?list=PL0-GT3co4r2y2YErbmuJw2L5tW4Ew2O5B

(*4) https://www.youtube.com/watch?v=spUNpyF58BY
(*5) ttps://wirelesspi.com


On 10.08.21 02:05, Gary Schafer wrote:

Several points:

1) Further reading: "Digital Signal Processing" by Steven Smith and 
"Understanding Digital Signal Processing" by Rick Lyons. Smith makes 
his book available for download at https://www.dspguide.com/. Lyons 
has many of his stuff scattered around "DSPRelated.com" 
(https://www.dsprelated.com/). Unlike your usual textbooks, these 
books actually *EXPLAIN* stuff, not just throw some math proofs at you 
and say, "See how easy it is to understand?"


2) What hardware are you actually using? USRP? RTL-SDR? HackRF? 
Something else? I've found that the HackRF, while it covers a huge 
frequency range relative to most other inexpensive SDRs, it also has a 
much worse noise figure.


3) 384k wasn't too *low*. I was guessing it was just *outside* of what 
the hardware can handle. If the hardware *could* handle it, then you 
would not have had the issue you did. The RTL-SDR, for example, can 
only handle sample rates between 200 kHz - 300 kHz, then jumps to 0.9 
- 3.2 MHz. Anything outside of that range gets pushed to the closest 
sample rate the device can handle. The few times I've managed to play 
with a USRP, I've found that it can only handle sample rates that are 
values of 100 MHz / N, where "N" is an integer. As you discovered with 
whatever hardware you're actually using, if you use a sample rate that 
will work with the hardware, you can change it in Gnu Radio to 
whatever you *need* it to be.


4) I'm game for a comparison between GQRX and Gnu Radio. We need to 
make sure we have similar settings between them. I don't think the 
sample rate is the problem. So long as you're within the parameters 
that the particular SDR wants, AND you are meeting Nyquist, you should 
be golden.  To me, so long as you're using the same hardware, the 
critical aspects of comparing audio from an FM signal are ensuring we 
have the same filters and that we're using the same demodulator. I'm 
willing to bet large sums that the GQRX is using a polar 
discriminator. That's the same as the "Quadrature Demod" block in Gnu 
Radio. Easy enough. But what of the filtering? I can't see what 
parameters you've selected for your lowpass filter in your attached 
PNG (and, by the way, you get major kudos for including those... makes 
troubleshooting infinitely easier!) What are your stop frequency and 
transition width for your lowpass filter (used in your "Frequency 
Xlating FIR Filter")?


Gary

*

Well, I guess it was the sample rate. As another message alluded to, 
384kS/s seems too low.  I'm not sure why that is; the arithmetic with 
decimation ought to result in a 48kHz audio output either way, but 
(with assistance from Andre Buhart who replied off-list) I upped the 
sample rate to 2.4M and now I can make out the audio (flowgraph 
attached).



However, playing with the gain settings to make them identical to gqrx 
I noticed that, quite simply, the audio quality was just plain better 
in gqrx compared to gnuradio. So, investigating further it seems that 
the default sample rate for hackrf in gqrx is 8MS/s.



Now, being a novice to DSP and SDR I conclude from this that a higher 
sample rate simply results in a better quality signal at the front end 
of the, uh, block chain. That is to say at 2.4M or 8M, the osmocom 
source must be emitting a better signal which translates to a better 
audio product at the other side of the flowgraph.



However, my understanding is that a 48kHz audio signal is "good 
enough", so I'm a little mystified as to why 384kS/s, which is more 
than double what I want on the other side, results in such poor 
audio.  I hope I'm explaining that properly.



Can anyone point me in the right direction for further reading?

Thanks to all who responded thus far,

Nathan

On 8/5/21 4:10 AM, Mike Markowski wrote:

    You bet, Nathan.  I just verified that the flowgraph demods NWR, 
so either osmocom Source or Audio Sink needs configuring. You might 
try simply playing a recording into your audio sink.  It might be as 
simple as adjusting audio rate.  Regarding osmocom Source set up, 
another flowgraph for HackRF was mentioned in this thread, and you 
might compare that src setting to yours.  (Also, not sure why I had RF 
gain maxed. Better to lower that...)



    Good luck,
    Mike

FOSDEM 2021: Amateur-radio infobooth ... volonteers needed

[Kristoff]

Hi all,



As some people who where on GNU Radio hamradio meeting on Saturday are 
already aware, the first weekend of February (6/2 and 7/2) is FOSDEM 
2021, the "Free and Open-Source Developers European Meeting".


This event is one of the largest conferences in open-source (hardware, 
software, data, knowledge) development in Europe, and includes the "Free 
Software radio devroom" on Sunday.
Check out the talks here: 
https://fosdem.org/2021/schedule/track/free_software_radio/



However, FOSDEM in not only talks and devroom; it also includes a number 
of stands to promote opensource projects and the opensource culture. One 
of these stands is the "Infobooth on Amateur Radio" hosted by the UBA, 
the Belgian Amateur Radio Society.
The purpose of the Amateur-radio infobooth is to try to help bridge the 
amateurradio and opensource / developers / hackers / maker communities.
The goal is to demonstrate amateur-radio -as technical / scientific 
hobby that allows everybody to learn and experiment with radio and 
radio-communication- to the open-source community; and -at the same 
time- get more people from the amateurradio side to FOSDEM and show the 
advantages of open-source software, hardware and open knowledge and data.


As FOSDEM 2021 is an online-event, so is the infobooth; so everything 
will be done via online chat and videolinks.

Using the internet, the stand will show what it means to be a ham.
The FOSDEM organisation will help redirect (online) visitors of the 
FOSDEM conference (i.e. the talks and presentation) to the web / chat / 
video-content of the infostands; which will allow the stands to interact 
with the visitors.



Why am I writing this? .. Well, I am looking for volunteers who can help 
out (part of) that weekend.


The motto of the infostand this year is "a day in the life of a 
radio-amateur".
However, to make the FOSDEM web-presence more then just a website and a 
chat-server; we want to add live video-contents.


The idea is that you simply you do whatever part of the amateur-radio 
hobby you normally do that weekend (make radio contacts, do FT8 or JT9, 
receive images from the ISS, make a QSO over satellite, solder an 
electronics kit, ... whatever you like, .. perhaps even some GNU Radio 
things!!), and you provide a live video-feed of that.
This "video-stream" can be a camera in your shack, a screen-capture of 
your computer or a websdr, or .. -why not- a live video-stream while you 
are activating a SOTA summit.


This video-link will be streamed to a video-server, so that visitors to 
FOSDEM can 'hop in' to the stand, see what the amateur-radio hobby is 
about ("no, amateur-radio not just talking into a microphone"), and ask 
questions via chat and videochat.




But, wait, there is more.

As we now have this video-server, why not use it for some experiments 
ourselves?


image this: make a contact over radio and -at the same time- have a 
video-link over the internet to the station on the other side.
Have you ever wondered what really happens to your signal on the remote 
side when you change transmission power-level, your antenna or 
transmission mode of your station?

How is the FreeDV voice-call over HF is impacted by changing band?
Or would you like to know how your SSTV images over QO-100 get impacted 
by changing the mode?

This might be your chance!



So, are you available on the weekend of 6 and 7 February (between 9 AM 
and 4 PM UTC), and are you interested to help out to demonstrate 
amateur-radio to an audience that is actually interested in what you are 
doing (especially if it is geeky :-) ), please contact me.


I would need about 3 or 4 more people for each day, .. so any help is 
welcome!




(But don't forget to watch the presentation of the Free Software Radio 
devroom too! :-) )



73
kristoff - ON1ARF

Re: FLL Band-Edge

[Kristoff]

Hi Marc, Jeff, all


Thanks for your reply.
(Also thanks to everybody who replied off-list.)


Hum.. looks like a good mental overview of all the blocks useful for PSK 
would be good start for myself.



I did know about the "PLL Carrier-tracking block", but I had not yet 
heard of this "FLL band-edge block".


Doesn't a PLL also track the frequency of the source (in addition to its 
phase)?

So what would be the reason to use a FLL and not a PLL?


Kristoff


On 15/01/2021 9:56 a.m., Marcus Müller wrote:

Pretty much.

The FLL band edge system in GNU Radio does the following:

1. have a filter that extracts the energy "around the place where the
upper edge of where the signal is supposed to be", and around the lower edge
2. compares energies in both
3. multiplies the signal with e^jft, while adjusting the f until there's
equal energy in both edge filters.

The idea behind 2. is that you want your signal centered, smack in the 0
Hz middle of your baseband.

The principle in 3. is just a control loop to control the frequency shift

The approach for 1. is that it's mathematically very elegant to use the
derivative of the transmitter's pulse shaping filter. It still works
(though with higher variance) if you just use any symmetric low-pass
filter that lets through roughly the signal's bandwidth.

For more info, fred harris himself has done a presentation of FLL band
edge filters at GRCon'17[1], and you might find that enlightening. Note
that GNU Radio's FLL band edge is nowhere as smart – it doesn't do
anything with the phase information it could be getting, for free.

Best regards,
Marcus

[1] https://www.youtube.com/watch?v=Zmjk9NE-3k0

On 15.01.21 02:33, Jeff Long wrote:

I think the general idea is that some signals have no carrier that a PLL
could lock onto. The FLL Band-Edge centers a signal using the shape of a
specific signal (the matched filter being used).

On Thu, Jan 14, 2021 at 6:55 PM Kristoff mailto:krist...@skypro.be>> wrote:

 Hi all,


 I have been reading some more on PSK demodulation.


 One of the PSK signals I can easily pick and and is available
 24h/day is
 the telemetry signal on QO100.
 I found a flowgraph from Daniel Estevez that decodes the QO100
 telemetry, so I started examining how it works.

 In that flowgraph (which for some reason I do not seams to find any
 more), the first block in the flow (i.e. right after downconverting and
 a AGC) is a "FLL_Band-edge" block.


 Can somebody explain what exactly this block does?

 I researching this, I found that it seams to shift the received signal
 slightly up in frequency (at least, that is what it did in my tests).

 I tried reading the documentation, which kinds-of explain how it does
 work, .. but not what it does and why it is there.
 Can somebody explain the purpose of a "FLL with band-edge filter" block?



 Thx :-)

 73
 kristoff - ON1ARF

FLL Band-Edge

[Kristoff]

Hi all,


I have been reading some more on PSK demodulation.


One of the PSK signals I can easily pick and and is available 24h/day is 
the telemetry signal on QO100.
I found a flowgraph from Daniel Estevez that decodes the QO100 
telemetry, so I started examining how it works.


In that flowgraph (which for some reason I do not seams to find any 
more), the first block in the flow (i.e. right after downconverting and 
a AGC) is a "FLL_Band-edge" block.



Can somebody explain what exactly this block does?

I researching this, I found that it seams to shift the received signal 
slightly up in frequency (at least, that is what it did in my tests).


I tried reading the documentation, which kinds-of explain how it does 
work, .. but not what it does and why it is there.

Can somebody explain the purpose of a "FLL with band-edge filter" block?



Thx :-)

73
kristoff - ON1ARF

Re: GNU Radio on Raspberry Pi 4?

[Kristoff]

Albin,


Can you share your configuration for this? Do you need to set up 
something special?
Can you do this on standard ubuntu 64 bit (20.04LTS or 20.10) on a pi4b 
or do you need another distro for this?



I read somewhere opengl on the pi4 has not been released yes as it has 
the pi4 has a more recent GPU.

Or am I completely wrong?


73
kristoff - ON1ARF


On 17/12/2020 1:22 p.m., Albin Stigö wrote:
I suspect a lot of the graphics could run perfectly fine if they took 
advantage of the gpu better. A lot of the current rendering in 
GNURadio (and GQRX) is very cpu bound.


I had a spectrum and waterfall running easily at 60fps on a pi3 by 
using opengl properly. Using vulkan on pi4 the sky is the limit.


--Albin

On Thu, Dec 17, 2020, 13:18 Marcus Müller <mailto:muel...@kit.edu>> wrote:


Can't stress this enough. Running a 32 bit Linux on a RPi 4 would be
like running Windows 98 on a modern PC and expecting top performance
from the CPU. You're not making use of the CPU you have, you're only
making use of a legacy mode that it still supports.

Best regards,
Marcus

On 17.12.20 10:53, Albin Stigö wrote:
> 64bit mode is most likely better because in addition to being
64bit it
> enables additional cpu features (certain new instructions and
more SIMD
> NEON registers)
>
> On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-st.fr
<mailto:jean-michel.fri...@femto-st.fr>
> <mailto:jean-michel.fri...@femto-st.fr
<mailto:jean-michel.fri...@femto-st.fr>>
mailto:jean-michel.fri...@femto-st.fr>
> <mailto:jean-michel.fri...@femto-st.fr
<mailto:jean-michel.fri...@femto-st.fr>>> wrote:
>
>     The benchmark on volk/64 bit kernel v.s 32 bit Raspbian is at
> https://pubs.gnuradio.org/index.php/grcon/article/view/73/55
>     <https://pubs.gnuradio.org/index.php/grcon/article/view/73/55>
>     last page. I get 3 to 7-fold improvement by volk_config on a
dedicated
>     toolchain for 64-bit CPU.
>
>     JM
>
>     --
>     JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe,
25000
>     Besancon, France
>
>     December 17, 2020 10:28 AM, "Kristoff" mailto:krist...@skypro.be>
>     <mailto:krist...@skypro.be <mailto:krist...@skypro.be>>> wrote:
>
>     > HI all,
>     >
>     > I also have a RPi4 (*).
>     > Some follow-up question.
>     >
>     > What OS would be the best for this?
>     > Would running 64 bit make a difference?
>     >
>     > I don't know to what degree this is related, but I did a
test running
>     > WebGL (**) on that pi, and I got about 1/3 of the frames per
>     second on
>     > my RPi4 compared to my laptop (which only has a UHD
Graphics 630
>     Mobile,
>     > so not the  best or latest neither)
>     > Is the GPU in the Pi4 good enough to run many GUI elements
in GNU
>     Radio
>     > at the same time?
>     >
>     > Kr.
>     >
>     > (*) RPi4B 8 GB, 120 SSD
>     >
>     > (*) https://webglsamples.org <https://webglsamples.org>
>     >
>     > On 16/12/2020 11:10 p.m., Dan Romanchik KB6NU wrote:
>     >
>     >> Has anyone successfully run GNU Radio on a Pi 4? I
recently purchased
>     >> an RTL-SDR dongle and thought it would be fun to
experiment a little
>     >> with GNU Radio and learn something about SDR.
>     >>
>     >> A couple of days ago, I fired up GNU Radio, and after
having some
>     >> trouble figuring out how to get the audio sink to talk to
the Pi, I
>     >> downloaded VE6EY's FM receiver flow graph. The flow graph
runs, but
>     >> the Pi 4 just doesn't seem to have enough horsepower to
run it in
>     real
>     >> time. The audio is slow and distorted.
>     >>
>     >> Thinking that it might be the WX widgets slowing down the
program, I
>     >> first deleted the FFT display widgets, then converted the
WX slider
>     >> controls to QT range controls. Neither had any effect on
how well the
>     >> flow graph ran.
>     >>
>     >> GQRX and CubicSDDR seem to work just fine. At least with
both of
>     them,
>     >> I'm able to receive FM broadcast and NOAA weather
station. But, maybe
>     >> the PI4 just doesn't have enough horsepower to run GNU
Radio? If so,
>     >> that's kind of disappointing.
>     >>
>     >> 73! <—ham radio lingo for “best regards"
>     >>
>     >> *Dan KB6NU*
>     >> CW Geek, Ham Radio Instructor
>     >> Author of the "No Nonsense" amateur radio license study
guides
>     >> Read my ham radio blog at http://www.kb6nu.com
<http://www.kb6nu.com>
>

Re: GNU Radio on Raspberry Pi 4?

[Kristoff]

HI all,

I also have a RPi4 (*).
Some follow-up question.

What OS would be the best for this?
Would running 64 bit make a difference?

I don't know to what degree this is related, but I did a test running 
WebGL (**) on that pi, and I got about 1/3 of the frames per second on 
my RPi4 compared to my laptop (which only has a UHD Graphics 630 Mobile, 
so not the  best or latest neither)
Is the GPU in the Pi4 good enough to run many GUI elements in GNU Radio 
at the same time?



Kr.


(*) RPi4B 8 GB, 120 SSD

(*) https://webglsamples.org/


On 16/12/2020 11:10 p.m., Dan Romanchik KB6NU wrote:


Has anyone successfully run GNU Radio on a Pi 4? I recently purchased 
an RTL-SDR dongle and thought it would be fun to experiment a little 
with GNU Radio and learn something about SDR.


A couple of days ago, I fired up GNU Radio, and after having some 
trouble figuring out how to get the audio sink to talk to the Pi, I 
downloaded VE6EY's FM receiver flow graph. The flow graph runs, but 
the Pi 4 just doesn't seem to have enough horsepower to run it in real 
time. The audio is slow and distorted.


Thinking that it might be the WX widgets slowing down the program, I 
first deleted the FFT display widgets, then converted the WX slider 
controls to QT range controls. Neither had any effect on how well the 
flow graph ran.


GQRX and CubicSDDR seem to work just fine. At least with both of them, 
I'm able to receive FM broadcast and NOAA weather station. But, maybe 
the PI4 just doesn't have enough horsepower to run GNU Radio? If so, 
that's kind of disappointing.


73! <—ham radio lingo for “best regards"

*Dan KB6NU*
CW Geek, Ham Radio Instructor
Author of the "No Nonsense" amateur radio license study guides
Read my ham radio blog at http://www.kb6nu.com

Re: some feature-requests for GRC

[Kristoff]

Barry,




On 14/11/2020 21:02, Barry Duggan wrote:


Hi Kristoff,

Regarding your item 4, it may not be obvious (as it wasn't to me as a 
newbie) that the Properties -> Advanced -> Comment field allows large, 
multi-line comments for *all* blocks. So for a Note block, the "Note" 
title is limited to about 18 characters before it starts getting 
truncated, but the Comments can be very large. The comments will only 
show on the flowgraph if the View -> Show Block Comments is checked.


Ah... Didn't know that.

Another useful hint!


Thanks! :-)



73,
---
Barry Duggan KV4FV
https://github.com/duggabe


73

Kristoff - ON1ARF

Re: some feature-requests for GRC

[Kristoff]

Hi Jeff,






For item 1 and 2.

Yep. I just did some more tests and I agree. I think I will just create 
one giant tarball with all the GRCs, i/q files and perhaps other stuff, 
and then run grc with the names of all the *grc-files. That should do 
the trick.


Good idea. Thx!



For item 3, well I did say that was probably the most difficult thing, 
didn't I? :-)


I got my idea based on how the 'start' button operates in GRC.
That button is only enabled if the flow meets certain criteria. There 
seams to be some kind of test that is done every time you change the 
flowgraph, which enables or disabled the start button,



I do not know the coding logic behind gnuradio-companion, not what gtk 
can provide for this, but I was wondering if this idea could also be 
applied the same logic to a complete tab: do a test and -if it fails- 
disable the flowgraph in that tab. (i.e. hide or disable all blocks)



But, I guess this would require two additional elements:
- the test will need to be based on rules that are provided by the flowgraph
- the test should be able to access resources from tabs. (e.g. the test 
for "tab2" could be "tab1.var.sampl_rate.value == 1200")


As said, I have never worked with gtk, so I have no idea if this is 
possible.



Just out of interest.
How to the test to determine if the 'start' button is enabled actually work?
I guess there must be some mechanism that parses the structure of the 
flow-graph and then perform some tests on that to check if it is ok?




Note, please do not  get me wrong. I do not want to be 'pushy'. I'm just 
trying to view this from an "education" point of view.


I have now given a number of GNU Radio demo's. I started out with 
"standard" presentation: I-as presenter-  demonstrate a GNU Radio flow 
and that the audience just needs to "watch and understand".
All very nice, except that, ... most people had already forgotten almost 
everything 5 minutes after the demonstration had ended. If people do not 
need to do or think themself, they are simply not sufficient engaged and 
-although they do get an idea of GNU Radio can do- the actual process of 
creating a flow-graph does not stick.
That is why I started looking into CTFs and now also this 
"getting-started" workshop.


So, let's then conciser a "howto" or a "workshop" that people can do by 
themself by downloading it from the web, things become even more 
difficult as there is not even a teacher to help them.
If you create a "howto" and just provide people with a number of 
flow-graphs, even a separate GRC for every step, I see very little 
incentive for people not immediately go to the final GRC and try at the 
end-result as soon as they hits a snag.
For that reason, I am more a fan of the model of -say- jupyter notebooks 
where people are forced to follow the complete flow of the training,  
step by step,  and cannot just jump to the end of the training.


So, in fact,  I am trying to figure out who to create the forced 
step-by-step learning model of a jupyter notebook, using GRC.





Concerning item 4:
Is it possible in gtk that, if a part of the text in a note-block is a 
URL (https://...), that GRC would starts a web browser if people click 
on it?


It would be nice to be able to incorporate external references (e.g. a 
video) in the notes of a flow-graph.




73
kristoff - ON1ARF



On 14/11/2020 17:21, Jeff Long wrote:

Looking for the simplest (maybe not the best) solution:

Item1 - A shell/batch script could run gnuradio-companion 1.grc 2.grc 
3.grc


Item 2 - files can be relative, e.g, ./sample.iq <http://sample.iq>. 
So, if you tar or zip the grc files and the sample files, everything 
should be runnable from a single directory, no searching around required.


Item 3 - I think this is pretty far out of scope for GRC.

On Sat, Nov 14, 2020 at 11:15 AM Kristoff <mailto:krist...@skypro.be>> wrote:


HI all,

Yesterday-evening, we did a small workshop 'getting started to GNU
Radio
for CTFs', to 'kickstart' some people using GNU Radio.


Afterwards, I was thinking that workshops do take up quite a bit of
time, and not every student has time to do a workshop during the
timeslot that is there is a teacher available; so perhaps we can
also do
this in another way.

One thing -I think- would help for this, is the possibility to create
'interactive getting started guides' for GR. That way, we should
be able
to reach more people.

The idea I have in mind is to create 'interactive learning-flows'. To
allow people to learn GNU Radio -step by step- how to use GRC, how to
analyse a CTF, how to create signals, ...


The model is a 'learning-flow', a course is divided into multiple GRC
flow-graphs, and where every 'tab

some feature-requests for GRC

[Kristoff]

ly possible to add the 
kind of comments (see 3/ above) to the graph.


What would also be nice is the ability to add URLs in the note blocks.
This would allow the note to link to -say- a video: " Change the 
datatype of the file-source block to the correct setting. Click here for 
a video on the different data-types used in GNU Radio"




I know that some of these feature-requests are probably not that easy.
But as the quite steep learning-curve of GNU Radio is the main reason 
people are scared away from GR, I do think that providing a good 
learning-tool can be one of the best ways to get the, over that hurdle.




73

kristoff - ON1ARF

Re: explaining i/q

[Kristoff]

Don,


A small (slightly) remark about this video, and about hams.

When I gave my first video-presentation for the Belgian SDR Meetup (in 
September), I have a presentation on GR (an example of an RTTY decoder).
But, to keep the presentation on topic, I first posted a "list of 
interesting things to view so you can better understand the 
presentation" (the video you mentioned, three of the videos by Michael 
Ossmann, ...).


When I asked the audience during the presentation who had taken the time 
to actually do this, I did not get any positive answers.


You know,, ...last time when we did a workshop in a hackerspace on a 
certain topic and asked the people to do some preparation, I think that 
more then 3/4 did do that.

The same when I organise a workshop at work.


Yeah ... Hams .. (sigh) :-(



73
kristoff - ON1ARF


On 4/11/2020 15:22, Don Wade wrote:
Here’s a YouTube video that’s got a bit of pencil math (so it doesn’t 
drone on) and oscilloscopes (for the ham guys), so it’s got a bit for 
everyone .


https://m.youtube.com/watch?list=PLvOgjCaG0WzDAF1Um894vv95mrcyortOB&v=h_7d-m1ehoY


On Nov 4, 2020, at 7:52 AM, Kristoff  wrote:

Jef,


Concerning the term "slope". Well, I also have my doubts about it. I 
think that for a lot of people, this would create the assumption that 
the signal then goes from the 'i' value to the 'q' value in a 
straight line, which is -as we know- not the case.


Sometimes it helps to -at first- give a very basic mental image of 
something, and -at the end, when people understand the topic- 
"correct" that image with a more correct one, or just point them to 
some youtube video that explains the topic in more detail.



Anycase,this is indeed all an interesting exercise in braking down 
concepts into very small steps.


The amateur-radio community is a bit strange as most people do have a 
technical background, but for a large number of hams, that is mainly 
based on assumptions or "that's what they said in the ham-radio 
courses", without understanding the full technical details, 
especially topics that are highly based on math.
For most hams, "SDR" is just "that piece of software you install on 
your computer to look at  waterfall graphs".


So we have a very long way to go. :-)


73
kristoff - ON1ARF



On 4/11/2020 02:21, Jeff Long wrote:
It's more important to give people some mental picture than to make 
sure it's completely correct. But, I would not use the "slope" 
terminology. The important things are, as you've said, (1) with the 
complex type, you can have a signal at baseband that is not 
symmetric, and (2) the price for this is doubling the amount of data 
needed. The signal you deal with at baseband is the same signal that 
is seen centered on the RF carrier.


I don't see a great way to talk about "phase" without going into the 
math. It is important to get into "phase" when you talk about any 
modulation fancier than slow FSK.


Good luck. Hope you find the right balance between useful, 
digestible, and correct.


On Tue, Nov 3, 2020 at 7:20 PM David Hagood <mailto:david.hag...@gmail.com>> wrote:


   I am sorrowful that you have decided you are going to stick with an
   explanation that is fundamentally incorrect. I know how direct
   conversion systems work - I design the software for them for a
   living.
   What you are basing your mental model on is an optimization for
   the case
   where the system is both sub-sampling the signal and going digital in
   the same operation. However, in many extremely high sample rate
   systems,
   the signal is brought down to baseband by mixing it with analog
   quadrature signals - that's the place where I and Q come from - and I
   assure you the only "delay by 90 degrees" is in the creation of the
   quadrature LO signals, not in the sampling of the actual data. But
   I've
   been around the Sun enough times to know that since you have decided
   upon this course and don't seem to want to change, there's no
   point in
   continuing to try to help.

Re: explaining i/q

[Kristoff]

David, all,


Well, I had also been thinking about this.

I do like the idea of the spinning doll. It provides a model for 
positive and negative frequencies: if it spins one way, the frequency is 
positive, if it spins in the other direction, it is a negative frequency.


And, it does also give a 'hint' at the issue that a frequency in the 
"real" domain is both a positive and a negative frequency in the complex 
frequency domain>




However, the problem is that people associate "spinning" with movement, 
i.e. a change of the location of an object in time, or -in this case- a 
rotation around an axis -which also includes an element of time-.


Now, unless I am completely wrong, the model you use captures both the I 
and the Q samples at the same time. This means that there is no element 
of 'time'.
In electronics, this works fine, due to the nature of mixing and a 
difference of phase of the two Local-Oscillators.
But that's not how people see the spinning doll. Our eyes do not see a 
difference in phase of light. For us humans, the object is spinning due 
to the element of "time": multiple observations.



For us, "even if we would be able to look at a rotating object up-front 
and from a 90 degrees angle at the same time, if the object would be 
frozen in time we would still not be able to determine if the doll 
rotates left of right".
(except perhaps that we will probably make a assumptions as the doll 
leans slightly backwards). (*)


(*) https://en.wikipedia.org/wiki/Spinning_dancer



Now, I completely agree that the model I used (taking two samples, 1/4 
sample-period apart), is indeed based on only one of the architectures 
of a SDR-receiver.  And, yes, other SDR receiver architectures exist 
that are not based on that model. But at least it provides something 
that is not that far from our daily experience: detecting the direction 
of a movement by two observations at difference times.


Small sidenote:
That particular receiver-architecture does happen to be one that is used 
in most amateur-radio DIY receiver-kits. So if a student of the workshop 
gets to see a schematics of an SDR receiver- it IQ mixing-part should at 
least ring a bell.




Anycase, don't get me wrong. I really appreciate your feedback.

What you say is completely correct.
The question however is how to "package" your model into something that 
is easy to understand.




73
kristoff - ON1ARF



On 4/11/2020 02:58, David Hagood wrote:

Like I said previously:

Think of the spinning dancer illusion. It works because you only see 
from one vantage point. If you saw a real doll spinning, and assuming 
you have two eyes and normal binocular vision, you will have parallax, 
and that will allow you to determine in reality which way the figure 
is spinning, because each eye will have a different view of what is 
going on, and so can work out what direction the figure is spinning in.


I/Q is like that - it allows the SDR to see have "parallax" - to have 
2 points of view on the signal at the same time, and so it can "see" 
which way the signal is rotating - whether the signal is spinning 
clockwise (negative frequencies, cause math) or counter-clockwise 
(positive frequencies).


There - no advanced math, short, and yet accurate.

Re: explaining i/q

[Kristoff]

Jef,


Concerning the term "slope". Well, I also have my doubts about it. I 
think that for a lot of people, this would create the assumption that 
the signal then goes from the 'i' value to the 'q' value in a straight 
line, which is -as we know- not the case.


Sometimes it helps to -at first- give a very basic mental image of 
something, and -at the end, when people understand the topic- "correct" 
that image with a more correct one, or just point them to some youtube 
video that explains the topic in more detail.



Anycase,this is indeed all an interesting exercise in braking down 
concepts into very small steps.


The amateur-radio community is a bit strange as most people do have a 
technical background, but for a large number of hams, that is mainly 
based on assumptions or "that's what they said in the ham-radio 
courses", without understanding the full technical details, especially 
topics that are highly based on math.
For most hams, "SDR" is just "that piece of software you install on your 
computer to look at  waterfall graphs".


So we have a very long way to go. :-)


73
kristoff - ON1ARF



On 4/11/2020 02:21, Jeff Long wrote:
It's more important to give people some mental picture than to make 
sure it's completely correct. But, I would not use the "slope" 
terminology. The important things are, as you've said, (1) with the 
complex type, you can have a signal at baseband that is not symmetric, 
and (2) the price for this is doubling the amount of data needed. The 
signal you deal with at baseband is the same signal that is seen 
centered on the RF carrier.


I don't see a great way to talk about "phase" without going into the 
math. It is important to get into "phase" when you talk about any 
modulation fancier than slow FSK.


Good luck. Hope you find the right balance between useful, digestible, 
and correct.


On Tue, Nov 3, 2020 at 7:20 PM David Hagood <mailto:david.hag...@gmail.com>> wrote:


I am sorrowful that you have decided you are going to stick with an
explanation that is fundamentally incorrect. I know how direct
conversion systems work - I design the software for them for a
living.
What you are basing your mental model on is an optimization for
the case
where the system is both sub-sampling the signal and going digital in
the same operation. However, in many extremely high sample rate
systems,
the signal is brought down to baseband by mixing it with analog
quadrature signals - that's the place where I and Q come from - and I
assure you the only "delay by 90 degrees" is in the creation of the
quadrature LO signals, not in the sampling of the actual data. But
I've
been around the Sun enough times to know that since you have decided
upon this course and don't seem to want to change, there's no
point in
continuing to try to help.

Re: explaining i/q

[Kristoff]

David,



On 4/11/2020 01:18, David Hagood wrote:
I am sorrowful that you have decided you are going to stick with an 
explanation that is fundamentally incorrect. I know how direct 
conversion systems work - I design the software for them for a living. 
What you are basing your mental model on is an optimization for the 
case where the system is both sub-sampling the signal and going 
digital in the same operation. However, in many extremely high sample 
rate systems, the signal is brought down to baseband by mixing it with 
analog quadrature signals - that's the place where I and Q come from - 
and I assure you the only "delay by 90 degrees" is in the creation of 
the quadrature LO signals, not in the sampling of the actual data. But 
I've been around the Sun enough times to know that since you have 
decided upon this course and don't seem to want to change, there's no 
point in continuing to try to help.



As mentioned, the goal here is to explain I/q sampling in 5 minutes to a 
group of average hams (i.e. who have limited knowledge of advanced 
electronics and even less of math).

The question to answer is this:
what is i/q sampling and why does it it matters for him/her when 
creating a GNU Radio flowgraph.



So, you do not have to convince me how i/q sampling works, you have to 
convince this audience.



So, feel free to explain in semi-tech (no math) talk in 5 minutes *why* 
SDR uses i/q sampling.

What is the PURPOSE of i/q sampling?



73
kristoff - ON1ARF

Re: explaining i/q

[Kristoff]

Jef, Fabian, Aditya, Anon, David,

I'll just reply to this one message so not to spam the list to much but 
please consider this a "thank you" to all for replying.



As said, this is for a limited and very specific goal:
I will probably be giving a workshop on GRC in a couple of weeks and I 
want to give a quick explanation of iq-sampling and how this impacts 
designing a GR flowgraphs.



I want to keep the workshop focused on that one topic. So I really want 
to avoid going "wondering around" trying to explain everything that is 
related to DSP or SDR. After all, it's a workshop on using GRC, not a 
generic presentation on SDR or signal-processing.



The reason I do want to mention iq sampling in the workshop, is simply 
that does is one of the basic datatypes of GNU Radio and it is an 
important element that affects how to build a flowgraph.



I think I will summarise it like this:

* complex numbers is one of the datatypes of GR, It is the format to 
store signals generated by a process called "i/q sampling".


So, what is iq-sampling?
IQ-sampling is like sampling a normal ("real") signal -i.e. what most 
people are familiar with-, ... except that you sample the data twice for 
each period: once at timer "t" and a second time 1/4 sampling period 
later. (*)


This 2nd sampling-action provides information about the 'direction' a 
signal is going (up or down). (I think the proper term here is its 'slope')

(thx David for the correction about 'phase' vs 'slope')

(*) Just look at the design of a direct-conversion SDR receiver.

The first sample is called the "in phase" sample, the 2nd sample is the 
"quadrature" sample; hence "i/q" sampling.



* as was also mentioned by Heather in the RSGB/BATC presentation, the 
use of iq-signals has a number of consequences on GNU Radio flow-graphs.

The most important ones are:

->  Mixing two complex signals (with a frequency of "f1" and "f2") will 
produce one new signal with a frequency of f1+f2 Hz.


This is in contrast to a mixer of "real" signals which -as most people 
know- produces two new signals (frequencies: f1+f2 and f1-f2)



-> In the "real" frequency-domain, only the frequencies from 0 up to 
sampling-rate / 2 is defined. The frequencies below zero are a mirror of 
the radio-spectrum above DC.


Using complex i/q sampling, both positive and negative frequencies exist 
and are independent of each other.



-> A signal with a "negative" frequency?
Yes, a complex signal can have a 'negative' frequency. This is basically 
the same as a signal with the equivalent positive frequency, but 
mirrored around the x-axis (**).


If you look at such a signal, you see that flipping a signal upside down 
will  inverse the sign of the value of every sample (something that does 
affect the value of the signal, but no its frequency), ... and inverse 
the "direction" of that signal.
And remember that the goal of i/q sampling is ...  to determine the 
direction of a signal?


(**) note: there do are other ways to negate the frequency of a complex 
signal.



-> Combine the two last points, and you get this:

If you mix (multiply) an incoming signal with frequency "f1" with a 
second signal that has a negative-frequency "-f2" will generate a new 
signal with a frequency of f1-f2, effectively moving a signal down in 
the radio-spectrum. (i.e. 'down-converting')



* And finally, ... certain hardware peripherals deals with 'real' 
signals (e.g. an audio-card or a speaker), other hardware create or read 
complex 'iq' signals (like most dedicated SDR peripherals)





Again, the goal is not a full detailed discussion about I/Q signals.
The goal is to give people who are not to SDR, new to GNU Radio and have 
never heard of i/q sampling before some idea of what it is, and how it 
will impact them when they start playing around with GRC.


But I do want my information to be factual correct, so .. if somebody 
sees factual errors in this, feel free to reply! :-)





73
kristoff - ON1ARF




On 3/11/2020 12:47, Jeff Long wrote:
This is a great thing to try to figure out. If we can come up with an 
answer that gives someone a feel for why I/Q is used in SDR in 10 
minutes, and does not include phasors, exponentials to a complex 
power, a derivation of any equation, the concept of orthogonality, 
etc. ... it will win a Nobel prize in education.


On Tue, Nov 3, 2020 at 4:56 AM gilles rubin <mailto:rubingil...@yahoo.com>> wrote:


Hello,

You can have a look here
The Concept of Frequency | Wireless Pi
<https://wirelesspi.com/the-concept-of-frequency/>


    


The Concept of Frequency | Wireless Pi

<https://wirelesspi.com/the-concept-of-frequency/>

Qasi

explaining i/q

[Kristoff]

Hi all,

I was watching the webinar of Heather on GNU Radio today, when it came 
to me that one of the most difficult part doing a presentation of GNU 
Radio is the data-types, .. and especially these 'complex numbers'.
The problem, or at least for me, is that when you mention 'GNU Radio 
complex numbers', you also have to mention iq-signals, which is a topic 
that is very difficult to explain in 10 seconds to an audience who has 
never seen anything about i/q sampling before.



I have been thinking on how to explain the concept of I/Q signalling in 
just a few lines, e.g. in the context of -say- a workshop on GR.



I have this idea in my head:

Statement:
The main difference between sampling with reals ('floats') and i/q 
sampling with complex numbers, is that the latter does not only provide 
the  instantaneous value (voltage) of a signal at a certain point of 
time, but also includes phase information (i.e. the slope of the signal 
at that point).



To make this visual:
Take half a sine-wave and plot it out for every 45 degrees.
This gives you 5 points: 0 (0 degrees), sqrt(2)/2 (45 degrees), 1 (90 
degrees), sqrt(2)/2 (135 degrees) and 0 (180 degrees).


Now look at the 2nd and the 4th point (45 degrees and 135 degrees), if 
you sample this using only real/float values, these two points are 
exactly the same (sqrt(2)/2). Just based on these values by themselves 
(i.e. remove all other points from the graph), there is no way you can 
tell that at the first point (45 degrees) the graph was going up, while 
at the 135-degrees point the graph was going down.


So, ... what i/q sampling does, is for every point "x", it not only 
provide the value of the graph at that point of time, but also 
information of the slope of the graphs at that time.



This also explains while i/q sampling is done by not just taking the 
value of a signal at point "t", but also at 1/4 period later (which is 
the information you need to determine the 'slope' of that graph at point 
't')



So, ... is this statement correct?

If it is more-or-less correct and it can help provide a basic mental 
image of the concept of i/q sampling, I would be more then happy! :-)





73
kristoff - ON1ARF

Fwd: [Sdrbelgium] 3th UBA Belgian SDR meetup: Friday 30/10/2020

[Kristoff]

Hi all,



This Friday (30/10), we will organise the 3th Belgian (online) UBA SDR 
meetup via jitsi.


Please find below the announcement for the event.

Note that times in the message are below are local Belgian time (CET), 
so the meetup starts at 19:00 UTC. The presentation of the two CTFs and 
"the elektor SDR shield: exploring a very basic SDR receiver" start at 
19:30 UTC.


The URL of the jitsi meeting is:
https://meet.jit.si/UBABelgianSDRMeetup



73
kristoff - ON1ARF

 Forwarded Message 
Subject:[Sdrbelgium] 3th UBA Belgian SDR meetup: Friday 30/10/2020
Date:   Mon, 26 Oct 2020 23:43:06 +0100
From:   kristoff Bonne via Sdrbelgium 
Reply-To:   kristoff Bonne 
Organization:   me organized?
To: sdrbelg...@lists.uba.be 



Hi all,


Please note that this Friday, 30 October, the 3th UBA Belgian (online) 
SDR Meetup will be organised.



As the previous meetups, the event will be held online (jitsi link, see 
below), starting at 20h00.


The agenda is as follows:
- Question & Answer round:
This allows everybody to ask questions on SDR, show of any SDR related 
projects you are working on, or just introduce yourself.


- The solution of the two CTF challenges.

- A small presentation of the 'Elektor SDR shield' project.

What have we learned sofar? How well does it work?
How does SDR receiver hardware actually work and what are the pitfalls?

- Time permitting, we can have a free discussion afterwards on any SDR 
related topic.




Like last time, the Meetup starts at 20:00. The presentations start 
around 20:30 and should be finished between 21:30-22:00


The URL of the jitsi meeting is:
https://meet.jit.si/UBABelgianSDRMeetup



73
kristoff - ON1ARF

--
Sdrbelgium mailing list
sdrbelg...@lists.uba.be
http://lists.uba.be/cgi-bin/mailman/listinfo/sdrbelgium

Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

[Kristoff]

Hi Markus, Edmar, Barry, all,


Sorry for the late reply (you know .. weekend),


Yes, I think it will be interesting do have a small video-chat on this 
subject.


I have the impression that everybody who is looking into getting more 
radio-amateurs into SDR seams to have a similar issue.
At first, it looks to be "doable" if you orient the classes towards the 
top 5 % hams that have a background that is compatible with looking at 
electronics as signals and as mathematical formulas, but -indeed- it 
becomes a lot more difficult to create a course for 'the average OM' 
especially as amateur-radio has always been a lot more about 
experimentation then 'detailed theory'.


Perhaps the most easy option is  now to do something for the former 
group and work from there on.


Concerning the difference between ham-radio courses and the academia. I 
agree with your analysis but I think we do need to keep in mind that not 
only the audience is very different, but also the goal. After all, our 
goal is (I think) to get more hams to understand SDR. It is not to train 
people to become telecom-engineers that are able to design 5G modems. :-)




Two more remarks:

- one think I do think that can help is a 'self-learning path' for 
people who want to learn by themself.


There is a lot of information on the internet about signal-processing, 
DSP and SDR (free and paying), and -based on the answers I got on the 
questionnaire I did in the SDR Belgium list- people who do are 
interested in these subjects do find them quite useful. So there might 
be no need to 'reinvent the hot water' (as they say in Dutch)



That's also how I got started.
I wanted to understand the code of Jonathan G4KLX from his pcrepeater 
project, so I needed a book on DSP to understand the code for the LPFs. 
I started with the dspguide (http://dspguide.com) and then the RIchard 
Lyons book. Next up where the 'SDR with the HackRF' videos by Michael 
Ossman, and I now going through the 'wireless-pi' course by Qasim 
Chadhari (when I have time for it).


I have a list of interesting resources (*), but I do think that a more 
structured 'path' can be quite useful for people.
This applies for people starting out with SDR, or people who have done 
your 'hamradio course' of SDR and want to really go further in this topic.



(*) https://github.com/on1arf/sdr/blob/master/links.md


- another element that can help is getting more people to use GNU Radio, 
just as an educational tool.


I once used GNU Radio to demonstrate how you can 'filter a signal out of 
noise' (like WSPR, FT8, ... do) by 'averaging out' the noise during out 
weekly jitsi-session of our local radioclub.
There is a very good video of Tom Rondeau explaining convolution and 
matched filters at TAPR 2012, using GNU Radio as a visual educational 
tool (*)
It's not about the visual / educational element itself. It also makes 
GNU Radio better known by both the students and the teachers (even 
outside the context of SDR), and let them appreciate the tool.


So it might be just as important to teach the trainers of the 
amateur-radio courses to use the tools out there that can really help 
them to explain things to their students, including GNU Radio. (**)



(*) https://youtu.be/cg3TA3EDx78?t=119
(**) Note that this does only apply to GNU Radio, but also 
antenna-simulation / visualisation tools, math tools like 
octave/scilab/scipy/numpy, or the "falstad" online circuit analysis: 
https://www.falstad.com/circuit/




Anycase,
I am very interested in the details your course on SDR and your plans on 
how to do this practically.
Is this a pure 'class' course or a workshop? How many hours of study 
would be needed for this?


So, if you would plan to do a video-conference on this topic, I think 
there would be quite some interest by some people I know on this topic.





73
kristoff - ON1ARF



On 26/09/2020 12:17, Markus Heller wrote:

Dear list,

here in Germany we've been working on a standard class to teach SDR to
radio amateurs. We see that the learning path is quite steep for the
ordinary OM.

In the academa you have several semesters time to learn everything you
need, including complex maths. But the ordinary OM has very little time
compared to a student, and moreover, we don't want to forget those who
do not have an academic background. And yes, theree are many who are
interested in SDR but are not proficient in English (same in Belgium,
I've been discussing this with Kristoff). Probably this also applies to
many other countries. So generally I'm glad we have a common language
here.

There is not much that speaks against preparing a standard class in
other languages as well. Here is our structure:

1.) Digital Signal Processing (introduction)
2.) Maths, operations on complex numbers
3.) GNURadio introduction
4.) NumPy, SciP

agc setting in osmocom source + rtl_tcp

[Kristoff]

Hi all,


I am using the osmocom source block with a remote rtl-sdr v3 dongle in 
direct mode (i.e. using rtl_tcp on a remote linux device).




Is there an easy way to configure "agc = 1" on the remote device using 
this setup?


As I use the dongle in direct mode, the normal 'gain' setting is ignored 
so the only option to get a descent signal-level at low frequencies is 
by enabling the agc.
But neither the osmocom source block as the rtl source block have an 
option to enable the agc.


Anybody any idea on how to do this?
(except patching rtl_tcp on the remote side)

Kristoff (on1arf)

Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

[Kristoff]

f possible 
teaching to radio amateurs) to help me with that.






I really like GNU Radio and I think it by far the best tool to get 
people to learn about signals, .. but it is important that people do it 
step by step and do not understand that they will be able to decode some 
random PSK-signal  by just connecting some blocks together in GRC!




If you plan to start the new mailing-list, please let me know as I am 
really interested!



73
kristoff - ON1ARF




On 24/09/2020 22:53, Barry Duggan wrote:


Hi kristoff,

Thank you for your thoughts. I am curious about your saying that "I 
have been hesitant to post here in the GR list as it's more about 
signal-process then about GNU Radio." Have you tried and not gotten 
good responses, or have you just assumed it was not the appropriate 
place? I hope we have not discouraged people from asking valid 
questions here.


As an alternate to creating another mailing list, we have a Ham Radio 
chat room which grew out of a GRCon20 Breakout session. It can be 
accessed by Matrix using the Element (previously Riot) desktop or 
phone app.


server: gnuradio.matrix.ungleich.cloud
room: #HamRadio:gnuradio.org

you also can join the #gnuradio:gnuradio.org room for the more 
specific GR questions.


I will soon be posting a news item here and on the gnuradio.org home 
page about our first video meeting.


73,
---
Barry Duggan KV4FV
https://github.com/duggabe

On Tue, 22 Sep 2020 22:24:49 +0200, kristoff wrote:

Hi Barry,

Concerning the separate GR-ham mailing-list, I don't know if it really 
needs to be a "GR ham-radio" list,  but what I think would be useful 
is a separate mailing-list to discuss signal-processing (that happen 
to use GNU Radio), separate of the 'discuss-gnuradio' list that is 
more related to questions on GNU Radio itself.


I am also still learning SDR, and I have a number of question on how 
to decode signals (e.g. "I want to decode RTTY with 1.5 stop-bits, 
what's the best way to handle that half a bit at the end without 
impacting the clock-recovery block?") here I have been hesitant to 
post here in the GR list as it's more about signal-process then about 
GNU Radio. When talking to fellow hams who tried GNU Radio, a lot of 
them have the same problem: how to create a working flowgraph? What 
blocks to use? What do all the parameters of that block really do and 
what do I value should I put in there?


So, yes, a separate list would be nice. .. but I don't know if a "GR 
Ham Radio"  is  the best combination.


- Why only Ham radio?

SDR and GNU Radio seams to me one of the best tools to promotion 
amateur-radio, especially if you target people from the open-source / 
hackerspace / maker scene. Focussing to much on amateur-radio will -I 
think- might mean you lose this opportunity.


- For the amateur-radio community, focussing to much on GNU Radio 
might not be ideal neither. For me, the main topic here is SDR, 
signal-processing, DSP and data-communication, ... GNU Radio is only 
part (be it, a very big and important part) of that. Most hams start 
out with a simple RTL-SDR dongle and just *use* it for some project: 
APRS receiver, beacon receiver, to track HABs to listen to 
weather-satellites, listen to QO100, ... It's usually only in a later 
stage that they move to GNU Radio, when they are comfortable with 
using SDR and are interesting going the next step: learn how SDR works 
internally and develop SDR applications themselves.


73
kristoff - ON1ARF

Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

[Kristoff]

Hi Barry,



Concerning the separate GR-ham mailing-list, I don't know if it really 
needs to be a "GR ham-radio" list,  but what I think would be useful is 
a separate mailing-list to discuss signal-processing (that happen to use 
GNU Radio), separate of the 'discuss-gnuradio' list that is more related 
to questions on GNU Radio itself.


I am also still learning SDR, and I have a number of question on how to 
decode signals (e.g. "I want to decode RTTY with 1.5 stop-bits, what's 
the best way to handle that half a bit at the end without impacting the 
clock-recovery block?") here I have been hesitant to post here in the GR 
list as it's more about signal-process then about GNU Radio.
When talking to fellow hams who tried GNU Radio, a lot of them have the 
same problem: how to create a working flowgraph? What blocks to use? 
What do all the parameters of that block really do and what do I value 
should I put in there?


So, yes, a separate list would be nice. .. but I don't know if a "GR Ham 
Radio"  is  the best combination.


- Why only Ham radio?
SDR and GNU Radio seams to me one of the best tools to promotion 
amateur-radio, especially if you target people from the open-source / 
hackerspace / maker scene. Focussing to much on amateur-radio will -I 
think- might mean you lose this opportunity.



- For the amateur-radio community, focussing to much on GNU Radio might 
not be ideal neither. For me, the main topic here is SDR, 
signal-processing, DSP and data-communication, ... GNU Radio is only 
part (be it, a very big and important part) of that.
Most hams start out with a simple RTL-SDR dongle and just *use* it for 
some project: APRS receiver, beacon receiver, to track HABs to listen to 
weather-satellites, listen to QO100, ...
It's usually only in a later stage that they move to GNU Radio, when 
they are comfortable with using SDR and are interesting going the next 
step: learn how SDR works internally and develop SDR applications 
themselves.





73
kristoff - ON1ARF



On 22/09/2020 14:30, Barry Duggan wrote:

Thank you for your feedback! It looks like we have a viable idea.

Here are some additional items to consider:

** use BigBlueButton or Zoom

** have a host / moderator present a topic with a demonstration

** limit to one hour (especially if using BigBlueButton)

** a time on the weekend might be better - something like 20:00 UTC?

** I will put out a news entry on the gnuradio.org homepage as soon as 
a kickoff seems feasible. Marcus will help "as much as he can"


** possibly start a GR Ham Radio mailing list like discuss-gnuradio

Thank you for your continued interest and ideas.

73 and stay safe,
---
Barry Duggan KV4FV
https://github.com/duggabe

On Mon, 21 Sep 2020 11:13:29 +0200, Marcus Müller wrote:

Hello Barry, hi everyone,

I just wanted to say I was very impressed with all the activity in the
breakout session, and how productive everything was.

I'd find it super interesting if aside from the social benefit of
ragchewing (no matter whether that happens on a video conference, via
pure voice comms, or in a text chat), people had would also take the
chance to give a short "impulse" presentation on what they think would
be interesting for the rest; for example, I think Barry's digital
modulations tutorials would be extremely interesting for a lot of people.

But also, a bit on stuff like (brainstorming here) "how to make use of
the new digital predistortion module to get the most out of my system",
"I've invented a digital mode, and you'll never guess what happened
next", "how it took me a month to figure out why I wasn't seeing any
satellites and why I hate storks", "SDR in club education settings", ….

Nothing that takes 2 hours, but something to get discussion off the
ground, and then if discussion shows people like where things are going,
go deeper into it.

Cheers,
Marcus

Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

[Kristoff]

Hi Barry,




On 21/09/2020 02:55, Barry Duggan wrote:
As a result of the CRGon20 Breakout session on Ham Radio, there seems 
to be a lot of enthusiasm for the formation of a monthly group meeting 
for those interested in using GNU Radio in amateur applications. We 
would like to get some feedback on the format, the media, and the 
frequency of proposed meetings. Please respond to this thread.


Look for further announcements here and on the GNU Radio home page 
https://www.gnuradio.org/



I am also interested.

I started the "SDR Belgium" mailing-list here in ON-country.
My plan is to start to do a "SDR Meetup" via jitsi at least once in two 
weeks.


I'm also looking in the option to do a number of workshops on GNU Radio 
for amateur-radios here.


If somebody here has experience on how to organise this -especially from 
an "educational" point of view- that would surely interest me.


Thinks like how many sessions, subjects, intended audience, "expected 
reading / watching" before the sessions, 





Thanks and 73,
Barry Duggan KV4FV


73

kristoff - ON1ARF

Re: linux distro with GNU Radio preinstalled?

[Kristoff]

Derek, Sid,


Sid,

Thanks. Looks like a good starting-point. thx :-)



Derek,

That is true, but I want to focus the workshop in GNU Radio itself, not 
on how-to-install-GNU-Radio :-)


So I prefer something where everything is already pre-installed and that 
the user just needs to do two things: 1/ configure his/her keyboard, 2/ 
"click on the GNU Radio Companion icon on your desktop".
Most of these people (with a few exceptions) are complete new to both 
GNU Radio and linux, and I do not want to scare them away by demanding 
they also need to learn linux.



BTW.
Somebody replied offlist mentioning sigintos. That's also an interesting 
option.

(I do know one of the people who wants to learn GNU Radio for cybersecurity)


Kristoff



On 27/08/2020 09:57, Derek Kozel wrote:

Hi Kristoff,

There are a bunch of ones around which have GNU Radio pre-installed, 
but my most common answer remains using the vanilla Ubuntu 20.04 live 
image and installing GNU Radio and any needed OOT modules from the 
Software library.


Clicking this link will open up the install page for GNU Radio

http://apt.ubuntu.com/p/gnuradio

The same works for many OOTs and apps like GQRX.

http://apt.ubuntu.com/p/gr-iio

Cheers,
Derek

On 26/08/2020 23:21, Kristoff wrote:

Hi all,


I am giving an (online) presentation / demo of GNU Radio next week.


As I do not know if there will be a lot of linux-users, I would like 
to provide an easy-to-use option for windows users.


The GNU Radio Live mentioned on the GNU Radio website (*) is based on 
Ubuntu 2016.04, which is ... euh ... not very recent :-)
Are there any new linux distro / liveCDs that have GNU Radio 
preinstalled and ready to use, either to boot from USB dongle or in a 
VM?



(*)
https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment


Kristoff (ON1ARF)

linux distro with GNU Radio preinstalled?

[Kristoff]

Hi all,


I am giving an (online) presentation / demo of GNU Radio next week.


As I do not know if there will be a lot of linux-users, I would like to 
provide an easy-to-use option for windows users.


The GNU Radio Live mentioned on the GNU Radio website (*) is based on 
Ubuntu 2016.04, which is ... euh ... not very recent :-)
Are there any new linux distro / liveCDs that have GNU Radio 
preinstalled and ready to use, either to boot from USB dongle or in a VM?



(*)
https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment


Kristoff (ON1ARF)

new mailing-list "sdr belgium" + 2nd Belgian SDR meetup

[Kristoff]

Hi all,


Just a small message to announce two things:

- We have started a new mailing-list "SDR Belgium".
The goal, as the name implies, it to get more people in Belgium 
interested in SDR.


The list is provided by the UBA, the Belgian Amateur-radio society, but 
is not limited to licensed hams.

The subscribe, just send an empty message to the following email-address:
sdrbelgium-subscr...@lists.uba.be


- On Friday 4 September, we will organise the 2nd (online) "Belgian SDR 
Meetup".


The meetup is a chance to meet other people in Belgium interested in SDR 
and DSP.
The event will include a walk-through of a simple Radio application (FSK 
receiver + RTTY/baudot decoder of DWD at 147.3 KHz), based on GNU Radio 
and some python code.
The goal is to show to use of GNU Radio to people new to SDR 
development, especially as  means to learn SDR and experiment with 
building a SDR-based receiver.



73
kristoff - ON1ARF

clock-recovery MM block

[Kristoff]

Hi,


Playing with GNU-radio again.


Short question:
Does somebody have a simple (not to mathematical) explanation what the 
parameters of the "clock-recovery MM" block actually do?
I've just used this block with these values to create a RTTY-decoder of 
the DWD at 147.3 KHz (which seams to work OK) but I do like to have at 
least some idea of what exactly I am doing :-)



The default parameters when you create the block in GRC seams to be:

Omega: samples_per_symbol
Gain Omega: 0.25*0.175*0.175
Mu: 0.5
Gain Mu: 0.175
Omega Relative Limit: 0.005


How can I interpret these values?




Thanks in advance!

Kr.

Re: creating a 57 KHz signal from 19 KHz reference

[Kristoff]

Christophe,


See my message to Andy,


I managed to get this working by using the 'PLL Ref Out' block which 
does produce a nice 19 KHz tone. Then filter (BFP) and multiply by three 
using a 3-input multiply block, to get a 57 KHz reference signal.


Next, use a complex conjugate to turn negate the frequency and 
mix/multiply with the 57 KHz RDS carrier.



Next step:
try to find a way to use the 19000/8 (=2375 Hz) reference for PSK 
demodulation.
But I first need to read-up on  PSK demodulator 
(https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation), 
especially the part on timing recovery.




Cheerio! Kr, Bonne,


On 15/11/19 10:03, Christophe Seguinot wrote:


Hi Kristoff

I already tried this in the past but did not saved the corresponding 
grc file. I remember thath I did not succeed in getting a non rotating 
constellation for the RDS signal which normally is achieved when using 
your method. I also tried to demodulate L-R using the square of the 
19Khz pilot (in the original GRC example, L+R demodulated signal has 
wrong phase and wrong amplitude so that is it not possible to recover 
L or R audio channel)


In fact cos^3 (x)= {cos(3x)+3cos(x)}/4 which after filtering lead to 
cos(3x)/4


However, in our case the 19KHz pilot amplitude (a) is very low so that 
when cubing (a cos(x))^3


You get  (a cos(x))^3 =a^3 {cos(3x)+3cos(x)}/4 which can be close to 
noise level


Normally, even if your 57Khz is low, it should be there.

Can you provide your grc file for further investigation?

Regards, Christophe

On 14/11/2019 23:39, Kristoff wrote:

Hi all,


I'm again experimenting with GNUradio, now with a flowgraph I found 
("rds_rx") to demodulate FM/RDS.


One facts about FM/RDS:
After demodulation a FM broadcasting signal, the signal contains 
multiple sub-signals, (among others) a 19 KHz 'stereo pilot' and a 
PSK (RDS) signal at 57 KHz.

57 KHz is three times 19 KHz.

Question:
I am trying to find a way to use the 19 KHz stereo-pilot signal to 
create a 57 KHz carrier (to down-convert the FM/RDS carrier at 57 KHz).

How do I do this?


I tried using a PLL carrier-tracking block to extract the 19 KHz 
carrier (which seams to work) and direct that carrier to a 3 input 
multiplier block, but that does not seams to work.
Even after filtering out DC and the carrier at  -19 KHz (negative 
frequency), the output of the multiplier is always zero. (*)


Or is there a better way to generate a 57 KHz complex sine-wave from 
a 19 KHz reference signal?



(*)
When I just connect the output of a signal-source block (that 
contains a 19 KHz complex-number signal) and connect this to all 
ports of a 3-input multiplier, I do get a carrier at 57 KHz.
So I am puzzled why this seams to work, but using the same technique 
to multiply the output of a PLL carrier-tracking block does not 
result in anything useful.



Cheerio! Kr, Bonne,

Re: creating a 57 KHz signal from 19 KHz reference

[Kristoff]

Hi Andy,


I played around with this some more yesterday.


On 15/11/19 18:16, Andy Walls wrote:

From:   Kristoff
Date:   Thu, 14 Nov 2019 23:39:32 +0100

[snip]


Question:

I am trying to find a way to use the 19 KHz stereo-pilot signal to
create a 57 KHz carrier (to down-convert the FM/RDS carrier at 57
KHz).

How do I do this?

Use the PLL carrier tracking block which will simultaneously:

1) phase lock to the 19 kHz pilot tone
2) shift (in reality rotate) the spectrum of the signal so the 19 kHz
tone gets moved to 0 Hz.


Yep. This turned out to be the problem.
I then replaced it with the "PLL ref out" block which seams to do the trick.




After that use a Rotator block to shift the spectrum another 38 kHz =
57 kHz - 19 kHz


Well, the goal of the exercise is to extract the 57 KHz RDS signal 
purely based on the 19 KHz reference and not be dependent on a signal 
locally generated in gnuradio.

This excludes the use of the rotator block.



Is there a block that is able to 'scale' a signal in the frequency-domain?
I was thinking for something like this:

- calculate the difference in phase of the input signal, as compared 
with the phase of the previous input sample


- create an output-signal with a "n" times phase-difference as compared 
to the previous output sample


That way, using the 19 KHz reference, it would be possible generate both 
the 57 KHz RDS-carrier and the 2375 baud (19KHz /8 ) reference for the 
PSK demodulator



Does something like that exist?



Or is there a better way to generate a 57 KHz complex sine-wave from
a 19 KHz reference signal?

There is no need to have a locally generated 57 kHz carrier, when you
can just use a PLL to phase lock and then a rotator to shift the
spectrum.


Can you explain this?

As far as I understand it, the rotator moves the frequency up or down 
"n" * ( sample-rate / 2pi), so it is dependent on a 'locally generated' 
reference (the sample-rate inside gnuradio), no?



Or am I wrong?


-Andy

Cheerio! Kr, Bonne,

creating a 57 KHz signal from 19 KHz reference

[Kristoff]

Hi all,


I'm again experimenting with GNUradio, now with a flowgraph I found 
("rds_rx") to demodulate FM/RDS.


One facts about FM/RDS:
After demodulation a FM broadcasting signal, the signal contains 
multiple sub-signals, (among others) a 19 KHz 'stereo pilot' and a PSK 
(RDS) signal at 57 KHz.

57 KHz is three times 19 KHz.

Question:
I am trying to find a way to use the 19 KHz stereo-pilot signal to 
create a 57 KHz carrier (to down-convert the FM/RDS carrier at 57 KHz).

How do I do this?


I tried using a PLL carrier-tracking block to extract the 19 KHz carrier 
(which seams to work) and direct that carrier to a 3 input multiplier 
block, but that does not seams to work.
Even after filtering out DC and the carrier at  -19 KHz (negative 
frequency), the output of the multiplier is always zero. (*)


Or is there a better way to generate a 57 KHz complex sine-wave from a 
19 KHz reference signal?



(*)
When I just connect the output of a signal-source block (that contains a 
19 KHz complex-number signal) and connect this to all ports of a 3-input 
multiplier, I do get a carrier at 57 KHz.
So I am puzzled why this seams to work, but using the same technique to 
multiply the output of a PLL carrier-tracking block does not result in 
anything useful.



Cheerio! Kr, Bonne,

Re: [Discuss-gnuradio] forum to learn more about signal-processing and SDR ?

[Kristoff]

Hi Quasin, Neel, Ali, Albin,


(I'll reply in everybody in one mail, this list is busy enough as it is 
:-) )



Ali, Neel,

Thanks for the link.

Also I agree that basic-information is important to get started, in this 
case, I was looking for a forum/list. Sometimes, one needs to have a 
place to just as a question on a particular issue or how it is 
implemented in a specific project.


In this case, my question was related to a APT decoder found here 
(http://oz9aec.net/radios/gnu-radio/simple-apt-decoder-prototype), and  
more specific how the AM demodulation is done. It uses a trick to shift 
the spectrum of a IQ signal down by 1/4 the sampling-rate, but I did not 
understand why he does one single conversion from 2 floats to a complex 
(s1, s2 -> [s1,s2]). and not two (s1,s2,s3,s4 -> [s1,s2],[-s3,-s4])
In the mean time, I found it out myself: as the next block is a 
complex-to-amplitude, the sign of the complex number is removed anyway.



I don(t know if this the same for other people new to signal-processing, 
GNU Radio is very interesting as it allows me to look at how other 
people do it and learn from that. Hence, having a forum to ask questions 
is a real forum.



Albin, Quasim,

Thanks for the link.
The "dsprelated" forum seams quite interesting.


The problem with stack-exchange (I have noticed) is that you really must 
have a very specific answer with a very specific answer. They do not 
like "generic" questions. (I once had a question on amateur-radio 
refused by them as it was "not precise enough").



Thanks!


Kristoff



On 18/03/19 00:55, Qasim Chaudhari wrote:

Hi Kristoff,

   Since you've asked about a forum, I think DSPrelated is a treasure 
trove of DSP knowledge. Hope you find it useful.


https://www.dsprelated.com/forums

Cheers,
Qasim


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

[Discuss-gnuradio] forum to learn more about signal-processing and SDR ?

[Kristoff]

Hi,


One of the reasons I am currently using GNU Radio is to learn more about 
signal-processing and SDR.


As the "discuss-gnuradio" list is about gnuradio itself, what would be a 
good mailing-list, newsgroup or forum to ask more generic questions 
about signal-processing?





Kristoff (ON1ARF)


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

Re: [Discuss-gnuradio] compressing I/Q files

[Kristoff]

Marcus, all,


Thx.

In the mean time, I did a little bit of testing.

A 256 MB piece of a I/Q file (a pass of NOAA-19), sampled at 240 Ksps.
Gzip compressed this down to 40 MB. 7Zip managed to get this down to 29 
MB (but compressing took 10 to 20 times longer).


Now, after converting this file from float to short, you get a 128 MB file.
However, if you then compress that, the gain isn't that big anymore: 
gzip 33 MB, 7zip 25 MB.



My guess is that gzip and 7zip do compression based on looking for 
repetitive patterns. This means that converting 32bit floats to 16bit 
shorts does not really help if you plan to compress the files afterwards 
anyway.




Kristoff


On 10/03/19 18:33, Marcus Müller wrote:

Hi Kristoff, Benny and Alban,

TL;DR:
Benny is exactly on spot. Other than that, decimate your signal if you
know the bandwidth is less than your sampling rate, and don't put too
much hope on audio encoders.

Long Version:

Point is: the signal coming from your SDR device, whatever that might
be, has finite resolution – typically, no more than 16 bits per
channel. Hence, the conversion from float to short (or directly getting
short, if your device driver allows that) is lossless. For example,
USRPs' driver (UHD), and the GNU Radio USRP source, can be configured
to hand out the signed complex 16 bit conversion of the data from the
network or USB interface instead of the float32 conversion.

Any other compression method can only do so much:
Your signal recording is essentially random – meaning that all values
should be roughly equally likely. Maybe extreme high amplitudes are a
little rarer, since you'd typically avoid those to stay clear of
clipping.
That means that the average info per sample is relatively high: From
seeing other samples, we know very little about it, so the surprise we
get from its actual value is pretty high. Information-theoretically,
the expected information content per sample is the entropy of a source.
Information and entropy are both measured in bit – the completely fair
random decision between 0 and 1 ("flipping a coin") is worth 1 bit, and
picking one out of 2¹⁶ values perfectly randomly is worth 16 bit.

(Lossless) compression can, best case, achieve a compression where the
amount of bits used per sample is equal to the entropy of the source.
Now, if your signal is somewhat noisy, and other than that relatively
interesting (i.e. you're not observing a constant value), your source
entropy often approaches the limit given by the ADC – in my tests, even
on severly backed-off signals, standard Huffmann and Lempel-Ziv-Welch
compressors (zip, gzip, 7z, zstd, bz2, xz) achieved negligible
compression ratios on radio recordings.

I've tried FLAC, too – FLAC doesn't allow to set the actual sampling
rate as high as was truly used by typical SDR hardware (i.e. the header
field for the sampling rate simply doesn't have enough size to allow
for 10⁷, for example). But that's mainly a metadata problem that can be
solved by ignorance.
However, FLAC's linear prediction coding relies on signals having
a) "small" deviation from a linear function for short time periods, and
b) the following residual coding relies on geometric distribution –

and that's usually not given, because
a) if you already know you will be in need of compression, you're
probably not significantly oversampling your signal, but are already
decimating it to a rate barely more than sufficient. Everything else
would be a larger waste of space – and has no benefits for signal
analysis later, and
b) with the prior assumption broken, only a zero-order linear precoder
doesn't make things worse – i.e., simply handing through the input
samples to the residual coder. That residual coder, as said, depends on
the distribution of amplitudes to follow a specific statistic to work
well.  Sadly, that statistic doesn't apply to I&Q signals, typically.

My experience is that FLAC doesn't work well for anything that's not
massively oversampled AM audio – which is no surprise, because that
literally isn't very different from audio, which is what FLAC was
designed for.

However, my FLAC experiments lie years in the past – maybe the encoder
got more versatile; Alban, do you have deviating experience?

Best regards,
Marcus
On Sun, 2019-03-10 at 11:54 +, Benny Alexandar wrote:

  Yes, converting float 32bit to short16 is an option, compressing
using 7zip or gzip won't give good compression .
From: Discuss-gnuradio <
discuss-gnuradio-bounces+ben.alex=outlook@gnu.org> on behalf of
Kristoff
Sent: Sunday, March 10, 2019 3:57 PM
To:discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] compressing I/Q files
  
Hi all,




Simple and short question:
What is the best way to compress a raw I/Q file? A generic
compression-tool like gzip, zip? Or are there better and specialised
tools?


Is converting the data in the I/Q file f

[Discuss-gnuradio] compressing I/Q files

[Kristoff]

Hi all,



Simple and short question:
What is the best way to compress a raw I/Q file? A generic 
compression-tool like gzip, zip? Or are there better and specialised tools?



Is converting the data in the I/Q file from float to short an option?


Kristoff


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

Re: [Discuss-gnuradio] creating a embedded python-block with multiple output types

[Kristoff]

Cinaed;


(inline comments)

On 27/02/19 05:37, Cinaed Simson wrote:

There's problem with the grc file - it doesn't load into grc.
The embedded python code is using ">" instead of ">" - at least that
was my guess.


I don't know. It seams to work as is on my machine (ubuntu 16.04).

I do also see the ">" in the .grc file, but when I open the python 
source-code from gnuradio-companion, they are replaced by "<" and ">".




As for your question, do you mean select a waveform in the signal source
block?


No, what I want to do is to allow the user to select the output type.

If you look at the signal-source block, it can output complex, float, 
int or short. I was wondering how to implement that as part of an 
embedded python block.



In my current python code, I have this:

    gr.sync_block.__init__(
    self,
    name='morsecode encoder',
    in_sig=[],
    out_sig=[np.complex64] <--
    )

(Where the "out_sig = ..." describes the output type)

I would like to make this output-type user-selectable.



-- Cinaed

Cheerio! Kr. Bonne.

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

[Discuss-gnuradio] creating a embedded python-block with multiple output types

[Kristoff]

Hi,


Last weekend, I've been playing around with python-blocks in python, one 
of the projects was to create a morsecode encoder block.

(0.0.1 alpha-code here: https://github.com/on1arf/gr-morsecode-enc)
The output-type of that block is complex64.

Small question.
How can I create a GNU Radio python-block that allows the user to select 
the output-type of the block, like -say- the signal-source block?




Kristoff



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

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

[Kristoff]

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

Re: [Discuss-gnuradio] Call for Participation FOSDEM & pre-FOSDEM Hackfest

[Kristoff]

Hi all,


First of all, thanks to Andrey for organising this.


I like to announce that, also as part of the "byteweek" event at hsbxl, 
there will also be an "amateur radio" day in hsbxl. This will be 
organised on Thursday 31/1.


The goal is the same as the "ham-radio infobooth" at FOSDEM itself: 
trying to bridge the gap between the amateur-radio community and the 
maker/hacker/open-source community. (*)


Currently planned are
- a presentation "amateur radio for hackers"
- an HF-station to demonstrate amateur radio (mainly digimodes)
- two workshops:


The two workshops try to bridge the amateur-radio community, working 
from the two directions:


- one workshop about the RTL-dongle and building a small antenna. This 
is because the RTL-dongle is for most people their first steps into 
exploring radio .


- for the other workshop, I would like to have a workshop "gnuradio for 
hams", i.e. an introduction for gnuradio for hams.
For that workshop, I am looking for somebody of the gnuradio community 
who can help with that.


I've talked to a number of other radio-amateurs about gnuradio, and 
quite a few have tried it (or at least watched videos about it), but 
most of them have quite a problem with getting started.


There is quite a few videos and other resources on gnuradio, but very 
few of them approach it from a amateur-radio perspective. Most hams I 
talked to have a problem to "transpose" their knowledge of radio and 
transceivers as "hardware" and electronic circuits into the pure 
software domain.


So, if somebody of gnuradio is interested in helping to organise this 
workshop (and help people get started to "learn to think in SDR"), that 
would be great!


From a practical side, for hardware needed for the workshop, we 
currently have a hackRF, a plutoSDR, a number of RTL-dongles and ... a 
flexradio 6500! (the station we will be using to demonstrate 
amateur-radio). (**)



Thanks in advance!


Cheerio! Kr. Bonne (ON1ARF)



(*) Also this year, we will be present at FOSDEM with a amateur-radio 
infobooth. If the location is similar to last year, it will be located 
in the AW building, just next to the entrance of where the SDR devroom 
is held)


(**) for the flexradio 6500, I found out there is a golang 
software-module to drive that tranceiver from gnuradio. Hence, it would 
be interesting for try to get gnuradio working with that rig! 100 Watt 
HF / 6 meter.





On 4/12/18 14:40, Andrej Rode wrote:

Hi all,

merely two months are left until we gather SDR hackers and friends in the Free
Software Radio Devroom in Brussels at FOSDEM. Please submit more
talks/events for the Devroom until December 7th here [0].

For everyone who is able to attend and is arriving early (or has the
possibility to do so): We want to invite you to the GNU Radio Hackfest
taking place at the Hackerspace Brussels (HSBXL) on *Jan 31st & Feb 1st '19*.
The hackfest will be part of a series called "Byteweek" which
is a yearly event organized by HSBXL in a byte-long week before
FOSDEM. The events' page can be found here [1].

Please feel free to add more ideas to the Hackfests' wiki page and if
you are able to attend you can add yourself to the list of participants
so we have rough idea who will be there. [2]

Cheers
Andrej (noc0lour)

[0] https://penta.fosdem.org/submission/FOSDEM19
[1] https://hsbxl.be/events/byteweek/2019/
[2] https://wiki.gnuradio.org/index.php/Hackfest1902

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



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

Re: [Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR programer

[Kristoff]

Hi Kevin,


(inline comments).



On 27-08-18 02:57, Kevin Reid wrote:

Some partial answers, from memory and not necessarily correct:

Well, they where usefull anyway, so thanks. :-)





On Sun, Aug 26, 2018 at 1:26 PM Kristoff <mailto:krist...@skypro.be>> wrote:


- Can somebody explain how to implement a source-block using
embedded-python?
In the code I have now, it is implemented as a sync-block, taking
in a
signal from a signal-generator block, but that is probably
(surely!) not
the correct way to do this.


A source block is just a block with no inputs. I haven't yet tried it 
in Python but it /should/ be simply specifying in_sig=[] in the 
__init__. This means that your work function will be called repeatedly 
rather than only when input data is available.

Correct.

Got that to work. Thx!

But do note that  you should also use "self.set_output_multiple" to set 
the number of bits you will send into the output queue every time the 
"work" function is called.




I did notice that the signal-generator blocks that exists in GRC
do have
a input-port that is greyed-out and not connected. I probably need to
implement something simular.


No, gray ports in GRC are message ports for receiving control 
messages. It is a separate additional feature of that block and not 
one you have to implement.

OK. I didn'tknow these block have control-ports. I should look into that :-)


(cut some more interesting stuff .. thx for that :-) )






- Basically, a pocsag paging-message is a packet, not a continuous
stream.
It is possible to create a source-block that creates a stream of a
limited length and then stop the execution of the graph?


There are two things you can do depending on what you need.

You can return -1 from the work function to indicate you are done. 
This propagates to downstream blocks, and causes the top_block.wait() 
call that exists in most GR programs to stop waiting and return, but 
it can instead choose to (reconfigure and) restart the flow graph if 
you have an application where that makes sense.


For some reason, tThat didn't work in my case. Returning -1 from the 
worker function did not stop the flow-graph.


I do get a lot of "U"s in the console, but the application does not stop.
No idea why this is.


If you mean you want to pause work and resume when the next packet 
comes along, then your source should just block until more data is 
available. You might need to pad the output with zeroes at the end to 
ensure the packet isn't cut off by sitting in partial buffers.


That DID work, .. starving the output-channel did caused the osmocom 
transmitter-module to stop transmit, .. but it did not revive when I 
restarted sending data out the egress port.


In my case, it was OK as I only wanted to send one single packet, but it 
does not looks to be a sollution for just switching on and off a 
transmitter.

OK. It's good enough for what I needed it for.





(I haven't worked with the second approach, so there might be other 
caveats, and there may be better tools — my work with GNU Radio has 
been primarily analog/continuous receiving rather than 
transmitters/transceivers using packets.)

No problem.
Thanks for your reply. It was very helpfull.


Kristoff

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

[Discuss-gnuradio] embedded-python block for pocsag paging: help request by first-time GR programer

[Kristoff]

Hi all,


I just did my first steps developing a embedded-python block for GR: a 
block to generate the data bitstream for sending pocsag paging messages.


See here: https://github.com/on1arf/gr-pocsag
(.grc-file, just look at the embedded-python block for the python code).

(the rest of the flow-graph is shamelessly stolen from the author of 
gr-mixalot).




After trying out some code, I managed to get something "kind-of 
working", but probably not implemented the correct way. Can somebody 
please help me with a couple of things I do not yet understand:


- Can somebody explain how to implement a source-block using 
embedded-python?
In the code I have now, it is implemented as a sync-block, taking in a 
signal from a signal-generator block, but that is probably (surely!) not 
the correct way to do this.



I did notice that the signal-generator blocks that exists in GRC do have 
a input-port that is greyed-out and not connected. I probably need to 
implement something simular.


- is it possible to define a variable in a embedded-python block that 
can only have a predefined number of possible values (e.g. "bitrate" can 
only be 512, 1200 or 2400, "inverted" can be true or false)?


Or do you allow the user to insert just any value and throw a ValueError 
in the python block if the value is not correct?


- How do you interface your embedded-python code with variables that 
change during run-time? (e.g. a variable mapped to a GUI slider).

How does the embedded-python program known when a variable has changed?

- Basically, a pocsag paging-message is a packet, not a continuous stream.
It is possible to create a source-block that creates a stream of a 
limited length and then stop the execution of the graph?

(so, in essence, a GRC


Also, I've found a couple of presentations online concerning stream-tags.
Are there any examples of how to use the stream-tags API inside a 
embedded-python block?


- Anycase, (not strickly speaking not GR-related) ... how do you 
actually switch a hackRF between RX and TX mode?



Thanks in advance for any help.

Kristoff - ON1ARF




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

Re: [Discuss-gnuradio] Live DVD for i386 ?

[Kristoff Bonne]

Mark,


I sometimes distribute image files for the raspberry pi for a number of 
ham-related projects. For that I used bittorrent.
That way, you only need to distribute it once and let the community 
distribute it further on.



If you are interested, I have no issue to distribute the file via 
bittorrent. I have a Raspberry pi in a datacenter I can use for this.



How do you propose you send the file to me. Do you have a NAS I can 
access to download it. Or, if needed, I can provide you with a ssh 
account so you can upload the file.




Cheerio! Kr. Bonne.




On 03-02-14 15:34, M Dammer wrote:

I have made a Gnuradio Live DVD named SDRLive for i386 based on Gnuradio
3.7 last November. The main software package on the DVD is Gnuradio, but
I added some useful other SDR packages (Quisk, Linrad) plus plotting and
audio DSP software as well. I was inspired to do this because I was
asked to do a presentation of SDR and of the missing i386 disk and I see
the need for a beginner friendly live DVD.
I wanted to publish the DVD, but I had to put it on the backburner
because of a death in the family.
My problem is that I have no place to host the DVD via FTP/HTTP or
Bittorrent and I only have a fairly slow rural broadband connection here
in northern Scotland, so I want to avoid uploading the 1.8Gb image
several times.
I am happy to release the DVD if anyone can provide hosting space or
point me in a direction where I could do this free of charge.

Mark

On 02/02/14 20:19, Kristoff Bonne wrote:

Hi all,


First, I like to thank everybody at the FOSDEM SDR devroom today. I
really really learned a lot today!



I want to try to use GR for a session on "how dooes a 433 Mhz ISM
signal look like" in our local radio-club. For that, I want to use the
live-CD / DVD of gnuradio so that people can try it out themseelfs.


However, at http://gnuradio.org/releases/gnuradio/iso/, I find only
AMD versions of the live DVD.


Is there a i386 version available somewhere?




Cheerio! Kr. Bonne.


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




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




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

[Discuss-gnuradio] Live DVD for i386 ?

[Kristoff Bonne]

Hi all,


First, I like to thank everybody at the FOSDEM SDR devroom today. I 
really really learned a lot today!




I want to try to use GR for a session on "how dooes a 433 Mhz ISM signal 
look like" in our local radio-club. For that, I want to use the live-CD 
/ DVD of gnuradio so that people can try it out themseelfs.



However, at http://gnuradio.org/releases/gnuradio/iso/, I find only AMD 
versions of the live DVD.



Is there a i386 version available somewhere?




Cheerio! Kr. Bonne.


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

[Discuss-gnuradio] FOSDEM 2013: local ham frequency

[Kristoff Bonne]

Hi,


For any hams who will be going to FOSDEM 2014 this weekend:

The proposed local frequency to find other hams: 145.525 Mhz.

http://aprs.fi/#!mt=osm&z=11&call=a%2FFOSDEM&timerange=3600&tail=3600
This APRS information will also be transmitted over RF during the 
weekend for people who have a APRS-enabled mobile rig.



The proposed meeting-place "/tmp/UrLab" (ULBs own hackerspace) on the 
ground floor of building F1 and ... of course, the GNUradio devroom on 
sunday:

https://fosdem.org/2014/schedule/track/software_defined_radio/



73
kristoff - ON1ARF

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

[Discuss-gnuradio] gnuradio at FOSDEM 2014

[Kristoff Bonne]

Hi,


I have seen that on sunday, the 2nd of february, there is a complete 
"Software Defined Radio" devroom at FOSDEM 2014 (Free and OpenSource 
Developers Eurooean Meeting) here in Brussels.

https://fosdem.org/2014/schedule/track/software_defined_radio/

GNUradio is (ofcourse) a big part of this track.



I am very interested in attending it.
Question:
Is this something I should take my laptop with me and where we can try 
out while attending, or is this more a "relax and listen" kind of event?





Cheerio! Kr. Bonne.

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

Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Kristoff Bonne]

Marcus,




On 30-07-13 21:41, Marcus D. Leech wrote:

On 07/30/2013 03:35 PM, Kristoff Bonne wrote:

Tom,


(inline comments)


My understanding was that all IEEE floating-point implementations 
followed the same rounding rules, etc?  Is that not the case?


Are the SIMD subsystems not IEEE compliant, for performance reasons?

As said, I'm not an expert in code-optimisation.

I did look up the discussions. It was more then "a few weeks ago", they 
date back to January this year. :-)


There are two discussions that might be interesting:
http://sourceforge.net/mailarchive/forum.php?forum_name=freetel-codec2&viewmonth=201301

"c2dec produces different wav-files on i386 and on ARM 
<http://sourceforge.net/mailarchive/forum.php?thread_name=50F137B8.8000403%40coppice.org&forum_name=freetel-codec2>" 
and "adding compiler flags 
<http://sourceforge.net/mailarchive/forum.php?thread_name=CABfYdSp2EkG9AHbsoXT7n_hLb1gSur2HH-noznGEJ7Eak6eiqw%40mail.gmail.com&forum_name=freetel-codec2>"



Cheerio! Kr. Bonne.



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

Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Kristoff Bonne]

Marcus,



(repost due to technical problems. My appolologies for a possible double 
post).



On 30-07-13 21:41, Marcus D. Leech wrote:

On 07/30/2013 03:35 PM, Kristoff Bonne wrote:

Tom,


(inline comments)


My understanding was that all IEEE floating-point implementations 
followed the same rounding rules, etc?  Is that not the case?


Are the SIMD subsystems not IEEE compliant, for performance reasons?

As said, I'm not an expert in code-optimisation.

I did look up the discussions. It was more then "a few weeks ago", they 
date back to January this year. :-)


There are two discussions that might be interesting:
http://sourceforge.net/mailarchive/forum.php?forum_name=freetel-codec2&viewmonth=201301

"c2dec produces different wav-files on i386 and on ARM" and "adding 
compiler flags"



Cheerio! Kr. Bonne.




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

Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Kristoff Bonne]

Tom,


(inline comments)


On 30-07-13 15:53, Tom Rondeau wrote:
The codec2 needs a bit of attention. I've not known it to fail like 
this (and that's a very close result you're seeing), but we need to 
update the version of codec2 that we're using. So unless you really 
wanted to use codec2 with GNU Radio, just ignore this error since it's 
very isolated.

But I must say that there does is quite a difference between the test in
gnuradio 3.6.4.1. and 3.7.0

All the stuff about "data" and "expected data" are simply not present in the
test-script in 3.6.4.1.

Perhaps the thing here is that the script for 3.6.4.1. simply does not do
this "compair with what we expect" test and it might be that this codec2
library is just as wrong on 3.6.4.1 as in 3.7.0

Apparently, in 3.6, we weren't actually properly testing that code.


Some time ago, there was a discussion in the mailing-list about exactly 
this, about the effects of code-optimalisation.


It turns out that when you start really optimizing code for specific 
processors or specific features (like Single-instruction-multiple-data) 
it is very difficult to do so without effecting the outcome of the 
codec2 decoding process.


I'm not an expert on ARM code optimalisation but it seams to be that the 
way floats are processed will under certain conditions result in very 
small differences in the result when you decode a codec2 frame to a PCM 
frame.
The difference are very small (after all, you do not hear a difference 
of 1 or 2 over a 65536 scale of 16 PCM audio) but they are there!
This was also seen when running the codec2 code on (say) a PPC processor 
instead of a intel or a ARM.




Now, I'm not a expert in the low-level code of the codec2 libraries or 
on volk, but I think it may be we are seeing the same thing here: that 
the code-optimalisation operations in volk result in these small 
differences -depending on what processor the code runs on- which is what 
causes this particular test to fail in the GNUradio 3.7.0 "make test" 
script.


So it might be that it would be better to remove these bit-comparison 
tests again as it will probably confuse people. People do expect a "make 
test" to result in a 100 % success-rate.




Tom

Chéério!
Kr. Bonne.

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

Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Kristoff Bonne]

Tom,


(inline comments)


On 29-07-13 17:01, Tom Rondeau wrote:

On Mon, Jul 29, 2013 at 5:48 AM, Kristoff Bonne  wrote:



Just found this, it might help:
https://github.com/dl1ksv/gr-afsk

Hmmm. Looks interesting. A good start. :-)


However, it seams I have another problem: it does not build on my system
(ubuntu 12.04 LTS).
It needs gnuradio-runtime and as I currently run gnuradio 3.6.4.1 + Boost
1.49 build from source, it doesn't have that.

I tried to build 3.7.1 -which seams to include gnuradio-runtime in its
source- but that fails on a number of tests (qa_fir_filter,
qa_freq_xlating_fir_filter, qa_constellation_receiver and
qa_codec2_vocoder).

Grrr! :-(

Those QA failures are probable a Volk issue. Try running volk_profile
after you run 'make install'. If a given kernel fails for an
architecture, it will be disabled. Once volk_profile completes (it can
take a while), try rerunning 'make test'.

Good news and bad news.

First test: to run volk_profile without doing the "make install" (I did 
not want to install something where the "make tests" indicated is wasn't 
100 % OK). Same result as before. "make test" still gives 4 errors.


2nd test:  ran "sudo make install" anyway, then volk_profile and then 
"make test":

Good news and bad news.
3 tests are now OK, only the codec2 vocoder still fails.


--- cut here --- cut here --- cut here --- cut here --- cut here ---
The following tests FAILED:
168 - qa_codec2_vocoder (Failed)
Errors while running CTest
--- cut here --- cut here --- cut here --- cut here --- cut here ---






If it still fails, run
'ctest -V -R volk' and send us the output.

Is now OK:
--- cut here --- cut here --- cut here --- cut here --- cut here ---
1: *** No errors detected
1/1 Test #1: qa_volk_test_all .   Passed0.92 sec

The following tests passed:
qa_volk_test_all

100% tests passed, 0 tests failed out of 1
--- cut here --- cut here --- cut here --- cut here --- cut here ---


What is strange is that I do get an error when I do this test on the 
codec2 vocoder block:

--- cut here --- cut here --- cut here --- cut here --- cut here ---

168: Test command: /bin/sh 
"/home/kristoff/ham/gnuradio/gnuradio-3.7.0/build/gr-vocoder/python/vocoder/qa_codec2_vocoder_test.sh"

168: Test timeout computed to be: 9.99988e+06
168: F
168: ==
168: FAIL: test001_module_load (__main__.test_codec2_vocoder)
168: ------
168: Traceback (most recent call last):
168:   File 
"/home/kristoff/ham/gnuradio/gnuradio-3.7.0/gr-vocoder/python/vocoder/qa_codec2_vocoder.py", 
line 54, in test001_module_load

168: self.assertEqual(expected_data, actual_result)
168: AssertionError: Tuples differ: (0, 0, 0, 3, 2, 0, 1, 5, 6, 7,... != 
(0, 0, 0, 3, 2, 0, 1, 5, 6, 7,...

168:
168: First differing element 112:
168: 24
168: 25
--- cut here --- cut here --- cut here --- cut here --- cut here ---

Am I correct to assume that the errors means there is a difference 
between what it actually gets back from the module based on a 
test-pattern and what is expects.
Is this related to the volt-libraries that produce a different result on 
my particular test.



But I must say that there does is quite a difference between the test in 
gnuradio 3.6.4.1. and 3.7.0


All the stuff about "data" and "expected data" are simply not present in 
the test-script in 3.6.4.1.


Perhaps the thing here is that the script for 3.6.4.1. simply does not 
do this "compair with what we expect" test and it might be that this 
codec2 library is just as wrong on 3.6.4.1 as in 3.7.0



Both versions I have are build with boost 1.49; as described in 
README.building-boost


I can try with newer versions of boost; but I must say that when using 
Boost 1.54, GNUradio doesn't even compile on my box.



What is the recommended version of boost to be used with gnuradio 3.7.0 ?



What's your processor?
The machine is a dell laptop. The CPU is a quad-core "Intel(R) Core(TM) 
i5 CPU   M 520  @ 2.40GHz"
(which is a bit strange as the wikipedia says the 520m is supposed to be 
dual-core).




Tom


Cheerio!
Kr. Bonne

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

Re: [Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Kristoff Bonne]

Hallo Marcus,



On 29-07-13 01:44, Marcus D. Leech wrote:



- My first step with GNUradio was to learn a bit more about using it;
so .. do some test.
I wanted to use GNUradio to determine the width of an AFSK signal; so
I started looking for a AFSK modulator / demodulator; to come to the
conclussion I didn't find one.
I looked in the GR source, on CGRAN, using several generic search
engines without look.
Am I missing something here? I would be surprised there is no AFSK
modulator / demodulator in GR as it would mean one cannot do
packetradio or APRS with gnuradio.

(...)



Just found this, it might help:
https://github.com/dl1ksv/gr-afsk

Hmmm. Looks interesting. A good start. :-)


However, it seams I have another problem: it does not build on my system 
(ubuntu 12.04 LTS).
It needs gnuradio-runtime and as I currently run gnuradio 3.6.4.1 + 
Boost 1.49 build from source, it doesn't have that.


I tried to build 3.7.1 -which seams to include gnuradio-runtime in its 
source- but that fails on a number of tests (qa_fir_filter, 
qa_freq_xlating_fir_filter, qa_constellation_receiver and 
qa_codec2_vocoder).


Grrr! :-(



Also, keep in mind that AFSK is a kind of "double modulation scheme".
To demodulate it, first demodulate the FM-voice using a narrowband
  FM demodulator, then run that into a suitaby-configured FSK demod.
AFSK was always a "hack" to allow you to send data over narrowband
FM-voice radios without having to do anything to the radio.  So, they
chose
  Bell-202 synchronous modem tones, because they'd "fit" in most
narrowband FM-voice radios.

Well, that is exactly the reason I would like to test it out. :-)

We currently do packet/ax.25/aprs at 1200 baud AFSK, which is not that 
much less then the 1400 bps needed for codec2. Add a little bit frame 
sync-patterns and -perhaps- some FEC, we might end up with 1600.



It would be kind-of-nice to be able to try out DV with standard FM 
handhelds without any need to have a radio that does 9k6.
But, this is for me just as much a practicle test and just a way to 
getting to know GNUradio. :-)




Cheerio!
Kr. Bonne - ON1ARF


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

[Discuss-gnuradio] new to GNUradio: AFSK and codec2 gmsk modem

[Kristoff Bonne]

Hi,


I'm still very new to GNUradio, so please excuse my (perhaps dump) 
question. I did look around at different places at the web but did not 
really find an answer:


- My first step with GNUradio was to learn a bit more about using it; so 
.. do some test.
I wanted to use GNUradio to determine the width of an AFSK signal; so I 
started looking for a AFSK modulator / demodulator; to come to the 
conclussion I didn't find one.


I looked in the GR source, on CGRAN, using several generic search 
engines without look.



Am I missing something here? I would be surprised there is no AFSK 
modulator / demodulator in GR as it would mean one cannot do packetradio 
or APRS with gnuradio.



- The main reason I am interested in gnuradio is because one of the 
projects I work on is "c2gsmk", a GMSK-based modem for VHF/UHF using the 
codec2 vocoder. Gnuradio looks to me like a very interesting platform to 
do simulation and work on the modem.
The modem is now rewriten as an API which can operate purely on 
bitstreams (i.e. all GMSK modulation / demodulation taken out of the 
code): 56 bits in (40 ms @ 1400 bps codec2), "n" times 96 or 192 Bits 
out (40 ms @ 2400 or 4800 bps c2gmsk).


I have been browsing the different documents on how to write a block and 
also looking in some code to find simular examples on how it is done. I 
have three things I kind-of do not understand.


- How does GNU radio deal with "sessions"? A c2gmsk session is not just 
a stream of bits; it has the notion of sessions. It has a beginning and 
a stream also ends; and it can end in a number of different ways.


I'm trying to understand how to fit the idea of "sessions" into GNUradio.

Or am I seeing it all wrong?



- How does GNUradio deal with information about events in the API.

The c2gmsk API does not only return a bitstream, but also information 
about events; like a change of state in the statemachine of the API, or 
an event like "a GMSK sync-pattern has been detected", or "the stream 
has terminated due to to many out-of-sync frames", or the versionid of 
the stream received, or statistics of the golay decoding process, etc.





- To get some idea of how a block is written. I have been looking at the 
codec2 encoder/decoder block. It is interesting as it is also "x bits 
in, y bits out".
However, c2gmsk is a bit different: there always is a fixed predefined 
number of bits in, but the number of bits "out" can vary. Sometimes just 
send in bits, but do not get anything back (e.g. in the decoder when the 
stream is not syncronised), sometimes one frame inbound results in one 
frame outbound, but sometimes one single frame in can result in (say) 5 
frames out. (e.g. when encodig the start of a stream).


Is this an issue for gnuradio?




Any information welcome.

Chrio!
Kr. Bonne.


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

[Discuss-gnuradio] new yahoo-groups: gmfsk-devel

[Kristoff Bonne]

Gegroet,


Not really related to gnuradio, but this might be interesting for some 
people here.



I've set up a new mailing-list on yahoogroups called "gmfsk-devel". Its 
goal is the discuss the further developement of gmfsk, the HAM 
digital-mode program originally written by Tomi Manninen OH2BNS.

(see http://gmfsk.connect.fi/ for more info on gmfsk).

As the official developement of the program by Tommi has stopped for 
some time now, some people have started to addapt and extend the program 
by themself; so this mailing-list is aimed to bring all these people 
together.


gmfsk provides a great GUI for some HAM-related digital modes; and -as 
it is published under the GPL-licence- it can be concidered a good 
starting-point for people interested in programming digital modes or 
extending the program with other modes.



More info:
http://groups.yahoo.com/group/gmfsk-devel/

To join the list via email, sent a message to 
"[EMAIL PROTECTED]".



Cheerio! Kr. Bonne.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio