Hi all,
I'm trying to build batman-adv^[1] for E310 however it required the
kernel sources since it builds /batman-adv.ko/ kernel object. I built
the batctl^[2] and alfred^[3] without problem. I searched on the
internet for kernel sources however couldn't find it. Is there a way to
build bat
Hello,
I’m trying to command my usrp B200mini via its command port. I used the
documentation from here:
https://www.gnuradio.org/doc/doxygen/page_uhd.html
here is my command:
pmt::pmt_t command = pmt::make_dict();
command = pmt::dict_add(command, pmt::mp("gain"), pmt::mp(gain));
Hi Samuel,
luckily, these days, segfaults are rather rare in stock GNU Radio, and
UHD.
Can you share your exact flowgraph, or a GDB-generated backtrace, with
us?
Best regards,
Marcus
On Wed, 2018-12-05 at 10:31 +0100, samuel verdon via USRP-users wrote:
> Hello,
>
> I’m trying to command my us
Unless you're planning to compile UHD for Android, you should not be
using the compiler that you only installed (hopefully in a $prefix) for
android development.
So, yes, please revert, and make sure you're not accidentally mixing
includes and headers from the standard libraries of GCC 4.8 and you
So I can confirm that there is a frequency offset between the two USRP
N310s when using only an octoclock (10MHz + PPS) to synchronize. I have
measured with the tx_waveforms program
./tx_waveforms --args
"addr=192.168.x.2,time_src=external,clock_src=external,master_clock_rate=122.88e6"
--rate
No,
With basicRx, allowed subdev are :
- A:AB
- A:BA
- B:AB
- B:BA
This is confirmed by get_rx_subdev_spec() or by usrp->get_usrp_rx_info() (key :
rx_subdev_spec).
It's a bit logic because this daugtherboard do nothing before conversion. SMA
are directly wired to ADC input. After, using UHD, it's
Hi Marcus,
Thank you for your answer, I made a simple flowgraph to summarize my problem.
Here is also the backtrace of the segfault:
#0 pmt::eqv_raw (x=x@entry=0x0, y=0x2529300) at
/usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:1104
#1 0x7f7f159065f6 in pmt::assv_raw (obj=0x0, ali
Hi Florian,
trying to get my head to understand the order of problems here:
Could you try to use a higher frequency (say, --freq 2e9 instead of
3.5e6)?
I'd thing 3.51 MHz is out of range for the N310, anyway?
Best regards,
Marcus
On Wed, 2018-12-05 at 11:49 +0100, Florian Kaltenberger via USRP-
Sorry typo. I did use a frequency of 3.51GHz.
> On 5 Dec 2018, at 12:54, Marcus Müller wrote:
>
> Hi Florian,
>
> trying to get my head to understand the order of problems here:
> Could you try to use a higher frequency (say, --freq 2e9 instead of
> 3.5e6)?
> I'd thing 3.51 MHz is out of rang
Hi Samuel,
cool! That's really helpful :)
I'm now cross-posting this to discuss-gr, because it's a GNU Radio-land
issue. The maintainers of gr-uhd are active over there, too, so this
seems the smarter place to continue discussion.
so, in medias res:
On Wed, 2018-12-05 at 12:43 +0100, samuel
Hi,
When attempting to stream different waveforms using both channels of the
replay block simultaneously to two radios on the same USRP (X310) there are
under-runs. Any ideas why this is happening? The replay block works as
expected when using either channel 0 or channel 1, but fails when
atte
On Wed, Dec 5, 2018 at 4:13 PM Max Thomas via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
>
> When attempting to stream different waveforms using both channels of the
> replay block simultaneously to two radios on the same USRP (X310) there are
> under-runs. Any ideas why this is happe
oh! That means 341 ppb frequency error, which *really* shouldn't be
happening.
I'd like to get some statistics of that error, how are you measuring
it?
Best regards,
Marcus
On Wed, 2018-12-05 at 12:55 +0100, Florian Kaltenberger wrote:
> Sorry typo. I did use a frequency of 3.51GHz.
>
> > On 5
13 matches
Mail list logo
