Hello Gullik (and list),

Background: Gullik is working on a fixed point port of the fdmdv tx
side.  I thought this might be useful for others.

For fixed point work in general we use 16 bits for inputs to multiplier
data and 32 bits for results.

For a fixed point port of the tx filter loop:

        acc += M * tx_filter_memory[c][j].real * gt_alpha5_root[k];

Take it step by step. At each step test the BER of the modem at the
operating SNR of around 7dB using the Octave version of the demod.  Plot
the float tx output and fixed point on top of each other to spot any
gross errors.  Use version control to back up if something breaks.

1/ Simulate fixed point quantisation of gt_alpha5_root[k], with
something like:

        short gt_alpha5_root_fixed = (M*gt_alpha5_root[k])<< S + 0.5;
        acc += tx_filter_memory[c][j].real * gt_alpha5_root_fixed;
        acc  >>= S + (1<<(S-1));

Experiment with S so that gt_alpha5_root_fixed doesn't overflow.  The
0.5 and (1<<(S-1)) (half a LSB) are for rounding.

2/ You can then check if acc is overflowing by clipping it to 32 bit
limits acc_max and acc_min:

        short gt_alpha5_root_fixed = (M*gt_alpha5_root[k])<< S + 0.5;
        acc += tx_filter_memory[c][j].real * gt_alpha5_root_fixed;
        acc  >>= S + (1<<(S-1));
        if (acc > acc_max) acc = acc_max;
        if (acc < acc_min) acc = acc_max;

If that's OK, acc can be replaced by a 32 bit int.

That should get u started.

Cheers,

David

On Tue, 2012-07-17 at 13:05 +0200, Gullik Webjörn wrote:
> Hello David,
> 
> It looks to me that gt_alpha_root is used ONLY in the fdmdv
> modem. I can see that the value span from -6.22187e-07
> to 0.00710203. This is a range of 1:12000, but including
> the 5 significant digits in the lower coeff gives
> 1 / 1^10. Clearly this does not fit into a 16 bit integer,
> but I wonder what precision you would suggest?
> 
> I also want to include the factor 1.4 (gain) and M into
> the table to avoid two multiplications in the actual 
> filter. Would not that be reasonable, if gt_alpha5 is
> used only for this purpose?
> 
> I can see the gain mult spreads the data into the imag vector,
> but at least for now, imag is not used. Good for later?
> 
> i.e. acc = tx_filter_memory[c][j] * new_gt_alpha[k]
> 
> The filter kernel loop iterates NSYM times, (6) so, allowing
> for a table mult result where the 3 most significant bits are zero, (or
> minus) would allow for a result before addition to acc of 29 bits, with
> no overflow of "acc". 
> 
> A filter table of 16 bits, would only allow for a tx_filter mem
> of 13 bits, which maybe could be reasonable for the IN signal, but 16
> for the filter table feels a bit coarse.
> 
> Gullik /SM6FBD
> 
> 
> 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to