This commit adds the implementation of these range formats to the
encoder. In addition, the work-around that tried range 512 first is
removed, so that the selection is primarily based on the max distance
between frequencies.
Ticket: OW#1061
Sponsored-by: On-Waves ehf
Currently the encoding of the chan_list is done by a hard-coded
sequence of macros that closely resembles figure 10.5.16 in
3GPP TS 04.08.
This patch replaces this by an algorithmic solution that can be used
for all range encodings and is based on the property
W(2^i) to W(2^(i+1)-1) are on w1_len-i bits when present
(see section 10.5.2.13 in TS 04.08).
Ticket: OW#1061
Sponsored-by: On-Waves ehf
f0 is currently set to arfcns[0] in range_enc_determine_range(),
while GSM 04.08 requires f0 to be ARFCN 0 in range1024 encoding.
This patch modifies range_enc_determine_range() to force f0 to be 0
if this encoding is used. This way the case distinction in
range_enc_filter_arfcns() is not longer necessary.
Sponsored-by: On-Waves ehf
Andreas highlighted that the doubel assignment is not needed and
wrong. Change the code to assign chan_list[0] before writing the
base frequency to the header. Update the testcase to make the highest
bit set and update the test result.
I saw the old copy of the "Appendix J" code too late and I have
discovered some quirks and I am more familar with my implementation.
Most noticable 'w' only needs to be as big as the input arfcn but
requires the 'w' to be initialized. The power_of_2 implementation
differs as well (mine matches the output of wirehsark).
The f0 could be chosen in a better way but right now picking
the lower bound is the easiest. It is not clear if to use
modulo if the range is chosen in the middle. This can be improved
in the future. Right now I have no bit fiddling for range128, 256
and 1024 as I was running out of time.
Jacob Erlbeck