If disabled, make sure we don't try calling rade_text_* with a null pointer. #794
Conversation
|
I think this commit may have stopped EOO text working in the most recent couple of builds I have tested. I have reporting enabled, but even with very strong signals I see no decodes since using the older build without this commit. |
Not sure how since this is just a null pointer check that got added. Are you able to confirm that the commit in v2.0-dev prior to this one works fine? |
|
I have dropped this commit and will report what happens once I find some on air signals from stations with EOO-text enabled. There are a few in the UK. Are there some RADE test wav files with EOO text included that I can try? |
I can appear on 160, 80, 60 or 40m this evening or some time tomorrow to do some testing if you wish. It's a long shot but do you have an AllStar/EchoLink node for talk-back if needed? |
If you could simply come up on 40m then I can see if a high RADE SNR means I get a decode of the callsign, it didn't work for any of you earlier on 60m despite 20dB SNR at times. I have reverted what I suspect is the commit that broke it. Of course it could simply be that the fast fading channel is breaking the EOO Text where the RADE codec just doesn't care.
No, sorry I don't. |
|
Are you receiving? |
|
I wonder if it's some sort of audio delay between the application and say, pipewire. Maybe you can try different values for "RX/TX Delay" (Tools->Options->Rig Control) and seeing if that helps? |
|
Some experimentation this evening revealed that even with good 10dB+ SNR on RADE we are failing to get EOO-Text detection on a significant percentage of overs. What happens is that as the transmitting station drops PTT there is almost no noise heard if EOO detection is successful, but if it isn't there is a noticeable amount of garbage "speech-alike" sound which is a bit like 700 modes sound with marginal error rates. I don't think this particular commit is the problem, but maybe some more debug output from the receive side at end of over would be useful. |
It does kinda sound like PTT may be dropping too soon at least some of the time. I'd suggest trying the RX/TX Delay option I mentioned above; perhaps there's some value for delay that will make decodes more likely. Also, do you have any recordings that you can try playing back? We can at least see if that decodes reliably too. |
|
I would expect PTT to be held until EOO-Text blocks are sent, and indeed the debug shows that: 20:56:48 INFO /home/bdm/git/freedv-gui-v2.0-ms-rade-snr/src/pipeline/TxRxThread.cpp:649: Triggering sending of EOO What I was wondering is if some extra debug might be useful before these messages are output: 20:53:07 INFO /home/bdm/git/freedv-gui-v2.0-ms-rade-snr/src/pipeline/rade_text.c:210: mean amplitude: 1.798888 I have not looked at the rade_text.c code to see what might be available at that point, but maybe we need to see what has been detected to actually call the code that output the debug above. Is that part of the RADE demodulator/decoder function? |
|
@Tyrbiter During some long CQ sessions I discovered that the callsign reporting is working perfectly when using the voice keyer, the callsign is also appearing in the text area below the 'scope'. No misses seen at all. When using the PTT I am hearing the garbage at EOO that you reported to me on 80m and no callsign is reported. I do already have 100ms TX/RX delay set up in FreeDV as I have been testing a linear amplifier. This makes me wonder if its a timing issue since I assume that the manual PTT OFF event and the program controlled VK EOO will be initiated in totally different ways. |
|
I created #800 as a place to put some WIP stuff while we figure this out. It's possible that the PR as is will help, but I'm not fully sure yet. Give it a try and leave comments there? |
|
I have done some more testing tonight using latest ms-rade-snr (#d47135) Following on from "I'd suggest trying the RX/TX Delay option I mentioned above; perhaps there's some value for delay that will make decodes more likely." Yes, that makes a difference. G4DYA was using this version today and he was also crashing during RX during the net. First the crash: I will re-test the delay in #93c1a0 which did not crash. OK, been re-testing #93c1a0 and I have seen the crash a couple of times but with 300ms delay the callsign is reporting reliably using PTT. I got the feeling that the crashes were more likely with low SNRs (QSB) but could be wrong. `21:40:44 DEBUG /home/baz/freedv-rade/freedv-gui/src/pipeline/rade_text.c:310: RX symbol: -0.213445, -0.817682 4330 state: search valid: 1 0 25 Dthresh: 0.04 Dtmax12: 0.16 0.31 tmax: 124 fmax: 7.50 SNRdB: 16.55 |
|
Looks like #799 got created for the crash bug, so we'll add further comments over there. |
|
barjac and I did a test earlier today, both running 2a40daa with no extra TX/RX delay in the Rig Control tab. Both eoo callsigns and snr are now showing in FreeDV reporter reliably. The callsign seems to need an snr of a plus a few dB to work reliably, a bit more than needed to decode speech. |
This PR prevents calling
rade_text_rx()on EOO if the user's disabled reporting. Without this change, errors similar to the following are possible: