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 <[email protected]> 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
> > [email protected]
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Connor Wolf
Sr. Technician / Code Monkey
Akela Inc_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
