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. Re: Example on how to use UHD_STREAM_MODE_NUM_SAMPS_AND_MORE
mode (Felipe Augusto Pereira de Figueiredo)
2. Re: Typecasting CPU timestamp as uhd timestamp (Sumit Kumar)
3. Re: Typecasting CPU timestamp as uhd timestamp (Marcus M?ller)
4. X310 GPIO (Mareike Hetzel)
5. Re: Trigger Signal (Julian Arnold)
6. Re: Trigger Signal (Mareike Hetzel)
7. Re: Trigger Signal (Julian Arnold)
8. Re: Trigger Signal (Mareike Hetzel)
----------------------------------------------------------------------
Message: 1
Date: Wed, 7 Jun 2017 18:15:59 +0200
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: "[email protected]" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] Example on how to use
UHD_STREAM_MODE_NUM_SAMPS_AND_MORE mode
Message-ID:
<ca+abmwlp48+1zyk8n1zt3w3pgtcro0asxsft0j676c8tgct...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
It is because I need to be able to start/stop reception and with the
continuous mode I open the stream and it keeps open for the whole duration
of the application. I tried to open/close the stream but I was told by you
guys that there is a bug that appears after 256 open/stop operations.
If I'm able to use the UHD_STREAM_MODE_NUM_SAMPS_AND_MORE mode it will help
me avoid auto reception of packets I've just transmitted as I will be able
to receive samples only when I read them.
I hope I have answered your question.
Could you help me with that mode, please? I mean, provide me with a sample
code?
Kind Regards,
Felipe Augusto
On Tue, Jun 6, 2017 at 6:53 PM, Felipe Augusto Pereira de Figueiredo <
[email protected]> wrote:
> Dear Folks,
>
> I'm writing an UHD application to receive and demodulate some signals
> and I'd like to use the UHD_STREAM_MODE_NUM_SAMPS_AND_MORE mode,
> however, I couldn't find any example on how to use this mode to read
> samples.
>
> I've googled "UHD_STREAM_MODE_NUM_SAMPS_AND_MORE" and only the headers
> where it is defined on the UHD project came back.
>
> Could someone give me an example on how to use that mode, please?
>
> Kind Regards,
>
> Felipe Augusto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170607/070b6820/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 7 Jun 2017 21:58:14 +0200
From: Sumit Kumar <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Typecasting CPU timestamp as uhd timestamp
Message-ID:
<caoextcrnwlt6dvo_cjm9u6oxuawyzlmhgtdcrsugjh4wke1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Marcus. Its "clearer" to me now :)
Here is my new understanding (pl correct if wrong)
I set my master clock rate as 20 MHz. => 1 tick every 1/(20e6) = 0.05 micro
secs. So 0.05 microsecs is the time difference between two consecutive
ticks.
My receiver thread reads data in a block of 2048 at a time. For every
block, I log the time stamp of the first sample. And I verified thru VCD
dumps that time stamp difference between two consecutive blocks is 2048
ticks, which is correct according to(my understanding).
Now I have to schedule my transmit 25 microsecs after the reception of the
block(which has time stamp say X ticks).
So according to my maths I should schedule my transmit at X ticks +
(25/0.05) ticks i.e. (X + 500) ticks
Is this right ?
Regards
Sumti
On Tue, May 30, 2017 at 10:32 AM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi Sumit!
> On 30.05.2017 06:17, Sumit Kumar via USRP-users wrote:
>
> Hi,
>
> I am putting this question based on my understanding (please correct if
> wrong)
>
> "uhd gives timestamp of the received samples. These timestamps are tagged
> to the received samples in the FPGA itself and have nothing to do with CPU
> time. "
>
> Correct!
>
> If this is correct, then my main question is :
>
> How to typecast/use the CPU timestamps as uhd timestamps.
>
> In the spirit of keeping these two independent clocks mentally separated:
> Not at all.
>
> So, technically, the answer is: The USRPs internally have a *tick counter*,
> which increases once every master clock rate cycle. To the software user,
> however, UHD uses uhd::time_spec_t, which allows you to define time in full
> seconds (integer) + fractional seconds (float), which gets converted to a
> tick number in UHD.
>
>
> For example, I want my wifi transceiver to send ACK , "X" time after the
> initial sync has been achieved. I know the CPU timestamp when initial sync
> is achieved(say "Y"). Now how shall I tell the transmitter to schedule
> transmission at Y + X
>
> Don't do that, it won't work; mixing CPU and device clock is *pretty much
> always* a bad idea. Always refer everything to the device time! If you know
> which sample corresponds to the initial sync, then you know the USRP time
> of the initial sync. You then just add X to that USRP time, and use it as
> the transmit time.
>
> Best regards,
> Marcus
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170607/4545c004/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 8 Jun 2017 09:34:24 +0200
From: Marcus M?ller <[email protected]>
To: Sumit Kumar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Typecasting CPU timestamp as uhd timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Sounds right!
Note that there's inherent, but constant (deterministic!) delay in DSP
and analog chain, so you'll have to experimentally adjust that delay a bit.
Best regards,
Marcus
On 07.06.2017 21:58, Sumit Kumar wrote:
> Thanks Marcus. Its "clearer" to me now :)
>
> Here is my new understanding (pl correct if wrong)
>
> I set my master clock rate as 20 MHz. => 1 tick every 1/(20e6) = 0.05
> micro secs. So 0.05 microsecs is the time difference between two
> consecutive ticks.
>
> My receiver thread reads data in a block of 2048 at a time. For every
> block, I log the time stamp of the first sample. And I verified thru
> VCD dumps that time stamp difference between two consecutive blocks is
> 2048 ticks, which is correct according to(my understanding).
>
> Now I have to schedule my transmit 25 microsecs after the reception of
> the block(which has time stamp say X ticks).
>
> So according to my maths I should schedule my transmit at X ticks +
> (25/0.05) ticks i.e. (X + 500) ticks
>
> Is this right ?
>
> Regards
>
> Sumti
>
> On Tue, May 30, 2017 at 10:32 AM, Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Sumit!
>
> On 30.05.2017 06:17, Sumit Kumar via USRP-users wrote:
>> Hi,
>>
>> I am putting this question based on my understanding (please
>> correct if wrong)
>>
>> "uhd gives timestamp of the received samples. These timestamps
>> are tagged to the received samples in the FPGA itself and have
>> nothing to do with CPU time. "
>>
> Correct!
>> If this is correct, then my main question is :
>>
>> How to typecast/use the CPU timestamps as uhd timestamps.
> In the spirit of keeping these two independent clocks mentally
> separated:
> Not at all.
>
> So, technically, the answer is: The USRPs internally have a /tick
> counter/, which increases once every master clock rate cycle. To
> the software user, however, UHD uses uhd::time_spec_t, which
> allows you to define time in full seconds (integer) + fractional
> seconds (float), which gets converted to a tick number in UHD.
>>
>> For example, I want my wifi transceiver to send ACK , "X" time
>> after the initial sync has been achieved. I know the CPU
>> timestamp when initial sync is achieved(say "Y"). Now how shall I
>> tell the transmitter to schedule transmission at Y + X
> Don't do that, it won't work; mixing CPU and device clock is
> *pretty much always* a bad idea. Always refer everything to the
> device time! If you know which sample corresponds to the initial
> sync, then you know the USRP time of the initial sync. You then
> just add X to that USRP time, and use it as the transmit time.
>
> Best regards,
> Marcus
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
>
>
> --
> --
> Sumit kumar
> Doctoral Student, UPMC
> Eurecom, BIOT
> France
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170608/19e82cd7/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 08 Jun 2017 10:23:50 +0200
From: Mareike Hetzel <[email protected]>
To: [email protected]
Subject: [USRP-users] X310 GPIO
Message-ID:
<20170608102350.horde.fwm4pmght_refrv0f3ul...@webmail.rrzn.uni-hannover.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hi everyone!
I have built a trigger for my X310 using the GPIO API. But the SDR
reacts very slowly to the signal. If I send a trigger it takes 250
milliseconds to change e.g. the amplitude of the tx stream. I measured
this with an oscilloscope which I connected to the SDR and to the
function generator which generates the trigger.
My first try was to leave out the tx stream and trigger another GPIO
pin. I send a trigger on pin 2 which sets another pin to a higher
voltage. But this did not work. I found out that my method to trigger
seems to work only with pin 2. I was not able to use another pin as a
trigger input with the same code that worked for pin 2!
I used the example here: https://files.ettus.com/manual/page_gpio_api.html
But pin 4 is not set to 1 afterwards.
So I have some questions:
1) Has every data pin the same purpose? Or are there some that are
supposed to be used in GPIO mode and some in ATR mode?
2) Is it possible to control more than one pin manually at the same time?
3) After I set this (out of
https://files.ettus.com/manual/page_gpio_api.html):
// let's manually set GPIO4 high
usrp->set_gpio_attr("FP0", "OUT", 1, MAN_GPIO_MASK);
the output of
std::cout << usrp->get_gpio_attr("FP0", "OUT");
should be 1, shouldn't it? But it is 0.
4) Which pin I use is set by "#define MAN_GPIO_MASK (1 << 4)" for
pin 4 and "(1 << 2)" for pin 2?
Because my trigger for pin 2 works also with "(1 << 4)" and other numbers.
5) Is there a way to make my trigger faster? Or is 250 milliseconds normal?
I put my code down below.
Best regards,
Mareike
My code is a version of tx_waveforms that I slightly changed:
#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(
buffers, buffer.size(), md
);
}
}
------------------------------
Message: 5
Date: Thu, 8 Jun 2017 10:40:33 +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
Hi Mareike,
so one thing I noticed is that you do not specify any mask in your calls
to set_gpio_attr. Therefore, all your GPIOs on bank FP0 will be changed.
Furthermore, you do not check the contents of you read-back variable.
Therefore, your trigger works on all GPIOs.
I still don't get from your code what you mean by changing the amplitude
and how you measure the timing in that case.
Cheers,
On 06/06/2017 04:11 PM, Mareike Hetzel wrote:
> 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
>
>
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 6
Date: Thu, 08 Jun 2017 11:13:34 +0200
From: Mareike Hetzel <[email protected]>
To: Julian Arnold <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Trigger Signal
Message-ID:
<20170608111334.horde.knse_46ixnun_jfrcmg7...@webmail.rrzn.uni-hannover.de>
Content-Type: text/plain; charset="utf-8"; Format="flowed";
DelSp="Yes"
Do you mean something like this?
boost::uint32_t mask = 1 << 2;
usrp->set_gpio_attr("FP0", "CTRL", mask, 0);
usrp->set_gpio_attr("FP0", "DDR", mask, 0);
What do you mean with checking the contents of my read-back variable?
I attached a photo of the oscilloscope. The yellow line shows the
trigger. There is small peak which shows the trigger I generated with
the function generator. The blue shows the tx stream. At first, it has
a high amplitude/power and 250 ms after the trigger it is set to a
smaller amplitude/power.
Thank you for your time!
Mareike
Zitat von Julian Arnold <[email protected]>:
> Hi Mareike,
>
> so one thing I noticed is that you do not specify any mask in your calls
> to set_gpio_attr. Therefore, all your GPIOs on bank FP0 will be changed.
> Furthermore, you do not check the contents of you read-back variable.
> Therefore, your trigger works on all GPIOs.
>
> I still don't get from your code what you mean by changing the amplitude
> and how you measure the timing in that case.
>
> Cheers,
>
> On 06/06/2017 04:11 PM, Mareike Hetzel wrote:
>> 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
>>
>>
>
> --
> Julian Arnold, M.Sc.
>
> Institute for Networked Systems
> RWTH Aachen University
>
> Kackertstrasse 9
> 52072 Aachen
> Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Oscilloscope.jpg
Type: image/jpeg
Size: 280630 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170608/51d115a0/attachment-0001.jpg>
------------------------------
Message: 7
Date: Thu, 8 Jun 2017 11:40: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,
one more question:
what is your sample rate and what is the size of your buffers?
Cheers,
On 06/08/2017 11:13 AM, Mareike Hetzel wrote:
> Do you mean something like this?
>
> boost::uint32_t mask = 1 << 2;
> usrp->set_gpio_attr("FP0", "CTRL", mask, 0);
> usrp->set_gpio_attr("FP0", "DDR", mask, 0);
>
> What do you mean with checking the contents of my read-back variable?
>
> I attached a photo of the oscilloscope. The yellow line shows the
> trigger. There is small peak which shows the trigger I generated with
> the function generator. The blue shows the tx stream. At first, it has
> a high amplitude/power and 250 ms after the trigger it is set to a
> smaller amplitude/power.
>
>
> Thank you for your time!
> Mareike
>
>
>
> Zitat von Julian Arnold <[email protected]>:
>
>> Hi Mareike,
>>
>> so one thing I noticed is that you do not specify any mask in your calls
>> to set_gpio_attr. Therefore, all your GPIOs on bank FP0 will be changed.
>> Furthermore, you do not check the contents of you read-back variable.
>> Therefore, your trigger works on all GPIOs.
>>
>> I still don't get from your code what you mean by changing the amplitude
>> and how you measure the timing in that case.
>>
>> Cheers,
>>
>> On 06/06/2017 04:11 PM, Mareike Hetzel wrote:
>>> 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
>>>
>>>
>>
>> --
>> 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: Thu, 08 Jun 2017 11:49:20 +0200
From: Mareike Hetzel <[email protected]>
To: Julian Arnold <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Trigger Signal
Message-ID:
<20170608114920.horde.xuwac3oo7aq3goj5ka-a...@webmail.rrzn.uni-hannover.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
I use a sample rate of 33.333333Mhz. With 20Mhz it took 420 ms! I did
not notice that before!
The size of my buffers is defined by
if (spb == 0) spb = tx_stream->get_max_num_samps() * 10;
what leads to spb=4960.
Zitat von Julian Arnold <[email protected]>:
> Hey,
>
> one more question:
> what is your sample rate and what is the size of your buffers?
>
> Cheers,
>
> On 06/08/2017 11:13 AM, Mareike Hetzel wrote:
>> Do you mean something like this?
>>
>> boost::uint32_t mask = 1 << 2;
>> usrp->set_gpio_attr("FP0", "CTRL", mask, 0);
>> usrp->set_gpio_attr("FP0", "DDR", mask, 0);
>>
>> What do you mean with checking the contents of my read-back variable?
>>
>> I attached a photo of the oscilloscope. The yellow line shows the
>> trigger. There is small peak which shows the trigger I generated with
>> the function generator. The blue shows the tx stream. At first, it has
>> a high amplitude/power and 250 ms after the trigger it is set to a
>> smaller amplitude/power.
>>
>>
>> Thank you for your time!
>> Mareike
>>
>>
>>
>> Zitat von Julian Arnold <[email protected]>:
>>
>>> Hi Mareike,
>>>
>>> so one thing I noticed is that you do not specify any mask in your calls
>>> to set_gpio_attr. Therefore, all your GPIOs on bank FP0 will be changed.
>>> Furthermore, you do not check the contents of you read-back variable.
>>> Therefore, your trigger works on all GPIOs.
>>>
>>> I still don't get from your code what you mean by changing the amplitude
>>> and how you measure the timing in that case.
>>>
>>> Cheers,
>>>
>>> On 06/06/2017 04:11 PM, Mareike Hetzel wrote:
>>>> 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
>>>>
>>>>
>>>
>>> --
>>> 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
------------------------------
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 8
*****************************************
