WiNGS Lab @ UW

The digital domain allows for much easier recovery of information from coherent systems. Even though radio channels are noisy and fading and difficult to work with, information can be recovered using approximation.

Warp website

Currently, a two-USRP GNURadio setup is being used, with either differential 8-PSK or straight 8- or 16-QAM.

• GNURadio: Feedback (non-feedforward) AGC that doesn't use std::max(), which should be more noise-resistant
• Error data using PSK/QAM
  • PSK should be taken before differential decoding and after differential encoding, to give numbers for the actual effect on constellation points, in addition to the actual values used
• Working QAM implementation:
  • GNURadio
    • Scrambler block? ('scrambling' can be on a bit level basis, i.e. each bit of a 16QAM gets scrambled independently, if that would aid us. Mason is admittedly unfamiliar with scrambling.)
  • WARP
• Streaming video
  • On GNURadio using IP Works, but laggy on Minis
  • On GNURadio using straight video transmission (benchmark_[tr]x.py) (currently sort-of-works but even worse than IP)
  • On WARP

MPEG Streaming on GR implementation details:

• Proposal is to take apart an MPEG stream, stripe out the I, P, B frames, send them over air, and then reassemble them into an MPEG stream at the other end. This means we need to:
  • Be able to parse an MPEG-2 file in python, read it in, save metadata, and start picking off I, P, B frames, etc
  • Be able to do the striping on separated I,P,B frames and metadata
  • Send this over the wireless link
  • destripe the data
  • reassemble into an MPEG-2 stream
  • output to some video player (through Python?)

What Steve is doing this week:

• Reading about how DSSS works, used in 802.11b,g to spread the signal in frequency. Open questions are:
  • How can this be used to put multiple bit streams with different error protection into one signal? (same error protection seems easy)
    • sub-thought: perhaps by spreading different bit streams by different amounts.
  • Is this implemented in GNU Radio? in WARP?
    • sub-question: where's the documentation for WARP?
• Assuming that QAM on GNU Radio is dead, unless a better AGC/phase error calculator works magically, given that we'll have WARP radios soon.
• Fighting occasionally with docuwiki syntax

Stuff done since October 28, when I started keeping track of what I was doing:

• 19-25 Oct - Read Morelos-Zaragosa Parts 1 & 2 for ideas for improving UEP after meeting with Sayandeep. Part 2 is not useful if we want to stick with something implementable in Wi-Fi hardware. Part 1 is not useful if we want to stay away from coding. We probably do not want to stay away from coding. Read “Carrier Synchronization and Detection of QASK Signal Sets”, Simon & Smith 1974, thinking it may shed some light on synchronization in GNURadio.
• 28 Oct - Began taking specific track of what I was doing, by date. Ran simulations of 64-QAM in matlab to see if I could find a constellation mapping that improves the BER of the most important bits while worsening BER of less important bits (while sticking with vanilla 64-QAM; being able to move the constellation points would make this trivial).
• 30 Oct - ran simulations of 256-QAM to get concrete measurements of UEP properties of 256-QAM, with a focus on what UEP could be taken from different groupings of bits.
• 04 Nov - created gr_diff_phasor_rot/derot_cc in a last-ditch effort to get QAM working on GNU Radio. The idea is to at the sender integrate the phase of the signal being sent, and the receiver differentiate the phase. In this manner, a constant rotation phase due to non-locking will be a (small and manageable) constant phase shift. I think the secret of how D[QB]PSK works in GNU Radio is via a similar mechanism which allows it to ignore locking completely. I somehow couldn't get the SWIG working so that the two new blocks were visible to python.
• 17 Nov - met with Sayandeep, Syed, Shreesha to get a hold of the status of WARP, given that I'm losin' it on GNU Radio. Got a pointer to the matlab file they're using on WARP.
• 19 Nov - read through aforementioned matlab file, seems straightforward enough.

TODO

1. Show effects of proposed changes to the pipeline(via simulations), ie whether the desired behavior of scrambling(consecutive sequence of 0/1 removal), interleaving(burst error mitigation) are hampered because of our suggested reordering.
2. Bit-mapping scheme switch (ie switching from BlockII to grey etc.) → when to switch (finding a metric). Currently we just say that the h/w should have capability to estimate error rates for all schemes (more clarifications/methodology) and some results (correlation between schemes, ie if we estimate the errors for just one scheme, can we predict the same for other schemes ?)??
3. Comment on delay induced by our protocol(we are buffering data), comment on the trade-off between additional delay(jitter??) and performance benefits observed. One more knob that the application can use.
4. Better bit position assignment algorithm, some joint-optimization of bit position assignment and priority of data ??, other things instead of greedy (needs more thoughts, not sure what exactly to do)
5. Do the multicast experiments as done by softcast, ie collect profiles from different location and show performance variation. and show that we let the users get performance commensurate with their channel conditions.
6. Results for audio
7. Other video metric like mos