GR-RDS .rx
sterlan opened this issue · 8 comments
Hi there.
I Downloaded your rds_rx.grc flowgraph, currently im using Adalm-Pluto and i edited the file and it looks perfectly!
But there is a point i cant understand. How did you configure the value of rrc_taps_manchester? (->> [rrc_taps[n] - rrc_taps[n+8] for n in range(len(rrc_taps)-8)]? I mean, i can't really understand what this is doing. Whats the difference between using a Decimating FIR FIlter using rrc_taps_manchester , instead of using a Root Raised Cosine Filter?
Your work is awesome btw.
Thanks a lot for the Help,
hope you are doing great!!
rrc_taps_manchester is the convolution of the RRC filter with a Manchester-encoded bit (01).
Okay, makes more sense now. But i really cant understand the formula-calculation. From where the formula " [rrc_taps[n] - rrc_taps[n+8] for n in range(len(rrc_taps)-8)] ", came from? Im searching like a maniac in Books and the entire Google for over a week and this is the only part i really can't understand. Any explanation would be wonderful, because sharing knowledge nowadays for free is something else and is appreciated a lot!!
Thank you Argilo!
The two halves of a manchester symbol are +1 and -1, and they are 8 samples apart. That formula calculates the convolution of rrc_taps with [1, 0, 0, 0, 0, 0, 0, 0, -1].
The result should be a matched filter for one manchester-encoded bit.
Seems now its way more clear.
I completely understand(We resampling at 19kS/s), and because manchester coding sents the combination of [+1, -1], the symbol rate from 1187.5 bits/s, now gets doubled and become 2375 bits/s.
Deviding 19.000(Samples/Second) / 2375 bits/sec(which is the symbol rate), we now have a Sample per bit that equals 8. That means that one symbol transmission require 8 samples. Also, for decoding, i found that the output of the decoding manchester is:
- 1 - (-1) = 2 > 0, so the output is logic 1.
- -1 - 1 = -2 < 0, so the output is logic 0.
Now its completely understandable why in rrc_manchester_taps , there is the equation : [rrc_taps[n] - rrc_taps[n+8]. But since the two halves are 8 samples apart, should we use "n+7" rather than "n+8" ? Seems its working too with "n+7" in my flowgraph.
Thanks a lot Argilo, the answers you gave me are appreciated a lot!
But since the two halves are 8 samples apart, should we use "n+7" rather than "n+8" ?
No, n+8 is the correct offset since it is 8 samples after n.
Seems its working too with "n+7" in my flowgraph.
It will still work since the shape of the filter will be close, but the quality of the matched filter will be worse if you use the incorrect offset.
Thanks a lot for the useful tips! Im almost done with my implementation. But i have a final question here:
-> Symbol Sync Block is used for the clock-timing recovery. Do we have a specific reason that we use the Zero Crossing TED? It works with Early-late or Gardner too, but with Zero Crossing the flowgraph has better performance.
Thanks a lot, again!
Do we have a specific reason that we use the Zero Crossing TED?
Not really. I don't know much about timing error detectors, so I just tried them all to see which would work well.