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. Wiring setup for calibration (Steve Gough)
2. Re: Wiring setup for calibration ([email protected])
3. Re: Repeat Function error - tx_samples_from_file program
(Cho, Daniel J (332C))
4. How to use one of USRP deicves connected to one computer
(David Yu ( III ))
5. Re: How to use one of USRP deicves connected to one computer
(Nate Temple)
6. Re: no product ID (Nate Temple)
7. Re: Trigger Signal (Julian Arnold)
8. USRP bin file to cfile conversion (Snehasish Kar)
9. Re: USRP bin file to cfile conversion (Marcus M?ller)
10. system requirements for 6X6 MIMO (Nikita Airee)
11. Re: USRP bin file to cfile conversion (Snehasish Kar)
12. Re: USRP bin file to cfile conversion (Marcus M?ller)
13. Re: The single USRP B210 achives to synchronize with GPS and
receive signal in 15:30(for example), how to implement?
(Marcus M?ller)
14. Re: USRP bin file to cfile conversion (Snehasish Kar)
15. Re: E310, rx_samples_to_file.cpp example, output question
(Marcus M?ller)
16. Re: x310 (Marcus M?ller)
17. Re: USRP bin file to cfile conversion (Claudio Cicconetti)
18. Re: USRP bin file to cfile conversion (Marcus M?ller)
19. Re: Error with multiple block output ports (Barker, Douglas W.)
20. Re: USRP bin file to cfile conversion (Snehasish Kar)
21. Re: GRC + RFNoC + Radio Loopback (Christophe ALEXANDRE)
22. Re: Trigger Signal (Mareike Hetzel)
23. Using the gpio in an OOT (Santos Campos)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 Jun 2017 12:22:29 -0400
From: Steve Gough <[email protected]>
To: [email protected]
Subject: [USRP-users] Wiring setup for calibration
Message-ID:
<CAFq1tbwxrBHe0ZdL1j+AcxFa=hdhvf1o09+t_xervqygjc4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I am running the UHD I/Q imbalance and DC offset calibration utilities on
my N210 with the CBX daughter board. Could you please tell me if this
calibration needs to be run without even the SMA/MCX cable that connects
from the front panel to the daughterboards ?
Or it does not matter, and I will only need to ensure that I have no
antennas connected to the front panel of the USRP?
Thanks!
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170605/a31f3bd8/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 05 Jun 2017 13:22:28 -0400
From: [email protected]
To: Steve Gough <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Wiring setup for calibration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
You should not have anything connected--there's an internal CAL pathway.
On 2017-06-05 12:22, Steve Gough via USRP-users wrote:
> Hi All,
>
> I am running the UHD I/Q imbalance and DC offset calibration utilities on my
> N210 with the CBX daughter board. Could you please tell me if this
> calibration needs to be run without even the SMA/MCX cable that connects from
> the front panel to the daughterboards ?
>
> Or it does not matter, and I will only need to ensure that I have no antennas
> connected to the front panel of the USRP?
>
> Thanks! Steve
> _______________________________________________
> 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/20170605/4b564236/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 5 Jun 2017 21:04:44 +0000
From: "Cho, Daniel J (332C)" <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Repeat Function error - tx_samples_from_file
program
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Derek,
Sorry about that. Here is the error message:
Error: AssertionError: _send_entries_in_use.at(which_stream) <= H2S_NUM_CMDS
in uhd::transport::zero_copy_if::sptr
e300_fifo_interface_impl::_make_xport(size_t, const
uhd::transport::zero_copy_xport_params&, bool)
at /home/dcho/maint/prefix/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:395
Thanks,
Daniel Cho
From: Derek Kozel [mailto:[email protected]]
Sent: Sunday, June 4, 2017 3:02 AM
To: Cho, Daniel J (332C) <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Repeat Function error - tx_samples_from_file program
Hello Daniel,
Your picture is just a black box to me. Can you please copy and paste the text
of the error into an email?
Thanks!
Derek
On Fri, Jun 2, 2017 at 10:40 PM, Cho, Daniel J (332C) via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello ?
I am trying to transmit samples from a file that was generated. There is no
issue with transmitting the file once but when I try and use the repeat
function to continuously loop the file in the tx_samples_from_file program, I
get the following error:
[cid:[email protected]]
Any help to allow continuous looping of transmitting a file will be greatly
appreciated! I am using all default configurations.
Thanks,
Daniel Cho
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170605/e5867670/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 5804 bytes
Desc: image002.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170605/e5867670/attachment-0001.jpg>
------------------------------
Message: 4
Date: Tue, 6 Jun 2017 13:25:51 +0800
From: "David Yu \( III \)" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] How to use one of USRP deicves connected to one
computer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Ettus Team:
If we connect two USRP devices to one computer with USB interface
simultaneously, how do I select specific one of these on my process?
David Yu
------------------------------
Message: 5
Date: Mon, 5 Jun 2017 22:41:05 -0700
From: Nate Temple <[email protected]>
To: "David Yu ( III )" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] How to use one of USRP deicves connected to
one computer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi David,
You can pass the serial number of each board to the Device Arguments / Address
string.
For example: ./rx_samples_to_file --args="serial=12345"
It's also possible to set this under the options in the UHD USRP Source/Sink
blocks if you're using GNU Radio.
You can find the serial number in the output of running the utilities
uhd_find_devices or uhd_usrp_probe with only one device connected at a time.
Additional information can be found here:
http://files.ettus.com/manual/page_identification.html
Regards,
Nate Temple
> On Jun 5, 2017, at 10:25 PM, David Yu ( III ) via USRP-users
> <[email protected]> wrote:
>
> Hi Ettus Team:
> If we connect two USRP devices to one computer with USB interface
> simultaneously, how do I select specific one of these on my process?
>
> David Yu
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Mon, 5 Jun 2017 22:55:23 -0700
From: Nate Temple <[email protected]>
To: john liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] no product ID
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi John,
Can you please send an email to [email protected] on this issue? We can work on
resolving this issue off of the list.
Regards,
Nate Temple
> On Jun 4, 2017, at 7:59 PM, john liu via USRP-users
> <[email protected]> wrote:
>
> Hi,all,
> Any suggestion is welcome.
> thank you.
>
> On Fri, Jun 2, 2017 at 10:12 AM, john liu <[email protected]> wrote:
> Hi,all,
> We have a usrp b210,and with command uhd_find_devices,information as below:
>
> uhd_find_devices
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.001.HEAD-0-g945fd653
>
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: b200
> name:
> serial:
> product: B2??
>
> Then we tried ./usrp_burn_mb_eeprom --read-all:
>
> /usr/local/lib/uhd/utils$ ./usrp_burn_mb_eeprom --read-alllinux; GNU C++
> version 4.8.4; Boost_105400; UHD_003.010.001.HEAD-0-g945fd653
>
> Creating USRP device from address:
> Error: RuntimeError: B200: Missing product ID on EEPROM.
>
> As the result showed,no product ID on EEPROM.
> How could we solved the problem?
>
> thank you.
>
> best regards
> John
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Tue, 6 Jun 2017 09:18:47 +0200
From: Julian Arnold <[email protected]>
To: Mareike Hetzel <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Trigger Signal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey Mareike,
> I was able to implement a trigger with the GPIO API.
Good to hear that!
I don't fully understand your problem though. Could you please share a
little bit more of your code?
Also, how are you calculating the mentioned timings?
> Additionally, I notice that my program with trigger included becomes
> unstable. Sometimes it runs without any problems and sometimes there
> are a lot of underflows by running the same code! Is this normal?
Do you have any wait statement in you while loop? Otherwise, it might be
that the loop is eating up too much CPU time (Just a wild guess).
Cheers,
On 06/02/2017 11:59 AM, Mareike Hetzel wrote:
> Hey!
>
> I was able to implement a trigger with the GPIO API. But I observed a
> strange behaviour:
> (case 1) If I use the trigger to start streaming, it takes
> approximately 700 to 800 microseconds until streaming actually starts.
> (case 2)If I use the trigger to change the amplitude or the frequency
> while it is already streaming, it takes approximately 250 milliseconds
> to change! And this duration did not significantly change with
> different implementations I tried.
>
> I thought that it might have to do with the increasing time the
> while-loop needs in case 1 compared to case 2. In case 1 it takes
> approximately 50 microseconds per iteration and in case 2 150
> microseconds. But this is only three times the runtime and does not
> explain the hugh difference in reaction time to me.
>
> Here is the relevant part of my code:
>
> int readback=0;
> while (true) {
> if (stop_signal_called) break;
> if (total_num_samps > 0 and num_acc_samps >= total_num_samps) break;
>
> readback = usrp->get_gpio_attr("FP0", "READBACK", 0);
> if (readback == 1) {
> i = 1;
> }
>
> if (i==1) {
> num_acc_samps += tx_stream->send(
> buffs, buff.size(), md
> );
> }
> else {
> num_acc_samps += tx_stream->send(
> /*case 1*/ "", 0, md
> /*case 2*/ buffers, buffer.size(), md
> );
> }
> }
>
> Do you have any idea what might cause this latency?
> Additionally, I notice that my program with trigger included becomes
> unstable. Sometimes it runs without any problems and sometimes there
> are a lot of underflows by running the same code! Is this normal?
>
> I would be grateful for any hint!
>
> Mareike
>
>
>
> Zitat von Julian Arnold <[email protected]>:
>
>> Hey Mareike,
>>
>> have you considered using the GPIO API for this task [1]?
>> I think using the GPIOs as a trigger source is more adequate than using
>> the PPS input as the PPS should be used for time synchronization between
>> multiple devices. (However, one could probably abuse it as a trigger)
>>
>> Cheers,
>>
>> [1] https://files.ettus.com/manual/page_gpio_api.html
>>
>> On 05/22/2017 04:50 PM, hetzel--- via USRP-users wrote:
>>> Hi!
>>>
>>> I want to build a trigger signal for my USRP X310 using UHD version
>>> 3.10.1.1. I want to send a pulse to the USRP and after receiving this
>>> pulse my device should start/stop streaming or something similar.
>>>
>>> I found that I can use the PPS TRIG IN port and send a trigger signal.
>>> Therefore I have to set the PPS to external:
>>> pps = "external" (Is this the right way to do so?)
>>> Afterwards the idea is to use timed commands and to start a long time
>>> from now. But with the next received PPS pulse, I set the clock to the
>>> same time. I started with a slightly changed tx_waveforms C++ file. I
>>> would use these additions to the code:
>>>
>>> usrp->set_time_now(0.0); //somewhere in the beginning
>>> usrp->set_command_time(uhd::time_spec_t(1e6));
>>>
>>> md.has_time_spec = true;
>>> md.time_spec = uhd::time_spec_t(1e6); // I am not sure if this is
>>> needed
>>>
>>> usrp->set_time_next_pps(uhd::time_spec_t(1e6)); // and this directly
>>> before I want to start streaming
>>>
>>> usrp->clear_command_time(); // in the end
>>>
>>>
>>>
>>> If I run this program my USRP seems to wait for a PPS signal but it
>>> does not react to those I send using a Function Generator. So how does
>>> a PPS input pulse has to look like? It says that it should have max 5V
>>> but how long should it be?
>>>
>>> So I have to stop the program. But if I want to re-run it there occurs
>>> a problem and I cannot run any other program until I power cycle the
>>> device. I get the following output to the console:
>>>
>>>
>>> Win32; Microsoft Visual C++ version 14.0; Boost_105900;
>>> UHD_003.010.001.001-rele
>>> ase
>>>
>>>
>>> Creating the usrp device with: ...
>>> -- X300 initialization sequence...
>>> -- Determining maximum frame size... 8000 bytes.
>>> -- Setup basic communication...
>>> -- Loading values from EEPROM...
>>> -- Setup RF frontend clocking...
>>> -- Radio 1x clock:200
>>> -- Creating WSA UDP transport for 192.168.40.2:49153
>>> -- Creating WSA UDP transport for 192.168.40.2:49153
>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.3MB/s)
>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.9MB/s)
>>> -- Creating WSA UDP transport for 192.168.40.2:49153
>>> Error: EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no
>>> response packet
>>> - AssertionError: bool(buff)
>>> in unsigned __int64 __cdecl ctrl_iface_impl::wait_for_ack(const bool)
>>> at
>>> C:\cygwin64\home\jenkins\worker\Package_Windows_x64_14\work\uhd\host\lib\rf
>>>
>>> noc\ctrl_iface.cpp:205
>>>
>>>
>>> Do you have any idea why this happens?
>>>
>>> I use Visual Studio 2015 on Windows 7.
>>>
>>> Best regards,
>>> Mareike Hetzel
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> --
>> Julian Arnold, M.Sc.
>>
>> Institute for Networked Systems
>> RWTH Aachen University
>>
>> Kackertstrasse 9
>> 52072 Aachen
>> Germany
>
>
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 8
Date: Tue, 6 Jun 2017 07:45:43 +0000
From: Snehasish Kar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP bin file to cfile conversion
Message-ID:
<pn1pr01mb0368a92fa799cabe7602b2d288...@pn1pr01mb0368.indprd01.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello
Can anyone please guide me in converting USRP bin file or streamed data
directly to cfile format in c++.
BR
Snehasish
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/8e1d5714/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 6 Jun 2017 10:35:26 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
While we don't have a specific "bin file" format, or "cfile" being any
specific format, you'd probably want to read:
https://stackoverflow.com/questions/36055644/how-to-edit-the-file-generated-by-file-sink-of-gnu-radio
Best regards,
Marcus
On 06.06.2017 09:45, Snehasish Kar via USRP-users wrote:
>
> Hello
>
>
> Can anyone please guide me in converting USRP bin file or streamed
> data directly to cfile format in c++.
>
>
> BR
>
> Snehasish
>
>
>
>
> _______________________________________________
> 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/20170606/0080fa72/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 6 Jun 2017 14:10:58 +0530
From: Nikita Airee <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] system requirements for 6X6 MIMO
Message-ID:
<CAOT=stknc3t_zgbzb7ob7td3aoym77qhexb9vvrzucog0-m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I would like to create a 6x6 MIMO setup with my x310s and n210s. The
transmitters have to be synchronized and hence have to be powered by the
same system but the receivers can driven separately by distinct hosts. To
use multiusrp configuration, driven by a single host, I need a system that
would be able to service these 6 x310s at the same time.
My current system is a Lenovo Thinkpad w530 with processor: Intel? Core?
i5-3320M CPU @ 2.60GHz ? 4. This one I believe would fall short. It is
anyway underpowered at 20M sampling rate.
So what type of a system should I have for smooth operation of my setup?
Any and all suggestions are welcome.
Bests,
Nikita Airee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/cb01a716/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 6 Jun 2017 09:08:14 +0000
From: Snehasish Kar <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Message-ID:
<pn1pr01mb0368eba97fcff1e816aca44388...@pn1pr01mb0368.indprd01.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
What is the format of the data streamed by USRP is it a 16 bit complex number?
________________________________
From: USRP-users <[email protected]> on behalf of Marcus
M?ller via USRP-users <[email protected]>
Sent: Tuesday, June 6, 2017 2:05:26 PM
To: [email protected]
Subject: Re: [USRP-users] USRP bin file to cfile conversion
While we don't have a specific "bin file" format, or "cfile" being any specific
format, you'd probably want to read:
https://stackoverflow.com/questions/36055644/how-to-edit-the-file-generated-by-file-sink-of-gnu-radio
Best regards,
Marcus
On 06.06.2017 09:45, Snehasish Kar via USRP-users wrote:
Hello
Can anyone please guide me in converting USRP bin file or streamed data
directly to cfile format in c++.
BR
Snehasish
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170606/fb02812c/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 6 Jun 2017 11:42:18 +0200
From: Marcus M?ller <[email protected]>
To: Snehasish Kar <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Depends on your USRP model and what you use as on-the-wire format.
But: you normally never directly deal with the data as it's streamed by
the USRP, but let UHD convert it to some data format that your CPU
"speaks" well.
Could you maybe describe your overall problem, rather than asking these
very isolated questions? This conversation sadly feels a lot like what
is described on http://xyproblem.info ; a good problem description
usually yields good answer :) !
Best regards,
Marcus
On 06.06.2017 11:08, Snehasish Kar wrote:
>
> What is the format of the data streamed by USRP is it a 16 bit complex
> number?
>
> ------------------------------------------------------------------------
> *From:* USRP-users <[email protected]> on behalf of
> Marcus M?ller via USRP-users <[email protected]>
> *Sent:* Tuesday, June 6, 2017 2:05:26 PM
> *To:* [email protected]
> *Subject:* Re: [USRP-users] USRP bin file to cfile conversion
>
>
> While we don't have a specific "bin file" format, or "cfile" being any
> specific format, you'd probably want to read:
>
>
> https://stackoverflow.com/questions/36055644/how-to-edit-the-file-generated-by-file-sink-of-gnu-radio
>
>
> Best regards,
>
> Marcus
>
>
> On 06.06.2017 09:45, Snehasish Kar via USRP-users wrote:
>>
>> Hello
>>
>>
>> Can anyone please guide me in converting USRP bin file or streamed
>> data directly to cfile format in c++.
>>
>>
>> BR
>>
>> Snehasish
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170606/e3b57e60/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 6 Jun 2017 11:45:50 +0200
From: Marcus M?ller <[email protected]>
To: Bob <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] The single USRP B210 achives to synchronize
with GPS and receive signal in 15:30(for example), how to implement?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Use the "set_start_time" method of the USRP source [1].
Best regards,
Marcus
[1]
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html#a810c34ba21faa4528c838b1c37a2b83b
On 02.06.2017 12:51, Bob wrote:
> I want to know that how to implement python "uhd_wbfm_receive2.py" in
> terminal. The result is below
> Key: rx_time Value: {1496146860 0.0577418}
> The first sample received time is 1496146860.0577418. And we want the
> time is 1496146860 or less than 1496146860.0000130 and more than
> 1496146860.
> If we want to implement it, how to do it?
>
> On 06/2/2017 17:23?Marcus M?ller<[email protected]>
> <mailto:[email protected]> wrote?
>
> Hi Bob,
> There's a few things wrong with that flow graph. Most important
> for the problem you're having: there almost certainly not a sound
> card in this world with a 44.4444... KHz sampling rate. I'd expect
> your sound system to select a different rate instead (watch out
> for console warnings!), but that rate won't be 1/9 of your USRP's
> 400 kHz sampling rate. So, you're basically incurring a sampling
> rate mismatch - which might either lead to your audio sink
> underflowing, or your USRP source overflowing.
> In either case, the time that your audio sink "counts" and the
> USRP time will not match.
>
> Best regards,
> Marcus
>
>
> On 2 June 2017 9:26:36 AM GMT+02:00, Bob via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hi,
> This is a flow graph about FM broadcast and we run it to
> generate uhd_wbfm_receive2.py. Then we increase
> "gps_time = self.uhd_usrp_source_0.get_mboard_sensor("gps_time")
> gps_seconds = gps_time.to_real()
> b = int(gps_seconds) + 1
> time.sleep(b-gps_seconds)
> gps_time1 = self.uhd_usrp_source_0.get_mboard_sensor("gps_time")
> gps_seconds = gps_time1.to_real()
> c = gps_seconds % 60
> time.sleep(60-c)
> gps_time = self.uhd_usrp_source_0.get_mboard_sensor("gps_time")
> gps_seconds = gps_time.to_real()
> next_pps_time = uhd.time_spec_t(gps_seconds+59.0)
> self.uhd_usrp_source_0.set_time_unknown_pps(next_pps_time)"
> in python code.
> And we use "python uhd_wbfm_receive2.py" in terminal. The
> result is below
> Key: rx_time Value: {1496146860 0.0577418}
> The first sample received time is 1496146860.0577418. And we
> want the time is 1496146860 or less than 1496146860.0000130
> and more than 1496146860.
> If we want to implement it, how to do it?
>
> Thank you very much for your answers. I am looking forward to
> your reply as soon as possible and as detailed as possible.
> Thanks!
>
> Bob
>
>
>
>
> <
> --
> Sent from my Android device with K-9 Mail. Please excuse my
> brevity./blockquote>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/362693ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 89557 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/362693ff/attachment-0001.png>
------------------------------
Message: 14
Date: Tue, 6 Jun 2017 09:52:59 +0000
From: Snehasish Kar <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Message-ID:
<pn1pr01mb03682d07e8d6365766541b1888...@pn1pr01mb0368.indprd01.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Sorry for that.
Actually I am trying to understand the data sent to the host by the UHD looks
like. I am trying to implement grgsm in a kind of multi-channel enviroment,
where the data from the USRP goes to DSP for baseband processing. So I am
trying to understand how the data looks like so that I can directly interface
it my code. As of now the recorded data I have is in the format :
3.2300e+02+8.0000e+01i
-1.26000e+02+2.9200e+02i
-3.0300e+02 - 1.1700e+02i
My code in DSP is able to work with these data format, so I need to get data
from UHD and convert it to the above format. I hope I am able to make you
understand the problem.
BR
Snehasish
________________________________
From: Marcus M?ller <[email protected]>
Sent: Tuesday, June 6, 2017 3:12:18 PM
To: Snehasish Kar; [email protected]
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Depends on your USRP model and what you use as on-the-wire format.
But: you normally never directly deal with the data as it's streamed by the
USRP, but let UHD convert it to some data format that your CPU "speaks" well.
Could you maybe describe your overall problem, rather than asking these very
isolated questions? This conversation sadly feels a lot like what is described
on http://xyproblem.info ; a good problem description usually yields good
answer :) !
Best regards,
Marcus
On 06.06.2017 11:08, Snehasish Kar wrote:
What is the format of the data streamed by USRP is it a 16 bit complex number?
________________________________
From: USRP-users
<[email protected]><mailto:[email protected]>
on behalf of Marcus M?ller via USRP-users
<[email protected]><mailto:[email protected]>
Sent: Tuesday, June 6, 2017 2:05:26 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] USRP bin file to cfile conversion
While we don't have a specific "bin file" format, or "cfile" being any specific
format, you'd probably want to read:
https://stackoverflow.com/questions/36055644/how-to-edit-the-file-generated-by-file-sink-of-gnu-radio
Best regards,
Marcus
On 06.06.2017 09:45, Snehasish Kar via USRP-users wrote:
Hello
Can anyone please guide me in converting USRP bin file or streamed data
directly to cfile format in c++.
BR
Snehasish
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170606/3198290c/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 6 Jun 2017 12:06:51 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310, rx_samples_to_file.cpp example, output
question
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Andrew,
> The values I have are basically anything from 0 to 65,536.
No, these should be /signed/ integers, and therefore $-2^{15}$ to
$2^{15} - 1$; you seem to be /misinterpreting/ the digital values as
/unsigned/ integers!
With $2^15$ being the fullest scale you'd get, you can calculate dBFS by
simply dividing all these by $2^15$, and taking the logarithm:
$x_\text{[dBFS]} = 20 \log_{10}\frac{\left\lvert x_\text{complex of
signed int16}\right\rvert}{2^{15}}$.
But: Gut feeling says you're not after the /decibel amplitude/, but
after /decibel //power/; in that case, use $10
\log_{10}\frac{|v|^2}{2^{30}}$ (digital power being square of digital
amplitude), then you'll notice that there's identity between these two:
Amplitude, simplified using logarithm arithmetic rules:
$$\begin{align} x_\text{[dBFS]} &= 20 \log_{10}\frac{\left\lvert
x_\text{complex of signed int16}\right\rvert}{2^{15}} \\&= 20\left(
\log_{10}\left\lvert x_\text{complex of signed int16}\right\rvert -
\log_{10} 2^{15}\right)\\&= 20\left( \log_{10}\left\lvert
x_\text{complex of signed int16}\right\rvert - 15\log_{10} 2\right)\\
&=20\log_{10}\left\lvert x_\text{complex of signed int16}\right\rvert -
300\log_{10} 2\end{align}$$
and power:
$$\begin{align} |x|^2_{\text{dBFS}} &= 10
\log_{10}\frac{|x_\text{complex of signed int16}|^2}{2^{30}}\\ &= 10
\cdot 2 \log_{10} |x_\text{complex of signed int16}| - 10\cdot 30
\log_{10}2 \\ &= 20 \log_{10}|x_\text{complex of signed int16}| - 300
\log_{10}2 \end{align}$$
Also not that only the second summand of $-300 \log_{10} 2$ is
influenced by the scaling of the data (i.e. whether you deal with 12
bit, 16 bit, 32 bit or 1234 bit numbers); since that is simply an
offset, and you'd need to calibrate these numbers using the real-world
known-power (or known-amplitude) source, anyway, your whole situation
can be summed up as:
$$x_\text{dBFS} = 10 \log_{10} x_\text{linear} + f$$,
with $f$ being the factor in dB between real-world and digital power,
which you calibrate yourself.
Hope that was helpful,
cheers,
Marcus
On 01.06.2017 20:37, Andrew Payne via USRP-users wrote:
> I compiled and can successfully run C++ file rx_samples_to_file, using
> most of the default parameters. So in reading the output, all of the
> numbers are 16-bit weighted I and Q values...how would I go about
> calculating the dB values? And plotting a frequency graph? The values
> I have are basically anything from 0 to 65,536. I didn't calibrate
> the unit to a known value or anything like that, and my signal
> generator was outputting a CW RF signal at a center frequency of
> 500MHz, with white Gaussian noise added in.
>
> Let me know what other information I can provide to help answer my
> question.
>
> Thanks,
> Andrew
>
>
> _______________________________________________
> 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/20170606/4178eba8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-22.png
Type: image/png
Size: 735 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-21.png
Type: image/png
Size: 782 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-20.png
Type: image/png
Size: 730 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-19.png
Type: image/png
Size: 2486 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-13.png
Type: image/png
Size: 1315 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-18.png
Type: image/png
Size: 7304 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-17.png
Type: image/png
Size: 6935 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-16.png
Type: image/png
Size: 1217 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-15.png
Type: image/png
Size: 1885 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-14.png
Type: image/png
Size: 611 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/4178eba8/attachment-0019.png>
------------------------------
Message: 16
Date: Tue, 6 Jun 2017 12:57:14 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Lihua,
"can it be done" doesn't really mean anything with an FPGA architecture
that is available in source code. You can change *everything* about the
X310's DSP chain, and thus, you can implement whatever fits onto the
FPGA (which is rather large).
I assume that you mean that you get 1.6384 million bits per second out
of the demodulator, and it takes in 114.688 million samples per second.
That means your demodulator has a 70 samples per bit ratio. That might
indicate that your demodulator takes in significantly more bandwidth
than your signal actually occupies ? or that you have very robust
channel coding.
Now, we haven't characterized or designed a mode where the ADC runs at a
multiple of 1.6384 MHz ? so, doing a complete analog re-verification
after configuring the clock generation to allow for that would be your
duty. That will cost months and will require very expensive measurement
equipment.
So, I'll go with a "no, this is not possible without a lot of work". I
don't know your level of Verilog or DSP experience ? so I can't asses
whether /you/ can do that!
The good news is that this is DSP, and thus, the processing clock
doesn't matter ? it just needs to be "fast enough"; add a clock
domain-crossing FIFO at both ends and run your DSP at any rate that is
/at least/ 114.688 MHz, and don't clock the processing chain if there's
nothing to be done. Just write your own rational or abitrary resampler
that goes between the USRP's frontend and your demodulation algorithm,
so that you get your required sampling rate. That's not simple, but
possible.
The usual approach here would be using RFNoC, implement said 20 MS/s ->
114.688 MS/s resampler as one RFNoC block, extensively test that with
offline data, and then just wrap your existing demodulator in a second
RFNoC block, and test the whole thing with recorded data, and then live
signals.
Your resampler could be a rational one, with a decimation of M = 3125
and an interpolation of L=1792. Yes, that is an ugly resampler with a
filter length of somewhere upwards of 100000 taps if you use a
fractional bandwidth of let's say 0.4 of the single-side output Nyquist
bandwidth (i.e. 0.5 would be a brick-wall filter).
But: the "steeper" that filter needs to be, the more taps you'll get.
So, that depends on what the spectral shape of your signal of interest
within those 114.688 MHz of Nyquist bandwidth actually are. Therefore,
rational resampling is only an option if the signal's bandwidth is
significantly less than 114.688 MHz ? if you need to use less than 0.4
of bandwidth////, then your filter specs get reduced very much, and
roughly throwing around a couple of numbers in my head, a x/3125
resampler with a fractional bandwidth somewhere around 0.2 should have
around 2^15 taps, which is many, but manageably many if you can allocate
a bit of block RAM for those, as through the magic of polyphase
resampling, you don't have to run the anti-aliasing resampling filter at
an extremely high rate, but at 200 MHz / 3125, which is 64 kHz.
Considering that each polyphase filter branch for the 0.2 fractional
bandwidth has 2^15/3125 taps, i.e. 11, that's seems possible, even if
you have to get the coefficients and filter state every time and store
the state back to block RAM afterwards, because you could use ten DSP
slices to do the multiplications in parallel. But it certainly would
require quite some engineering.
In other cases, you'd probably just aim for an arbitrary resampler.
Never wrote one for FPGA hardware myself ? but I guess for a ca
1.75-rate arbitrary resampler, you'd simply go for a bank of filters
with different fractional delays and construct your output by cycling
through these (PFB arbitrary resampler). The number of length of these
filters would depend on how robust your demodulator is with respect to
jitter. But there's multiple different approaches to arbitrary
resampling, and which one you choose depends on what your demodulator needs.
I also made the assumption that the demodulator internally has some
timing correction ? that could also be a resampler! In that case, you'd
often want to modify that to directly work with 200 MS/s rather than
having a separate resampler. But I don't know your demodulator.
Takeaway: You'll need a resampler for your demodulator to be useable on
an X3x0; which kind of resampler you use, and how you implement that,
will depend solely on your demodulator and the constraints you're given.
In other words: you'll have to apply your DSP experience and your
intimate knowledge of the demodulator here to pick the right way to
resample things. Wrapping of your existing demodulator should not be the
problem.
Best regards,
Marcus
On 01.06.2017 08:01, Lihua Ren via USRP-users wrote:
> hi ,all
> My purpose is to achieve it?The received data rate is 1.6384MHz, and
> the processing clock of the demodulation algorithm is 114.688Mhz.
> The demodulation code is all for the Verilog language . Can this
> be implemented at USRP x310? The most important thing is to ensure
> that the timing of the case, 114.688Mhz how to generate.
>
>
>
>
>
>
> _______________________________________________
> 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/20170606/97b74a15/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 6 Jun 2017 13:17:49 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear Snehasish,
Assuming your I,Q samples have been recorded as 16-bit integer ("sc16"
in Ettus terminology) and your UHD trace file is "samples.dat", you can
just use the following bash mini-script:
$ od samples.dat -td2 -Anone -w4 -v | (while read a b ; do S="" ; if [
$b -ge 0 ] ; then S="+" ; fi ; i=`echo "$a / 32767.0" | bc -l` ; q=`echo
"$b / 32767.0" | bc -l` ; echo "$i$S$q""i" ; done)
Example of output with a 5-samples file:
-.91219824823755607776+.78368480483413190099i
-.56184575945310831019-.44944608905301065095i
.89962462233344523453-.19760734885708182012i
-.71578112125003814813-.93090609454634235663i
.54835657826471755119+.23618274483474227118i
Best regards,
Claudio
On 06/06/2017 11:52 AM, Snehasish Kar via USRP-users wrote:
> Sorry for that.
>
>
> Actually I am trying to understand the data sent to the host by the UHD looks
> like. I am trying to implement grgsm in a kind of multi-channel enviroment,
> where the data from the USRP goes to DSP for baseband processing. So I am
> trying to understand how the data looks like so that I can directly interface
> it my code. As of now the recorded data I have is in the format :
>
>
> 3.2300e+02+8.0000e+01i
>
> -1.26000e+02+2.9200e+02i
>
> -3.0300e+02 - 1.1700e+02i
>
>
> My code in DSP is able to work with these data format, so I need to get data
> from UHD and convert it to the above format. I hope I am able to make you
> understand the problem.
>
>
> BR
>
> Snehasish
>
> ________________________________
> From: Marcus M?ller <[email protected]>
> Sent: Tuesday, June 6, 2017 3:12:18 PM
> To: Snehasish Kar; [email protected]
> Subject: Re: [USRP-users] USRP bin file to cfile conversion
>
>
> Depends on your USRP model and what you use as on-the-wire format.
>
> But: you normally never directly deal with the data as it's streamed by the
> USRP, but let UHD convert it to some data format that your CPU "speaks" well.
>
>
> Could you maybe describe your overall problem, rather than asking these very
> isolated questions? This conversation sadly feels a lot like what is
> described on http://xyproblem.info ; a good problem description usually
> yields good answer :) !
>
>
> Best regards,
>
> Marcus
>
> On 06.06.2017 11:08, Snehasish Kar wrote:
>
> What is the format of the data streamed by USRP is it a 16 bit complex number?
>
> ________________________________
> From: USRP-users
> <[email protected]><mailto:[email protected]>
> on behalf of Marcus M?ller via USRP-users
> <[email protected]><mailto:[email protected]>
> Sent: Tuesday, June 6, 2017 2:05:26 PM
> To: [email protected]<mailto:[email protected]>
> Subject: Re: [USRP-users] USRP bin file to cfile conversion
>
>
> While we don't have a specific "bin file" format, or "cfile" being any
> specific format, you'd probably want to read:
>
>
> https://stackoverflow.com/questions/36055644/how-to-edit-the-file-generated-by-file-sink-of-gnu-radio
>
>
> Best regards,
>
> Marcus
>
> On 06.06.2017 09:45, Snehasish Kar via USRP-users wrote:
>
> Hello
>
>
> Can anyone please guide me in converting USRP bin file or streamed data
> directly to cfile format in c++.
>
>
> BR
>
> Snehasish
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]<mailto:[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
>
------------------------------
Message: 18
Date: Tue, 6 Jun 2017 13:35:35 +0200
From: Marcus M?ller <[email protected]>
To: Snehasish Kar <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Sorry, still depends on the USRP model and selected On-the-wire format.
On 06.06.2017 11:52, Snehasish Kar wrote:
>
> Sorry for that.
>
>
> Actually I am trying to understand the data sent to the host by the
> UHD looks like. I am trying to implement grgsm in a kind of
> multi-channel enviroment, where the data from the USRP goes to DSP for
> baseband processing. So I am trying to understand how the data looks
> like so that I can directly interface it my code. As of now the
> recorded data I have is in the format :
>
>
> 3.2300e+02+8.0000e+01i
>
> -1.26000e+02+2.9200e+02i
>
> -3.0300e+02 - 1.1700e+02i
>
>
> My code in DSP is able to work with these data format, so I need to
> get data from UHD and convert it to the above format. I hope I am able
> to make you understand the problem.
>
>
> BR
>
> Snehasish
>
> ------------------------------------------------------------------------
> *From:* Marcus M?ller <[email protected]>
> *Sent:* Tuesday, June 6, 2017 3:12:18 PM
> *To:* Snehasish Kar; [email protected]
> *Subject:* Re: [USRP-users] USRP bin file to cfile conversion
>
>
> Depends on your USRP model and what you use as on-the-wire format.
>
> But: you normally never directly deal with the data as it's streamed
> by the USRP, but let UHD convert it to some data format that your CPU
> "speaks" well.
>
>
> Could you maybe describe your overall problem, rather than asking
> these very isolated questions? This conversation sadly feels a lot
> like what is described on http://xyproblem.info ; a good problem
> description usually yields good answer :) !
>
>
> Best regards,
>
> Marcus
>
>
> On 06.06.2017 11:08, Snehasish Kar wrote:
>>
>> What is the format of the data streamed by USRP is it a 16 bit
>> complex number?
>>
>> ------------------------------------------------------------------------
>> *From:* USRP-users <[email protected]> on behalf of
>> Marcus M?ller via USRP-users <[email protected]>
>> *Sent:* Tuesday, June 6, 2017 2:05:26 PM
>> *To:* [email protected]
>> *Subject:* Re: [USRP-users] USRP bin file to cfile conversion
>>
>>
>> While we don't have a specific "bin file" format, or "cfile" being
>> any specific format, you'd probably want to read:
>>
>>
>> https://stackoverflow.com/questions/36055644/how-to-edit-the-file-generated-by-file-sink-of-gnu-radio
>>
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 06.06.2017 09:45, Snehasish Kar via USRP-users wrote:
>>>
>>> Hello
>>>
>>>
>>> Can anyone please guide me in converting USRP bin file or streamed
>>> data directly to cfile format in c++.
>>>
>>>
>>> BR
>>>
>>> Snehasish
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170606/1e0f97d8/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 6 Jun 2017 11:45:40 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>, "Yim,
Kaun J." <[email protected]>, "Brassard, Sean M."
<[email protected]>
Subject: Re: [USRP-users] Error with multiple block output ports
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
Is there any update on our issue?
Thanks
Doug
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 29, 2017 2:16 AM
To: Barker, Douglas W.
Cc: [email protected]
Subject: Re: [USRP-users] Error with multiple block output ports
Try fixing these issues, especially the first one, and see if that helps:
- In uhd_rfnoc_split_stream.xml, the RX stream args defines 2 channels instead
of 3.
- In noc_block_split_stream.v, the ACTIVE_MASK on split_stream_fifo is set to
have only two active outputs.
On Fri, May 26, 2017 at 8:03 AM, Barker, Douglas W.
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I?ve attached the XML files that I was using.
Thanks!
Doug
From: Jonathon Pendlum
[mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, May 25, 2017 3:46 PM
To: Barker, Douglas W.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Error with multiple block output ports
Hi Doug,
Can you share your Noc Script XML file?
Jonathon
On Fri, May 19, 2017 at 2:17 PM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I?m starting a new thread for this problem. I get an error when trying to use
more than 2 output ports on a RFNoC block. I?ve designed a CE that has 9
output ports and when starting the gnuradio flowgraph it errors out. When I
reduce the ports to 2 it works. If I increase the ports to 3 it errors out.
I then made a simple modification to the ?noc_block_split_stream? block that is
provided to have three output ports (also modified the associated XML files).
It error out as well, in the same way. This test has
Radio->DDC-SplitStream->host. Below are the messages produced by gnuradio when
starting. Can the folks at Ettus please take a look as it appears to be a bug
in UHD. I?ve attached the modified ?noc_block_split_stream.v? file so you can
easily reproduce the error.
Thanks
Doug
Generating: '/home/dm/Documents/doug_rfnoc/top_block.py'
Executing: /usr/bin/python2 -u /home/dm/Documents/doug_rfnoc/top_block.py
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609; Boost_106300;
UHD_4.0.0.rfnoc-devel-316-g24b98579
[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mDetermining maximum frame size...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mSetup basic communication...
[32;1m[INFO] [X300] [39;0mLoading values from EEPROM...
[32;1m[INFO] [X300] [39;0mSetup RF frontend clocking...
[32;1m[INFO] [X300] [39;0mRadio 1x clock:200
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 0...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1305.2MB/s)
[32;1m[INFO] [RFNOC] [39;0m[DMA FIFO] Running BIST for FIFO 1...
[32;1m[INFO] [RFNOC] [39;0mpass (Throughput: 1302.5MB/s)
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[32;1m[INFO] [RFNOC RADIO] [39;0mRegister loopback test passed
[33;1m[WARNING] [RFNOC] [39;0m[0/SplitStream_0] defines 3 input buffer sizes,
but 1 input ports
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
[32;1m[INFO] [CORES] [39;0mPerforming timer loopback test...
[32;1m[INFO] [CORES] [39;0mTimer loopback test passed
DEBUG: output item size: 8
[33;1m[WARNING] [X300 RADIO] [39;0mset_rx_gain: could not apply gain for this
daughterboard.
INFO: Setting args on 0/DDC_0
(input_rate=200000000,output_rate=1000000,fullscale=1.0,freq=1000000.0)
DEBUG: output item size: 8
INFO: Setting args on 0/SplitStream_0 (gr_vlen=1)
DEBUG: output item size: 8
[32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/DDC_0
[32;1m[INFO] [RFNOC] [39;0mAssuming max packet size for 0/Radio_0
DEBUG: check_topology()
DEBUG: RFNoC blocks with streaming ports: 1
DEBUG: start(): ninputs == 0 noutputs == 3
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=0
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=1
DEBUG: creating rx streamer with:
gr_vlen=1,block_id=0/SplitStream_0,block_port0=0,block_port1=1,block_port=2
thread[thread-per-block[0]: <block uhd_rfnoc_SplitStream (3)>]: LookupError:
KeyError: [0/Radio_0] sr_write(): No such port: 2
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20170606/a055b443/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 6 Jun 2017 13:34:10 +0000
From: Snehasish Kar <[email protected]>
To: Claudio Cicconetti <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP bin file to cfile conversion
Message-ID:
<pn1pr01mb0368ccf235a010835a8b6c4f88...@pn1pr01mb0368.indprd01.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Thanks it will help me in understanding the problem.
Sent from my iPhone
> On 06-Jun-2017, at 4:47 PM, Claudio Cicconetti <[email protected]>
> wrote:
>
> Dear Snehasish,
> Assuming your I,Q samples have been recorded as 16-bit integer ("sc16"
> in Ettus terminology) and your UHD trace file is "samples.dat", you can
> just use the following bash mini-script:
>
> $ od samples.dat -td2 -Anone -w4 -v | (while read a b ; do S="" ; if [
> $b -ge 0 ] ; then S="+" ; fi ; i=`echo "$a / 32767.0" | bc -l` ; q=`echo
> "$b / 32767.0" | bc -l` ; echo "$i$S$q""i" ; done)
>
> Example of output with a 5-samples file:
>
> -.91219824823755607776+.78368480483413190099i
> -.56184575945310831019-.44944608905301065095i
> .89962462233344523453-.19760734885708182012i
> -.71578112125003814813-.93090609454634235663i
> .54835657826471755119+.23618274483474227118i
>
> Best regards,
> Claudio
>
>> On 06/06/2017 11:52 AM, Snehasish Kar via USRP-users wrote:
>> Sorry for that.
>>
>>
>> Actually I am trying to understand the data sent to the host by the UHD
>> looks like. I am trying to implement grgsm in a kind of multi-channel
>> enviroment, where the data from the USRP goes to DSP for baseband
>> processing. So I am trying to understand how the data looks like so that I
>> can directly interface it my code. As of now the recorded data I have is in
>> the format :
>>
>>
>> 3.2300e+02+8.0000e+01i
>>
>> -1.26000e+02+2.9200e+02i
>>
>> -3.0300e+02 - 1.1700e+02i
>>
>>
>> My code in DSP is able to work with these data format, so I need to get data
>> from UHD and convert it to the above format. I hope I am able to make you
>> understand the problem.
>>
>>
>> BR
>>
>> Snehasish
>>
>> ________________________________
>> From: Marcus M?ller <[email protected]>
>> Sent: Tuesday, June 6, 2017 3:12:18 PM
>> To: Snehasish Kar; [email protected]
>> Subject: Re: [USRP-users] USRP bin file to cfile conversion
>>
>>
>> Depends on your USRP model and what you use as on-the-wire format.
>>
>> But: you normally never directly deal with the data as it's streamed by the
>> USRP, but let UHD convert it to some data format that your CPU "speaks" well.
>>
>>
>> Could you maybe describe your overall problem, rather than asking these very
>> isolated questions? This conversation sadly feels a lot like what is
>> described on http://xyproblem.info ; a good problem description usually
>> yields good answer :) !
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 06.06.2017 11:08, Snehasish Kar wrote:
>>
>> What is the format of the data streamed by USRP is it a 16 bit complex
>> number?
>>
>> ________________________________
>> From: USRP-users
>> <[email protected]><mailto:[email protected]>
>> on behalf of Marcus M?ller via USRP-users
>> <[email protected]><mailto:[email protected]>
>> Sent: Tuesday, June 6, 2017 2:05:26 PM
>> To: [email protected]<mailto:[email protected]>
>> Subject: Re: [USRP-users] USRP bin file to cfile conversion
>>
>>
>> While we don't have a specific "bin file" format, or "cfile" being any
>> specific format, you'd probably want to read:
>>
>>
>> https://stackoverflow.com/questions/36055644/how-to-edit-the-file-generated-by-file-sink-of-gnu-radio
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 06.06.2017 09:45, Snehasish Kar via USRP-users wrote:
>>
>> Hello
>>
>>
>> Can anyone please guide me in converting USRP bin file or streamed data
>> directly to cfile format in c++.
>>
>>
>> BR
>>
>> Snehasish
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]<mailto:[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
>>
>
------------------------------
Message: 21
Date: Tue, 6 Jun 2017 15:47:50 +0200
From: Christophe ALEXANDRE <[email protected]>
To: Nick Foster <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GRC + RFNoC + Radio Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
that's better.
A) Radio Rx -> Radio Tx loopback
this flowgraph works properly, but when i quit, there is still an error :
[WARNING] [X300 RADIO] set_tx_gain: could not apply gain for this
daughterboard.
[WARNING] [X300 RADIO] set_rx_gain: could not apply gain for this
daughterboard.
[INFO] [RFNOC] Assuming max packet size for 0/Radio_0
Press Enter to quit:
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl
(CE_00_Port_30) packet parse error - EnvironmentError: IOError: Expected
SID: 02:30>00:00 Received SID: 02:40>00:00
and both leds (TX and RX2) stay on. But it's usable.
B) Radio Rx -> DDC -> DUC -> Radio Tx loopback
this flowgraph works also properly now,and there is the same error when
i quit and both leds stay on.
if the flowgraph runs for a few minutes and if i rerun it, it crashes
with the following error :
fpga@elec58:~/Documents$ ./loopback_radio_ddc_duc_radio.py
[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
UHD_4.0.0.rfnoc-devel-316-g24b98579
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
[INFO] [RFNOC] pass (Throughput: 1299.7MB/s)
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
[INFO] [RFNOC] pass (Throughput: 1299.1MB/s)
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl
(CE_01_Port_65) no response packet - AssertionError: bool(buff)
in uint64_t ctrl_iface_impl::wait_for_ack(bool)
at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl
(CE_01_Port_40) no response packet - AssertionError: bool(buff)
in uint64_t ctrl_iface_impl::wait_for_ack(bool)
at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
Traceback (most recent call last):
File "./loopback_radio_ddc_duc_radio.py", line 154, in <module>
main()
File "./loopback_radio_ddc_duc_radio.py", line 143, in main
tb = top_block_cls()
File "./loopback_radio_ddc_duc_radio.py", line 26, in __init__
self.device3 = variable_uhd_device3_0 =
ettus.device3(uhd.device_addr_t( ",".join(('type=x300',
"addr=192.168.10.2")) ))
File
"/home/fpga/rfnoc/lib/python2.7/dist-packages/ettus/ettus_swig.py", line
1291, in make
return _ettus_swig.device3_make(*args, **kwargs)
RuntimeError: EnvironmentError: IOError: [0/Radio_0] sr_read64() failed:
EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet
- AssertionError: bool(buff)
in uint64_t ctrl_iface_impl::wait_for_ack(bool)
at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197
i need to restart the X310 to make it work again. It's not very reliable.
regards.
Christophe ALEXANDRE
Le 02/06/2017 ? 19:11, Nick Foster a ?crit :
> Issue the start stream command *after* the connect() call.
>
> On Fri, Jun 2, 2017 at 8:58 AM Christophe ALEXANDRE
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> i suppose you mean this setting :
>
> self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
> self.device3,
> uhd.stream_args( # Tx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="", # empty
> ),
> uhd.stream_args( # Rx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="spp=600",
> ),
> 1, -1
> )
>
>
> i get the same behavior.
>
>
> regards.
>
>
> Christophe ALEXANDRE
>
>
> Le 02/06/2017 ? 16:27, Nick Foster a ?crit :
>>
>> Looks ok at first glance. Try setting "spp=600" in the block args
>> of the RX-side Radio block.
>>
>> --n
>>
>>
>> On Fri, Jun 2, 2017, 4:19 AM Christophe ALEXANDRE
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> here you are.
>>
>>
>> regards.
>>
>>
>> Christophe ALEXANDRE
>>
>>
>>
>> Le 01/06/2017 ? 22:33, Nick Foster a ?crit :
>>>
>>> Can you post your changes to UHD and gr-ettus?
>>>
>>>
>>> On Tue, May 30, 2017, 6:42 AM Christophe ALEXANDRE
>>> <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hi Nick,
>>>
>>> i have spent more time on your guide at :
>>>
>>> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>>>
>>> i have tried :
>>>
>>> step 1, approach 1, uhd solution
>>> step 2, with GnuRadio
>>> step 3, GRC + manual change in the flowgraph
>>>
>>> After all the modifications, i have run pybombs to recompile
>>> uhd and gr-ettus with the following command :
>>>
>>> pybombs -p rfnoc rebuild uhd gr-ettus
>>>
>>> i have made 2 tests (you will find attached 2 flowgraphs) :
>>>
>>> A) Radio Rx -> Radio Tx loopback
>>> B) Radio Rx -> DDC -> DUC -> Radio Tx loopback
>>>
>>> The A test runs, but with a strange behavior.
>>> 1) i power on the x310
>>> 2) i run loopback_radio_radio.py
>>> it starts with no errors, but doesn't work
>>> when i stop the flowgraph, an error messages occurs :
>>>
>>> fpga@elec58:~/Documents$ ./loopback_radio_radio.py
>>> [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_4.0.0.rfnoc-devel-316-g24b98579
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Determining maximum frame size...
>>> [INFO] [X300] Maximum frame size: 1472 bytes.
>>> [INFO] [X300] Setup basic communication...
>>> [INFO] [X300] Loading values from EEPROM...
>>> [INFO] [X300] Setup RF frontend clocking...
>>> [INFO] [X300] Radio 1x clock:200
>>> [INFO] [X300] Detecting internal GPSDO....
>>> [INFO] [GPS] No GPSDO found
>>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
>>> [INFO] [RFNOC] pass (Throughput: 1304.9MB/s)
>>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
>>> [INFO] [RFNOC] pass (Throughput: 1304.5MB/s)
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [WARNING] [RFNOC] [0/SplitStream_0] defines 2 input
>>> buffer sizes, but 1 input ports
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [WARNING] [X300 RADIO] set_tx_gain: could not apply gain
>>> for this daughterboard.
>>> [WARNING] [X300 RADIO] set_rx_gain: could not apply gain
>>> for this daughterboard.
>>> [INFO] [RFNOC] Assuming max packet size for 0/Radio_1
>>> Press Enter to quit:
>>> [ERROR] [UHD] Exception caught in safe-call.
>>> in virtual ctrl_iface_impl::~ctrl_iface_impl()
>>> at
>>> /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
>>> this->peek32(0); -> EnvironmentError: IOError: Block
>>> ctrl (CE_00_Port_30) packet parse error -
>>> EnvironmentError: IOError: Expected SID: 02:30>00:00
>>> Received SID: 02:50>00:00
>>>
>>> 3) i run loopback_radio_radio.py again
>>> it start with no errors, and it works. Rx signal is
>>> copied on Tx output, both leds are on
>>> when i stop the flowgraph, the same error messages
>>> occurs.
>>>
>>>
>>> Each time i want to run the flowgraph, i need to follow
>>> these steps.
>>>
>>>
>>> the B test doesn't work. When i run the flowgraph
>>> loopback_radio_ddc_duc_radio.py,
>>> it starts with no errors, but doesn't work. When i stop
>>> it, i get the same error than with the A test.
>>>
>>> Do you have any idea ?
>>>
>>> regards.
>>>
>>>
>>> Christophe ALEXANDRE
>>> Conservatoire National des Arts et M?tiers (CNAM)
>>> Laboratoire CEDRIC-LAETITIA
>>> EPN3 EEAM EASY
>>> Acc?s 11B niveau -1
>>> 292 rue Saint Martin
>>> 75141 PARIS CEDEX 03
>>> FRANCE
>>> email :[email protected]
>>> <mailto:[email protected]>
>>> tel. 0140272699
>>> mob. 0651087311
>>> fax. 0140272994
>>>
>>>
>>> Le 23/05/2017 ? 21:08, Nick Foster a ?crit :
>>>> Christophe,
>>>>
>>>> This might be a dumb question, but If you followed Step
>>>> 2 in the guide I wrote, did you also follow steps 1 & 3?
>>>>
>>>> --n
>>>>
>>>> On Tue, May 23, 2017 at 7:43 AM Jonathon Pendlum via
>>>> USRP-users <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Hi Christophe,
>>>>
>>>> Out of the box, all RFNoC flowgraphs require at
>>>> least one connection back to the host. This is a
>>>> limitation of UHD that we plan on fixing. That is
>>>> also why your second flowgraph worked. We are
>>>> having some discussions on making a block to allow
>>>> loopback, but I can't give you any dates when that
>>>> will be done. If you want to give it a try
>>>> yourself, one possibility would be to make a custom
>>>> rfnoc block with 2 inputs / 1 output. One of the
>>>> inputs would be from the rx radio, the other a
>>>> "dummy" connection from the host. The output would
>>>> connect to the tx radio. The block would also need
>>>> to adjust vita time or just strip it off the header.
>>>>
>>>>
>>>>
>>>> Jonathon
>>>>
>>>> On Tue, May 23, 2017 at 5:40 AM, Christophe
>>>> ALEXANDRE via USRP-users
>>>> <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> i'm using an X310 with 2 BasicRx and 2 BasicTx
>>>> and a fresh install of RFNoC.
>>>>
>>>> i'm trying to understand how i can use RFNoC
>>>> with gnuradio companion
>>>> and how i can mix gnuradio software blocks and
>>>> RFNoC blocks.
>>>>
>>>> With the help of Ettus documentations, i think
>>>> i understand the idea
>>>> except in one case, when i try to use both Rx
>>>> and Tx radio blocks (and i can't
>>>> see any examples in
>>>> ~rfnoc/src/gr-ettus/examples/rfnoc).
>>>>
>>>> My first test is a simple loopback :
>>>>
>>>>
>>>>
>>>>
>>>> when i run this flowgraph, there is no errors,
>>>> but nothing happens
>>>> and the rf0 and rf1 leds are off. There is no
>>>> signal copy
>>>> from rf1:Rx2 to rf0:Tx.
>>>>
>>>> if i understand clearly the problem explained
>>>> here :
>>>>
>>>>
>>>> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>>>>
>>>> this is a timestamp problem on the Tx side.
>>>> I've tried to follow the proposed solution
>>>> (Step 2: Enable Streamer), but without success.
>>>>
>>>> But if the flowgraph go back to the host doing
>>>> nothing (add a 0 constant), it works
>>>> (i suppose that gnuradio creates the necessary
>>>> timestamps for the Tx side) :
>>>>
>>>>
>>>>
>>>>
>>>> Leds are on and the input signal is going from
>>>> rf1:Rx2 to rf0:Tx.
>>>>
>>>>
>>>> Is there any better way to solve this problem ?
>>>>
>>>>
>>>> regards.
>>>>
>>>>
>>>> Christophe ALEXANDRE
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> <mailto:[email protected]>
>>>>
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> <mailto:[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/20170606/c8f3716a/attachment-0001.html>
------------------------------
Message: 22
Date: Tue, 06 Jun 2017 16:11:52 +0200
From: Mareike Hetzel <[email protected]>
To: Julian Arnold <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Trigger Signal
Message-ID:
<20170606161152.horde.fr2nlgb9zwjtxubbi41_...@webmail.rrzn.uni-hannover.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hi!
I generate the trigger signal with a function generator which I
connect to the GPIO API and an oscilloscope. The x310 TX/RX output is
connected to another channel of the oscilloscope and to a spectrum
analyzer.
On the oscilloscope I can see the time difference between the trigger
signal and the reaction of the SDR. It takes 700-800 microseconds to
start streaming and 250 milliseconds to change settings like the
amplitude. I don't know where this big difference comes from!
The GPIO setup is based on the example here:
https://files.ettus.com/manual/page_gpio_api.html
I used the tx_waveforms example code and from this starting point, I
mainly changed this:
... URRP setup...
#define MAN_GPIO_MASK (1 << 2)
#define ATR_MASKS (AMP_GPIO_MASK | MAN_GPIO_MASK)
// set up our values for ATR control: 1 for ATR, 0 for manual
#define ATR_CONTROL (AMP_GPIO_MASK & ~MAN_GPIO_MASK)
// set up the GPIO directions: 1 for output, 0 for input
#define GPIO_DDR (AMP_GPIO_MASK & ~MAN_GPIO_MASK)
// assume an existing USRP device handle, called "usrp_x300"
// now, let's do the basic ATR setup
usrp->set_gpio_attr("FP0", "CTRL", 0);
usrp->set_gpio_attr("FP0", "DDR", 0);
for (size_t n = 0; n < buff.size(); n++) {
buff[n] = 0.3;
buffer[n] = 0.15;
}
int i = 0;
int readback = 0;
while (true) {
if (stop_signal_called) break;
if (total_num_samps > 0 and num_acc_samps >= total_num_samps)
break;
readback = usrp->get_gpio_attr("FP0", "READBACK", 0);
if (readback == 1) {
i = 1;
}
if (i==0) {
num_acc_samps += tx_stream->send(
buffs, buff.size(), md
);
}
else {
num_acc_samps += tx_stream->send(
/*case 1*/ "", 0, md
/*case 2*/ buffers, buffer.size(), md
);
}
}
No, by now I don't have a wait statement in there, because it is the
same loop in which I send the buffers. Wouldn't this only cause
additional underflows? (At least in this case)
I connected pin 2 to the function generator and I thought that
"#define MAN_GPIO_MASK (1 << 2)" sets pin 2 to manual control. But I
noticed that Pin 2 still works as trigger input if I define "#define
MAN_GPIO_MASK (1 << 3)" or any other pin number. I wanted to trigger
pin 2 and then use pin 3 as an output which is changed when pin 2 is
triggered. (To measure this time difference independent of streaming)
But in my case only pin 2 is working as an trigger input. I thought
every data-pin can be used the same way?
Thank you for your help!
Mareike
Zitat von Julian Arnold <[email protected]>:
> Hey Mareike,
>
>> I was able to implement a trigger with the GPIO API.
> Good to hear that!
> I don't fully understand your problem though. Could you please share a
> little bit more of your code?
> Also, how are you calculating the mentioned timings?
>
>> Additionally, I notice that my program with trigger included becomes
>> unstable. Sometimes it runs without any problems and sometimes there
>> are a lot of underflows by running the same code! Is this normal?
> Do you have any wait statement in you while loop? Otherwise, it might be
> that the loop is eating up too much CPU time (Just a wild guess).
>
> Cheers,
>
> On 06/02/2017 11:59 AM, Mareike Hetzel wrote:
>> Hey!
>>
>> I was able to implement a trigger with the GPIO API. But I observed a
>> strange behaviour:
>> (case 1) If I use the trigger to start streaming, it takes
>> approximately 700 to 800 microseconds until streaming actually starts.
>> (case 2)If I use the trigger to change the amplitude or the frequency
>> while it is already streaming, it takes approximately 250 milliseconds
>> to change! And this duration did not significantly change with
>> different implementations I tried.
>>
>> I thought that it might have to do with the increasing time the
>> while-loop needs in case 1 compared to case 2. In case 1 it takes
>> approximately 50 microseconds per iteration and in case 2 150
>> microseconds. But this is only three times the runtime and does not
>> explain the hugh difference in reaction time to me.
>>
>> Here is the relevant part of my code:
>>
>> int readback=0;
>> while (true) {
>> if (stop_signal_called) break;
>> if (total_num_samps > 0 and num_acc_samps >= total_num_samps) break;
>>
>> readback = usrp->get_gpio_attr("FP0", "READBACK", 0);
>> if (readback == 1) {
>> i = 1;
>> }
>>
>> if (i==1) {
>> num_acc_samps += tx_stream->send(
>> buffs, buff.size(), md
>> );
>> }
>> else {
>> num_acc_samps += tx_stream->send(
>> /*case 1*/ "", 0, md
>> /*case 2*/ buffers, buffer.size(), md
>> );
>> }
>> }
>>
>> Do you have any idea what might cause this latency?
>> Additionally, I notice that my program with trigger included becomes
>> unstable. Sometimes it runs without any problems and sometimes there
>> are a lot of underflows by running the same code! Is this normal?
>>
>> I would be grateful for any hint!
>>
>> Mareike
>>
>>
>>
>> Zitat von Julian Arnold <[email protected]>:
>>
>>> Hey Mareike,
>>>
>>> have you considered using the GPIO API for this task [1]?
>>> I think using the GPIOs as a trigger source is more adequate than using
>>> the PPS input as the PPS should be used for time synchronization between
>>> multiple devices. (However, one could probably abuse it as a trigger)
>>>
>>> Cheers,
>>>
>>> [1] https://files.ettus.com/manual/page_gpio_api.html
>>>
>>> On 05/22/2017 04:50 PM, hetzel--- via USRP-users wrote:
>>>> Hi!
>>>>
>>>> I want to build a trigger signal for my USRP X310 using UHD version
>>>> 3.10.1.1. I want to send a pulse to the USRP and after receiving this
>>>> pulse my device should start/stop streaming or something similar.
>>>>
>>>> I found that I can use the PPS TRIG IN port and send a trigger signal.
>>>> Therefore I have to set the PPS to external:
>>>> pps = "external" (Is this the right way to do so?)
>>>> Afterwards the idea is to use timed commands and to start a long time
>>>> from now. But with the next received PPS pulse, I set the clock to the
>>>> same time. I started with a slightly changed tx_waveforms C++ file. I
>>>> would use these additions to the code:
>>>>
>>>> usrp->set_time_now(0.0); //somewhere in the beginning
>>>> usrp->set_command_time(uhd::time_spec_t(1e6));
>>>>
>>>> md.has_time_spec = true;
>>>> md.time_spec = uhd::time_spec_t(1e6); // I am not sure if this is
>>>> needed
>>>>
>>>> usrp->set_time_next_pps(uhd::time_spec_t(1e6)); // and this directly
>>>> before I want to start streaming
>>>>
>>>> usrp->clear_command_time(); // in the end
>>>>
>>>>
>>>>
>>>> If I run this program my USRP seems to wait for a PPS signal but it
>>>> does not react to those I send using a Function Generator. So how does
>>>> a PPS input pulse has to look like? It says that it should have max 5V
>>>> but how long should it be?
>>>>
>>>> So I have to stop the program. But if I want to re-run it there occurs
>>>> a problem and I cannot run any other program until I power cycle the
>>>> device. I get the following output to the console:
>>>>
>>>>
>>>> Win32; Microsoft Visual C++ version 14.0; Boost_105900;
>>>> UHD_003.010.001.001-rele
>>>> ase
>>>>
>>>>
>>>> Creating the usrp device with: ...
>>>> -- X300 initialization sequence...
>>>> -- Determining maximum frame size... 8000 bytes.
>>>> -- Setup basic communication...
>>>> -- Loading values from EEPROM...
>>>> -- Setup RF frontend clocking...
>>>> -- Radio 1x clock:200
>>>> -- Creating WSA UDP transport for 192.168.40.2:49153
>>>> -- Creating WSA UDP transport for 192.168.40.2:49153
>>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.3MB/s)
>>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.9MB/s)
>>>> -- Creating WSA UDP transport for 192.168.40.2:49153
>>>> Error: EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no
>>>> response packet
>>>> - AssertionError: bool(buff)
>>>> in unsigned __int64 __cdecl ctrl_iface_impl::wait_for_ack(const bool)
>>>> at
>>>> C:\cygwin64\home\jenkins\worker\Package_Windows_x64_14\work\uhd\host\lib\rf
>>>>
>>>> noc\ctrl_iface.cpp:205
>>>>
>>>>
>>>> Do you have any idea why this happens?
>>>>
>>>> I use Visual Studio 2015 on Windows 7.
>>>>
>>>> Best regards,
>>>> Mareike Hetzel
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> --
>>> Julian Arnold, M.Sc.
>>>
>>> Institute for Networked Systems
>>> RWTH Aachen University
>>>
>>> Kackertstrasse 9
>>> 52072 Aachen
>>> Germany
>>
>>
>
> --
> Julian Arnold, M.Sc.
>
> Institute for Networked Systems
> RWTH Aachen University
>
> Kackertstrasse 9
> 52072 Aachen
> Germany
------------------------------
Message: 23
Date: Tue, 6 Jun 2017 11:57:35 -0400
From: Santos Campos <[email protected]>
To: [email protected]
Subject: [USRP-users] Using the gpio in an OOT
Message-ID:
<CABqE4yN3=gZ01R=gfypp-3g8-vataslg52drc-yeu-q-v63...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello, all!
I took a crack at this a while ago and decided to try again.
So, I'm having trouble getting the uhd gpio functions in my OOT module to
play nice with my flow graph. Am I making this shared pointer correctly?
#include <gnuradio/uhd/usrp_block.h>`
.
.
.
boost::shared_ptr<gr::uhd::usrp_block> usrp;
It compiles fine, but when I try to access the set_gpio_attr function it
crashes the flow graph.
Any push in the right direction would be much appreciated!
Also, I'm trying to use a usrp sink in the same graph. Could I be having
some conflict with that?
I'm trying to use the same device
--
/*
Santos Campos
University of Michigan '17 | B.S.E. Computer Engineering
santosecampos.com
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170606/50d5b883/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 6
*****************************************
