[Discuss-gnuradio] qam modulation blocks in GRC cannot work btw two computers?
Hi all, I'm playing with qam modulation and demodulation blocks using GRC. To begin with, I built a flow graph in one computer as follows: File source>packet encoder>qam mod->qam demod> packet decoder->file sink It worked well. The file sink can get what is in the file source. Then, I separated the flow graph in two computers connected to a USRP N210 each to test real environment performance: Computer1: File source>packet encoder>qam mod->usrp sink Computer2:usrp source> qam demod> packet decoder->file sink However, the file sink cannot get anything.(both with/without differential encoding ) To find out why, I pinted out the transmitted symbols in qam mod block in gnuradio/gnuradio-core/src/gengen/chunks_to_symbol_bc.cc in a txt file, and received symbols in qam demod block in gnuradio/gr-digital/lib/digital_constellation_recever_cb.cc in another txt file. Next, I demodulate those symbols based on closet Euclidean distance criterion by MATLAB, however,bit error rate turned to be around 0.5 (some shift is made to find the minimum ber ) which implies that received symbols and transmitted symbols are independent. AM I RIGHT ABOUT WHERE TO PRINTING OUT THE SYMBOLS? One thing to notice, when I changed qam blocks to OFDM blocks, the file sink can get what is transmitted properly even in the case of two computers. Therefore, I'm wondering if there is any problem with the qam blocks, like synchronization or channel equalization etc. that result in transmission failure. How can I solve it? MY PURPOSE IS TO GET correct symbols to demap to bits by myself. Sorry for sending such a long mail. Thank you very much for your help. Best, Jia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio transmission delay
On Thu, Jun 14, 2012 at 9:40 PM, Phelps Williams wrote: > I found an old discussion > http://lists.gnu.org/archive/html/discuss-gnuradio/2012-01/msg00104.html > on this exact issue... Per Ed Criscuolo's suggestion modifying > GR_FIXED_BUFFER_SIZE in > gnuradio-core/src/lib/runtime/gr_flat_flowgraph.cc worked! > > I'm a virtual noob here, but this issue is interesting. When there is actual UDP source, there is essentially no latency issue, right? Could the synthesized output with no input consumption be "confusing" the scheduler? When the scheduler calls forecast/work and there is no input, what happens? Do you call produce or produce_each directly after synthesizing output? If you set the environment variable GR_SCHEDULER to STS, do you see the same symptoms. Thanks for your analysis. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org services temporarily unavailable
Our hosting service, Amazon Web Services, is experiencing problems and the gnuradio.org server is offline. We do not have an ETA from them yet; I'll post here again when there is an update. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large Sample Spikes after Each Packet in tx_bursts Example
block ram^H^H^H^H^H^H^H^using SRL16's ;-) > > If you are seeing transients at the beginning of a burst, thats probably > the half band filters. They are implemented in block ram and dont clear > between bursts. > > -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large Sample Spikes after Each Packet in tx_bursts Example
> You can see the magnitude hovers over 30 which is good (noise hovers > around 5). But, as you can see, there are two spikes with suppressed > samples around it. These are exactly spaced 363 samples apart (this > changes as I change the samples per buffer at the transmitter). Does > anyone have an idea where this is coming from? I'm running out of > ideas of where to look to figure out the problem. Any ideas of what I > can do to remove it (even manually)? > > Regards, Jason T. > If you are seeing transients at the beginning of a burst, thats probably the half band filters. They are implemented in block ram and dont clear between bursts. On the other hand, if they are at the end, it might actually be that mini EOB packet. Its supposed to be a zero length packet but its actually sending a single sample (value zero). If this is the case, you might try setting EOB on the last packet actually with sample data. -josh > > > > ___ 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] Large Sample Spikes after Each Packet in tx_bursts Example
Hi All, (this might be a duplicate e-mail -- if so, sorry everyone!) I am trying to generate on-off traffic patterns with high timing accuracy, so I decided to use the tx_timed_samples and tx_bursts examples to do so. To start, I tried to understand the examples by using tx_bursts to send constant samples of 0.3+0.3j to the USRP_A to send across a wire to another USRP_B. Then, I used rx_samples_to_file on the receiver end to pick up the signal and store it into a .dat file using type "short." Lastly, I used the following guide to import the samples into matlab using the read_short_binary and split_vect functions provided in gnuradio/gnuradio-core/src/utils/: http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave After I did that, I combined the two columns from the output after split_vect to make a complex number. I then plotted the magnitude of the samples because all I care about is to see if there is a signal or not. Although that came out successful, I am running into these spikes of high sample magnitudes separated by the size of the samples per buffer (spb or samps_per_buff) which is automatically set to 363 samples (to fit in one ipv4 packet I presume). A picture of it can be seen by following the link below: http://imageshack.us/f/835/samplejumps.jpg/ You can see the magnitude hovers over 30 which is good (noise hovers around 5). But, as you can see, there are two spikes with suppressed samples around it. These are exactly spaced 363 samples apart (this changes as I change the samples per buffer at the transmitter). Does anyone have an idea where this is coming from? I'm running out of ideas of where to look to figure out the problem. Any ideas of what I can do to remove it (even manually)? Regards, Jason T. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio transmission delay
I found an old discussion http://lists.gnu.org/archive/html/discuss-gnuradio/2012-01/msg00104.html on this exact issue... Per Ed Criscuolo's suggestion modifying GR_FIXED_BUFFER_SIZE in gnuradio-core/src/lib/runtime/gr_flat_flowgraph.cc worked! Because this is universal to the build and not radio specific it does present performance issues at higher rates. Is it possible to modify this allocated block buffer size when building the flowgraph? On Thu, Jun 14, 2012 at 2:30 PM, Phelps Williams wrote: > I found that I can specify max_noutput_items when calling > top_block::start(). This however doesn't appear to do anything but > delay the onset of this large amount of latency as the various blocks > will still seem to request the maximum available. Setting this to the > exact rate I expect the radio to consume results in a steady flow of > UHD buffer underruns but enough data gets through for me to confirm > the latency has disappeared. > > My problem still remains however, I need to reduce the amount of > buffer each block is attempting to maintain. > > On Thu, Jun 14, 2012 at 2:15 PM, Phelps Williams wrote: >> I am not throttling the amount of data generated by my custom udp >> source. I am generating enough output to match noutput_items passed >> as the first argument to work(). My understanding is that >> noutput_items is the number of bytes the main event loop is requesting >> from my block for it to prevent an underrun. What establishes this >> demand? How is this noutput_items value generated? >> >> I notice in the first two calls to work() noutput_items == 32768. >> After those first two cycles it settles down to match the expected >> data rate. I think the correct solution is to change the total amount >> of buffering that is driving that demand rather than institute >> throttling in my core which will surely not be quite in sink with the >> UHD throttling source. >> >> Running the same test with a normal udp source results in the data >> being instantaneously modulated as I would expect. It seems clear >> that large buffers resulting in a large noutput_items is the source of >> this issue. >> >> Any idea on how to modify these per block buffer sizes? >> >> >> On Wed, Jun 13, 2012 at 5:58 PM, Josh Blum wrote: >>> >>> >>> On 06/13/2012 05:15 PM, Phelps Williams wrote: I have a simple bpsk transmitter setup with a custom udp source block which outputs a fixed pattern if no data is available from the socket. I have instrumented the block to indicate when data is read from the socket inside of work(). My radio looks like this: Custom UDP Source -> DPSK Mod (DBPSK, 10 samp/sym) -> Multiply Const (0.3) -> UHD: USRP Sink My sample rate is 1e6. I can tell from my instrumented UDP Source that udp traffic is handled by work and passed on almost immediately. However I can tell from both monitoring the spectrum and the receiver output on the other side that the data takes between 7 and 10 seconds before I see the expected output from the N200. I thought this could be improved by reducing the maximum socket buffer size (sudo sysctl -w net.core.wmem_max=500) but that didn't seem to make a difference. I went as low as wmem_max=1 with no difference in delay. My goal is to get the total delay to < 1sec. What else could be adding delay to my transmission path? Are there other buffers I can tweak? Where else should I be looking? >>> >>> Well the usrp only has a megabyte of buffering, as does the socket. At >>> that rate, you couldnt not be buffering more than half a second's worth >>> in the post-gnuradio part of the chain. >>> >>> I bet you have produced a lot of data all at once, filled up all of the >>> gnuradio buffering, and you are simply measuring the time it takes to >>> drain these buffers at a rate of 1Msps. >>> >>> If thats the case, you might pace your inputs. Or not transmit when you >>> have nothing to transmit, this lets things flush out and idle. >>> >>> -josh >>> >>> ___ >>> 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] Constallation receiver block in gnuradio companion
Hello, I want to transmit a continuous stream of data and obtain its synchronized version (before decoding) at the receiver using gnuradio companion. Following the generic_mod_demod.py, I have designed the transmit and receive path in the following way Tx:GLFSR source (producing +1 & -1) --> RRC filter --> USRP Sink Rx: USRP Source --> AGC2 --> FLL Band Edge --> Polyphase Clock Sync. I want to insert the *Constellation Receiver* block at the end of the Polyphase Clock Sync. I have two questions on this: 1. The Constellation Receiver block asks for "constellation object" and it accepts raw data type. What should I put here? I tried using the options 2 and bpsk but they did not work. 2. The Constellation_Receiver_cb accepts baseband complex streams and returns byte level data. Will it output the decoded data? I want the complex data, that has gone through the costas and M&M recovery block, but has not been decoded yet. How can I obtain that? Any suggestion will be appreciated. Thanks, Nazmul -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Debian package grc_setup_freedesktop problems
On 06/14/2012 03:30 PM, Mark Cottrell wrote: > I am trying to build a gnuradio debian package in ubuntu 12.04, but have > been having some issues with the postinst and prerm scripts trying to call > grc_setup_freedesktop. > > Looking at grc/freedesktop/CMakeLists.txt, grc_setup_freedesktop is only > installed if you have xdg-utils installed. However, the postinst and prerm > scripts attempt to run it whether xdg-utils is installed or not. The other Yea, I can see that being an issue. There probably should be a conditional check for the utility, or require the xdg-utils package as a dependency. > issue is that even when xdg-utils is installed, grc_setup_freedesktop is > installed to /usr/libexec, but the postinst and prerm scripts are looking > for it in /usr/local/libexec. Am I doing something wrong here or is the > cmake config slightly wrong for this stuff? > It looks in the install prefix, you should set -DCMAKE_INSTALL_PREFIX=/usr -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Debian package grc_setup_freedesktop problems
I am trying to build a gnuradio debian package in ubuntu 12.04, but have been having some issues with the postinst and prerm scripts trying to call grc_setup_freedesktop. Looking at grc/freedesktop/CMakeLists.txt, grc_setup_freedesktop is only installed if you have xdg-utils installed. However, the postinst and prerm scripts attempt to run it whether xdg-utils is installed or not. The other issue is that even when xdg-utils is installed, grc_setup_freedesktop is installed to /usr/libexec, but the postinst and prerm scripts are looking for it in /usr/local/libexec. Am I doing something wrong here or is the cmake config slightly wrong for this stuff? Thanks, Mark -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio transmission delay
I found that I can specify max_noutput_items when calling top_block::start(). This however doesn't appear to do anything but delay the onset of this large amount of latency as the various blocks will still seem to request the maximum available. Setting this to the exact rate I expect the radio to consume results in a steady flow of UHD buffer underruns but enough data gets through for me to confirm the latency has disappeared. My problem still remains however, I need to reduce the amount of buffer each block is attempting to maintain. On Thu, Jun 14, 2012 at 2:15 PM, Phelps Williams wrote: > I am not throttling the amount of data generated by my custom udp > source. I am generating enough output to match noutput_items passed > as the first argument to work(). My understanding is that > noutput_items is the number of bytes the main event loop is requesting > from my block for it to prevent an underrun. What establishes this > demand? How is this noutput_items value generated? > > I notice in the first two calls to work() noutput_items == 32768. > After those first two cycles it settles down to match the expected > data rate. I think the correct solution is to change the total amount > of buffering that is driving that demand rather than institute > throttling in my core which will surely not be quite in sink with the > UHD throttling source. > > Running the same test with a normal udp source results in the data > being instantaneously modulated as I would expect. It seems clear > that large buffers resulting in a large noutput_items is the source of > this issue. > > Any idea on how to modify these per block buffer sizes? > > > On Wed, Jun 13, 2012 at 5:58 PM, Josh Blum wrote: >> >> >> On 06/13/2012 05:15 PM, Phelps Williams wrote: >>> I have a simple bpsk transmitter setup with a custom udp source block >>> which outputs a fixed pattern if no data is available from the socket. >>> I have instrumented the block to indicate when data is read from the >>> socket inside of work(). >>> >>> My radio looks like this: >>> Custom UDP Source -> DPSK Mod (DBPSK, 10 samp/sym) -> Multiply Const >>> (0.3) -> UHD: USRP Sink >>> >>> My sample rate is 1e6. >>> >>> I can tell from my instrumented UDP Source that udp traffic is handled >>> by work and passed on almost immediately. However I can tell from >>> both monitoring the spectrum and the receiver output on the other side >>> that the data takes between 7 and 10 seconds before I see the expected >>> output from the N200. I thought this could be improved by reducing >>> the maximum socket buffer size (sudo sysctl -w >>> net.core.wmem_max=500) but that didn't seem to make a difference. >>> I went as low as wmem_max=1 with no difference in delay. My goal >>> is to get the total delay to < 1sec. >>> >>> What else could be adding delay to my transmission path? Are there >>> other buffers I can tweak? Where else should I be looking? >>> >> >> Well the usrp only has a megabyte of buffering, as does the socket. At >> that rate, you couldnt not be buffering more than half a second's worth >> in the post-gnuradio part of the chain. >> >> I bet you have produced a lot of data all at once, filled up all of the >> gnuradio buffering, and you are simply measuring the time it takes to >> drain these buffers at a rate of 1Msps. >> >> If thats the case, you might pace your inputs. Or not transmit when you >> have nothing to transmit, this lets things flush out and idle. >> >> -josh >> >> ___ >> 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] gnuradio transmission delay
I am not throttling the amount of data generated by my custom udp source. I am generating enough output to match noutput_items passed as the first argument to work(). My understanding is that noutput_items is the number of bytes the main event loop is requesting from my block for it to prevent an underrun. What establishes this demand? How is this noutput_items value generated? I notice in the first two calls to work() noutput_items == 32768. After those first two cycles it settles down to match the expected data rate. I think the correct solution is to change the total amount of buffering that is driving that demand rather than institute throttling in my core which will surely not be quite in sink with the UHD throttling source. Running the same test with a normal udp source results in the data being instantaneously modulated as I would expect. It seems clear that large buffers resulting in a large noutput_items is the source of this issue. Any idea on how to modify these per block buffer sizes? On Wed, Jun 13, 2012 at 5:58 PM, Josh Blum wrote: > > > On 06/13/2012 05:15 PM, Phelps Williams wrote: >> I have a simple bpsk transmitter setup with a custom udp source block >> which outputs a fixed pattern if no data is available from the socket. >> I have instrumented the block to indicate when data is read from the >> socket inside of work(). >> >> My radio looks like this: >> Custom UDP Source -> DPSK Mod (DBPSK, 10 samp/sym) -> Multiply Const >> (0.3) -> UHD: USRP Sink >> >> My sample rate is 1e6. >> >> I can tell from my instrumented UDP Source that udp traffic is handled >> by work and passed on almost immediately. However I can tell from >> both monitoring the spectrum and the receiver output on the other side >> that the data takes between 7 and 10 seconds before I see the expected >> output from the N200. I thought this could be improved by reducing >> the maximum socket buffer size (sudo sysctl -w >> net.core.wmem_max=500) but that didn't seem to make a difference. >> I went as low as wmem_max=1 with no difference in delay. My goal >> is to get the total delay to < 1sec. >> >> What else could be adding delay to my transmission path? Are there >> other buffers I can tweak? Where else should I be looking? >> > > Well the usrp only has a megabyte of buffering, as does the socket. At > that rate, you couldnt not be buffering more than half a second's worth > in the post-gnuradio part of the chain. > > I bet you have produced a lot of data all at once, filled up all of the > gnuradio buffering, and you are simply measuring the time it takes to > drain these buffers at a rate of 1Msps. > > If thats the case, you might pace your inputs. Or not transmit when you > have nothing to transmit, this lets things flush out and idle. > > -josh > > ___ > 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] tunnel.py destination host unreachable
Most likely you did not set the freq and gain properly. Unstable physical layer communications cause the ARP routing failure. Please use different frequencies for tx and rx. On Thu, Jun 14, 2012 at 1:51 PM, Weixian Zhou wrote: > I was testing with tunnel.py and following the instructions in README > located in gnuradio/gr-digital/examples/narrwoband. > I found that when I input* ifconfig gr0 192.168.200.1* on machine A, and > input* ifconfig gr0 192.168.200.2* on machine B at the same time, both > machines showed Tx and Rx packages. > But when I* ping 192.168.200.2* from machine A ( or *ping 192.168.200.1*from > machine B respectively), one window of machine A only showed Tx > packages and another window showed "Destination Host Unreachable". Machine > B showed both Rx/Tx packages. > It means that machine B can successfully received packages from machine A > but A failed to receive replied packages from machine B. It confused me > that the packages tx/rx were succeed before the ping. Anyone has idea? > > -- > Regards, > Weixian Zhou > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] if uhd_transmitter instantiated after receiver, TX works, otherwise RX works
Hi all, I'm observing some odd behavior that I can't seem to figure out. This is in (your favorite script) tunnel.py Here, self.sink is instantiated as a uhd_transmitter() and then self.source is a uhd_receiver(). Both are connected respectively to their part of the flow graph: https://github.com/gnychis/gnuradio-3.5.0-dmr/blob/b3b9be2380553706f152fbf4ffee6804aef8525c/gr-digital/examples/ofdm/tunnel.py#L54 The weird thing that I am observing is that whichever (uhd_transmitter or uhd_receiver) is instantiated _last_ is the part of the flow graph that operates properly. If the receiver is instantiated last, the receiver is able to receive packets (from another device) without a problem, but the transmitted packets are unable to be decoded by a standalone receiver (a different device running a receiver only). It is actually transmitting (we see power out of the antenna), but whatever it is transmitting is undecodable by our receiver. If you instantiate the transmitter before the receiver, then the transmitter works just fine and our standalone receiver can receive its packets. But, this breaks the uhd_receiver() running on the transceiving device. Has anyone else observed this? I have double checked that both are setting the sampling rates, independent of which is instantiated first (bandwidth is the same)... so I'm a little confused what would make the difference here. Thanks a bunch! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build errors on systems with non-English configuration
I've gotten not-very-good reports of build-gnuradio failing on systems that are set for languages other than English, and which contain pathname components with non-English characters. This appears to affect the underlying Gnu Radio build when it uses Python internally, and also to Gnu Radio applications that are run subsequently. I'd like to get good error reports from people who have experienced this, so we can determine if there's an easy fix that continues to allow the user to use a non-English system configuration. So, if you've experienced this situation on a non-English system, with pathnames (like you home directory) that contain non-ASCII-English characters, I'd like to know about it, and get good error logs. -Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tunnel.py destination host unreachable
I was testing with tunnel.py and following the instructions in README located in gnuradio/gr-digital/examples/narrwoband. I found that when I input* ifconfig gr0 192.168.200.1* on machine A, and input* ifconfig gr0 192.168.200.2* on machine B at the same time, both machines showed Tx and Rx packages. But when I* ping 192.168.200.2* from machine A ( or *ping 192.168.200.1*from machine B respectively), one window of machine A only showed Tx packages and another window showed "Destination Host Unreachable". Machine B showed both Rx/Tx packages. It means that machine B can successfully received packages from machine A but A failed to receive replied packages from machine B. It confused me that the packages tx/rx were succeed before the ping. Anyone has idea? -- Regards, Weixian Zhou ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] packets not being decoded in gnuradio 3.6 but was decoded in 3.4 and 3.5
Hello all,
I have figured out that the code gets stuck at line 275 of the code attached
thus;
msg = self.rcvd_pktq.delete_head()
Can anyone tell me which module is implementing the received message queue and
any ideas on why it will be empty apart from received frequency not aligned to
transmit frequency?
Henry
#
# Copyright 2005 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING. If not, write to
# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
#
# This is derived from gmsk2_pkt.py.
#
# Modified by: Thomas Schmid, Leslie Choong, Sanna Leidelof
#
import numpy
from gnuradio import gr, digital, gru
from gnuradio import ucla
import crc16
import gnuradio.gr.gr_threading as _threading
import ieee802_15_4
import struct
MAX_PKT_SIZE = 128
def make_ieee802_15_4_packet(FCF, seqNr, addressInfo, payload, pad_for_usrp=True, preambleLength=4, SFD=0xA7):
"""
Build a 802_15_4 packet
@param FCF: 2 bytes defining the type of frame.
@type FCF: string
@param seqNr: 1 byte sequence number.
@type seqNr: byte
@param addressInfo: 0 to 20 bytes of address information.
@type addressInfo: string
@param payload: The payload of the packet. The maximal size of the message
can not be larger than 128.
@type payload: string
@param pad_for_usrp: If we should add 0s at the end to pad for the USRP.
@type pad_for_usrp: boolean
@param preambleLength: Length of the preambble. Currently ignored.
@type preambleLength: int
@param SFD: Start of frame describtor. This is by default set to the IEEE 802.15.4 standard,
but can be changed if required.
@type SFD: byte
"""
if len(FCF) != 2:
raise ValueError, "len(FCF) must be equal to 2"
if seqNr > 255:
raise ValueError, "seqNr must be smaller than 255"
if len(addressInfo) > 20:
raise ValueError, "len(addressInfo) must be in [0, 20]"
if len(payload) > MAX_PKT_SIZE - 5 - len(addressInfo):
raise ValueError, "len(payload) must be in [0, %d]" %(MAX_PKT_SIZE)
SHR = struct.pack("B", 0, 0, 0, 0, SFD)
PHR = struct.pack("B", 3 + len(addressInfo) + len(payload) + 2)
MPDU = FCF + struct.pack("B", seqNr) + addressInfo + payload
crc = crc16.CRC16()
crc.update(MPDU)
FCS = struct.pack("H", crc.intchecksum())
pkt = ''.join((SHR, PHR, MPDU, FCS))
if pad_for_usrp:
# note that we have 16 samples which go over the USB for each bit
pkt = pkt + (_npadding_bytes(len(pkt), 8) * '\x00')+0*'\x00'
return pkt
def _npadding_bytes(pkt_byte_len, spb):
"""
Generate sufficient padding such that each packet ultimately ends
up being a multiple of 512 bytes when sent across the USB. We
send 4-byte samples across the USB (16-bit I and 16-bit Q), thus
we want to pad so that after modulation the resulting packet
is a multiple of 128 samples.
@param ptk_byte_len: len in bytes of packet, not including padding.
@param spb: samples per baud == samples per bit (1 bit / baud with GMSK)
@type spb: int
@returns number of bytes of padding to append.
"""
modulus = 128
byte_modulus = gru.lcm(modulus/8, spb) / spb
r = pkt_byte_len % byte_modulus
if r == 0:
return 0
return byte_modulus - r
def make_FCF(frameType=1, securityEnabled=0, framePending=0, acknowledgeRequest=0, intraPAN=0, destinationAddressingMode=0, sourceAddressingMode=0):
"""
Build the FCF for the 802_15_4 packet
"""
if frameType >= 2**3:
raise ValueError, "frametype must be < 8"
if securityEnabled >= 2**1:
raise ValueError, " must be < "
if framePending >= 2**1:
raise ValueError, " must be < "
if acknowledgeRequest >= 2**1:
raise ValueError, " must be < "
if intraPAN >= 2**1:
raise ValueError, " must be < "
if destinationAddressingMode >= 2**2:
raise ValueError, " must be < "
if sourceAddressingMode >= 2**2:
raise ValueError, " must be < "
return struct.pack("H", frameType
+ (securityEnabled << 3)
+ (framePending << 4)
+ (acknowledgeRequest << 5)
+ (intraPAN << 6)
+ (destinationAddressingMode << 10)
+ (sourceAddressingMode << 14))
Re: [Discuss-gnuradio] Fw: Fw: Error Is OpenBTS going to support USRP2?
Muhammad: Could you possibly move this discussion *OFF* the Gnu Radio mailing list? There are mailing lists dedicated to discussion OpenBTS problems, and this isn't one of them. OpenBTS doesn't even use Gnu Radio, so it's doubly inappropriate. -Marcus On 14 Jun 2012 14:00, Muhammad JUNAID wrote: > muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ killall transceiver > transceiver: no process found > > muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ps > PID TTY TIME CMD > 2383 pts/0 00:00:00 bash > 2560 pts/0 00:00:00 ps > muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ !. > ./OpenBTS > > OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc. > Release 2.6PUBLIC built Jun 11 2012 > "OpenBTS" is a trademark of Kestrel Signal Processing, Inc., > regsitered with the US Patent and Trademark Office. > > Contributors: > Kestrel Signal Processing, Inc.: > David Burgess, Harvind Samra, Raffi Sevlian, Roshan Baliga > GNU Radio: > Johnathan Corgan > Others: > Anne Kwong, Jacob Appelbaum, Joshua Lackey, Alon Levy > Alexander Chemeris, Alberto Escudero-Pascual > Incorporated GPL libraries and components: > libosip2, liportp2, readline > > This program comes with ABSOLUTELY NO WARRANTY. > > This is free software; you are welcome to redistribute it > under the terms of AGPLv3. > Please see the COPYING file in the source code for information > about the AGPLv3 license and recommended procedures for compliance > with the Affero requirements of that license. > > Use of this software may be subject to other legal restrictions, > including patent licsensing and radio spectrum licensing. > All users of this software are expected to comply with applicable > regulations and laws. > > Starting the system... > 1339480280.9026 ALARM 3074075328 OpenBTS.cpp:517:main: OpenBTS starting, ver 2.6PUBLIC build date Jun 11 2012 > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b > > 1339480280.9197 FORCE 3051112928 Logger.cpp:196:gLogInit: Setting initial global logging level to NOTICE > 1339480288.9073 ALARM 3065236336 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > 1339480291.9106 ALARM 3065236336 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > ^CReceived shutdown signal > Shutting down transceiver... > 1339480294.074994 3074075328: Handling signal 2 > Received shutdown signal > muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ clear > > muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ps > PID TTY TIME CMD > 2383 pts/0 00:00:00 bash > 2571 pts/0 00:00:00 ps > muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ !. > ./OpenBTS > > OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc. > Release 2.6PUBLIC built Jun 11 2012 > "OpenBTS" is a trademark of Kestrel Signal Processing, Inc., > regsitered with the US Patent and Trademark Office. > > Contributors: > Kestrel Signal Processing, Inc.: > David Burgess, Harvind Samra, Raffi Sevlian, Roshan Baliga > GNU Radio: > Johnathan Corgan > Others: > Anne Kwong, Jacob Appelbaum, Joshua Lackey, Alon Levy > Alexander Chemeris, Alberto Escudero-Pascual > Incorporated GPL libraries and components: > libosip2, liportp2, readline > > This program comes with ABSOLUTELY NO WARRANTY. > > This is free software; you are welcome to redistribute it > under the terms of AGPLv3. > Please see the COPYING file in the source code for information > about the AGPLv3 license and recommended procedures for compliance > with the Affero requirements of that license. > > Use of this software may be subject to other legal restrictions, > including patent licsensing and radio spectrum licensing. > All users of this software are expected to comply with applicable > regulations and laws. > > Starting the system... > 1339480301.6948 ALARM 3075037888 OpenBTS.cpp:517:main: OpenBTS starting, ver 2.6PUBLIC build date Jun 11 2012 > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b > > 1339480301.7112 FORCE 3050641888 Logger.cpp:196:gLogInit: Setting initial global logging level to NOTICE (What is this Error) > 1339480309.6988 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > 1339480312.7022 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > 1339480315.7053 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > 1339480318.7068 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > 1339480321.7101 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > 1339480324.7109 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. > 1339
[Discuss-gnuradio] Fw: Fw: Error Is OpenBTS going to support USRP2?
muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ killall transceiver transceiver: no process found muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ps PID TTY TIME CMD 2383 pts/0 00:00:00 bash 2560 pts/0 00:00:00 ps muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ !. ./OpenBTS OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc. Release 2.6PUBLIC built Jun 11 2012 "OpenBTS" is a trademark of Kestrel Signal Processing, Inc., regsitered with the US Patent and Trademark Office. Contributors: Kestrel Signal Processing, Inc.: David Burgess, Harvind Samra, Raffi Sevlian, Roshan Baliga GNU Radio: Johnathan Corgan Others: Anne Kwong, Jacob Appelbaum, Joshua Lackey, Alon Levy Alexander Chemeris, Alberto Escudero-Pascual Incorporated GPL libraries and components: libosip2, liportp2, readline This program comes with ABSOLUTELY NO WARRANTY. This is free software; you are welcome to redistribute it under the terms of AGPLv3. Please see the COPYING file in the source code for information about the AGPLv3 license and recommended procedures for compliance with the Affero requirements of that license. Use of this software may be subject to other legal restrictions, including patent licsensing and radio spectrum licensing. All users of this software are expected to comply with applicable regulations and laws. Starting the system... 1339480280.9026 ALARM 3074075328 OpenBTS.cpp:517:main: OpenBTS starting, ver 2.6PUBLIC build date Jun 11 2012 linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b 1339480280.9197 FORCE 3051112928 Logger.cpp:196:gLogInit: Setting initial global logging level to NOTICE 1339480288.9073 ALARM 3065236336 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480291.9106 ALARM 3065236336 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. ^CReceived shutdown signal Shutting down transceiver... 1339480294.074994 3074075328: Handling signal 2 Received shutdown signal muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ clear muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ ps PID TTY TIME CMD 2383 pts/0 00:00:00 bash 2571 pts/0 00:00:00 ps muhammadjunaid@ubuntu:~/OpenBts/openbts-uhd/public-trunk/apps$ !. ./OpenBTS OpenBTS, Copyright 2008-2010 Free Software Foundation, Inc. Release 2.6PUBLIC built Jun 11 2012 "OpenBTS" is a trademark of Kestrel Signal Processing, Inc., regsitered with the US Patent and Trademark Office. Contributors: Kestrel Signal Processing, Inc.: David Burgess, Harvind Samra, Raffi Sevlian, Roshan Baliga GNU Radio: Johnathan Corgan Others: Anne Kwong, Jacob Appelbaum, Joshua Lackey, Alon Levy Alexander Chemeris, Alberto Escudero-Pascual Incorporated GPL libraries and components: libosip2, liportp2, readline This program comes with ABSOLUTELY NO WARRANTY. This is free software; you are welcome to redistribute it under the terms of AGPLv3. Please see the COPYING file in the source code for information about the AGPLv3 license and recommended procedures for compliance with the Affero requirements of that license. Use of this software may be subject to other legal restrictions, including patent licsensing and radio spectrum licensing. All users of this software are expected to comply with applicable regulations and laws. Starting the system... 1339480301.6948 ALARM 3075037888 OpenBTS.cpp:517:main: OpenBTS starting, ver 2.6PUBLIC build date Jun 11 2012 linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.000-1156d9b 1339480301.7112 FORCE 3050641888 Logger.cpp:196:gLogInit: Setting initial global logging level to NOTICE (What is this Error) 1339480309.6988 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480312.7022 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480315.7053 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480318.7068 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480321.7101 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480324.7109 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480327.7142 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480330.7158 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480333.7189 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480336.7222 ALARM 3066198896 TRXManager.cpp:90:clockHandler: TRX clock interface timed out, assuming TRX is dead. 1339480336.7285 A
[Discuss-gnuradio] (no subject)
http://focusoneuropeantower.com/wp-content/themes/metro_10/body.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "QAM Demod" error in GRC
This is a bug. In file gr-digital/grc/digital_qa_demod.xml the line gray_coded = $gray_coded should be changed to mod_code = $mod_code On Wed, Jun 13, 2012 at 7:56 AM, jiajue ou wrote: > Hi all, > > I’m using GRC and the simple flow graph(1) at receiver is as follows: > > Usrp source>qam demod>file sink > > > > It works fine at first. However, when I tried to execute another similar > flow graph(2) that was built before UPDATING GNURADIO from 3.5.0 to 3.6.0. > an error occurs: > > > > Generating:”/home/azalea/exp/top_block.py” > > > > executing:”/home/azalea/exp/top_block.py” > > > > File :”/home/azalea/exp/top_block.py”, line 79 > > Self.digital_qam_demod_0=---> > > > > Syntax error: invalid syntax > > (I looked up the python file, line 79 and line 80 are: > > Self.digital_qam_demod_0=---> > > Cannot find ‘gray_coded’: digital.qam.qam_demod( > > ) > > Then, I return to the mentioned flow graph(1), same error again. > > I also tried to start a new flow graph or make/make install gnuradio, but in > vain. > > I’m just confused. The flow graph(1) worked well even after updating > gnuradio. After that and before the error I didn’t remove or modify any > module in gnuradio. > > Thanks a lot! > > > > Best, > > Jia > > > > > > > ___ > 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] Conference Details and Updates
Hi everyone! Just a few quick items about the conference. First, the big news is that we have been awarded a grant from the National Science Foundation to help support students attending the conference. Specifically, it is to cover travel costs (planes, trains, and automobiles) for -roughly- a dozen students to get to the conference. We are working on details for applicants, but I wanted to let you all know now so you can start to plan accordingly, especially if the cost getting to the conference was going to inhibit your ability to come and therefore participate/present. More details to follow. Don't forget that abstracts/proposals for presentations are due on June 29th. It's a short, simple form to fill out: http://www.trondeau.com/grc2012-call-for-presentations/ Please also feel free to distribute information to help us promote the conference. Feel free to use this flyer: http://www.trondeau.com/storage/grcon2012_flyer.pdf Remember, all information is or will be available at the main conference website: http://www.trondeau.com/gnu-radio-conference-2012/ Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make check errors in release 3.5.0
On Thu, Jun 14, 2012 at 1:40 AM, azalea au wrote: > Hi all, > I'm having "make check" errors when installing gnuradio 3.5.0: > > make[7]: Entering directory > `/home/azalea/Desktop/gnuradio-3.5.0/gr-trellis/src/python' > Traceback (most recent call last): > File "./qa_trellis.py", line 32, in > import digital_swig > ImportError: No module named digital_swig > FAIL: run_tests > == > 1 of 1 test failed > == > > Could you please give me any suggestions on how to fix it? > > Many thanks, > Jia Upgrade to 3.5.3. That was a bug, I think, that should be fixed in the later releases of the 3.5 series. There is no reason not to update to the latest version of an API release. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
