[Discuss-gnuradio] shift param in FFT block in GRC
When I add a FFT block in the GRC (gr_fft_vxx if I understand things correctly) I am offered a boolean parameter 'shift'. When I attempt to discern the code, there is a comment: // apply a fft shift on the data - for the fwd FFT and // apply an ifft shift on the data - for reverse. What does this parameter do? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NEC uPD720200 and USRP B100
Hi Ben, Hi Nick, yes, without changing anything, when the B100 is connected to a "normal" 2.0 port (whether integrated on the motherboard or on a PCI card) it is found correctly. here are lspci, lsusb outputs and kernel info regards vincenzo # lspci -v 00:00.0 Host bridge: Intel Corporation Sandy Bridge DRAM Controller (rev 09) Subsystem: Hewlett-Packard Company Device 1495 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information: Len=0c 00:01.0 PCI bridge: Intel Corporation Sandy Bridge PCI Express Root Port (rev 09) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: f900-faff Prefetchable memory behind bridge: f000-f5ff Capabilities: [88] Subsystem: Hewlett-Packard Company Device 1495 Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [a0] Express Root Port (Slot+), MSI 00 Capabilities: [100] Virtual Channel Capabilities: [140] Root Complex Link Kernel driver in use: pcieport 00:16.0 Communication controller: Intel Corporation Cougar Point HECI Controller #1 (rev 04) Subsystem: Hewlett-Packard Company Device 1495 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at fb12a000 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+ 00:16.3 Serial controller: Intel Corporation Cougar Point KT Controller (rev 04) (prog-if 02 [16550]) Subsystem: Hewlett-Packard Company Device 1495 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17 I/O ports at f0a0 [size=8] Memory at fb129000 (32-bit, non-prefetchable) [size=4K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel driver in use: serial 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) Subsystem: Hewlett-Packard Company Device 1495 Flags: bus master, fast devsel, latency 0, IRQ 51 Memory at fb10 (32-bit, non-prefetchable) [size=128K] Memory at fb128000 (32-bit, non-prefetchable) [size=4K] I/O ports at f040 [size=32] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [e0] PCI Advanced Features Kernel driver in use: e1000e Kernel modules: e1000e 00:1a.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: Hewlett-Packard Company Device 1495 Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at fb127000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci_hcd 00:1b.0 Audio device: Intel Corporation Cougar Point High Definition Audio Controller (rev 04) Subsystem: Hewlett-Packard Company Device 1495 Flags: bus master, fast devsel, latency 0, IRQ 52 Memory at fb12 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [130] Root Complex Link Kernel driver in use: snd_hda_intel 03:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fb00 (64-bit, non-prefetchable) [size=8K] Capabilities: [50] Power Management version 3 Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ Capabilities: [90] MSI-X: Enable+ Count=8 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff Capabilities: [150] #18 Kernel driver in use: xhci_hcd 00:1c.0 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 1 (rev b4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Capabilities: [40] Express Root Port (Slot+), MSI 00 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [90] Subsystem: Hewlett-Packard Company Device 1495 Capabilities: [a0] Power Manage
Re: [Discuss-gnuradio] shift param in FFT block in GRC
On Tue, Jun 12, 2012 at 08:19:21PM +1200, John Shields wrote: > When I add a FFT block in the GRC (gr_fft_vxx if I understand things > correctly) I am offered a boolean parameter 'shift'. When I attempt > to discern the code, there is a comment: > >// apply a fft shift on the data - for the fwd FFT and >// apply an ifft shift on the data - for reverse. > > What does this parameter do? It applies an FFT shift on the data for the forward FFT and an IFFT shift on the data for reverse FFT. Did that help? If not, a quick Google search for 'fft shift' explains that this moves the DC carrier to the centre of the spectrum (instead of the far left). MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpfaebQQHpiV.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NEC uPD720200 and USRP B100
some additional info. this is weird: although everything is fine while using 2.0 controllers, when I use the 3.0 expansion card and the b100 gets cold-started (i mean it is not yet loaded with firmware) i get this: dc7900 utils]# ./uhd_find_devices linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2); Boost_104700; UHD_003.004.000-1-gea19de0b -- Loading firmware image: /home/soft-rf/Desktop/UHD-Mirror/UHD-images-003.004.000-f500b92/share/uhd/images/usrp_b100_fw.ihx... done No UHD Devices Found if it already has the firmware loaded, I just get: @dc7900 utils]# ./uhd_find_devices linux; GNU C++ version 4.6.3 20120306 (Red Hat 4.6.3-2); Boost_104700; UHD_003.004.000-1-gea19de0b No UHD Devices Found this also happens on a Fedora16 x86_64 machine, and standard USB-memories work well when connected to the expansion board with the NEC 3.0 controller. any clues? regards vince 2012/6/11 Ben Hilburn : > Vincenzo - > > I have the exact same USB 3.0 controller: > 0d:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller > (rev 04) > > ... on this Thinkpad 420s, and I have no issues using the B100. > > Like Nick said, can you provide the output of: > > $ sudo lspci -v > $ uname -a > > Also, without making any changes, if you plug the B100 into a USB2.0 port, > it works fine? > > Cheers, > Ben > > On Mon, Jun 11, 2012 at 10:39 AM, Nick Foster wrote: >> >> On Mon, Jun 11, 2012 at 10:28 AM, Vincenzo Pellegrini >> wrote: >>> >>> Hi Nick and everybody, >>> >>> today I tried to access my B100 via the NEC Corporation uPD720200 >>> usb 3.0 controller that you quoted in this message: >>> >>> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg35877.html >>> >>> installed on a PCIe USB 3.0 expansion card. >>> >>> UHD could not find devices (./uhd_find_devices) >>> >>> whereas it actually can find my B100 both if it is connected to the USB >>> 2.0 >>> controller on-board the PC motherboard and if it's connected to a PCI >>> USB 2.0 expansion card. >> >> >> Mine's onboard, although it really shouldn't make a difference. Can you >> paste the output of lsusb and lspci -v? >> >> --n >> >>> >>> >>> do you have any search hints for this, is your uPD720200 on-board the >>> motherboard or on a separate device? >>> >>> thanks and regards >>> >>> vincenzo >>> >>> >>> -- >>> Vincenzo Pellegrini >>> http://www.youtube.com/user/wwvince1 >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > -- Vincenzo Pellegrini http://www.youtube.com/user/wwvince1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Screencasts on gnuradio.org
Hi everyone, I've added Sumit's and Balint's GNU Radio videos to the GNU Radio wiki: http://gnuradio.org/redmine/projects/gnuradio/wiki/ExternalDocumentation These videos are really nice and obviously a lot of work was put into them; I suggest checking them out and would like to encourage anyone who has made additional docs or similar to put links to their code or documentation into the wiki. The same goes for presentations or papers. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpjnBaknyZHZ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] b100 error
I think the problem is related to the host code, because i have an UBUNTU installations where the SID message appears less times and b100 hardware no need a reboot to working correctly. In GENTOO i have this version of the UHD: linux; GNU C++ version 4.6.3; Boost_104900; UHD_003.004.002-137-g49d4f8e4 cat /usr/share/uhd/images/003.004.001.tag 003.004.001-109-g6ca39ad9 Wed Apr 25 19:13:06 PDT 2012 md5sum /usr/share/uhd/images/usrp_b100_fpga.bin /usr/share/uhd/images/usrp_b100_fw.ihx 4016e7efd022cb9f7c7be7ecfcd89d16 /usr/share/uhd/images/usrp_b100_fpga.bin 622e25ca14ac6bd4fbb518b32dbf58d6 /usr/share/uhd/images/usrp_b100_fw.ihx I have my B100 with SBX about one week and in GENTOO freezes constantly but in UBUNTU this happens less times. I will try to compile UHD host code with the same "BOOST" version of ubuntu in my gentoo to view if the problem persisting and then inform the result. Best regards, Jose Quaresma 2012/6/11 Josh Blum : > Hey guys, > > I'm looking into this. I really thought I squashed this bug, so please > make sure you have the latest image. If you are using the master branch > this would be: > > md5sum /usr/local/share/uhd/images/usrp_b100_fpga.bin > 4016e7efd022cb9f7c7be7ecfcd89d16 > /usr/local/share/uhd/images/usrp_b100_fpga.bin > > -josh > > On 06/11/2012 10:51 AM, sumitstop wrote: >> >> Hi Josh, >> Did you update the code :-) >> >> Josh Blum-3 wrote: >>> >>> the SID keeps changing although .. While I saw I similar problem earlier in this thread(http://old.nabble.com/uhd-b100-problems-td33345827.html#a33345827 ) but I am afraid that the problem still persists :( my UHD version is uhd-images_003.004.001-109-g6ca39ad9 >>> >>> This is an RX issue. I really swear I had nailed this down a while ago. >>> Do you mind trying an update? >>> >>> It looks like you are using the master branch. >>> I would update the host code and grab images here: >>> http://files.ettus.com/binaries/master_images/ >>> >>> -josh >>> Thanks - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> - >> Sumit Kr. >> Research Assistant >> Communication Research center >> IIIT Hyderabad >> India -- Cumprimentos, José Quaresma ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] packets not being decoded in gnuradio 3.6 but was decoded in 3.4 and 3.5
I have the attached codes which were working and the uhd_cc2420_rxtest.py was
decoding packets albeit with high error rate. I upgraded to gnuradio 3.6 and
had to change a few commands like changing packet_utils to digital and
clock_clock_recovery_mm_ff to digital_clock_recovery_mm_ff.
Both codes are executing without errors and I can see that packets are being
sent using an independent spectrum analyser. Yet I am not receiving any packets
from uhd_cc2420_rxtest.py.
Is there any change that I need to do to at least get a few packets
irrespective of the error rate?
H.E. Baidoo-Williams
GRA, University of Iowa
#!/usr/bin/env python
#
# Transmitter of IEEE 802.15.4 RADIO Packets.
#
# Modified by: Thomas Schmid, Sanna Leidelof, Kresimir Dabcevic
#
from gnuradio import gr, eng_notation, uhd
from gnuradio import ucla
from gnuradio.ucla_blks import ieee802_15_4_pkt
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import math, struct, time
class transmit_path(gr.top_block):
def __init__(self, options):
gr.top_block.__init__(self)
self.normal_gain = 8000
self.u = uhd.usrp_sink(device_addr=options.address,
io_type=uhd.io_type.COMPLEX_FLOAT32,
num_channels=1)
self.u.set_clock_config(uhd.clock_config.internal(), uhd.ALL_MBOARDS)
u = self.u
self._data_rate = 200
self._spb = 2
# Set and print sampling rate
#self._samp_rate = 20
self._samp_rate = 200
self.u.set_samp_rate(self._samp_rate)
input_rate = self.u.get_samp_rate()
print "Sampling rate: %d" %(input_rate)
# Set and print center frequency
self.u.set_center_freq(options.cordic_freq)
frekva = self.u.get_center_freq()
print "Center frequency: %d" %(frekva)
# transmitter
self.packet_transmitter = ieee802_15_4_pkt.ieee802_15_4_mod_pkts(self, spb=self._spb, msgq_limit=2)
self.gain = gr.multiply_const_cc (self.normal_gain)
self.connect(self.packet_transmitter, self.gain, self.u)
self.filesink = gr.file_sink(gr.sizeof_gr_complex, 'tx_test.dat')
self.connect(self.gain, self.filesink)
def set_gain(self, gain):
self.gain = gain
self.u.set_gain(gain, 0)
def send_pkt(self, payload='', eof=False):
return self.packet_transmitter.send_pkt(0xe5, struct.pack("", 0x, 0x, 0x10, 0x10), payload, eof)
def main ():
parser = OptionParser (option_class=eng_option)
parser.add_option("-a", "--address", type="string", default="addr=192.168.10.2",
help="Address of UHD device, [default=%default]")
parser.add_option ("-c", "--cordic-freq", type="eng_float", default=247500,
help="set Tx cordic frequency to FREQ", metavar="FREQ")
parser.add_option ("-r", "--data-rate", type="eng_float", default=200)
parser.add_option ("-f", "--filename", type="string",
default="rx.dat", help="write data to FILENAME")
parser.add_option ("-g", "--gain", type="eng_float", default=0,
help="set Rx PGA gain in dB [0,20]")
parser.add_option ("-N", "--no-gui", action="store_true", default=False)
(options, args) = parser.parse_args ()
tb = transmit_path(options)
tb.start()
for i in range(1000):
print "send message %d:"%(i+1,)
tb.send_pkt(payload=struct.pack('9B', 0x1, 0x80, 0x80, 0xff, 0xff, 0x10, 0x0, 0x20, 0x0))
#this is an other example packet we could send.
#tb.send_pkt(struct.pack('BBB', 0x1, 0x8d, 0x8d, 0xff, 0xff, 0xbd, 0x0, 0x22, 0x12, 0xbd, 0x0, 0x1, 0x0, 0xff, 0xff, 0x8e, 0xff, 0xff, 0x0, 0x3, 0x3, 0xbd, 0x0, 0x1, 0x0, 0x0, 0x0))
#print "Payload: " + str(map(hex, map(ord, payload)))
time.sleep(0.1)
# tb.wait()
if __name__ == '__main__':
# insert this in your test code...
#import os
#print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
#raw_input ('Press Enter to continue: ')
main ()
#!/usr/bin/env python
#
# Decoder of IEEE 802.15.4 RADIO Packets.
#
# Modified by: Thomas Schmid, Leslie Choong, Mikhail Tadjikov, Kresimir Dabcevic
#
from gnuradio import gr, eng_notation, uhd
from gnuradio.ucla_blks import ieee802_15_4_pkt
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import struct, sys, time, math
n2s = eng_notation.num_to_str
class stats(object):
def __init__(self):
self.npkts = 0
self.nright = 0
class oqpsk_rx_graph (gr.top_block):
def __init__(self, options, rx_callback):
gr.top_block.__init__(self)
print "cordic_freq = %s" % (eng_notation.num_to_str (options.cordic_freq))
#
Re: [Discuss-gnuradio] Registering Custom Data Types
On 06/11/2012 09:11 PM, Ryan Wolfarth wrote: > Hi again, > > The "device streaming" documentation mentions that users may register their > own data types and converter routines. I'd like to implement a converter > that takes the sc8 data type from the wire and converts to an sc8 host data > type. It looks like Josh added this functionality in November of last > year. Could I make use of this converter in rx_samples_to_file? If so, > can you provide an example of general converter use? This is also cited as > "todo" in the "Device streaming" documentation. > :-) If you take a look at lib/convert/* its actually full of examples. Basically, you can register any arbitrary conversion function with some identifiers and priority. FWIW, I pushed a converter for sc8 to/from sc8 host to master just now, since I think thats all you need. -josh > Thank you, > Ryan > > Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server. > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis convolutional coder FSM
Clemens, puncturing is not part of the FSM class. You can implement it as a simple memoryless device: eg, if i want to puncture every third bit, then the device accepts 3bits as inputs and outputs the first two. If you can give me more details on what exactly you want to implement i may be able to help you out. Similraly, if you let me know which part of the FSM/trellis documentation is hard to read, hopefully i will be able to help. regards, Achilleas Hi, I'm working on a modulator using a punctured (non-recursive) convolutional coder based on a 1/2 rate mother code with length 7. However I find the documentation of gr-trellis pretty hard to read, I don't really understand how punctuation should actually be implemented. Are there any additional documents or papers on designing the FSM of a convolutional coder? Thanks, Clemens ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Registering Custom Data Types
Excellent, much appreciated! -Ryan On Tue, Jun 12, 2012 at 12:51 PM, Josh Blum wrote: > > > On 06/11/2012 09:11 PM, Ryan Wolfarth wrote: > > Hi again, > > > > The "device streaming" documentation mentions that users may register > their > > own data types and converter routines. I'd like to implement a converter > > that takes the sc8 data type from the wire and converts to an sc8 host > data > > type. It looks like Josh added this functionality in November of last > > year. Could I make use of this converter in rx_samples_to_file? If so, > > can you provide an example of general converter use? This is also cited > as > > "todo" in the "Device streaming" documentation. > > > > :-) > > If you take a look at lib/convert/* its actually full of examples. > Basically, you can register any arbitrary conversion function with some > identifiers and priority. > > FWIW, I pushed a converter for sc8 to/from sc8 host to master just now, > since I think thats all you need. > > -josh > > > Thank you, > > Ryan > > > > Setup: Dell PowerEdge R510 running UHD 3.4.2 on Ubuntu 12.04 server. > > > > > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] shift param in FFT block in GRC
On 12/06/12 21:00, Martin Braun wrote: On Tue, Jun 12, 2012 at 08:19:21PM +1200, John Shields wrote: When I add a FFT block in the GRC (gr_fft_vxx if I understand things correctly) I am offered a boolean parameter 'shift'. When I attempt to discern the code, there is a comment: // apply a fft shift on the data - for the fwd FFT and // apply an ifft shift on the data - for reverse. What does this parameter do? It applies an FFT shift on the data for the forward FFT and an IFFT shift on the data for reverse FFT. Did that help? If not, a quick Google search for 'fft shift' explains that this moves the DC carrier to the centre of the spectrum (instead of the far left). MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Thanks Martin, Yes it does help. I had seen some 'funky stuff' in Marcus' Simple_RA and wondered why. Now I think I know. Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
