Hi Glen and David, No problem, as parrot/freebeacon records everything.
Files on http://www.unixservice.com.au/parrot/ofdm 5.5 Mb of files. `date`_q.raw is going to the transmitter. BTW: the ":" colon in the date string is a pain. Replaced with "-". (I use "scp" to xfer files) One thing of note, in the text string, I'd like to be able to remove my repeater trigger string, so that if the next repeater repeats and my repeater receives, it won't retransmit this message again. Sending the unmodified raw Rx data, doesn't allow me to change the text as far as I know. Is this true? Or, is there a way? Alan VK2ZIW On Wed, 15 Jul 2020 09:52:02 +1000, glen english wrote > 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 > > > >> [email protected] > > > >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > > > > > > _______________________________________________ > > > Freetel-codec2 mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > > > --------------------------------------------------- > > Alan VK2ZIW > > > > OpenWebMail 2.53, nothing in the cloud. > > > > > > _______________________________________________ > > Freetel-codec2 mailing list > > [email protected] > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 --------------------------------------------------- Alan VK2ZIW OpenWebMail 2.53, nothing in the cloud. _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
