On 2021-09-10 2:35 p.m., Mike wrote:
Hello,
We are using an external GPSDO to provide 10 MHz and PPS into a B200.
Our application collects a fixed number of samples at 50 MSPS using a
stream command (UHD_STREAM_MODE_NUM_SAMPS_AND_DONE and the timespec
for the next PPS). In this way we rely
Hello,
We are using an external GPSDO to provide 10 MHz and PPS into a B200.
Our application collects a fixed number of samples at 50 MSPS using a
stream command (UHD_STREAM_MODE_NUM_SAMPS_AND_DONE and the timespec for
the next PPS). In this way we rely on the USRP to provide samples that
begin
On 2021-09-10 1:37 p.m., Dobler, Anton wrote:
Thank you for that explanation! Does the transaction regarding the
GPIO states use the SFP+ ports or the management connection?
I will go for the raw c++ application and come back to the list ASAP.
Thank you all for your answers!
That's a good
Thank you for that explanation! Does the transaction regarding the GPIO states
use the SFP+ ports or the management connection?
I will go for the raw c++ application and come back to the list ASAP.
Thank you all for your answers!
?
Von: Marcus D. Leech
Gesen
On 2021-09-10 12:08 p.m., Dobler, Anton wrote:
Is there any alternative to the standard GPIO UHD interface, that
allows me the desired speed and is this issue I see related to
gnuradio and its scheduler or rather to the UHD API for the GPIOs?
BR,
Anton
Every GPIO state transition requi
Is there any alternative to the standard GPIO UHD interface, that allows me the
desired speed and is this issue I see related to gnuradio and its scheduler or
rather to the UHD API for the GPIOs??
BR,
Anton?
Von: Marcus D. Leech
Gesendet: Freitag, 10. Septe
PS: To clarify the 20us:
If I do not use a sleep function in that OOT block and run the flowgraph, I
measure a switching time of the GPIOs of 20us no matter which sample rate I
use I
f I use a sleep function the toggling period really depends on the
corresponding flowgraph's complexity.
On 2021-09-10 11:54 a.m., Dobler, Anton wrote:
I am extracting the package rate of a receive signal using a rather
complex GRC flowgraph, i.e. I am detecting the preamble of a receive
signal and generate a clock from here. This clock signal period is
within the range of 100us - 1ms.
Toggling
I am extracting the package rate of a receive signal using a rather complex GRC
flowgraph, i.e. I am detecting the preamble of a receive signal and generate a
clock from here. This clock signal period is within the range of 100us - 1ms.
As I wrote in my first message, the work function with the
On 2021-09-10 10:18 a.m., Dobler, Anton wrote:
Dear all,
I am currently trying to write an OOT block to switch a GPIO pin high
or low depending on the input signal. So far it has worked with the
configuration of the pins and I can also switch the pins according to
the input signal in a relati
You're probably right that a custom FPGA image would be needed here.
On Fri, Sep 10, 2021 at 11:07 AM Dobler, Anton
wrote:
> PS: Forgot to mention that I am using a USRP N310 and its front panel
> GPIO...
>
>
> Thank you for your help!
> --
> *Von:* Discuss-gnuradio
PS: Forgot to mention that I am using a USRP N310 and its front panel GPIO...
Thank you for your help!?
Von: Discuss-gnuradio
im Auftrag von Dobler, Anton
Gesendet: Freitag, 10. September 2021 16:18
An: discuss-gnuradio@gnu.org
Betreff: USRP, GPIO toggling and
A sleep is implemented by the kernel, not the scheduler, so what you're
seeing is that the kernel can not reschedule threads faster than 20kHz
(which is pretty fast). For higher speed, you'll need some sort of driver
that works closer to real time.
On Fri, Sep 10, 2021 at 10:21 AM Dobler, Anton
w
Dear all,
I am currently trying to write an OOT block to switch a GPIO pin high or low
depending on the input signal. So far it has worked with the configuration of
the pins and I can also switch the pins according to the input signal in a
relatively simple flowgraph consisting of a signal gene
Dear GNU Radio community,
Monday, the 13. of September, at 12:30 UTC
we will temporarily shut down the Matrix homeserver. This means that if you
have a
@username:gnuradio.org Matrix account, it will temporarily stop working.
We expect the Matrix infrastructure to be up and running, at better pe
15 matches
Mail list logo
