Hello,
maybe this : https://github.com/EttusResearch/uhd/pull/135
will help you
Gwen
On Fri, 10 Nov 2017 00:29:25 -0600
Kevin McGuire via USRP-users wrote:
> I was able to get the compiler flags passed in so that the check for
> the header arm_neon.h passes. I added it to the CMakeList root fi
Gwen,
Wow, it was only 15 days ago too. The coincidence! Yes, that is the exact
problem. Thank you!
I have got mine compiled and I can see that it did build the converter for
the neon.
Kevin
On Fri, Nov 10, 2017 at 2:07 AM, Gwenhael Goavec-Merou via USRP-users <
usrp-users@lists.ettus.com> wrot
I guess this is a little late, but you can pass in compiler flags on the
command line with -DCMAKE_CXX_FLAGS. For example:
cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon
-mtune=cortex-a15" ../
Ron
On 11/10/2017 12:07 AM, Gwenhael Goavec-Merou via USRP-users wrote:
Hello,
maybe
On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote:
> I guess this is a little late, but you can pass in compiler flags on the
> command line with -DCMAKE_CXX_FLAGS. For example:
>
> cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon
> -mtune=cortex-a15" ../
That would be the pref
On 11/10/2017 06:41 AM, Philip Balister via USRP-users wrote:
> On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote:
>> I guess this is a little late, but you can pass in compiler flags on the
>> command line with -DCMAKE_CXX_FLAGS. For example:
>>
>> cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-a
I've some difficults to understand because the piece of code impacted
by this patch is only use if HAVE_ARM_NEON_H is true.
Then I suppose if the CPU is an ARM but has no neon this test is false
and then this part is not used.
It's seems logical because c and asm files added in this section are
neo
On 11/10/2017 06:57 AM, Gwenhael Goavec-Merou via USRP-users wrote:
> I've some difficults to understand because the piece of code impacted
> by this patch is only use if HAVE_ARM_NEON_H is true.
> Then I suppose if the CPU is an ARM but has no neon this test is false
> and then this part is not us
On 11/10/2017 01:11 AM, Bakshi, Arjun via USRP-users wrote:
I'm observing an unstable phase when I'm transmitting and receiving a
constant value over a wire. Is that normal, or is something wrong with
my HW or configuration?
I assumed that since the channel is fixed, and USRPs are synced, t
Hi Ian,
OK - is there code for the dissector available to build a new version?
Or do you think it's worth it?
Also - our host sending the samples was actually only 1Gbps ethernet (we
weren't using the 10Gbps card for that), so I'm not sure that the
samples would be going into the switch fast
Kevin,
I wouldn’t expend more effort at the moment on the dissector, the UDP ports and
packet sizes pretty much tell you whats going on if you understand UHD. It may
be that the dissector for the old UHD protocol was never complete/perfect.
Interesting that it was the monitoring port that was 10
On 11/10/2017 06:52 AM, Philip Balister via USRP-users wrote:
> On 11/10/2017 06:41 AM, Philip Balister via USRP-users wrote:
>> On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote:
>>> I guess this is a little late, but you can pass in compiler flags on the
>>> command line with -DCMAKE_CXX_
Wanted to further clarify something. Do you mean that a usrp will in most cases
stay below acceptable levels, or that my specific setup is safe?
Like TX at 520mhz makes the snr much higher compared to that at 1.2GHz.
Thanks
AB
Bakshi, Arjun wrote
>
>
>Thanks for clearing that up.
>
There is nothing you can do with a USRP to expose you to harmful levels of
RF energy. You would need to add an amplifier.
On Fri, Nov 10, 2017 at 11:04 AM Arjun Bakshi
wrote:
> Wanted to further clarify something. Do you mean that a usrp will in most
> cases stay below acceptable levels, or that
My fix will be in a file which has a GPL copyright notice, so I think there
won't be a problem with it.
Still, it might be a good idea to include the license in the root directory
of the repository. It's recommended e.g. by GNU GPL how-to.
2017-11-09 16:33 GMT+01:00 Michał Wróbel :
> Hi Manuel,
14 matches
Mail list logo