Thanks, Marcus.
I was running a slightly older version, so updated to release_003_010_002_000.
Now it does not get as far at all, but seg faults :-(
Backtrace looks like
Thread 18 "TxRxFlood" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8ff9700 (LWP 7602)]
0x00007ffff731fb96 in
__convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector<void
const*> const&, uhd::ref_vector<void*> const&, unsigned long) () from
/usr/local/lib/libuhd.so.003
(gdb) bt
#0 0x00007ffff731fb96 in
__convert_sc16_item32_le_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector<void
const*> const&, uhd::ref_vector<void*> const&, unsigned long) () from
/usr/local/lib/libuhd.so.003
#1 0x00007ffff768a361 in
uhd::transport::sph::recv_packet_handler::convert_to_out_buff(unsigned long) ()
from /usr/local/lib/libuhd.so.003
#2 0x00007ffff7695d1f in
uhd::transport::sph::recv_packet_streamer::recv(uhd::ref_vector<void*> const&,
unsigned long, uhd::rx_metadata_t&, double, bool) () from
/usr/local/lib/libuhd.so.003
#3 0x00000000004841e0 in uhd::jitc::liquidDspPhy::receiveLoop (this=0x754650)
at /home/knud/Development/uhd-jitc/lib/phy_layer/liquidDspPhy.cpp:273
#4 0x000000000048a543 in boost::_mfi::mf0<void,
uhd::jitc::liquidDspPhy>::operator() (this=0x7790c8, p=0x754650)
at /usr/include/boost/bind/mem_fn_template.hpp:49
#5 0x000000000048a4c4 in
boost::_bi::list1<boost::_bi::value<uhd::jitc::liquidDspPhy*>
>::operator()<boost::_mfi::mf0<void, uhd::jitc::liquidDspPhy>,
boost::_bi::list0> (this=0x7790d8, f=..., a=...) at
/usr/include/boost/bind/bind.hpp:253
#6 0x000000000048a45c in boost::_bi::bind_t<void, boost::_mfi::mf0<void,
uhd::jitc::liquidDspPhy>,
boost::_bi::list1<boost::_bi::value<uhd::jitc::liquidDspPhy*> > >::operator()
(this=0x7790c8) at /usr/include/boost/bind/bind_template.hpp:20
#7 0x000000000048a40e in boost::detail::thread_data<boost::_bi::bind_t<void,
boost::_mfi::mf0<void, uhd::jitc::liquidDspPhy>,
boost::_bi::list1<boost::_bi::value<uhd::jitc::liquidDspPhy*> > > >::run
(this=0x778f10)
at /usr/include/boost/thread/detail/thread.hpp:116
#8 0x00007ffff67305d5 in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
#9 0x00007ffff65096ba in start_thread (arg=0x7fffe8ff9700) at
pthread_create.c:333
#10 0x00007ffff53b93dd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Looked at the source for the __convert_sc16_item32_le_… and can’t see the issue
easily. Obviously originates at my call to recv at #2, which is invoked after
the first scheduled receive. I assume that recv starts getting samples at the
scheduled time and a wire sample conversion goes awry.
Tried a different program that does only scheduled receives and it still works
properly, so it must be something in the new program, but not UHD-related.
I’ll keep looking…
thanks,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
An Fortschritt glauben heißt nicht glauben, daß ein Fortschritt schon geschehen
ist. Das wäre kein Glauben. - Franz Kafka
Post hoc ergo propter hoc.
> On Sep 6, 2017, at 18:37, Marcus D. Leech via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> On 09/06/2017 08:15 PM, Steven Knudsen via USRP-users wrote:
>> Hi All,
>>
>> I am building a TDMA system based on the B200mini. TX is out the TRX port
>> and RX is on RX2.
>>
>> I schedule both TX and RX using stream commands. Tested separately, they
>> work great. However, when I have them running together (separate threads for
>> send and recv calls), the transmit waveform is attenuated about 70%. Since
>> I’ve not yet got the demodulation set up, I am not sure if it’s just
>> attenuation or maybe something else. The transmitted packet length looks to
>> be okay.
>>
>> I thought that maybe the transmit and receive windows are maybe too close in
>> time, so separated them by a millisecond; no change.
>>
>> I suspect I am seeing some kind of interference between the TX and RX
>> streamers. Maybe I need to issue some command at the end of RX?
>>
>> Any suggestions on where I’m going wrong?
>>
>> Thanks,
>>
>> steven
>>
>>
> Are you running the latest UHD?
>
> I vaguely recall some switching issues on this platform with an early code
> release. But I could be mis-remembering.
>
>
> _______________________________________________
> 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
