|
| From: | Connor Wolf |
| Subject: | Re: [Discuss-gnuradio] Overview of packet decoding? |
| Date: | Thu, 26 Jan 2017 19:44:04 -0800 |
I can see my data in the *receive* window, after round tripping through the USRP hardware (tx -> 30 dB pad -> rx). I've looked through the examples. My notes: ------------- - burst_tagger.grc Seems to be for demonstrating burst shaping, but I'm not sure what burst shaping is for. Could this also be used to insert synchronization symbols into the stream? Possibly also used to control the frequency content of the radio start-up? What are phasing symbols used for? ("Phasing symbols" is a ungooglable term) - example_corr_est.grc More promising, I assume you use a correlation estimator to detect your message preamble? I'm not sure how to apply this to FSK, though, since my demodulated signal from FSK is not a complex value, and you can't switch the the correlation estimator's datatype - example_corr_est_and_clock_sync.grc - example_corr_est_and_phase_sync.grc Both of these are similar to example_corr_est.grc, but I'd have thought you'd want the clock sync/costas loop *before* the correlation estimator, rather then after. Also, again, I'm not sure how any of this applies to a non-complex data stream. - formatter_crc.grc Interesting, the documentation for the `digital_protocol_parser` block seems to suggest that it can do it's own synchronization ("Block that synchronizes to a header based on a header format object class. Designed to accept hard bits and produce PDUs with packed bytes (pmt::u8vector)."). It appears it has to be fed bits at the correct rate still, so I'd still need to do clock recovery beforehand? - formatter_ofdm.grc Seems very similar to `formatter_crc.grc`, but with a different `digital.header_format_xxx` type? - packet_loopback_hier.grc Giant assembly that makes interesting graphs, but I don't quite understand what I'm supposed to do with it. - tx_stage0.grc - tx_stage1.grc These are relatively straightforward. - tx_stage2.grc I think I understand what's going on here, though "CC Encoder" is *COMPLETELY* un-googleable. All you get is stuff about how to encode media using adobe Creative Cloud. I assume is's some form of FEC encoding. - tx_stage3.grc This is relatively straight-forward, though I don't understand why the protocol formatter separates the header and payload components. - tx_stage4.grc - tx_stage5.grc - tx_stage6.grc These seem to be dealing with managing the out-of-band emissions of a BPSK signal? As I understand it, for FSK, this effectively can be implemented by simply filtering the modulation rate-of-change (which is already done in the CPFSK/NBFM blocks) - tx_stage6a.grc Filter stuff. I'm realizing my lack of DSP background. - uhd_packet_rx.grc - packet_rx.grc - uhd_packet_tx.grc - packet_tx.grc While these are interesting, I only have one USRP so I can't do much testing. I tried to merge the files into a single one, but it doesn't work (the receiver turns off as soon as the first TX packet is sent) I unwrapped the packet_rx.grc section to see if I could figure out what's broken, but didnt' get anywhere. Here's the GRC file: https://gist.github.com/fake-name/cc487900b008268e331cc519832fde84 - uhd_packet_rx_tun.grc - uhd_packet_tx_tun.grc I'm not running linux, so I can't play with tun interfaces. I don't have two USRPs anways. - simple_bpsk_tx.grc This /sounds/ like it's exactly where I should start, but it's TX only. A ccomplementing `simple_bpsk_rx.grc` example that can receive the sent messages would be enormously illuminating. - transmitter_sim_hier.grc Is this for testing the "Packet TX" block? ------------- I chose FSK for my test project because I assume it'll be easier to deal with decoding, as the un-modulated signal is purely real. OTOH, I also don't know enough about RF comms to know if that's a completely off-the-wall assumption. Another thing I've noticed is that the USRP TX has a startup time? Generating a gated simple single-tone burst, and graphing the complex to mag^2 over time, I get a gradual ramp-up of the TX power over ~300 milliseconds: https://i.imgur.com/fuNQjbW.png Here's the layout I used to generate that plot: https://i.imgur.com/tAlkNfg.png. This is with the B205mini TX/RX port connected to the RX2 port with 30 db of attenuation. My naive guess is that it's a effect of the TX power amp being power-gated, but that's just seat-of-the-pants on my part. It does appear that design can gate the TX PA power. If it's normal, I'll just ignore it, but I figure I'll ask. Thanks so much! Connor On Thu, Jan 26, 2017 at 2:54 AM, Martin Braun <address@hidden> wrote: Hey Connor, Connor Wolf Sr. Technician / Code Monkey Akela Inc |
| [Prev in Thread] | Current Thread | [Next in Thread] |
