Re: [Discuss-gnuradio] Can't open GNURadio Companion as root?
This is just you not forwarding the user environment to the root process you're starting. Hence, GRC doesn't know how to talk to your graphical interface. That is standard Unix/X11 – and personally: that's good that way; you'd really only want to execute as little software as possible as root. As the software maintainer: I can attest that there's literally no good reason to run a software design tool such as GRC as root. Even if your flow graph for some reason needs root privileges for execution, the appropriate way of dealing with that would be generating the python file and then executing that as root (e.g. using sudo). In all likelihood, however, your flow graph doesn't actually need root privileges for what you're trying to do, and there's a more elegant way of making things work[1]! Maybe you could tell us why you need to, and we'd come up with an appropriate workaround. Best regards, Marcus [1] http://xyproblem.info On Sat, 2019-06-08 at 14:00 -0400, Eamon Heaney wrote: > Hey all, I'm getting a gtk error when I try to run gnuradio-companion > as root. Error message below. > > File "/usr/bin/gnuradio-companion", line 97, in > check_gtk() > File "/usr/bin/gnuradio-companion", line 64, in check_gtk > die(err, "Failed to initialize GTK. If you are running over ssh, > " > File "/usr/bin/gnuradio-companion", line 42, in die > import gtk > File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", > line 69, in > _init() > File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", > line 57, in _init > warnings.warn(str(e), _gtk.Warning) > gtk.GtkWarning: could not open display > > > The instructions on the github repo I'm working from indicate that I > should be running this as root, so I do think it's necessary. Any > ideas on how to fix this? > > > > ___ > 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] Can't open GNURadio Companion as root?
On 06/08/2019 02:00 PM, Eamon Heaney wrote: > Hey all, I'm getting a gtk error when I try to run gnuradio-companion as > root. Error message below. > > File "/usr/bin/gnuradio-companion", line 97, in > check_gtk() > File "/usr/bin/gnuradio-companion", line 64, in check_gtk > die(err, "Failed to initialize GTK. If you are running over ssh, " > File "/usr/bin/gnuradio-companion", line 42, in die > import gtk > File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line > 69, in > _init() > File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line > 57, in _init > warnings.warn(str(e), _gtk.Warning) > gtk.GtkWarning: could not open display > > > The instructions on the github repo I'm working from indicate that I should > be running this as root, so I do think it's necessary. Any ideas on how to > fix this? That sounds like a terrible idea (running gnuradio-companion as root). Where is this github repo? That said, I've seen it run as root on embedded boards so there nothing in the code to stop it. The could not open display message suggest you are trying to run over ssh without using X forwarding. Philip > > > > > > ___ > 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] Can't open GNURadio Companion as root?
Hey all, I'm getting a gtk error when I try to run gnuradio-companion as root. Error message below. File "/usr/bin/gnuradio-companion", line 97, in check_gtk() File "/usr/bin/gnuradio-companion", line 64, in check_gtk die(err, "Failed to initialize GTK. If you are running over ssh, " File "/usr/bin/gnuradio-companion", line 42, in die import gtk File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 69, in _init() File "/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py", line 57, in _init warnings.warn(str(e), _gtk.Warning) gtk.GtkWarning: could not open display The instructions on the github repo I'm working from indicate that I should be running this as root, so I do think it's necessary. Any ideas on how to fix this? -- Eamon Heaney *Fleet Commander* *President, Model UN at Virginia Tech* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM
Hello,I am trying to change the OFDM_tx_rx payload modulation by a custom 64kQAM,I implemented the block in several ways, it works fine but I had issues using it with OFDM_tx_rx:/*1- sync:taking a short item and produce a complex itemmodulation:**signatures:***64kQAM_code_impl::64kQAM_code_impl( ) : gr::sync_block("64kQAM_code", gr::io_signature::make(1, 1, sizeof(unsigned short int)), gr::io_signature::make(1, 1, sizeof(gr_complex))) {}**work function:***int 64kQAM_code_impl::work(int noutput_items, gr_vector_const_void_star _items, gr_vector_void_star _items) { const unsigned short int *in = (const unsigned short int *) input_items[0]; gr_complex *out = (gr_complex *) output_items[0]; for(int i = 0;i out[i].real((float(in[i]&0x00FF)-128.0)*level); out[i].imag((float((in[i]&0xFF00)>>8)-128.0)*level); } return noutput_items; }demodulation:taking a complex item and produce a short item**signature:*** 64kQAM_decode_impl::64kQAM_decode_impl( ) : gr::sync_block("64kQAM_decode", gr::io_signature::make(1, 1, sizeof(gr_complex)), gr::io_signature::make(1, 1, sizeof(unsigned short int))) {}**work function:*** int 64kQAM_decode_impl::work(int noutput_items, gr_vector_const_void_star _items, gr_vector_void_star _items) { const gr_complex *in = (const gr_complex *) input_items[0]; unsigned short int *out = (unsigned short int *) output_items[0]; unsigned short int tmp; for(int i =0; i { tmp = int((in[i].imag()/level)+128.5); tmp = (tmp<<8) | int((in[i].real()/level)+128.5); out[i] = tmp; } return noutput_items; } Problem: -I got the write samples in the QT time sink, and in the file sink, but the transmission stops after some amount of data has been transmitted (repeat set to yes), the packet_len tag is displayed/*2- interpolator/decimator:***modulation: takes 2 bytes and produce one complex itemdemodulation:takes one complex item and produce 2 bytes.my decimaition and interpolation factor is 2 Problems: same as 1. /**2-general:**modulation:taking two byte items and produce a complex item void 64kQAM_code_impl::forecast (int noutput_items, gr_vector_int _items_required) { ninput_items_required[0] = noutput_items*2; } int 64kQAM_code_impl::general_work (int noutput_items, gr_vector_int _items, gr_vector_const_void_star _items, gr_vector_void_star _items) { const unsigned char *in = (const unsigned char*) input_items[0]; gr_complex *out = (gr_complex *) output_items[0]; for(int i = 0;i { out[i].real(in[2*i]*level); out[i].imag(in[2*i+1]*level); } consume_each (noutput_items); // Tell runtime system how many output items we produced. return noutput_items; }demodulation: void 64kQAM_decode::forecast (int noutput_items, gr_vector_int _items_required) { ninput_items_required[0] = noutput_items/2; } int 64kQAM_decode_impl::general_work (int noutput_items, gr_vector_int _items, gr_vector_const_void_star _items, gr_vector_void_star _items) { const gr_complex *in = (const gr_complex *) input_items[0]; unsigned char *out = (unsigned char *) output_items[0]; for(int i =0; i { out[2*i]=in[i].real()/level; out[2*i+1] =in[i].imag()/level; } consume_each (noutput_items); // Tell runtime system how many output items we produced. return noutput_items*2; }taking a complex item and produce two byte items problem: -It writes quickly a large amount of data to the disk. -In the QT display I get the correct samples but in a sink file I got additionnal data generally this type (^@^@), also packet_len tag is not displayed on the QT time GUI.4-trying with tagged stream block, tagged stream mux block gives an error : " Buffer too small for min_noutput_items" Thank you. ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Determining distance from OFDM signals
Hi Qasim, a) it's so nice to see you drop in here from time to time :) b) that's true! But reality is even better; the back and forth exchange isn't strictly necessary. c) I finally find the time to write down what I wanted to write. ## First, agreeing with you: One can basically emulate the principle of a correlation-based radar by making the other end "reflect" info with a known delay. All one needs to do is ensure that a reply packet is sent a *fixed* amount of time after a packet is received. That interval doesn't have to be necessarily short, just known. From the reply, and its knowledge of the original transmission's time, the original transmitter can deduce the double of the one-way transmission latency; that can, given enough bandwidth, SNR and processing gain, be enough to resolve integer wavelength ambiguities. In practice, passband bandwidth will often be the fundamentally limiting factor. With the phase estimate done on the reply, and info on the phase estimate done by the replying party, both sides would have relative phase CSI, and the original transmitter a distance estimate. ## Then, disagreeing with you (just a little bit): Now, while the above works with any transmission that allows phase recovery, OFDM frames have the advantage of allowing a two-dimensional DFT to be used to estimate range through the time-shift property of the DFT. However, that requires knowledge of the transmitted symbols at the receiver – which luckily is recoverable in case of successful OFDM communication¹. In fact, that's how OFDM radar works very nicely; it's explained in [1]. Imagine a receiver with knowledge of the transmitted signal. While lacking a common time base, a receiver can infer distance from the development of the phases of entries of a sufficiently large (in both number of OFDM symbols and number of subcarriers) OFDM frame. The idea is simple: assume you know the symbols at the transmitter. The speed-of-light induced delay is constant across all subcarriers. The resulting phase shift, thus, is proportional to the subcarrier frequency, and hence the subcarrier number. Therefor, when you observe linear channel phase change over subcarrier, you can get a distance estimate. Phase being a linear function of index implies we're dealing with a sinusoid – and a DFT in subcarrier direction will give us a range plot. Same idea for Doppler, but with phase on the same subcarrier, but for consecutive and hence constant-interval OFDM symbols; do another DFT for each subcarrier across OFDM symbols, and get a doppler plot. Overall: Write down your received OFDM symbols as column vectors of a matrix, point-wise divide by the transmitted symbols (normalize amplitude if helpful); the result is a matrix full of complex numbers with the channel phase for each subcarrier at each symbol time. Do an appropriate 2D-DFT, get a range/doppler plane "image". Find the peak; use clever interpolation / post-processing to increase resolution and/or reduce estimate variance. Cheers, Marcus ¹ (unless someone inexplicably decided to use differential PSK on the subcarriers – looking at DAB, there.) [1] https://publikationen.bibliothek.kit.edu/138892 On Sat, 2019-06-08 at 14:21 +1000, Qasim Chaudhari wrote: > Phase information is preserved whether the Rx architecture is zero-IF > or not. The OP I guess is already using a back and forth exchange > between two USRPs, from which the distance information can be > extracted in case of OFDM signals. > > Cheers, > Qasim > > > On Sat, Jun 8, 2019 at 4:05 AM > wrote: > > Send Discuss-gnuradio mailing list submissions to > > discuss-gnuradio@gnu.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > or, via email, send a message with subject or body 'help' to > > discuss-gnuradio-requ...@gnu.org > > > > You can reach the person managing the list at > > discuss-gnuradio-ow...@gnu.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Discuss-gnuradio digest..." > > > > > > Today's Topics: > > > >1. Re: test message please ignore (Marcus Müller) > >2. Help with sound output (Sara Kim) > >3. Re: Help with sound output (Michael Dickens) > >4. Re: Getting a Runtime Error: gr::tuntap_pdu::make: tun_alloc > > failed (Adrian Musceac) > >5. Re: query regarding wav file recording through wav file sink > > block (Maitry Raval) > >6. Re: query regarding wav file recording through wav file sink > > block (Müller) > >7. Re: query regarding wav file recording through wav file sink > > block (Maitry Raval) > >8. Re: Request for comment: FFT optimizations (Müller) > >9. Re: query regarding wav file recording through wav file sink > > block (Müller) > > 10. Re: query regarding wav file recording through wav file sink > > block (Maitry Raval) > >
Re: [Discuss-gnuradio] Determining distance from OFDM signals
On Wed, 05 Jun 2019 at 16:20:12 -0700, Andrew Wolfram wrote:
> I'm trying to alter the file ofdm_txrx.py (
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py)
> to get phase information from the carrier data so I can calculate an
> approximate distance between two USRP devices. Ideally I want to grab
> data from one of the blocks in the rx pipeline in the above python
> file after the frequency/timing corrections have been applied. I tried
> using the data after the serializer block, but it appears that this
> has no phase information. I tried with the equalizer block output but
> I'm not sure how to interpret its output data.
You cannot use the output of the equalizer block to get information on
channel phase (or amplitude). That’s the point of equalization. A
received subcarrier in a OFDM system is given by Y = H·X + N where H is
the channel transfer function at the subcarrier, X is the sent symbol
and N is noise (in frequency domain, i.e. after the FFT; note some
assumption regarding synchronisation must hold, see [1]). The equalizer
returns hat{X} = Y/hat{Y} where hat{·} denotes estimation. Note that
the serializer block is a downstream block of the equalizer in the file
you mention.
> For my particular payload with 300 occupied carriers and an fft size
> of 512 only the first 214 items of the equalizer output vector have
> any phase information, so I'm somewhat confused. Any ideas?
This might be related to the number of used pilots and their position.
Do you use 86 pilots? How do you define their position? It’s rather odd
that the position of carriers without phase information is not
scattered.
[1] https://ieeexplore.ieee.org/document/803501
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
