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. B2XXmini PPS reference jumping around (Sean Nowlan)
2. weird E310 libboost update problem (Jason Matusiak)
3. Re: X300 timing (Sean Nowlan)
4. Re: weird E310 libboost update problem (Philip Balister)
5. Received samples using rx_samples_to_file not same as
transmitted file (Tejashri Kuber)
6. Re: weird E310 libboost update problem (Bela Berde)
7. Re: Received samples using rx_samples_to_file not same as
transmitted file (Mike McLernon)
8. Re: Received samples using rx_samples_to_file not same as
transmitted file (Tejashri Kuber)
9. Re: X300 timing (Jacob Knoles)
10. Which versions of uhd, gnuradio, and gr-ettus will run the
radio gr-ettus examples without crashing on the X310? (Swanson, Craig)
11. Use of the drone DJI Matrix 100 with a radio SDR B205 mini
(gauthier duchene)
12. Re: Received samples using rx_samples_to_file not same as
transmitted file (Marcus M?ller)
13. Re: weird E310 libboost update problem (Jason Matusiak)
14. Re: weird E310 libboost update problem (Philip Balister)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Jun 2017 14:43:25 -0400
From: Sean Nowlan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B2XXmini PPS reference jumping around
Message-ID:
<cagmpsnqbag-v7jkaejyazrfn0we_iakjv+idogpkrvpwfmf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To Whom It May Concern:
I'm using a B200mini (we also have some B205minis which I believe behave
exactly the same). I'm working on a narrowband application that requires a
precise clock due to susceptibility to carrier frequency offset. So far
we've been using a 1PPS as a reference, which gives good accuracy, better
than 100ppb. However, I've noticed that the frequency reference jumps in
discrete steps at 1 second intervals, leading me to believe that the
control voltage to the VCTCXO is updated at the 1PPS edge, and the loop
filter bandwidth in the digital PLL implementation [1] may be too wide. Do
you have any recommendations for greatly reducing the discrete jumps, e.g.,
by greatly narrowing the bandwidth of the loop filter? In our application
it won't be a problem to let the PLL converge over a long period
(hours/days).
Also for clarification, past emails on the list about the TCXO stability
refer to its accuracy (over temperature, I'm assuming) as +/- 0.5ppm.
However the code [1] states that the TCXO is 5ppm. What are these numbers
referring to, and which one is correct?
Thanks,
Sean Nowlan
[1]
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/b2xxmini/b205_ref_pll.v
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/756a5eaf/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 21 Jun 2017 14:55:39 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] weird E310 libboost update problem
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I took an SD card and put a brand new E310 load on it:
e3xx_images/beta/jethro-test/sdimage-gnuradio-demo.direct.xz.
That went fine and it booted normally. I then went into my e3xx prefix
and made a build-arm directory in uhd/host. I then cd-ed into it and ran:
cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
then I ran: make -j4
After that, I ran mkdir ~/E310_remote && sshfs -o allow_root
[email protected]:/ /home/jmat/E310_remote
then: make install
This installs everything across the network to the E310 unit. I then
rebooted the E310 to make sure all was OK and it booted up fine. Next I
ran a uhd_usrp_probe fully expecting it to through a compatibility
mismatch error since the FPGA bitfile wasn't updated yet, but instead I
got this error:
# uhd_usrp_probe
uhd_usrp_probe: error while loading shared libraries:
libboost_program_options.so.1.57.0: cannot open shared object file: No
such file or directory
When I go look in /usr/lib, I see the following:
lrwxrwxrwx 1 root root 34 Apr 4 18:37
./usr/lib/libboost_program_options.so -> libboost_program_options.so.1.58.0
-rwxr-xr-x 1 root root 385360 Apr 4 18:37
./usr/lib/libboost_program_options.so.1.58.0
So it looks to me as if the uhd_usrp_probe was built again libboost
1.57, but the image is running at 1.58. What should I do to get past this?
------------------------------
Message: 3
Date: Wed, 21 Jun 2017 15:17:42 -0400
From: Sean Nowlan <[email protected]>
To: Jacob Knoles <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300 timing
Message-ID:
<CAGmpSnq5MpKd4xChxUKv=rwvkuagvnbjump6ccbm07d+y1-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Off the top of my head, it seems like you need to periodically
resynchronize between system and USRP time. You may be seeing drift between
the two by using boost::this_thread::sleep_for. Maybe you can add an outer
control loop that will wait for a PPS edge by querying get_time_last_pps
every 10ms until the value changes, then load commands using the method
you're using now. This should keep drift from accumulating significantly.
You could experiment with counting N PPS edges to resynchronize less
frequently.
Sean
On Tue, Jun 20, 2017 at 4:14 PM, Jacob Knoles via USRP-users <
[email protected]> wrote:
> Hey Marcus,
>
> Some details, I need the frequency to hop at a rate of 0.333 kHz or every
> 3.003 ms. At the same time I am playing a sequence of pulses continuously
> so my actual available hopping time is more like 333 microseconds (time
> between two pulses).
>
> I am aware of the queue limit and have programmed to accommodate that, I
> try to keep no more than 3-5 commands queued up at a time. In my code I am
> pre-loading 4 commands, then using boost::this_thread::sleep_for() I have
> the thread wait for the 3 ms hop time and loop, adding one more command to
> the queue, until all my hop commands have been issued. I have a queue of
> all the hop commands set up on the host.
>
> I calculate the command execution time using a reference start time which
> I grab from the usrp just before the entire process starts, then offset by
> the hop time multiplied by a loop counter.
>
> Thanks.
>
> Jacob
>
> -----------------------------
> Jacob Knoles
> Compliance Engineer / Software Developer
> MiCOM Labs Inc.
> Pleasanton, CA
>
> On Sun, Jun 18, 2017 at 12:10 AM, Marcus M?ller via USRP-users <
> [email protected]> wrote:
>
>> 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
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> 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/20170621/7bacee9f/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 21 Jun 2017 15:28:15 -0400
From: Philip Balister <[email protected]>
To: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] weird E310 libboost update problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/21/2017 02:55 PM, Jason Matusiak via USRP-users wrote:
> I took an SD card and put a brand new E310 load on it:
> e3xx_images/beta/jethro-test/sdimage-gnuradio-demo.direct.xz.
Also use the sdk from this directory, not the older one.
Philip
>
> That went fine and it booted normally. I then went into my e3xx prefix
> and made a build-arm directory in uhd/host. I then cd-ed into it and ran:
> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
>
> then I ran: make -j4
>
> After that, I ran mkdir ~/E310_remote && sshfs -o allow_root
> [email protected]:/ /home/jmat/E310_remote
>
> then: make install
>
> This installs everything across the network to the E310 unit. I then
> rebooted the E310 to make sure all was OK and it booted up fine. Next I
> ran a uhd_usrp_probe fully expecting it to through a compatibility
> mismatch error since the FPGA bitfile wasn't updated yet, but instead I
> got this error:
> # uhd_usrp_probe
> uhd_usrp_probe: error while loading shared libraries:
> libboost_program_options.so.1.57.0: cannot open shared object file: No
> such file or directory
>
> When I go look in /usr/lib, I see the following:
> lrwxrwxrwx 1 root root 34 Apr 4 18:37
> ./usr/lib/libboost_program_options.so -> libboost_program_options.so.1.58.0
> -rwxr-xr-x 1 root root 385360 Apr 4 18:37
> ./usr/lib/libboost_program_options.so.1.58.0
>
> So it looks to me as if the uhd_usrp_probe was built again libboost
> 1.57, but the image is running at 1.58. What should I do to get past this?
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Wed, 21 Jun 2017 13:53:22 -0400
From: Tejashri Kuber <[email protected]>
To: [email protected]
Subject: [USRP-users] Received samples using rx_samples_to_file not
same as transmitted file
Message-ID:
<cacrf2hq0g2y7dny+5lkkacsw8r78v7wsf4rnpjxirc8ylp3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I'm using two X-310 USRPs for transmission and reception, with OctoClock-G
input. I'm transmitting WLAN packets repeatedly at 100ms intervals, using
the UHD example tx_samples_from_file, at rate 20MHz. I'm receiving this
data, a few feet away, using rx_samples_to_file at 20MHz rate. I'm able to
cross-correlate the packets with the 802.11 preamble to obtain the packets,
and I'm able to observe the packets in the received data file visually as
well (when plotted).
However, looking closely I see that the packet size isn't the same - few of
the samples at the end have been dropped.
Also, the start of the packet (short preamble) cannot be recovered
completely.
Using padding before and after the packet, I was able to fix this issue,
but the demodulated and decoded data field still has many errors. I am
using MATLAB's WLAN toolbox for demodulating and decoding.
Have you faced these errors before? Please let me know if you need any
further details of my experimental setup.
1. Incorrect number of received samples
2. Incorrect decoding of received WLAN data
Any help/suggestions will be appreciated.
Thanks and regards,
Tejashri
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/cfb8de34/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 21 Jun 2017 19:39:20 +0000
From: Bela Berde <[email protected]>
To: Jason Matusiak <[email protected]>, Philip Balister
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] weird E310 libboost update problem
Message-ID:
<cacwuzi9qbmz8-zhenftlh9jedgqbdnnxd3jse8zbtcfax+z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
A general remark:
I think this boost library dependance should be (can be easely) removed,
since only some old fashioned constructs require it, such as unique or
shared pointers (I cannot remember), witnessing at least 5 years of missing
code maintenance.
Cheers
On Wed, 21 Jun 2017 at 21:29, Philip Balister via USRP-users <
[email protected]> wrote:
> On 06/21/2017 02:55 PM, Jason Matusiak via USRP-users wrote:
> > I took an SD card and put a brand new E310 load on it:
> > e3xx_images/beta/jethro-test/sdimage-gnuradio-demo.direct.xz.
>
> Also use the sdk from this directory, not the older one.
>
> Philip
>
> >
> > That went fine and it booted normally. I then went into my e3xx prefix
> > and made a build-arm directory in uhd/host. I then cd-ed into it and
> ran:
> > cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
> > -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
> >
> > then I ran: make -j4
> >
> > After that, I ran mkdir ~/E310_remote && sshfs -o allow_root
> > [email protected]:/ /home/jmat/E310_remote
> >
> > then: make install
> >
> > This installs everything across the network to the E310 unit. I then
> > rebooted the E310 to make sure all was OK and it booted up fine. Next I
> > ran a uhd_usrp_probe fully expecting it to through a compatibility
> > mismatch error since the FPGA bitfile wasn't updated yet, but instead I
> > got this error:
> > # uhd_usrp_probe
> > uhd_usrp_probe: error while loading shared libraries:
> > libboost_program_options.so.1.57.0: cannot open shared object file: No
> > such file or directory
> >
> > When I go look in /usr/lib, I see the following:
> > lrwxrwxrwx 1 root root 34 Apr 4 18:37
> > ./usr/lib/libboost_program_options.so ->
> libboost_program_options.so.1.58.0
> > -rwxr-xr-x 1 root root 385360 Apr 4 18:37
> > ./usr/lib/libboost_program_options.so.1.58.0
> >
> > So it looks to me as if the uhd_usrp_probe was built again libboost
> > 1.57, but the image is running at 1.58. What should I do to get past
> this?
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Sent from iPad
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/13794cc1/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 21 Jun 2017 19:58:01 +0000
From: Mike McLernon <[email protected]>
To: Tejashri Kuber <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Received samples using rx_samples_to_file
not same as transmitted file
Message-ID:
<dm2pr05mb448c801bc759e0a8028a959e9...@dm2pr05mb448.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Tejashri,
A few thoughts:
1. Are you getting any overruns or underruns?
2. Is there any command line output that would be helpful to send?
3. Are you using C code gen?
4. Are you using burst mode at the tx or rx?
Given that you are using WLAN System Toolbox, it might be best if you contacted
our tech support directly, at https://www.mathworks.com/support/, so that you
can get routed to the WLAN System Toolbox team.
Best,
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
Tejashri Kuber via USRP-users
Sent: Wednesday, June 21, 2017 1:53 PM
To: [email protected]
Subject: [USRP-users] Received samples using rx_samples_to_file not same as
transmitted file
Hello all,
I'm using two X-310 USRPs for transmission and reception, with OctoClock-G
input. I'm transmitting WLAN packets repeatedly at 100ms intervals, using the
UHD example tx_samples_from_file, at rate 20MHz. I'm receiving this data, a few
feet away, using rx_samples_to_file at 20MHz rate. I'm able to cross-correlate
the packets with the 802.11 preamble to obtain the packets, and I'm able to
observe the packets in the received data file visually as well (when plotted).
However, looking closely I see that the packet size isn't the same - few of the
samples at the end have been dropped.
Also, the start of the packet (short preamble) cannot be recovered completely.
Using padding before and after the packet, I was able to fix this issue, but
the demodulated and decoded data field still has many errors. I am using
MATLAB's WLAN toolbox for demodulating and decoding.
Have you faced these errors before? Please let me know if you need any further
details of my experimental setup.
1. Incorrect number of received samples
2. Incorrect decoding of received WLAN data
Any help/suggestions will be appreciated.
Thanks and regards,
Tejashri
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/19b12a34/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 21 Jun 2017 20:23:15 +0000
From: Tejashri Kuber <[email protected]>
To: Mike McLernon <[email protected]>, Tejashri Kuber
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Received samples using rx_samples_to_file
not same as transmitted file
Message-ID:
<cacrf2hp0qj7pbaaqbxm7oubg1hw9qpsyrdqgnqprqecgihp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you for your prompt reply.
I'll try answering-
1. No underruns or overruns
2. The usual command line output when rx_samples_to_file: no aberration
3. Yes, I'm using the basic UHD examples which are written in C.
4. No, I'm not using the burst mode in either the transmitter or the
receiver.
Thank you for the MATLAB tech support suggestion, I'll do that.
Please let me know if there's anything else I can clarify.
Any help would be very welcome.
Thanks,
Tejashri
On Wed, Jun 21, 2017 at 3:58 PM Mike McLernon <[email protected]>
wrote:
> Hi Tejashri,
>
>
>
> A few thoughts:
>
> 1. Are you getting any overruns or underruns?
>
> 2. Is there any command line output that would be helpful to send?
>
> 3. Are you using C code gen?
>
> 4. Are you using burst mode at the tx or rx?
>
>
>
> Given that you are using WLAN System Toolbox, it might be best if you
> contacted our tech support directly, at https://www.mathworks.com/support/,
> so that you can get routed to the WLAN System Toolbox team.
>
>
>
> Best,
>
> Mike
>
>
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Tejashri Kuber via USRP-users
> *Sent:* Wednesday, June 21, 2017 1:53 PM
> *To:* [email protected]
> *Subject:* [USRP-users] Received samples using rx_samples_to_file not
> same as transmitted file
>
>
>
> Hello all,
>
> I'm using two X-310 USRPs for transmission and reception, with OctoClock-G
> input. I'm transmitting WLAN packets repeatedly at 100ms intervals, using
> the UHD example tx_samples_from_file, at rate 20MHz. I'm receiving this
> data, a few feet away, using rx_samples_to_file at 20MHz rate. I'm able to
> cross-correlate the packets with the 802.11 preamble to obtain the packets,
> and I'm able to observe the packets in the received data file visually as
> well (when plotted).
>
> However, looking closely I see that the packet size isn't the same - few
> of the samples at the end have been dropped.
>
> Also, the start of the packet (short preamble) cannot be recovered
> completely.
>
> Using padding before and after the packet, I was able to fix this issue,
> but the demodulated and decoded data field still has many errors. I am
> using MATLAB's WLAN toolbox for demodulating and decoding.
>
> Have you faced these errors before? Please let me know if you need any
> further details of my experimental setup.
>
> 1. Incorrect number of received samples
>
> 2. Incorrect decoding of received WLAN data
>
> Any help/suggestions will be appreciated.
>
> Thanks and regards,
>
> Tejashri
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/6621e795/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 21 Jun 2017 13:28:43 -0700
From: Jacob Knoles <[email protected]>
To: Sean Nowlan <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300 timing
Message-ID:
<ca+z4yfgu3z+ftgkr1ns8mthstx2u-n0iz_sk38wxjpr4h6s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sean,
That's an interesting idea, I will look into it. I had thought that by
utilizing the timed command queue I was not relying on the system time, I
know that keeping the system and USRP time in sync would be problematic at
best. I also know there is a cap on the command queue and that the USRP
should execute a tune command every 3 ms so by making the host thread wait
for even approximately 3 ms before adding another command to the queue I
could keep at least 2-3 commands in the queue while not overloading it.
Then by using a reference time taken from the USRP just before beginning
this sequence, and offsetting by the required hop time, using USRP time,
there wouldn't be an issue. I am not sure how the host's time keeping is
causing this delay? As a side note, is there a way to query the USRP to
find out how many commands are queued? I could not find anything that
suggested as much.
Thanks!
On Wed, Jun 21, 2017 at 12:17 PM, Sean Nowlan <[email protected]> wrote:
> Off the top of my head, it seems like you need to periodically
> resynchronize between system and USRP time. You may be seeing drift between
> the two by using boost::this_thread::sleep_for. Maybe you can add an outer
> control loop that will wait for a PPS edge by querying get_time_last_pps
> every 10ms until the value changes, then load commands using the method
> you're using now. This should keep drift from accumulating significantly.
> You could experiment with counting N PPS edges to resynchronize less
> frequently.
>
> Sean
>
> On Tue, Jun 20, 2017 at 4:14 PM, Jacob Knoles via USRP-users <
> [email protected]> wrote:
>
>> Hey Marcus,
>>
>> Some details, I need the frequency to hop at a rate of 0.333 kHz or every
>> 3.003 ms. At the same time I am playing a sequence of pulses continuously
>> so my actual available hopping time is more like 333 microseconds (time
>> between two pulses).
>>
>> I am aware of the queue limit and have programmed to accommodate that, I
>> try to keep no more than 3-5 commands queued up at a time. In my code I am
>> pre-loading 4 commands, then using boost::this_thread::sleep_for() I
>> have the thread wait for the 3 ms hop time and loop, adding one more
>> command to the queue, until all my hop commands have been issued. I have a
>> queue of all the hop commands set up on the host.
>>
>> I calculate the command execution time using a reference start time which
>> I grab from the usrp just before the entire process starts, then offset by
>> the hop time multiplied by a loop counter.
>>
>> Thanks.
>>
>> Jacob
>>
>> -----------------------------
>> Jacob Knoles
>> Compliance Engineer / Software Developer
>> MiCOM Labs Inc.
>> Pleasanton, CA
>>
>> On Sun, Jun 18, 2017 at 12:10 AM, Marcus M?ller via USRP-users <
>> [email protected]> wrote:
>>
>>> 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
>>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>> _______________________________________________
>> 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/20170621/e07c3c0f/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 21 Jun 2017 23:15:40 +0000
From: "Swanson, Craig" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Which versions of uhd, gnuradio, and gr-ettus
will run the radio gr-ettus examples without crashing on the X310?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I am having trouble running the RFNoC Radio gr-ettus/examples/rfnoc specific
flowgraphs without crashing. In particular, the ones that are giving me
trouble are rfnoc_tx.grc, rfnoc_rxtx.grc, rfnoc_ddc.grc, and rfnoc_duc.grc
Which version of Ubuntu is the most stable running the RFNoC flowgraphs?
14.04, 15.04, or 16.04?
I am using a UBX-160.
I followed the appnote getting started with RFNoC:
git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git
[https://avatars2.githubusercontent.com/u/125709?v=3&s=400]<https://github.com/EttusResearch/uhd.git>
GitHub - EttusResearch/uhd: The USRP(tm) Hardware Driver
Repository<https://github.com/EttusResearch/uhd.git>
github.com
uhd - The USRP(tm) Hardware Driver Repository
git clone --recursive -b master https://github.com/gnuradio/gnuradio.git
[https://avatars3.githubusercontent.com/u/1278659?v=3&s=400]<https://github.com/gnuradio/gnuradio.git>
GitHub - gnuradio/gnuradio: GNU Radio<https://github.com/gnuradio/gnuradio.git>
github.com
gnuradio - GNU Radio
git clone -b master https://github.com/EttusResearch/gr-ettus.git
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170621/a84ffa86/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 22 Jun 2017 08:27:48 +0200
From: gauthier duchene <[email protected]>
To: [email protected]
Subject: [USRP-users] Use of the drone DJI Matrix 100 with a radio SDR
B205 mini
Message-ID:
<capxtmhrjnq66edjupkud5eahfpfgyqnvglke+ebv573qrbv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello guys,
During the last months I had the opportunity to work on a exciting
project, the purpose was to work with a drone DJI Matrix 100 and a radio
ETTUS USRP B205 mini in the same source code to carry out a tracking.
The goal is to have an autonomous drone that is able to locate a missing
person, to provide video footages of his location to the rescue team and
create a mobile network to communicate with him. I put the Github link for
those who would be interested in running these two devices together, there
are the CmakeList to compile both.
At the moment, I was able to make a dozen fully autonomous flights and each
time the drone found the target at a distance of about 30-40 meters.
Technical precision : I used a directional antenna on the drone and a
pattern matching method to find the direction of the target.
The link : https://github.com/gauthduchene/mfe/tree/master/Onboard-SDK-3.2
Do not hesitate to contact me for details
kind regards,
Gauthier Duch?ne
--
Gauthier Duch?ne
MA2 student - MSc in Electronics and Information Technology
focus Nano, opto-electronics and Embedded Systems
T : +32 (0)479 52 06 23
[email protected]
[image: www.ulb.be] <http://www.ulb.ac.be/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170622/1c98de99/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 22 Jun 2017 10:26:58 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Received samples using rx_samples_to_file
not same as transmitted file
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hello Tejashri,
the signal processing chain of any SDR contains phase delays ? I don't
know what /exactly/ you're saving in the files you transmit, but it
sounds like just padding with a couple zeros at the end might solve the
problem by "flushing" out the remainder of signal out of the different
filters and DSP mechanisms.
Best regards,
Marcus
On 06/21/2017 07:53 PM, Tejashri Kuber via USRP-users wrote:
> Hello all,
>
> I'm using two X-310 USRPs for transmission and reception, with
> OctoClock-G input. I'm transmitting WLAN packets repeatedly at 100ms
> intervals, using the UHD example tx_samples_from_file, at rate 20MHz.
> I'm receiving this data, a few feet away, using rx_samples_to_file at
> 20MHz rate. I'm able to cross-correlate the packets with the 802.11
> preamble to obtain the packets, and I'm able to observe the packets in
> the received data file visually as well (when plotted).
>
> However, looking closely I see that the packet size isn't the same -
> few of the samples at the end have been dropped.
> Also, the start of the packet (short preamble) cannot be recovered
> completely.
>
> Using padding before and after the packet, I was able to fix this
> issue, but the demodulated and decoded data field still has many
> errors. I am using MATLAB's WLAN toolbox for demodulating and decoding.
>
> Have you faced these errors before? Please let me know if you need any
> further details of my experimental setup.
> 1. Incorrect number of received samples
> 2. Incorrect decoding of received WLAN data
>
> Any help/suggestions will be appreciated.
>
> Thanks and regards,
> Tejashri
>
>
> _______________________________________________
> 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/20170622/05610614/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 22 Jun 2017 09:50:47 -0400
From: Jason Matusiak <[email protected]>
To: Philip Balister <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] weird E310 libboost update problem
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Philip, How would the directions go now (I am originally following the
ones from the Ettus website)? I don't see somewhere in my prefix to
replace the oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh with
the one that was in the jethro-test folder.
So I am guessing that I need to download it, and then run it, and let it
install to the default /usr/local/oecore-x86_64?
If want to bounce between two different images (say a new one and the
one we've been fielding), is there a way two have two of these installed
at the same time? Or do I just need to keep overwriting things?
~Jason
On 06/21/2017 03:28 PM, Philip Balister wrote:
> On 06/21/2017 02:55 PM, Jason Matusiak via USRP-users wrote:
>> I took an SD card and put a brand new E310 load on it:
>> e3xx_images/beta/jethro-test/sdimage-gnuradio-demo.direct.xz.
> Also use the sdk from this directory, not the older one.
>
> Philip
>
>> That went fine and it booted normally. I then went into my e3xx prefix
>> and made a build-arm directory in uhd/host. I then cd-ed into it and ran:
>> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
>> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
>>
>> then I ran: make -j4
>>
>> After that, I ran mkdir ~/E310_remote && sshfs -o allow_root
>> [email protected]:/ /home/jmat/E310_remote
>>
>> then: make install
>>
>> This installs everything across the network to the E310 unit. I then
>> rebooted the E310 to make sure all was OK and it booted up fine. Next I
>> ran a uhd_usrp_probe fully expecting it to through a compatibility
>> mismatch error since the FPGA bitfile wasn't updated yet, but instead I
>> got this error:
>> # uhd_usrp_probe
>> uhd_usrp_probe: error while loading shared libraries:
>> libboost_program_options.so.1.57.0: cannot open shared object file: No
>> such file or directory
>>
>> When I go look in /usr/lib, I see the following:
>> lrwxrwxrwx 1 root root 34 Apr 4 18:37
>> ./usr/lib/libboost_program_options.so -> libboost_program_options.so.1.58.0
>> -rwxr-xr-x 1 root root 385360 Apr 4 18:37
>> ./usr/lib/libboost_program_options.so.1.58.0
>>
>> So it looks to me as if the uhd_usrp_probe was built again libboost
>> 1.57, but the image is running at 1.58. What should I do to get past this?
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
------------------------------
Message: 14
Date: Thu, 22 Jun 2017 10:21:42 -0400
From: Philip Balister <[email protected]>
To: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] weird E310 libboost update problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/22/2017 09:50 AM, Jason Matusiak via USRP-users wrote:
> Philip, How would the directions go now (I am originally following the
> ones from the Ettus website)? I don't see somewhere in my prefix to
> replace the oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh with
> the one that was in the jethro-test folder.
>
> So I am guessing that I need to download it, and then run it, and let it
> install to the default /usr/local/oecore-x86_64?
Ah, here is the answer to your question. Don't use the default install
path :)
I have (on one machine):
[balister@mini ~]$ ls sdks/
master-032016 release-4
So I made a directory "sdks" in my home directory and and install the
sdks there. This way I can easily access multiple sdks, dependsing on
what I am using and/or testing.
Philip
>
> If want to bounce between two different images (say a new one and the
> one we've been fielding), is there a way two have two of these installed
> at the same time? Or do I just need to keep overwriting things?
>
> ~Jason
>
>
> On 06/21/2017 03:28 PM, Philip Balister wrote:
>> On 06/21/2017 02:55 PM, Jason Matusiak via USRP-users wrote:
>>> I took an SD card and put a brand new E310 load on it:
>>> e3xx_images/beta/jethro-test/sdimage-gnuradio-demo.direct.xz.
>> Also use the sdk from this directory, not the older one.
>>
>> Philip
>>
>>> That went fine and it booted normally. I then went into my e3xx prefix
>>> and made a build-arm directory in uhd/host. I then cd-ed into it and
>>> ran:
>>> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
>>> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON ..
>>>
>>> then I ran: make -j4
>>>
>>> After that, I ran mkdir ~/E310_remote && sshfs -o allow_root
>>> [email protected]:/ /home/jmat/E310_remote
>>>
>>> then: make install
>>>
>>> This installs everything across the network to the E310 unit. I then
>>> rebooted the E310 to make sure all was OK and it booted up fine. Next I
>>> ran a uhd_usrp_probe fully expecting it to through a compatibility
>>> mismatch error since the FPGA bitfile wasn't updated yet, but instead I
>>> got this error:
>>> # uhd_usrp_probe
>>> uhd_usrp_probe: error while loading shared libraries:
>>> libboost_program_options.so.1.57.0: cannot open shared object file: No
>>> such file or directory
>>>
>>> When I go look in /usr/lib, I see the following:
>>> lrwxrwxrwx 1 root root 34 Apr 4 18:37
>>> ./usr/lib/libboost_program_options.so ->
>>> libboost_program_options.so.1.58.0
>>> -rwxr-xr-x 1 root root 385360 Apr 4 18:37
>>> ./usr/lib/libboost_program_options.so.1.58.0
>>>
>>> So it looks to me as if the uhd_usrp_probe was built again libboost
>>> 1.57, but the image is running at 1.58. What should I do to get past
>>> this?
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
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 21
******************************************
