hello everyone
i am using the demo on e310,when i use the command
cmake ../ （success）success means no error
make (success)
make install(success)
ldconfig i got a mesage
ldconfig : /usr/lib/libstdc++.so.6.0.20-gdb.py is not ELF file - it has the
wrong magic bytes at start.
what is this mean?
--Ek
Hello,
I am trying to understand how the USRP performs the
modulation/demodulation to/from higher frequencies.
Let's say I have a complex signal s(t). When I feed it to the USRP
block, my understanding is that the USRP performs something like
s(t)*exp(i*w*t), and transmit the real part of it
Yes I am changing the frequency on both.
I have replaced the LFTX and the USRP motherboard with other boards and
I get the same results, so I ruled out a hardware problem.
It's like when using the length_tag feature on the USRP block it resets
the USRP after every packet.
I have created a
On 11/13/2015 03:15 PM, Jason Matusiak wrote:
>> Note the directory contains the file system and sdk.
>
>> http://files.ettus.com/e3xx_images/e3xx-release-3/
>
> Philip, That wasn't the directory I was using on the site, so thank you.
> It seems like gr-ettus is not in the build by default, is t
> Note the directory contains the file system and sdk.
> http://files.ettus.com/e3xx_images/e3xx-release-3/
Philip, That wasn't the directory I was using on the site, so thank you.
It seems like gr-ettus is not in the build by default, is that by
design? At this point I assume that I need to cr
On 11/13/2015 11:37 AM, Jason Matusiak wrote:
>> Assuming you are using Release-3 on the E310, make sure the sdk and file
>> system image come from the same directory. The error looks like this is
>> not the case.
> Are you saying Release-3 for the cross-compiler (I was assuming so)? And
> for th
Hi Israel,
can you please try to keep this discussion on the mailing list? It's
just that I'm not the only one who can help you, and certainly not even
the most competent :)
> 1- I have a very short distance between USRPs (approximately half
> a meter), so I’m surprised that I have so many e
> Assuming you are using Release-3 on the E310, make sure the sdk and file
> system image come from the same directory. The error looks like this is
> not the case.
Are you saying Release-3 for the cross-compiler (I was assuming so)? And
for the directory do you mean on the ettus file page?
>There
You're probably just seeing the group delay of the interpolation filters
on the N210, which for a given configuration,
should be of a fixed and predictable duration.
On 2015-11-13 11:18, Will Thompson wrote:
> Hi
>
> I have question about the latency of transmissions in the N210 USPR.
>
Hi
I have question about the latency of transmissions in the N210 USPR.
A bit of back ground in my system:
I have three nodes.
One (Node1) that periodically transmits a signal.
The one of the other nodes (Node2) tries to synchronise its transmission with
that of Node 1.
Node3 is simply used to re
On 11/13/2015 10:43 AM, Jason Matusiak wrote:
> Thank you Philip. I blew away my old toolchain, re-grabbed the latest
> and installed it. I can then run the cmake, make, and make install to
> load up the SD card on the E310 without error.
>
> Sadly, it doesn't appear to be 100% right because if
Thank you Philip. I blew away my old toolchain, re-grabbed the latest
and installed it. I can then run the cmake, make, and make install to
load up the SD card on the E310 without error.
Sadly, it doesn't appear to be 100% right because if I run a python
script I created in GRC on my PC, I get:
On 11/13/2015 08:37 AM, Jason Matusiak wrote:
>> The release-3 (and newer) toolchains have mako. Anything older doesn't.
>> That's the first thing to check.
>
> Thank you Philip. What is the best way to do that? I tried looking at
> the version-armv7ahf-vfp-neon-oe-linux-gnueabi only shows:
>
On 11/13/2015 08:37 AM, Jason Matusiak wrote:
>> The release-3 (and newer) toolchains have mako. Anything older doesn't.
>> That's the first thing to check.
>
> Thank you Philip. What is the best way to do that? I tried looking at
> the version-armv7ahf-vfp-neon-oe-linux-gnueabi only shows:
> Di
> The release-3 (and newer) toolchains have mako. Anything older doesn't.
> That's the first thing to check.
Thank you Philip. What is the best way to do that? I tried looking at
the version-armv7ahf-vfp-neon-oe-linux-gnueabi only shows:
Distro: nodistro
Distro Version: nodistro.0
Metadata Revis
On 11/13/2015 08:09 AM, Jason Matusiak wrote:
> I am having an issue with a cross compile (which I haven't done in a
> while) for my E310 and failing on Mako w/n pybombs.
The release-3 (and newer) toolchains have mako. Anything older doesn't.
That's the first thing to check.
Philip
>
>
> if I
I am having an issue with a cross compile (which I haven't done in a
while) for my E310 and failing on Mako w/n pybombs.
if I go to: ~/pybombs/src/uhd/host/build-arm
and run: .
/usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
followed by: cmake
-DCMAKE_TOOLCHAIN_FILE=
Hi Roee,
are you changing the frequency on both the transmitter and receiver?
Because: mixing anything to a higher frequency is exactly that, a
multiplication with a sinusoid.
Best regards,
Marcus
On 13.11.2015 07:01, Roee Bar wrote:
> Hello,
>
> I am experiencing some weird behaviour with USRP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This happens when too many shared buffers are allocated but not
released. It's an indicator that your flowgraphs are not terminated
correctly. So I suppose the issue is to figure out what 'Ctrl-Z'
really does.
On 12.11.2015 20:03, Richard Bell wrote:
19 matches
Mail list logo
