well, looks OK, looks like it is worked as expected. but...
It's like the demod freezes. and freezes and doesnt update the UW
buffer......
and rx_uw[i] is not being updated.
HMM but
LINE 1495:
ofdm->uw_errors+= ofdm->tx_uw[i] ^ rx_uw[i];
ERRR AHH ofdm->tx_uw[i] IS set to zero (line 242....) and never
updated in that file.
and I cannot find it being updated anywhere else ?
so is it waiting until rx_uw is all zeros, also? maybe , maybe not. and
it waits until rx_uw is non zero ( a whistle) , because the input level
is low (squelched ????) and rx_uw is zero filled.) ?
can you pls inspect ofdm->tx_uw[i] and rx_uw[i] ? they are ofdm->nuwbits
in length of type uint8.
you might need to add after the print that you added :
for(i = 0; i < ofdm->nuwbits; i++) {
printf("%0u",(unsigned int) ofdm->tx_uw[i]);
}
printf("\r\n");
for(i = 0; i < ofdm->nuwbits; i++) {
printf("%0u",(unsigned int) ofdm->rx_uw[i]);
}
printf("\r\n");
AND OR
the amplitude is super low and the UW word buffer is not getting
flushed with the new noisy frames because the demod goes unlocked.
Do you have plenty of noise going into the demod when the signals
disappear ? what happens if you crank up the level by 10x ?
NOW.....
(I dont know the demod very well, yet - learning little pieces a bit at
a time)
The UW being 0 in the period following the
*state: Rx Sync peak: 106 sync: 1 SNR: 1.2 triggered:
1 recordany: 0 rxDataCnt 1414 ncodec 14*
*SYN: 2 0 1 0 *
*SYN: 2 2 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 1 1 0
*
On 7/15/2020 9:09 PM, Al Beard wrote:
*Hi Glen,*
*
*
*Done as asked... SYN: sync_state, uw_errors, sync_mode, sync_counter*
*
*
*SYN: 2 0 1 0 good solid reception of ve9qrp_700d.wav*
*state: Rx Sync peak: 1901 sync: 1 SNR: 15.7
triggered: 1 recordany: 0 rxDataCnt 1218 ncodec 14*
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
* RX txtMsg: cq cq cq hello world*
* Tx triggered!*
*SYN: 2 0 1 0 *
*
*
*......*
*
*
*SYN: 2 0 1 0 *
*SYN: 2 2 1 0 reception of ve9qrp_700d.wav is over, *
*SYN: 2 1 1 0 *
*state: Rx Sync peak: 106 sync: 1 SNR: 1.2
triggered: 1 recordany: 0 rxDataCnt 1414 ncodec 14*
*SYN: 2 0 1 0 *
*SYN: 2 2 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 0 1 0 *
*SYN: 2 1 1 0 *
*SYN: 2 4 1 0 here I whistle into the mic*
*state: Rx Sync peak: 748 sync: 1 SNR: 3.5
triggered: 1 recordany: 0 rxDataCnt 1428 ncodec 14*
*SYN: 2 2 1 1 *
*SYN: 2 1 1 0 *
*SYN: 2 8 1 0 *
*SYN: 2 5 1 1 *
*SYN: 2 6 1 2 *
*SYN: 2 6 1 3 *
*SYN: 2 3 1 4 *
*state: Rx Sync peak: 821 sync: 1 SNR: -4.6
triggered: 1 recordany: 0 rxDataCnt 1428 ncodec 14*
*SYN: 2 6 1 5 *
*SYN: 2 3 1 6 *
*state: Rx Maybe UnSync peak: 110 sync: 0 SNR: -8.4
triggered: 1 recordany: 0 rxDataCnt 1428 ncodec 0*
No more SYN: n n n n messages.
*Over to you...*
*
*
*Alan VK2ZIW*
*
*
*
*
*On Wed, 15 Jul 2020 19:43:37 +1000, glen english wrote*
> Alan, please be sure to keep correct subject line.
> Right. ofdm.c
> voidofdm_sync_state_machine(structOFDM *ofdm, uint8_t*rx_uw)
> there are two synced states, synced (ongoing) and trial sync (when
sync is getting established for the first time- checking if this is
real sync or bogus sync due to frquency offset aliasing)
>
> the difference in bits between the unique word template and the
actual received unique word is checked
> (lines 1494..1496)
>
> When synced (ongoing) if the unique_word (uw_errors) error count
is > 2 (IE more than 2 bits different from the template,
ofdm->sync_counter is incremented.
> when ofdm->sync_counter is >6 AND ofdm->sync_mode== autosync (line
1540) , sync will be dropped.
> So, since you can compile from source, I'd like you to insert some
extra debug printfs or whatever and above line 1533,
> IE immediately before
> if(ofdm->sync_state== synced) {
> please print out : (just use %u style, that's fine, do a explicit
cast to unsigned int for each variable in case they are chars )
> ofdm->sync_state
> ofdm->uw_errors
> ofdm->sync_mode
> ofdm->sync_counter
> IE
> printf("SYN: %u %u %u %u \r\n",(unsigned int) ofdm->sync_state, etc etc
>
> just the integer values will be fine, we can look up the numbers.
> So the sync state machine could do with some refinement, could be
error easily programmer error prone . I will put that on my to-do list
to re write .
>
> On 7/15/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
>
>
---------------------------------------------------
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 trading as Cortex RF
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
