Re: [Discuss-gnuradio] correlation estimator reliability problem
On 1/31/19 6:39 AM, Alban Meffre wrote: > Hi All > did someone make the test_corr_est.grc example work properly recently ? > i tried the 3.7.13 gnuradio version on linux, macos and windows > in all versions the output of the correlation estimator block is really > a mess > this block put tag even if there is no signal at all, with corr_est = 0 It's an easy way to find it. Post your test_corr_est.grc file. -- Cinaed > > yesterday i managed to transmit a realtime MPEGTS videosignal using the > gnuradio example packet_tx -> packet_rx. i used an analog devices ADALM > PLUTO as an emitter and a RTLSDR as a receiver. both antenna where put > side by side at a few centimeter distance so the received baseband > signal had an amplitude near 0.5 > > the problem was that the transmission did not work for more than few > tens of second because the correlation block added misplaced tags every > now and then and put the header/payload demux in a locked state so i got > #f and no more packet output ! > > another problem is that if i set the thershold to 0., 0.9 or > more 9's, the result is not satisfying. > is someone able to explain me how to use correlation estimation block in > a reliable way ? > do i need to set the thershold to ABSOLUTE mode ? > > thanks > bob > > ___ > 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] Moving my antenna
In general, good quality 75 ohm (CATV) coax is perfectly acceptable for receive applications, and for that matter, most transmit applications. There's a fair bit of misconception about the amount of "loss" introduced by an impedence mismatch. If you mentioned the frequency range you're interested in, I missed it. the higher you go (i.e., VHF vs. HF, or UHF/SHF vs. VHF), loss does start to matter. There's an effective attenuation factor at different frequency ranges in coax based on length: it's effectively a resistor. As Doug and Albin (above) note this has to be accounted for. gerry n5jxs On Tue, Jan 29, 2019 at 3:57 PM david vanhorn wrote: > It would be very helpful to know the main frequency of interest. > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Gerry Creager NSSL/CIMMS 405.325.6371 ++ *The way to get started is to quit talking and begin doing.* * Walt Disney* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PC requirements for DVB-S2 processing at a high bandwidth
In addition to what Ron mentioned there is an FPGA implementation of the LDPC portion of DVB-S2 that I will be releasing late February (I hoped to be ready to relase it by FOSDEM, but work got in the way) which achieves the full bitrate. The initial release will not be integrated with RFNoC, but that could be added at a later date. Right now it is mostly running on the Ultra96 board. --Brennan On Thu, Jan 31, 2019, 11:56 AM Ron Economos The processing requirement for DVB-S2 are significant, especially the > receiver. Since you're using an X-series USRP, I'll guess you're > interested in satellite downlinks which can be 30 to 50 Msyms/s. > > Basically, the requirement would be the most powerful system you can > afford. Something with an Intel i9 or Xeon Gold/Platinum series processor. > > Even then, real-time processing for the receiver will be limited unless > you use an FPGA or GPU for the LDPC decoding. > > The good news is that I've ported an SIMD optimized LDPC decoder to GNU > Radio. > > https://github.com/drmpeg/gr-dvbs2rx > > Which is ported from: > > https://github.com/xdsopl/LDPC > > However, it's still not capable of satellite bitrates. > > Ron > > On 1/31/19 10:33, Maria Jesus Cañavate Sanchez wrote: > > Hi there! > > > > My name is Maria and I would like to make a question regarding the > > kind of PC characteristics which would be required to be able to > > process the signal in real-time (on the PC) when using the maximum > > bandwidth available on the USRP X-series. > > > > The scenario would be the following one: we would like to use GNU > > radio to send and receive DVB-S2 signals. Hence, the PC will do all > > the processing to check the BER, constellation, EVM, etc. Do you think > > it is possible to use a PC (with SSD drive and some suggested > > requirements) which could do the processing in real time or the only > > way to achieve that bandwidth in real time would be using the FPGA of > > the USRP? If the second case, then I guess we will do the processing > > off-line =) > > > > Thank you very much in advance! > > > > Best regards, > > > > Maria Jesus > > > > ___ > > 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] AM modulated signal using USRP2
Here's a flow graph. It's set up for an Ettus B2x0, so you'll have to change the UHD sink parameters. Ron On 1/31/19 12:01, Afaq Ahmed wrote: Hello fellows, I want to create an AM Modulator using USRP2. The setup is such that I want to use one USRP2 as AM Modulator (Transmitter) and another USRP2 to be the AM Demodulator (Receiver). Can you please point in the right direction ? May be some suggestions on how I can achieve this would be very nice? OS: Xubuntu 18.04 LTS PC: RAM 4 GB, Core i3 USRP2 with XCVR2450 daughterboard Thanks a lot BR Afaq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio am.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AM modulated signal using USRP2
Hello fellows, I want to create an AM Modulator using USRP2. The setup is such that I want to use one USRP2 as AM Modulator (Transmitter) and another USRP2 to be the AM Demodulator (Receiver). Can you please point in the right direction ? May be some suggestions on how I can achieve this would be very nice? OS: Xubuntu 18.04 LTS PC: RAM 4 GB, Core i3 USRP2 with XCVR2450 daughterboard Thanks a lot BR Afaq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PC requirements for DVB-S2 processing at a high bandwidth
The processing requirement for DVB-S2 are significant, especially the receiver. Since you're using an X-series USRP, I'll guess you're interested in satellite downlinks which can be 30 to 50 Msyms/s. Basically, the requirement would be the most powerful system you can afford. Something with an Intel i9 or Xeon Gold/Platinum series processor. Even then, real-time processing for the receiver will be limited unless you use an FPGA or GPU for the LDPC decoding. The good news is that I've ported an SIMD optimized LDPC decoder to GNU Radio. https://github.com/drmpeg/gr-dvbs2rx Which is ported from: https://github.com/xdsopl/LDPC However, it's still not capable of satellite bitrates. Ron On 1/31/19 10:33, Maria Jesus Cañavate Sanchez wrote: Hi there! My name is Maria and I would like to make a question regarding the kind of PC characteristics which would be required to be able to process the signal in real-time (on the PC) when using the maximum bandwidth available on the USRP X-series. The scenario would be the following one: we would like to use GNU radio to send and receive DVB-S2 signals. Hence, the PC will do all the processing to check the BER, constellation, EVM, etc. Do you think it is possible to use a PC (with SSD drive and some suggested requirements) which could do the processing in real time or the only way to achieve that bandwidth in real time would be using the FPGA of the USRP? If the second case, then I guess we will do the processing off-line =) Thank you very much in advance! Best regards, Maria Jesus ___ 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] PC requirements for DVB-S2 processing at a high bandwidth
Hi there! My name is Maria and I would like to make a question regarding the kind of PC characteristics which would be required to be able to process the signal in real-time (on the PC) when using the maximum bandwidth available on the USRP X-series. The scenario would be the following one: we would like to use GNU radio to send and receive DVB-S2 signals. Hence, the PC will do all the processing to check the BER, constellation, EVM, etc. Do you think it is possible to use a PC (with SSD drive and some suggested requirements) which could do the processing in real time or the only way to achieve that bandwidth in real time would be using the FPGA of the USRP? If the second case, then I guess we will do the processing off-line =) Thank you very much in advance! Best regards, Maria Jesus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM TX original example - output broken
Hey All! I'm fighting a problem with the original GNU Radio OFDM TX example from https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/ofdm/tx_ofdm.grc Nothing is changed, except adding two File Sinks writing the data to two text files. One File Sink is added at the random source and one at the OFDM Receiver output (parallel to Tag Debug). Letting it run for a short while, gives me two output files: send.txt and received.txt Then, I'm comparing the outputs in hex: hexdump -C send.txt > send.txt.hex hexdump -C received.txt > received.txt.hex meld send.txt.hex received.txt.hex (meld is a nicer diff tool) Every time I do this, the received file is broken at some point. Six lines in hexdump (i.e. 6*16=96 bytes) are missing. It occurs at random places, sometimes multiple times, and as the pattern is repeating but not always broken at the same point, you can see that it is not a special magic string that is causing it. My expectation is an error-free transmission. Can someone explain this behaviour? Am I missing some basic aspect? I have noticed, that the packet length is 96bytes. Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Does anyone use the Sphinx (Python) Manual?
Hey All, We are attempting to migrate the useful Sphinx documentation into Doxygen so there is less redundant documentation, and one less thing to deal with in 3.8. If you are someone who uses or has used the Sphinx manual, we would appreciate feedback about what parts of it you use. Hypothetically, if it disappeared tomorrow, would you notice/care? If you don't want to reply on the mailing list feel free to email me directly, I appreciate any feedback! Personally, in the past I have used it for: 1) Seeing docs of in-tree Python blocks, nearly all of which are hier blocks. Although I usually just use the documentation tab within GRC. 2) Looking up the Python version of a function, like PMT/tags/msg related stuff. That being said, more often I just pull up the Usage Manual page and jump to the example Python code. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] correlation estimator reliability problem
Hi All did someone make the test_corr_est.grc example work properly recently ? i tried the 3.7.13 gnuradio version on linux, macos and windows in all versions the output of the correlation estimator block is really a mess this block put tag even if there is no signal at all, with corr_est = 0 yesterday i managed to transmit a realtime MPEGTS videosignal using the gnuradio example packet_tx -> packet_rx. i used an analog devices ADALM PLUTO as an emitter and a RTLSDR as a receiver. both antenna where put side by side at a few centimeter distance so the received baseband signal had an amplitude near 0.5 the problem was that the transmission did not work for more than few tens of second because the correlation block added misplaced tags every now and then and put the header/payload demux in a locked state so i got #f and no more packet output ! another problem is that if i set the thershold to 0., 0.9 or more 9's, the result is not satisfying. is someone able to explain me how to use correlation estimation block in a reliable way ? do i need to set the thershold to ABSOLUTE mode ? thanks bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Custom Block ID as variable
Thanks for both your answers! The solution proposed by Marcus where a block drops samples until it receive a message is definitely worth a try and I think that will solve my problem also in an easier way. I think that Glens event detection block will come in handy sometime in the future! Cheers Erik Den ons 30 jan. 2019 kl 18:49 skrev Glen I Langston < glen.i.langs...@gmail.com>: > The actual GitHub command is > > git clone http://GitHub.com/glangsto/gr-nsf > > sorry for any confusion. > > Glen > > > On Jan 30, 2019, at 12:37 PM, Glen I Langston > wrote: > > > > Thanks for both the question and the answer! > > > > I’ve been puzzling over how to selectively capture data also > > and how to feed info back to gnuradio graphs, based on the detected data. > > > > I will try Marcus’s message-to-variable and variable-to-message blocks. > > > > We did create general purpose data-capture blocks for radio astronomy, > that identify events > > based on the significance of the input samples compared to the RMS of the > > data stream. The python code uses a circular buffer, and the output, > captured, data stream > > has the event centered in the middle of the buffer, so we can look at > the intensities > > before and after the _identified event_.The writing is separated > from > > detection, so that not much astronomy info is needed to detect an > event. The > > astronomy info is contained in the _event sink_ block. > > > > A counter-based capture could easily be implemented as well, based on > our blocks. > > We use variable tags to send the peak, rms and event time downstream. > This is all > > done in python. The computers I’m using can only deal with about 1MHz > > bandwidth. I’m working on a port to C++, to allow increased sample > rates. > > > > One note, our graphs did not work properly unless the data stream > continuued > > after the event was detected. i.e. our (perhaps simple minded) > implementation > > would hang up all data flow unless we provided the output vector > continually. > > So our block repeatedly provides the _captured_ sample output stream, > > until the next event is detected. > > > > Our event capture blocks are obtained with > > git clone http://www.github.com/gr-nsf/ > > > > And the “examples" directory has eventdetect.grc and eventwrite.grc > > that use simulated data, and require no source blocks. > > > > Best regards, > > > > Glen > > > > > > > > > >> On Jan 30, 2019, at 11:26 AM, Müller, Marcus (CEL) > wrote: > >> > >> Hi Erik, > >> > >> I'm not sure I'd do it the way you do; wouldn't something that simply > >> only lets through N samples each time after you send a message or call > >> a function be better? There's nothing "forcing" a block to "forward" > >> input to an output. On the contrary, you can just consume from the > >> input without producing on the output of your block. > >> > >> That makes things quite a bit easier. Write a block that drops all > >> samples, unless it gets a message (via a message port: see [1]), then > >> it passes N samples. > >> > >> How to send that message? Basically, you could write your own block > >> which has a attribute that gets called when a value changes, > >> and use one of the Qt GUI widgets' IDs as variable in there. > >> > >> Or you can basically use my variable to message source [2]. I haven't > >> tested it in ages, and I wrote it as a debugging tool, because I don't > >> consider it architecturally wise in the long run¹, but it might just be > >> useful for this very specific use case. > >> > >> [1] > >> https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics > >> [2] > >> > https://github.com/marcusmueller/gr-msgtools/blob/master/python/variable_to_msg.py > >> ¹ The future is bright and RPC-y; I'd love GRC to migrate from sharing > >> state between blocks via random Python objects to communicating via > >> messages in general, but we're clearly not there yet. > >> > >> On Wed, 2019-01-30 at 17:06 +0100, Erik von Keyserlingk wrote: > >>> Hi, > >>> I am developing a program with GRC where I want to take N samples. > (The hardware is a HackRF-one). I want to take N samples because I want to > measure at certain points with a H-field probe. > >>> > >>> The way I have thought to solve it is to develop a custom block, > "sampling counter" (in python), to count the number of samples that have > passed and after N samples it changes its value from 1 to 0 and a > "selector" block is directing other samples to /dev/null. This works with a > "check box" where a user can set/unset and change where the stream goes, > either into a file or to /dev/null. See attached flowgraph.png. > >>> > >>> TLDR: > >>> Q: How to implement the ID of a custom block so that it can be used as > a variable as from a checkbox, slider etc. Both in python an xml, that is > what is needed to be added in the .xml file and in the .py file to use the > ID as a variable? > >>> > >>> ___ > >>>
