Re: taps for a Raised Cosine function

[Phil Frost]

A raised cosine is also known as a Hann window.

https://www.gnuradio.org/doc/doxygen/classgr_1_1fft_1_1window.html#a599d7e9625d6cc77203a8b877c4911e2a0099ec5d7a2ab5d7a7f3fd7f7835c72a

Example usage:
https://github.com/bitglue/gr-radioteletype/blob/3a00e28a2c83b45e9252da41802dcbe30decc49a/python/radioteletype/filters.py#L161-L170

On Tue, Aug 10, 2021 at 12:46 PM Kristoff  wrote:

> 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: Reliable "virtual RF channel" between two grc applications (UDP Source/Sink?)

[Phil Frost]

On Wed, Apr 22, 2020 at 10:48 AM Lukas Haase  wrote:

>
> Has anyone done something like this before and has a recommendation for a
> reliable setup?
> Is UDP Source/Sink over localhost even the best way to go?
>

If you just want to connect two local processes, you could try using mkfifo
 and the file
sink/source on the fifo you create.

You could also create a hierarchical block <
https://wiki.gnuradio.org/index.php/GNURadioCompanion#Hierarchical_Blocks>
and then you don't need to connect to processes at all.

Compensating for sample delay in one audio source channel

[Phil Frost]

I have an audio interface (behringer UCA222) which, for whatever reason,
has a 1 sample delay in one of the input channels. Consequently, the two
input channels have unequal phase across the entire bandwidth. I'd like to
compensate for that.

I measured the delay with this flow graph:

[image: image.png]

Initially the delay was set to 0. I have a Y cable hooked up to the audio
interface so the same square wave is fed back in to both inputs. Then I
compare the phase of the inputs in the time sink. From this I see the 2nd
channel needs to be delayed by 1 sample to correct the error.

I thought the delay block would correct this, but unfortunately it doesn't
seem to do anything. The time sink shows the two channels from the audio
source with the same 1 sample difference in phase no matter how I set the
delay block.

Is there some other way I should go about this?

Re: [Discuss-gnuradio] Moving average

[Phil Frost]

from __future__ import division

...in the script at the top or as a GRC block will also do the trick.

On Tue, Jan 22, 2019, 17:42 Cinaed Simson  On 1/22/19 4:59 AM, david vanhorn wrote:
> > Nope.
> >
> > 1/Averaging evaluates to zero.
> > 1/Averaging. (trailing period) does not evaluate, either in the Moving
> > Average parameters, or as a separate variable.
>
> You can't put a "." after a variable.
>
> Use
>
>   1/float(Averaging)
>
> or
>
>   1./Averaging
>
> -- Cinaed
>
>
> >
> >
> > On Mon, Jan 21, 2019 at 11:00 PM Cinaed Simson  > > wrote:
> >
> > 1/5 is zero using integer division in python.
> >
> > Try using float division
> >
> >  1/4000.
> >  1/5.
> >
> > -- Cinaed
> >
> >
> > On 1/21/19 4:41 PM, david vanhorn wrote:
> > > The docs say that I need to set Scale to the inverse of the Length.
> > > Ok, I interpret that as Length = 4000 and Scale = 1/4000
> > > The docs here:
> > >
> >
> https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1moving__average__ff.html
> > > says that Scale is a float.
> > >
> > > The discussion here clearly shows Scale working for values <1 and
> >0
> > >
> >
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00084.html
> > >
> > > If I enter a scale value by hand, like 0.2, then I see 200m which
> is
> > > what I expect.
> > > If I enter a scale value as (1/5) then I see 0.
> > > If I set a variable called "Scale" = (1/) and enter "Scale" in the
> > Scale
> > > field of the moving average, it evaluates to 0.
> > >
> > >
> > > When I enter the values in the block, it looks like scale is an
> int,
> > > which makes 1/4000 or indeed 1/(>1) problematic in that it always
> > > evaluates to zero, which kinda breaks things.
> > > When I enter 1/2 I get "0"
> > >
> > > When I hover over the field to enter Scale, I get Type Real.
> > >
> > > I have the input and output of my integrator connected to a QT GUI
> > Time
> > > Sink, and while the input waveform is what I expect, if I have any
> <1
> > > Scale parameter, the output is 0.
> > >
> > >
> > > Is something broken here, or is it me?
> > > I've not had any problems using simple math in any of the other
> fields
> > > where appropriate.
> > >
> > >
> > > --
> > > K1FZY (WA4TPW) SK  9/29/37-4/13/15
> > >
> > > ___
> > > 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
> >
> >
> >
> > --
> > K1FZY (WA4TPW) SK  9/29/37-4/13/15
>
>
> ___
> 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] [Freetel-codec2] Why the DMR 4FSK modem is less optimal than David Rowe's 4FSK modem

[Phil Frost]

Wouldn't the ISI largely (theoretically, completely) be ameliorated by
trellis decoding? And I'm not talking about FEC, but rather incorporating
the ISI into the expected Cartesian coordinates for each symbol.

I did some experimentation with this technique on BPSK31, and I was able to
get a little more performance in simulations with a matched filter and
trellis decoding than fldigi and PSKCore got with their unmatched filters
designed to minimize the ISI. Though in the case of BPSK31 the ISI isn't
all that bad, so there less than 1 dB of a gain to be had. Perhaps with DMR
there's more potential?

On Tue, Sep 12, 2017 at 6:50 AM Adrian Musceac  wrote:

> Hi,
>
> In this post: http://www.rowetel.com/?p=4650 David was asking the
> question why the 4FSK modem used by the DMR standard seemed to be
> performing so poorly, especially as compared to his ideal 4FSK modem.
> I was curious myself, so I implemented both and analysed them using my
> modified version of Gqrx, known by some people as gqrx-digital.
> The results can be seen in this video:
> https://www.youtube.com/watch?v=hLeJvqrFrS8
>
> As you can see, the DMR modem uses a sensitivity of PI/sps, which leads to
> a lot of ISI, about 8 dB worth, compared to the optimal 4FSK modem which
> uses a sensitivity of 2*PI/sps. The reason why the DMR modem does this is
> twofold:
> One is bandwidth efficiency. But the most significan one is the fact that
> DMR radios use the same FM modulator for both digital and analog voice.
> Using double sensitivity would lead to analog voice being too wide for
> standard FM channels in commercial bands.
>
> Of course, for me as a developer, I can create two Gnuradio flowgraphs, so
> I can use one modulation type for digital, and another one (proper) for
> analog FM transmission.
>
> Hope this is useful for someone.
>
> 73,
> Adrian YO8RZZ
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Freetel-codec2 mailing list
> freetel-cod...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Good SNR despite rotating constellation

[Phil Frost]

On Tue, Jul 4, 2017 at 6:30 AM Rafik ZITOUNI  wrote:

> Could you give me an explanation how it was possible to obtain a good snr
> and ber with a wrong constellation with  good SNR and BER?
>

for BPSK the value of the bit is determined only by examining the sign of
the real part. There will be errors only when the cluster of points
approaches the imaginary axis, where the sign of the real point changes. If
the frequency offset it small (it rotates slowly) and the SNR high, then
for most rotations there will be negligible errors.

In practice you will probably have great difficulty tuning the receiver
accurately enough for this to work. Furthermore, doppler shift in the
channel may make the frequency change over time. Thus, the need for the
Costas loop or some other frequency synchronization.

Alternately, you can compare the phase of the current signal to the
previous symbol:
https://en.wikipedia.org/wiki/Phase-shift_keying#Demodulation
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FM Modulation problem/question

[Phil Frost]

On Mon, Jun 26, 2017 at 1:50 PM Brashendeavours 
wrote:

> Thank you, Kevin. That is reassuring.
>
> My next question then, is since the deviation is affected by both
> amplitude and frequency, how would you recommend I empirically
> determine/set a peak deviation of 2400Hz for 1200Hz baseband?
> Is this experiment not possible to visualize/determine on a waterfall,
> simply?
>

 I think your confusion may be that deviation != occupied bandwidth.

If the sensitivity on the FM mod block is (2*pi*2400)/(48000), and the
sample rate is 48k, then the maximum deviation is 2.4kHz provided the
baseband signal does not exceed +/- 1. You can verify this by making the
baseband input a very low frequency sine wave, say 0.1 Hz. Viewed in the
waterfall you should then see the carrier move between -2.4 and +2.4kHz.

To determine the bandwidth occupied by the FM signal, you can use the
Carson bandwdith rule, which says the bandwidth required is the peak
deviation _plus the highest baseband frequency_, times two.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] AGC for PAM

[Phil Frost]

I'm working on a BPSK demodulator, which I guess is a kind of PAM. The
signal has some inherent ISI so I'm using Viterbi to decode it. It's
working well in idealized conditions, but I'm a bit lost on how to get the
amplitude right. It seems important that the amplitude is consistent
(modulo noise) for the Viterbi metrics to be accurate.

If that doesn't make sense, I'd think QAM has a similar problem: if the
amplitude is wrong then the wrong symbols are decoded.

What's the best way to do this? Is there something better than the basic
agc_ff block? I know each sample should land on one of 6 places -- perhaps
some kind of least-squares fit?

I've noticed when the input to agc_ff has low amplitude, say -40dB relative
to a normalized +/- 1 signal, it is slower to respond. and likewise,
at +40dB it's faster to respond, and it can start introducing noise as the
gain changes significantly from sample to sample. Not sure if that's
intended behavior, but it does present another challenge since input
amplitude could vary over many orders of magnitude.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

[Phil Frost]

Do you mean the equalization would be performed with another linear filter?

matched filter -> equalizing filter -> clock recovery -> [...]

Wouldn't that be equivalent of convolving the input responses of the two
cascaded FIRs, with the net result being an unmatched filter?

Existing implementations of this mode take that approach, using a filter
which minimizes the ISI while attempting to be close to matched. I wrote
about some of them at https://ham.stackexchange.com/a/7744/218. I was
hoping to try something new, at least for educational purposes.

I'm beyond what I comfortably know at this point, but if someone can
confirm I'm on the right track I can continue researching the right things.
I think part of the problem of the approach above is after filtering, the
noise is no longer uncorrelated. Maybe the canonical solution is something
like this?

matched filter -> equalizing filter -> clock recovery -> decimate to 1
sample per symbol -> "whitening filter" -> Costas loop -> Viterbi detector

I haven't yet studied whitening filters in depth, but my guess is it
reverses the effects of the equalization filter so that the noise is again
uncorrelated. At that point we're back to having ISI, but now with
uncorrelated noise the Viterbi detector can deal with that optimally. Am I
on the right track?

On Thu, Jun 15, 2017 at 9:29 AM Federico 'Larroca' La Rocca <
flarr...@gmail.com> wrote:

> Hi,
> Nice problem you got there. In any case, have you considered performing
> matched filtering (thus maximizing SNR), outputting more than one sample
> per symbol (in fact, without decimation at all), then equalize (so that the
> signal looks as if it was sent and received with a squared-root Nyquist
> pulse) and after all that use a standard clock recovery block? Since you
> know the shaping pulse, and as long as it does not go to zero over the
> range of frequencies of interest, you should be able to transform it into a
> Nyquist pulse. I may be wrong, but in any case Viterbi decoding for symbols
> will be difficult, so this may be worth trying.
> best
> Federico
>
> 2017-06-15 9:57 GMT-03:00 Phil Frost :
>
>> I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK
>> where the pulses are a raised cosine (impulse, not frequency domain) twice
>> the symbol duration[2], no error correction, at 31.25 baud. The transmitted
>> signal has no ISI, but after matched filtering it does:
>>
>> [image: 0SDEq.png]
>>
>> I had hoped to do matched filtering and compensate ISI with a Viterbi
>> equalizer, but I'm unsure how to do clock recovery.
>>
>> I hoped to use the polyphase clock recovery block, but it seems this
>> won't work since the derivative of the signal may not be zero at the ideal
>> sampling points. Is that an accurate assessment?
>>
>> [image: 2017-06-15-083544_393x230_scrot.png]
>>
>> Perhaps the clock recovery MM block? The zero crossings aren't exactly in
>> the middle of the ideal sampling points, but the error is probably
>> negligible. I can't get it to work: I think it outputs the correct bits,
>> but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1
>> depending on the adjacent bits. I'm using the default settings. Is that the
>> intended behavior?
>>
>> [image: 2017-06-15-084108_1038x201_scrot.png]
>> [image: 2017-06-15-084340_475x253_scrot.png]
>>
>> Finally, any other algorithms I should be considering?
>>
>>   [1]: http://bipt106.bi.ehu.es/psk31.html
>>   [2]: https://ham.stackexchange.com/a/7744/218
>>
>> ___
>> 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] Clock recovery for BPSK with intentional ISI

[Phil Frost]

I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK
where the pulses are a raised cosine (impulse, not frequency domain) twice
the symbol duration[2], no error correction, at 31.25 baud. The transmitted
signal has no ISI, but after matched filtering it does:

[image: 0SDEq.png]

I had hoped to do matched filtering and compensate ISI with a Viterbi
equalizer, but I'm unsure how to do clock recovery.

I hoped to use the polyphase clock recovery block, but it seems this won't
work since the derivative of the signal may not be zero at the ideal
sampling points. Is that an accurate assessment?

[image: 2017-06-15-083544_393x230_scrot.png]

Perhaps the clock recovery MM block? The zero crossings aren't exactly in
the middle of the ideal sampling points, but the error is probably
negligible. I can't get it to work: I think it outputs the correct bits,
but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1
depending on the adjacent bits. I'm using the default settings. Is that the
intended behavior?

[image: 2017-06-15-084108_1038x201_scrot.png]
[image: 2017-06-15-084340_475x253_scrot.png]

Finally, any other algorithms I should be considering?

  [1]: http://bipt106.bi.ehu.es/psk31.html
  [2]: https://ham.stackexchange.com/a/7744/218
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Audio latency keeps increasing

[Phil Frost]

I'm prototyping some software which uses a PulseAudio sink/source pair
which I wrote[1]. Even doing something as simple as having the audio source
go into a GUI sink and the audio sink, I'm having an issue where as the
program runs longer, the latency gets higher. Running for a day the latency
will grow to many seconds. This causes issues for the external program
generating and receiving the baseband signal, which is unaware of this
latency.

I best guess of what's going on is this: the source block is connected to a
PulseAudio monitor device. I do this so the audio output of other
applications I'm running can be routed into GnuRadio's input. The same
audio device is associated with the sink and source, so the clocks are
normally synchronized. But as those other applications open and close the
audio device, gaps are introduced into the monitor device, requiring
GnuRadio's buffers to grow as the clock (temporarily) drift apart.

So two questions:

1) Is there a way I can inspect the buffer sizes within GnuRadio to confirm
my hypothesis?

2) Assuming that's what's going on, is there an adjustment I can make
(perhaps to the flow graph, or to the PulseAudio blocks) to drop samples
instead of buffering?

[1]: https://github.com/bitglue/gr-pulseaudio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Synchronization in FreeDV (PSK FDM)

[Phil Frost]

I'm trying to demodulate FreeDV as a learning exercise. Without much
experience in DSP I'm afraid I'm lost in the source code :(

The modulation consists of 15 subcarriers each with a symbol rate of 50
per second, spaced 75 Hz apart. The center subcarrier is BPSK and
alternates phase every symbol (to help with synchronization) and the
rest are QPSK with the encoded data.

I'm having trouble wrapping my head around how to demodulate this. I've
gone through the PSK demodulation tutorial and I'm trying to apply it to
this problem.

I've started by using the polyphase channelizer with a root raised
cosine filter to extract each subcarrier, and that much seems to work.
I'm not sure then how to proceed with timing recovery. The tutorial uses
the polyphase clock sync for this, but since the signal has already gone
through the RRC filter in the channelizer, going through another RRC
does not seem correct. And it seems rather inefficient to decimate each
channel, only to effectively interpolate it again for timing recovery.
How can I approach this?

Furthermore, it seems relevant all the channels share a clock: I'd think
I can use that somehow. Also the center subcarrier is sending a known
sequence of symbols and that should be worth something.

Some pointers to algorithms I should consider, and hopefully relevant
blocks would be very much appreciated.

___
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

[Phil Frost]

On 07/30/2013 08:51 PM, Gregory Warnes wrote:
> How about enclosing the bit-for-bit tests in 
> #ifdef IEEE754_Compliant
> ...
> #endif

Merely knowing that a platform conforms to IEEE 754 is not sufficient to
guarantee bit-for-bit compatibility. The order of operations also
matters, and compliers can, and do, re-arrange, eliminate, and combine
operations as an optimization. Even if the rounding rules are the same,
the cost of various operations or the primitive operations that are
available are not the same between platforms, so the optimizations also
differ, and also depend on compiler version and build environment.

Search http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html for
"float" for some idea of the myriad complier options which influence this.

Getting bit-for-bit IEEE 754 behavior on some platforms comes at the
expense of both speed and precision. For example, on the x87, the FPU
registers are 80 bits, and all register instructions operate on the full
80 bits, while IEEE 754 defines no such format (64 bits being the
closest). To avoid this requires -ffloat-store, which forces all
variables to be stored in RAM, which is a significant performance hit
for most programs and makes rounding error worse. I can't see this as
being good for gnuradio in any way.

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

[Discuss-gnuradio] Adjusting IQ balance for audio sources

[Phil Frost]

I'm wondering what block GnuRadio offers to adjust IQ balance to
maximize image rejection from an audio source. Is there a block
available, or a description of a (perhaps manual) algorithm I can
implement with existing blocks?

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

Re: [Discuss-gnuradio] Announcing new scheduler for GNU Radio

[Phil Frost]

On 04/17/2013 09:45 AM, Philip Balister wrote:

On 04/17/2013 04:26 AM, Josh Blum wrote:

Behind all of the GRAS fluff, the Theron C++ concurrency library is the
real scheduler.

>

I dislike projects that force you to enter an email address to download
the source and do not provide access to the project SCM. It makes
automated builds very difficult.


Looks like Josh has already solved that problem:

https://github.com/guruofquality/Theron

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

Re: [Discuss-gnuradio] Voice over IP using GNu Radio.

[Phil Frost]

On 03/03/2013 06:18 AM, Sajjad Safdar wrote:

Is there any way of transmitting voice over ip using GNu Radio Companion.


To the extent that you can define what networking, modulation, and VoIP 
protocols you intend to use, yes.


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