Hello David, As always, a great read with real examples of how your working your way through the optimization process for the freeDV suite. One thing did peak my interest:
"The fluttering at the start of the 1600 bit/s sample might be caused by bit errors in the frame energy parameter causing the level to jump around, or possibly bit errors in the voicing bit. If we know the channel is bad (the modem can tell us), we could “lock down” a few bits to enhance speech on poor channels." Have you considered using a DVMDV training sequence say at the beginning of the QSO much like what our old analog phone POTS modems used to do? I think with an initial training and possibly mid-QSO re-training (the FreeDV UI could also inform the user of the retraining vs. guessing why the delay), the codec can get updated information on the link well as non-FreeDV users might get informed what this "new mode" is. Methods could be via a visual waterfall text (like how HamDRM based SSTV), a PSK31, a new set of RSID codes, or even CW. Just a thought but I think there are benefits here to consider. --David KI6ZHD ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
