Martin,
thank you very much for your help!
I would like to do this! Could you please give me some further
information what exactly I need to do? As I have never done anything
with FPGAs, I don't know where to start. I have to modify the FPGA
image? Will there be only the GPIO definition or a lot of my other
code as well?
Is there an example I could use to understand how this works (even
though it won't do what I want)?
Cheers,
Mareike
Zitat von Martin Braun via USRP-users <[email protected]>:
Mareike,
the reason for the delays is that your software is polling the GPIO, and
that goes over network. You're adding in network latency, and SW
scheduling latency.
Also, with the DDC, once a packet leaves the computer, it needs to go
through various stages before it reaches the ADC (after the ADC, there's
still a tiny delay before your volts hit the antenna, but that's much
much smaller than what you're looking at).
If you want the signal to start Tx'ing within nanoseconds of your
trigger signal, you need to implement all of this in the FPGA. This is
an interesting use case, but unfortunately not one for which we have
examples. The quickest way to hack this up that I can think of is to
wire the GPIO lines to the time stamp comparison logic. If you're not
familiar with FPGA development, this is not a trivial task, though.
Cheers,
Martin
On 06/08/2017 02:49 AM, Mareike Hetzel via USRP-users wrote:
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
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
