approx-comm
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
approx-comm [2008/10/28 16:17] masond adding the MPEG streaming stuff |
approx-comm [2009/05/02 13:31] (current) sdsen |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | =====Approximate communications using Software Radio.===== | + | **[[http://pages.cs.wisc.edu/~sdsen/wiki/doku.php?id=old_page_apex|Older updates]]**\\ |
| - | 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. | + | **TODO** |
| - | ====Resources==== | + | - **Evaluate the impact of proposed changes to the radio 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 pipeline modifications.** |
| - | [[http://warp.rice.edu/trac|Warp website]] | + | - **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 ?) + rate assignment?? ** |
| - | ====Setup==== | + | - 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) |
| - | Currently, a two-USRP GNURadio setup is being used, with either differential 8-PSK or straight 8- or 16-QAM. | + | - **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.** Maybe point out how the protocol can be opportunistic. |
| - | + | - Comment on throughput achieved by different bit-mapping schemes(as opposed to application performance). Comment on what to choose if thrpt. is the only metric. | |
| - | ====Todo==== | + | - 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. |
| - | * GNURadio: Feedback (non-feedforward) AGC that doesn't use std::max(), which should be more noise-resistant | + | - Results for audio |
| - | * Error data using PSK/QAM | + | - Other video metric like mos |
| - | * 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 | + | **Writing Issues** |
| - | * Working QAM implementation: | + | - Why are selected error rate/ FEC rate values relevant ?(SB had commented earlier that the choice of evaluation seetings seem ad-hoc) |
| - | * GNURadio | + | - The MOS mapping table(from medusa). |
| - | * 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 | + | |
| - | * <del>On GNURadio using IP</del> 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?) | + | |
| - | + | ||
| - | + | ||
| - | ====Help, I Don't Have the Permissions to Create a New Page for This==== | + | |
| - | + | ||
| - | 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 | + | |
approx-comm.1225228666.txt.gz · Last modified: 2008/10/28 16:17 by masond
Page Tools
