Re: [Svxlink-devel] ToneDetector news
Brought to you by:
sm0svx
From: Tobias B. <sm...@us...> - 2011-11-28 22:36:42
|
On Sunday 27 November 2011 19.56.28 st...@ar... wrote: > Hi Tobias, > > I've done some further experiments with the ToneDetector code and > came to the conclusion, that the the phase detector is less critical > in terms of bandwidth, but should be period-aligned to simplify > calculations. This is the way you've also implemented in the > improved voter branch. The period alignment is no problem for > low tone frequencies / bandwidths e.g. used for CTCSS detection. > I did however not find a good solution for 1750Hz and DTMF > because the frequency bin alignment algorithm does not work > well for phase detectors. Yes, the phase detector approach may not be as good on high frequencies as on low frequencies. It does work but I'm not sure how good it is. I have not really evaluated this since I wanted to concentrate on the CTCSS case. Let's solve that first. > Enclosed I send you my experimental decoder which uses > 3 Goertzel detectors: One magnitude only detector runs at > the specified tone freq and bandwidth, one phase detector > at double bandwidth (phase offset is either zero or 180° > according to the number of periods in the first detector) > and a third magnitude detector with a four times higher > bandwidth to have a reference for the close-in power. With the provided thresholds this detector does not work on real world data. I changed the threshold calculations to: bool active = ((main_level > 2.4*ref_level) && (max_phase < 0.3f)); This was just a very quick fix to get it to work on my test data. Anyway, with the above parameters I get a detection delay of about 400ms which is far worse than the 160ms I got now in the current detector. I also get a bunch of false detections but that may be possible to get better with more careful setting of the thresholds. The quick tests I did indicated that the phase signal you use have more noise in it than the one in the current detector (improved tone detector). So, the somewhat strange approach I use seem to be better for now. I also use both mean phase diff and standard deviation. The former tell me how far off the detected tone is and the latter say how much noise there is in it. That seem to work pretty well. Your new level camparisons have at least one problem, which is the same as in the old detector really. To get a good estimation of the noise floor you have a couple of parameters to play with. The most important ones are time and bandwidth. If you decrease the bandwidth of the noise estimator you need to compensate with a longer integration time to get the same quality of the estimation. We don't want a slow detector so we want to use as much bandwidth as possible. The whole CTCSS band is a good choice in this case. If both time and bandwidth is decreased, the third parameter to play with is the noise to center tone threshold which then have to be set higher to avoid false detections, causing a less sensitive detector. So, I still say that the current implementation in the improved_tone_detector branch outperforms your new one. Also, please make sure that when you supply me with code to test that it actually is possible to use out of the box. I didn't have to do much but it make it much harder for me to test if the code isn't complete. I hade to add if (active != is_activated) { is_activated = active; activated(active); } at the end of the postProcess method and also include sigc++, define the "activated" signal and undefine INTERNAL_SAMPLE_RATE. > One additional problem: As you've already mentioned the > new_audio_pipe branch is a already mixture of features > that belong there and others that should not be there > because they've almost nothing to do with the audio pipe. > I'd like to separate them step-by-step and try to make > patches to apply them to trunk, but this will certainly not > easy to achieve. Most svxlink components in the > new_audio_pipe branch do not require any special > components anymore (with a few exceptions). > Many components have been patched back to the > trunk version, so there should be no significant > differences. This sound good. I like clean branches :-) What features is it that you want to port to trunk? 73's de SM0SVX / Tobias > > 73s Steve |