well, there is either a state machine error

or the SYNC IN to SYNC OUT threshold/filter is too low for some noise characteristics

I can look at it at some point

Al, can you please get a WAV fle recording of this occurring, as many seconds or minutes or hours as required

raw wave files, no compression

Then, David and I can look at the problem .


On 15/07/2020 8:02 am, Al Beard wrote:
Hi Glen and David,

In my testing of "parrot" derived from "freebeacon", mode 700D,
I'm "seeing" sync holding up when it shouldn't.

I'm running relatively low input levels, similar to what
an FM receiver might do when the mute is closed.

state: Rx Sync               peak:   1981  sync: 1  SNR: 16.3  triggered: 1 recordany: 0 rxDataCnt 9492 ncodec 14  <- valid signal state: Rx Sync               peak:   2215  sync: 1  SNR: 16.2  triggered: 1 recordany: 0 rxDataCnt 9590 ncodec 14 state: Rx Sync               peak:    124  sync: 1  SNR: 9.9  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 <- signal lost background noise into mic. state: Rx Sync               peak:    126  sync: 1  SNR: 7.9  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 state: Rx Sync               peak:    105  sync: 1  SNR: 7.0  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 state: Rx Sync               peak:    118  sync: 1  SNR: 7.5  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 state: Rx Sync               peak:    120  sync: 1  SNR: 8.6  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 state: Rx Sync               peak:    113  sync: 1  SNR: 8.3  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 state: Rx Sync               peak:    129  sync: 1  SNR: 5.7  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 state: Rx Sync               peak:    119  sync: 1  SNR: 3.7  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 state: Rx Sync               peak:    713  sync: 0  SNR: -7.0  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 14 <- me whistling to get it out of this silly state state: Rx Maybe UnSync       peak:    130  sync: 0  SNR: -7.7  triggered: 1 recordany: 0 rxDataCnt 9632 ncodec 0

At this point, I'm hoping the SSB receiver will feed in sufficient noise and "sync" will "behave".

Alan VK2ZIW


On Wed, 15 Jul 2020 06:09:44 +0930, David Rowe wrote
> Hi Glen,
>
> Yes cohpsk_ch could be used to apply amplitude variations.
>  Replaying a chunk of your stored samples that demonstrates the
> issue is also a good approach.
>
> You can also run the Octave version of the 700D demod, which will
> give a better view of the modems internal states.  You won't be able
> to measure BER, but you'll be able to see if the LDPC decoder is
> converging, and if the demod is falling over in the fast ALC condition.
>
> - David
>
> On 14/7/20 5:09 pm, glen english wrote:
> > OK, in addition to my actual recordings,
> >
> > that would be using :
> >
> > https://github.com/drowe67/codec2/blob/master/src/cohpsk_ch.c
> >
> > together with
> >
> > https://github.com/drowe67/codec2/blob/master/octave/cohpsk_ch_fading.m
> >
> > ?
> >
> > On 7/14/2020 5:23 PM, David Rowe wrote:
> >> Hi Glen,
> >>
> >>> /* update mean amplitude estimate for LDPC decoder scaling */
> >>>
> >>>      ofdm->mean_amp = 0.9f * ofdm->mean_amp + 0.1f * sum_amp /
> >>> (ofdm->rowsperframe * ofdm->nc);
> >> Yes, that's used for LDPC decoding so could be related.
> >>
> >> It would also be useful to have a repeatable unit test to explore the > >> issue, e.g. a repeatable fading profile running with the command line
> >> version of the modem.
> >>
> >> Cheers,
> >> David
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Freetel-codec2 mailing list
> >> Freetel-codec2@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> >
>
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2


---------------------------------------------------
Alan VK2ZIW

OpenWebMail 2.53, nothing in the cloud.


_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

--
Glen English
RF Communications and Electronics Engineer

CORTEX RF
&
Pacific Media Technologies Pty Ltd

ABN 40 075 532 008

PO Box 5231 Lyneham ACT 2602, Australia.
au mobile : +61 (0)418 975077




_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to