Rx decoders #1153
Open
Rx decoders #1153
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
WOW! I'll try to rebase this on top of my dev branch and test. |
|
I think, it may be better to fix individual commits (tabs to spaces, minimize boost usage, fix compatibility with newer and older GNU Radio versions) |
mcapdeville
force-pushed
the
rx_decoders
branch
3 times, most recently
from
d1f4ae5
to
07625d8
Compare
|
The CI still fails. I've tested the RTTY decoder and it sort-of works on strong signals. It produces many garbage symbols from noise when there is no signal and does not decode weak signals well. Carrier detector missing? |
|
The CI is passing. You may ignore MacOS build if you do not have a developer certificate. |
|
Testing (2/10): https://github.com/vladisslav2011/gqrx/tree/rx_decoders_test |
|
Testing (10/10). |
|
Wow, quite the patch! I wonder if we should have the GR blocks as a separate package somehow. They seem like they would be useful to other projects. No specific ideas on how to do this. |
mcapdeville
force-pushed
the
rx_decoders
branch
2 times, most recently
from
208e43a
to
104f934
Compare
|
Hi, thanks for your comments. Marc F4JMZ |
|
Hello. The main problem is not the sensitivity. The main problem is incorrect filtering... The RRC filter does not fit well here. More possible RTTY decoder improvements: Better symbol synchronization: delay decoding by 10 symbols; check, that there are 10 valid, almost noise-free symbols in a buffer before switching to a CD state; check that next 10 symbols does not look valid and exit CD state. Save settings to a config file and restore settings at startup. Carrier detection and logging timestamps and signal power ("\n2022-10-18T00:00:00Z [30db] " style prefix on CD). An option to enable unattended logging to a text file on GNU Radio side (to make it more compatible with multi VFO implementations). Suggested file name template: "gqrx_[date]_[freq]_rtty.txt". An option to select a directory to write RTTY log files. |
|
Marc, 2011,
adding to what's written below, RTTY uses a truly *ancient* modulation
system. Two tones are specified—mark and space—but with no specification
as to how to transition from one to the other. The transition could be a
glide (FM), or it could be an amplitude controlled stop of one and start
of the other (AM), or an abrupt stop of one and start of the other.
There is *no matched filtering*. To a modern communication engineer, the
whole thing is horrific!
A traditional analogue decoder would use a pair of [audio frequency]
tuned circuits, with their centre frequencies separated by the shift
used. Traditionally that was 850 Hz, and later 170 Hz which reduced
spectrum occupancy. The output from each tuned circuit is rectified to a
DC voltage, and then sliced. This is crude. A decoder which copes better
with selective fading uses a slicer on each output, so that there is a
mark slicer and a space slicer. That allows each channel to behave as if
it were on/off keyed when the other channel fades out. A further slicer
then selects the dominant channel for decoding, or uses both when
signals are strong enough. Generally, one unit is good enough to deal
with 45.45, 50 or 75 baud symbol rate.
These days, one would write a decoder in software rather than hardware,
of course! Which is where we started. Why does an RRC filter ([square]
root raised cosine filter) perform badly? It's what a more modern design
might use to enable effective matched filtering. A single RRC filter
distorts the pulse, giving rise to inter-symbol interference (ISI). (Two
RRC filters in series—one at a transmitter, one at a receiver—give no
ISI.) A digital band-pass filter (BPF) provides essentially constant
group delay, and thus little pulse distortion. Even better, a digital
BPF can offer far better filtering performance than a simple 2nd order
(tuned circuit equivalent) filter.
How might one detect a signal? The "obvious" answer is to detect
sustained transitions at a rate of 45.45, 50 or 75 Hz, noting that every
character ends with a stop signal at least 1.5 units long for a 5-level
code. In other words, unless it looks like an RTTY signal, then the
squelch need not be opened.
That raises another issue. The parameters of an RRC filter depend on the
symbol rate, assuming a constant β. Thus the channel filter would be
required to change its bandwidth depending on the signal received,
assuming that the transmit channel were similarly filtered—which, in
this case, it's not. [An RRC filter only offers zero inter-symbol
interference when there are two such filters in series, as noted above.]
And as a final note, an RTTY signal is only synchronous within a single
character.
HTH, 73, Stay Safe,
Robin, G8DQX
PS: The Wikipedia article on RTTY/Radiotelegraphy is very light on
specific technical detail
(https://en.wikipedia.org/wiki/Radioteletype#Technical_specification).
On 18/10/2022 11:32, vladisslav2011 wrote:
Hello.
Thanks. I'll pull your latest changes and test.
The main problem is not the sensitivity. The main problem is incorrect
filtering... The RRC filter does not fit well here.
Just replacing the RRC with a complex bandpass makes FSK demodulator
work much, much better. Most moderate-powered signals can be decoded
and some weak signals can be decoded too (with a lot of garbage).
Common Gqrx simple_squelch/pwr_squelch does not work well on FSK
signals. It either opens too often (on pulsed/wideband interference),
producing garbage or does not open on a weak signal. I think, the
squelch should operate on space-mark difference instead of absolute level.
I think, if a signal can be "decoded visually" from the waterfall (see
picture), it should be decoded perfectly by the decoder.
bandpass
<https://user-images.githubusercontent.com/17007837/196402035-017d2e18-8c84-4336-9878-fc069e56920a.png>
More possible RTTY decoder improvements:
Better symbol synchronization: delay decoding by 10 symbols; check,
that there are 10 valid, almost noise-free symbols in a buffer before
switching to a CD state; check that next 10 symbols does not look
valid and exit CD state.
Save settings to a config file and restore settings at startup.
Carrier detection and logging timestamps and signal power
("\n2022-10-18T00:00:00Z [30db] " style prefix on CD).
An option to enable unattended logging to a text file on GNU Radio
side (to make it more compatible with multi VFO implementations).
Suggested file name template: "gqrx___rtty.txt". An option to select a
directory to write RTTY log files.
Message ID: ***@***.***>
|
mcapdeville
force-pushed
the
rx_decoders
branch
from
104f934
to
a7256f4
Compare
|
Hi, what's news :
Marc F4JMZ |
|
Is there an ETA on this ? |
|
No, there is not. I'll review this when I get a chance, but I don't know when that will be. |
mcapdeville
force-pushed
the
rx_decoders
branch
from
b0740b8
to
50c4bed
Compare
argilo
reviewed
Nov 4, 2023
src/dsp/fax/fax_store.h
Outdated
| std::mutex d_mutex; | ||
|
|
||
| int d_len; | ||
| boost::circular_buffer<std::vector<unsigned char>> d_data; |
There was a problem hiding this comment.
Gqrx does not use boost (except boost::shared_ptr, which is required to support GNU Radio 3.8, and will be removed as soon as Gqrx stops supporting 3.8). I don't want to add back boost as a dependency, so this will need to be replaced with either something in the standard library, or else a GNU Radio circular buffer.
argilo
reviewed
Nov 4, 2023
src/dsp/rtty/char_store.h
Outdated
|
|
||
| void store(std::string data); | ||
| std::mutex d_mutex; | ||
| boost::circular_buffer<std::string> d_data; |
There was a problem hiding this comment.
As above, this should be replaced with something else.
argilo
reviewed
Nov 4, 2023
src/dsp/rtty/fsk_demod_impl.h
Outdated
| int cd_count; | ||
|
|
||
|
|
||
| boost::circular_buffer<char> last_samples; |
There was a problem hiding this comment.
As above, this should be replaced with something else.
argilo
reviewed
Nov 4, 2023
src/dsp/fax/fax_demod.h
Outdated
| #include "fax_demod.h" | ||
| #include "dsp/fax/fax_decoder.h" | ||
| #include "dsp/fax/fax_store.h" | ||
| #include "vector" |
There was a problem hiding this comment.
Suggested change
| #include "vector" | |
| #include <vector> |
|
Some errors are printed during startup: |
|
Gqrx now warns about implicit promotions from float to double ( |
|
Valgrind reports various errors. They appear to be due to various variables (e.g. |
mcapdeville
force-pushed
the
rx_decoders
branch
from
50c4bed
to
ed2dacf
Compare
|
Hi, thanks for your revue. Marc F4JMZ |
|
Thanks for making those improvements. Unfortunately the updated code does not compile due to the following error: |
|
Sorry, It seems that M_PIf is not define on all platform. It is on debian 12 with libc6-dev:amd64 version 2.36-9+deb12u2. |
mcapdeville
force-pushed
the
rx_decoders
branch
from
ed2dacf
to
ef7774e
Compare
To be able to have more than one digital decoder in rx chain and not to add a per decoder interface, this patch make a generic interface to decoders implemented in rx chain. Decoders are asign an identifier : enum receiver_base_cf::rx_decoder Function added : start_decoder(enum rx_decoder decoder_type) stop_decoder(enum rx_decoder decoder_type) is_decoder_active(enum rx_decoder decoder_type) reset_decoder(enum rx_decoder decoder_type) get_decoder_data(enum rx_decoder decoder_type,void* , int&) set_decoder_param(enum rx_decoder decoder_type, std::string param, std::string val); get_decoder_param(enum rx_decoder decoder_type, std::string param, std::string& val); in receiver_base_cf class : decoder_type is one of enum receiver_base_cf::rx_decoder : RX_DECODER_ALL, RX_DECODER_NONE, RX_DECODER_ANY, follows by any added decoder type, ending with RX_DECODER_MAX. multiplexing between receiver::rx_decoder and rx_chain dependent decoder type is done in applications/gqrx/receiver.cpp RX_DECODER_ALL and RX_DECODER_ANY are for convenience in statement if (decoder_is_active(RX_DECODER_ANY) reset_decoder(RX_DECODER_ALL )
decoder type for rds decoder is RX_DECODER_RDS Function renamed : get_rds_data(std::string, int&) -> get_decoder_data(RX_DECODER_RDS,void* , int&) start_rds_decoder() -> start_decoder(RX_DECODER_RDS) stop_rds_decoder() -> stop_decoder(RX_DECODER_RDS) reset_rds_parser() -> reset_decoder(RX_DECODER_RDS) is_rds_decoder_active() -> is_decoder_active(RX_DECODER_RDS)
mcapdeville
force-pushed
the
rx_decoders
branch
from
ef7774e
to
d929fa2
Compare
|
There was other float to double implicit promotion that i've corrected in this last push. |
|
I'm not sure yet exactly how I triggered this, but I got a heap buffer overflow: |
|
It looks like you implemented your own queue from scratch to replace |
|
An error from UBSAN:
|
|
ASAN reports a memory leak: |
|
By the way, if you want to test your code with ASAN and UBSAN, you can add the following to src/CMakeLists.txt: |
mcapdeville
force-pushed
the
rx_decoders
branch
from
d929fa2
to
d7a5325
Compare
|
It seems that all these error are due to my implementation of circular buffer. I replace it by std::queue in this rewrite. |
Decoder_type for fax decoder is RX_DECODER_FAX
Dockable window to control fax decoder and display received image.
This is the rtty decoder dsp block for gqrx This block is to be plug in nbrx rx_chain.
Windows to control rtty decoder and display decoded text.
mcapdeville
force-pushed
the
rx_decoders
branch
from
d7a5325
to
50a62bc
Compare
|
And more float to double conversion that trigger warning on MacOs CI only. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
This patch serie add generic decoders interface to receiver class.
To be able to have more than one digital decoder in rx chain and not to
add a per decoder interface, this patch make a generic interface to
decoders implemented in rx chain.
Decoders are assign an identifier : enum receiver_base_cf::rx_decoder
wfmrx demodulator is tweaked so the rds decoder use this interface.
Then a radiofax and a rtty decoder are added to nbrx demodulator.
Marc F4JMZ