Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. MIT Haystack Digital RF v2.5 open source release (Frank Lind)
2. Re: X300 timing (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Sat, 17 Jun 2017 19:09:29 -0400
From: Frank Lind <[email protected]>
To: [email protected]
Subject: [USRP-users] MIT Haystack Digital RF v2.5 open source release
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
MIT Haystack Observatory is pleased to announce the formal open source release
of Digital RF version 2.5 under a BSD license. The software implements a data
recording format for scientific radio frequency (RF) instrumentation using the
HDF5 scientific data format. The implementation is designed for the management
of highly time-dependent data from a large number of radio sensors.
Applications include radio science (e.g., radio astronomy, geospace radar) and
any project requiring the capture and use of RF data as raw digital samples.
Key Digital RF features include:
1. Data is written in a very deterministic way that allows for both high-speed
linear recording of data and O(1) read-back of arbitrary data intervals.
2. Consistent metadata is provided and a sub-library offers a robust means of
creating time-dependent metadata to annotate the raw RF data.
3. Tools, examples, and interfaces are provided to demonstrate use of the
software and to allow basic manipulation and visualization of the data.
4. The Haystack Observatory Recorder (thor) is provided as a data recording
example for use with Ettus software radios (i.e., X300, N200, B210, B200mini).
5. The core implementation is written in the C programming language with a
Python wrapper.
6. A MATLAB interface is provided for reading data.
7. An interface to popular software radio systems is provided through a plugin
for the GNU radio framework.
This work was supported by the National Science Foundation under the Geospace
Facilities and MRI programs, and by National Instruments/Ettus Corporation
through the donation of software radio hardware. We are grateful for the
support that made this development possible.
Digital RF is available on GitHub:
https://github.com/MITHaystack/digital_rf
We hope you find the software useful and can contribute to its future
development. For discussions related to Digital RF, please use our mailing
lists ([email protected] [email protected]).
Regards,
Frank Lind, Bill Rideout, Juha Vierinen, Ryan Volz, John Swoboda, and Phil
Erickson
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170617/4944f2c7/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 18 Jun 2017 09:10:52 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X300 timing
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Jacob,
hm, the timing should not becoming worse, unless at some point, you
don't get the commands or the samples out to the USRP in time. So, the
GPSDO shouldn't improve things.
Since the command queue is of limited depth, the latter might be the
case. What's your hop time, just to give us an order of magnitude?
Best regards,
Marcus
On 06/17/2017 12:08 AM, Jacob Knoles via USRP-users wrote:
> Hello,
>
> I am developing a frequency hopper that must transmit a specified
> number of pulses on each frequency, then change frequencies within a
> short and specific window of time.
>
> I am currently achieving this using the timed commands of the X300, I
> load the buffer with frequency tune requests all increasingly offset
> from a reference start point.
>
> For example (pseudo-code):
>
> set usrp time = 0
> reference time = get usrp time
> change frequency at reference time + (hop time * 1)
> change frequency at reference time + (hop time * 2)
> change frequency at reference time + (hop time * 3)
> .... and so on.
>
> Meanwhile in a helper thread I have the tx_streamer that replays the
> pulse sequence the specified number of times.
>
> So far this is working out very well, but I have noticed that with
> more hops, the timing becomes less accurate, there is more time
> between each frequency change.
> And since my ultimate goal is 100 frequency hops this is an issue.
>
> My initial thought is that this could be remedied by utilizing the
> GPSDO option, thus giving the X300 a much better clock source. Could
> someone please confirm this for me as I do not have the GPSDO option.
>
> Or if anyone has any better ideas I am open to suggestions.
>
> Note: I am using the UHD C++ API directly (not using GNU-Radio).
>
> Thanks!
>
> -- Jacob
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170618/b128544a/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 82, Issue 18
******************************************
