Hi all,
I’d like to invite you all to join the Free Software Radio Devroom at the
FOSDEM 2022 online event tomorrow February 6th 2022 at 1300 (CET).
We have a range of very interesting presentations ranging from project updates,
implementation of hardware accelerators for Software Radio
up to
Software Radio Devroom Managers)
> On 6. Dec 2021, at 02:04, Andrej Rode wrote:
>
> Dear friends and fans of software-defined radio and free/open-source radio
> topics in general,
>
> FOSDEM 2022 (the free and open-source developer's meeting usually in
> Brussel
mp;A.
** Steering Committee
The track committee consists of:
* Phil Balister - "Crofton"
* Derek Kozel - "dkozel"
* Andrej Rode - "noc0lour"
* Martin Braun - "mbr0wn"
Hope to hear from you soon! And please forward this announcement.
Cheers
Andrej
__
_ptr]
> > at /root/work/e310/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> >
> > [ERROR] [UHD] Exception caught in safe-call.
> > in virtual ctrl_iface_impl::~ctrl_iface_impl()
> > at /root/work/e310/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> > this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
> > in typename T::sptr e300_transport::get_buff(double) [with T =
> > uhd::transport::managed_send_buffer; typename T::sptr =
> > boost::intrusive_ptr]
> > at /root/work/e310/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> >
> > [ERROR] [UHD] Exception caught in safe-call.
> > in virtual ctrl_iface_impl::~ctrl_iface_impl()
> > at /root/work/e310/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> > this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
> > in typename T::sptr e300_transport::get_buff(double) [with T =
> > uhd::transport::managed_send_buffer; typename T::sptr =
> > boost::intrusive_ptr]
> > at /root/work/e310/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257
> >
> >
> > any tips?
> >
> >
> > Thank you !
> >
> >
> > Best Regards,
> >
> > Carry
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
signature.asc
Description: Digital signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
dio. Though I have a custom built image on top of
`jethro-cleanup` in meta-ettus. Not sure from what the jethro image
distributed by Ettus is built.
Maybe a look in `dmesg` could provide some more info about the audio
driver initializing?
Cheers
Andrej
--
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D
this works through GR API.
Cheers
Andrej
--
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
signature.asc
Description: Digital signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus
adata creation in front of
the loop, memory allocation in a tight send loop could result in a
performance loss.
Other than that the code looks good. Sending data in bigger chunks would
certainly improve the performance.
Cheers,
Andrej
--
Andrej Rode
GPG Key: 750
ation you have increasing buffer sizes and
thus the uhd send()/recv() calls try to send bigger buffers?
But that's just guessing. An explanation what you are trying to do with
the Python API would be helpful, so the root cause (either in UHD or
your application can be identified)
Cheers,
Andr
buffers of your udp transport accordingly.
AFAIK this is not closely related to the Python API, bit might be
triggered by huge buffers passed into the python send/recv call?
Cheers,
Andrej
--
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA
signature.asc
Descriptio
