[Discuss-gnuradio] Detect ADC Overload
Hello Support Team, Is there any chance to detect an ADC overload through the python API. In my case, I am receiving an unknown input signal. The software should be able to find the highest possible RX gain value on its own, but the ADC should stay in the linear range. Unfortunately, my connection is too slow to stream the 200 MSample raw signal to the Laptop. Is there any flag that can be checked to avoid ADC clipping? I would like to do a method like: -Check if ADC is in overload -If yes: decrease gain -If No: increase gain My System *X310 with two TwinRX daughterboards, GPSDO *Connection to laptop: single Gigabit Ethernet *Sample Rate: 2e6, Center Frequency: 100e6, Possible Gain Twin RX: 0-95 *Oscillator and time base comes from GPSDO, all channels are tuned manually for coherent operation *UHD Version 3.10.003.001 FPGA version 35 *Python 3.7 Best regards Philipp ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Burst Shaper block partially delays burst
Hi community,
I do have an issue with the 'Burst Shaper' block and I'm uncertain how
to tackle this problem. In this particular case I'm stuck with 3.7 for
now, but as fas as I can tell, the actual implementation did not change
with respect to 3.8.
So, here is the problem:
I have a flowgraph like this
Source -> MyModulator -> Burst Shaper -> UHD Sink
-> Qt Time Sink
Source emits a packet at certain intervals, say every 1ms.
MyModulator transforms those bits into a burst with complex samples.
'Burst Shaper' is supposed to prepad some zeros and postpad some zeros.
UHD Sink expects a tagged burst with a packet length to transmit.
What happens? I get lots of underruns ('U') because Burst Shaper waits
somewhere in the order of milliseconds to write the last portion of the
burst to its output buffer. The actual burst consists of ~1k samples
@12.5MSps. Less than 100us duration.
Burst Shaper is required to pre and post pad zeros.
Prepad to 'reinitialize' a USRP. Otherwise the preamble is distorted
which ultimately screws my receiver algorithms.
Postpad is required to flush USRP FIFOs. Otherwise you'd see the end of
a previous burst at the beginning of the next burst.
In my Qt Time Sink, I can see that all bursts are tagged correctly. The
packet length tags are at the correct position.
The problem is really, that 'Burst Shaper' does not write the last part
of the burst until some later time. This makes the USRP sink miss some
samples in every burst and print one 'U' per burst. Also, this results
in this last part of the burst to be transmitted just before the next
burst. This does corrupt my bursts and does cause more artifacts like
cut off bursts which pollute the spectrum.
How would you proceed? Convert 'Burst Shaper' to a tagged stream block?
I tried to use 'Packet Pad2' from 'gr-foo'. Though, this would still
occasionally result in 'U's printed. Also, I can still see that my
bursts are occasionally transmitted late.
I'd really like to fix 'Burst Shaper'. Though, I don't know how I should
proceed yet.
Cheers
Johannes
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Project Call Today!
Hi, We have the first project call of the year today, at the usual time (10 AM Pacific, 19:00 CET). We'll post the call link on IRC and slack right before the call. Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Burst Shaper block partially delays burst
Johannes,
I don't know if this helps but I think I was facing the same issue quite
a while ago.
If I remember correctly, I was able to work around the issue by setting
a tx_time time tag on each burst which was pointing far enough into the
future to use the USRP as a "buffer" until all samples had left the
Burst Shaper (hope this makes sense).
Not very elegant but I think it worked quite well at the end.
You can find the block I used to calculate and set the tx_time tags in
flow graph [1].
Cheers,
Julian
[1] https://github.com/RWTH-iNets/gr-inets/blob/master/grc/inets_tx_phy.grc
On 17.01.19 12:39, Johannes Demel wrote:
Hi community,
I do have an issue with the 'Burst Shaper' block and I'm uncertain how
to tackle this problem. In this particular case I'm stuck with 3.7 for
now, but as fas as I can tell, the actual implementation did not change
with respect to 3.8.
So, here is the problem:
I have a flowgraph like this
Source -> MyModulator -> Burst Shaper -> UHD Sink
-> Qt Time Sink
Source emits a packet at certain intervals, say every 1ms.
MyModulator transforms those bits into a burst with complex samples.
'Burst Shaper' is supposed to prepad some zeros and postpad some zeros.
UHD Sink expects a tagged burst with a packet length to transmit.
What happens? I get lots of underruns ('U') because Burst Shaper waits
somewhere in the order of milliseconds to write the last portion of the
burst to its output buffer. The actual burst consists of ~1k samples
@12.5MSps. Less than 100us duration.
Burst Shaper is required to pre and post pad zeros.
Prepad to 'reinitialize' a USRP. Otherwise the preamble is distorted
which ultimately screws my receiver algorithms.
Postpad is required to flush USRP FIFOs. Otherwise you'd see the end of
a previous burst at the beginning of the next burst.
In my Qt Time Sink, I can see that all bursts are tagged correctly. The
packet length tags are at the correct position.
The problem is really, that 'Burst Shaper' does not write the last part
of the burst until some later time. This makes the USRP sink miss some
samples in every burst and print one 'U' per burst. Also, this results
in this last part of the burst to be transmitted just before the next
burst. This does corrupt my bursts and does cause more artifacts like
cut off bursts which pollute the spectrum.
How would you proceed? Convert 'Burst Shaper' to a tagged stream block?
I tried to use 'Packet Pad2' from 'gr-foo'. Though, this would still
occasionally result in 'U's printed. Also, I can still see that my
bursts are occasionally transmitted late.
I'd really like to fix 'Burst Shaper'. Though, I don't know how I should
proceed yet.
Cheers
Johannes
___
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] Creating a Python tagged_stream block
Hi all,
I am trying to create a tagged_stream block in Python using gr_modtool but
I am having some trouble. Am using the latest Gnuradio version (3.7.13.4)
on Ubuntu 16.04. Below is the error log.
Any suggestions? Adding other block types works fine.
Moreover, if gr_modtool does not support tagged_stream, can you suggest how
to create one manually in Python?
Thanks,
Amani
**
winesl@wines-feynman:~/gr-ieee802-11-master$ gr_modtool add
GNU Radio module name identified: ieee802-11
Enter name of block/code (without module name prefix): my_block
Block/code identifier: my_block
('sink', 'source', 'sync', 'decimator', 'interpolator', 'general',
'tagged_stream', 'hier', 'noblock')
Enter block type: tagged_stream
Language (python/cpp): python
Language: Python
Please specify the copyright holder:
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n] n
Adding file 'python/my_block.py'...
Traceback (most recent call last):
File "/usr/local/bin/gr_modtool", line 46, in
main()
File "/usr/local/bin/gr_modtool", line 38, in main
modtool.run()
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_add.py",
line 186, in run
self._run_python()
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_add.py",
line 331, in _run_python
self._write_tpl('block_python', self._info['pydir'], fname_py)
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_add.py",
line 172, in _write_tpl
open(path_to_file, 'w').write(get_template(tpl, **self._info))
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/code_generator.py",
line 58, in get_template
return str(GRMTemplate(Templates[tpl_id], searchList=kwargs))
File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005,
in __str__
rc = getattr(self, mainMethName)()
File "cheetah_DynamicallyCompiledCheetahTemplate_1547763062_44_25644.py",
line 99, in respond
KeyError: 'tagged_stream'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-ieee802-15-4 OOT Module not Working on E312
Hi, I am currently trying to get an OOT module working on an Ettus E312, but I am having issues with the code as I have described in the following Github Issue https://github.com/bastibl/gr-ieee802-15-4/issues/40 The flowgraph I am trying to run is the example CSS USRP Transceiver in that repository. It works fine on my laptop running Ubuntu on x86 architecture, however, it fails to work on the E312's ARM architecture - I believe this is the root of the problem, but I was wondering if anyone else has had similar issues with the same or other OOT modules on ARM-based USRPs and has managed to fix it, as I currently have had little success. Thanks for your help, David ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding correlate access code-tag block
Thanks for your guidance and support. I will try to make flow graph with the blocks as per examples given by you. With Best Regards, Maitry Raval, - Original Message - From: "Cinaed Simson" To: "Maitry Raval" Cc: "discuss-gnuradio" Sent: Tuesday, January 15, 2019 10:25:52 AM Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block Actually, with the Default Header Format file, and the Protocol Formatter, use correlation-access tagged block was a piece of cake. Also, here's an example of bspk using constellations - if you haven't found already. -- Cinaed On 1/14/19 12:39 PM, Cinaed Simson wrote: > As you may have already discovered, I was wrong about unpacking bits for > fec. > > Actually, I have no idea on how I'm getting the results I'm getting > using my modifications of your flowgraph - those depreciated blocks > definitely have strange problems. If I insert the unpack k=8 block as > required for fec the flowgraph doesn't work. > > I ran into a problem testing fec - I modified your sources and I didn't > have enough frame bits. So I set the frame bits to exactly what I need. > > And I can't get a simple correlation access tagged test working - even > with a tag gate. The only way it works is if remove the access code - > which defeats the purpose. > > So I'm go to have to evolve and get the protocol formatter working. > > Also, you don't have to use the rx and tx packet blocks - you can use > the replacements for the PSK mod/demod blocks - the constellation > mod/demod blocks - you probably shouldn't use any depreciated blocks. > > -- Cinaed > > > On 1/10/19 10:01 PM, Maitry Raval wrote: >> Hello, >> >> Ok, One more query, what is the purpose of the block unpack k=1 bit at >> output of PSK demod block, because the meaning of unpack k=1 means byte to >> byte conversion, right? >> >> With Best Regards, >> Maitry Raval, >> >> - Original Message - >> From: "Cinaed Simson" >> To: "Maitry Raval" >> Cc: "discuss-gnuradio" >> Sent: Friday, January 11, 2019 2:11:54 AM >> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block >> >> On 1/10/19 2:47 AM, Maitry Raval wrote: >>> Hello, >>> >>> Thanks for your time! >>> >>> It works completely fine, now I understand that we have to give tagged >>> stream at the input of encoder. >> >> Sorry, I didn't mean to imply you needed the stream to tagged stream >> block to make it work. >> >> I just put in at the beginning so I could use the tag debug as a brute >> force search to find out what was blocking the flow. >> >> There are two sequential tag blocks - the correlate correlate access >> code-tag from gnuradio and a block from gr-satellites - I would guess >> that is all you need. >> >> Select "pass thru" on the stream to tagged stream block - it should >> still work. >> >> -- Cinaed >> >> >>> >>> >>> With Best Regards, >>> Maitry Raval, >>> R& D engineer|Azista Industries Pvt Ltd| >>> 079-40605800|www.azistaaerospace.com >>> >>> - Original Message - >>> From: "Cinaed Simson" >>> To: "discuss-gnuradio" >>> Cc: "Maitry Raval" >>> Sent: Thursday, January 10, 2019 1:21:34 PM >>> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block >>> >>> Hi Mailry - I was able to get it run. >>> >>> I used the "correlate access" block from gnuradio - my installation of >>> gnuradio didn't like the block in your flowgraph. >>> >>> And then I had to install the python module "construct" in order to get >>> the flowgraph to run. >>> >>> In order to get the flowchart to work - at least in the sense of filling >>> up the output.txt file - I added a "Stream to Tagged Stream" block and >>> define a consist tag to get the Tag Debug block to work. >>> >>> Also, I had to remove the "unpack" block before the PSK modulation, >>> added a "Unpack K=1" block just after the PSK demodulation - and I set >>> "Generate Options" to "No Gui" in the Options block. >>> >>> -- Cinaed >>> >>> >>> >>> On 1/8/19 12:40 AM, Maitry Raval wrote: Hello, thanks for your guidance. I have also attached the grc file, input/output files and python file for your reference. after adding tag debug, still didn't get any output. I have also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version. actually because these psk blocks are deprecated, I have tried it with dpsk mod, demod block. But as I wanted to do continuous transmission, I didn't find replaced block for correlate access code-tag block, and the cusom block from gr-satellites are for extracting syncbits. I have also tried with simple flow graph by just sream muxing 2 files one with sync bits and other one is payload file and give that output to correlate access code-tag block, but that also didn't work. It would be grateful, If you guide me on this. I just want to make that sync bits searching and extracting from payload and receive only payload at the output. >
Re: [Discuss-gnuradio] gr-ieee802-15-4 OOT Module not Working on E312
Hi, On 1/18/19 12:42 AM, David Alexander wrote: > I am currently trying to get an OOT module working on an Ettus E312, but > I am having issues with the code as I have described in the following > Github Issue > https://github.com/bastibl/gr-ieee802-15-4/issues/40 ...and what about the proposed solution of changing `int` to a clearly defined data type like `uint8_t` or whatever fits for the different vectors? This should be done in the GNU Radio blocks (C++ domain) and the numpy arrays used in the PHY (np.array([...], dtype=np.uint8)). Best, Bastian smime.p7s Description: S/MIME Cryptographic Signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
