Hi! Reading about Huffman Coding [1], I realized that UHD codes float samples using 16, 12 or 8 bits (depending on the otw_format stream arg) probably assuming a uniform distribution on the samples. This is obviously correct since there is no way to guess what a SDR user will want to transmit or expect to receive, but I can think of an example where this assumption appears to be sub-optimal. Imagine this set up: [some bits] --> [8 PSK modulator] --> [2X Upsampling RRC FIR FILTER with #taps ~ 100] --> [UHD Sink] * It's ok to assume that the output of "[8 PSK modulator]" is uniformly distributed in the set of 8 constellation points. * The FIR Filter will output many more different values that are not in the constellation (they are needed to "soften" the signal and reduce bandwidth) BUT they will not be uniformly distributed. * UHD Sink will map the [-1; 1] float interval to [- 2^(n-1); 2^(n-1) - 1] (n=#bits). * Those integers will then be transmitted to the USRP. My thought is that before the last step, some custom coding table be used according to the user knowledge of the signal he is synthesizing, thus allowing a reduction on the transport data rate. If some application has reached a maximum sample rate because a bottleneck in the transport medium, this may rise it up some non-negligible percentage. Obviously this will need a modification on USB or FPGA firmware, and I don't know how difficult/convenient it may be. I attached the result of a QT GUI Histogram Sink of the real part of the FILTER output, to show that there are values significantly more probable than others. I didn't attempt yet to estimate the gain, because I first wanted some feedback on the accuracy of my assumptions and deductions. Let me know what you think. Bye and thanks. PS: I'm writing this PS after a while playing with numbers (and I'm afraid I should call this "Post Mortem" instead "Post Script" :P). I sent the filter output through a Complex to IChar, then to a Bytes File Sink, loaded its content with numpy, obtained the list and count of unique values with "u, c = numpy.unique(x, return_counts=True)", estimate the probabilities as "c/sum(c)" and the entropy as "sum(-p * numpy.log2(p))" and it was ~7.4 bits. Nothing to be gained in this example, to be honest :( . I hope the discussion is still valuable. [1] http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-02-introduction-to-eecs-ii-digital-communication-systems-fall-2012/readings/MIT6_02F12_chap03.pdf

> My thought is that before the last step, some custom coding table be used > according to the user knowledge of the signal he is synthesizing, thus > allowing a reduction on the transport data rate. If some application has > reached a maximum sample rate because a bottleneck in the transport medium, > this may rise it up some non-negligible percentage. You might as well just transmit the 3 bits per symbol and do the constellation mapping and LPF on the FPGA then ... The whole point of the general purpose SDR here is to not make assumption about the signal. If you drop that and specialize for one kind of signal, then you might as well go all out and do the modulation on the FPGA because it's going to be much bigger gain and not much more difficult ( actually a 8 PSK HW modulator is _easier_ than a huffman decoder in many respect ). Cheers, Sylvain Munaut

Hi Francisco, On Wed, Jul 27, 2016 at 10:05 AM, Francisco Albani via USRP-users <usrp-users@lists.ettus.com> wrote: > Reading about Huffman Coding [1], I realized that UHD codes float samples > using 16, 12 or 8 bits (depending on the otw_format stream arg) probably > assuming a uniform distribution on the samples. Sample values over-the-wire are always integer, but the sizes are as you describe. > Imagine this set up: > > [some bits] --> [8 PSK modulator] --> [2X Upsampling RRC FIR FILTER with > #taps ~ 100] --> [UHD Sink] > > My thought is that before the last step, some custom coding table be used > according to the user knowledge of the signal he is synthesizing, thus > allowing a reduction on the transport data rate. If some application has > reached a maximum sample rate because a bottleneck in the transport medium, > this may rise it up some non-negligible percentage. In the more general case, you are referring to data compression over the host-device I/O link. Methods for IQ data compression do exist, but have rarely been used in industry. This is changing, though, with recent LTE networks that use remote radio heads with baseband units connected through CPRI links. USRP products do not support IQ compression at this time. -TT

On 07/27/2016 10:29 AM, Sylvain Munaut via USRP-users wrote: >> My thought is that before the last step, some custom coding table be used >> according to the user knowledge of the signal he is synthesizing, thus >> allowing a reduction on the transport data rate. If some application has >> reached a maximum sample rate because a bottleneck in the transport medium, >> this may rise it up some non-negligible percentage. > > You might as well just transmit the 3 bits per symbol and do the > constellation mapping and LPF on the FPGA then ... > > The whole point of the general purpose SDR here is to not make > assumption about the signal. If you drop that and specialize for one > kind of signal, then you might as well go all out and do the > modulation on the FPGA because it's going to be much bigger gain and > not much more difficult ( actually a 8 PSK HW modulator is _easier_ > than a huffman decoder in many respect ). Note that if your source encoding does some scrambling (like most telecom standards), bits will be pseudo-random going into the symbol mapper and a Huffman code will not reduce the data load compared to what Sylvain is suggesting. Cheers, M