[USRP-users] weird usrp coredump
Trying to run a C++ based flowgraph and occasionally getting a
segfault/coredump. Finally, was able to capture the stack trace, and I am not
sure what to make of it. I //think// that this is all UHD, and not my app, but
I find that hard to believe. Here is that core dump, any thoughts on what is
causing this and if there is any way for more to gracefully recover from it?
This was using a single N320, gnuradio v3.8, and UHD 4.1.0.5.
#0 __memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:257
#1 0x7fe7f4950bbd in uhd::convert::converter::conv (num=,
out=..., in=..., this=)
at /opt/gnuradio/v3.8/src/uhd/host/include/uhd/convert.hpp:36
#2 uhd::transport::rx_streamer_impl::_convert_to_out_buff (num_samps=, chan=0, out_buffs=...,
this=0x7fe7a00027f8) at
/opt/gnuradio/v3.8/src/uhd/host/lib/include/uhdlib/transport/rx_streamer_impl.hpp:339
#3 uhd::transport::rx_streamer_impl::_recv_one_packet (buffer_offset_bytes=0, timeout_ms=100,
eov_positions=..., metadata=..., nsamps_per_buff=5000192, buffs=...,
this=0x7fe7a00027f8)
at
/opt/gnuradio/v3.8/src/uhd/host/lib/include/uhdlib/transport/rx_streamer_impl.hpp:311
#4 uhd::transport::rx_streamer_impl::recv (this=0x7fe7a00027f8, buffs=..., nsamps_per_buff=5000192,
metadata=..., timeout=, one_packet=)
at
/opt/gnuradio/v3.8/src/uhd/host/lib/include/uhdlib/transport/rx_streamer_impl.hpp:143
#5 0x7fe7f8b6bbd5 in gr::uhd::usrp_source_impl::work (this=0x7fe7c80053d0,
noutput_items=5000192,
input_items=std::vector of length 0, capacity 0, output_items=std::vector
of length 2, capacity 2 = {...})
at /opt/gnuradio/v3.8/src/gnuradio/gr-uhd/lib/usrp_source_impl.cc:549
#6 0x7fe7f8690637 in gr::sync_block::general_work (this=0x7fe7c80055b0,
noutput_items=, ninput_items=..., input_items=...,
output_items=...) at
/opt/gnuradio/v3.8/src/gnuradio/gnuradio-runtime/lib/sync_block.cc:61
#7 0x7fe7f8644a45 in gr::block_executor::run_one_iteration
(this=this@entry=0x7fe7c37fd8c0)
at
/opt/gnuradio/v3.8/src/gnuradio/gnuradio-runtime/lib/block_executor.cc:514
#8 0x7fe7f869cc3c in gr::tpb_thread_body::tpb_thread_body
(this=0x7fe7c37fd8c0, block=..., start_sync=..., max_noutput_items=)
at
/opt/gnuradio/v3.8/src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
#9 0x7fe7f868d844 in gr::tpb_container::operator() (this=,
this=, this=, this=,
this=) at
/opt/gnuradio/v3.8/src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:50
#10 gr::thread::thread_body_wrapper::operator()
(this=0x7fe7c8050810)
at
/opt/gnuradio/v3.8/src/gnuradio/gnuradio-runtime/lib/../include/gnuradio/thread/thread_body_wrapper.h:52
#11
boost::detail::function::void_function_obj_invoker0,
void>::invoke (function_obj_ptr=...)
at /usr/include/boost/function/function_template.hpp:159
#12 0x7fe7f86a9a92 in boost::function0::operator() (this=) at /usr/include/boost/function/function_template.hpp:759
#13 boost::detail::thread_data >::run (this=) at /usr/include/boost/thread/detail/thread.hpp:116
#14 0x7fe7f5787bcd in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.65.1
#15 0x7fe7f99ae6db in start_thread (arg=0x7fe7c37fe700) at
pthread_create.c:463
#16 0x7fe7f8ead61f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Help with collecting GNSS signals by using GNSS-SDR and USRP N210
Hi, To set thread priority, you need to add your user to group usrp... "D" means dropped packages. You are not reading fast enough. Since your last run was also at 4 Mhz without any "D"s, it seems your problem is with your hard disk I/O... HTH Nikos On Wed, Jul 13, 2022 at 1:39 PM Marta Brkić wrote: > > Hi, > > we have problem with collecting GNSS signals for GNSS spoofing by using USRP > N210 (daughterboard UBX-40), active GNSS antenna (GPSGlonass-36-N-GA) and > GNSS-SDR. > Firstly, we followed all steps from GNSS-SDR configuration page and we > successfully got the position fixes with downloaded file of raw signal > samples as at the link. > Afterwards, we tried to get the position fixes with active GNSS antenna but > unsuccessfully. We set all the parameters as at the instructions at the link > and ran 'my_GPS_receiver.conf' file. As the result, we got printed 'D' > (please see screenshots 1 and 2 attached). We tried to solve this problem by > following the instructions at ETTUS page but nothing worked in our case. > > Then, we tried to set the sampling frequency to 2MHz and there was no printed > 'D' after running the conf file. However, we didn't get the position fixes > and we only got 'Loss of lock in channel' (screenshot 3). We searched for > the solution and we wonder if missed something or we do not have all > necessary equipment (we saw that bias-tee is needed for some daughterboards). > > We would be thankful if you could help us with our problem. > > Thank you in advance and best regards, > Katarina Radoš and Marta Brkić > > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Help with collecting GNSS signals by using GNSS-SDR and USRP N210
...or your locks. Are you locking your reader? What exactly are you locking? Nikos On Thu, Jul 14, 2022 at 4:28 PM Nikos Balkanas wrote: > > Hi, > > To set thread priority, you need to add your user to group usrp... > "D" means dropped packages. You are not reading fast enough. > Since your last run was also at 4 Mhz without any "D"s, it seems your > problem is with your hard disk I/O... > > HTH > Nikos > > On Wed, Jul 13, 2022 at 1:39 PM Marta Brkić wrote: > > > > Hi, > > > > we have problem with collecting GNSS signals for GNSS spoofing by using > > USRP N210 (daughterboard UBX-40), active GNSS antenna (GPSGlonass-36-N-GA) > > and GNSS-SDR. > > Firstly, we followed all steps from GNSS-SDR configuration page and we > > successfully got the position fixes with downloaded file of raw signal > > samples as at the link. > > Afterwards, we tried to get the position fixes with active GNSS antenna but > > unsuccessfully. We set all the parameters as at the instructions at the > > link and ran 'my_GPS_receiver.conf' file. As the result, we got printed 'D' > > (please see screenshots 1 and 2 attached). We tried to solve this problem > > by following the instructions at ETTUS page but nothing worked in our case. > > > > Then, we tried to set the sampling frequency to 2MHz and there was no > > printed 'D' after running the conf file. However, we didn't get the > > position fixes and we only got 'Loss of lock in channel' (screenshot 3). > > We searched for the solution and we wonder if missed something or we do not > > have all necessary equipment (we saw that bias-tee is needed for some > > daughterboards). > > > > We would be thankful if you could help us with our problem. > > > > Thank you in advance and best regards, > > Katarina Radoš and Marta Brkić > > > > ___ > > USRP-users mailing list -- usrp-users@lists.ettus.com > > To unsubscribe send an email to usrp-users-le...@lists.ettus.com ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Help with collecting GNSS signals by using GNSS-SDR and USRP N210
Hi, If you use SSDs, you are even faster than hard disks:) RXLO is part of your UBX spec. I don't have one:( It seems that it has to do something with locking your GPS positions... A reader lock would be a lock on your reading, and could explain your "D"s, dropped samples, when you use it. That "RX" on the "RXLO" looks suspicious, but from your saying is just a lock on the receiver location... Could it be that until your N210 locks to a location, it receives samples, and therefore drops them? I don't know much about your configuration, so I better let someone else with more knowledge about it, answer. BR Nikos On Thu, Jul 14, 2022 at 4:46 PM Katarina Radoš wrote: > > Hi Nikos, > > thank you for your response. > We don't have HDD and we only have SSD on our laptop. > Is it necessary to have hard disk in order to run this? > > Regarding the locks, could you explain us what reader locking is exactly? > > Best regards, > Katarina and Marta > > From: Nikos Balkanas > Sent: Thursday, July 14, 2022 1:37 PM > To: Marta Brkić > Cc: usrp-users@lists.ettus.com ; > usrp-users-requ...@lists.ettus.com ; > Katarina Radoš > Subject: Re: [USRP-users] Help with collecting GNSS signals by using GNSS-SDR > and USRP N210 > > ...or your locks. Are you locking your reader? > What exactly are you locking? > > Nikos > > On Thu, Jul 14, 2022 at 4:28 PM Nikos Balkanas wrote: > > > > Hi, > > > > To set thread priority, you need to add your user to group usrp... > > "D" means dropped packages. You are not reading fast enough. > > Since your last run was also at 4 Mhz without any "D"s, it seems your > > problem is with your hard disk I/O... > > > > HTH > > Nikos > > > > On Wed, Jul 13, 2022 at 1:39 PM Marta Brkić wrote: > > > > > > Hi, > > > > > > we have problem with collecting GNSS signals for GNSS spoofing by using > > > USRP N210 (daughterboard UBX-40), active GNSS antenna > > > (GPSGlonass-36-N-GA) and GNSS-SDR. > > > Firstly, we followed all steps from GNSS-SDR configuration page and we > > > successfully got the position fixes with downloaded file of raw signal > > > samples as at the link. > > > Afterwards, we tried to get the position fixes with active GNSS antenna > > > but unsuccessfully. We set all the parameters as at the instructions at > > > the link and ran 'my_GPS_receiver.conf' file. As the result, we got > > > printed 'D' (please see screenshots 1 and 2 attached). We tried to solve > > > this problem by following the instructions at ETTUS page but nothing > > > worked in our case. > > > > > > Then, we tried to set the sampling frequency to 2MHz and there was no > > > printed 'D' after running the conf file. However, we didn't get the > > > position fixes and we only got 'Loss of lock in channel' (screenshot 3). > > > We searched for the solution and we wonder if missed something or we do > > > not have all necessary equipment (we saw that bias-tee is needed for some > > > daughterboards). > > > > > > We would be thankful if you could help us with our problem. > > > > > > Thank you in advance and best regards, > > > Katarina Radoš and Marta Brkić > > > > > > ___ > > > USRP-users mailing list -- usrp-users@lists.ettus.com > > > To unsubscribe send an email to usrp-users-le...@lists.ettus.com ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: weird usrp coredump
On 2022-07-14 08:25, Jason Matusiak wrote: Trying to run a C++ based flowgraph and occasionally getting a segfault/coredump. Finally, was able to capture the stack trace, and I am not sure what to make of it. I //think// that this is all UHD, and not my app, but I find that hard to believe. Here is that core dump, any thoughts on what is causing this and if there is any way for more to gracefully recover from it? This was using a single N320, gnuradio v3.8, and UHD 4.1.0.5. I have not had any other reports. One of the things about C/C++ (which you likely know) is that it's relatively easy for an application to corrupt heap or stack that some library relies on,and then something inside the library takes a left turn that it wouldn't otherwise take--this can make it *appear* that the library is the culprit, but it may well have been the calling application, often thousands of instructions ago... ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: weird usrp coredump
But that application is the USRP block of GNU Radio, so you're at least not the first to use it :) Wild stab: So, this is run on your PC, right; are you sure that the GNU Radio you run was built against the UHD you're using? (This is basically asking how you installed both GNU Radio and UHD) Best regards, Marcus On 14.07.22 22:23, Marcus D. Leech wrote: On 2022-07-14 08:25, Jason Matusiak wrote: Trying to run a C++ based flowgraph and occasionally getting a segfault/coredump. Finally, was able to capture the stack trace, and I am not sure what to make of it. I //think// that this is all UHD, and not my app, but I find that hard to believe. Here is that core dump, any thoughts on what is causing this and if there is any way for more to gracefully recover from it? This was using a single N320, gnuradio v3.8, and UHD 4.1.0.5. I have not had any other reports. One of the things about C/C++ (which you likely know) is that it's relatively easy for an application to corrupt heap or stack that some library relies on,and then something inside the library takes a left turn that it wouldn't otherwise take--this can make it *appear* that the library is the culprit, but it may well have been the calling application, often thousands of instructions ago... ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Is it possible to control the sampling position of the baseband signal on the rx side of the usrp?
Hello Fan: USRPs (or any other general-purpose SDRs) do not do the timing recovery for you. It is designed to transmit arbitrary signals, so it simply does not have any idea about the "timing" of your signals. The mismatch in the internal oscillator clocks will cause phase drift over time. You can try using external clock inputs (PPS and 10 MHz inputs) of the USRPs to forcefully synchronize them. This is often not practical in real-world wireless systems, though. It is great for some (albeit limited) applications and for debugging jobs. Something else that you can do is implementing your own synchronization algorithms. You can either oversample your signals and then use signal processing frameworks (like GNU Radio) to do the recovery, or implement them on the FPGA of the B210. Both will give you the same performance, assuming that your USB port can handle the oversampled signals and the FPGA is sufficiently large for your purposes. Regards, Kyeong Su Shin 보낸 사람: fan 보낸 날짜: 2022년 7월 14일 목요일 오후 3:12 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Is it possible to control the sampling position of the baseband signal on the rx side of the usrp? Hi，everyone. I have the question: Is it possible to control the sampling position of the baseband signal on the rx side of the usrp? The situation is as follows: I use a usrp b210 to transmit a set of 16QAM signals, and receive this signal on the rx side of the same device, and repeat this several times. However, under the condition that the transmitted signal, tx gain, rx gain, channel frequency and other settings are unchanged, there are some differences in amplitude and phase between the received data each time. I never moved the position of b210, so the channel should be time-invariant. I think there are two possible reasons: First, even if the transmitted signal and transmit settings are the same each time, the signal actually transmitted by usrp each time is still different; second, the receiver does not sample at the optimal sampling point , but randomly samples. Firstly，let's discuss the second possibility. As far as I know, USRP's dsp module downconverts the received bandpass signal to baseband and then samples the baseband signal. a gardner loop is usually used to get the best sampling point from the sampled data (timing recovery), but the implementation of the gardner rings in 2x2 mimo with 16QAM is more difficult. Is there a UHD interface that can control the position of the sample points? Or, the real reason is the first？ ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: weird usrp coredump
On 2022-07-14 18:57, Marcus Müller wrote: But that application is the USRP block of GNU Radio, so you're at least not the first to use it :) Wild stab: So, this is run on your PC, right; are you sure that the GNU Radio you run was built against the UHD you're using? (This is basically asking how you installed both GNU Radio and UHD) Best regards, Marcus Indeed, mis-match between what an application was linked against, and what it has dynamically loaded can cause Bad Things(tm). It's unfortunate that the *reality* of dynamically-linked, shared-library applications is that you *cannot* mix-and-match. This was one of the "promises" of DLLs "back in the day", when they were a shiny-new thing. Sigh. But my comment still holds to a certain degree. If you're writing an app in C++ or C that uses Gnu Radio, you can still "paste" things in such a way that some "distant" library loses its lunch. Been there. Done that. Yikes. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
