These are from a gmsk mod/demod pair, showing the output of the TX’s
gaussian filter (blue) overlaid with the output of the RX’s fmdemod
(red).
BT = 0.35.
At 8 samples per symbol, everything looks ok. Red is pretty much right
on
top of blue, as we’d expect.
As I increase samples per symbol, however, something strange happens,
shown
in plot sequence. The RX’s fmdemod output gets successively more
“glitchy”.
If I (in python) do the same thing that gr_quadrature_demod_cf is doing
in
C, ie:
def fm_quadrature_demod(re, im, gain):
num_c = min(len(re),len(im))
out = []
for i in range(1,num_c):
prod =
complex(re[i],im[i])(complex(re[i-1],im[i-1]).conjugate())
out.append(gainatan2(prod.imag, prod.real))
return out
the glitches do not exist. This tells me that TX fmmod output is fine.
Something is going wonky as gr_quadrature_demod_cf does its work. Any
ideas?
Is this a problem with the scheduler?
Code attached (incidentally, I tried using the old style flowgraph,
without
hier_block2 / top_block, glitches were still present).
As I increase samples per symbol, however, something strange happens,
shown in plot sequence. The RX’s fmdemod output gets successively more
“glitchy”.
This might be because of the use of gr_fast_atan2f. This function is an
approximation used in order to speed things up since the real atan2f is
slow. Could you try replacing line 58 of gr_quadrature_demod_cf:
and see if the problem persists? When doing very high oversampling like
you are, the difference in phase angles between successive samples is
very small. If the error when doing the lookup table interpolation
changes a bit when crossing over the endpoints of the table, you could
see this sort of effect. You’ll notice that the errors are always at
the same point in the diagram, around the mid-level, which is where the
frequency is lowest.
Thanks Matt, I understand the issue now and switching atan functions
does
indeed make the glitches go away.
Do you have a sense of how much slower the regular atan2f function is
than
gr_fast_atan2f?
If the performance hit isn’t too bad, I might leave it in for peace of
mind.
Regarding excessive oversampling: I agree that 64, 128, etc. samples per
symbol is pretty ridiculous, I was just seeing how the issue scaled with
sps.
What is the best strategy when you want to rx a signal at a very slow
symbol
rate? Max decimation (256?) on the USRP, then decimate/filter some more
in
software? As an arbitrary example, symbol rate 7812.5 sym/sec: have the
usrp
decimate by 256 and you’re still at 32 samp/sym. What is the best way to
partition decimation between hw and sw? Which sw blocks are ideal for
this?
Thanks Matt, I understand the issue now and switching atan functions
does indeed make the glitches go away.
Great!
Do you have a sense of how much slower the regular atan2f function is
than gr_fast_atan2f?
I think Eric looked at it a while ago when he wrote it.
If the performance hit isn’t too bad, I might leave it in for peace of
mind.
You are dealing with very low sample rates, so I wouldn’t worry about
the performance.
What is the best strategy when you want to rx a signal at a very slow
symbol rate? Max decimation (256?) on the USRP, then decimate/filter
some more in software? As an arbitrary example, symbol rate 7812.5
sym/sec: have the usrp decimate by 256 and you’re still at 32
samp/sym. What is the best way to partition decimation between hw and
sw? Which sw blocks are ideal for this?
In general, decimate as much as possible in hardware, where it is free.
However, I usually try leaving the last 2x (or more) for the software
decimator, which will have higher precision and better filter skirts.
In software, use the standard gr_fir_filter blocks, and just set the
decimation rate (which is the first parameter, I think).
As I increase samples per symbol, however, something strange happens,
shown in plot sequence. The RX’s fmdemod output gets successively more
“glitchy”.
One other thing – you really shouldn’t be going to more than 8:1
oversampling on GMSK anyway – all the timing recovery stuff will have
trouble with that high of an oversampling rate when you have noise on
the signal. We still need to fix this problem, but I would advise
staying at 8:1 or lower. Your bandpass filtering also becomes harder at
the higher oversampling ratios.
When I wrote a fast atan table look algorithm a long time ago ( and I
have no recollection if our stuff traces its ancestry to that or not) I
picked the table size for my problem at the time. There is a large
speed up using the table lookup algorithm even on today’s machines but
there is no reason we can’t increase the size of the table to get a
better approximation and the theoretical speed will be the same but with
decreased average error. The trade off is that the table becomes very
large as you demand higher accuracy. We could in fact make the error
demand an input and compute the table on set up.
Things to think about when you are otherwise indisposed. ;-).
Bob
Johnathan C. wrote:
Steven C. wrote:
Do you have a sense of how much slower the regular atan2f function is
than gr_fast_atan2f?
I don’t think there were any formal benchmarks done, but IIRC the fast
atan2 reduced CPU utilization by a factor of 5 for a WFM demodulator.
–
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“If you’re going to be crazy, you have to get paid for it or
else you’re going to be locked up.” Hunter S. Thompson