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 <martin.braun@ettus.com> wrote:
Hey Connor,
don't worry, you'll get there! It's a big question, though, and you
should go step-by-step or it can be frustrating. You also may need to do
frequency synchronization since you're not at baseband.
First, can you see your signal in the time sink when you're
transmitting? If so, that's a good first step. Once that's working,
adding the header would be the next step. Take a look at the examples in
gr-digital/examples/packet.
Cheers,
Martin
On 01/23/2017 11:55 PM, Connor Wolf wrote:
> Hi there!
>
> I'm experimenting with a USRP, trying to transmit and receive a simple
> manchester-coded bfsk signal, and I'm stuck on how to properly build a
> message packet, and actually extract the data from the received waveform.
>
> Basically, I have the receive chain all functional, and I can see the
> data in a time-sink window, but I've been unable to figure out where to
> go from there.
>
> Right now, I'm using a random PDU generator, with a custom block that
> does the manchester encoding. Here is my current flow-graph:
> Inline image 1
> http://imgur.com/a/tBqyw
>
> (Note that the repeats are primarily to make the data easier to see in
> the time window)
>
> I'm pretty clearly missing a few things - There's no header or
> synchronization, and I'm not sure how to add them.
>
> As I understand it, I need to do a few things to make this a "real" system:
>
> * Prepend synchronization and header to the data (do I do this in PDU
> form, or as bytes?
> If this is done in the bytes stage, I'd need to also modify the
> stream length tag, I guess.
> * Synchronization and header and detection
> * clock recovery (easy since it's manchester)
> * data unslicing (Is that the right term?)
>
> I'm relatively clear on how I'd do this manually (I've done this kind of
> thing with simple OOK-ed radios on a microprocessor before), I have no
> idea how to implement the system within gnuradio. The only example that
> seems relevant is the `uhd_packet_tx.py` and `uhd_packet_rx.py` files,
> but for some reason when I try to run them, the `uhd_packet_rx.py`
> example disables the USRP rx as soon as a single message is received,
> and I've been unable to determine why.
>
> Any help would be wonderful, I'm currently more or less flailing
> randomly and realizing how little I know about RF anything.
>
> I'm using GNURadio 3.7.10.1, with a USRP B205mini-i on windows, if it's
> relevant.
>
> --
> Connor Wolf
> Sr. Technician / Code Monkey
> Akela Inc
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Connor Wolf
Sr. Technician / Code Monkey
Akela Inc
No comments:
Post a Comment