Hi David,
On 15 January 2013 05:58, David Rowe <[email protected]> wrote:
> > I'm in the middle of hacking the code in fdmdv.c to give an indication
> > of the quality of the received symbols as well as the symbols
> > themselves. This means that if the CRC check fails, we can flip the
> > bits most likely to be incorrect and see if it passes.
>
> This is also something I would like to look at so perhaps we can
> collaborate. There is some other structure in the parameters (e.g the
> LSPs) that could be treated the same way as you have described above.
>
That would be good. My approach is to change
float qpsk_to_bits(int rx_bits[], int *sync_bit, COMP phase_difference[],
COMP prev_rx_symbols[], COMP rx_symbols[])
to
float qpsk_to_bits(int rx_bits[], int *sync_bit, COMP phase_difference[],
COMP prev_rx_symbols[], COMP rx_symbols[], float errors[])
I calculate the mean magnitude avg_r for each frame, and then define the
error in each symbol as the distance between the symbol and a "perfect"
symbol at avg_r, theta (where theta is one of pi/4, 3*pi/4, 5*pi/4 or
7*pi/4, depending on the quadrant the symbol is in.)
At the moment I'm returning the error on a per-bit basis rather than
per-symbol. This has the disadvantage that it ignores the fact that errors
are going to affect whole symbols not individual bits, but it means that
the whole approach can be used with more complicated modems. (One idea I
had was that the codec2 bits which have a more minor effect on the voice
quality could be carried in 16QAM carriers to reduce the overall
transmitted bandwidth and giving a more analogue-like drop in quality as
signal levels dropped instead of a digital all-or-nothing effect.) I'm
hoping to just start simple and then possibly improve in the future to a
more intelligent approach which carries data about which bits come from
which symbol and the quality of that symbol.
I'm also very deliberately sticking to a frame-by-frame approach rather
than gathering data across several frames. I'm trying to avoid doing
anything which will reduce the sync speed of the system.
> To the list in general: over the next few months I will be looking at
> making FreeDV more robust on HF radio channels. This will involve work
> to FreeDV, Codec2, and the fdmdv modem
>
>
One thing which I think would be valuable is some kind of indication of the
format of the data being sent over the fdmdv modem.
At the moment, if we change the data format without changing the modem then
existing FreeDV users will hear odd noises (since the data will demodulate
from the modem correctly but will not make sense when decoded by the
codec.) It would be nice if in future we are able to change the data
format and FreeDV mutes the sound and possibly brings up a notification
that a new modulation scheme is being used and it may be time to go online
and check for updates.
Obviously if the modem is changed then this will be shown in the waterfall
looking different and existing copies of FreeDV would probably not be able
to decode anything.
Cheers,
Dan MD1CLV
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
