the gr pdu utilities - gnu radio · 2020-02-02 · sand2019-10616c 5 motivation for the pdu...
TRANSCRIPT
P R E S E N T E D B Y
Sandia National Laboratories is a multimission
laboratory managed and operated by National
Technology & Engineering Solutions of Sandia,
LLC, a wholly owned subsidiary of Honeywell
International Inc., for the U.S. Department of
Energy’s National Nuclear Security
Administration under contract DE-NA0003525.
The GR PDU Utilities
Jacob Gi lber t – a t the 2019 GNU Rad io Conference
j a c o b . g i l b e r t @ s a n d i a . g ov
S A N D 2 0 1 9 - 1 0 6 1 6 C
U N C L A S S I F I E D U N L I M I T E D
R E L E A S E
SAND2019-10616C
GR Operation: Streaming2
“item”
GNU Radio Runtime
Output buffer write pointer
Input buffer read pointerDownstream read pointer
Upstream write pointer
msg()
{...}
work ( )
{
do_some_dsp()
out=result
}
Complex to Mag^2
SAND2019-10616C
GR Asynchronous Message Passing / PDUs3
GNU Radio Runtime
work()
{...}
handle_msg ( )
{
do_other_dsp()
publish_pdu()
}
Complex to Mag^2
PMT
PMT
GR PDU
{key1: val1,
key2: val2,
key3: val3}
{metadata, data}
[0,1,2,3,
4,5,6,7]:8
gr::pmt pair
gr::pmt vectorgr::pmt dict
SAND2019-10616C
Motivation
4
SAND2019-10616C
Motivation for the PDU Utilities5
o Receive a burst of information, respond with burst based on the received data
o Current tools exist but have limitations:
o gr-uhd Stream Tags
o Tagged Stream Blocks
o GR Packet Communications API
o gr-eventstream
o Complicated by real-world radio protocol constraints:
o Minimum RF turnaround time (latency)
o Other TDMA system constraints such as relative burst timing
o Frequency agility, RF tuning and tracking
o ‘We tried GNU Radio but there was too much latency so we used instead’
libuhd
C++
RFNoC
X-Midas
SAND2019-10616C
Required Capabilities6
o RX: Convert received bursts of energy into discrete datasets for further processing
o ~Sample accurate time estimate of bursts
o Fixed or arbitrary frequency operation
o TX: Convert data into bursts of modulated data
o ~Sample-accurate transmission time
o Minimize RX/TX latency through SDR system
o Fixed or arbitrary frequency operation
o Portable: minimize processing hardware dependencies
o Robustness: recover from overflows or dropped data
o Efficient: design for lower power embedded hardware
SAND2019-10616C
Existing Toolset
7
SAND2019-10616C
Existing In Tree Tools8
o GR Tagged Stream API
o Support for burst processing within the streaming architecture of GR
o Going to be deprecated?
o gr-uhd Stream Tags
o ‘rx_time’ provides for RX time tracking, ‘tx_time’ allows synchronized, timed transmissions
o ‘tx_sob’ and ‘tx_eob’ tags allow for single port half-duplex transceiver
o Not a complete solution, still streaming based
o Since this relies on hardware, simulation can be difficult (weird SW emulation)
o Still very useful – leveraged by gr-pdu_utils and extended to Sidekiq hardware
“there's a lot of bugs and inefficiencies, and quite some grief¹ and undocumented contracts connected to TSBs” – M. Müller, 2017
SAND2019-10616C
Existing In Tree Tools: Packet Communications API9
o Powerful packet processing schema, somewhat complicated (makes use of TSBs…)
o Appears to use open loop timing, lots of rework to meet our requirements
o Doxygen Documentation: https://www.gnuradio.org/doc/doxygen/page_packet_comms.html
o Interesting Module Example: https://www.gnuradio.org/deptofdefense/gr-uaslink
o Reasonable option for custom protocols and more complicated modulations
o We found the PDU Utilities to be easier for existing / simple protocols
SAND2019-10616C
OOT Modules: gr-eventstream10
o Allows burst processing with closed loop timing by interleaving bursts into TX stream
o Relies on conventional GR backpressure: buffers will impact latencyo Minimize number of streaming blocks between ES source and HW Sink
o Good description of functionality: https://oshearesearch.com/index.php/tag/eventstream/
o Limitations for our use: T/R latency, different overall approacho Possible that we will integrate ES concepts in future
SAND2019-10616C
Theory of Operation
11
SAND2019-10616C
Usage of the PDU Utilities12
o Robust set of blocks for converting between streaming and async message (PDU)
o Receive energy, basic preprocessing
o Identify start/stop of burst
o Convert required data elements to PDU
o Keep track of time
o Do higher layer processing
o Convert PDU to stream if required
o Emit RF energy at specified time
SAND2019-10616C
PDU Utilities Time Management 13
Uses the ‘tx_time’ tag key
SAND2019-10616C
The Timing Utilities Module14
o Separated from gr-pdu_utils to contain various time tracking functions
o Some complexity is now OBE
o Lots of time tuple related code
o Tracking UHD Time Tuples
o Adding periodic Time Tuples
o Does this need to be a separate module?
o No, BUT…
UHD Time Tuple: ( rx_time {1432 0.912341} )
Timing Utils Tuple: ( rx_time {1432 0.912341 243123411 1000000.0} )
[Key] [Integer Secs] [Fractional Secs] [Sample Offset] [Sample Rate]
SAND2019-10616C
Extending The ‘Basic FSK Receiver’ Example15
Channel Filter
Quadrature
Demod
Clock
Recovery
Binary
Slicer
Burst
Detection
BITSTREAM
SAND2019-10616C
o We have a bitstream and know where bursts start…now what?
o Encapsulate a complete burst of data
o End-of-burst sequence detection
o Encoded length field in header
o Blind (fixed length after burst detection)
o Create a PDU from received data
o Pass this information to a higher-layer processor
Extending The ‘Basic FSK Receiver’ Example16
SAND2019-10616C
Building a Simple TDMA FSK Modem17
SAND2019-10616C
Building a Simple TDMA FSK Modem18
Higher layer radio processing, interface to application layers, etc
SAND2019-10616C
“Low Latency”…?19
o ‘Low latency’ is a key design consideration
o Minimize time from burst RX to burst TX
o Blame the OS / Scheduler?
o Its usually buffering…
o Tradeoff…small buffers often means less efficient processing
Onboard
SDR DSP
Buffering
Transport
Control
Buffering
GR Source
Block
Buffering
‘High Rate’
GR RX
Buffering
SDR ADC
Buffering
Onboard
SDR DSP
Buffering
Transport
Control
Buffering
GR Sink
Block
Buffering
SDR DAC
Buffering
‘High Rate’
GR TX
Buffering
‘Low Rate’
GR
Buffering
✓ Reduce Data Buffer Sizes
✓ Increase Sample Rate
X More CPU Utilization
𝑇𝑅_𝑙𝑎𝑡𝑒𝑛𝑐𝑦𝑚𝑖𝑛 ≥𝑑𝑎𝑡𝑎_𝑏𝑢𝑓𝑓𝑒𝑟_𝑠𝑖𝑧𝑒
𝑠𝑎𝑚𝑝𝑙𝑒_𝑟𝑎𝑡𝑒𝑚𝑎𝑥
SAND2019-10616C
“Low Latency”…?20
o ‘Low latency’ is a key design consideration
o Minimize time from burst RX to burst TX
o Blame the OS / Scheduler?
o Its usually buffering…
o Tradeoff…small buffers often means less efficient processing
Onboard
SDR DSP
Buffering
Transport
Control
Buffering
GR Source
Block
Buffering
‘High Rate’
GR RX
Buffering
SDR ADC
Buffering
Onboard
SDR DSP
Buffering
Transport
Control
Buffering
GR Sink
Block
Buffering
SDR DAC
Buffering
‘High Rate’
GR TX
Buffering
‘Low Rate’
GR
Buffering
✓ Reduce Data Buffer Sizes
✓ Increase Sample Rate
X More CPU Utilization
𝑇𝑅_𝑙𝑎𝑡𝑒𝑛𝑐𝑦𝑚𝑖𝑛 ≥𝑑𝑎𝑡𝑎_𝑏𝑢𝑓𝑓𝑒𝑟_𝑠𝑖𝑧𝑒
𝑠𝑎𝑚𝑝𝑙𝑒_𝑟𝑎𝑡𝑒𝑚𝑎𝑥
SAND2019-10616C
Characterizing Round Trip Latency21
o Flowgraph included in Timing Utilitieso PULSE → RX → PDU → […] → TX → SCOPE
latency requires external equipment
o TRIG → PDU → […] → TX → RX → TIME SINK is simpler (terminate TX port of USRP)
Low Latency UHD Arguments:
"recv_frame_size=256, num_recv_frames=256, send_frame_size=256, num_send_frames=256"
>4.0ms
Default UHD Args
‘Low Latency’ Args
‘LL’ Args + 2x ZMQ ~350µs
~270µs
~1860µs
SAND2019-10616C
Characterizing Round Trip Latency22
o Flowgraph included in Timing Utilitieso PULSE → RX → PDU → […] → TX → SCOPE
latency requires external equipment
o TRIG → PDU → […] → TX → RX → TIME SINK is simpler (terminate TX port of USRP)
Default UHD Args
‘Low Latency’ Args
‘LL’ Args + 2x ZMQ
Low Latency UHD Arguments:
"recv_frame_size=256, num_recv_frames=256, send_frame_size=256, num_send_frames=256"
…received data from the SDR source block
On the rising edge of the ‘trigger pulse’ waveform,
emit an RF pulse PDU for immediate transmission
Tag both the trigger pulse
and received pulse locationsVisualize everything, print
time differences to STDOUT
Generate a ‘trigger pulse’ waveform
that is coherent with…
>4.0ms
~350µs
~270µs
~1860µs
RF Pulse waveform definition
SAND2019-10616C
Notable Blocks in the PDU Utilities Module23
o PDU/Stream Conversion:
o In-Tree Streaming Analog:
o New PDU Manipulation Blocks:
o Debugging Tools:
• Tags to PDU
• PDU to Bursts
• Take/Skip to PDU
• Tag Message Trigger
• Pack/Unpack
• PDU Alignment
• Commutator
• Data Encoding
• Extract Field
• PDU WPCR
• PDU Logger
• Flow Controller
• PDU Counters
• QT PDU Source
• PDU Message Gate
• Random Drop
• Complex to Mag^2
• Keep 1 in N
• Binary Arithmetic
• Up/Downsample
• PFB Arb Resampler
• FIR Filter
• FM Modulator
• Quadrature Demod
SAND2019-10616C
o Emits messages based on certain conditions
o Robust arming/triggering architecture based on messages or stream tags
o Re-trigger holdoff, arm timeout, TX limits, etc
o Can emit fixed Messages or Timed PDUs
o Converts data within U8 PDU formats
o Stuff U8 bits into U8 bytes, bit swap, etc
o Requires work for higher order PDU translation
o Whole Packet Clock Recovery Symbol Synch
o Based on M. Ossmann’s WPCR project[1]
o Operates well between 4 and 60 Samples/Symbol
o Asynchronous message passing: no flow control
o Block queues are checked, PDUs block if >Max
o Helpful for highly variable input situations
Notable Blocks24
o PDU / Stream Conversion have been covered pretty well
[1] https://github.com/mossmann/clock-recovery/blob/master/wpcr.py
SAND2019-10616C
Other Sandia GR Modules
25
SAND2019-10616C
FHSS Utilities26
o Built for ISM FHSS receiver applications
o Bursts of energy on arbitrary frequencies
o Derived from CCC’s gr-iridium
o Similar approach, generalized
o Efficient implementation, good sensitivity to ~6dB C/N
Broadband Time-Sliced BurstsBursts Tagged in Input Data Stream
Decimated and
Centered Bursts
Real World Example:STFT of 900 ISM Band
30 MHz
400 ms
Strong in-
band CW
signal
UNCLASSIFIED UNLIMITED RELEASE SAND2019-10616C
Detections highlighted
UNCLASSIFIED UNLIMITED RELEASE SAND2019-10616C
SAND2019-10616C
Sandia Utilities29
o Assorted useful blocks that don’t fit well into other modules
o Holding area for in-tree improvements we have yet to get released
o Mostly oriented at debug applications
o Usually minor documentation if any
o Blocks are generally not extensively tested…may be dangerous
o Sometimes things get stuck in here before being moved or upstreamed…o Useful to install if you are using Sandia’s GR Toolkit
SAND2019-10616C
[Yet another] gr-sidekiq30
o Coming soon…
o Extends many UHD-style features to the Sidekiq hardware
o DDC / DUCs in FPGA
o Command queues in FPGA (separate for instantaneous and timed commands)
o Time tags generated by source, support for TX tag based flow/time/frequency control
o Supports direct PDU-based transmission
o Efficient implementation (thread-per-channel)
o Currently works on the M.2 and VPX2 Sidekiq variants
SAND2019-10616C
Summary
31
SAND2019-10616C
Takeaways32
o PDU’s are underutilized, and very useful…With only a bit of frustrating PMT behavior…
o The PDU Utilities help bridge GNU Radio’s streaming and PDU APIs
o There are straightforward tools available for developing bursty transceivers within GR
o Significant enhancement to GR’s in-tree PDU capabilities are available
o GNU Radio can be used for ‘reliable’ ‘low latency’ applications
o The FHSS Utilities module has a robust and efficient arbitrary burst detector and associated signal processing
SAND2019-10616C
Thank you!33
Questions?