Re: [Discuss-gnuradio] diagnosing overflows
Hi Philip, Check out line 188: https://github.com/osmocom/gr-osmosdr/blob/master/lib/osmosdr/osmosdr_src_c.cc It would appear that other driver writers have followed the lead of Ettus and use the same letters to indicate the same error. I've only looked at this code for an entire five minutes, but it looks like the code is initialized with a string that is fed to a dictionary, and after that, _buf_len's size is set from the dictionary, or if there's no entry in the dictionary, sets it to 15. Perhaps you could increase your buffer size? Also, if you're building from source, perhaps you can use -O2 or -O3 when you build it? I don't see any optimization flags set in the top-level CMakeLists.txt In my limited experience with overflows, the two solutions I have used are 1) sample the input at a lower rate, or if the input sample rate has to be at whatever level it is, 2) decimate the samples as soon as possible. Regards, Sean On Tue, Aug 8, 2017 at 8:53 PM, Philip Hahn <hah...@gmail.com> wrote: > Hi Sean, > > I am not using UHD blocks, I am using osmocom source/sinks. I did not see > any warnings about changing buffer sizes. > > Thank you, > > philip > > On Tue, Aug 8, 2017 at 8:42 PM, Sean Horton <seanhorto...@gmail.com> > wrote: > >> Unless I'm mistaken, only the usrp sink/source blocks report overflow >> (source) or underflow (sink). You can see this mentioned in >> uhd/docs/general.dox (uhd github repo). >> >> Did you listen to the warnings you get on startup about changing buffer >> sizes with a series of commands requiring sudo? That helped me resolve some >> overflow, otherwise it sounds like you'll need to drop your sample rate >> unless you need it as high as it currently is. >> >> Regards, >> Sean >> >> On Tue, Aug 8, 2017 at 7:56 PM, Philip Hahn <hah...@gmail.com> wrote: >> >>> Folks, >>> >>> Is there a way to diagnose which block first reports an overflow in a >>> flowgraph? >>> >>> In my particular instance I am running a flowgraph which is overflowing >>> without pegging either RAM or CPU. >>> >>> Thank you, >>> >>> philip >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> Sean Horton >> >> > -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] diagnosing overflows
Unless I'm mistaken, only the usrp sink/source blocks report overflow (source) or underflow (sink). You can see this mentioned in uhd/docs/general.dox (uhd github repo). Did you listen to the warnings you get on startup about changing buffer sizes with a series of commands requiring sudo? That helped me resolve some overflow, otherwise it sounds like you'll need to drop your sample rate unless you need it as high as it currently is. Regards, Sean On Tue, Aug 8, 2017 at 7:56 PM, Philip Hahn <hah...@gmail.com> wrote: > Folks, > > Is there a way to diagnose which block first reports an overflow in a > flowgraph? > > In my particular instance I am running a flowgraph which is overflowing > without pegging either RAM or CPU. > > Thank you, > > philip > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Spurious Spikes in RX Data
Hi Marcus, I'm not getting overruns, and the signal source was the N210 (I was doing a loopback test). I switched to a hardware radio to transmit data, and the spikes went away. Is that what you'd expect? The spikes were 2000-3000 samples apart. If you don't think I should see those spikes even when the SDR is receiving from itself, I can investigate trying different frequency settings. What equation can be used to calculate supported sample rates? Is it just clock (default 50 MHz, but I think it can be set to other values) divided by any integer value, only even integers, etc...? I just used the sample rate someone had chosen before I inherited the code, and it didn't generate any warnings about not being a value supported by the hardware (which is what I saw when switching the frequency to other values). Thanks, Sean On Fri, Jul 14, 2017 at 1:52 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > On 07/06/2017 12:46 PM, Sean Horton wrote: > >> Hi, >> >> I've recently gotten someone with Matlab to help me look at what's going >> on in my receiver. The image was created with matlab from data from a file >> sink connected directly to a usrp source. I am seeing spurious spikes when >> plotting I or Q, and I'm not sure where they could be coming from, or how >> to get rid of them. I know what I think I'm about to transmit doesn't have >> those spikes. >> >> Some info that might be helpful: >> Using a N210 with a UBX connected directly to my desktop. >> I have tried a few sample rates (96000, 201613). >> I am currently doing a loopback test, though working on getting the sdr >> to listen to a signal generated by another piece of equipment. >> This doesn't stop me from being able to decode what is transmitted, but >> since my issue is I can't decode messages with as low of an SNR as I >> expect, I'm trying to examine everything as closely as possible. I'm off by >> 20-30 dB. >> The entire path to get to matlab is: usrp_source -> file_sink -> Python's >> scipy in order to read in the raw data and store it in a .mat. >> >> Also, if any responder would be kind enough to also point out how I >> properly respond, that'd be great. I know I can't just hit reply to the >> digest, and I also can't change the subject line when I hit reply in the >> digest, so I'm sort of stumped. I have had digest mode on, so I'll turn >> that off for now. >> >> Thanks, >> Sean >> >> -- >> Sean Horton >> >> >> Sean: > > So, I'll note that for an N210, neither of those sample rates are > supported precisely by the hardware. > > Are you getting overruns when recording the data? > > What is the source of the signal? > > What frequency, and do the spikes come/go with frequency setting? > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Spurious Spikes in RX Data
Hi, I've recently gotten someone with Matlab to help me look at what's going on in my receiver. The image was created with matlab from data from a file sink connected directly to a usrp source. I am seeing spurious spikes when plotting I or Q, and I'm not sure where they could be coming from, or how to get rid of them. I know what I think I'm about to transmit doesn't have those spikes. Some info that might be helpful: Using a N210 with a UBX connected directly to my desktop. I have tried a few sample rates (96000, 201613). I am currently doing a loopback test, though working on getting the sdr to listen to a signal generated by another piece of equipment. This doesn't stop me from being able to decode what is transmitted, but since my issue is I can't decode messages with as low of an SNR as I expect, I'm trying to examine everything as closely as possible. I'm off by 20-30 dB. The entire path to get to matlab is: usrp_source -> file_sink -> Python's scipy in order to read in the raw data and store it in a .mat. Also, if any responder would be kind enough to also point out how I properly respond, that'd be great. I know I can't just hit reply to the digest, and I also can't change the subject line when I hit reply in the digest, so I'm sort of stumped. I have had digest mode on, so I'll turn that off for now. Thanks, Sean -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Are pmt Message Handled Differently In Hier Blocks
I have a series of tests to test two blocks, where one block encodes/modulates a message, and the other demodulates/decodes the message. Since there are several parts of the hier block, to test it I have a series of tests that do something like this: A -> ~A A -> B -> ~B -> ~A etc (there's ~6 blocks to encode and ~6 blocks to decode) This allows me to build up the hier blocks piece by piece, and at each step make sure the decoding block can decode what is encoded. I then have a test for the hier blocks themselves, which do nothing more than create and connect all of the blocks that I've already tested, just not inside a hier block. All of the tests before the test using the hier blocks pass. I've run the tests 3000 times in a row. But one of my hier blocks doesn't work, and after hours of debugging, it seems that a message from one of the blocks isn't propagated to the next block. I added code to print when message are published and handled, and there's a publish print statement without a corresponding handled print statement. I've added a message probe, and it gets the message. This block has worked, but I've changed my test to only send one message instead of repeating the same message and expecting to get it at least once. Thanks, Sean -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Making Sure Usrp Sink Center Frequency Changed Before Data Arrives
I have a flowgraph that is supposed to be set up so that the tx frequency can be changed on the fly. It was originally changed by changing variables, but I've switched to publishing pmt_t destined for the usrp sink (it didn't seem to work on the rx side very well, something was buggy). Testing seems to indicate that the center frequency isn't always changed before the data is transmitted (in the test I should be sending 20 chunks of data, and I should be alternating between two frequencies). Is there a way to query the usrp sink to determine when it has changed it's center frequency? It doesn't publish a message, or it doesn't look that way after looking at source. -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tune Requests
I have my flowgraph set up so that parameters such as rx and tx frequencies can be changed while running, and it's being sent two frequencies to listen to, freq1 and freq2, and the idea is that if there are two frequencies, to set the frequency to (freq1 + freq2) / 2, but the fft shows that one of the receive chains has the dc spike in it, which makes me think the center frequency is really freq1, but it's simply shifting the received signal. What type of request will force the center frequency to actually be at (freq1 + freq2) / 2? If it's a tune_request, how do you make one in cpp, I can't find any example of it being done. It's not a big deal, but if I can get rid of the dc spike, I'd certainly like to. Regards, -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Writing Different Number of Bytes To Different Outputs
I'm having trouble outputting data from a block through multiple outputs of
unequal length. The first four output one int, the second four output
num_channels int (which is determined by the value passed in from the
constructor).
If I try to output my data like so, it doesn't work, everything is 0:
int32_t * out0 = reinterpret_cast(output_items[0]);
...
int32_t * out7 = reinterpret_cast(output_items[7]);
out0[0] = val0;
...
out3[0] = val3;
for (std::size_t i = 0; i < num_channels; ++i) {
out4[i] = val4[i];
...
out7[i] = val7[i];
}
The next block connected to the last port was getting all zero values, so I
just did
int32_t * out = reinterpret_cast(output_items[0]);
memset(out, 0x08, noutput_items);
That finally resulted in non-zero values popping being outputted. I can't
set any value with what I want it to be, though, so the sole value coming
out of the first output is always zero when I'm not memsetting every byte
to the same value.
Regards,
Sean
--
Sean Horton
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using Function Probe To Get Value From Probe Signal Vector
I have a function probe to get an int from one block's output, and been using a function probe to get the value of the probe signal. I now want to have the block output a vector of ints, and use a probe signal vector to capture them, and nave a few function probes to get index 0, 1, and so forth. How do you do that? It does not seem to be as simple as replacing level with leve[index] (where index is 0, 1, etc) in the function probe's function name field. In my test setup, the function probe never changes from the default value, which is not one of the values in my vector source I'm using for testing. -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running
All right, that makes me feel better. A few corrupted samples is perfectly fine since the setting should only change before transmitting/receiving, not during. Thanks, Sean On Tue, Dec 20, 2016 at 10:21 AM, Kevin Reid <kpr...@switchb.org> wrote: > On Tue, Dec 20, 2016 at 8:38 AM, Sean Horton <seanhorto...@gmail.com> > wrote: > >> What is the best way to change settings such as gain, taps, frequency >> values, etc of various blocks while running? The current setup I'm >> refactoring receives new configs over tcp, and a block outputs the new >> config values to probe signals, and those probe signals are used to change >> various settings. In the case of setting some usrp source parameters >> (center frequency), it appears to not properly work, so for the usrp sink >> and sources, I am going to pass messages to change the parameters. This >> isn't possible for other blocks, though, as they do not have message >> inputs. >> >> If I should stick with the current method, though, I'm really curious how >> there is mutual exclusion, as the values are being changed while the >> flowgraph is running. I have looked at the source code for some of the >> blocks I'm using, and I don't see any mutexes. This makes me think this >> isn't the best way to do what is being done. >> > > Calling the setter methods is fine. Mutexes are not necessary for simple > numeric parameters, because one thread (the block work thread) is only > reading and one thread is only writing (your control thread) and there are > no particular invariants to be maintained. > > The worst thing that could happen is reading a half-written large value > and producing bad data for a period, but changing parameters in many cases > will result in some kind of “glitch” in the sample stream anyway, so this > is merely “noisier”. > -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running
Thanks. I only know enough about gnuradio to be dangerous right now, so I wasn't sure if that was an intended way to modify block parameters. I haven't been able to test most of that yet, initial variables have been the same as what was being sent from a remote server, so if it didn't work, I wouldn't notice. I may not be able to get around to it, but I was hoping to convert as much of the code into C++ (easier for me to unit test it), so would it be easier to change block parameters in C++? I can see that a hier block made with gnuradio has functions generated to set the internal block parameters, not sure if the same would happen if the hier block were made in C++. Perhaps I should test that. Unfortunately the code that sends the configuration is a scary mess that I'd have to spend weeks refactoring, so right now I have a block that just converts raw bytes sent over tcp back into the parameters. That might be something I want to aim for, though. Thanks again, Sean On Tue, Dec 20, 2016 at 9:16 AM, <mle...@ripnet.com> wrote: > If your flow-graph is GRC based, then any block parameters that can be > changed at runtime can be tied to a variable. > > Once you have that, then you can use, for example, XMLRPC to set any > variable in the flow-graph from the "outside world" (which includes > "reflexive" setting from non-flowgraph python code). > > There's also controlport, which I have haven't played with. > > > > > > > On 2016-12-20 11:38, Sean Horton wrote: > > What is the best way to change settings such as gain, taps, frequency > values, etc of various blocks while running? The current setup I'm > refactoring receives new configs over tcp, and a block outputs the new > config values to probe signals, and those probe signals are used to change > various settings. In the case of setting some usrp source parameters > (center frequency), it appears to not properly work, so for the usrp sink > and sources, I am going to pass messages to change the parameters. This > isn't possible for other blocks, though, as they do not have message > inputs. > > If I should stick with the current method, though, I'm really curious how > there is mutual exclusion, as the values are being changed while the > flowgraph is running. I have looked at the source code for some of the > blocks I'm using, and I don't see any mutexes. This makes me think this > isn't the best way to do what is being done. > > Thanks, > Sean > > -- > Sean Horton > > > _______ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running
What is the best way to change settings such as gain, taps, frequency values, etc of various blocks while running? The current setup I'm refactoring receives new configs over tcp, and a block outputs the new config values to probe signals, and those probe signals are used to change various settings. In the case of setting some usrp source parameters (center frequency), it appears to not properly work, so for the usrp sink and sources, I am going to pass messages to change the parameters. This isn't possible for other blocks, though, as they do not have message inputs. If I should stick with the current method, though, I'm really curious how there is mutual exclusion, as the values are being changed while the flowgraph is running. I have looked at the source code for some of the blocks I'm using, and I don't see any mutexes. This makes me think this isn't the best way to do what is being done. Thanks, Sean -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Can't Make Any OOT Block Depending on Blocks with X in name
I have already made some OOT blocks, so I should have the basic process
down, but I can't find out why using any blocks in a hier block with X in
the name, which indicates an input, output, and/or parameter can be of
multiple types, results in undefined references to the make functions.
I have tried using the not_bb block in gnuradio/blocks, diff_encoder_bb in
gnuradio/digital, and freq_xlating_fir_filter_ccf in gnuradio/filter. I can
use these blocks in python without incident, but making a hier block using
those types of blocks is not working. I run the built in default tests, and
they all fail because of an undefined references to code in gnuradio, which
I have already built from source.
For example, this is from the test logs:
undefined symbol:
_ZN2gr6filter27freq_xlating_fir_filter_ccf4makeEiRKSt6vectorIfSaIfEEdd
After using c++filt:
gr::filter::freq_xlating_fir_filter_ccf::make(int, std::vector<float,
std::allocator > const&, double, double)
This is the entire contents of a source file I've made trying to resolve
this issue:
#include "test_xx_impl.h"
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include
namespace gr {
namespace howto {
test_xx::sptr test_xx::make() {
return gnuradio::get_initial_sptr(new test_xx_impl());
}
test_xx_impl::test_xx_impl()
: gr::hier_block2("test_xx", gr::io_signature::make(1, 1,
sizeof(uint8_t)),
gr::io_signature::make(1, 1, sizeof(uint8_t))) {
filter::freq_xlating_fir_filter_ccf::sptr testing =
filter::freq_xlating_fir_filter_ccf::make(1, {1}, 1, 100);
}
41
42 } /* namespace howto */
43 } /* namespace gr */
Regards,
Sean
--
Sean Horton
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problems Changing USRP Sink Center Frequency During Runtime
After about a week of debugging why I was having trouble receiving multiple AX25 packets when sent together, I've discovered the issue seems to be that if the initial center frequency of the usrp sink is not the frequency that it is changed to after it starts running, then the problem surfaces. Tweaking parameters in other blocks, like quad demod and clock recovery mm have had almost no impact. The code is supposed to allow the center frequency (and other parameters) to be changed while running, which is why just setting the center frequency to the frequency I'm using for testing is not the best way to solve this. What sending multiple ax25 packets look like. There's a single 0x7E between each ax25 packet, which is allowed by the specifications. Also, an icom radio works just fine, and it's in a different room. <~100 bytes of preamble> Also, if the radio is sending one ax25 packet at a time, even when the starting center frequency is 100 MHz+ away from where the radio is transmitting at. -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using OOT In Gnuradio Error
Thanks Nicolas, that was it. Regards, Sean On Wed, Oct 12, 2016 at 2:25 PM, Nicolas Cuervo <nicolas.cue...@ettus.com> wrote: > Hello Sean, > > after you built and install your OOT block, did you ran: > > $ sudo ldconfig > > ? > > Cheers, > > -Nicolas > > On Wed, Oct 12, 2016 at 1:42 PM, Sean Horton <seanhorto...@gmail.com> > wrote: > >> I have followed the following example, the only difference being: >> step 1) I didn't use tutorial as the name, >> step 2) I named my block qpsk_demod_cb instead of my_qpsk_demod_cb, which >> then meant in step 4 I used a different name, key, catetory, import, and >> make where I replaced tutorial and removed "my_" >> >> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tu >> torial_GNU_Radio_in_C++ >> >> When I then run mpsk_stage6 with my demod block, it stops working >> immediately. When I call the .py directly, I get: >> >> self.oot_qpsk_demod_cb_0 = oot.qpsk_demod_cb(True) >> AttributeError: 'module' object has no attribute 'qpsk_demod_cb' >> >> Also, if it's helpful, I called the qa_qpsk_demod_cb.py in the python >> folder, and I get >> >> File "./qa_qpsk_demod_cb.py", line 24, in >> import oot_swig as tyvak >> ImportError: No module named oot_swig >> >> Any help on fixing this would be great, I'd like to test my blocks by >> visualizing in gnuradio before switching to C++. >> >> -- >> Sean >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Sean Horton ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using OOT In Gnuradio Error
I have followed the following example, the only difference being: step 1) I didn't use tutorial as the name, step 2) I named my block qpsk_demod_cb instead of my_qpsk_demod_cb, which then meant in step 4 I used a different name, key, catetory, import, and make where I replaced tutorial and removed "my_" http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++ When I then run mpsk_stage6 with my demod block, it stops working immediately. When I call the .py directly, I get: self.oot_qpsk_demod_cb_0 = oot.qpsk_demod_cb(True) AttributeError: 'module' object has no attribute 'qpsk_demod_cb' Also, if it's helpful, I called the qa_qpsk_demod_cb.py in the python folder, and I get File "./qa_qpsk_demod_cb.py", line 24, in import oot_swig as tyvak ImportError: No module named oot_swig Any help on fixing this would be great, I'd like to test my blocks by visualizing in gnuradio before switching to C++. -- Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
