The new system supports:
- time-tagging of log messages
- message priority levels with a threshold below which they are not printed
- colored output of the message priority for easy identification
- compile-time disabling of all logging per C module
So far, it is integrated in the main and rx modules which generate most
messages. Other modules will be migrated in the future.
- passing argument 2 of 'crc_generate_key' discards ‘const’ qualifier;
a bit ugly but signature of crc_generate_key() is wrong
- variable 'linearized_history' set but not used
- typedef is unused
- superfluous arguments to DEBUG_LOG() and fprintf()
- implicit declaration of function 'memset'
- unused arguments
If passed on, these cause a segmentation fault in the channel decoder. As
zero-length packets currently make no real sense in this protocol, they are
ignored now.
- Ramp-up length increased to 128 symbols (here is room for
improvement!)
- Try to detect the frequency once during ramp-up. To do so, every
second symbol is inverted (to remove the +/-1 symbol toggling) and the
phase difference between neigboring resulting symbols is checked. When
it is low enough for all symbols, the frequency is estimated and
corrected. When frequency estimation was done, it is not retried for a
number of incoming symbols in order to allow the timing estimator to
converge again.
- This approach was verified in a simulated loopback test with frequency
offset and AWGN.
The RX chain uses this to acquire an initial estimate of the carrier frequency. The estimate is adjusted on every incoming symbol until a preamble is found.
- limit frequency adjustment range
- pre-filter the baseband signal to remove out-of-band interference
- reset the frequency acquisition periodically (every 30s) if no preamble is found
Packets are now read from the TUN device and transmitted. The signal
goes through a channel emulator and is then received + decoded. If
decoding is successful, the result is written back to the TUN device
(which does not make much sense, but works for testing).
Unfortunately, there still seems to be a problem in the receiver: packet
loss is very high even at extremely high SNRs.
This allows a higher layer to adjust data rate based on the current
channel conditions. For example, the SNR could be measured and if it
becomes too low for the current modulation/code, a lower-order
modulation or stronger code could be used.
Thomas Kolb
Simon Ruderich