updates the LSM decoder to follow the same design pattern. Adds LSM
decoder support to the demodulator viewer application. The current
symbol timing gain for LSM is set too high -- is using the C4FM gain
and causes too much fluctuation in the timing error.
error calculator. After increasing the gain for symbol timing, this
new symbol evaluator class seems to track the signal very accurately
despite lots of noise and ISI.
timing error calculation with symbol decision. In the process of
changing over to this new class and remove the previous implementations
for the 3 values. This commit includes the partial implementation
so I can access from another dev machine.
based on the P25 LSM decoder using a costas loop and a gardner detector.
Updates the Demodulator Viewer FX application to add in a symbol chart
and a phase error chart. The decoder won't lock on yet ... still a wip.
ordering to each channel configuration to provide the user with greater
control over initial application startup configuration.
Adds new dialog window that displays on startup that allows the user to
invoke/cancel auto-start, or simply allow the timer to expire whereby
the channels will be auto-started.
Updates channel table model to include an auto-start column and relabels
the 'Enabled' column to read 'Playing'.
Updates channel editor to change the 'Enable/Disable' button to read
'Start/Stop'.
Changes the 'enabled' property of the channel configuration to indicate
the current 'processing' status - isProcessing().
Channel's XML configuration re-purposes the 'enabled' property to indicate
auto-start and adds a new (optional) auto-start 'order' attribute.
so that on startup, the application attempts to source the channel from
the preferred tuner.
If the tuner is currently not available, or if the tuner cannot source
the channel, then the next available tuner is selected.
when the tuner controller indicates that there is a center DC spike
blocked region or when the tuner has clipped outer spectral regions
resulting in less than 100% usable bandwidth.
produces a significant reduction in memory usage, especially for tuners
like the airspy and hackrf that produce 10/20 MSPS sample rates. This
is observed to be around 66% reduction in peak memory usage and provides
a more stable memory utilization across time reducing stress on the
garbage collector.
Use of these reusable memory buffers will be pushed further down into
the processing chain modules to ensure we keep new object creation
to the lowest levels possible.
ChannelizerViewer so that we can compare the two-channel synthesis
operations. The SynthesizerViewer is successfully down-sampling and
synthesizing two 25.0 kHz channels into a combined 25.0 kHz channel with
no noticeable drop/nulling in the joined region. However, the channelizer
viewer's synthesized channels definitely have a null in the joined
region. I suspect that the channelizer is not quite where it needs to
be and am going to start experimenting there.
and translating it by -FS/4 to correctly center the synthesized channel.
The low-pass filter is currently disabled to better troubleshoot/view the
state of the synthesized channel. It appears that the synthesizer is
not correctly joining the channel ... instead of down-sampling and then
synthesizing the two channels, it appears to be synthesizing and then
down-sampling. The synthesized channel has a null in the middle which
would render it unusable.
TestTuner and TestTunerController implementations. This implementation
only has support for channels that are completely centered within a
channelizer output. Two output slice stitching to form a composite
channel will be implemented next.
Initial profiling indicates that the FFT function within the polyphase
channelizer is now the dominant processing workload - 28% cpu loading
when channelizing a 10 MHz sample rate input into 800 channels running
at 25.0 kHz each. This is ideal for offloading to an OpenCL kernel and
running on a GPU.
complex buffer listeners. Removes complex buffer broadcast support from
the source manager and renames it to channel source manager to convey
that it's only responsible for providing channels from the tuner.
calculator must be updated immediately any time the tuner's center
frequency changes so that a channel can be allocated immediately. So,
I changed source event handling to two parts where the channel calculator
is immediately updated and the channelizer configuration is deferred so
that it can happen on the buffer processor execution thread and we can
avoid any sync() locking on the channelizer or polyphase channel
sources.
messages and events can be accurately timestamped, and more importantly,
allocated traffic channels can request to be pre-loaded with buffered
samples to ensure that traffic channels don't miss any samples that
are currently missed due processing latency inherent in current buffer
sizing. This should reduce the clipping of starting messages or voice
on the traffic channels.
Restructures processing path for tuner frequency and sample rate change
events. The tuner now embeds these events in the sequence of buffers
that are generated immediately after the event occurs since those are
the buffers that will be impacted by the change. Previously, the change
event would be broadcast throughout the system and would impact any
buffered/cached buffers. This also reduces the number of source event
change listeners that have to be managed. Note: this change is not yet
implemented in all tuners ... only in the TestTuner implementation.
Updates the polyphase channelizer to now buffer channel results and then
dispatch the buffer to the channel output processors to improve efficiency
of using float arrays versus single value complex float processing.
center frequency each time we allocate a new DDC/channel. Adds
support for broadcasting channel count change source events so that the
tuner can accurately convey sourced channel counts via tuner events.
Completes changeover of polyphase channel manager to support arbitrary
bandwidth channels. The new approach provides greater compatibility
across any tuner sample rates. Likewise, all decoders will have to be
updated to adapt to any channel sample rate, although channel bandwidths
will be at least 12.5 kHz and likely no more than 25.0 kHz, with a 2x
oversampling that produces channel sample rates in range 25.0 - 50.0
kHz.
Updates wave writer to add the metadata LIST and ID3 chunks to the end
of the recording so that the file contains the final/complete set of
metadata that was accumulated over the call lifecycle.
