Modifications to the FM stereo receiver have been underway for two
days. Nothing that changes the way things work inside the FM stereo
receiver were included in the tar balls. However a change that could
change the way you use gr_pll_carriertracking has been submitted and was
in the tar ball.
Before, the code (incorrectly in my estimation) returned the complex
conjugate of the recovered carrier. This has been “corrected” to be
return the recovered carrier. If you need a conjugate from this,
accomplish it in your code. Bugs in the locking, squelching mechanism
in this routine were also submitted and are in the tar balls.
In wfm_rcv_pll.py one can find commented out the two line beginning of
the correct way to do the FM stereo carrier recovery.
Right now we simply filter and multiply. This introduces phase noise,
inconsistent amplitudes, and makes no provision to squelch the additive
demultiplexing signal in the case of poor signal or absent stereo
carrier. As a result as you are tuning, the noise floor sounds
particularly harsh. In the new scheme, if all works out well, all
noise will be squelched. The user will be provided a way to set their
“squelch” tolerance level. Mine is pretty low. I do not like to listen
to crackly music and the talking heads are irritating enough without
being modulated with FM recovery noise!
We are attempting to provide for RDS use with this as well and there the
phase noise becomes more important.
As soon as we have the carrier recovered and the amplitudes balanced
again, we will deliver the rds signal (at 3X the stereo carrier) to a
null sink until such time as we get the rds code sent here earlier
integrated into the project.
I hope these changes did not inconvenience anyone. I had my head in the
sand and did not realize we were making these tar balls for the next web
distro. I will resume this work now that we have the tar balls.
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540