In case of scrambling the self synchronizing scrambler ensures
that enough repetitions of the AX.25 flag have been received.
However, this does not hold for the case of non scrambled
transmissions. In this case, we wait for at least two consecutive
AX.25 flags to reduce the false alarms. Experiments have shown
that due to the poor CRC there were many false positive frames.
It is expected however, to miss some transmissions that use only one
AX.25 flag.
Update the obsolete flowgraphs and update the existing with
the new decoding architecture blocks. Client should
not have big problems with the new decoders as we utilizing
the multiformat frame sink that takes care of it. This
is just a work around for testing as we move forward for
fully socket-based communication with the client
To allow easier integration to the new architecture the
multi format file sink supports bot legacy and the new
format of the PMT messages. In poth cases, only the PDU
is extracted. Legacy used the PDU as a BLOB, whereas
now the PDU is stored in base64 format inside a
dictionary, which structure is defined through
the gr::satnogs::metadata() class
Add a IEEE 802.15.4 like decoder, which supports
the IEEE 802.15.4 standard but also a large variety
of ICs based on this framing scheme. Such framings
are quite common in many Cubesat missions.
The decoder has been tested an works well with at least
the Reaktor Hello World satellite
* Removed obsolete blocks
* Created a new CRC class with static methods. This will make easier the
integration of new CRC schemes. The old way was rather too C-styled
* Blocks removed are now covered from decoders available supporting the
new decoder architecture
* The quadrature demodulation filter block, had as primary goal to
reduce the false alarms and the performance of the DUV decoder. Now the
new DUV decoder, uses a shift register approach, likewise the AX.25
decoder, therefore it is not needed anymore.
TODO:
* Use the shift register likewise the AX.25 to get rid off the
quadrature demodulation filter. This will significantly increase the
number of decoded frames
The decoders produce a PMT message containing several information about
the decoded frame. While this is very convenient for handling data
inside the flowgraph, it is not for third party applications. The JSON
converter block is responsible to serialize all the information
contained in a PMT originating from a decoded frame.
For simple demonstration some metadata were added on the AX.25 decoder.
These metadata are still a WIP and they subjected to changes.
To simplify the logic and allow an easy and more efficient way to add
new decoders, the new architecture uses only one decoder block.
This block takes as input a void* stream and produces PDUs with their
metadata. To do so, the block accepts a decoder object. Every decoder
should implement the virtual class decoder(). This class provides the
necessary API and an arbitrary number of decoders can be supported. The
decoding status is reported to the frame_decoder block through the
decoder_status_t structure.
Manolis Surligas
Vasilis Tsiligiannis
Julien