Hi Ellie,
> The nature of the equipment I am working with requires that the SDR
be plugged in to a different computer from the one which is storing the
data,
The problem is not that it's not on the same computer – the problem is
that the samples coming from a USRP are just that: samples, not voltage
measurements calibrated to a known voltage.
You could calibrate yourself, however, using a source of signal of
known power, and infer the proportionality between say sample magnitude
squared and watt, and from that the proportionality between sample
amplitude and volt.
> Also -- if you don't mind me asking, what does it mean that the
constructors deadlock each other?
Depending on the configuration, a TCP socket block might only finish
its constructor when the TCP connection is established. If the other
side does the same, you get a deadlock.
> If you know of any blocks or methods that are more reliable, I am
open to suggestions.
ZeroMQ blocks.
Also, I don't know which USRPs you have, but a lot of them are network-
based and could directly used by your remote computer.
Also, be double sure that your network link even allows the data rate
you want it to pass.
Especially, you might want to send the original short samples instead
of converting them to (twice as large in data size) floating point
numbers and then pumping them through network.
Also: we've marked the WX GUI blocks deprecated about four years ago.
Please don't use WX anymore, we've removed it from GNU Radio and can't
fix any bugs with it. It's unsupported from our side! Use the Qt GUI
instead.
Most importantly:
Your File Meta sink really makes no sense in your ettus-filesink.grc.
There's no metadata to save here, at all, because the TCP sink/source
doesn't even transport any tags.
There's zeroMQ sinks/sources that do that!
Best regards,
Marcus
On Thu, 2019-07-25 at 13:21 -0400, Ellie White wrote:
> Forgot to cc the list the first time...
>
>
> On Thu, Jul 25, 2019 at 1:16 PM Ellie White <elliewhite1420@gmail.com> wrote:
> > Hi Marcus,
> >
> > Thanks for the suggestion, much appreciated. Do you have an alternative to recommend? The nature of the equipment I am working with requires that the SDR be plugged in to a different computer from the one which is storing the data, so that is why some kind of socket connection is needed. Also -- if you don't mind me asking, what does it mean that the constructors deadlock each other? How does this affect the data I am collecting? If you know of any blocks or methods that are more reliable, I am open to suggestions.
> >
> > Thanks again!
> > Ellie
> >
> > On Thu, Jul 25, 2019 at 12:51 PM Müller, Marcus (CEL) <mueller@kit.edu> wrote:
> > > Also, I'd recommend not to rely on TCP sink/source, it's python-only
> > > and it is indeed quite fiddly – the constructors can deadlock each
> > > other.
> > > On Wed, 2019-07-10 at 17:51 -0400, Marcus D. Leech wrote:
> > > > On 07/10/2019 02:54 PM, Ellie White wrote:
> > > > > Hello!
> > > > >
> > > > > I am working on a radio astronomy project with the Green Bank
> > > > > Observatory / NRAO Central Development Lab this summer, utilizing GNU
> > > > > Radio and an Ettus Research SDR, and I've got a question regarding how
> > > > > to collect metadata information from a filesink.
> > > > >
> > > > > I have attached the flowgraph I am using to this email. The project
> > > > > requires that I use two computers in tandem for data collection -- one
> > > > > is connected to the Ettus -- it is the TCP server, and sends an
> > > > > interleaved data stream to the TCP client flowgraph (attached) on the
> > > > > machine which will be storing the data. As you can see, I am saving
> > > > > integrated spectra to a file. My question is simply, how do I retrieve
> > > > > a time stamp corresponding to each spectra using the metadata time
> > > > > sink? I have been fiddling with this all afternoon attempting to get
> > > > > it to work properly, and I have been able to save data to a file, read
> > > > > out spectra (using attached Python program), and display header
> > > > > information using the command gr_read_file_metadata in the terminal,
> > > > > but this is just showing me a timestamp for the beginning of the data
> > > > > collection run, rather than showing me timestamps for each spectrum
> > > > > which is saved to file, and I am not sure how to implement this.
> > > > >
> > > > > Any advice would be much appreciated! If I can provide any more info
> > > > > about my system or what steps I have tried, please let me know. Thank
> > > > > you so much for your time -- have a good afternoon!
> > > > >
> > > > > Best,
> > > > > Ellie
> > > >
> > > > So, another thing to keep in mind is that the TCP source/sink DO NOT
> > > > CARRY metadata tags--only the samples. So if you're relying on that,
> > > > it won't work.
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
No comments:
Post a Comment