“By about 2020 software radios will have become the standard technology for commercial, as well as military, radios, employed in a range of devices, from battery-powered sensors and hand-held devices to plugged-in devices (such as base stations),” claims BBN's Craig Partridge in the September 2011 issue of CACM. However, one of the chief impediments to realizing this future is that today's software radios are large, expensive, and power-hungry, and so they're poorly-suited to battery-power and hand-held devices. This project explores clean-slate system architectures for software-defined radios, ranging from highly-programmble radios to RF front-ends with reconfigurable hardware baseband processing to simple RF front-ends with pure software baseband processing. The key challenge is how to define, describe, and partition the computations that occur across electronics (e.g. filters), hardware (e.g. verilog), and software (e.g. C/C++) to maximize efficiency and resource utilization. Our chief aim is to make software radios small, inexpensive, and low-power. Today, we have an 802.15.4-compatible SDR platform that's just 3”x5” and costs around $100. It will soon be an open platform for other researchers, and it will allow us to explore the range of architectural tradeoffs necessary to economically and efficiently realize pervasive SDR systems.
"Reconfiguring the Software Radio to Improve Power, Price, and Portability", Ye-Sheng Kuo, Pat Pannuto, Thomas Schmid, and Prabal Dutta, In Sensys'12: Proceedings of the 10th ACM Conference on Embedded Networked Sensor Systems, Toronto, Ontario, Canada, Nov. 6-9, 2012.
"Putting the Software Radio on a Low-Calorie Diet", Prabal Dutta, Ye-Sheng Kuo, Akos Ledeczi, Thomas Schmid, and Peter Volgyesi, In HotNets-IX: Proceedings of the Ninth Workshop on Hot Topics in Networks, Monterey, California, Oct. 20-21, 2010.
August 27, 2012.
Hardware known issues:
August 24, 2012. Measuring the Dynamic and Static power consumption of Smartfusion on uSDRv2
|Voltage rail||Dynamic current||Static current|
|3.3V (IO)||86.0 mA||26.9 mA|
|1.5V (CPU+FPGA)||51.5 mA||8.0 mA|
February 23, 2012. Remeasuring the uSDR coldboot and post-processing(median filter) the usrp coldboot.
February 23, 2012. Simple comparison with other SDR platforms.
|USRP E100||WARP||uSDR||MSR Sora|
|FPGA||Xilinx Spartan||Xilinx Virtex-4||Microsemi Smartfusion||Xilinx Virtex-5|
|Processor||Arm Cortex-A8||Power PC 405||ARM Cortex-M3||Intel Core 2 Quad|
|Power||9 ~ 15W||10 ~ 15W||0.5 ~ 1.3W||N/A|
|size (cm)||22 x 16 x 5||20 x 20 x ?||15 x 8 x 3||N/A|
Detail costs for uSDR.
|FPGA||Microsemi||A2F500M3G||17 x 17||45|
|Radio||Maxim||MAX2831||7 x 7||4|
|ADC||ADI||AD9288||9 x 9||5|
|DAC||Maxim||MAX5189||6 x 10||5|
All the cost is based on 1K quantity.
February 22, 2012. Measuring the throughput of from processor to FPGA.
The experiment setup: The processor sends data through AHB bus, each transfer is one byte long. Measure both reading/writing period.
|Data length||Write time||Read time|
February 22, 2012. Measuring the command throughput from processor to radio.
The experiment setup: The processor sends command to Radio(MAX2831) using memory-mapped access. The commands send through serial SPI interface. The two consecutive command can be sent in 2.94uS.
The command throughput is 340.14K commands/s
February 22, 2012. Measuring the high speed bus between Cortex-M3 and FPGA.
The experiment setup: The processor is clocked at 48MHz. Cortex-M3 writes to an particular address in FPGA, then FPGA generates an Fabric interrupt to the Cortex-M3. Measure the time from writing an address to get the interrupt.
The experiment ran 10000 trials. All result stay the same - 56 timer counts. Timer runs at the same frequency as Processor, namely 48MHz. The Cortex-M3 takes 12 cycles to handle the interrupt. The round-trip time equal 44 ticks.
Average round-trip latency = 44/48 uS = 0.92uS.
February 21, 2012. Measuring the packet collide resolving for different number of envelopes in the packets.
The experiment setup: Two packets with fixed length(31 Bytes) collide. The total packet length is 31*32=992uS.
|# envelope||RX Ratio (2 modes)1||RX Ratio (2 modes)2|
The experiment setup: Two packets with fixed length(51 Bytes) collide. The total packet length is 51*32=1632uS.
|# envelope||RX Ratio (2 modes)2|
February 21, 2012.
Measuring the packet collide resolving across different packet length.
The experiment setup: Initiator transmits a “Glossy” packet with one relay left to two receiver. Measuring the Glossy packets forwarded by receiver collide. Input power -30dBm.
|Packet Length||Rx Ratio (1 node)1||RX Ratio (2 modes)1||RX Ratio (2 modes)2|
February 20, 2012.
The new receiver architecture achieves 99.96% receiving ratio with -60dBm input signal.
The experiment setup: TX node sends packet to two RX nodes and requests for ACK. Two RX nodes generate the ACK at precise 192uS. Two ACKs collide at the TX. Each run performs 10000 transmission, total 5 runs.
|AGC mode||RX Ratio %||STD|
February 10, 2012. Known issues:
February 10, 2012. Redesigning receiver architecture. Removed MM clock recovery block but sync the frame base on decoding bits. This decoding scheme is based on the previous design but removing symbol re-sync every 256 samples. Instead, a “brute force” method is used to compare all the samples with known-chip-sequence. This architecture is able to reduce the packet loss rate to 1% or lower. Although this architecture requires more computation, more logic are moved to combinational to reduce the number of registers. In terms of area, it has a little overhead (1% total cells) compare to previous design.
February 7, 2012. Redesigning receiver architecture. Original receiver architecture has about 20% packet loss rate due to timing synchronization. According to Thomas Schmid's 802.15.4 GNU Radio implementation, a MM clock recovery has been implemented in hardware. The simulation result shows receiver architecture is able to decode the signal with 10dB SNR or lower. The hardware overhead increases 11% of total area. However, MM clock recovery doesn't work under “real” received signal. The decoder noise get worse in real system. Packet loss rate with MM clock recovery is bigger than 10%.
February 5, 2012. Modeling the entire receiver architecture in Matlab to get deep understand of receiver performance.
February 1, 2012.
Observe the ACK collision on uSDR platform. The slight different in carrier frequency results to a low-frequency envelope in RX-baseband signal. CH1: RX-baseband signal. CH2, CH4: receiver-generated ACKs baseband signal. CH3: RX-RSSI.
January 20, 2012. Duty cycling SDR, measure the power of system full running. All the chips are fully active, continues sending packets.
January 19, 2012. Duty cycling uSDR. The Cortex-M3 is in WFI mode, the turn on time is the time period from fabric interrupt to the first packet transmit.
|Turn on time||Current||Cortex-M3||ADC||DAC||RF||Ethernet||External memories||frequency scaling*|
|34 uS||210 mA||WFI||on||sleep||sleep||on||present||off|
|34 uS||108 mA||WFI||sleep||sleep||sleep||not avail||not avail||off|
|3.01 mS||161 mA||WFI||on||sleep||sleep||on||present||on|
|3.01 mS||67 mA||WFI||sleep||sleep||sleep||not avail||not avail||on|
*note: in frequency scaling mode,
January 18, 2012. Characterize Dynamic & Static power of SmartFusion in our SDR platform.
|Voltage rail||operate current||Static current|
|3.3V (IO)||91 mA||85.6 mA|
|1.5V (CPU+FPGA)||50 mA||7.76 mA|
January 4, 2012. Power profiling the FPGA on USRP2 (Xilinx Spartan). This FPGA uses 3.3V, 2.5V and 1.2V. Which are IO, AUX and core respectively. The idle (turn on the power and do nothing) and static (w/o clock) power consumption are following:
|Voltage rail||Idle current||Static current|
|3.3V (IO)||79 mA||79 mA|
|2.5V (AUX)||90 mA||88 mA|
|1.2V (core)||330 mA||80 mA|
December 17, 2011. Power profiling USRP2 with 2.4G daughter board.
December 14, 2011. Power profiling the USRP2. USRP2 uses Xilinx Spartan FPGA and the firmware of FPGA is stored in the SD card. When the power first applied, USRP loads the firmware from SD card. When the firmware is loaded, LED4 goes high. This measurement monitors the LED4 and system current.
December 14, 2011. Exploring the possibility to “clock gate” the Fabric. The clock condition is controlled by five registers.
The most critical registers are MSS_CCC_MUX_CR and MSS_CCC_PLL_CR. Although it's not possible to clock gating the entire fabric. The method to reduce the power consumption when the process goes to sleep is to turn the Main crystal and PLL off. RC oscillator on chip also is unable to disable. Before switch off the main crystal, it's necessary to switch the GLKA source to RC oscillator and lower the frequency.
December 13, 2011. Identifying the power consumption for each chips on the SDR board in sleep mode.
|RF (MAX2831)||65 mA||2.85V and 3.3V|
|ADC (AD9288)||44 mA||3.3V|
|DAC (MAX5189)||7 mA||3.3V|
|Ethernet (KSZ8721CL)||34 mA||3.3V|
December 13, 2011. Continue power profiling the cold boot of SDR platform. Current is measured by putting the Ethernet phi chip and ADC to sleep mode. Also removing the RESET IC for fast transient response.
The following figures are the comparison of two different scenarios.
December 9, 2011. Power profiling the cold boot of SDR platform. We observed the following:
November 17, 2011. Power profiling the SmartFusion Dev. Kit. The chip uses 2 power rails(1.5V, 3.3V) to power different blocks. 3.3V uses to power the I/O buffers and ACE, whereas 1.5V powers MSS and FPGA. The chip has 4 different power mode(SoC, Sleep, Power Down, Time keeping.) SoC mode is normal operation mode. Sleep mode puts ARM Cortex-M3 into WFI mode and lower the FPGA frequency. Power Down mode shuts off the 1.5V supply but 3.3V remains. Time keeping mode has only RTC running. The table below is the data we logged from SmartFusion Dev. Kit (A2F500M3G)
|Modes||Current (1.5V)||Current (3.3V)|
|SoC||58.88 mA||18.15 mA|
|SoC all peripheral off||56.10 mA||17.19 mA|
|Sleep||42.44 mA||17.19 mA|
|Power Down||0.003 mA||0.581 mA|
October 27, 2011. The μSDR platform is now running a hand-coded equivalent of the TinyOS
RadioCountToLeds application and interoperating with Irene nodes (which use the CC2420 radio) running the original application. Two Irene nodes are programmed on two different channels (11 and 12) with the
RadioCountToLeds and the SDR is programmed with conceptually the same app. This app works as follows: A node has a local counter running at some frequency. Every tick of the counter causes a node to read the counter value, put it in a packet, and transmit it. A packet reception (from a different node) causes a node to extract the three low-order counter bits from the packet and set its LEDs to this value. Two nodes programmed with this app on the same channel will cause each other's LEDs to cycle. In our case, the SDR's four pushbutton switches are used to increment/decrement the channel number and counter frequency. As these are adjusted on the SDR platform, either one or the other Irene blinks, and the blinking rate gets slower or faster. The following video shows this in action: YouTube video
October 22, 2011. The integrated μSDR platform appears to work (modulo a couple of minor part footprint bugs). The radio successfully transmits and receives 802.15.4 frames so this verifies the programming, CPU/FPGA, ADC, DAC, and RF front ends. The figures below show the 1st article of the SDR and a scope trace of its operation. The yellow trace (CH1) is the TX baseband signal. The green trace (CH4) is the RX baseband. The magenta trace (CH3) is the TX (ACK) baseband signal which happens 192μs after a frame is received. The digital data trace (B1) shows the decoded signals.
"Realizing the Future of Wireless Data Communications" by Craig Partridge. This paper provides a high-level overview of the software-defined radio space including technology and policy, highlights a number of interesting technology developments and their implications on the SDR roadmap, and speculates that SDR will become the “standard technology” for radios by 2020. A must-read for anyone who wants a quick introduction to the background, current state, and future prospects of SDR.
"Sora: High Performance Software Radio using General Purpose Multi-core Processors" by Kun Tan, Jiansong Zhang, Ji Fang, He Liu, Yusheng Ye, Shen Wang, Yongguang Zhang, Haitao Wu, Wei Wang, and Geoffrey Voelker. This paper presents a fully programmable software radio platform based on a commodity PC architecture. The key contribution is that this work offers both low latency and a commodity PC architecture. This means that it is possible to program these systems using a high-level language (e.g. C) and yet still create interoperate implementations of high-performance protocols like 802.11 that require tight timing.
"Enabling MAC Protocol Implementation on Software-Defined Radios" by George Nychis, Thibaud Hottelier, Zhuocheng Yang, Srinivasan Seshan, Peter Steenkiste. This paper argues that the architecture of modern SDR systems prevent many MAC layer functions and customizations. The paper identifies a set of core MAC functions that must be implemented close to the radio, particularly in high-latency SDR architectures, to enable efficient, high-performance MAC operation.
"Airblue: A System for Cross-Layer Wireless Protocol Development" by Man Cheuk Ng, Kermin Elliott Fleming, Mythili Vutukuru, Samuel Gross, Arvind, and Hari Balakrishnan. This paper presents Airblue, an FPGA-based software radio platform, that provides (i) a flexible way to convey information beyond the data itself from lower to higher layers, (ii) and a way for higher layers to conﬁgure lower layers dynamically and within some latency bounds, (iii) a way to modify a layer’s processing pipeline without triggering a cascade of changes. Airblue runs at speeds comparable to commodity hardware. This paper discusses the design philosophy underlying Airblue that makes it relatively easy to modify it, and presents early experimental results.
"Porting Lessons Learned From Soldier Radio Waveform (SRW)" by Adam Blair, Tom Brown, Jonathan Cromwell, Sungill Kim, Ryan Milne. This paper highlights a number of challenges in porting SDR hardware (e.g. Verilog) and software (e.g. C/C++) algorithms to different SDR architectures. It points out most software implementations are serial and most hardware implementations are parallel, but this often fails to hit a design sweet spot. Software may be too slow, leading to things like loop unrolling. Conversely, fully parallel hardware implementation may be quite wasteful. My take is that the paper is really hinting at the need for parametrizable blocks that can trade off area, time, and power along a Pareto-optimal surface.
"Performance Evaluation of the Functional Description Language in a SDR Environment" by Shi Zhong, Craig Dolwin, Klaus Strohmenger, Bernd Steinke.
This material is based upon work supported by the National Science Foundation under grant #0964120 and #0964592 (”CNS-NeTS”). Additional NSF support was provided under grant #1019343 to the Computing Research Association for the CIFellows Project. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.