Re: [Discuss-gnuradio] Proper block inheritance
Thank you Josh. At the moment I wanted to make this as simple as possible. My idea was to make a new class(block type) and to make my impl class inherit that class also. In that new class I would store message port subscription and a method for sending message that deframer received valid message. The problem is i can't really figure out how to make a the new class that will be used only to be inheritted by my deframer block. Something simillar is done with filter blocks in gnuradio, there are few classes declared in fir_filter.h and other filters inherit that class. Cheers, Nemanja On Fri, Sep 6, 2013 at 1:07 AM, Josh Blum wrote: > > > On 09/05/2013 02:12 AM, Nemanja Savic wrote: > > HI all guys, > > > > I have 3 different packet deframers, and now I would like them to be able > > to send a message to a certain block about correct packet reception. In > > order to do that I want to make some "phantom" block that will have > message > > out port. > > Are you looking to have a sort of control block that can apply > configuration settings to these packet deframers? Either once at > init-time or at runtime based on some conditions? If so, this also might > make sense for you: > > In GRAS, your deframers would register calls for configuring packet > reception: > https://github.com/guruofquality/gras/wiki/Codeguide#method-registration > > In the top block, when you connect flows, you can also register the > blocks into a tree. The control block could then find the deframers at > runtime and apply new settings dynamically: > > https://github.com/guruofquality/gras/wiki/Codeguide#wiki-zero-configuration > > > Its all GRC friendly and thread safe. You could do this with messages > too, it really depends what works best or makes the most sense. Anyway, > I have just been thinking about this kind of stuff and I wanted to share. > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] not responding B100
Hi List, My B100 suddenly stopped responding to UHD init. It appears that the USB interface actually lost its ability to identify as a device. Here below, you can find the output of the fedora "messages" log for the Broken B100 as well as for a working one. Could this be solved by re-programming the USB interface somehow? my best regards vince _ Bricked B100 Sep 9 17:43:25 vince kernel: [293521.821638] usb 1-1.2: USB disconnect, device number 23 Sep 9 17:43:28 vince kernel: [293524.558326] usb 1-1.2: new high-speed USB device number 25 using ehci_hcd Sep 9 17:43:28 vince kernel: [293524.643549] usb 1-1.2: New USB device found, idVendor=0a00, idProduct=0002 Sep 9 17:43:28 vince kernel: [293524.643554] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Sep 9 17:43:28 vince mtp-probe: checking bus 1, device 25: "/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2" Sep 9 17:43:28 vince mtp-probe: bus: 1, device: 25 was not an MTP device Good B100 Sep 9 17:43:28 vince mtp-probe: bus: 1, device: 25 was not an MTP device Sep 9 17:43:58 vince kernel: [293555.356431] usb 1-1.2: USB disconnect, device number 25 Sep 9 17:44:17 vince kernel: [293573.964334] usb 1-1.2: new high-speed USB device number 26 using ehci_hcd Sep 9 17:44:17 vince kernel: [293574.050317] usb 1-1.2: New USB device found, idVendor=2500, idProduct=0002 Sep 9 17:44:17 vince kernel: [293574.050322] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=6 Sep 9 17:44:17 vince kernel: [293574.050326] usb 1-1.2: Product: USRP B1004 Sep 9 17:44:17 vince kernel: [293574.050328] usb 1-1.2: Manufacturer: Ettus Research LLC Sep 9 17:44:17 vince kernel: [293574.050330] usb 1-1.2: SerialNumber: E8R10ZFB1 Sep 9 17:44:17 vince mtp-probe: checking bus 1, device 26: "/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.2" Sep 9 17:44:17 vince mtp-probe: bus: 1, device: 26 was not an MTP device Sep 9 17:44:49 vince kernel: [293606.298898] usb 1-1.2: USB disconnect, device number 26 -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF and gnuradio?
Gave it a short try during lunch break - gnuradio wants to address hackrf, although I do not own this and in fact even did unselect hackrf in gr-osmosdr cmake command. Ralph. > -Original Message- > From: Brian Padalino [mailto:bpadal...@gmail.com] > Sent: Monday, September 09, 2013 6:38 PM > To: Ralph A. Schmid, dk5ras > Cc: GNURadio Discussion List > Subject: Re: [Discuss-gnuradio] bladeRF and gnuradio? > > On Mon, Sep 9, 2013 at 6:43 AM, Ralph A. Schmid, dk5ras > wrote: > > Hi, > > > > Are there any out here with experience in getting bladeRF being usable > > with gnuradio/grc? So far I followed the usual steps, bladerf and > > gr-osmosdr compiled, but as documentation is being far from getting > > finished, I only reach the point of loading manually the FPGA image, > > nothing more :( Furthermore, with the latest changes in code bladeRF > > even does not compile any more... > > There was a recent change which added a call to libusb_get_version() which > doesn't exist in 1.0.9 of libusbx. So if you're running that, you should > consider updating to a newer version. I know it exists in > 1.0.12 and later. What version of libusbx are you using? Is it a possibility to > update? version 1.0.17 was recently released. > > https://github.com/libusbx/libusbx > > > I know the forum, but I prefer mailing lists like this - maybe there > > even is some active bladeRF list? > > We've gone through some restructuring of the library and where it's installed > to so if you've potentially got a stale version somewhere you're not > expecting it to be, that might cause issues. > > After moving to libusb instead of a straight kernel driver, the current work to > go on the driver right now is to interface with the asynchronous stream > instead of using the synchronous transmit and receive interface. The kernel > driver did a bit of pseudo asynchronous shenanigans on the synchronous > interface whereas the libusb synchronous interface does not. This will limit > the effective samplerate, but we're working on getting it resolved. > > As for any other issues - anything specifically you're seeing that is an error > and stopping the flowgraph? > > Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF and gnuradio?
OK, got it. I had to remove all osmocom files and completely reinstall gr-osmosdr, then I got rid of the hackRF, and the bladeRF was recognized. RX works fine, TX does work, but the modulation (plain FM) does not work, have to check with my USRP1 if this is a gnuradio or a bladeRF issue... The TCXO needs some alignment before it could be used for OpenBTS; but as this is not yet supported, this is not very urgent for now. Ralph. > -Original Message- > From: Brian Padalino [mailto:bpadal...@gmail.com] > Sent: Monday, 9 September, 2013 18:38 > To: Ralph A. Schmid, dk5ras > Cc: GNURadio Discussion List > Subject: Re: [Discuss-gnuradio] bladeRF and gnuradio? > > On Mon, Sep 9, 2013 at 6:43 AM, Ralph A. Schmid, dk5ras > wrote: > > Hi, > > > > Are there any out here with experience in getting bladeRF being usable > > with gnuradio/grc? So far I followed the usual steps, bladerf and > > gr-osmosdr compiled, but as documentation is being far from getting > > finished, I only reach the point of loading manually the FPGA image, > > nothing more :( Furthermore, with the latest changes in code bladeRF > > even does not compile any more... > > There was a recent change which added a call to libusb_get_version() which > doesn't exist in 1.0.9 of libusbx. So if you're running that, you should consider > updating to a newer version. I know it exists in > 1.0.12 and later. What version of libusbx are you using? Is it a possibility to > update? version 1.0.17 was recently released. > > https://github.com/libusbx/libusbx > > > I know the forum, but I prefer mailing lists like this - maybe there > > even is some active bladeRF list? > > We've gone through some restructuring of the library and where it's installed to > so if you've potentially got a stale version somewhere you're not expecting it to > be, that might cause issues. > > After moving to libusb instead of a straight kernel driver, the current work to go > on the driver right now is to interface with the asynchronous stream instead of > using the synchronous transmit and receive interface. The kernel driver did a bit > of pseudo asynchronous shenanigans on the synchronous interface whereas the > libusb synchronous interface does not. This will limit the effective samplerate, > but we're working on getting it resolved. > > As for any other issues - anything specifically you're seeing that is an error and > stopping the flowgraph? > > Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Questions on rx_ofdm example in GR 3.7.1
GR 3.7.1 gr-digital/examples/ofdm/rx_ofdm.grc 1. The OFDM Frame Equalizer block that is downstream from the Header Stream Virtual Source block has the Length Tag Key field set to length_tag_name, yet all other blocks on the diagram with that field are set to length_tag_key (which is the ID of a Variable block at the top of the diagram). Is that a mistake? If someone will confirm, I can file the bug. 2. When I try to run this flowgraph, modified for my target's custom source block, I get this error: FATAL: Missing a required length tag on port 0 at item #0 thread[thread-per-block[21]: ]: Missing length tag. Which led me to question (1) above. However, changing that block to match the others does not correct the runtime error. I found a couple of instances of the same error listed in (2) above in the mailing list, but no one replied to them. TIA, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How can I measure the RSSI with SBX board
Hi all, It is seen that the RSSI can be obtained by the read_aux_adc. But I am not sure if SBX board supports it or not. And how to specify the parameters: int which_side, int which_adc Any hints for this question? Thanks! -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I measure the RSSI with SBX board
Hi all, It is seen that the RSSI can be obtained by the read_aux_adc. But I am not sure if SBX board supports it or not. And how to specify the parameters: int which_side, int which_adc Any hints for this question? Thanks! -- Alex, /Dreams can come true – just believe./ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hardware RSSI is only available on some daughtercards, and is usually not accurate with respect to the final bandwidth of interest. Generally if you want to measure received power over your final bandwidth of interest, just insert a complex-to-mag**2 in the stream, and average that and decimate, and you'll have a good received power estimate. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] swig smart pointer inheritance issue
I'm converting some old blocks I wrote for ~3.5 gnuradio APIs to 3.7. I
have a block that
calculates the MER of an incoming signal - this block is a synchronous
decimator, and
the make function takes a constellation_sptr and decimation rate as input:
mer::sptr
mer::make(gr::digital::constellation_sptr mod_const, int decim_rate)
{
return gnuradio::get_initial_sptr (new mer_impl(mod_const,
decim_rate));
}
Note, I'm using gr_modtool to rough out all the details of building a module
template & associated build system scaffolding.
To test, I'm trying to pass in a constellation_rect_sptr, which is a
subclass
of the constellation class. The relevant code snippet is this:
def make_qam_constellation(pts):
return gr_qam.qam_constellation(constellation_points=pts,
differential=False)
When I pass in the constellation_rect_sptr, like this:
#!/usr/bin/python
from myqam import *
from qam_demod import mer
import gnuradio
c = make_qam_constellation(256)
print "type(c) = ", type(c)
print "type(c.base()) = ", type(c.base())
m = mer(c.base(), 4096)
the swig type checker is throwing out the c.base() input:
type(c) =
type(c.base()) =
Traceback (most recent call last):
File "/home/rick/Z/test_mer.py", line 9, in
m = mer(c.base(), 4096)
File
"/usr/local/lib/python2.7/dist-packages/qam_demod/qam_demod_swig.py", line
95, in make
return _qam_demod_swig.mer_make(*args, **kwargs)
TypeError: in method 'mer_make', argument 1 of type
'gr::digital::constellation_sptr' <
Just looking at the output from the two type() statements, the types seem
proper, though
the dotted notation vs '::' is interesting.
I notice that Ben Reynwar posted a very similar issue back in 2010. I had
the same problem
at the time, and resolved it via using the .base() method, apparently just
as he did. I suspect
this issue, while similar, may have something to do with 3.7's use of
namespaces, and some
of the complexity of SWIG's processing of namespace. I'm a definite SWIG
neophyte, and
perhaps I'm just missing something obvious, or at least I hope so.
Has anyone run into this issue and found a resolution? Looking at the .i
files in the distribution
didn't provide much in the way of inspiration as to how to solve the
problem.
Any pointers would be greatly appreciated.
Rick Spanbauer
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
