Closed sp5wwp closed 1 year ago
In order to try and separate the faulty emitter or receiver: is this signal broadcast by the USRP properly decoded by the RTL-SDR fetching another reception software implementing M17?
Yes. It works flawlessly with SDR++ software. I think the problem resides in the symbol sync block. The symbol stream at the output looks fine to me, so I have no idea what might be going wrong there. Can you take a look to confirm?
The general_work
method does not preserve any state, so each time a (small) batch of symbols arrives it starts in the unsynchronized state, and there are never enough symbols to proceed to decoding.
The state variables (last
, syncd
, pld
, pushed
, etc.) need to be member variables of the m17_decoder_impl
class, not local variables in the general_work
method.
Fantastic, thank you for identifying my mistakes and providing the means to correct.
I believe commit d8b2139411371265c3fc082621ed937b53667f1d allows for running the m17_loopback_noisychannel.grc (which includes the modulation and demodulation) example that had been resisting so far while keeping the m17_streamer.grc functional.
Thank you ! I am away from the lab and cannot test on actual hardware but am looking for some feedback on PlutoSDR and possibly RTL-SDR.
It's actually a separate issue, but the 8.28 value for cross-correlation computations is wrong.
#define CODE_STD 8.78 // std(str_sync)*sqrt(length(str_sync))
when it should be
#define CODE_STD 8.21583836f //std(str_sync)*sqrt(length(str_sync)-1)
This gives value of 1.0 for ideal correlation, rather than 0.935 in your case.
And one more fix that needs to be pulled in: https://github.com/M17-Project/M17_Implementations/pull/6
last
also needs to be changed to a member variable. Once that is done, the decoder block appears to work correctly.
Fixed?
With this changeset, things are more or less working:
diff --git a/lib/m17_decoder_impl.cc b/lib/m17_decoder_impl.cc
index 7299c3300e..a7f5b083a6 100644
--- a/lib/m17_decoder_impl.cc
+++ b/lib/m17_decoder_impl.cc
@@ -42,7 +42,7 @@
//#define XCORR_THRESHOLD 0.90 // arbitrary threshold between 0 and 1: might be tunable from GNU Radio Block for flexibility
#define CODE_MEAN -0.75 // mean(str_sync)
-#define CODE_STD 8.78 // std(str_sync)*sqrt(length(str_sync))
+#define CODE_STD 8.21583836f //std(str_sync)*sqrt(length(str_sync)-1)
// see ../M17_Implementations/SP5WWP/inc/m17.h for const int8_t str_sync[8]={-3, -3, -3, -3, +3, +3, -3, +3};
@@ -105,6 +105,7 @@ void decode_callsign(uint8_t *outp, const uint8_t *inp)
encoded/=40;
i++;
}
+ outp[i] = 0;
}
m17_decoder::sptr
@@ -167,7 +168,6 @@ void m17_decoder_impl::set_debug_ctrl(bool debug)
int countout=0;
float sample; //last raw sample from the stdin
- float last[8]; //look-back buffer for finding syncwords
float xcorr; //cross correlation for finding syncwords
float meanx; //mean value
float normx; //cross correlation normalization
diff --git a/lib/m17_decoder_impl.h b/lib/m17_decoder_impl.h
index 84b0207fb2..c43fd027a8 100644
--- a/lib/m17_decoder_impl.h
+++ b/lib/m17_decoder_impl.h
@@ -25,6 +25,7 @@ private:
bool _debug_ctrl=false;
float _threshold=0.9;
+ float last[8] = {0}; //look-back buffer for finding syncwords
float pld[SYM_PER_PLD]; //raw frame symbols
uint16_t soft_bit[2*SYM_PER_PLD]; //raw frame soft bits
uint16_t d_soft_bit[2*SYM_PER_PLD]; //deinterleaved soft bits
Let's incorporate these changes?
OK, I committed those fixes to the main branch.
I'm still seeing broken packets printed sometimes during startup, so there could still be a bug or two.
Some other issues I noticed:
lich_chunks_rcvd
should probably be reset when an LSF is receivedfl
is not set to 1 until an LSF is receivedI'm going to close this issue as resolved. Other bugs can be reported with separate issues.
I have set up a simple M17 receiver as follows:
The resulting eye diagram is pretty decent
however, I'm not able to get any decode.
payload.bin
is empty, the log is empty too. My transmitter is a USRP B210 with GNURadio running flowgraph shown below.