[VOLK] Maintenance release 3.1.2

[Johannes Demel]

Hi everyone!

This is the VOLK v3.1.2 release! We want to thank all contributors.
This release wouldn't have been possible without them.

https://www.libvolk.org/release-v312.html

The last maintenance release revealed issues in areas that are difficult 
to test. While the changes to the library should be minimal, usability 
should be improved. Most notably, we build and deploy [the VOLK 
documentation](https://www.libvolk.org/docs) automatically now.


### Contributors

- Andrej Rode 
- Clayton Smith 
- Johannes Demel , 
- Marcus Müller 
- Rick Farina (Zero_Chaos) 

### Changes

- Documentation improvements, and automatically generate and publish
- docs: Add VOLK doc build to CI
- docs: Add upload to GitHub actions
- cpu_features: Update hints in README
- Remove sse2neon with a native NEON implementation
- Replace sse2neon with native NEON
- Remove loop unrolling
- Simplify Spiral-generated code
- Improve CI pipeline with new runner
- flyci: Test CI service with M2 instance
- actions: Update GH Actions checkout
- Auto-format CMake files
- cmake: Add .cmake-format.py
- cmake: Apply .cmake-format.py
- Release script fixes
- scripts/release: fix multi-concatenation of submodule tars
- shellcheck fixes
- bash negative exit codes are not portable, let's be positive

[VOLK] Maintenance release 3.1.1

[Johannes Demel]

Hi everyone!

This is the VOLK v3.1.1 release! We want to thank all contributors. This 
release wouldn't have been possible without them.


This is a maintenance release to fix subtle bugs in many areas and to 
improve our tests where possible. All in all, our CI is more stable now 
and catches more errors.


### Contributors

- Clayton Smith 
- Johannes Demel , 
- Kenji Rikitake 
- Philip Balister 

### Changes

- CI fixes
  - Allow for rounding error in float-to-int conversions
  - Allow for rounding error in `volk_32fc_s32f_magnitude_16i`
  - Allow for rounding error in float-to-int interleave
  - Add missing `volk_16_byteswap_u_orc` to puppet
  - Fix 64-bit integer testing
  - Build and test neonv7 protokernels on armv7

- kernels
  - Remove broken sse32 kernels
  - Fix flaky `fm_detect` test
  - Fix flaky `mod_range` test
  - Remove unnecessary volatiles from `volk_32fc_s32f_magnitude_16i`
  - Remove SSE protokernels written in assembly
  - Remove inline assembler from `volk_32fc_convert_16ic_neon`
  - Use bit shifts in generic and `byte_shuffle` reverse
  - Remove disabled SSE4.1 dot product
  - Fix `conv_k7_r2` kernel and puppet
  - Remove unused argument from renormalize
  - Align types in ORC function signatures
  - Uncomment AVX2 implementation
  - Renormalize in every iteration on AVX2
  - Remove extraneous permutations
  - Compute the minimum over both register lanes
  - `volk_32fc_s32f_atan2_32f`: Add NaN tests for avx2 and avx2fma code

- fixes
  - Express version information in decimal
  - Remove `__VOLK_VOLATILE`
  - Remove references to simdmath library
  - cmake: Switch to GNUInstallDirs
  - fprintf: Remove fprintf statements from `volk_malloc`
  - release: Prepare release with updated files
  - Get the sse2neon.h file to a git submodule to avoid random copies.

Re: volk questions

[Johannes Demel]

Hi Fons,

sorry for the abbreviation PR == Pull Request. A request to merge your 
contribution into the VOLK repository in this case. This includes a 
forum to discuss the specifics and possible improvements before we merge 
your code.


Did your Boost issue get solved? Boost was only required for old VOLK 
and environment versions that did not support `std::filesystem` yet. 
Your kernel versions imply you use a more recent system that supports 
this C++17 feature.
For everyone else, libvolk is still a C library. We only use C++ for 
tests etc.


For reference, these are the CPUs
Intel Core i5-3470
https://www.intel.com/content/www/us/en/products/sku/68316/intel-core-i53470-processor-6m-cache-up-to-3-60-ghz/specifications.html
With SSE and AVX

Intel Core i5-4300U
https://www.intel.com/content/www/us/en/products/sku/76308/intel-core-i54300u-processor-3m-cache-up-to-2-90-ghz/specifications.html
With SSE, AVX, and AVX2

I can't tell from a distance, why VOLK would not select AVX kernels on 
an AVX capable CPU.


For your benchmarking needs:
https://github.com/google/benchmark

This might be a very important section of the docs:
https://github.com/google/benchmark/blob/main/docs/user_guide.md#preventing-optimization
Especially `DoNotOptimize` should be interesting.
It could very well happen, that your code was optimized out.

Cheers
Johannes



On 14.10.23 11:02, Fons Adriaensen wrote:

Hi Johannes,

Thanks for your response !


first off, we'd need to know a bit more about your setup. Could you share
the versions of VOLK and your host system, e.g. OS, version, etc.
Furthermore, do you use a VM, a container, or smth like this?


VOLK was 2.5.0, now upgraded to 3.0.0, same results.
No VM, container, etc used.

Machine info:

zita1 (desktop)

fons@zita1:~> lscpu
Architecture:x86_64
   CPU op-mode(s):32-bit, 64-bit
   Address sizes: 36 bits physical, 48 bits virtual
   Byte Order:Little Endian
CPU(s):  4
   On-line CPU(s) list:   0-3
Vendor ID:   GenuineIntel
   Model name:Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz
 CPU family:  6
 Model:   58
 Thread(s) per core:  1
 Core(s) per socket:  4
 Socket(s):   1
 Stepping:9
 CPU(s) scaling MHz:  45%
 CPU max MHz: 3600.
 CPU min MHz: 1600.
 BogoMIPS:6387.26
 Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov
  pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 
pbe syscall
  nx rdtscp lm constant_tsc arch_perfmon pebs bts 
rep_good nopl
  xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq 
dtes64
  monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm 
pcid
  sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes 
xsave avx
  f16c rdrand lahf_lm cpuid_fault epb pti tpr_shadow 
flexp
  riority ept vpid fsgsbase smep erms xsaveopt dtherm 
ida arat
  pln pts vnmi
Virtualization features:
   Virtualization:VT-x
Caches (sum of all):
   L1d:   128 KiB (4 instances)
   L1i:   128 KiB (4 instances)
   L2:1 MiB (4 instances)
   L3:6 MiB (1 instance)
NUMA:
   NUMA node(s):  1
   NUMA node0 CPU(s): 0-3
Vulnerabilities:
   Gather data sampling:  Not affected
   Itlb multihit: KVM: Mitigation: VMX disabled
   L1tf:  Mitigation; PTE Inversion; VMX conditional cache 
flushes, SMT disabled
   Mds:   Vulnerable: Clear CPU buffers attempted, no 
microcode; SMT disabled
   Meltdown:  Mitigation; PTI
   Mmio stale data:   Unknown: No mitigations
   Retbleed:  Not affected
   Spec rstack overflow:  Not affected
   Spec store bypass: Vulnerable
   Spectre v1:Mitigation; usercopy/swapgs barriers and __user 
pointer sanitization
   Spectre v2:Mitigation; Retpolines, STIBP disabled, RSB filling, 
PBRSB-eIBRS Not affected
   Srbds: Vulnerable: No microcode
   Tsx async abort:   Not affected

fons@zita1:~> uname -a
Linux zita1 6.5.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 23 Sep 2023 22:55:13 
+ x86_64 GNU/Linux


zita4 (laptop)

Architecture:x86_64
   CPU op-mode(s):32-bit, 64-bit
   Address sizes: 39 bits physical, 48 bits virtual
   Byte Order:Little Endian
CPU(s):  4
   On-line CPU(s) list:   0-3
Vendor ID:   GenuineIntel
   Model name:Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
 CPU family:  6
 Model:   69
 Thread(s) per core:  2
 Core(s) per socket:  2
 Socket(s):   1
 Stepping:1
 CPU(s) scaling MHz:  46%
 CPU max MHz:   

Re: volk questions

[Johannes Demel]

Hi Fons,

first off, we'd need to know a bit more about your setup. Could you 
share the versions of VOLK and your host system, e.g. OS, version, etc. 
Furthermore, do you use a VM, a container, or smth like this?


Regarding your question, if these functions may be useful to VOLK / GNU 
Radio. I'd say yes. We'd have to figure out how this may work in 
practice though. I'd suggest to start with a PR.


Cheers
Johannes

On 13.10.23 16:08, Fons Adriaensen wrote:

Hello all,

I've recently installed volk on two machines, both Intel i5
but different types.

1. On one of the two machines 'make' failed while 'cmake ..'
ran without errors. Installing boost fixed this. Could it be
that the cmake step doesn't check for boost ?

2. On one the two machines, 'volk_profile -R volk_32f_sin_32f'
only tests the SSE4 versions even if AVX is supported (as
confirmed by profiling e.g. volk_32f_asin_32f), and an AVX
implemention is available (it is the selected one on the
other machine). Why is this ?

3. The reason I installed volk was to compare it against
some SSE4 code I developed for sin() and cos(). These calls
use cycles instead of rads as the argument as I find that
generally more convenient. They are not to full float32
precision, but more than good enough for e.g. music
synthesis. Testing them against volk on the two machines
produces:

fons@zita1:~/library/ssemath> testsin
sinf():   0.005975 us
volk_32f_sin_32f():   0.003983 us (SSE4.1)
sse_fastsin_f32():0.000802 us

fons@zita4:~/library/ssemath> testsin
sinf():   0.005324 us
volk_32f_sin_32f():   0.002579 us (AVX2)
sse_fastsin_f32():0.001088 us

The results for volk are consistent with the volk_profile
as above.

Harmonic distortion is:

  Harm  Level (dB)
 3 -162.0
 5 -137.8
 7 -128.6
 9 -147.3
11 -141.1
13 -138.1
15 -138.1
17 -138.6
19 -139.4
21 -140.5
23 -141.6
25 -142.8
27 -143.6
29 -144.6
31 -145.7
THD:  -125.7

Would such routines be useful in volk / gnuradio ?

Ciao,

Re: Volk sqrt ARM performance

[Johannes Demel]

Hi Jeff,

there's a good chance that your compiler outsmarted you. i.e. parts of 
your test are optimized out. I suggest to use smth like "benchmark" for 
tests. Also, make sure that the variables in your test cannot be 
optimized out.


Cheers
Johannes

On 08.10.23 00:22, Jeff R wrote:
I modified a simple Volk sqrt program for an ARM1176JZ-S processor to 
test performance, and the results are puzzling. The following program 
prints:



dur_VolkSqrt=(0.00)0.001721 dur_CRTLSqrt=(0.00)0.000318


The following processor information is displayed. It appears as though 
NEON is supported.



~/volk-3.0.0/build# cpu_features/list_cpu_features

arch    : aarch64

implementer :  65 (0x41)

variant :   0 (0x00)

part    : 3336 (0xD08)

revision    :   3 (0x03)

flags   : asimd,cpuid,crc32,fp


Why are the numbers so slow for Volk versus the CRTL? I may be missing 
something obvious. Thank you in advance.



Here’s the test program:



// g++ -I /usr/local/include/volk volk_sqrt.cpp -o volk_sqrt -L 
/usr/local/lib64/ -lvolk


// export LD_LIBRARY_PATH=/usr/local/lib64; ./volk_sqrt


#include 

#include 

#include 

#include 

#include 

#include 


double get_wall_time()

{

 struct timeval time;


 if (gettimeofday(,NULL))

 {

 //  Handle error

 return 0;

 }

 return (double)time.tv_sec + (double)time.tv_usec * .01;

}


int main(int argc, char* args[])

{

 double walStop;

 double walStart;

 double dur_VolkSqrt;

 double dur_CRTLSqrt;

 int N = 1024*16;


 unsigned int alignment = volk_get_alignment();

 float* in = (float*)volk_malloc(sizeof(float)*N, alignment);

 float* out = (float*)volk_malloc(sizeof(float)*N, alignment);


 for(unsigned int ii = 0; ii < N; ++ii)

 {

 in[ii] = (float)(ii*ii);

 }


 walStart = get_wall_time();

 volk_32f_sqrt_32f_a(out, in, N);

 //volk_32f_sqrt_32f(out, in, N);

 walStop = get_wall_time();

 dur_VolkSqrt = walStop - walStart;


 walStart = get_wall_time();

 for(unsigned int ii = 0; ii < N; ++ii)

 {

 out[ii] = sqrt(in[ii]);

 }

 walStop = get_wall_time();

 dur_CRTLSqrt = walStop - walStart;


 printf("dur_VolkSqrt=(%f)%f dur_CRTLSqrt=(%f)%f\n", dur_VolkSqrt/N, 
dur_VolkSqrt, dur_CRTLSqrt/N, dur_CRTLSqrt);


 volk_free(in);

 volk_free(out);

 return 0;

}

Re: GRC: Cannot find "RFNoC Fosphor" blocks

[Johannes Demel]

Hi Luca,

you need to install the OOT module that includes the RFNoC version of 
fosphor.


Cheers
Johannes

On 04.09.23 13:00, Bachmaier, Luca wrote:

Hey everyone,

I’m currently implementing a flowgraph that uses RFNoC by UHD / Ettus 
Research. In GNU Radio companion, I noticed that there are no blocks 
“RFNoC Fosphor Block” and “RFNoC Qt Fosphor Display” available (See this 
workshop https://www.youtube.com/watch?v=M9ntwQie9vs 
 @ 22:13 for a flowgraph 
that uses them). My basic software setup is:


-OS: Debian 12

-GNU Radio 3.10.5.1

-UHD 4.3.0.0+ds1-5

I was wondering why these blocks aren’t available or if I need to 
install an additional module in order to get them. The module gr-fosphor 
(https://projects.osmocom.org/projects/sdr/wiki/Fosphor 
) just installs 
the “standard” version of Fosphor, **not** the FPGA / RFNoC implementation.


Thank you and regards

Luca



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Round trip time calculation - simulation

[Johannes Demel]

Hi Jiya,

some inline comments.

On 31.08.23 12:35, Jiya Johnson wrote:

Hi Johannes,
Thanks in advance for your valuable inputs!
I appreciate your help so much.

1.I want to measure the time taken by 1 sample from the random source to 
the decoder unit-endpoint.
My previous comment was targeted at the fact that FEC encoders and 
decoders work on blocks or frames. The concept of single samples or bits 
and how long they take to propagate through a flowgraph is probably not 
a good measure. It would probably make more sense to look at FEC frames 
and how long they take to propagate through a flowgraph.
Depending on the exact position in your flowgraph, an FEC frame might 
imply that these are the info bits or a codeword.



2.Need more clarifications in throttle usage in terms of latency.
The throttle block measures how many samples it passed to the output 
during a time period and will just stall if more samples could pass through.
The GR buffer architecture tries to fill buffers. If you stall in any 
part of the flowgraph, it might take longer until your blocks where you 
want to measure latency are called by the scheduler.


3.Time stamp i have used is with two stamping before encoding and after 
decoding whether it will make sense ,what i understood is time delta if 
i am using it will be taking only the latest time key added.

The "Add System Time" block is intended to be used together with
https://github.com/gnuradio/gnuradio/blob/main/gr-pdu/include/gnuradio/pdu/time_delta.h
There's a nice explanation in the wiki:
https://wiki.gnuradio.org/index.php/Time_Delta


4.How can i use the control performance monitor for this FG.
GNU Radio Companion 3.10.7.0
performance monitor is intended for things like load and buffer state. 
Latency needs extra info (the discussed timestamps). Thus, performance 
monitor won't report latency.



I will upload a PDF of the flowgraph.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: RuntimeError: invalid msg port in connect() or disconnect()

[Johannes Demel]

Hi Theo,

I assume this setup is part of a very old experiment that you want to 
reboot. However, something must have changed since it's broken at the 
moment.


It is very difficult to spot the issue without any context but just a 
traceback.


The message itself tells you that you try to connect a message port 
that's not an actual message port.


GRC generates a Python file for your flowgraph. In your case you also 
have a hier block that receives a second Python file. The error happens 
in there:

  File "/home/theow/.grc_gnuradio/RX_SC_PHY.py", line 91, in __init__
self.msg_connect((self, 'time_per_angle_message'), 
(self.theomodule_set_array_and_tt_RX_0, 'time_per_angle_message'))


This hier block is potentially called "RX_SC_PHY". You might want to 
check what happened there.


Cheers
Johannes

On 29.08.23 15:28, theow...@web.de wrote:

Hey everybody,
I am currently facing the following error:
Could not find port: time_per_angle_message in:
system
Traceback (most recent call last):
   File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line 
561, in 

     main()
   File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line 
549, in main

     tb = top_block_cls()
   File "/home/theow/GNURadio/flowgraphs/transceiver_station_2.py", line 
398, in __init__

     usrp_tx_address="addr=192.168.10.4",
   File "/home/theow/.grc_gnuradio/phy_transceiver.py", line 90, in __init__
     threshold=detector_threshold,
   File "/home/theow/.grc_gnuradio/RX_SC_PHY.py", line 91, in __init__
     self.msg_connect((self, 'time_per_angle_message'), 
(self.theomodule_set_array_and_tt_RX_0, 'time_per_angle_message'))
   File 
"/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 59, in wrapped
     func(self, src.to_basic_block(), srcport, dst.to_basic_block(), 
dstport)
   File 
"/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 131, in msg_connect

     self.primitive_msg_connect(*args)
   File 
"/home/theow/60GHzDemo/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 3586, in primitive_msg_connect
     return _runtime_swig.hier_block2_sptr_primitive_msg_connect(self, 
*args)

RuntimeError: invalid msg port in connect() or disconnect()
I googled a lot, but I did not really find an answer to that problem...
I am on an older setup with gnuradio 3.7 and ubuntu 16.04. I know for 
sure, that this setup was already working...so I am even more confused 
about that error.
Would be very great if anyone had maybe a quick idea, how to solve this 
error. If you need any more information, I will gladly provide it.

Thanks in advance,
Theo


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Round trip time calculation - simulation

[Johannes Demel]

Hi Jiya,

It seems like you want to measure the DSP latency in a flowgraph without 
hardware.


For better readability, I suggest to use a service that lets you upload 
screenshots in higher resolution and you just share the link.


In said screenshot, I suggest to mark your start end endpoint for your 
measurement. Thus, we all know exactly what you want to do.


The "Throttle" block will have an influence on your measurement even if 
it is before your measurement starting point because it influences GR 
scheduler behavior.


The timestamp and latency measurement approach seems sensible. I used 
the same approach for such investigations.


How do you want to track the timing for 1 sample?
Especially FEC works on blocks. A lot of blocks do. Not just in GR but 
just in principle.
I assume that you want to measure the time it takes for a frame of 
specific size to be processed.


Since I don't know which GR version you use, you might want to double 
check if all the rate changing blocks place the tags on the correct 
sample in the output.


These are a few thoughts that came to mind when I looked at your flowgraph.

Cheers
Johannes

On 30.08.23 11:40, Jiya Johnson wrote:


Hello, community. I have attempted to create a system that uses
1. A random source as input
2. A time stamper.These inputs are provided to the encoder, which 
performs the modulation and demodulation
3.I want to track back the timing for 1 sample (latency) after using the 
decoder; can somebody tell me whether my flowgraph is correct?

Screenshot from 2023-08-26 11-24-39.png




smime.p7s
Description: S/MIME Cryptographic Signature

Experience on how to publish data on Zenodo

[Johannes Demel]

Hi everyone,

I'd like to publish some of the data I recorded with my GNU Radio demo 
on zenodo.org. It is not IQ data but other data that we stored in an 
elasticsearch database.
Maybe some of you know about a suitable data format or a source that 
discusses best practices. Right now, I export everything via

https://github.com/elasticsearch-dump/elasticsearch-dump
But they use their custom format and change it over time. I doubt it is 
suitable for archiving purposes.


I'd appreciate hints on how to do that properly.

Cheers
Johannes

--
Johannes Demel M.Sc.
Research Engineer

University of Bremen
Department of Communications Engineering
Faculty 1 - Physics / Electrical Engineering
NW1, N2400
Otto-Hahn-Allee NW1
28359 Bremen


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Missings packets on OFDM system simulation

[Johannes Demel]

Hi Jorge,

a couple of observations first:
- the "throttle" block needs to be part of the actual flowgraph to have 
any effect. You might want to remove your null source -> throttle -> 
null sink chain.
- for the sake of a Minimum Working Example (MWE) I suggest to remove 
the file sink and virtual sinks as well.
- Did you check the actual sample level on the "OFDM Transmitter" output 
port? I suspect these values do not have a mean energy of 1 but way 
less. In your case probably 1/sqrt(64). You'd need to adopt the "Noise 
Voltage" parameter in your "Channel Model" block accordingly.

- How did you compute your SNR value?
- As long as there's noise, you'd eventually lose packets.

Cheers
Johannes

On 13.07.23 20:08, JORGE GONZALEZ ORELLANA via GNU Radio, the Free & 
Open-Source Toolkit for Software Radio wrote:

As you can see, it's the basic implementation of OFDM.
My goal it's to measure the BER, but as I mentioned earlier, below 
certain level or SNR (20dB)


El jue, 13 jul 2023 a las 8:05, Marcus Müller (>) escribió:


Hi Jorge,

yes, please share your flowgraph. It's moot even beginning talking
about it without
knowing it.

Best regards,
Marcus

On 12.07.23 20:53, JORGE GONZALEZ ORELLANA via GNU Radio, the Free &
Open-Source Toolkit
for Software Radio wrote:
 > Hello everyone, I have some question related with a OFDM
transmission simulation, in
 > particular, about losing packets.
 >
 > I am using the OFDM Transmitter and Receiver blocks to do the
transmission (if you need
 > more details, I can upload an image of the flowgraph).
 >
 > The problem that I get is when put some noise (to get some level
of SNR), when I have
 > about 20dB (or more) of SNR I don't lose any packet, but if I put
less than 20dB of SNR,
 > almost all packets gets lost, (just 1 or 2 packets are received),
all of this happen over
 > simulation.
 >
 > Any suggestions on why this might happen?



smime.p7s
Description: S/MIME Cryptographic Signature

Re: gr-gfdm

[Johannes Demel]

Hi Mike,

you'd need to provide more detail for a good answer.
How did you install gr-gfdm and GNU Radio?
Which source did you use?

Cheers
Johannes

On 05.07.23 17:29, Mike Sousa wrote:
i'm trying to execute gr-gfdm in gnuradio companion v3.10. There are a 
lot of Flowgraph errors out of the box. For example: Block : 
import_cyclic_prefix, Aspect : Param ‘Import’, Message : Import “from 
gfdm.pygfdm import cyclic_prefix” failed.  Any idea how to get the rest 
of the gr-gfdm package


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Detected an invalid packet at item

[Johannes Demel]

Hi Hamed,

you mentioned that increasing the TX and RX gain reduced the number of 
invalid packets. Still, as long as you transmit over an imperfect 
channel, there will be reception errors.


The reports you receive stem from the logging system. They are tagged 
":info:" because this might be an interesting information in some cases. 
However, this is not a software system error. This is a reception error 
and should be treated as such.

You already mentioned a few channel effects that influence your reception:
- multipath
- interference
I'd like to stress that:
- noise
- hardware imperfections
- any unfortunate condition in your receiver chain
may also affect your reception.

The questions that arise are:
- What do you want to fix here?
- Did you observe anything that you didn't expect?

Cheers
Johannes

On 14.05.23 05:33, Hamed Al-Zubi wrote:


Ed,

I tried the NLOS scenario to avoid distortion, but still the same error 
occurs.


Thanks!
HZ
On Saturday, May 13, 2023 at 11:07:22 AM CDT, Ed Criscuolo 
 wrote:



2 meters seems like an incredibly short distance unless you have an 
attenuator in series with the Tx antenna. You may be overdriving the 
receiver and causing distortion errors.


@(^.^)@ Ed
Sent from my iPhone

On May 12, 2023, at 8:10 PM, Hamed Al-Zubi  
wrote:



Hello,

I am utilizing two USRPs, specifically the X300 models, along with 
GNURadio for the purpose of transmitting and receiving OFDM signals. I 
have implemented the OFDM flowgraphs available on Github for this 
purpose. The transmission and reception setup involves LOS 
(Line-of-Sight) configuration, where the transmit and receive antennas 
are positioned with a separation distance of 2 meters. To minimize the 
impact of multipath interference, the antennas are surrounded by 
absorption boards. Although the transmission and reception process 
itself is functioning without issues, I have encountered a problem 
when displaying the channel state information. In particular, there 
are instances where invalid packets are detected, as evidenced by the 
following occurrences.


*packet_headerparser_b :info: Detected an invalid packet at item 167472*
*header_payload_demux :info: Parser returned #f*

I have searched the possible causes of the error I'm encountering, and 
there are a few factors that have been suggested:


1- Interference--> I used different frequencies and ensured they are 
not in use.
2- Multipath --> absorption boards were used to minimize the impact of 
multipath.
3- Some people suggested to change  the FFT length and CRC length as a 
potential solution, however, modifying these papermeters did not 
resolve the issue.


When I used a channel model instead of USRPs, the error did not occur.
I am still uncertain about the exact cause of the error I am experiencing.


Thanks,
HZ


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Segmentation fault when adding a variable...

[Johannes Demel]

Hi Niklas,

since gdb starts quite a few threads, I suggest you extract the part 
that segfaults into a script that's as small as possible. I assume you 
run a flowgraph in GRC. Just take the generated `.py` file and reduce it.

A simple unittest would be an alternative approach.
Which GR version do you use exactly?
How did you install GR?
You might want to check which pybind11 version was used to build GR and 
which version was picked up by CMake for your OOT module. This is just a 
wild guess.
It's beneficial to start using git as early as possible. Even if you 
just run into situations like: "It works this morning, what did I break?".


I assume your "certain variable" is your customized `phy_header`. Is 
this correct?


Cheers
Johannes

PS: Instead of absolute paths like `#include "/home/inets/..."` you 
might want to figure out how to configure your system such that it picks 
up the correct prefixes.


On 31.03.23 13:42, Beckmann, Niklas wrote:

Dear all,


I am currently facing a problem, where gunradio segfaults, when I add a 
certain variable into the flowchart.


I created a little apache server, to share the according code of my 
module, where the segfault happens (/include & /lib cpp files):


http://nbws.hopto.org/ 


Maybe there is something wrong with the code?


When I do a gdb backtrace, I get the following:

[New Thread 0x7fffe0c4f700 (LWP 172481)]
[Thread 0x7087c700 (LWP 172476) exited]
[Thread 0x7fffdbfff700 (LWP 172479) exited]
[New Thread 0x7fffdbfff700 (LWP 172482)]
[New Thread 0x7087c700 (LWP 172483)]
[Thread 0x7fffdbfff700 (LWP 172482) exited]
[Thread 0x7087c700 (LWP 172483) exited]
--Type  for more, q to quit, c to continue without paging--

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x7fffdaa52c6b in pybind11::detail::same_type (rhs=..., lhs=...)
     at /usr/include/pybind11/detail/internals.h:55
55 inline bool same_type(const std::type_info , const std::type_info 
) { return lhs == rhs; }

(gdb) backtrace
#0  0x7fffdaa52c6b in pybind11::detail::same_type(std::type_info 
const&, std::type_info const&) (rhs=..., lhs=...) at 
/usr/include/pybind11/detail/internals.h:55
#1  
pybind11::detail::type_caster_base::src_and_type(gr::digital::packet_header_default const*)

     (src=0x7fffe3519cf0 )
     at /usr/include/pybind11/cast.h:852
#2  
pybind11::detail::type_caster_base::cast_holder(gr::digital::packet_header_default const*, void const*)
     (holder=0x7fff7cd0, src=0x7fffe3519cf0 gr::mymodule::phy_header_impl+96>) at /usr/include/pybind11/cast.h:877
#3  
pybind11::detail::copyable_holder_caster >::cast(std::shared_ptr const&, pybind11::return_value_policy, pybind11::handle)
     (src=std::shared_ptr (use count 
25760825, weak count -1) = {...}) at /usr/include/pybind11/cast.h:1466
#4  
pybind11::cpp_function::initialize, gr::digital::packet_header_default, , pybind11::name, pybind11::is_method, pybind11::sibling, char const*>(std::shared_ptr (gr::digital::packet_header_default::*)(), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, char const* const&)::{lambda(gr::digital::packet_header_default*)#1}, std::shared_ptr, gr::digital::packet_header_default*, pybind11::name, pybind11::is_method, pybind11::sibling, char const*>(pybind11::cpp_function::initialize, gr::digital::packet_header_default, , pybind11::name,--Type  for more, q to quit, c --Type  for more, q to quit, c to continue without paging--
  pybind11::is_method, pybind11::sibling, char 
const*>(std::shared_ptr 
(gr::digital::packet_header_default::*)(), pybind11::name const&, 
pybind11::is_method const&, pybind11::sibling const&, char const* 
const&)::{lambda(gr::digital::packet_header_default*)#1}&&, 
std::shared_ptr 
(*)(gr::digital::packet_header_default*), pybind11::name const&, 
pybind11::is_method const&, pybind11::sibling const&, char const* 
const&)::{lambda(pybind11::detail::function_call&)#3}::operator()(pybind11::detail::function_call) const (call=..., this=0x0)

     at /usr/include/pybind11/pybind11.h:159
#5  
pybind11::cpp_function::initialize, gr::digital::packet_header_default, , pybind11::name, pybind11::is_method, pybind11::sibling, char const*>(std::shared_ptr (gr::digital::packet_header_default::*)(), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, char const* const&)::{lambda(gr::digital::packet_header_default*)#1}, std::shared_ptr, gr::digital::packet_header_default*, pybind11::name, pybind11::is_method, pybind11::sibling, char const*>(pybind11::cpp_function::initialize, gr::digital::packet_header_default, , pybind11::name, pybind11::is_method, pybind11::sibling, char const*>(std::shared_ptr (gr::digital::packet_header_default::*)(), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, char const* const&)::{lambda(gr::digital::packet_header_default*)#1}&&, std::shared_ptr (*)(gr::digital::packet_header_default*), pybind11::name const&, 

Re: Undefined symbol: zmq_strerror in OOT C++ block

[Johannes Demel]

Hi,

the error comes up when you try to `import satmisc_python`. This is the 
Pybind11 Bindings part of your module.


Fortunately, the bindings exist and are found. Also, the library 
`libgnuradio-satmisc.so` exists. This is the file where your blocks get 
compiled into.
However, this library is looking for a symbol `zmq_strerror` that it 
can't find. You probably didn't link your module against ZMQ.

This is probably missing in your module:
https://github.com/gnuradio/gnuradio/blob/78d89e1466864d305fbb8a5b25a7e1e94efc18c4/gr-zeromq/lib/CMakeLists.txt#L31

Cheers
Johannes

On 16.02.23 15:02, Guillermo Lena wrote:
I have ported an OOT block from 3.8 to 3.10 by creating a new module and 
block with gr_modtool in GNU Radio 3.10 and copying the 3.8 code into de 
3.10 corresponding files. I have built it with cmake .. make etc 
successfully. This blocks involves CSP and ZMQ. When I run a flowgraph 
where this block is, i get the following error:


Traceback (most recent call last):
   File "/home/gnuradio/persistent-folder/satlab/srs3_radio_lime.py", 
line 38, in 

     from gnuradio import satmisc
   File 
"/usr/local/lib/python3.10/dist-packages/gnuradio/satmisc/__init__.py", 
line 18, in 

     from .satmisc_python import *
ImportError: 
/usr/local/lib/x86_64-linux-gnu/libgnuradio-satmisc.so.1.0.0: undefined 
symbol: zmq_strerror


I do not know exactly where this error comes from and would much 
apreciate any hints on how to fix this.


smime.p7s
Description: S/MIME Cryptographic Signature

[VOLK] Major release 3.0.0

[Johannes Demel]

Hi everyone!

This is the VOLK v3.0.0 major release! This release marks the conclusion 
of a long lasting effort to complete [GREP 
23](https://github.com/gnuradio/greps/blob/main/grep-0023-relicense-volk.md) 
that proposes to change the VOLK license to LGPLv3+. We would like to 
thank all VOLK contributors that they allowed this re-licensing effort 
to complete. This release wouldn't have been possible without them.


For VOLK users it is important to not that the VOLK API does NOT change 
in this major release. After a series of discussion we are convinced a 
license change justifies a major release. Thus, you may switch to VOLK 3 
and enjoy the additional freedom the LGPL offers.


### Motivation for the switch to LGPLv3+

We want to remove usage entry barriers from VOLK. As a result, we expect 
greater adoption and a growing user and contributor base of VOLK. This 
move helps to spread the value of Free and Open Source Software in the 
SIMD community, which so far is dominated by non-FOSS software. 
Moreover, we recognize the desire of our long term contributors to be 
able to use VOLK with their contributions in their projects. This may 
explicitly include proprietary projects. We want to enable all 
contributors to be able to use VOLK wherever they want. At the same 
time, we want to make sure that improvements to VOLK itself are easily 
obtained by everyone, i.e. strike a balance between permissiveness and 
strict copyleft.


Since VOLK is a library it should choose a fitting license. If we see 
greater adoption of VOLK in more projects, we are confident that we will 
receive more contributions. May it be bug fixes, new kernels or even 
contributions to core features.


Historically, VOLK was part of GNU Radio. Thus, it made total sense to 
use GPLv3+ just like GNU Radio. Since then, VOLK became its own project 
with its own repository and leadership. While it is still a core 
dependency of GNU Radio and considers GNU Radio as its main user, others 
may want to use it too. Especially, long term VOLK contributors may be 
able to use VOLK in a broader set of projects now.


After a fruitful series of discussions we settled on the LGPLv3+. We 
believe this license strikes a good balance between permissiveness and 
strict copyleft for VOLK. We hope to foster contributions to VOLK. 
Furthermore, we hope to see VOLK usage in a wider set of projects.


### Contributors

The VOLK 3.0.0 release is only possible because all contributors helped 
to make it possible. Thus, we omit a list of contributors that 
contributed since the last release.

Instead we want to thank everyone again!

### Changes

* License switch to LGPLv3+
* Fix build for 32 bit arm with neon
* Add experimental support for MIPS and RISC-V

Re: what is gateway.py

[Johannes Demel]

Hi,

If you use a Python block, you use `gateway.py`. Under the hood, this 
file provides the functionality that binds Python and GR together to be 
able to call Python code during runtime. Everywhere else GR uses Python 
to configure flowgraphs but the actual flowgraph execution is entirely 
implemented in C++.


The actual error seems to be related to a missing configuration. However 
it is terribly hard to tell without more info.


Cheers
Johannes

PS: Your email signature tries to load remote content. To me this looks 
like your antivir, aka AVG, is placing an ad there.


On 16.12.22 02:40, Elmore Family wrote:
I am attempting to run a flowgraph that has a button. When the button is 
pressed, I get an error stating that ‘gateway.py has no attribute 
set_ft8button’ which is the callback for the button pressed.
What is gateway.py and why is it being called? The only results I get in 
a search for gateway.py relate to the Gateway class in Python that 
appears related to an interface of some sort. I am not using anything 
like this.

Thus, how can I correct this error?
Jim


  Virus-free.www.avg.com 


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Import error using an OOT

[Johannes Demel]

Hi all,

it looks like there's a path issue.

In line 34 in "run_response.py" you do
```
parser.read('./ft8_qso.conf')
```
There's a good chance, that you did not load this file.
I assume this is:
https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.read

> If none of the named files exist, the ConfigParser instance will
> contain an empty dataset. An application which requires initial values
> to be loaded from a file should load the required file or files using
> read_file() before calling read() for any optional files:

The `./` part in you file name is relative to the folder where you run 
Python. It is not relative to the `.py` file.


Anyways, You might want to check which file gets read when etc.

Cheers
Johannes

On 12.12.22 15:27, Elmore Family wrote:
You are confusing main() in run_response.py with the ‘main’ section in 
ft8_qso.conf.
parser.get in line 36 is looking for the ‘main’ section but throws the 
NoSectionError.

Why can’t the parser see the ‘main’ section?
When I said I have run an OOT before, I meant another OOT which runs 
well in this same app. However, this is irrelevant since we are not 
talking about the same problem.

Jim
*From:* Cinaed Simson
*Sent:* Monday, December 12, 2022 12:57 AM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The main method is defined beginning on line 216 and called 4 times on 
lines 36-39.


And it appears the configparser is throwing the NoSectionError.

Try commenting out line 36 to see if line 37 throws the same exception.

When you said is has run before, did it run under python3.9?

-- Cinaed


On 12/11/22 19:11, Elmore Family wrote:
I have attached the 2 files in question. Look at the beginning of 
run_response.py. It uses ConfigParser to access the ft8_qso.conf 
configuration file.
This line seems to be the problem: my_call = str(parser.get('main', 
'my_call_sign')).
But ‘main’ is a section in the ft8_qso.conf file. Why can’t it find 
‘main’?

Jim
*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 8:52 PM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The problem appears to be in the python code

  response.py

- there is no 'main()' method.

-- Cinaed

On 12/11/22 09:48, Elmore Family wrote:

Here is the result:

pi@raspberrypi:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ft8
Traceback (most recent call last):
File "", line 1, in 
File "/usr/local/lib/python3.9/dist-packages/ft8/__init__.py", line 
23, in 

from .run_response import run_response
File "/usr/local/lib/python3.9/dist-packages/ft8/run_response.py", 
line 36, in 

my_call = str(parser.get('main', 'my_call_sign'))
File "/usr/lib/python3.9/configparser.py", line 781, in get
d = self._unify_values(section, vars)
File "/usr/lib/python3.9/configparser.py", line 1149, in _unify_values
raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'main'

Jim

*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 12:15 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
Type

   python3

then enter

  import ft8

and see if it works.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
  imports: import ft8
  make: ft8.run_response(${ft8_button})
  callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make 
entry)

# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
  default: 0
#  'file_format' specifies the version of the GRC yml format used in 
the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked 
at the previous OOT and reviewed the GNU Radio docs on OOTs without 
seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim


  Virus-free.www.avg.com 










smime.p7s
Description: S/MIME Cryptographic Signature

Re: Problem with the OOT forecast() method in Python

[Johannes Demel]

Hi George,

first a few words of caution. Python blocks are intended for quick tests 
and incur a serious performance penalty. Thus, they are actually not 
that well documented in terms of more advanced functionality. Given that 
`forecast` is generally more of a performance optimization function, 
this is not surprising.
It might be interesting to describe your issue in more detail. What are 
you actually trying to do? Maybe the `forecast` method is not the thing 
you actually need to implement.


Please refer to a default implementation for the Python `forecast` method:
https://github.com/gnuradio/gnuradio/blob/09930fdcc5c892eaff5754f6ef0203146bc1cca7/gnuradio-runtime/python/gnuradio/gr/gateway.py#L153

Also:
https://github.com/gnuradio/gnuradio/blob/09930fdcc5c892eaff5754f6ef0203146bc1cca7/gnuradio-runtime/python/gnuradio/gr/gateway.py#L336
This is another example how to implement the forecast method.

The implementations for sync, decimation, and interpolation blocks are 
available and do not need to be implemented separately. This would only 
be necessary for general blocks.


Cheers
Johannes

On 13.10.22 01:00, George Edwards wrote:

Hi Jeff, thanks for bearing with me.

When I retested the last approach just now upon receiving your email it 
works. Earlier, l forgot to take out some extraneous stuff in my code, 
which broke it. The code snippet I sent implies a one to one 
relationship between input and output. The forecaster does its job to 
ensure the number of input samples is at least the same size as the 
output, but in many instances the input is larger. This, however, will 
present a problem to the signal processing algorithm I have in mind 
which requires the post-pending samples (the size of my filter) to the 
end to the incoming data before upsampling. It seems the forecaster may 
be too loose in its input/output sample relationship and will mess up my 
algorithm.


Anyway, if you have any thought on this and do not mind sharing I would 
appreciate it.


Thank again for your assistance.

George

On Wed, Oct 12, 2022, 2:58 PM Jeff Long > wrote:


The last one looks correct, and would not have given the error you
mention above. What happened?

On Wed, Oct 12, 2022 at 4:49 PM George Edwards
mailto:gedwards@gmail.com>> wrote:

Hi Jeff, thank you very much for the response.
I tries:
ninput_items_required[0]=[noutput_items]
ninput_items_required=[noutput_items]
and
return [noutput_items]
None of these worked for me.

Regards
George

On Wed, Oct 12, 2022, 8:07 AM Jeff Long mailto:willco...@gmail.com>> wrote:

For Python, the forecast() function should return a list,
containing the number of items required for each input.

On Wed, Oct 12, 2022 at 8:08 AM George Edwards
mailto:gedwards@gmail.com>> wrote:

Hello GNURadio Community,

I am getting a TypeError when I fill in the code in the
forecast() method in my Gnuradio OOT block design. I
know, if I want to interpolate or decimate, I can simply
pick the block type in the gr_modtool design menu,
however, I would like to develop the capability to
design my own. Here is how I fill in the forecast()
method in Python to do either decimation or interpolation:

ninput_items_required[0] = noutput_items*self.sps  # for
decimation
OR
ninput_items_required[0] = noutput_items/self.sps  # for
interpolation

On running the flowgraph in GRC Console I see TypeError:
'int' object does not support item assignment.

Will appreciate any suggestion to fix this problem.

George



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOLK] Release 2.5.2

[Johannes Demel]

Hi Chris,

The issue arises in an odd combination.

1. you installed VOLK (and cpu_features) to your custom prefix before
2. your custom prefix is currently NOT sourced
3. you try to re-compile with `CMAKE_INSTALL_PREFIX=`

What I've learned so far:
1. It requires special configuration in a submodule to disable installation.
2. CMake tries to be smart and the linker does smth different.

A more complete analysis and a subsequent fix may be nice.

Cheers
Johannes

On 08.09.22 23:40, Chris Vine wrote:

On Sun, 4 Sep 2022 18:41:18 +0200
Johannes Demel  wrote:

Hi everyone!

We have a new VOLK release! We are happy to announce VOLK v2.5.2! We
want to thank all contributors. This release wouldn't have been possible
without them.


Something seems to be amiss when compiling against the internal version
of cpu_features:

   ...
   [ 88%] Built target volk_obj
   [ 89%] Linking C shared library libvolk.so
   /usr/bin/ld: cannot find -lcpu_features: No such file or directory
   collect2: error: ld returned 1 exit status
   make[2]: *** [lib/CMakeFiles/volk.dir/build.make:168: lib/libvolk.so.2.5.2] 
Error 1
   make[1]: *** [CMakeFiles/Makefile2:239: lib/CMakeFiles/volk.dir/all] Error 2
   make: *** [Makefile:146: all] Error 2


smime.p7s
Description: S/MIME Cryptographic Signature

[VOLK] Release 2.5.2

[Johannes Demel]

Hi everyone!

We have a new VOLK release! We are happy to announce VOLK v2.5.2! We 
want to thank all contributors. This release wouldn't have been possible 
without them.


We are happy to announce that our re-licensing effort is complete. This 
has been a long and challenging journey. Being technical: There are 3 
people left (out of 74) who we haven't been able to get in contact with 
(at all), for a total of 4 (out of 1092) commits, 13 (of 282822) 
additions, and 7 (of 170421) deletions. We have reviewed these commits 
and all are simple changes (e.g., 1 line change) and most are no longer 
relevant (e.g., to a file that no longer exists). VOLK maintainers are 
in agreement that the combination -- small numbers of changes per 
committer, simple changes per commit, commits no longer relevant -- 
means that we can proceed with re-licensing without the approval of the 
folks. We will try reaching out periodically to these folks, but we 
believe it unlikely we will get a reply.


This maintainance release is intended to be the last VOLK 2.x release. 
After we completed our re-licensing effort, we want to make a VOLK 3.0 
release soon. VOLK 3.0 will be fully compatible with VOLK 2.x on a 
technical level. However, VOLK 3+ will be released under LGPL. We are 
convinced a license change justifies a major release.


### Contributors

* Aang23 
* Clayton Smith 
* Johannes Demel , 
* Michael Dickens 
* Michael Roe 

### Changes

* Android
- Add Android CI
- Fix armeabi-v7a on Android
* CI
- Update all test jobs to more recent actions
* volk_8u_x4_conv_k7_r2_8u
- Add NEON implementation `neonspiral` via `sse2neon.h`
* Fixes
- Fix out-of-bounds reads
- Fix broken neon kernels
- Fix float to int conversion
* CMake
- Suppress superfluous warning
- Fix Python install path calculation and documentation
* cpu_features
- Update submodule pointer
* VOLK 3.0 release preparations
- Use SPDX license identifiers everywhere
- Re-arrange files in top-level folder
- Update Doxygen and all Doxygen related tasks into `docs`

Re: How can I split a periodic signal?

[Johannes Demel]

Hi all,

since Audacity is targeted at audio samples, it might be interesting to 
have a tool that is more targeted at IQ samples.


I've heard/read about quite a few people who use "inspectrum":
https://github.com/miek/inspectrum
(I hope this is the correct repo.)

A somewhat older tool might be "baudline":
https://www.baudline.com/
(I used it in the past but I'd probably switch to inspectrum nowadays).

Cheers
Johannes


On 25.08.22 20:33, Mike Markowski wrote:

James,

I find an easy approach is to write the signal out as alternating i/q 
binary if it's not already.  That can be read into audacity as stereo 
(File -> Import -> Raw), edited and written back out as raw data without 
header (File -> Export -> Export Multiple, and choose Raw Headerless). 
Don't worry about audacity's sample rate because you're editing raw i/q 
anyway.  This allows editing down to the sample level.


Good luck!
Mike ab3ap

On 8/25/22 1:52 PM, James Wanga wrote:
I'm receiving a phase modulated signal representing a periodic pulsed 
byte that looks something like this:


-|-|||--||-|||---|---|- 



I'm trying to understand how I might split this signal roughly halfway 
between each pulse of activity so I can save each pulse as a separate 
IQ fil, bit like this:


--|-|||--||--

---|||-----

--|---|--

The split does not have to be precise, it only needs to avoid 
bisecting any of the pulses. Here are some things I've tried.- 
Creating a custom block on the receiver that uses a timing interval. 
Unfortunately, the pulses aren't perfectly periodic so eventually this 
causes the split to drift.[...]




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Regarding GNU radio file Sink

[Johannes Demel]

Hi,

I'd like to point out that we maintain a guide on "How to ask questions"
https://wiki.gnuradio.org/index.php?title=ReportingErrors

I'd like to point to our netiquette because of multiple similar postings 
to the mailing list.


Specifically in your case, please share more information on
- what you want to achieve exactly?
- what have you already tried?
- Which resources have you consulted before?
- How is your case different from prior discussions?

e.g. I remember discussions on CSV files and how appropriate they are 
for IQ sample storage. Generally, CSV files are a really bad choice to 
store IQ data.


Cheers
Johannes

On 24.08.22 05:53, debanka giri wrote:

Hi,
       Kindly share how I can save captured signal data to a csv file.

/*Thanks & Regards,
Debanka Giri
Researcher
Indian Institute of Technology
New Delhi-110016*/
/*Mob. No.- 8001471858*/





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOLK] a += b*c ?

[Johannes Demel]

Hi Randall,

in your case,

https://github.com/gnuradio/volk/blob/main/kernels/volk/volk_32f_x2_multiply_32f.h

followed by
https://github.com/gnuradio/volk/blob/main/kernels/volk/volk_32f_x2_add_32f.h

would be the way to go at the moment.
```
volk_32f_x2_multiply_32f(multiply_result, b, c, num_samples);
volk_32f_x2_add_32f(a, a, multiply_result, num_samples);
```

You're welcome to start a new kernel
```
volk_32f_x3_multiply_add_32f(out, a, b, c, num_samples);
```
In fact, it would be a great addition to VOLK.

Cheers
Johannes


On 16.08.22 01:38, Randall Wayth wrote:
Thanks for the suggestions and apologies for not being 100% clear at the 
start.

I'm not looking for a dot product. I'm looking for
a[i] += b[i]*c[i]     specifically for floating point

So it would be the equivalent of IPP's ippsAddProduct_32f.
The application is to apply a window to a set of samples before 
accumulating, to implement a weighted overlap add PFB. In my case the 
samples are real-valued, but I could also see a case for a and b being 
complex, or the case for b being 8 or 16-bit ints with a and c being 
floating point.


Cheers,
Randall


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOLK] a += b*c ?

[Johannes Demel]

Hi,

the kernels are type specific. However, if you want a dot product:


a = \sum_{i=0}^{N-1} b[i]c[i],

https://github.com/gnuradio/volk/blob/main/kernels/volk/volk_32fc_x2_dot_prod_32fc.h


A [i] += B [i] * C [i], for i = 0...N-1


This would implement the above formula:
1.
https://github.com/gnuradio/volk/blob/main/kernels/volk/volk_32fc_x2_multiply_32fc.h
2.
https://github.com/gnuradio/volk/blob/main/kernels/volk/volk_32fc_x2_add_32fc.h

It would be interesting to see how much faster an integrated kernel 
would be.


The ipp `AddProduct function:
https://www.intel.com/content/www/us/en/develop/documentation/ipp-dev-reference/top/volume-1-signal-and-data-processing/essential-functions/arithmetic-functions/addproduct.html

I assume ipp aims for:
https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#ig_expand=3202,3202,3202,3206,3206,3206=_mm256_fmadd_ps

Which version are you looking for?

Cheers
Johannes


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Capturing 2 Level FSK with frequency hopping?

[Johannes Demel]

Hi Peter,

since you're looking at a signal with less than 10MHz bandwidth around 
910MHz, you might have hardware available that is able to capture the 
whole bandwidth. This should be a good starting point.


Besides, the best approach to solve your challenge depends on more 
parameters.


Questions that I'd consider first:
Do you need to process all 6 bands in parallel?
Are all signal sources synchronized? Do they come from the same source?
How large are the guard bands?
How large is the time gap between every sequential hop in a subband?
Do the subbands depend on each other in some way?
Is there a preamble to sync to?
Do you intend to change block parameters at runtime?

It might be interesting to use polyphase filters to divide your ~10MHz 
signal into 6 subbands first. Then use a polyphase filter to separate 
your channels. Or use the Xlating FIR for your subbands. I'd play around 
and observe the effects of each approach.

You might want to use a polyphase filter for all your 6 * 60 channels.

Cheers
Johannes

On 10.07.22 12:18, Peter Lambrechtsen wrote:

Hello,

Excuse my ignorance as I am fairly new to gnuradio but I am trying to 
figure out how best to capture a data stream that is in the ISM band 
that also has frequency hopping.


Channel spacing of 25kHz
It has two data bit rates of 62.5bps and 500bps
Starting at 910.5Mhz and going up to 919.975 and in there it has 6 sub 
bands of 60 channels it hops between sequentially between the 
frequencies in the sub band every 0.4s


I'm wondering what the best approach would be to capture the data and 
figure out when the timing frame was to determine which was the 
initial frame as then it should be able to follow the sequential hopping.


Still trying to work on the blocks to capture all the traffic as I 
haven't figured that out yet as I am just working off the specification 
and trying to understand the Frequency Xlating FIR Filter to at least 
capture one FSK stream to make sure it is sane what I should be 
receiving, then move to the frequency hopping.


Thanks, Peter

Re: How to convert complex float file to complex int 16 in Gnuradio For USRP input...

[Johannes Demel]

Hi,

If you target USRPs, their driver does the complex float 32 to complex 
int 16 conversion. No need for you to do this "manually". If you want to 
use complex int 16 in your flowgraph, there should be converters. VOLK 
includes kernels to convert between these data types as well.
In GRC search for e.g. "complex" and you should have a short list of 
blocks where one should fit your needs.


Cheers
Johannes


On 30.06.22 16:35, sp h wrote:
In Gnuradio there are different types that you can see in the below 
screenshot?


How to convert complex float file to complex int 16 in Gnuradio For USRP 
input I need to convert complex float to complex int...

, My question is how can I do this action? Thanks in advance
Screenshot from 2022-06-30 19-01-27.png

Re: [SOLVED] pybind11 problems, gr::block undefined in gnuradio 3.10

[Johannes Demel]

Hi Tom,

I've seen this error before in conjunction with pybind11. The error 
indicates that the pybind11 version for your GR install and the pybind11 
version for your OOT module differ. Unfortunately, the error message is 
not helpful in that case.
I assume it doesn't hurt to switch to 22.04 and not look back. However, 
the issue got fixed in the process because all older pybind11 versions 
got eliminated.
I ran into this issue when I tried to compile my OOT against a conda 
installed GR version. I had to check which pybind11 version ships with 
conda and make sure that my OOT CMake configuration points to the 
correct version.

GR reports the required pybind11 version with:
```
gnuradio-config-info --pybind
```

Cheers
Johannes

On 15.05.22 23:40, Tom McDermott wrote:


 >>> import hpsdr
Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python3.8/site-packages/gnuradio/hpsdr/__init__.py", 
line 18, in 

     from .hpsdr_python import *
ImportError: generic_type: type "hermesNB" referenced unknown base type 
"gr::block"

 >>>

The only way I found to solve this problem was to stop using Ubuntu 
20.04 Focal and move to Ubuntu 22.04 Jammy.
22.04 seems to have the latest versions of the key tools, it all built, 
and runs correctly.


I suspect this just affects pybind11,  if so folks probably would still 
be able to install the OOT
on the older version of Ubuntu, they just couldn't change anything that 
would require re-binding.


-- Tom, N5EG

Re: Realtime Kernel, UHD 4.0, GNURadio

[Johannes Demel]

Hi Anton,

This guide may help you:
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
I usually use the CPU Governor, Thread Priority Scheduling, Adjust 
Network Buffers, and Adjust Ethernet MTU sections.


I can run flowgraphs at 30.72MSps without hiccups. Thus, I suggest you 
check your host capabilities and probably more important: Check that GR 
is compiled and installed with `CMAKE_BUILD_TYPE=Release`.


Besides, you may want to investigate which thread (and thus GR block) is 
the culprit. A first simple approach would be to use htop and find out 
which thread is close to 100% CPU load. If you change the htop Display 
Options to "Show custom thread names" it should be fairly simple to get 
a better understanding of your issue.


Cheers
Johannes


On 05.05.22 20:52, Dobler, Anton wrote:

Dear community,


I am running UHD 4.0 and GNURadio 3.10 on a Ubuntu 20.04 with a N310 as 
a SDR.



When I execute the benchmark_rate example with DPDK enabled, I do not 
see any under- or overruns even with the sampling rate set to 125 MHz, 
however using GNURadio - DPDK enabled here as well - I do not achieve 
that high sampling rate. The limit seems to be around 30MHz though.



Do you know, apart from using taskset and isolcpus any other possibility 
to achieve higher sampling rates?



Would it be an option to use the realtime kernel available for Ubuntu 
20.04 and is this kernel compatible with GNURadio?



Any help also with regards to the usage of taskset and isolcpus would be 
highly appreciated!



Thank you in advance!


BR,


Anton

Re: Problem using volk_32fc_s32fc_multiply_32fc function with vector params

[Johannes Demel]

Hi George,

yes, you need to add `#include ` to use 
`volk::vector`. A `volk::vector` is a specially templated `std::vector`. 
You still use it with `.data()`.

An example would be:
```
#include 
#include 

...

volk::vector  my_val (240);
volk_32fc_s32fc_multiply_32fc(my_val.data(), my_val.data(), scale, 240);
```

If you look at the `std::vector` docs:
https://en.cppreference.com/w/cpp/container/vector

You can see `std::vector` has a second template argument that defaults 
to `class Allocator = std::allocator`. `volk::vector` provides a 
different `Allocator` for it. Thus, you can use a `volk::vector` just 
like a `std::vector`. Be aware that different template arguments lead to 
different classes and thus, a function that accepts a `std::vector` will 
not accept a `volk::vector` and vice versa.


Cheers
Johannes

On 03.05.22 16:01, George Edwards wrote:

Hi Johannes,

Thank you very much! Thanks for also providing an alternative solution 
if I were to define the vector as a volk vector. Please allow me to 
confirm my understanding of how to use volk vectors. So with my current 
definition using std::vector  my_val (240); you and Brian 
suggested the solution should look as follows:

volk_32fc_s32fc_multiply_32fc(my_val.data(), my_val.data(), scale, 240);

Based on your volk vector suggested solution, my interpretation is that 
I would write my code as follows:

volk::vector  my_val (240);

volk_32fc_s32fc_multiply_32fc(my_val, my_val, scale, 240); // Or do I 
need to use _val
Also, my current code has the following: #include do I in 
addition need to include #include   ?


Thank you very much!
George


On Tue, May 3, 2022 at 3:35 AM Johannes Demel <mailto:de...@ant.uni-bremen.de>> wrote:


Hi George,

All VOLK functions require pointers as you already noticed. You can
access the underlying data structure of a vector via its `.data()`
method as Brian noted.
Moreover, you can use `volk::vector` if you want your vectors to be
aligned. `volk::vector` is almost a `std::vector` but uses its own
allocator that ensures alignment.
`volk::vector` is available in `volk/volk_alloc.hh`. Since it is a C++
only feature.

Cheers
Johannes

On 03.05.22 04:28, George Edwards wrote:
 > Hello GNURadio Community,
 >
 > I am having a problem using the above function with
vector parameters.
 > If I use an array say:
 > gr_complex my_val[240];
 > volk_32fc_s32fc_multiply_32fc(my_val, my_val, scale, 240);
 >
 > It works! But if I change my_val to be a vector like below, it fails:
 > std::vector  my_val(240);
 >
 > The reason I need to use a vector is that with arrays, the size
must be
 > known at compile time, while with vectors one can build it at
runtime.
 >
 > I would appreciate any suggestions.
 > Thank you!
 >
 > George

Re: Problem using volk_32fc_s32fc_multiply_32fc function with vector params

[Johannes Demel]

Hi George,

All VOLK functions require pointers as you already noticed. You can 
access the underlying data structure of a vector via its `.data()` 
method as Brian noted.
Moreover, you can use `volk::vector` if you want your vectors to be 
aligned. `volk::vector` is almost a `std::vector` but uses its own 
allocator that ensures alignment.
`volk::vector` is available in `volk/volk_alloc.hh`. Since it is a C++ 
only feature.


Cheers
Johannes

On 03.05.22 04:28, George Edwards wrote:

Hello GNURadio Community,

I am having a problem using the above function with vector parameters. 
If I use an array say:

gr_complex my_val[240];
volk_32fc_s32fc_multiply_32fc(my_val, my_val, scale, 240);

It works! But if I change my_val to be a vector like below, it fails:
std::vector  my_val(240);

The reason I need to use a vector is that with arrays, the size must be 
known at compile time, while with vectors one can build it at runtime.


I would appreciate any suggestions.
Thank you!

George

Re: RX/TX switching

[Johannes Demel]

Hi Fabien,

Personally, I use PDUs to control when TX starts. GR 3.10 integrated a 
lot more of these.

https://github.com/gnuradio/gnuradio/tree/main/gr-pdu
Besides, the gr-pdu_utils OOT might be a good reference.
https://github.com/sandialabs/gr-pdu_utils
It mentions SOB/EOB in their docs.
EOB is required to signal that a burst ends. I'm not sure if a SOB is 
really required or if a USRP would just "wake up" and start transmitting.


I suggested the SOB/EOB mechanism because it sounds like you transmit 
long bursts. Short bursts might be handled via tagged streams. The UHD 
sink would handle these cases. By short bursts I mean <=4k complex samples.


Generally, the idea is: trigger transmission with a PDU block, use a PDU 
to tagged stream block to fead you data into the GR streaming interface. 
Then make sure to signal to the UHD sink when a burst ends.


Cheers
Johannes

On 04.03.22 12:50, Fabien PELLET wrote:

Hi Johannes,

Yes this is exactly my problem : after unlocking the flowgraph, I get 
some underruns (only, no overrun).


Do you have an example of code using EOB/SOB ? Ok for sending EOB before 
locking but is it necessary to send a SOB also and when ?


Your suggestion of idling the TX flowgraph is something I looked for 
during several days but I never found how. Indeed, if I do not connect a 
source and a sink at each ends, gnuradio will fail to run. How to stop 
feeding one branch of a flowgraph ? Do you have examples of codes for 
doing that ?


Thanks for your help,

Fabien, F4CTZ.

Le 04/03/2022 à 12:03, Johannes Demel a écrit :

Hi Fabien,

do those underruns occur after you lock/unlock and switch from TX to 
RX or vice versa? Do you see overruns as well?


I'd assume the USRP expects a constant sample flow and even a short 
interuption, like your lock/unlock task interrupts that flow.
Still assuming this is the root cause, you might fix this by sending 
an EOB signal to the USRP before you lock the flowgraph.


Besides, the whole SOB/EOB mechanism might help you with your issue. 
You can just stop the TX flowgraph portion while you don't need it. By 
stop I mean, the flowgraph is not fed any new samples and just idles.
As an added bonus, you minimize LO leakage which might be an issue for 
your RX flowgraph. I know this is a more intrusive change.


Cheers
Johannes

On 04.03.22 10:45, Fabien PELLET wrote:

Hello again,

I build a flowgraph in C++ with an RX chain and a TX chain. I'm using 
a USRP N210. When I'm in RX, the TX chain is connected to a constant 
zero source and feed a null sink and the RX chain is connected to 
USRP source and sink. When I'm in TX, it is the opposite.


I have to keep the two chains running at the same time for switching 
speed purpose and do not have to stop the flowgraph and restart it. 
So for my switching, I just lock the top block and unlock it after.


If I always stay in RX, I have no underrun. Same thing in TX. My 
problem is that when I lock and unlock the flowgraph, I get a lot of 
underruns.


As a test, I remove the TX part of my flowgraph and only keep the RX 
part and I try do some lock/unlock sometimes : same problem with 
underruns.


How to do lock/unlock safely in C++ to avoid underruns ?

Thanks for the help,

Best regards,

Fabien, F4CTZ.

Re: RX/TX switching

[Johannes Demel]

Hi Fabien,

do those underruns occur after you lock/unlock and switch from TX to RX 
or vice versa? Do you see overruns as well?


I'd assume the USRP expects a constant sample flow and even a short 
interuption, like your lock/unlock task interrupts that flow.
Still assuming this is the root cause, you might fix this by sending an 
EOB signal to the USRP before you lock the flowgraph.


Besides, the whole SOB/EOB mechanism might help you with your issue. You 
can just stop the TX flowgraph portion while you don't need it. By stop 
I mean, the flowgraph is not fed any new samples and just idles.
As an added bonus, you minimize LO leakage which might be an issue for 
your RX flowgraph. I know this is a more intrusive change.


Cheers
Johannes

On 04.03.22 10:45, Fabien PELLET wrote:

Hello again,

I build a flowgraph in C++ with an RX chain and a TX chain. I'm using a 
USRP N210. When I'm in RX, the TX chain is connected to a constant zero 
source and feed a null sink and the RX chain is connected to USRP source 
and sink. When I'm in TX, it is the opposite.


I have to keep the two chains running at the same time for switching 
speed purpose and do not have to stop the flowgraph and restart it. So 
for my switching, I just lock the top block and unlock it after.


If I always stay in RX, I have no underrun. Same thing in TX. My problem 
is that when I lock and unlock the flowgraph, I get a lot of underruns.


As a test, I remove the TX part of my flowgraph and only keep the RX 
part and I try do some lock/unlock sometimes : same problem with underruns.


How to do lock/unlock safely in C++ to avoid underruns ?

Thanks for the help,

Best regards,

Fabien, F4CTZ.

Re: Adding external libs to an OOT block

[Johannes Demel]

Hi Dave,

fortunately, the process got simpler.

For now, let's assume the library you want to use supports CMake. In my 
experience, every library you can install via `sudo apt install 
lib...-dev` supports CMake.


Let's assume you want to use libfmt, then you need:
`find_package(fmt REQUIRED)`
in your top-level CMakeLists.txt.

In your `/lib/CMakeLists.txt` you need to add:
`target_link_libraries({YOUROOTMODULENAME} gnuradio::gnuradio-runtime 
fmt::fmt)`.


That's it.

In case of VOLK, the 2 entries are:
`find_package(Volk REQUIRED)`
and
`Volk::volk`

The `REQUIRED` option let's CMake fail if it can't find the necessary 
information. Otherwise, you'd have to check everything yourself.


You might have noticed that you can e.g. use VOLK without the CMake 
entries in your OOT. That's because you include it with the GNU Radio 
CMake config.


Cheers
Johannes

On 22.02.22 19:06, Ryan Volz wrote:

Hi Dave,

On 2/22/22 11:34 AM, David Cherkus wrote:
So, I found 
https://stackoverflow.com/questions/48562304/gnuradio-c-oot-extrernal-so-library 
 
which is a very good answer to how to get your OOT block to link to a 
shared library from another package.


    /As pointed out by the answer of Marcus Müller below I did not 
link properly. In fact *one has to edit three different cmake files in 
three places to add an external dynamically loaded library (.so) to an 
OOT module in GNURadio*. I try to explain briefly what to do:

    /

 1. /Put a find_package(LIBNAME) in the CMakeLists.txt in the 
base directory of the OOT module./
 2. /Corresponding to that a FindLIBNAME.cmake file in the 
cmake module path is necessary. This file has the purpose to implement 
the search for include directories and library files (.so files)./
 3. /Once found the path to the library has to be used with 
target_link_libraries(...) in lib/CMakeLists.txt (linking)./
 4. /The include file path, i.e. LIBNAME.h has to be added as 
include directory using include_directories(...) in the CMakeLists.txt 
in the base directory of the module.

    /

    /With ldd it is possible to find out if the external library 
is linked correctly./

    /
    *ldd /usr/local/lib/YOURLIB.so*/

Am wondering if this is documented on the GNUradio web site?  I could 
use a bit more info, but will give it a go anyway.  I did the C++ 
tutorial ( 
https://wiki.gnuradio.org/index.php?title=Guided_Tutorial_GNU_Radio_in_C%2B%2B 
  
) and this was the very next thing I wanted to do, and I presume many 
others as well.   I know it's hard to know where to draw the line on 
teaching enough vs too much, but I think this is a pretty frequent use 
case, no?  Note that I am teaching myself cmake on the fly.  That's 
OK, I just taught myself enough C++ to understand the tutorial on the 
fly as well.


Regards,
Dave.


This can be easier or harder depending on how well the library you want 
to link with supports CMake. In more detail, you may or may not have to 
do step 2 of the instructions above, and it may be possible to skip 4 as 
well if the library's include paths are part of the target that you 
"link" with in step 3. So I think it is most helpful to ask: what 
library specifically are you needing to link with?


In general I think covering how to use CMake is best left to the CMake 
documentation, but the GNU Radio tutorials could probably benefit from a 
simple example of linking with a "nice" external library. (That's if 
they don't already include that somewhere, and I can't say that I've 
looked!)


Cheers,
Ryan

Re: [VOLK] Release 2.5.1

[Johannes Demel]

Hi all,

while I did not run the ABI compliance checker to compare 2.5.0 vs 2.5.1 
specifically, it is simple and can be done with this tool:

https://lvc.github.io/abi-compliance-checker/#ABI_Dumper
So far, we were able to keep the ABI compatible across VOLK 2.x.
Also, we didn't change any function signatures of existing functions.

It might be a worthwhile undertaking to add an ABI compliance checker to 
our CI.


The VOLK library is written in C. Here, we rely on C11. Also, we require 
cpu_features because detecting such features across systems and 
architectures is terribly difficult.


Then, the questions are: Why Boost, why C++17 at all?
We use tools around our library. The volk_profile utility and our tests 
are written in C++. Here, we need to write the profile results to a 
file. In the past, we used `boost::filesystem` to achieve this. 
`boost::filesystem` basically became part of C++17 with 
`std::filesystem`. Thus, we use `std::filesystem` now.


Cheers
Johannes

On 13.02.22 12:08, Jeff Long wrote:

Fons - filesystem is used for the volk_profile utility.

Chris - do not assume ABI compatibility. A number of small things have 
changed in ".h" files.


On Sat, Feb 12, 2022 at 6:19 PM Chris Vine <mailto:vine24683...@gmail.com>> wrote:


On Sat, 12 Feb 2022 11:40:26 +0100
Johannes Demel mailto:de...@ant.uni-bremen.de>> wrote:
 > Hi everyone!
 >
 > You can find the news at
https://www.libvolk.org/release-v251.html
<https://www.libvolk.org/release-v251.html> as well.
 >
 > We have a new VOLK release! We are happy to announce VOLK v2.5.1! We
 > want to thank all contributors. This release wouldn't have been
possible
 > without them.

Hi,

Is this ABI compatible with volk-2.5.0 (or put another way, if I
upgrade from volk-2.5.0 will I need to recompile gnuradio)?

Chris

[VOLK] Release 2.5.1

[Johannes Demel]

Hi everyone!

You can find the news at https://www.libvolk.org/release-v251.html as well.

We have a new VOLK release! We are happy to announce VOLK v2.5.1! We 
want to thank all contributors. This release wouldn't have been possible 
without them.


The list of contributors is pretty long this time due to a lot of 
support to relicense VOLK under LGPL. Currently, we are "almost there" 
but need a few more approvals, please support us. We thank everyone for 
their support in this effort.


We use `cpu_features` for a while now. This maintainance release should 
make it easier for package maintainers, FreeBSD users, and M1 users to 
use VOLK. Package maintainers should be able to use an external 
`cpu_features` module. For everyone else, `cpu_features` received 
support for M1 and FreeBSD.


You can find [VOLK on Zenodo DOI: 
10.5281/zenodo.3360942](https://doi.org/10.5281/zenodo.3360942).
We started to actively support Zenodo now via a `.zenodo.json` file. 
This might come in handy for people who use VOLK in publications. As a 
contributor, if you want more information about yourself added to VOLK, 
feel free to add your ORCiD and affiliation.


In the past, we relied on Boost for several tasks in `volk_profile`. For 
years, we minimized Boost usage to `boost::filesystem`. We mostly 
switched to C++17 `std::filesystem` years ago. The last distribution in 
our CI system that required Boost to build VOLK, was Ubuntu 14.04. Thus, 
now is the time to remove the Boost dependency completely and rely on 
C++17 features.


Some VOLK kernels are untested for years. We decided to deprecate these 
kernels but assume that nobody uses them anyways. If your compiler spits 
out a warning that you use a deprecated kernel, get in touch. Besides, 
we received fixes for various kernels. Especially FEC kernels are 
notoriously difficult to debug because issues often pop up as 
performance regressions.


Finally, we saw a lot of housekeeping in different areas. Scripts to 
support us in our LGPL relicensing effort, updated docs, and updated our 
code of conduct. We could remove some double entries in our QA system 
and fixed a `volk_malloc` bug that ASAN reported.
Finally, we switched to the Python `sysconfig` module in our build 
system to ensure Python 3.12+ does not break our builds.




### Contributors

* A. Maitland Bottoms 
* Aang23 
* AlexandreRouma 
* Andrej Rode 
* Ben Hilburn 
* Bernhard M. Wiedemann 
* Brennan Ashton 
* Carles Fernandez 
* Clayton Smith 
* Doug 
* Douglas Anderson 
* Florian Ritterhoff 
* Jaroslav Škarvada 
* Johannes Demel 
* Josh Blum 
* Kyle A Logue 
* Luigi Cruz 
* Magnus Lundmark 
* Marc L 
* Marcus Müller 
* Martin Kaesberger 
* Michael Dickens 
* Nathan West 
* Paul Cercueil 
* Philip Balister 
* Ron Economos 
* Ryan Volz 
* Sylvain Munaut 
* Takehiro Sekine 
* Vanya Sergeev 
* Vasil Velichkov 
* Zlika 
* namccart 
* dernasherbrezon 
* rear1019 


### Changes

* Kernels
- Fixup underperforming GENERIC kernel for volk_8u_x4_conv_k7_r2_8u
- volk_32fc_x2_conjugate_dot_prod_32fc: New generic implementation
- Add volk_32f(c)_index_min_16/32u
- Fix volk_32fc_index_min_32u_neon
- Fix volk_32fc_index_min_32u_neon

* Misc
- Fix volk_malloc alignment bug
- qa: Remove repeating tests
- python: Switch to sysconfig module
- deprecate: Add attribute deprecated
- deprecate: Exclude warnings on Windows
- docs: Update docs
- Add the list of contributors agreeing to LGPL licensing
- Add a script to count the lines that are pending resubmission
- Testing: Add test for LGPL licensing
- Update CODE_OF_CONDUCT file

* Boost
- boost: Remove boost dependency
- c++: Require C++17 for std::filesystem

* cpu_features
  cpu_features: Update submodule pointer
  cpu_features: Make cpu_features submodule optional

* Zenodo
  zenodo: Add metadata file
  zenodo: Re-organize .zenodo.json

[VOLK] Help needed for PR reviews before release

[Johannes Demel]

Hi all,

today I'd like to ask for help to review some PRs before we can do a 
VOLK 2.5.1 release. I'd like to do a release ASAP to still have time to 
get these changes into large distro releases.


I'd like to see better support for automatic publication on Zenodo:
https://github.com/gnuradio/volk/pull/559
you can find prior VOLK releases on Zenodo:
https://zenodo.org/record/4903136
This PR is probably mostly interesting for academia to make it easier to 
cite VOLK if you use it in your work. At least I consider it very 
interesting.
You can add more info about yourself if you like. e.g. ORCID and 
affiliation.


This fix should make it easier for package maintainers to use a system 
cpu_features package:

https://github.com/gnuradio/volk/pull/558

This fix should boost convolutional decoder performance.
https://github.com/gnuradio/volk/pull/475
Since changes to FEC code that affect FER/BER performance are 
notoriously difficult to verify, It'd be great to have more people 
testing this fix. However, this fix is already in use by some users with 
good results.


Some rather obscure kernels are untested for years and probably unused. 
https://github.com/gnuradio/volk/pull/555
I'd like to know if this deprecation approach does not break things for 
anyone.


We need to replace `distutils` in our build system because the functions 
we use are deprecated.

https://github.com/gnuradio/volk/pull/554


These two PRs concern our Boost dependency:
https://github.com/gnuradio/volk/pull/548
https://github.com/gnuradio/volk/pull/557
Either we decide to remove obsolete code in #548 and update our 
requirements, or we finally drop our Boost dependency in #557.
Boost is an optional dependency for old systems that lack 
`std::filesystem` support. The latest CI that required Boost was for 
Ubuntu 14.04. Starting with Ubuntu 16.04, we were able to use 
`std::experimental::filesystem` and drop our Boost dependency. Thus, it 
might be time to finally drop our Boost dependency.


If you have time to look at those PRs and review them, that'd be great.

Cheers
Johannes

--
Johannes Demel M.Sc.
Research Engineer

Re: GNU Radio 3.9.3.0 Python basic block - issues with forecast and produce

[Johannes Demel]

Hi Patric,

first off, the `consume_each` call needs to go behind any read on the 
input buffer. You really tell the system at this point: I'm finally done 
with these items, do whatever. Since GR is a multi-threaded system, this 
may cause trouble because the samples you want to read are already 
overwritten.


The best place to check for specifics about Python blocks is here:
https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/python/gnuradio/gr/gateway.py

This is the interface that is implemented. The `forecast` method is 
implemented in L153ff. It is different from the C++ version.


I guess Python blocks (and embedded Python blocks even more) are 
considered simple blocks for beginners. Unfortunately, this is not how 
they're treated by developers. Also, they are leaky abstractions over 
their C++ originals.


To rephrase the new issue:
- You insert a known pattern and expect corresponding output.
- Actual output is all zeros. (The screenshot is missing).

So let's comment on your `general_work`.

> def general_work(self, input_items, output_items):
>  # Firstly check, if input_items has a sufficient amount of items
>  if len(input_items[0]) >= self.buffer_len:
>  # Then consume exactly self.buffer_len items
>  self.consume_each(self.buffer_len)
`consume_each` should go after the last use of `input_items`.

>  # Now only output a fraction of the input items, say the first
> self.out_items, on output port[0]
>  output_items[0]  = input_items[0][:self.out_items]
This is probably the line causing issues. Try
`output_items[0][0:self.out_items] = input_items[0][0:self.out_items]`
The difference is the left hand indexing. Now, you write items to 
positions in an array. Previously, you overwrote the array and replaced 
it with a new one. Thus, the output buffer was still full of zeros.


This behavior is very unpythonic. It makes perfect sense though from a 
C++ block perspective. You pass pointers or references to a data 
structure and write data to it in C++. You wouldn't normally do that in 
Python.


Cheers
Johannes

On 23.01.22 19:27, Patric Müller wrote:

Hello everyone and hello Johannes,

first of all, a huge thanks for the quick and detailed response, it is 
really helpful. After implementing your suggested changes and additional 
tinkering, I am still facing two issues:



The `forecast` method expects estimates. The scheduler will call
`general_work` anyways at some point, if the system is unable to fulfill
your forecast requirement. `set_output_multiple` is much more strict.
In your case I'd start with:
`ninput_items_required[0] = noutput_items`


I've changed the `forecast`method accordingly, however I still get the 
same errors. If I use

`ninput_items_required[0] = noutput_items`
then I receive:
`TypeError: 'int' object does not support item assignment`
I've checked the type and value of `ninput_items_required` and sure 
enough, it is of `` and has a value of `1`.


My next thought was that it may not be a , since I only 
have one input port, so I also tried:

`ninput_items_required = noutput_items`
This yields me with:
`Unable to cast Python instance to C++ type (compile in debug mode for 
details)`


For now and since it isn't strictly necessary, I've commented the 
`forecast` method.




At the end of `general_work` report these values to the system:
- consumed items via `consume_each`
- produced items via `return integer_with_number_of_consumed_items`.


I have changed my code accordingly. My `general_work` function now looks 
like this:


def general_work(self, input_items, output_items):
     # Firstly check, if input_items has a sufficient amount of items
     if len(input_items[0]) >= self.buffer_len:
     # Then consume exactly self.buffer_len items
     self.consume_each(self.buffer_len)
     # Now only output a fraction of the input items, say the first 
self.out_items, on output port[0]

     output_items[0]  = input_items[0][:self.out_items]

     else:
     # if we do not have enough input_items, set empty output
     output_items[0] = []

     # finally, return len(output_items[0]), which is either equal to 
`out_items` or `0`

     return len(output_items[0])


It runs and I did some tests. I have created a signal of length 1024, 
which is composed of a random sequence with length 312 and a cosine 
signal with a length of 712 both muxed together. Next follows the python 
block and the signal is compared before and after by using time sinks.

Screenshot of the flowgraph:



I would expect that I should only observe the random sequence (first 312 
samples) in the `processed signal` time sink. However the time sink only 
shows zeros, which is probably due to a coding error.
In order to investigate, I took a look at the content of 
`output_items[0]` and also at the length. The length is 312, which seems 
fine, since I specified it with `self.out_items`. The contents also seem 
fine, it is definitely not 

Re: GNU Radio 3.9.3.0 Python basic block - issues with forecast and produce

[Johannes Demel]

Hi Patric,

since your goal is to produce a variable number of output items, your 
`general_work` approach seems to be the correct one.
I mean "variable number of output items" in the sense that there is no 
fixed relation between the number of input items to the number of output 
items. Just for reference.


`WORK_CALLED_PRODUCE` is one of those "magic values" that are defined 
somewhere in the system. I've never personally used it in any block.


It is documented here:
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html

The function is found here:
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#aa5581727d057bdd8113f8b2a3fc5bd66

I use `bpython3` to explore Python methods etc. In your case, I expect 
that `self.WORK_CALLED_PRODUCE` should be available.


BUT: Don't use `produce`! In your case use:
`return self.buffer_len`

Why? Because the all the buffer pointer updates will be handled after 
you return from `general_work`. The `produce` method exists for cases 
where you have multiple output buffers and want to produce different 
numbers of output items. e.g 5 samples on `output_items[0]` and 25 
samples on `output_items[1]`.


In your case, you `return 0` which tells the scheduler that you did not 
produce any items.


More generally, try to minimize calls to `consume`/`produce`. Keep track 
of the number of samples your `general_work` consumes and how many 
samples you've written to your output buffer. At the end of 
`general_work` report these values to the system:

- consumed items via `consume_each`
- produced items via `return integer_with_number_of_consumed_items`.

The `forecast` method expects estimates. The scheduler will call 
`general_work` anyways at some point, if the system is unable to fulfill 
your forecast requirement. `set_output_multiple` is much more strict.

In your case I'd start with:
`ninput_items_required[0] = noutput_items`
which might be inefficient. But you can update it with better forecasts 
later. Talking about efficiency: I'd only worry about efficiency in C++ 
blocks. Python blocks incur quite a penalty.


Cheers
Johannes

On 21.01.22 15:14, Patric Müller wrote:

Hello everyone,

I am currently trying to create a basic block similar to this issue:
https://stackoverflow.com/questions/68289222/gnu-radio-buffer-size

Some software and hardware info:
GNU Radio version: 3.9.3.0
Python version: 3.9.7
OS: Ubuntu 20.04

I always want to work on the same number of items, say 1024. Now I would 
like to use up all of the items, but I want to produce something between 
say 500 - 1500 items.
For now, I would like to create a simple block with one input and one 
output, which consumes a set number of items and outputs only a fraction 
of those incoming items in order to understand it better.


Therefore I started with a general block and wanted to change 
ninput_items_required[0].
However, ninput_items_required is an integer. Trying to directly change 
this integer values results in:


Unable to cast Python instance to C++ type (compile in debug mode for 
details)



My second question is about the produce() function. If it is used, 
general_work() should return

WORK_CALLED_PRODUCE
but how exactly? After calling produce() and telling the scheduler how 
many items are produced, can I then change output_items[0]?


My attempt at the forecast() function and general_work() is provided 
below. General suggestions/hints or a basic example would be helpful and 
immensely appreciated.
If additional background is required, let me know and I will gladly 
provide more information.



     def forecast(self, noutput_items, ninput_items_required):
     # Estimate, that we will always need self.buffer_len items on 
input port [0]

     ninput_items_required[0] = self.buffer_len


     def general_work(self, input_items, output_items):
         # Firstly check, if input_items has a sufficient amount of items
     if len(input_items[0]) >= self.buffer_len:
     # Then consume exactly self.buffer_len items on input_port[0]
     self.consume(0, self.buffer_len)
     # Now I would like to only output a fraction of the input 
items

             # say the first self.out_items, on output port[0]
     self.produce(0, self.out_items)
     # Do I set my output_items[0] here?
     # Now I only need to return WORK_CALLED_PRODUCE, but how exactly?
     return 0


Kind regards,
Patric Müller

Re: VOLK C++ core

[Johannes Demel]

 of vectorized code.


I would be very happy to see VOLK move to C++ (or at least provide 
wrappers). I strongly advocate for using C++20 -- std::span, variadic 
arguments, lambdas etc. seem tailor-made for VOLK. Runtime dispatching 
could be positively elegant, compared to how it must be done in C. And 
C++20 finally makes C++ a much less Lovecraftian nightmare of a 
language than the one I learned from Stroustrop.


Nick

    Re: RFC: can we have something like a wiki page (maybe on the VOLK 
repo?) to collect

    these
    comments?

    You mention spans, so C++-VOLK would be >= C++20?

    Cheers,
    Marcus

    On 21.12.21 10:55, Johannes Demel wrote:
 > Hi everyone,
 >
 > today I'd like to propose an idea for the future of VOLK. 
Currently, VOLK is a C

    library
 > with a C++ interface and tooling that is written in C++.
 >
 > I propose to make VOLK a C++ library. Similar to e.g. UHD, we 
can add a C interface if

 > the need arises.
 >
 > This email serves as a request for comments. So go ahead.
 >
 > Benefits:
 > - sane std::complex interface.
 > - same compilation mode on all platforms.
 > - Better dynamic kernel load management.
 > - Option to use std::simd in the future
 > - Less manual memory management (think vector, ...).
 >
 > Drawbacks:
 > - It is a major effort.
 > - VOLK won't be a C project anymore.
 >
 > Why do I propose this shift?
 > VOLK segfaults on PowerPC architectures. This issue requires a 
breaking API change

    to be
 > fixable. I tried to update the API to fix this isse.
 > https://github.com/gnuradio/volk/pull/488 
<https://github.com/gnuradio/volk/pull/488>

 > It works with GCC and Clang but fails on MSVC.
 > One might argue that PowerPC is an obscure architecture at this 
point but new
 > architectures might cause the same issue in the future. Also, 
VOLK tries to be

    portable
 > and that kind of issue is a serious roadblock.
 >
 > How did we get into this mess?
 > The current API is a workaround to make things work for a 
specific compiler: MSVC.

    MSVC
 > does not support C `complex.h` at all. The trick to make things 
work with MSVC is:

 > compile VOLK in C++ mode and pretend it is a C++ library anyways.
 > In turn `volk_complex.h` defines complex data types differently 
depending if VOLK is
 > included in C or C++. Finally, we just hope that the target 
platform provides the same
 > ABI for C complex and C++ complex. C complex and C++ complex 
are not compatible.

 > However, passing pointers around is.
 > Thus, the proposed change does not affect Windows/MSVC users 
because they were

    excluded
 > from our C API anyways. The bullet point: "same compilation 
mode on all platforms"

 > refers to this issue.
 >
 > Proposed timeline:
 > Together with our re-licensing effort, we aim for a VOLK 3.0 
release. VOLK 3.0 is a

    good
 > target for breaking API changes.
 >
 > Effects:
 > I'd like to make the transition to VOLK 3.0 as easy as 
possible. Thus, I'd like to

    keep
 > an interface that hopefully doesn't require any code changes 
for VOLK 2.x users. A
 > re-built of your application should be sufficient. However, 
we'd be able to adopt a

 > C++-ic API as well. e.g. use vectors, spans etc.
 >
 > The current implementation to detect and load the preferred 
implementation at

    runtime is
 > hard to understand and easy to break. C++ should offer more 
accessible tools to make

 > this part easier.
 >
 > What about all the current kernels?
 > We'd start with a new API and hide the old kernel code behind 
that interface. We

    come up
 > with a new implementation structure and how to load it. Thus, 
we can progressively

 > convert to "new-style" implementations.
 >
 > Another bonus: std::simd
 > Currently, std::simd is a proposal for C++23. Making VOLK a C++ 
lib would allow us to
 > eventually use std::simd in VOLK and thus make Comms DSP 
algorithms more optimized on

 > more platforms.
 >
 > Cheers
 > Johannes
 >

VOLK C++ core

[Johannes Demel]

Hi everyone,

today I'd like to propose an idea for the future of VOLK. Currently, 
VOLK is a C library with a C++ interface and tooling that is written in C++.


I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a 
C interface if the need arises.


This email serves as a request for comments. So go ahead.

Benefits:
- sane std::complex interface.
- same compilation mode on all platforms.
- Better dynamic kernel load management.
- Option to use std::simd in the future
- Less manual memory management (think vector, ...).

Drawbacks:
- It is a major effort.
- VOLK won't be a C project anymore.

Why do I propose this shift?
VOLK segfaults on PowerPC architectures. This issue requires a breaking 
API change to be fixable. I tried to update the API to fix this isse.

https://github.com/gnuradio/volk/pull/488
It works with GCC and Clang but fails on MSVC.
One might argue that PowerPC is an obscure architecture at this point 
but new architectures might cause the same issue in the future. Also, 
VOLK tries to be portable and that kind of issue is a serious roadblock.


How did we get into this mess?
The current API is a workaround to make things work for a specific 
compiler: MSVC. MSVC does not support C `complex.h` at all. The trick to 
make things work with MSVC is: compile VOLK in C++ mode and pretend it 
is a C++ library anyways.
In turn `volk_complex.h` defines complex data types differently 
depending if VOLK is included in C or C++. Finally, we just hope that 
the target platform provides the same ABI for C complex and C++ complex. 
C complex and C++ complex are not compatible. However, passing pointers 
around is.
Thus, the proposed change does not affect Windows/MSVC users because 
they were excluded from our C API anyways. The bullet point: "same 
compilation mode on all platforms" refers to this issue.


Proposed timeline:
Together with our re-licensing effort, we aim for a VOLK 3.0 release. 
VOLK 3.0 is a good target for breaking API changes.


Effects:
I'd like to make the transition to VOLK 3.0 as easy as possible. Thus, 
I'd like to keep an interface that hopefully doesn't require any code 
changes for VOLK 2.x users. A re-built of your application should be 
sufficient. However, we'd be able to adopt a C++-ic API as well. e.g. 
use vectors, spans etc.


The current implementation to detect and load the preferred 
implementation at runtime is hard to understand and easy to break. C++ 
should offer more accessible tools to make this part easier.


What about all the current kernels?
We'd start with a new API and hide the old kernel code behind that 
interface. We come up with a new implementation structure and how to 
load it. Thus, we can progressively convert to "new-style" implementations.


Another bonus: std::simd
Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib 
would allow us to eventually use std::simd in VOLK and thus make Comms 
DSP algorithms more optimized on more platforms.


Cheers
Johannes

Re: Peaks when increasing the FFT lenght ofdm example

[Johannes Demel]

Hi Pedro,

we'd need more info to tell why you observe these peaks. How large are 
your input packets? Do they span multiple OFDM symbols? How many 
subcarriers are active?


Your peaks hint at some kind of repetition or lot's of zeros.

Cheers
Johannes


On 14.12.21 13:07, Pedro Viegas wrote:

Hi everyone,

I'm having a problem when I increase the number of carriers from 64 to 
512 in the gnuradio OFDM example. When the number of carriers is 512, 
the complex envelope of the signal in the time domain has some peaks, 
which I can not have for the test I'm trying to make. Can anyone tell 
why there are those peaks and how I get rid of them?
A possible cause for the peaks, in my opinion, can be the fixed frame 
len of the header, that is filled with zeros when the FFT size 
increases, resulting in a peak in the beginning of each frame because of 
the ifft block. If this is the problem, how can I change that frame len?
To better show what I'm saying, there is an image on the attachments of 
the complex envelope with the peaks.


Thanks in advance,
Pedro Viegas

Re: Does complex conjugate invert IQ ?

[Johannes Demel]

Hi,

I assume the "Swap IQ" block is exactly what you're looking for.
https://wiki.gnuradio.org/index.php/Swap_IQ

Cheers
Johannes

On 13.12.21 16:39, Cyrille Morin wrote:

Hi,

You could use a "Complex to Float" to separate the I and Q components, 
followed by a "Float to Complex", inverting the re and im inputs.



Le 13/12/2021 à 16:31, Rachida SAROUI a écrit :
Thank you for responding, but what I meant by invert is swapping the I 
and Q components of the signal.


Le lun. 13 déc. 2021 à 16:25, Fabian Schwartau > a écrit :


Complex conjugate only inverts the imaginary (Q) part of the signal.
If you want to invert both, just multiply with -1.

Am 13.12.21 um 16:22 schrieb Rachida SAROUI:
> Hi everyone,
>
> I need to invert the I and Q of a complex signal. Does the block
complex
> conjugate do the job?
>
> Thank you
>

Re: Questions On GNU Radio FFT Data logging

[Johannes Demel]

Hi Zen Chen,

I add the mailing list to the discussion again. Please reply to the 
mailing list for all mailing list discussions.


This is an example for a UDP client/server
https://pythontic.com/modules/socket/udp-client-server-example

Your visualization app is probably a server waiting for your GNU Radio 
flowgraph (the client) to send data.


Cheers
Johannes

On 13.12.21 03:38, Zen Chen wrote:

Hi Demel,

I sort of get what you meant . How do I read the data from UDP sink ? 
That is one of my questions.


Regards,
Chen Chong Zhi

On Fri, 10 Dec 2021 at 19:49, Johannes Demel <mailto:de...@ant.uni-bremen.de>> wrote:


Hi Chong Zhi,

I assume you want to observe the FM band ~90MHz to ~100MHz is that
correct?

If you want to listen to audio, have a look at gr-rds.
https://github.com/bastibl/gr-rds <https://github.com/bastibl/gr-rds>
It helps quite a bit more to understand FM.

Since this discussion seems to have started in the GR Matrix chat, I
infer you actually want to re-implement the Qt GUI Frequency Sink block
outside of GNU Radio.
Further, this needs to happen online.

As Martin mentioned, at your current sample rate a CSV is a bad choice.
If CSV is a hard requirement, sent the resulting CSV to the person
requesting it and ask them to open it. I just hope they understand the
issue after their spreadsheet visualization tool crashed/is
unresponsive
or anything else.

The file format is explained in the GR wiki, as Marcus pointed out.

https://wiki.gnuradio.org/index.php/File_Sink#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F

<https://wiki.gnuradio.org/index.php/File_Sink#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F>

Let's assume you use a binary file and want to open in in Python, in
your case this would be
```
import numpy as np
samples = np.fromfile('your_file.cdat', dtype=np.complex64)
```
Please mind that the File extension (.cdat) is an arbitrary choice. In
your flowgraph, the filename is just "Yes933FFT".

The most common tool for visualization in Python is matplotlib.
However,
this is more directed at drawing a static graph. It might be a good
idea
to look into e.g. pyqtgraph, if you want to continuously update your
graph. There are probably hundreds of libraries that will cater your
needs depending on what you want to do. e.g. there are libraries that
help you create an interactive website, if you want to do that.

The Qt GUI Frequency Sink block does quite a few more things. The
processing chain looks a bit like this:
1. FFT
2. compute magnitude squared
3. moving average
4. compute dB values, i.e. 10*log10(...)
5. Discard most samples and only draw a new line at the "update rate".

You might be able to swap step 4 and 5.
It might be interesting for you to perform some, most, or all of these
steps in your GNU Radio flowgraph. This might lower your sample rate.

Besides, if you want to visualize your data "online", a file is a bad
choice for data exchange. I would expect that you end up in
"concurrency
hell".
GNU Radio offers quite a few useful options here. e.g. UDP or TCP
sinks.
Or there are ZeroMQ sinks. With Python you should be able to receive
data from these sinks with just a few lines of code.
For example, you might use a UDP sink in your flowgraph and send all
data to a UDP port on your machine. Then, your visualization tool
listens on that UDP port, receives your data and does what it is
supposed to do.

Cheers
Johannes



On 10.12.21 09:59, Zen Chen wrote:
 > Yes933_10_12_20212nd.csv
 >

<https://drive.google.com/file/d/1tEaxr9bQICfDm-Uu6nIfGcLSQd6Rfb1Z/view?usp=drive_web

<https://drive.google.com/file/d/1tEaxr9bQICfDm-Uu6nIfGcLSQd6Rfb1Z/view?usp=drive_web>>
 > HI all,My name is Zen Chen , a GNU radio Novice and I tried to
create an
 > account on the GNU Radio .org website to post my questions on the
 > mailing list however I could not . I am using GNU radio and Hack
RF 1 to
 > design a power spectrum analyser and I am using the attached
flowgraph
 > to and python script to give me the attached CSV file however , the
 > results (FFT connect to file sink) is to large to be contained in a
 > single excel file . Is there a problem in my GNU Radio Flowgraph?
 >
 > Regards,
 > Chong Zhi

Re: Questions On GNU Radio FFT Data logging

[Johannes Demel]

Hi Chong Zhi,

I assume you want to observe the FM band ~90MHz to ~100MHz is that correct?

If you want to listen to audio, have a look at gr-rds.
https://github.com/bastibl/gr-rds
It helps quite a bit more to understand FM.

Since this discussion seems to have started in the GR Matrix chat, I 
infer you actually want to re-implement the Qt GUI Frequency Sink block 
outside of GNU Radio.

Further, this needs to happen online.

As Martin mentioned, at your current sample rate a CSV is a bad choice.
If CSV is a hard requirement, sent the resulting CSV to the person 
requesting it and ask them to open it. I just hope they understand the 
issue after their spreadsheet visualization tool crashed/is unresponsive 
or anything else.


The file format is explained in the GR wiki, as Marcus pointed out.
https://wiki.gnuradio.org/index.php/File_Sink#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F

Let's assume you use a binary file and want to open in in Python, in 
your case this would be

```
import numpy as np
samples = np.fromfile('your_file.cdat', dtype=np.complex64)
```
Please mind that the File extension (.cdat) is an arbitrary choice. In 
your flowgraph, the filename is just "Yes933FFT".


The most common tool for visualization in Python is matplotlib. However, 
this is more directed at drawing a static graph. It might be a good idea 
to look into e.g. pyqtgraph, if you want to continuously update your 
graph. There are probably hundreds of libraries that will cater your 
needs depending on what you want to do. e.g. there are libraries that 
help you create an interactive website, if you want to do that.


The Qt GUI Frequency Sink block does quite a few more things. The 
processing chain looks a bit like this:

1. FFT
2. compute magnitude squared
3. moving average
4. compute dB values, i.e. 10*log10(...)
5. Discard most samples and only draw a new line at the "update rate".

You might be able to swap step 4 and 5.
It might be interesting for you to perform some, most, or all of these 
steps in your GNU Radio flowgraph. This might lower your sample rate.


Besides, if you want to visualize your data "online", a file is a bad 
choice for data exchange. I would expect that you end up in "concurrency 
hell".
GNU Radio offers quite a few useful options here. e.g. UDP or TCP sinks. 
Or there are ZeroMQ sinks. With Python you should be able to receive 
data from these sinks with just a few lines of code.
For example, you might use a UDP sink in your flowgraph and send all 
data to a UDP port on your machine. Then, your visualization tool 
listens on that UDP port, receives your data and does what it is 
supposed to do.


Cheers
Johannes



On 10.12.21 09:59, Zen Chen wrote:
Yes933_10_12_20212nd.csv 

HI all,My name is Zen Chen , a GNU radio Novice and I tried to create an 
account on the GNU Radio .org website to post my questions on the 
mailing list however I could not . I am using GNU radio and Hack RF 1 to 
design a power spectrum analyser and I am using the attached flowgraph 
to and python script to give me the attached CSV file however , the 
results (FFT connect to file sink) is to large to be contained in a 
single excel file . Is there a problem in my GNU Radio Flowgraph?


Regards,
Chong Zhi

Open PhD positions at ANT, Uni Bremen

[Johannes Demel]

Hi all,

we have quite a few open positions for PhD candidates at our institute. 
If you're interested, I pasted the description in this email. You can 
find the description here: https://www.ant.uni-bremen.de/en/int_jobs/


Cheers
Johannes


As a key partner in various collaborative research projects, the 
Department of Communications Engineering (headed by Prof. Dr.-Ing. Armin 
Dekorsy) of the University of Bremen has been researching innovative 
concepts, methods and technologies for future communication systems with 
a focus on baseband signal processing. To complement our research teams, 
we are looking for 13 PhD-candidates and at least 2 postdoctoral 
researchers in the following areas:


- 6G communication system
- Satellite communications
- Swarm exploration on Mars
- Quantum communications.

Potential research topics include, but are not limited to:

- Information transmission and interference management in 6G network 
concepts
- 6G network concepts and architectures: terrestrial-orbital (3D) 
networks, organic networks, OpenRAN, dynamic subnetworks

- Source and channel coding (e.g. Information Bottleneck Method)
- Event-based sampling, Event-based communication
- Semantic communication
- Graph-based, distributed signal processing and compressive sensing
- Machine learning methods, Bayesian learning methods
- mmWave (26GHz) communication and localization

The candidates are expected to have skills that cover one or more of the 
following areas:


- Communications engineering (baseband, resource management)
- Signal processing and signal theory
- Coding and information theory
- Network information theory
- Machine learning, stochastic inference techniques.

We are looking for candidates carrying out at least one of the following 
activities


- Fundamental, theoretical-oriented research
- Software implementation of innovative technologies, e.g. in an 6G testbed.

If you have a very good M.Sc. degree in electrical 
engineering/information technology, computer engineering or applied 
mathematics and are interested in conducting independent research with 
your ideas and approaches as a member of one of our research teams, we 
look forward to receiving your unsolicited application. The possibility 
of a doctorate is given for all positions.


Please send your application (brief cover letter, CV. transcripts, 
certificates, list of pub if applicable) to applicati...@ant.uni-bremen.de

Re: USRP N210 growing latencies

[Johannes Demel]

Hi Fabien,

unless this is a very specific issue and you know exactly that your OS 
is the component that causes an issue, I recommend to stick with your 
distros generic kernel image.


I'd need more information but my gut feeling tells me that your issue is 
somehow a 2-clock problem.


So let's start with a few questions about your system.
Which Linux distribution do you use? Which exact GNU Radio and UHD 
versions do you use? GR 3.9.3? UHD 4.1.0.x? How did you install GNU 
Radio. Do you run your flowgraph in a VM or smth similar?

UHD RX sample rate?
UHD TX sample rate?
Are both rates supported by your N210?
Does your flowgraph decimate by some integer value?

Which blocks are in between?
Just to get this out of the way, another hardware block such as an audio 
sink might get you into a 2-clock problem situation. Since you use 
hardware blocks, I assume you don't use a Throttle block, if so, remove 
the Throttle block.


Can you share the flowgraph? It might be easiest to just write down the 
exact blocks.


Are there any custom blocks?

Do you need continuous streaming?

How fast does the delay grow?

A lot of questions, I know. The answers to these questions might help to 
find your root issue.


Cheers
Johannes



On 26.10.21 21:41, Fabien PELLET wrote:

Hello,

Thanks for the answer Marcus.

OK I understand that. But is there any solution which permits to reset 
that growing propagation delay ? How to reset the flowgraph buffers 
without killing the application and restart it ? Is there any method 
that permits to purge and resync buffers of the flowgraph ?


Even if my application runs on a preempt_rt OS with a good calculation 
power, I'm not enough good in Linux tweaking to be sure that my 
application will not have a unusable delay after a long time. So I can 
accept to loose some time when I catch a PMT message of underflow to 
reset the sequencer and buffers. But how without killing apps ??


Best regards,
Fabien, F4CTZ

 Marcus Müller a écrit 

Hello!


On 26.10.21 16:12, Fabien PELLET wrote:
 >
 > Why that propagation delay is always growing ?
 >

Exactly *becuause* your underflowing.

Your Receive side produces N samples – but too slow at some point, 
leading to your
transmitter needing to "invent" an amount P of samples, because it 
simply has a fixed

sample rate.

So, now, from the point of view of the transmitter's DAC, N+P sample 
periods have passed,
whereas the receiver's ADC saw N sample periods. This repeats, and every 
P > 0. Therefore,

the delay is always only growing.

Best regards,
Marcus

Re: Completely blank flowgraph takes a minute to generate

[Johannes Demel]

Hi,

I used:
https://docs.python.org/3/library/profile.html#module-cProfile
in the past to locate the problematic lines of code.

```
import cProfile
import pstats

with cProfile.Profile() as pr:
run_the_problematic_function_etc()
stats = pstats.Stats(pr)
stats.sort_stats('cumtime').reverse_order()
stats.print_stats()
```
You might want to adopt these lines for your use-case. I started at the 
top-level of my application and then gradually moved the code to a more 
fitting function.


Cheers
Johannes

On 28.09.21 23:40, Jameson Collins wrote:

I have a completely blank flowgraph (well just the default 'Options' block).

On my 8 core, 2 GHz, Intel based virtual machine this flowgraph 
generates in under a second.


On my 4 core, 1GHz, embedded ARM processor it takes 56 seconds and 
completely maxes out 1 core while it's running.


Why might cause this?  How might I troubleshoot it?

[VOLK] Help us relicense VOLK under LGPLv3+

[Johannes Demel]

Dear contributors of VOLK,

we are writing to let you know that we are working towards a new major
release of VOLK. The possibly biggest change will be that we intend to
use a different license for this release: VOLK 3.0 shall be licensed
under the LGPL 3.0 (or later).
To do this effectively, we will need your help, should you agree. If you
are already aware of this effort and are in support, you can skip to
"What are you asking from contributors?" below, but we recommend you
read this letter in its entirety to make sure you understand our
intentions and process.


# Why are we doing this?

In retrospect, LGPL would probably have been the better choice for VOLK
from the get-go. The FSF recommendations on libraries states that "If
developers are already using an established alternative library released
under a nonfree license or a lax pushover license, then we recommend
using the GNU Lesser General Public License (LGPL)."
(https://www.gnu.org/licenses/license-recommendations.html).

We agree with this recommendation, and want to avoid VOLK being a SIMD
library exclusively used by GNU Radio (and a few others), while other
software packages rally behind other SIMD libraries, that are more
liberally licensed.

We could have chosen an even less restrictive license, but we are
believers in copyleft, and believe the LGPL strikes the right balance
between not restricting users in which types of software they may use
VOLK, and requiring users to continue upstreaming their modifications to
VOLK.


# How are we going to do this?

Relicensing codebases is a complex process, full of potential pitfalls.
To avoid any misconceptions, ambiguities, or legal issues, we have
decided to go for the nuclear option: We will delete all of VOLK, and
start from scratch, using the LGPL from the beginning of VOLK 3.0.
It would be a futile attempt to try and recreate the decades of work
that went into previous versions of VOLK without violating the VOLK 2.0
license. We are therefore asking all contributors to re-grant us
permission to include their code, previously submitted into VOLK
versions 1 and 2, into the newly licensed VOLK 3. The process for
contributors is simple (see below), but first, we want to explain how
this works.

For contributing to VOLK 2.0, most of you signed a CLA, granting the
copyright to the FSF. This CLA includes a paragraph stating that the FSF
grants back to the developer the rights to use their contributions as
they see fit.

We cannot copy code from VOLK 2.0, since that is GPL licensed. But we
can ask you to resubmit your contributions to VOLK 3.0, which is LGPL
licensed. And that's what we're asking you to do in this letter. The
process to do so is really simple and will be explained shortly.

Once your previous contributions are re-submitted, the copyright will
fall back onto the original authors.


# What's going to happen to VOLK 2? Will there be other changes in VOLK
3.0 other than the license change?

VOLK 2 will remain GPL-licensed. We may choose to continue supporting it
with bug fixes, but the main development focus will lie on VOLK 3 going
forward.

The roadmap for VOLK 3.0 is not yet fully laid out, but we are
considering making some API-breaking changes in VOLK 3 along with the
relicensing.
At the moment, we consider approaches to fix complex data type
incompatibilities between C and C++.


# What are you asking from contributors?

To grant us permission to use your contributions under the LGPL3 license
for VOLK 3.0, we ask that you sign the paragraph 
[HERE](https://github.com/gnuradio/volk/blob/main/AUTHORS_RESUBMITTING_UNDER_LGPL_LICENSE.md). 
You
can do this either by submitting a pull request against [THIS 
FiLE](https://github.com/gnuradio/volk/blob/main/AUTHORS_RESUBMITTING_UNDER_LGPL_LICENSE.md)., 
adding your name and email address as they appear in previous

commits. Alternatively, you can send us an email, in which you state
that you've read and understood the following paragraph, and we will add
your name on your behalf.

There is *no need to submit pull requests with your previous
submissions*. Once you have agreed to re-submit your code to VOLK 3, we
will pull your submissions out of git history and apply them to the VOLK
3 branch under the new license on your behalf.

Should you not wish to re-use your contributions for VOLK 3, we
understand and respect that, and will not include your code in future
versions of VOLK. For logistical purposes, it would be very helpful if
you still respond to this email and let us know about your decision, so
we can more easily track how many contributors are in agreement with
this change.


# Relicensing Agreement (this goes into the repo)
This statement goes into the commit message.

I, {contributor name}, hereby resubmit all my contributions to the VOLK
project and repository under the terms of the LGPL-3.0-or-later.
My GitHub handle is {github handle}.
My email addresses used for contributions are: {email address}, ... .

I hereby agree that 

Re: Regarding linking the libraries for undefined symbol error

[Johannes Demel]

Hi Arhum,

first off a few comments. You mention Ubuntu 16.04 which reached 
End-Of-Life (EOL) a few months back. Please don't use obsolete software. 
After all, it is a security risk. Besides, Ubuntu 16.04 exposed a series 
of bugs that are very specific to this distro. Thus, they are considered 
to be distro bugs. Since 16.04 is EOL and e.g. 20.04 does not expose 
these bugs (and in fact no other distro), it is unlikely that these 
issues will ever be fixed.


GNU Radio version 3.7.x is considered to be outdated at this point. It 
seems like you want to start a project. Newer GR versions offer a lot of 
packet data tools and blocks. I highly recommend to go with the latest 
GNU Radio 3.9 release.

https://wiki.gnuradio.org/index.php/UbuntuInstall
I assume these PDU utilities might help you to get even further:
https://github.com/sandialabs/gr-pdu_utils

Please don't send screenshots of terminal output. It is harder to read 
than necessary and more difficult to use. Just copy paste the terminal 
output.


Regarding your undefined symbol:
It might be the case that you ended up with an old VOLK version that 
does not include the `volk_32fc_index_max_32u` kernel. Thus, it lacks 
the `_manual` version as well.
If you consider installing a newer version of VOLK on Ubuntu 16.04, be 
aware that this will trigger a bug with this distros GCC version as well 
as some headers.


All of that brings me back to my first paragraph. Please start with a 
supported and recent toolchain that will definitely get you further.


Cheers
Johannes

On 06.09.21 12:35, Arhum Ahmad via GNU Radio, the Free & Open-Source 
Toolkit for Software Radio wrote:

Respected sir,
I am trying to transmit and receive packets in BPSK modulation for which 
I useGNU Radio Packetized 
transmissions> named gr-packetizer. 
It was installed through source in ubuntu version 16.04. Even though it 
successfully installed, when it runs it gives an attribute error (like: 
AttributeError: 'module' object has no attribute 'packet_encoder'). In 
order to debug it was tested using "ctest -V" (image attach) command in 
the build directory which failed 50%. Also the command `ldd -r lib/*.so` 
in build directory gives undefined symbols, both of them point error in 
"*volk_32fc_index_max_32u_manual*". This I was unable to solve and 
understand. Please help me with this. All related images are attached. 
I'll be highly obliged.


all related versions are:
GNU radio - 3.7.9
cmake - 3.5.1
GNU make - 4.1
python - 2.7.12
python3 - 3.5.2




--
*Thanks and Regards**
*
*Arhum Ahmad*
Ph.D. Scholar, Electrical Engineering Department, IIT Ropar

+91- 7974897279 | arhum.19eez0...@iitrpr.ac.in 



Lab No. 323, Communication Research Lab, J.C.Bose Building


*
/CONFIDENTIALITY NOTICE: The contents of this email message and any 
attachments are intended solely for the addressee(s) and may contain 
confidential and/or privileged information and may be legally protected 
from disclosure. If you are not the intended recipient of this message 
or their agent, or if this message has been addressed to you in error, 
please immediately alert the sender by reply email and then delete this 
message and any attachments. If you are not the intended recipient, you 
are hereby notified that any use, dissemination, copying, or storage of 
this message or its attachments is strictly prohibited./

*

Re: N310 phase sync issue with antenna array

[Johannes Demel]

Hi Larry,

Which carrier frequency do you use for your tests? Something like 2.4GHz?
do the 4 receive channels have a stable phase between them? i.e. if you 
don't move the transmit antenna or your RX array, the phases do not change?


I assume you have 1 TX antenna and 4 RX antennas. I would expect that 
your N310 receives this signal with a stable phase and time aligned.


However, your wireless channel will introduce a phase shift (you 
compensated it with a delay, if I understand correctly). This is 
expected and introduced by your wireless channel.
In your wired test case you fixed the "different distances" issue by 
using same-length cables.


> What I believe should be the expected results of this setup is that 
each AD9371 should receive synchronous signals aligned in phase, with a 
random 180 degree offset between each AD9371 transceiver (please correct 
me if this assumption if wrong).


Your assumption is probably wrong. You can only expect a fixed phase 
relation between your RX antennas. Your RX signal will not have the same 
phase on all RX antennas. And there might still be a 180 degree ambiguity.


In case you aim for a SIMO configuration, you need to do channel 
estimation for every RX stream.


Cheers
Johannes


On 29.06.21 22:51, Larry wrote:

Hello everyone,

I am having an issue with achieving a phase-synchronous RF configuration 
using an N310 with an Octoclock and a linear antenna array. What I 
believe should be the expected results of this setup is that each AD9371 
should receive synchronous signals aligned in phase, with a random 180 
degree offset between each AD9371 transceiver (please correct me if this 
assumption if wrong). Here is a summary of my setup, issues, and outcomes:


1)  Hardware/software setup: Using an N310 running HG image at 1-gigabit 
network connection on UHD version 3.15 on Ubuntu 18.04. This is 
supported by an Octoclock-G serving as the 10MHz reference and PPS 
source for the N310. Equal length cables are used between all channels 
of the N310, to facilitate better phase synchronization. My GnuRadio 
flowgraph consists of a USRP source into a simple squelch, feed forward 
AGC, frequency xlating fir filter, and then converted from complex to 
real going into a QT time sink.


2) Testing & results: I am attempting to receive a bursty signal using a 
four element linear dipole antenna array, with the elements spaced 
slightly under lambda/2 distance apart. Two main tests have been 
performed; one with the N310 directly wired to another SDR that is 
injecting a generated sine wave into the N310, and another test over the 
air using a radio transmitter.


i. Testing with a wired connection results in the correct expected 
results - phase-aligned signals, with the channel pairs on each AD9371 
transceiver offset by presumably + or - 180 degrees. I can then align 
using simple delays to achieve phase alignment between all channels. 
This works with 2, 3, or 4 channels used.


ii. Testing over the air results in very unsynchronized signals among 
all four channels. These results tend to be repeatable and consistent in 
their behavior, but the channels all are received both wildly out of 
phase (even channels on the same AD9371 transceiver), and even 
(depending on location of the transmitter relative to the antenna array) 
inverted in amplitude relative to other channels (particularly 
interesting was that the imaginary component of one channel would match 
the inverse of a different channel's real component). This test has been 
performed at ranges exceeding 75~ feet, and as near as 5 feet away. The 
results are similar in either situation. It is also worth noting that 
varying the transmitter's location parallel to the antenna array 
(finding a 'sweet spot', so to speak) resulted in at most 2, possibly 3 
of the channels to align properly in phase without calibrating using 
delays (at least one channel would always stay wildly different). 
Testing over the air using fewer than 4 channels yields marginally 
improved, but overall similarly poor results.


I have tried using an external LO source for the N310 as well as 
operating the Octoclock with and without GPS functionality enabled. I 
have varied the sample rates, distances, and testing environments as 
well as changing cables and splitters to try to rule out any hardware 
component errors. These seem to have no real impact on the strange 
results I get with the over the air RF configuration. Any help to sanity 
check or troubleshoot my issues would be greatly appreciated. Thank you!

Re: How to remove channel noise?

[Johannes Demel]

Hi,

besides the hint to work through textbooks, I'd like to point out that 
you will probably have more success if you start with nearly perfect 
"Channel Model" coefficients and then observe changes in the following 
order:

1. Noise Voltage: 0 (and raise it slowly e.g. in 1e-2 increments.
2. Taps: 1 + 0j (play around with more values, change it to a vector 
e.g. [1., .3+.3j])
3. Frequency Offset: 0 (Increase this value slowly observe the 
constellation sink)
4. Epsilon: 1.0, supposed to simulate sample rate mismatch between 
transmitter and receiver.


Further, it'd be a good idea to start with e.g. QPSK as an initial 
constellation. It is sufficiently simple and easy to observe channel 
influences.


Cheers
Johannes


On 18.06.21 08:50, Kyeong Su Shin wrote:

Hello 能书能言,

You can take multiple samples and average out the noise (if the 
transmitted signal is not varying quickly), but you need to obtain 
channel estimates in order to recover the original phase and amplitude. 
You will have to transmit additional signals (known by the receiver) and 
use them as the reference signals to recover the channel state.


Please note that long-term averaging may not work as expected on 
real-world environments, due to the non-stationary channel and various 
hardware imperfections, like CFO.


You are probably better off if you just use off-the-shelf digital 
transceivers to transmit data in digital manner (if you are not required 
to implement things in this way.. by some weird reason).  If you have to 
implement this by yourself (in real-world, especially), I recommend 
going through information theory and communication theory textbooks 
before jumping into the implementation.


(Also, 2V noise in the channel noise block is somewhat... high. Pretty 
low SINR it is. )


Regards,
Kyeong Su Shin

*보낸 사람:* 能书能言 <2127629...@qq.com> 대신 Discuss-gnuradio 


*보낸 날짜:* 2021년 6월 18일 금요일 오후 12:46
*받는 사람:* discuss-gnuradio 
*제목:* How to remove channel noise?
Hi,guys.
My flowchart is attached in the attachment, this is just a test case. I 
sent a constant complex number directly to pass it through a channel 
module, and the received result was also expected, and it was seriously 
disturbed. The real situation is like this. I have several such complex 
constant data (there may be hundreds or thousands). If I send it 
directly like this, I will definitely suffer similar interference, so is 
there any good way to make it? Can I send and receive these data 
accurately? In other words, there may still be interference, but at 
least it is within a controllable range.

Remarks: These data are plural data, not file dataThanks in advance!
Sincerely

[VOLK] Release 2.5.0

[Johannes Demel]

Hi everyone!

We have a new VOLK release! We are happy to announce VOLK v2.5.0! We 
want to thank all contributors. This release wouldn't have been possible 
without them.


This release adds new kernel implementations and fixes. Some of these 
were longstanding PRs that could only be merged recently thanks to our 
switch from CLA to DCO.


### Announcements

I would like to point out one upcoming change. After this release, we 
will rename our development branch to `main` as discussed in [issue 
#461](https://github.com/gnuradio/volk/issues/461).



I'd like to point the community to this [VOLK relicensing 
GREP](https://github.com/gnuradio/greps/pull/33).

This is an ongoing effort to relicense VOLK under LGPLv3.
We're looking for people and organizations that are interested in 
leading this effort.


### Contributors

* Aang23 
* Carles Fernandez 
* Florian Ritterhoff 
* Jam M. Hernandez Quiceno , 
* Jaroslav Škarvada 
* Johannes Demel 
* Magnus Lundmark 
* Michael Dickens 
* Steven Behnke 
* alesha72003 
* dernasherbrezon 
* rear1019 


### Changes

* Kernels
- volk_32f_stddev_and_mean_32f_x2: implemented Young and Cramer's 
algorithm

- volk_32fc_accumulator_s32fc: Add new kernel
- volk_16ic_x2_dot_prod_16ic_u_avx2: Fix Typo, was `_axv2`.
- Remove _mm256_zeroupper() calls
- Enforce consistent function prototypes
- 32fc_index_max: Improve speed of AVX2 version
- conv_k7_r2: Disable broken AVX2 code
- improve volk_8i_s32f_convert_32f for ARM NEON
- Calculate cos in AVX512F
- Calculate sin using AVX512F


* Compilers
- MSVC
- Fix MSVC builds
- GCC
- Fix segmentation fault when using GCC 8
- MinGW
- add support and test for MinGW/MSYS2

* The README has received several improvements

* Build
- Fix python version detection
- cmake: Check that 'distutils' is available
- c11: Remove pre-C11 preprocessor instructions

* CI
- Add more CI to GitHub Actions
- Remove redundant tests from TravisCI
- Add non-x86 GitHub Actions
- Update compiler names in CI
- Disable fail-fast CI
- Add more debug output to tests

* Contributing
- contributing: Add CONTRIBUTING.md and DCO.txt

Re: libosmo-dsp build hangs (required for gr-osmosdr)

[Johannes Demel]

Hi Jeff,

thanks for your help. I decided to be a bit more pragmatic and just 
install the missing piece.
On Ubuntu 20.04 the required package is `texlive-latex-extra` and 
requires 182 MB of disk space.


All of this is part of my effort to install gr-osmosdr on GR 3.9. 
Besides this hiccup, the pybombs recipe tries to install gr-fcdproplus 
which seems to be stuck with 3.8. This project's CMake output is really 
useful. Anyways, I decided to set gr-fcdproplus to `forceinstalled: 
'True'` in my prefix config.yml. gr-osmosdr is kind enough to just skip 
this dependency in that case.


Cheers
Johannes

On 27.05.21 11:32, Jeff Long wrote:
Or could just install the missing LaTeX module. On Fedora, it's 
texlive-newunicodechar. For reference, no problems building libosmo-dsp 
here.


On Thu, May 27, 2021 at 4:21 AM Johannes Demel <mailto:de...@ant.uni-bremen.de>> wrote:


Thanks Jeff!

Unfortunately, these settings are already present in that config.yml. I
double checked the config.yml in my prefix as well. There are no
overwrites.

This is from `gr-recipes/libosmo-dsp.lwr`:
```
configure: autoreconf -i -I /usr/share/aclocal && ./configure
--prefix=$prefix $config_opt
```
I'd really like to learn about `$config_opt`. What value(s) are in
there?
I removed libosmo-dsp (also from the inventory.yml).

This is the output of `pybombs -v install libosmo-dsp`:
```
[DEBUG] Requirements met.
[DEBUG] Using build directory:
/home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Configuring recipe libosmo-dsp
[DEBUG] Using vars - ordereddict([('config_opt', ''), ('builddir',
'/home/johannes/prefix/gnuradio/src/libosmo-dsp')])
[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ autoreconf -i -I /usr/share/aclocal &&
./configure --prefix=/home/johannes/prefix/gnuradio'
Configuring: (100%)
[DEBUG] Thread signaled termination or returned
[DEBUG] Return value: 0
[DEBUG] Configure successful.
[DEBUG] Setting state to `configured'
[DEBUG] Saving inventory to file
/home/johannes/prefix/gnuradio/.pybombs/inventory.yml...
[DEBUG] Building recipe libosmo-dsp
[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ make -j64'
Building:    [
```
This is where it hangs.

I just tried to run it on a host with a full LaTeX installation. There
it goes through without any issue.

My guess would be that I'd have to do a full LaTeX install. That's
something I'd like to avoid.

I'd like to skip the whole Doxygen part and hope the issue goes away. A
more narrow solution would be nice as well though.

Cheers
Johannes

On 26.05.21 19:17, Jeff Long wrote:
 > In ~/.pybombs/config.yml
 >
 > - config:
 >      makewidth: 4
 >      builddocs: OFF
 >      cmakebuildtype: Release
 >
     > On Wed, May 26, 2021 at 12:41 PM Johannes Demel
mailto:de...@ant.uni-bremen.de>
 > <mailto:de...@ant.uni-bremen.de
<mailto:de...@ant.uni-bremen.de>>> wrote:
 >
 >     Hi all,
 >
 >     I'm trying to install gr-osmosdr with GR 3.9. Currently
pybombs hangs
 >     during libosmo-dsp build. Unfortunately it just hangs forever
without
 >     any output, but if I try it manually, I see:
 >
 >     ```
 >     ! LaTeX Error: File `newunicodechar.sty' not found.
 >
 >     Type X to quit or  to proceed,
 >     or enter new name. (Default extension: sty)
 >
 >     Enter file name:
 >     ```
 >     Thus, I'd like to disable generating docs. All of this
happens while
 >     docs are generated. There's a minimal latex install but I
don't want
 >     any
 >     more TeX on that machine.
 >
 >     I can't find the switch to disable docs. How do I do that? Or
disable
 >     doxygen.
 >
 >     Cheers
 >     Johannes
 >
 >     --
 >     Johannes Demel M.Sc.
 >     Research Engineer
 >
 >     University of Bremen
 >     Department of Communications Engineering
 >     Faculty 1 - Physics / Electrical Engineering
 >     NW1, N2400
 >     Otto-Hahn-Allee NW1
 >     28359 Bremen
 >
 >     Phone +49 421 218-62393
 > de...@ant.uni-bremen.de <mailto:de...@ant.uni-bremen.de>
<mailto:de...@ant.uni-bremen.de <mailto:de...@ant.uni-bremen.de>>
 >
 >     Secretariat
 >     Tel. +49 421 218-62390
 > pre...@ant.uni-bremen.de <mailto:pre...@ant.uni-bremen.de>
<mailto:pre...@ant.uni-bremen.de <mailto:pre...@ant.uni-bremen.de>>
 >
 > www.uni-bremen.de/en <http://www.uni-bremen.de/en>
<http://www.uni-bremen.de/en <http://www.uni-bremen.de/en>>
 >
 >     University of Bremen - Established 1971
 >

Re: libosmo-dsp build hangs (required for gr-osmosdr)

[Johannes Demel]

Thanks Jeff!

Unfortunately, these settings are already present in that config.yml. I 
double checked the config.yml in my prefix as well. There are no overwrites.


This is from `gr-recipes/libosmo-dsp.lwr`:
```
configure: autoreconf -i -I /usr/share/aclocal && ./configure 
--prefix=$prefix $config_opt

```
I'd really like to learn about `$config_opt`. What value(s) are in there?
I removed libosmo-dsp (also from the inventory.yml).

This is the output of `pybombs -v install libosmo-dsp`:
```
[DEBUG] Requirements met.
[DEBUG] Using build directory: 
/home/johannes/prefix/gnuradio/src/libosmo-dsp

[DEBUG] Configuring recipe libosmo-dsp
[DEBUG] Using vars - ordereddict([('config_opt', ''), ('builddir', 
'/home/johannes/prefix/gnuradio/src/libosmo-dsp')])

[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ autoreconf -i -I /usr/share/aclocal && 
./configure --prefix=/home/johannes/prefix/gnuradio'

Configuring: (100%)
[DEBUG] Thread signaled termination or returned
[DEBUG] Return value: 0
[DEBUG] Configure successful.
[DEBUG] Setting state to `configured'
[DEBUG] Saving inventory to file 
/home/johannes/prefix/gnuradio/.pybombs/inventory.yml...

[DEBUG] Building recipe libosmo-dsp
[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ make -j64'
Building:[
```
This is where it hangs.

I just tried to run it on a host with a full LaTeX installation. There 
it goes through without any issue.


My guess would be that I'd have to do a full LaTeX install. That's 
something I'd like to avoid.


I'd like to skip the whole Doxygen part and hope the issue goes away. A 
more narrow solution would be nice as well though.


Cheers
Johannes

On 26.05.21 19:17, Jeff Long wrote:

In ~/.pybombs/config.yml

- config:
     makewidth: 4
     builddocs: OFF
     cmakebuildtype: Release

On Wed, May 26, 2021 at 12:41 PM Johannes Demel <mailto:de...@ant.uni-bremen.de>> wrote:


Hi all,

I'm trying to install gr-osmosdr with GR 3.9. Currently pybombs hangs
during libosmo-dsp build. Unfortunately it just hangs forever without
any output, but if I try it manually, I see:

```
! LaTeX Error: File `newunicodechar.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name:
```
Thus, I'd like to disable generating docs. All of this happens while
docs are generated. There's a minimal latex install but I don't want
any
more TeX on that machine.

I can't find the switch to disable docs. How do I do that? Or disable
doxygen.

Cheers
    Johannes

    -- 
Johannes Demel M.Sc.

Research Engineer

University of Bremen
Department of Communications Engineering
Faculty 1 - Physics / Electrical Engineering
NW1, N2400
Otto-Hahn-Allee NW1
28359 Bremen

Phone +49 421 218-62393
de...@ant.uni-bremen.de <mailto:de...@ant.uni-bremen.de>

Secretariat
Tel. +49 421 218-62390
pre...@ant.uni-bremen.de <mailto:pre...@ant.uni-bremen.de>

www.uni-bremen.de/en <http://www.uni-bremen.de/en>

University of Bremen - Established 1971

libosmo-dsp build hangs (required for gr-osmosdr)

[Johannes Demel]

Hi all,

I'm trying to install gr-osmosdr with GR 3.9. Currently pybombs hangs 
during libosmo-dsp build. Unfortunately it just hangs forever without 
any output, but if I try it manually, I see:


```
! LaTeX Error: File `newunicodechar.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name:
```
Thus, I'd like to disable generating docs. All of this happens while 
docs are generated. There's a minimal latex install but I don't want any 
more TeX on that machine.


I can't find the switch to disable docs. How do I do that? Or disable 
doxygen.


Cheers
Johannes

--
Johannes Demel M.Sc.
Research Engineer

University of Bremen
Department of Communications Engineering
Faculty 1 - Physics / Electrical Engineering
NW1, N2400
Otto-Hahn-Allee NW1
28359 Bremen

Phone +49 421 218-62393
de...@ant.uni-bremen.de

Secretariat
Tel. +49 421 218-62390
pre...@ant.uni-bremen.de

www.uni-bremen.de/en

University of Bremen - Established 1971

Re: Windows 7 x64 problem...

[Johannes Demel]

Hi Alberto,

Since your error is "Python.exe stopped working", it might be a Python 
issue. Besides, Windows 7's time has run out for over a year. Further, 
you use GR 3.7 and Python 2. Again, Python 2's time has run out for over 
a year. Please update your system.


GR is supposed to run on supported platforms but MS does not support W7 
anymore. Thus, GR might or might not run on it.


As far as GR is concerned, there are conda packages to install newer GR 
versions. I recommend GR 3.9.


You should never use a Throttle and a Hardware block (your osmocom 
source). This might cause issues.


Please don't send pictures of your screen, use screenshots. Even better: 
don't send screenshots but copy and paste the error message.


Cheers
Johannes

On 22.04.21 22:01, Alberto wrote:

No idea ?



Inviato da iPhone


Il giorno 19 apr 2021, alle ore 17:55, Alberto  ha 
scritto:

Hi !
I have created a simple example to View 100MHz signal from sdr receiver...but i 
have a problem.

My OS is Windows 7 x64, GNURadio 3.7.13.5.

When i start a receiver with gnuradio an window error open:

Pyton.exe has stop working

Can you help me ?

Alberto




Inviato da iPhone

Re: About umts

[Johannes Demel]

Hi Oliver,

unfortunately, I don't know of any GNU Radio UMTS implementation. If 
others do, they will point you to it.


Besides, I'd like to point out a few caveats. UMTS is not a simple 
single carrier system. You can't just use a Costas Loop to sync to your 
constellation. You first need to synchronize, deal with CDMA and 
probably equalize before you can observe a constellation.


My understanding is that UMTS systems will be shut down soon. At least 
in Germany all carriers have announced to shut down their 3G systems in 
'21. It might be totally different in other countries. 2G/GSM is still 
available in Germany, and will be after the UMTS shutdown.

Where do you want to receive UMTS signals?

Cheers
Johannes

On 26.03.21 11:04, Oliver pamt wrote:

Hello, new user here.
I'm looking for a way to receive umts (3g) with usrp and gnuradio.
first, I would like to observe the constellation qpsk.
Is there a tool already developed that could do the trick?

Thank you

Oliver

Re: PMT thoughts

[Johannes Demel]

Hi John,

you're not alone with your concerns. There's a GREP (GNU Radio 
Enhancement Proposal) [0] where issues with PMTs are discussed. This 
would be an excellent place to discuss more details and contribute.


Cheers
Johannes

[0] https://github.com/gnuradio/greps/pull/31

On 25.03.21 23:43, John Sallay wrote:
I appreciate the effort that you guys have put into cleaning up gnuradio 
and making it easier to work with over the past few years (python2 - 
python3, swig to pybind11).  I see that you are going to improve the 
logging as well which is great.
I've recently been doing some message based processing, and been using 
PMTs.  I think that PMTs could use an overhaul too.

Here are some of my concerns:
The interface is inconsistent.  Here are a few examples:
is_integer, but from/to_long
is_dict, is_vector, not no is_list
make_dict, make_vector, but list1, list2, etc

Type safety doesn't really work in several cases:
# apt install of gr 3.9 on ubuntu 20.04
a = pmt.make_dict()
a = pmt.dict_add(a, pmt.intern("a"), pmt.intern("a"))
pmt.is_dict(a) # True
a = pmt.list_add(a, pmt.intern("b"))   # I believe that this changes the 
dictionary to a list

pmt.is_dict(b) # False
I could come up with more examples, but they illustrate roughly the same 
point.  I should note that something changed in GR3.9.  It was even 
worse in 3.8.  For example, on a list, pmt.is_dict() returns True.  I 
can call some of the dict functions which return unexpected results, 
while others raise an error.


The interface doesn't feel like modern C++.  The pmt object doesn't 
really have any useful functions associated with it.  You have to use 
the functions in pmt namespace to operate on any pmt.  I believe that 
PMTs are using boost::any under the hood.  I can get why some of the 
choices were made, but I think that there may be some alternatives 
available that could lead to an easier interface.


I've been playing around with std::variant (in c++17, boost::variant 
prior to that).  I have some ideas for how we could use it to wrap the 
scalar types as well as the vector and dynamic types.  I would be happy 
to explore the idea if there is interest.  We could also use variadic 
templates to avoid things like list1, ..., list6.


Using std::variant, I would envision an interface like:
pmt my_dict();
my_dict["abc"] = 4.0 // Automatically convert the string and the number 
to the proper type.

std::get(my_dict["abc"]))

pmt_list my_list();
my_list.append(pmt(my_dict));
for (auto& element : my_list) {
    // Do something
}
std::cout << my_list.type() << " " << my_list << std::endl;

We should be able to deprecate, but maintain the current functions for 
dealing with PMTs.  I believe that these changes could be made without 
breaking existing code.


To be clear, I haven't implemented any of this.  My goal right now is 
just to see if there is interest in doing something like this.  If there 
is, I am happy to look into it and try to create a proof of concept.  
I'm also open to suggestions and feedback.


Thanks,

John

Re: Suggestion for an SDR computer

[Johannes Demel]

Hi Moses,

2GSps sounds like a lot of samples. Assuming you have 16bit I and Q that 
would be around 64Gbit/s (4 * 8bit * 2e9) if streamed continuously. 
Thus, I'd focus on whatever interface you need to get your samples in 
and out of your CPU.


In my experience GNU Radio flowgraphs do not require a lot of RAM. I 
focused on core count and high CPU frequency.


Cheers
Johannes

On 20.02.21 22:27, Moses Browne Mwakyanjala wrote:

Hi everyone,
I will be acquiring a frontend that could receive up to 2 Gsps. The 
frontend has an FPGA that could host user-defined VHDL signal processing 
RTL. It can also stream data directly to the CPU or GPU. I understand 
that using the FPGA or the GPU could be quite efficient. BUT, I want the 
signal processing functions done in the CPU whereby the waveform is 
processed in GNU Radio (or other C++ implementations). I'm currently 
looking for a computer that could handle this sample rate. What kind of 
specs do you think I could look for (RAM, CPU frequency, cache size 
etc).? What specific products would you recommend?


Regards,
Moses.

Re: How to use 2 N310 for TX and RX

[Johannes Demel]

Hi,

yes, I just attach a grc file for GR 3.9 that I use to test things.

It works if I specify `addr=...` or `addr0=...` with one device. If I 
switch to 2 devices `addr=,addr1=...` it fails.


It seems like UHD tries to initialize the devices twice.


[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_3.15.0.0-62-g7a3f1516
[INFO] [MPMD] Initializing 2 device(s) in parallel with args: 
mgmt_addr0=192.168.20.213,type0=n3xx,product0=n310,serial0=319841B,claimed0=False,mgmt_addr1=192.168.21.218,type1=n3xx,product1=n310,serial1=3180AF3,claimed1=False,addr0=192.168.20.213,addr1=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=external
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,clock_source=external,master_clock_rate=122.88e6,product=n310,mgmt_addr=192.168.20.213'.

[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,product=n310,master_clock_rate=122.88e6,clock_source=external,mgmt_addr=192.168.21.218'.

[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)

[...]

[INFO] [1/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [MPMD] Initializing 2 device(s) in parallel with args: 
mgmt_addr0=192.168.20.213,type0=n3xx,product0=n310,serial0=319841B,claimed0=True,mgmt_addr1=192.168.21.218,type1=n3xx,product1=n310,serial1=3180AF3,claimed1=True,addr0=192.168.20.213,addr1=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=external

[ERROR] [RPC] Someone tried to claim this device again (From: 192.168.20.34)


If I use only one device, it looks like this:


[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_3.15.0.0-62-g7a3f1516
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.20.213,type=n3xx,product=n310,serial=319841B,claimed=False,addr0=192.168.20.213,master_clock_rate=122.88e6,clock_source=external,time_source=external
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,clock_source=external,master_clock_rate=122.88e6,product=n310,mgmt_addr=192.168.20.213'.

[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)

[...]

[INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0)
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)


The last 4 lines are suspicious because they indicate that 
synchronization is performed twice. Also, most of the time during start 
up is spend there.


Anyways, I attached my MWE flowgraph. I'd be happy if you could tell me 
how to fix my issue.


Cheers
Johannes

On 10.02.21 22:52, Marcus D Leech wrote:

What happens if you just use a single N310 for both TX and RX?

Just trying to figure out where the problem might be. Also please share a 
minimal flow graph that shows the problem.

Sent from my iPhone


On Feb 10, 2021, at 1:25 PM, Johannes Demel  wrote:

Hi all,

I have a flowgraph where I want to use two N310s for TX and RX.

If I run `benchmark_rate`, everything works fine.

```
./benchmark_rate --pps external --ref external --rx_channels "0,4" --tx_channels 
"2,6" --rx_rate 61.44e6 --tx_rate 61.44e6 
--args="addr0=192.168.21.218,addr1=192.168.20.213,master_clock_rate=122.88e6
```

It's important that I use one RX and one TX channel each on those USRPs.

But it seems like I can't do that with

```
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_3.15.0.0-62-g7a3f1516
[INFO] [MPMD] Initializing 2 device(s) in parallel with args: 
mgmt_addr0=192.168.20.213,type0=n3xx,product0=n310,serial0=319841B,claimed0=False,mgmt_addr1=192.168.21.218,type1=n3xx,product1=n310,serial1=3180AF3,claimed1=False,addr0=192.168.20.213,addr1=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=external
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,clock_source=external,master_clock_rate=122.88e6,product=n310,mgmt_addr=192.168.20.213'.
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,product=n310,master_clock_rate=122.88e6,clock_source=external,mgmt_addr=192.168.21.218'.

[...]

[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.21.218,type=n3xx,product=n310,serial=3180AF3,claimed=True,addr=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=exter

How to use 2 N310 for TX and RX

[Johannes Demel]

Hi all,

I have a flowgraph where I want to use two N310s for TX and RX.

If I run `benchmark_rate`, everything works fine.

```
./benchmark_rate --pps external --ref external --rx_channels "0,4" 
--tx_channels "2,6" --rx_rate 61.44e6 --tx_rate 61.44e6 
--args="addr0=192.168.21.218,addr1=192.168.20.213,master_clock_rate=122.88e6

```

It's important that I use one RX and one TX channel each on those USRPs.

But it seems like I can't do that with

```
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; 
UHD_3.15.0.0-62-g7a3f1516
[INFO] [MPMD] Initializing 2 device(s) in parallel with args: 
mgmt_addr0=192.168.20.213,type0=n3xx,product0=n310,serial0=319841B,claimed0=False,mgmt_addr1=192.168.21.218,type1=n3xx,product1=n310,serial1=3180AF3,claimed1=False,addr0=192.168.20.213,addr1=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=external
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,clock_source=external,master_clock_rate=122.88e6,product=n310,mgmt_addr=192.168.20.213'.

[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A004)
[INFO] [MPM.PeriphManager] init() called with device args 
`time_source=external,product=n310,master_clock_rate=122.88e6,clock_source=external,mgmt_addr=192.168.21.218'.


[...]

[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.168.21.218,type=n3xx,product=n310,serial=3180AF3,claimed=True,addr=192.168.21.218,master_clock_rate=122.88e6,clock_source=external,time_source=external

[ERROR] [RPC] Someone tried to claim this device again (From: 192.168.21.34)
[WARNING] [MPM.RPCServer] Someone tried to claim this device again 
(From: 192.168.21.34)

Traceback (most recent call last):
  File "gr-tacmac/examples/usrp_multi_test.py", line 360, in 
main()
  File "gr-tacmac/examples/usrp_multi_test.py", line 338, in main
tb = top_block_cls()
  File "gr-tacmac/examples/usrp_multi_test.py", line 133, in __init__
self.uhd_usrp_sink_0 = uhd.usrp_sink(
RuntimeError: RuntimeError: Error during RPC call to `claim'. Error 
message: Someone tried to claim this device again (From: 192.168.21.34)

```

I can share the example flowgraph. It's just a USRP source connected to 
a Qt time sink (and a Qt Freq sink). And a USRP sink that's fed by two 
Signal sources.


It works if I only have either a USRP sink or USRP source. But in case I 
try to use both. The configuration breaks with the above error. How do I 
fix this?


Cheers
Johannes

Re: Stop making unneeded improvements

[Johannes Demel]

Hi Glen,

I fully understand your frustration to make things work long term and 
constant breakage.


There are, however, reasons why breaking changes are unavoidable. Some 
examples are:

1. GRC used Cheetah with XML for block definitions BUT:
Cheetah got unmaintained for years. Cheetah is only available for 
Python2. Python2 support ran out. Instead of relying on an unmaintained 
project, GRC switched to Mako which uses YAML instead.


2. With Ubuntu 20.04, it would probably be impossible to do a "simple" 
install of GR 3.7 because it requires Python2 and 20.04 basically dumped 
Python2 in favor of Python3. Thus, it was important to move to a newer 
Python version. You might be able to install 3.7 on that system BUT you 
might very well break it for other applications.
Ubuntu 20.04 is actually a very good reason to move to a newer GR 
version because it cuts off a lot of dependencies GR 3.7 has. e.g. 
Python2, Qt4, etc. That also exemplifies why GNU Radio must evolve 
because the ecosystem around it evolves as well.


3. There has been a lot of discussion if and how SWIG might be replaced 
by a different system. SWIG seemed like a good solution when it was 
introduced. But it turned out to be extremely frustrating whenever there 
are problems to fix.


4. Deprecating blocks seems like an annoying thing to do as well. 
Unfortunately, sometimes things that seemed like a good idea turn out to 
be a dead end. In this case, we all like a better alternative and some 
time to move in case we must.


I know that a lot of package maintainers do a fantastic job to make GR 
available for their respective systems. I hope that helps to get the 
installation process going.
I'd like to refer to Geof Nieboers recent email where he explains all 
the difficulties that come up with old software.


Of course, developers tend to be eager to adopt new technology and learn 
how to use it. Just like Radio astronomers want to discover and learn 
about new signals.
Personally, I think Marcus is doing a fantastic job and balancing things 
between long term usability and progressive changes.
Also, you'd be very welcome to join discussions about the future of GNU 
Radio and make sure it is as good as possible for you too.


Cheers
Johannes

On 23.12.20 02:21, Glen Langston wrote:

Hello GNuradio Superheros,

I have to say, after 5 years with gnu radio, I’m either tool old or
something has to change.

I’ve been trying to produce some tools for High School teacher to do radio 
astronomy.
and for that gnuradio 3.7 was perfectly fine.  However some people are 
continuing
to make “improvements” that break everything.   I used to really like gnuradio.

I like the SDRPlay device, but it can not be used in gnuradio 3.8.  According 
to the web.
But the web indicates it might be usable in 3.9
So I installed 3.9 only to find that swig has been replace by pybind.  This 
breaks all my
existing C++ modules.   The modules worked fine, but if using ubuntu 20.40 the 
students can not
easily install gnuradio 3.7.  The pybind instructions are puzzling.  gr-modtool 
all the
modules copy something or other.   This is for no good reason that I’m aware of.
Either make the equivalent of pythons “2to3” or do not make the gnuradio 
fundamental changes.

Stop making useless changes that break all code!

We do NOT need these changes.  The advice on the web, after I’ve spent 2 days 
building 3.9
on a Raspberry pi is use 3.8.  This is frustrating.

The documentation is falling apart because of all these variants.

It is good to make changes that ADD tool capabilities.  It is NOT good to make 
changes that
make small improvements and break such large fractions of the code.

Sorry for the Rant.

Best regards Glen







On Dec 22, 2020, at 3:43 PM, Adam Gorski  wrote:

Marcus,

Thank you for the detailed response! This enriches my understanding of the 
demod process as well as the knobs involved; looks like I'll have to go back to 
the drawing board to implement something similar using non-deprecated blocks.

Thanks,

Adam Gorski
Virginia Tech Applied Research Corporation (VT-ARC)
Lead Communications Engineer
410-818-3188

-Original Message-
From: Discuss-gnuradio 
 On Behalf Of Marcus 
Müller
Sent: Tuesday, December 22, 2020 8:11 AM
To: discuss-gnuradio@gnu.org
Subject: Re: Setting DPSK Demod Block Parameters

Hi Adam,

I'm very sorry, you **really** really shouldn't be using that block (and that's 
the reason it's deprecated): it has bugs that just lose data. So, it's not 
really all that useful if I spend time reading old GNU Radio's source code to 
figure out what /exactly/ you want: You'll have to use a different block, 
sorry. Can't offer you to fix that block, we've tried and decided against it.

Since you'll need to know the answers to these even if you implement this 
differently, let me quickly answer in-text:

On 22/12/2020 02.13, Adam Gorski wrote:

  * Excess bandwidth: I've read that in general the more excess
bandwidth supplied the 

[VOLK] Release v2.4.1

[Johannes Demel]

Hi everyone!

We have a new VOLK bugfix release! We are happy to announce VOLK v2.4.1! 
We want to thank all contributors. This release wouldn't have been 
possible without them.


Our v2.4.0 release introduced quite a lot of changes under the hood. 
With this bugfix release, we want to make sure that everything works as 
expected again.


You can find the release news on 
[libvolk.org](https://www.libvolk.org/category/news.html)


### Contributors

* A. Maitland Bottoms 
* Johannes Demel 
* Michael Dickens 
* Philip Balister 
* Ron Economos 
* Ryan Volz 


### Changes

* Build
- cpu_features CMake option
- Add cpu_features to static library build.
- Use static liborc-0.4 library for static library build.
- cmake: Detect if cpu_features submodule is present.

* Install
- Check for lib64 versus lib and set LIB_SUFFIX accordingly.

* CI
- Add CI test for static library build.

* Releases
- project: Include git submodules (i.e. cpu_features) in release 
tarball.

- scripts: Add GPG signature to release script

* Other
- readme: Update TravisCI status badge

[VOLK] Release v2.4.0

[Johannes Demel]

Hi everyone!

We have another VOLK release! We're happy to announce VOLK v2.4.0! We 
want to thank all contributors. This release wouldn't have been possible 
without them.


We introduce `cpu_features` as a private submodule in this release 
because we use it to detect CPU features during runtime now. This should 
enable more reliable feature detection. Further, it takes away the 
burden to implement platform specific code. As a result, optimized VOLK 
kernels build for MacOS and Windows with AppleClang/MSVC out-of-the-box now.


You can find the release news on 
[libvolk.org](https://www.libvolk.org/category/news.html)


### Highlights

* Documentation
- Update README to be more verbose and to improve usefulness.

* Compilers
- MSVC: Handle compiler flags and thus architecture specific 
kernels correctly. This enables optimized kernels with MSVC builds.

- AppleClang: Treat AppleClang as Clang.
- Paired with the `cpu_features` introduction, this enables us to 
use architecture specific kernels on a broader set of platforms.

* CI
- Update to newest version of the Intel SDE
- Test the rotator kernel with a realistic scalar
- Introduce more test cases with newer GCC and newer Clang versions.
* CMake
- Enable to not install `volk_modtool`.
- Remove "find_package_handle_standard_args" warning.
* cpu_features
- Use `cpu_features` v0.6.0 as a private submodule to detect 
available CPU features.

- Fix incorrect feature detection for newer AVX versions.
- Circumvent platform specific feature detection.
- Enable more architecture specific kernels on more platforms.
* Kernels
- Disable slow and broken SSE4.1 kernel in `volk_32fc_x2_dot_prod_32fc`
- Adjust min/max for `32f_s32f_convert_8i` kernel
- Use `INT8_*` instead of `CHAR_*`


### Contributors

* Adam Thompson 
* Andrej Rode 
* Christoph Mayer 
* Clayton Smith 
* Doron Behar 
* Johannes Demel , 
* Martin Kaesberger 
* Michael Dickens 
* Ron Economos 


### Changes

* Documentation
- Update README to include ldconfig upon volk build and install 
completion

- Update README based on review
- readme: Fix wording
- docs: Fix conversion inaccuracy

* MSVC
- archs: MSVC 2013 and greater don't have a SSE flag

* CI
- update to newest version of the Intel SDE
- Test the rotator kernel with a realistic scalar

* CMake
- build: Enable to not install volk_modtool
- cmake: Remove "find_package_handle_standard_args" warning.
- cmake: Ensure that cpu_features is built as a static library.

* cpu_features
- readme: Add section on supported platforms
- readme: Make supported compiler section more specific
- travis: Add GCC 9 test on focal
- travis: Add tests for clang 8, 9, 10
- travis: Fix incorrect CXX compiler assignment
- cpu_features: Remove unused feature checks
- ci: Update TravisCI for cpu_features
- cpu_features: Fix MSVC build
- pic: Fix BUILD_PIC issue
- ci: Update CI system configuration
- cpu_features: Bump submodule pointer to v0.6.0
- docs: Add hints how to handle required submodules
- cpu_features: Switch to cpu_features
- ci: Update CI system for cpu_features
- cpu_features: Force PIC build flag
- appveyor: Add recursive clone command
- cpu_features: Remove xgetbv checks
- pic: Cache and force BUILD_PIC
- ci: Remove explicit BUILD_PIC from cmake args
- ci: Remove BUILD_PIC from CI cmake args
- cpu_features: Remove commented code
- cpu_features: Assume AppleClang == Clang
- cpu_features: Remove obsolete code in archs.xml
- fix for ARM cross-compiling CI
- ARM CI: remove unneeded environment variables

* Housekeeping
- structure: Move release scripts to scripts folder

* Kernels
- emit an emms instruction after using the mmx extension
- volk_32fc_x2_dot_prod_32fc: disable slow & broken SSE4.1 kernel
- fix: Adjust min/max for 32f_s32f_convert_8i kernel
- fix: Use INT8_* instead of CHAR_*

Re: clang formating

[Johannes Demel]

Hi Gisle,

`file` is not a placeholder but the literal argument. `--style=file` 
tells `clang-format` to search for a `.clang-format` file in the current 
and parent folders.


Cheers
Johannes

On 11.11.20 13:19, Gisle Vanem wrote:

Johannes Demel wrote:


unless the clang-format behavior changed, the function call should be:

clang-format --style=file -i path/to/file.cc

The `--style=file` option tells clang-format to search for a 
`.clang-format` file.


Does not work on Windows (using clang-format v10.0.0).
In a .bat-file I have:
   clang-format.exe -style=%GR_ROOT%/.clang-format -i %*

No matter how style is; '--style' or '-style', it
says 'Invalid value for -style'.

Only these values works:
   LLVM, Google, Chromium, Mozilla, WebKit.
which all are equally ugly.

Re: clang formating

[Johannes Demel]

Hi,

unless the clang-format behavior changed, the function call should be:

clang-format --style=file -i path/to/file.cc

The `--style=file` option tells clang-format to search for a 
`.clang-format` file.


Cheers
Johannes

On 11.11.20 11:47, Ron Economos wrote:
I forgot to mention, you have to run clang-format-10 in tree. It gets 
the formatting rules from the file .clang-format in the top level 
directory.


Ron

On 11/11/20 02:41, Ron Economos wrote:

On Ubuntu 20.04:

sudo apt-get install clang-format-10

Then update your changed files.

clang-format-10 -i sourcefile.cc

The -i formats the file in place. Otherwise, output is to stdout.

Ron

On 11/11/20 02:20, Volker Schroer wrote:

Hi,

I just made a pr and got the message that the pr formatting check
failed. But looking at the output I don't understand, what's wrong.

Even more I'd like to know how I can do the formatting check locally.
The coding guide in the wiki is empty.

Thanks in advance

-- Volker

Re: Messages into two blocks: Message order & timing guaranteed?

[Johannes Demel]

Hi Lukas,

I'd suggest you use timed transmissions with your USRP. I assume you 
want to build a TDD system. In that case, it would be advisable to avoid 
transmitting `0`s. One more reason to use timed transmissions.


I assume your align block is some kind of synchronization. I suggest to 
sync your RX stream first and then use your messages to align your stream.


Your 2 Msg2Tag blocks will probably deviate sometimes since they run in 
separate threads.


Cheers
Johannes

On 25.08.20 18:35, Lukas Haase wrote:

Hi,

I have a block that generates messages (may be very fast, in the ms range or 
below).

At some point I need to convert these into precise, repeatable timing, so I have a 
"Msg2Tag" block. It takes messages at the input and outputs a sample stream of zeros with 
the messages as tags. However, since I need repeatable and precice timing, that block has a 
parameter "period" and it would insert a tag only every period-th sample.

+-+  Msg+-+
| Message +>+ Msg2Tag |-> Stream with 0s, tag every period-th sample
+-+ +-+

Now I want to copy this "Message to Tag" block and feed it with the same 
message source.


+-+  Msg+-+
| Message +---+>+ Msg2Tag |-> Stream with tags #1
+-+   | +-+
   |
   | +-+
   `>+ Msg2Tag |-> Stream with tags #2
 +-+

*** Will both output sequences (and tags) be guaranteed to be identical?


*** Why am I doing this? I have a system with a query and response (think of an RFID reader 
for example) based on USRP. The query/response time is short (>1ms). I need to perfectly 
time-align the USRP response with the USRP query. Right now I only have one "Message to 
Tag" block which I use as global timing control: I feed this signal not only into the 
USRP Sink but also in a block that properly aligns the response from USRP Source:


+-+  Msg+-+  +---+
| Message +>+ Msg2Tag |-+--->+ USRP Sink |
+-+ +-+ |+---+
 |
 |+-+
`--->+ |
  | Align   |-> Further
  ,-->+ |   processing
/+-+
 |
  +-+|
  + USRP Source |'
  +-+

(Note that I am omitting blocks and details for the sake of clarity).

However, a configuration in which the USRP is "in the loop" seems to be 
extremely unreliable [*].
Since I can perfectly reproduce the signal that goes into the USRP Sink, I 
could just clone the block; I would not need to use the same output stream of 
the Msg2Tag block.
However, for reproducible results, the clone must be guaranteed to be an 
identical copy.


I am afraid that with two Msg2Tag blocks, the result will not be guaranteed the 
same. Which options do I have for my setup? I do want to use messages initially 
because it makes high-level protocol stuff much easier.

Thanks,
Lukas


PS: I heard about gr-eventstream but want to avoid it if possible.

[*] While this setup seems to be working for some parameters (such as inserting huge 
delay blocks and changing min output buffer of Msg2Tag block, this generally seems to be 
unreliable and at some point the USRP reports a late packets. I think this is because now 
the "Align" block dictates the sample flow. It might let Msg2Tag buffer lots of 
samples at the output while reading in samples from USRP Source. During this time, the 
USRP clock proceeds. Once the samples in the buffer are sent to the USRP, they are late 
and the system breaks.

Re: volk and alignment

[Johannes Demel]

Hi Thomas,

with AVX512 we have maximum 64byte alignment. That's the current maximum 
`volk_get_alignment` could return. Of course, that'll change at some 
point in the future. So, at the moment we could define this value and 
hope we'll update it as soon as we introduce our first kernel that uses 
AVX1024 or smth NEON related. Those return values are defined in [0].
At the moment I'd be in favor of using `aligned_alloc` for aligned 
allocation since all other implementations have shown issues at some 
point. But then again relying on standardized functions breaks for 
non-compliant compilers.


> ```
> char buf[alignment+bytes_needed];
> int adjust = (aligned - (buf % alignment)) % aligned;
> char* p = buf + adjust;
> ```
We had a similar implementation to allocate aligned buffers in case none 
of the other methods were available. Of course this broke on some 
machines. Although these issues came up with heap allocation.


`alignas()` would solve this issue if we would always go for this 
maximum alignment. Do all compilers we target support `alignas`?

What are the pros and cons?

Cheers
Johannes

[0] 
https://github.com/gnuradio/volk/blob/91e5d073532ea6c516d9984e8d4dfcc645fddac8/gen/archs.xml#L291


On 08.07.20 21:48, tho...@habets.se wrote:

On Wed, 8 Jul 2020 18:09:30 +0100, "Marcus Müller"  said:

  > Is there a maximum size that volk_get_alignment could return, a size
  > that's reasonable?

I'd go with "realistically, yes, but isn't relying on that a bad idea?".


Yes, it does sound like a bad idea. :-)
Really I'm looking to solve the problem, not a specific solution.


I'm thinking back and forth about how to address that problem.
Basically, what we'd need is a "worst case of all available machines"
alignment, that is present in an integer constant expression, so you can
put it into alignas(), right?


Right.

It's not my field, but surely 4kiB will align everything? On the other
hand, of course, stepping into a new page may incur a page fault,
which could be more than even using `volk::vector` which may incur an
allocation, but usually won't incur a context switch.

I suppose a mere dynamic stack alloc would do just fine:

```
char buf[alignment+bytes_needed];
int adjust = (aligned - (buf % alignment)) % aligned;
char* p = buf + adjust;
```

(except making sure that the pointer arithmetic doesn't cause UB. Off
the top of my head I don't know the right types to use)

Not very nice with two mod ops per time this is needed, though. For
the PR linked to this would happen every sample.

Another option is a thread-local stack, which would make
allocs/deallocs very cheap. Assuming all use cases of this would be
for local variables.

--
typedef struct me_s {
   char name[]  = { "Thomas Habets" };
   char email[] = { "tho...@habets.se" };
   char kernel[]= { "Linux" };
   char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt; };
   char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
   char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

Re: Calculating SNR of an incoming signal

[Johannes Demel]

Hi Alex,

please keep this discussion on the mailing list. Thus, I included the 
mailing list in this reply again.


Let's summarize your system
carrier frequency 5.8GHz
Radar ranging with reflection loss. Do you have any info on your 
reflecting object? An objects radar cross-section may heavily influence 
your results.
You stated, you'd work on a passive RF ranging system. The setup you 
describe is active though. I'm curious how you'll convert this to a 
passive system.


What's the signal structure you send? Is it just a sine? Is it random 
QPSK symbols? What's your frontend's carrier frequency? Which SDR 
frontend do you use? A USRP? A HackRF?


As long as your bandwidth definition together with your SNR definition 
is sound, it might work to pre-calibrate your system. You might want to 
do this periodically in case you'll run it for a longer time.


EO (Electro-Optical?)

Cheers
Johannes

On 26.06.20 18:01, Alex Batts wrote:

Hello,

Yes, I understand the Nyquist sampling theorem and my hardware 
limitations. That is why I assumed filtering would not work although I 
gave it a shot anyways. I am not trying to demodulate any baseband 
signal, rather I am going to be receiving a reflected signal at around 
5.8 GHz and using that signal for range detection. The signal itself 
will not contain any information, but the strength of the signal is the 
information I need. However, I need a method for determining, or at 
least estimating, SNR because that is the key variable that will change 
throughout my experiment in the radar range equation and will ultimately 
be the deciding factor to determine how far away the object is. That was 
why I proposed doing a pre-trial calculation where my source is not 
transmitting to get the average noise power, and then set that as a 
constant block and subtract it in real time from my average total power 
with noise and signal both included. The constant block would then be 
updated prior to each run.


A necessary part of the radar range equation is the transmit power from 
the source as well as the directivity. The SNR I'll be looking for is at 
the receiver. So the equation takes care of any signal attenuation.


I'm building a passive RF range calculation system in conjunction with 
an EO object tracking system.


Thank you,

Alex



On Fri, Jun 26, 2020 at 11:14 AM Johannes Demel <mailto:de...@ant.uni-bremen.de>> wrote:


Hi Alex,

your cut-off frequency needs to be lower than half your sampling rate.
If your sampling rate is 61.44MHz, your maximum cut-off frequency
can be
30.72MHz. And it should probably be a bit lower. You're working in
baseband here. It is really important to understand the concepts of
digital signal processing. That's also the reason I pointed out several
resources.

SNR calculation itself is not always trivial. You need a way to
distinguish samples that should only carry noise energy and those that
should carry signal energy.
Often people distinguish between SNR estimation for AWGN channels and
for fading channels. While your estimator will probably not distinguish
between the two, some estimators just fail for fading channels
especially.
For OFDM you might want to look into Schmidl preamble based SNR
estimation. There might be an M2M4 estimator for symbol based SNR
estimation.
What kind of system are you using?

Cheers
Johannes


On 26.06.20 15:49, Alex Batts wrote:
 > Right, because the filter cutoff frequency needs to be at least
half the
 > sampling rate, I figured I would not be able to use a filter
since the
 > bladeRF I will be using has a 61.44 MHz sampling rate and I will be
 > operating in the GHz range.
 >
 > What I will probably end up having to do is do a pre-run calibration
 > where the tone is not playing, use a complex to mag^2 and average
power
 > combination, set that as a constant block, and then subtract the
 > calibrated constant from the total power when the tone is on to
get the
 > most accurate possible signal power. While not ideal because it
is not a
 > truly live SNR calculation, it is the best workaround that avoids
the
 > filter I can think of.
 >
 > If there are any other suggestions to get a more live/real time SNR
 > calculation I am open to that as well.
 >
 > Thank you for the help,
 >
 > Alex
     >
 >
 >
 > On Fri, Jun 26, 2020 at 4:17 AM Johannes Demel
mailto:de...@ant.uni-bremen.de>
 > <mailto:de...@ant.uni-bremen.de
<mailto:de...@ant.uni-bremen.de>>> wrote:
 >
 >     Hi Alex,
 >
 >     "0 < fa <= sampling_rate/2" is correct and should always be
 >     enforced. If
 >     you try to set your filter cut-off frequency at >=
samp

Re: Calculating SNR of an incoming signal

[Johannes Demel]

Hi Alex,

your cut-off frequency needs to be lower than half your sampling rate.
If your sampling rate is 61.44MHz, your maximum cut-off frequency can be 
30.72MHz. And it should probably be a bit lower. You're working in 
baseband here. It is really important to understand the concepts of 
digital signal processing. That's also the reason I pointed out several 
resources.


SNR calculation itself is not always trivial. You need a way to 
distinguish samples that should only carry noise energy and those that 
should carry signal energy.
Often people distinguish between SNR estimation for AWGN channels and 
for fading channels. While your estimator will probably not distinguish 
between the two, some estimators just fail for fading channels especially.
For OFDM you might want to look into Schmidl preamble based SNR 
estimation. There might be an M2M4 estimator for symbol based SNR 
estimation.

What kind of system are you using?

Cheers
Johannes


On 26.06.20 15:49, Alex Batts wrote:
Right, because the filter cutoff frequency needs to be at least half the 
sampling rate, I figured I would not be able to use a filter since the 
bladeRF I will be using has a 61.44 MHz sampling rate and I will be 
operating in the GHz range.


What I will probably end up having to do is do a pre-run calibration 
where the tone is not playing, use a complex to mag^2 and average power 
combination, set that as a constant block, and then subtract the 
calibrated constant from the total power when the tone is on to get the 
most accurate possible signal power. While not ideal because it is not a 
truly live SNR calculation, it is the best workaround that avoids the 
filter I can think of.


If there are any other suggestions to get a more live/real time SNR 
calculation I am open to that as well.


Thank you for the help,

Alex



On Fri, Jun 26, 2020 at 4:17 AM Johannes Demel <mailto:de...@ant.uni-bremen.de>> wrote:


Hi Alex,

"0 < fa <= sampling_rate/2" is correct and should always be
enforced. If
you try to set your filter cut-off frequency at >= samp_rate/2, you'll
experience aliasing.

After reading your mails, I get the impression you try to set your
filter cut-off frequency at your carrier frequency $f_c$ + bandwidth/2
$B/2$. Or something in that range. That won't work in baseband.
Effectively, your signal at $f_c$ goes through a mixer and is shifted
such that it would appear at $0$ in your baseband signal.

There's a lot of digital signal processing fundamentals involved. I
like
the explanations given in [0]. Though, of course there are well known
books such as the ones by Proakis or Sklar on the topic.

Cheers
Johannes

[0] https://dspillustrations.com/pages/index.html

On 25.06.20 22:22, Alex Batts wrote:
 > The effective noise bandwidth is part of the calculation. I'm
using the
 > radar range equation.
 >
 > My purpose for including the bandwidth in my response was that
any time
 > I try to use a filter with a frequency greater than my sampling
rate/2 I
 > get an error returned. I agree that ideally I would use a band-pass
 > filter with very narrow cutoffs to best capture the signal in its
 > entirety, however, I can't because the frequency I'm trying to
set my
 > filter at is more than half my sampling rate, giving me an error.
Maybe
 > there is something askew with that error and it's something else,
but it
 > returns saying 0 < fa <= sampling_rate/2
 >
 > On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller mailto:muel...@kit.edu>
 > <mailto:muel...@kit.edu <mailto:muel...@kit.edu>>> wrote:
 >
 >     Hi Alex,
 >
 >     On 25/06/2020 21.00, Alex Batts wrote:
 >      > I'm sampling an incoming signal, but only around 2 MSps.
 >      >
 >
 >     and that's fine! that's the *equivalent* baseband, it has all
the same
 >     information as the RF signal.
 >
 >      > I need the signal power to noise power ratio at the
receiver as
 >     part of
 >      > my range calculation.
 >
 >     Yes, but you'd always want to do that "signal to noise" only
in the
 >     bandwidth that actually contains your tone; the rest will
just contain
 >     more noise, interferers... to make your measurement worse.
 >
 >      > So I would need to be able to distinguish between
 >      > the power of the tone vs the power of the surrounding
noise and use
 >      > those two numerical values in an equation to calculate the
range.
 >
 >     You need to define "surrounding"! Your signal doesn't get
worse by
 >     applying a filter that only select

Re: Calculating SNR of an incoming signal

[Johannes Demel]

Hi Alex,

"0 < fa <= sampling_rate/2" is correct and should always be enforced. If 
you try to set your filter cut-off frequency at >= samp_rate/2, you'll 
experience aliasing.


After reading your mails, I get the impression you try to set your 
filter cut-off frequency at your carrier frequency $f_c$ + bandwidth/2 
$B/2$. Or something in that range. That won't work in baseband.
Effectively, your signal at $f_c$ goes through a mixer and is shifted 
such that it would appear at $0$ in your baseband signal.


There's a lot of digital signal processing fundamentals involved. I like 
the explanations given in [0]. Though, of course there are well known 
books such as the ones by Proakis or Sklar on the topic.


Cheers
Johannes

[0] https://dspillustrations.com/pages/index.html

On 25.06.20 22:22, Alex Batts wrote:
The effective noise bandwidth is part of the calculation. I'm using the 
radar range equation.


My purpose for including the bandwidth in my response was that any time 
I try to use a filter with a frequency greater than my sampling rate/2 I 
get an error returned. I agree that ideally I would use a band-pass 
filter with very narrow cutoffs to best capture the signal in its 
entirety, however, I can't because the frequency I'm trying to set my 
filter at is more than half my sampling rate, giving me an error. Maybe 
there is something askew with that error and it's something else, but it 
returns saying 0 < fa <= sampling_rate/2


On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller > wrote:


Hi Alex,

On 25/06/2020 21.00, Alex Batts wrote:
 > I'm sampling an incoming signal, but only around 2 MSps.
 >

and that's fine! that's the *equivalent* baseband, it has all the same
information as the RF signal.

 > I need the signal power to noise power ratio at the receiver as
part of
 > my range calculation.

Yes, but you'd always want to do that "signal to noise" only in the
bandwidth that actually contains your tone; the rest will just contain
more noise, interferers... to make your measurement worse.

 > So I would need to be able to distinguish between
 > the power of the tone vs the power of the surrounding noise and use
 > those two numerical values in an equation to calculate the range.

You need to define "surrounding"! Your signal doesn't get worse by
applying a filter that only selects your tone and as little else as
possible. So you should do that – it makes your SNR better. Hence, your
Signal power estimate gets more reliable (which you definitely want).

(that also highlights why I have a bit of doubt on your measurement
methodology – if your SNR depends on receiver bandwidth, then how much
does it actually tell you about the range, unless you specify the
bandwidth alongside with it?)

Think about it: we typically assume noise to be white, i.e. to have
identical power spectral density all over the spectrum, e.g. -170
dBm/Hz.

Now, if your receiver bandwidth is set to 2 MHz (because that's what
your SDR is probably configured to filter out if you ask for 2 MS/s),
then you get twice as much noise power than if you set the sampling
rate
to 1 MS/s.

It's the same thing that I always let students figure out by themselves
the first time they use the lab spectrum analyzer:
Feed a 2 GHz -60 dBm tone into the spectrum analyzer.
Set the resolution bandwidth of the spectrum analyzer to 1 MHz, and
tell
me what the SNR is. Now set the resolution bandwidth to 300 kHz and
tell
me again.
You get as much "N" in your SNR as you let through your system. In the
case of the spectrum analyzer, every point on the display is the power
in 1 MHz (or 300 kHz) of filter. In the case of your Qt plot, it's the
power in a FFT bin. There's (f_sample)/(FFT length) bandwidth to each
bin; so your graphical analysis hinges on the setting of sample rate
and
FFT length (also, on window choice and labeling, and software
convention). Proportionally!

It's really hard to define "SNR" for 0-bandwidth, i.e. a single tone
(having a single tone, actually, gets tricky physically, but there's a
lot of people who could tell you more about oscillators than I could).

If you'd be fair, the only choice for the noise filter bandwidth would
be 0 Hz, because if you chose any wider, you always get more noise. But
in 0 Hz, there's actually 0 noise power! So, that doesn't work.

Instead, you need to define SNR exactly on the bandwidth your detection
system will have to use. That's a design parameter you haven't
mentioned
so far!

 > This
 > is why I referenced the green and red lines on the qt gui freq.
display,
 > this would seem to give me signal strength in dB.

Hopefully, above explained how much these lines depend on your
configuration and aren't "SNR".

Cheers,

Re: Problems with the GNU WiFi and the USRP B210

[Johannes Demel]

Hi Silvio,

please do not send docx Files. After reading Marcus answer, I assume 
your file contains valid info. But I thought this was just a spam or 
phishing mail. I'd totally expect some malicious macro in such a file. I 
see such malicious attachments regularly going through my spam filter.

Also, use pdf please.

Since we are on a publicly archived mailing list, it is really 
preferable to describe your issue directly in your email and just 
reference illustrations. In the past, people were asked to upload files 
to a platform and just add a link to their email.


Cheers
Johannes


On 26.06.20 01:21, Silvio Cardero wrote:

Please open and read the document

​

signature_658765992



Silvio Cardero

Chief Scientist

520.247.7275 (cell)

Web www.ed2corp.com 

Email Silvio@ed2corp _.com_

7636 N. Oracle Road

Tucson, Az. 85704

Re: Building gnuradio and hooking into neonv8

[Johannes Demel]

Hi John,

VOLK tries to figure out the correct flags for you. We run CI tests for 
aarch64, so these seem to work. Unless you have a good reason to set 
compiler flags, I'd recommend to stick with what CMake detects for you.


The line `-- CPU is armv8, Overruled arch neonv7` tells you that armv8 
was detected. Thus, we disable neonv7 and enable neonv8 if the compiler 
supports it. On another system you'd see the inverse. We had a 
discussion if it would be reasonable to enable both archs and select the 
correct one during runtime but apparently you either have one arch or 
the other, never both.


Cheers
Johannes

On 30.05.20 14:56, John Langworthy wrote:

Hi Ron,

Just seen your last. I had written this before you sent it, but thought 
worth sharing anyway


Building volk with that toolchain does fail, see directly below. See 
also further down, cmake output from volk without it (which is successful).


(gr_py36) pi@raspberry:~/volk/build$ cmake -DCMAKE_BUILD_TYPE=Release 
-DPYTHON_EXECUTABLE=~/.conda/envs/gr_py36/python3/bin 
-DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a72_hardfp_native.cmake 
../


-- The C compiler identification is GNU 7.5.0

-- The CXX compiler identification is GNU 7.5.0

-- Check for working C compiler: /usr/bin/gcc

-- Check for working C compiler: /usr/bin/gcc -- broken

CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 
(message):


   The C compiler

     "/usr/bin/gcc"

   is not able to compile a simple test program.

   It fails with the following output:

     Change Dir: /home/pi/volk/build/CMakeFiles/CMakeTmp

 Run Build Command:"/usr/bin/make" "cmTC_ba179/fast"

     /usr/bin/make -f CMakeFiles/cmTC_ba179.dir/build.make 
CMakeFiles/cmTC_ba179.dir/build


     make[1]: Entering directory '/home/pi/volk/build/CMakeFiles/CMakeTmp'

     Building C object CMakeFiles/cmTC_ba179.dir/testCCompiler.c.o

     /usr/bin/gcc   -march=armv8-a -mtune=cortex-a72 -mfpu=neon-fp-armv8 
-mfloat-abi=hard    -o CMakeFiles/cmTC_ba179.dir/testCCompiler.c.o   -c 
/home/pi/volk/build/CMakeFiles/CMakeTmp/testCCompiler.c


     gcc: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’

     gcc: error: unrecognized command line option ‘-mfloat-abi=hard’

     CMakeFiles/cmTC_ba179.dir/build.make:65: recipe for target 
'CMakeFiles/cmTC_ba179.dir/testCCompiler.c.o' failed


     make[1]: *** [CMakeFiles/cmTC_ba179.dir/testCCompiler.c.o] Error 1

     make[1]: Leaving directory '/home/pi/volk/build/CMakeFiles/CMakeTmp'

     Makefile:126: recipe for target 'cmTC_ba179/fast' failed

     make: *** [cmTC_ba179/fast] Error 2

   CMake will not be able to correctly generate this project.

Call Stack (most recent call first):

   CMakeLists.txt:23 (project)

-- Configuring incomplete, errors occurred!

Without the toolchain, I get:

(gr_py36) pi@raspberry:~/volk/build$ cmake -DCMAKE_BUILD_TYPE=Release 
-DPYTHON_EXECUTABLE=~/.conda/envs/gr_py36/bin/python3.6 ../


-- Build type set to Release.

-- Extracting version information from git describe...

--

-- Python checking for python >= 3.4

-- Python checking for python >= 3.4 - found

--

-- Python checking for mako >= 0.4.2

-- Python checking for mako >= 0.4.2 - found

-- Looking for C++ include filesystem

-- Looking for C++ include filesystem - not found

-- Looking for C++ include experimental/filesystem

-- Looking for C++ include experimental/filesystem - found

-- Performing Test CXX_FILESYSTEM_NO_LINK_NEEDED

-- Performing Test CXX_FILESYSTEM_NO_LINK_NEEDED - Failed

-- Performing Test CXX_FILESYSTEM_STDCPPFS_NEEDED

-- Performing Test CXX_FILESYSTEM_STDCPPFS_NEEDED - Success

-- Looking for aligned_alloc

-- Looking for aligned_alloc - found

-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")

-- Checking for module 'orc-0.4 > 0.4.11'

--   No package 'orc-0.4' found

-- orc files (missing: ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE)

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") found 
components:  doxygen missing components:  dot


-- QA Testing is enabled.

--   Modify using: -DENABLE_TESTING=ON/OFF

-- System profiling is disabled.

--   Modify using: -DENABLE_PROFILING=ON/OFF

-- Looking for cpuid.h

-- Looking for cpuid.h - not found

-- Looking for intrin.h

-- Looking for intrin.h - not found

-- Looking for fenv.h

-- Looking for fenv.h - found

-- Looking for dlfcn.h

-- Looking for dlfcn.h - found

-- Compiler name: GNU

-- Performing Test HAVE_WERROR_UNUSED_CMD_LINE_ARG

-- Performing Test HAVE_WERROR_UNUSED_CMD_LINE_ARG - Failed

-- Performing Test have_mfloat_abi_softfp

-- Performing Test have_mfloat_abi_softfp - Failed

-- Performing Test have_mfloat_abi_hard

-- Performing Test have_mfloat_abi_hard - Failed

-- Performing Test have_funsafe_math_optimizations

-- Performing Test have_funsafe_math_optimizations - Success

-- Performing Test have_mfpu_neon

-- Performing Test have_mfpu_neon - Failed

-- Performing Test have_m32

-- Performing Test 

Re: GNU Radio 3.7 on Ubuntu 20.04

[Johannes Demel]

Hi all,

we all saw the Python clock [0] run out on 2020-01-01 after over 10 years.

Also, Maitland Bottoms had to add GR patches to switch from Qt4 to Qt5 
for GR 3.7 even earlier to be able to get GR3.7 into newer Debian 
versions. Apps are not accepted to the repos if they run with Qt 
versions < 5.


All in all, new systems require new software. In this case GR3.8.

If you really need a GR3.7 install, this worked for me:
`sudo docker run --rm -it --net=host --env="DISPLAY" 
--volume="$HOME/.Xauthority:/root/.Xauthority:rw" 
`. cf [1]
At least I could open and run flowgraphs and run UHD commands. I used 
GR3.8 from `ppa:gnuradio` though the docker command should work as well. 
 USB devices might be another adventure.

You probably want to set up a new container with the latest GR3.7 release.

Cheers
Johannes


[0] https://pythonclock.org/
[1] 
https://medium.com/@SaravSun/running-gui-applications-inside-docker-containers-83d65c0db110


On 15.05.20 03:31, James Hayek wrote:
I tried it and ran into a ton of problems... I posted it earlier today. 
Nothing as of yet, but I am still researching. I might give up and 
install Ubuntu 18 so I can use the new Pluto I bought. ;)



iio Block Errors (WSL) Ubuntu 20.04 LTS

I am running a Windows 10 system where I have installed the Windows 
Subsystem for Linux running Ubuntu 20.04 LTS.
I followed the steps outlined here: 
http://wiki.analog.com/resources/tools-software/linux-software/gnuradio


After doing the steps outlined above, I ran into the following error.

·Traceback (most recent call last):

·File 
"/home/jameshayek/GNURadio-Projects/FMReceiver/Simple_FM_Receiver.py", 
line 35, in 


·from gnuradio.qtgui import Range, RangeWidget

·File "/usr/lib/python3/dist-packages/gnuradio/qtgui/__init__.py", line 
36, in 


·from .qtgui_swig import *

·File "/usr/lib/python3/dist-packages/gnuradio/qtgui/qtgui_swig.py", 
line 13, in 


·from . import _qtgui_swig

·ImportError: libQt5Core.so.5: cannot open shared object file: No such 
file or directory



I assume this is an issue with mapping the location of swig, so copied 
the recursive directory to the gnuradio folder as the lesson said if 
there is a swig import error. Still no luck.


I also thought it was an issue with the qt5 library, so I ran "sudo 
apt-get install -y qt5-default"


But still no luck.

/Is this an issue with Ubuntu 20?/

/
/

My exact steps are shown below.

1.Moving Post-Install to Pre-Install:

oFor Python 3.8 I initially exported the following location to $PYTHONPATH

§export PYTHONPATH=$PYTHONPATH:/usr/lib/python{PYTHON VERSION}/{site or 
dist}-packages


·export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3.8/dist-packages/

oI used the python3.8 folder since GNC > About showed Python 3.8

oI then noticed I must have added the wrong PATH, because find resulted 
in: “/usr/lib/python3/dist-packages/gnuradio”


oI re-ran the “export” command to include what “find” returned.

2.Installing all “apt install” dependencies:

osudo apt install libxml2 libxml2-dev bison flex cmake git libaio-dev 
libboost-all-dev


osudo apt install liborc-dev

osudo apt install swig

§I was under the impression this was not needed for 3.8; however I did 
have it installed as a failsafe.


osudo apt install bison flex cmake git libgmp-dev

oOther stuff that I didn’t need but installed anyway

§sudo apt install libavahi-common-dev libavahi-client-dev

§sudo apt install libusb-1.0-0-dev

§sudo apt install doxygen

3.Building from source:


olibiio

§git clone https://github.com/analogdevicesinc/libiio.git

§cd libiio

§cmake ./

§make

§sudo make install

§cd ../


olibad9361-iio

§git clone https://github.com/analogdevicesinc/libad9361-iio.git

§cd libad9361-iio

§cmake ./

§make

§sudo make install

§cd ../


ogr-iio

§git clone -b upgrade-3.8 https://github.com/analogdevicesinc/gr-iio.git

§cd gr-iio

§cmake ./

§make

§sudo make install

§cd ../

§sudo ldconfig



4.Because it seems like I have a swig import issue, I copied the 
directory to the gnuradio folder


osudo cp -r /usr/local/lib/python3/dist-packages/iio/ 
/usr/lib/python3/dist-packages/gnuradio/


image.png


My $PYTHONPATH has the following locations:

image.png

Any advice as to what went wrong?

 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, May 14, 2020 at 11:30 AM Alex Humberstone 
mailto:alex.m.humberst...@gmail.com>> wrote:


The new Ubuntu 20.04 does not include Python 2 anymore. But GNU
Radio 3.7 requires Python 2. So then can you run GNU Radio 3.7 on
Ubuntu 20.04? I think there's still a package that you can instal to
add Python 2 support in Ubuntu 20.04. I found a bunch of websites
that make it sound like this should be possible. So I'm thinking it
should still actually 

[VOLK] Release 2.3.0

[Johannes Demel]

Hi everyone!

VOLK 2.3 is out! We want to thank all contributors. This release
wouldn't have been possible without them. We saw lots of great improvements.

On GNU Radio 'master' VOLK was finally removed as a submodule.

Currently we see ongoing discussions on how to improve CPU feature
detection because VOLK is not as reliable as we'd like it to be in that
department. We'd like to benefit from other open source projects and
don't want to reinvent the wheel. Thus, one approach would be to include
`cpu_features` as a submodule.

### Highlights

* Better reproducible builds
* CMake improvements
- ORC is removed from the public interface where it was never
supposed to be.
- CMake fixes for better usability
* Updated and new CI chain
- TravisCI moved to new distro and does more tests for newer GCC/Clang
- Github Actions
- Add Action to check proper code formatting.
- Add CI that also runs on MacOS with XCode.
* Enforce C/C++ coding style via clang-format
* Kernel fixes
- Add puppet for `power_spectral_density` kernel
- Treat the `mod_range` puppet as a puppet for correct use with
`volk_profile`
- Fix `index_max` kernels
- Fix `rotator`. We hope that we finally found the root cause of the
issue.
* Kernel optimizations
- Updated log10 calcs to use faster log2 approach
- Optimize `complexmultiplyconjugate`
* New kernels
- accurate exp kernel is finally merged after years
- Add 32f_s32f_add_32f kernel to perform vector + scalar float operation

### Contributors

* Bernhard M. Wiedemann 
* Clayton Smith 
* Johannes Demel  
* Michael Dickens 
* Tom Rondeau 
* Vasil Velichkov 
* ghostop14 

### Changes

* Reproducible builds
- Drop compile-time CPU detection
- Drop another instance of compile-time CPU detection
* CI updates
- ci: Add Github CI Action
- ci: Remove Ubuntu 16.04 GCC5 test on TravisCI
- TravisCI: Update CI to bionic distro
- TravisCI: Add GCC 8 test
- TravisCI: Structure CI file
- TravisCI: Clean-up .travis.yml
* Enforce C/C++ coding style
- clang-format: Apply clang-format
- clang-format: Update PR with GitHub Action
- clang-format: Rebase onto current master
* Fix compiler warnings
- shadow: rebase kernel fixes
- shadow: rebase volk_profile fix
* CMake
- cmake: Remove the ORC from the VOLK public link interface
- versioning: Remove .Maint from libvolk version
- Fix endif macro name in comment
* Kernels
- volk: accurate exp kernel
- exp: Rename SSE4.1 to SSE2 kernel
- Add 32f_s32f_add_32f kernel
- This kernel adds in vector + scalar functionality
- Fix the broken index max kernels
- Treat the mod_range puppet as such
- Add puppet for power spectral density kernel
- Updated log10 calcs to use faster log2 approach
- fix: Use unaligned load
- divide: Optimize complexmultiplyconjugate

Re: porting OOT to gr3.8 Make failure

[Johannes Demel]

Hi Tom,

ORC is a Tool that is used in VOLK to optimize some kernels. Though, 
this is an optional dependency. ORC kernels are not built if liborc etc 
is not found.


I assume you can run example flowgraphs in GRC.
In this case, you shouldn't need to worry about ORC at all. Though, 
somehow you try to link against it. Maybe it's worth a try to figure out 
how ORC ends up in your `target_link_libraries`?


I know, you fixed your issue by installing liborc*-dev but this should 
not be necessary.


Cheers
Johannes


On 30.04.20 09:37, Tom McDermott wrote:

Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
It is suggested by the make failure for the ported OOT module.

Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
and make completed successfully.  Thanks for the suggestion Vasil.
Perhaps it's a dependency that is missing when installing grc on 20.04?

With that, gr-hpsdr installed successfully on gr3.8, and the module 
instantiates

in the flowgraph.  Now to start testing to see if it works...

-- Tom, N5EG






On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller > wrote:


Hi Tom,

nice hearing from you! I didn't know that hpsdr needed orc?

Best regards,
Marcus

On 29.04.20 22:46, Tom McDermott wrote:
 > I am porting an OOT from 3.7 to 3.8.
 > Ubuntu 20.04.  Gnuradio installed via apt install from the
 > gnuradio-releases PPA.  GR 3.8.1
 >
 > It looks like all the modules are compiling OK, but am getting an
error.
 >
 > scanning dependencies of target gnuradio-hpsdr
 > [ 12%] Building CXX object
 > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
 > [ 25%] Building CXX object
 > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
 > [ 37%] Building CXX object
lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
 > [ 50%] Building CXX object
 > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
 > [ 62%] Building CXX object
 > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
 > make[2]: *** No rule to make target
 > '/usr/lib/x86_64-linux-gnu/liborc-0.4.so 
', needed
 > by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
 > make[1]: *** [CMakeFiles/Makefile2:248:
 > lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
 > make: *** [Makefile:141: all] Error 2
 >
 >
 > Not sure what liborc is.   Is this what's missing, or is it
something else?
 > liborc-dev is listed as having no installation candidate for 20.04
 >
 > $ apt-cache policy liborc-dev
 > liborc-dev:
 >   Installed: (none)
 >   Candidate: (none)
 >   Version table:
 >
 >
 >
 > -- Tom, N5EG
 >
 >

Re: R: Gnuradio 3.7

[Johannes Demel]

Hi Vincenzo,

please reply on list. Every mail client is configurable to make this 
task easier for you. I recommend you search for the correct settings for 
your client.


Regarding use of GR 3.7. I suggest you ask yourself the following questions:

- Did you use GNU Radio before? No? -> use GR 3.8
- Are you willing to fight your way through with old software and old 
dependencies?


If you'd come to the conclusion that you really need a Linux distro with 
Python2 support, I'd recommend you choose one with long term support. 
e.g. Ubuntu 18.04LTS. Ubuntu 19.10 will drop out of support around July. 
At that point you shouldn't use this system at all.


Using older systems is really something you should only ever consider if 
you know the pros and cons on a technical level. Otherwise you lack all 
the newer features and improvements while it always becomes harder to 
find support and help.
I assume most developers that can help you with any project are really 
eager to use the latest versions of distros, compilers etc. because they 
want to use the latest features. To most of them legacy support is no 
fun. That's another great argument in favor of using the latest GNU 
Radio version as well.


Cheers
Johannes


On 27.04.20 12:53, Vincenzo Mone wrote:

Hello Johannes,
thanks for your reply.
I have also the 19.10 version.
Can I use this one or you definitely suggest me to find the 18.04 one?
Then how to get the Gnuradio 3.7?
Thanks

73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




   *
   **   GSM  +39 328 7110193  **
   * SMS  +39 328 7110193    *
   *


-Messaggio originale-
Da: Discuss-gnuradio 
Per conto di Johannes Demel
Inviato: lunedì 27 aprile 2020 09:45
A: discuss-gnuradio@gnu.org
Oggetto: Re: Gnuradio 3.7

Hi Vincenzo,

one major change in Ubuntu 20.04 is: Python 2 is removed. "Long live

Python

3+!" [0] Theoretically you could re-enable it but this is discouraged.

One major change for GNU Radio 3.8 is Python 3 support for exactly this
reason. Python2 is dead effective 2020-01-01. We had 10 years to port
everything from 2 to 3.
Also, Qt will probably be tricky too but that's just a guess.

So, if you want to (or have to) use GNU Radio 3.7, stick with Ubuntu

18.04.

This would be the reasonable approach. If you'd want to use an OOT module
that was not ported to 3.8, now might be a good time to port it.

Cheers
Johannes


[0]
https://pythoninsider.blogspot.com/2020/04/python-2718-last-release-of-
python-2.html

On 26.04.20 15:25, Vincenzo Mone wrote:

Please I own the UBUNTU 20.04 LTS.

I do not want to use the latest 3.8 Gnuradio-Companion but

I would like to install the 3.7 version.

Please anybody can point me step by step how to do?

Thanks

73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




    *

**   GSM  +39 328 7110193  **

    * SMS  +39 328 7110193    *

    *

Re: Gnuradio 3.7

[Johannes Demel]

Hi Vincenzo,

one major change in Ubuntu 20.04 is: Python 2 is removed. "Long live 
Python 3+!" [0] Theoretically you could re-enable it but this is 
discouraged.


One major change for GNU Radio 3.8 is Python 3 support for exactly this 
reason. Python2 is dead effective 2020-01-01. We had 10 years to port 
everything from 2 to 3.

Also, Qt will probably be tricky too but that's just a guess.

So, if you want to (or have to) use GNU Radio 3.7, stick with Ubuntu 
18.04. This would be the reasonable approach. If you'd want to use an 
OOT module that was not ported to 3.8, now might be a good time to port it.


Cheers
Johannes


[0] 
https://pythoninsider.blogspot.com/2020/04/python-2718-last-release-of-python-2.html


On 26.04.20 15:25, Vincenzo Mone wrote:

Please I own the UBUNTU 20.04 LTS.

I do not want to use the latest 3.8 Gnuradio-Companion but

I would like to install the 3.7 version.

Please anybody can point me step by step how to do?

Thanks

73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




   *

**   GSM  +39 328 7110193  **

   * SMS  +39 328 7110193    *

   *

New OOT module gr-latency

[Johannes Demel]

Hi everyone,

I'd like to share a new module `gr-latency` that I created and use[0].

Sometimes it would be great to be able to measure latency in a 
flowgraph. With this module this should be easier. I have questions in 
mind like:


* Which blocks delay processing?
* How long does it take a packet to propagate through the DSP chain?

This module is inspired by [1]
"latency: Tag samples or messages with timestamps and measure how long 
it takes to propagate them through the flowgraph."


Cheers
Johannes

[0] https://github.com/ant-uni-bremen/gr-latency
[1] https://github.com/bastibl/gr-sched#metrics

Re: gr-fosphor on AMD RX 550

[Johannes Demel]

Hi Sylvain,

It tried the GLFW version but the error is the same, the shaders fail.

How did you manage to install OpenCL + amdgpu? I tried that and thought 
I had succeeded but apparently that's not the case.


Cheers

PS: Yeah, taking it off the list was an error.


On 26.02.20 13:39, Sylvain Munaut wrote:

Hi Johannes,



I really hoped I could install AMD OpenCL on top of the open driver.
How do you do that? I guess, if I install the correct OpenCL + amdgpu version, 
this should actually work.


Yeah, that's what I did ... I use the AMD binary OpenCL stuff, but I
continued using the amdgpu driver.



It works and look fine. This is part of the output.


Oh, so that's interesting. That means the issue is somewhere in the
way the OpenGL context is setup by Qt, that's really strange.
Can you try the GLFW version of the fosphor GR block ?



If I do `./main` without an argument, a window is opened and unresponsive.


Yeah, that's expected, it's reading  sample data from stdin in that mode.


Cheers,

 Sylvain


PS: I re-cc'd the mailing list since taking it off seemed like an error ...

AW: gr-fosphor on AMD RX 550

[Johannes Demel]

Hi Sylvain,

I attached the output of glxinfo and ran glmark2. The output is attached 
in this mail. I'm glad that this is supposed to run on my machine.
Currently, I'm stuck with a 5.0 kernel because the system won't boot 
with newer kernels due to some MCS checks. I'm confident this is fixed 
in kernel 5.5 and thus I'll migrate to Ubuntu 20.04 as soon as it's 
available. I hope that'll make it easier as well.


Cheers
Johannes


Von: Sylvain Munaut <246...@gmail.com>
Gesendet: Montag, 24. Februar 2020 23:47
An: Johannes Demel
Cc: discuss-gnuradio@gnu.org
Betreff: Re: gr-fosphor on AMD RX 550

Hi Johannes,

First off the RX550 should work just fine. I have a RX570 and run
fosphor on it with no issues.
I am using Ubuntu 19.10 though which is much newer kernel and newer Mesa.

The OpenCL procedure looks fine and if it gets to that point, that
also worked fine. For some reason the shader fail ... but it's
supposed to print the error message which it's obviously not doing :/

Can you provide the full output of glxinfo and also try some open gl
application / benchmark (like glmark) see if they run fine ?

Cheers,

 Sylvain



$ glmark2
===
glmark2 2014.03+git20150611.fa71af2d
===
OpenGL Information
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER:   Radeon RX 550 Series
GL_VERSION:4.6.13581 Compatibility Profile Context 19.50
===
[build] use-vbo=false: FPS: 4433 FrameTime: 0.226 ms
[build] use-vbo=true: FPS: 7157 FrameTime: 0.140 ms
[texture] texture-filter=nearest: FPS: 6887 FrameTime: 0.145 ms
[texture] texture-filter=linear: FPS: 6761 FrameTime: 0.148 ms
[texture] texture-filter=mipmap: FPS: 6860 FrameTime: 0.146 ms
[shading] shading=gouraud: FPS: 6629 FrameTime: 0.151 ms
[shading] shading=blinn-phong-inf: FPS: 6572 FrameTime: 0.152 ms
[shading] shading=phong: FPS: 6373 FrameTime: 0.157 ms
[shading] shading=cel: FPS: 6317 FrameTime: 0.158 ms
[bump] bump-render=high-poly: FPS: 4981 FrameTime: 0.201 ms
[bump] bump-render=normals: FPS: 7201 FrameTime: 0.139 ms
[bump] bump-render=height: FPS: 7020 FrameTime: 0.142 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 6108 FrameTime: 0.164 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 3650 FrameTime: 
0.274 ms

[pulsar] light=false:quads=5:texture=false: FPS: 6707 FrameTime: 0.149 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: 
FPS: 2857 FrameTime: 0.350 ms

[desktop] effect=shadow:windows=4: FPS: 5108 FrameTime: 0.196 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 1094 FrameTime: 0.914 ms
[buffer] 
columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: 
FPS: 2714 FrameTime: 0.368 ms
[buffer] 
columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: 
FPS: 1320 FrameTime: 0.758 ms

[ideas] speed=duration: FPS: 5700 FrameTime: 0.175 ms
[jellyfish] : FPS: 5068 FrameTime: 0.197 ms
[terrain] : FPS: 569 FrameTime: 1.757 ms
[shadow] : FPS: 5056 FrameTime: 0.198 ms
[refract] : FPS: 1280 FrameTime: 0.781 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 7313 FrameTime: 
0.137 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 7263 FrameTime: 
0.138 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 7299 FrameTime: 
0.137 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 7295 
FrameTime: 0.137 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 7299 
FrameTime: 0.137 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 7260 
FrameTime: 0.138 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 7266 
FrameTime: 0.138 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 7244 
FrameTime: 0.138 ms

===
  glmark2 Score: 5535 
===



name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: AMD
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: AMD
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_p

[VOLK] Release v2.2.1

[Johannes Demel]

Hi everyone,

with VOLK 2.2.0, we introduced another AVX rotator bug which is fixed
with this release.
In the process 2 more bugs were identified and fixed. Further, we saw
some documentation improvements.


### Contributors

*  Clayton Smith 
*  Michael Dickens 


### Changes


* Fix loop bound in AVX rotator
* Fix out-of-bounds read in AVX2 square dist kernel
* Fix length checks in AVX2 index max kernels
* includes: rearrange attributes to simplify macros Whitespace
* kernels: fix usage in header comments

gr-fosphor on AMD RX 550

[Johannes Demel]

Hi all,

We have some new AMD machines with RX 550 graphics. I want to run 
gr-fosphor on them. So far I've failed to make it work.


It's an AMD system with RX 550 and Ubuntu 18.04 with amdgpu open source 
drivers. I work with GR 3.8-master (or 3.9.0.0-git) 
`4f53ac5a76e3ab05960a81905a570cd74d2708d7`


Since it was quite tricky for me to install OpenCL and make gr-fosphor 
find it, I just document my workflow really quick.


I found this website:
https://einsteinathome.org/content/quick-guide-how-install-opencl-amd-gpus-linux-kubuntu-1804-and-similar-distro

First, I went to amd.com and got the drivers for my GPU:
https://www.amd.com/en/support/graphics/radeon-500-series/radeon-rx-500-series/radeon-rx-550

Then I ran:
./amdgpu-pro-install --opencl=legacy,pal
This does only install OpenCL

Further, I had to install these packages on Ubuntu:
libfreetype6-dev
ocl-icd-opencl-dev
libglfw3-dev

Also, `clinfo` was useful because it gives you some info about your system.

So finally, I could compile and install `gr-fosphor`. It appears in GRC 
and I can plug the block (Qt version) in a flowgraph.


But if I run this flowgraph, I get the following error:
```
[!] gl_cmap shader compilation failed (cmap_simple.glsl)
[w] Color map shader 'simple' failed to load, will use fallback
[!] gl_cmap shader compile log :

[!] gl_cmap shader compilation failed (cmap_bicubic.glsl)
[w] Color map shader 'bicubic' failed to load, will use fallback
[!] gl_cmap shader compile log :

[!] gl_cmap shader compilation failed (cmap_fallback.glsl)
[!] Color map shader 'fallback' failed, aborting
gr::log :ERROR: qt_sink_c0 - Failed to initialize fosphor
```

I have no idea why and so far googling brought me to some macports 
threads that were related to Intel GPUs on MacOS.


Did someone already succeed with gr-fosphor on this hardware? Do I have 
suitable hardware? Did I fail the installation process somewhere? Do I 
need to provide additional info?


Cheers
Johannes

[VOLK] Release v2.2.0

[Johannes Demel]

Hi everyone,

we have a new VOLK release v2.2.0!

We want to thank all contributors. This release wouldn't have been
possible without them.

We're curious about VOLK users. Especially we'd like to learn about VOLK
users who use VOLK outside GNU Radio.

If you have ideas for VOLK enhancements, let us know. Start with an
issue to discuss your idea. We'll be happy to see new features get
merged into VOLK.

The v2.1.0 release was rather large because we had a lot of backlog. We
aim for more incremental releases in order to get new features out there.

### Highlights

VOLK v2.2.0 updates our build tools and adds support functionality to
make it easier to use VOLK in your projects.

* Dropped Python 2 build support
- Removed Python six module dependency
* Use C11 aligned_alloc whenever possible
- MacOS `posix_memalign` fall-back
- MSVC `_aligned_malloc` fall-back
* Add VOLK version in `volk_version.h` (included in `volk.h`)
* Improved CMake code
* Improved code with lots of refactoring and performance tweaks

### Contributors

*  Carles Fernandez 
*  Gwenhael Goavec-Merou 
*  Albin Stigo 
*  Johannes Demel  
*  Michael Dickens 
*  Valerii Zapodovnikov 
*  Vasil Velichkov 
*  ghostop14 
*  rear1019 

### Changes

* CMake
- Fix detection of AVX and NEON
- Fix for macOS
- lib/CMakeLists: use __asm__ instead of asm for ARM tests
- lib/CMakeLists: fix detection when compiler support NEON but nor
neonv7 nor neonv8
- lib/CMakeLists.txt: use __VOLK_ASM instead of __asm__
- lib/CMakeLists.txt: let VOLK choose preferred neon version when
both are supported
- lib/CMakeLists.txt: simplify neon test support. Unset neon version
if not supported
- For attribute, change from clang to "clang but not MSC"
* Readme
- logo: Add logo at top of README.md
* Build dependencies
- python: Drop Python2 support
- python: Reduce six usage
- python: Move to Python3 syntax and modules
- six: Remove build dependency on python six
* Allocation
- alloc: Use C11 aligned_alloc
- alloc: Implement fall backs for C11 aligned_alloc
- alloc: Fix for incomplete MSVC standard compliance
- alloc: update to reflect alloc changes
* Library usage
- Fixup VolkConfigVersion
- add volk_version.h
* Refactoring
- qa_utils.cc: fix always false expression
- volk_prefs.c: check null realloc and use temporary pointer
- volk_profile.cc: double assignment and return 0
- volk_32f_x2_pow_32f.h: do not need to _mm256_setzero_ps()
- volk_8u_conv_k7_r2puppet_8u.h: d_polys[i] is positive
- kernels: change one iteration for's to if's
- kernels: get rid of some assignments
- qa_utils.cc: actually throw something
- qa_utils.cc: fix always true code
- rotator: Refactor AVX kernels
- rotator: Remove unnecessary variable
- kernel: Refactor square_dist_scalar_mult
- square_dist_scalar_mult: Speed-Up AVX, Add unaligned
- square_dist_scalar_mult: refactor AVX2 kernel
- kernel: create AVX2 meta intrinsics
* CI
- appveyor: Test with python 3.4 and 3.8
- appveyor: Add job names
- appveyor: Make ctest more verbose
* Performance
- Improve performance of generic kernels with complex multiply
- square_dist_scalar_mult: Add SSE version
- Adds NEON versions of cos, sin and tan

[VOLK] Release v2.1.0

[Johannes Demel]

Hi everyone,

we just released VOLK v2.1.0!

we would like to announce that Michael Dickens and Johannes Demel are
the new VOLK maintainers. We want to review and merge PRs in a timely
manner as well as commenting on issues in order to resolve them.

We want to thank all contributors. This release wouldn't have been
possible without them.

We're curious about VOLK users. Especially we'd like to learn about VOLK
users who use VOLK outside GNU Radio.

If you have ideas for VOLK enhancements, let us know. Start with an
issue to discuss your idea. We'll be happy to see new features get
merged into VOLK.

## Highlights

VOLK v2.1.0 is a collection of really cool changes. We'd like to
highlight some of them.

- The AVX FMA rotator bug is fixed
- VOLK offers `volk::vector<>` for C++ to follow RAII
- Move towards modern dependencies
- CMake 3.8
- Prefer Python3
- We will drop Python2 support in a future release!
- Use C++17 `std::filesystem`
- This enables VOLK to be built without Boost if available!
- more stable CI
- lots of bugfixes
- more optimized kernels, especially more NEON versions

## Contributors

*  Albin Stigo 
*  Amr Bekhit 
*  Andrej Rode 
*  Carles Fernandez 
*  Christoph Mayer 
*  Clayton Smith 
*  Damian Miralles 
*  Johannes Demel  
*  Marcus Müller 
*  Michael Dickens 
*  Philip Balister 
*  Takehiro Sekine 
*  Vasil Velichkov 
*  luz.paz 


## Changes

* Usage
- Update README to reflect how to build on Raspberry Pi and the
importance of running volk_profile

* Toolchain
-  Add toolchain file for Raspberry Pi 3
-  Update Raspberry 4 toolchain file

* Kernels
- Add neonv7 to volk_16ic_magnitude_16i
- Add neonv7 to volk_32fc_index_max_32u
- Add neonv7 to volk_32fc_s32f_power_spectrum_32f
- Add NEONv8 to volk_32f_64f_add_64f
- Add Neonv8 to volk_32fc_deinterleave_64f_x2
- Add volk_32fc_x2_s32fc_multiply_conjugate_add_32fc
- Add NEONv8 to volk_32fc_convert_16ic

* CI
- Fix AVX FMA rotator
- appveyor: Enable testing on windows
- Fixes for flaky kernels for more reliable CI
- volk_32f_log2_32f
- volk_32f_x3_sum_of_poly_32f
- volk_32f_index_max_{16,32}u
- volk_32f_8u_polarbutterflypuppet_32f
- volk_8u_conv_k7_r2puppet_8u
- volk_32fc_convert_16ic
- volk_32fc_s32f_magnitude_16i
- volk_32f_s32f_convert_{8,16,32}i
- volk_16ic_magnitude_16i
- volk_32f_64f_add_64f
- Use Intel SDE to test all kernels
- TravisCI
- Add native tests on arm64
- Add native tests on s390x and ppc64le (allow failure)

* Build
- Build Volk without Boost if C++17 std::filesystem or
std::experimental::filesystem is available
- Update to more modern CMake
- Prevent CMake to choose previously installed VOLK headers
- CMake
- bump minimum version to 3.8
- Use sha256 instead of md5 for unique target name hash
- Python: Prefer Python3 over Python2 if available

* C++
- VOLK C++ allocator and C++11 std::vector type alias added

Re: [Discuss-gnuradio] cannot find block tree panel in grc

[Johannes Demel]

Hi,

I kind of had this experience a few days ago. Basically the block tree 
panel was just minimized to the right. i.e. the width was 0 and a mouse 
over and click fixed it. I hope this helps. It seems so obvious but it 
wasn't.

Cheers
Johannes

On 07.11.19 22:16, Achilleas Anastasopoulos wrote:
> 
> Have you fixed this issue?
> I got the same thing in Ubuntu 18.04 since yesterday and cannot figure 
> out what happened...
> 
> Achilleas

Re: Subject Line Prefix Missing

[Johannes Demel]

Hi all,

I was wondering about that mailing list behavior as well.

My solution
1. If "Mail From 'discuss-gnuradio@gnu.org'"
2. If "Mail To 'discuss-gnuradio@gnu.org'"
In my case: move to folder.
1. covers original mails
2. covers replies.

I had to split this into 2 separate rules but that's due to my email 
service provider.
This solution is more verbose about who receives such an email. e.g. 
off-list replies should not end up to be caught by these rules.

Anyways, I just wanted to share my 2 cents on that. Maybe someone finds 
this info useful.

Cheers
Johannes



On 30.10.19 15:11, Müller, Marcus (CEL) wrote:
> Hi Ed,
> 
> "deliberate" would be wrong. Surprising, not really, if we'd have read
> the info mails from the gnu.org mailing list admin more carefully:
> 
> In the process of respecting DMARC in the ML infrastructure, they
> disabled rewriting of the subject line for outgoing mail servers that
> signal strict DMARC compliance. The mailing list seems to think your
> server does (I don't know why, to be honest, can't seem to find those
> DNS entries).
> 
> So, for now, my understanding is that there's nothing *we* can do about
> it. (We should be able to change the settings of the ML; but in which
> range, and what we'd break on the way, isn't quite clear to us at this
> point.)
> 
> For some reason, my university mail server seems to sort these mails
> correctly, and so do GMail instances. Probably a list header?
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-10-30 at 09:17 -0400, Ed Criscuolo wrote:
>> I've noticed that recent postings to the list are missing
>> the "[Discuss-gnuradio] prefix that was automatically
>> added to the subject line.
>>
>> Was this  a deliberate change? I hope not, as I find that
>> feature very useful in picking out the list messages
>> from amid all the spam.
>>
>>
>> @(^.^)@  Ed
>>

Re: [Discuss-gnuradio] XFDMSync and gr-gfdm

[Johannes Demel]

Hi Satish,

I didn't receive your mail through the mailing list. I wonder if anyone 
else did? Anyways, I just post my answer to the mailing list so others 
may benefit as well.

First off, there is a `convert38` branch in both repos that enables you 
to use `gr-gfdm` and `XFDMSync` with GNU Radio 3.8. These branches got 
some additional bugfixes and some clean-up. I'd just recommend to use 
these branches now.

I just pushed a new commit to the repo with an updated flowgraph. Of 
course everything is on `convert38` and thus you need to use it with GNU 
Radio 3.8.

It is always useful to have some form of CRC check. Usually you'd use 
some FEC as well. Though, this is left out in the example flowgraph.

Cheers
Johannes

On 22.09.19 17:26, Satish Kolli wrote:
> Mr.Demel,
> 
> I hope you are doing great. I sent the following to the 
> 'discuss-gnuradio' per your direction last time and just want to bring 
> it to your attention, if you can help. Thank you very much.
> 
> Satish
> 
> 
> *From:* Satish Kolli
> *Sent:* Sunday, September 22, 2019 11:21 AM
> *To:* discuss-gnuradio@gnu.org 
> *Subject:* XFDMSync and gr-gfdm
> Hello,
> 
> I am using XFDMSync and gr-gfdm from the following github.
> 
> https://github.com/jdemel/XFDMSync
> https://github.com/jdemel/gr-gfdm
> 
> I am generating a fixed byte message (ex: "AA|timestamp") and 
> sending it through USRP (tried with N200 and X310). I am able to 
> successfully transmit and receive but the messages on the receiver end 
> are interleaved (meaning some message don't start exactly with my  
> prefix, part of previous message and part of next message gets written 
> to my Sync). I noticed that the first few messages are always printed as 
> garbled characters at my Sync.
> 
> I augmented gfdm_ota_demo.grc 
>  
> (https://github.com/jdemel/gr-gfdm/blob/master/examples/gfdm_ota_demo.grc) 
> with 
> my source that generates the messages and added a sync to capture the 
> messages.
> 
> Any insight/help is greatly appreciated. Thank you.
> 
> Satish
> 
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ffast-math

[Johannes Demel]

Hi Albin,

one of my students reported a little oddity about `-ffast-math`. Assume 
you want to set a float to -0, i.e. set the sign bit only. In this case 
`-ffast-math` seems to remove the sign bit.

In VOLK this might be an issue with `_mm256_conjugate_ps` in 
`include/volk/volk_avx_intrinsics.h`. I didn't check for other potential 
error sources.

Cheers
Johannes

Am 01.09.19 um 16:10 schrieb Albin Stigö:
> Anyone has experience with the real world impact of using gcc 
> -ffast-math with SDR in general, and GNURadio/Volk in particular?
> 
> 
> --Albin SM6WJM
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[Johannes Demel]

Hi Sumit,

this is not an installation error. Your configuration is wrong. The 
argument `enb` must be of type bool but it is a string in your case.
I assume you use GRC to generate this flowgraph.
Open your USRP source block. Go to the `FE Corrections` tab and put in 
`False` in both fields. No `, ' or ". This will generate a line that says:
`self.uhd_usrp_source_0.set_auto_dc_offset(False, 0)`
instead of
`self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)`.
This should fix your issue.

Cheers
Johannes

Am 24.07.19 um 19:33 schrieb Sumit Kumar:
> Hi Michael,
> Any update on this? I downgraded my install of uhd and gnuradio as 
> follows but I have the same error.
> 
> Traceback (most recent call last):
>    File "/home/sumit/Desktop/top_block.py", line 122, in 
>      main()
>    File "/home/sumit/Desktop/top_block.py", line 110, in main
>      tb = top_block_cls()
>    File "/home/sumit/Desktop/top_block.py", line 78, in __init__
>      self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)
>    File 
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", 
> line 3499, in set_auto_dc_offset
>      return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 
> of type 'bool'
> 
> sumit@PP0380:~/gradio/src/gnuradio$ uhd_find_devices
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
> *UHD_3.14.1.HEAD-0-g5491b80e*
> --
> -- UHD Device 0
> --
> Device Address:
>      serial: 317DD1E
>      addr: 192.168.10.2
>      fpga: HG
>      name:
>      product: X310
>      type: x300
> 
> 
> sumit@PP0380:~/gradio/src/gnuradio$ gnuradio-companion --version
> *GNU Radio Companion 3.7.13.5
> *
> This program is part of GNU Radio
> GRC comes with ABSOLUTELY NO WARRANTY.
> This is free software, and you are welcome to redistribute it.
> 
> sumit@PP0380:~/gradio/src/gnuradio$ git status
> On branch maint-3.7
> *Your branch is up to date with 'origin/maint-3.7'.*
> *
> *
> Regards
> Sumit
> 
> On Thu, Jun 27, 2019 at 8:07 PM Michael Dickens 
> mailto:michael.dick...@ettus.com>> wrote:
> 
> __
> I guess for your need so long as it works that's what matters, yes?
> 
> We'll work on fixing the issue you found anyway ... seems like it's
> legit & undesirable LOL.
> 
> Good luck with your demo! - MLD
> 
> On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
>> Well it worked after compiling old checkouts (but not giving me
>> the usual satisfaction of a fresh install... but anyways)
>>
>> On Thu, 27 Jun 2019 at 19:45, sumit kumar > > wrote:
>>
>> Its overwhelming :D, I have a demo on Monday and I was 100%
>> assured gr-ieee-80211 will work as usual.
>>
>> Before I saw your mail, I already checked out GR to 3.7.12,
>> UHD to 003 009 006 and compiling now.
>> Yes I used pybombs for installation.
>>
>> I have a USB with gnuradio installed into it. It works good
>> and it has GR 3.7.11, uhd 003 009 006 and gr-ieee-80211
>> version I dint check.
> 
> 
> 
> -- 
> -- 
> Sumit kumar
> Postdoc
> SnT, Luxembourg
> 
> 
> 
> ___
> 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] [job posting] Looking for Researchers for 5G SDR work @ANT/Uni Bremen

[Johannes Demel]

Hi all,

I'd like to let you know that we have open positions for SDR-related 
work at our department [0]. The goal would be to eventually graduate as 
a PhD (Dr.-Ing.).
The research focus will be on 5G baseband signal processing and SDR 
implementations.

Applications should go directly to our head, Prof. Dr.-Ing. Armin 
Dekorsy 

Cheers
Johannes


[0] 
https://www.uni-bremen.de/de/universitaet/die-uni-als-arbeitgeber/offene-stellen/detailansicht/joblist/Job/show/div-wissenschaftliche-mitarbeiterinnen-wmd-5832/

PS: This is my second try to post this email on the mailing list. I did 
not receive a copy of my first try.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC2019]: First report from Bowen

[Johannes Demel]

Hi Bowen,

it's great that you start to work on your project right away. Since you 
want to implement a new feature for GNU Radio, I'd suggest to use the 
latest GNU Radio version which is the one in the repository. To rephrase 
it, I recommend to use GNU Radio 3.8. Though, I assume you already 
discussed this with your mentors or will do so.
Therefore I suggest to use a source build/install instead of the version 
provided by your distribution.

Cheers
Johannes

Am 12.05.19 um 18:18 schrieb Bowen Hu:
> Hi all,
> 
> I am happy to be accepted by GSoC 2019 working on cycle-accurate 
> simulation of Verilog. Here 
>  
> (https://b0wen-hu.github.io/2019/05/12/First-report/) 
> is my first report.
> 
> 
> ## Progress this week
> I have set up the working environment and read some tutorials for GNU 
> Radio development in the last few days.
> 
> My current working environment is Ubuntu 18.04 LTS installed GNU Radio 
> version 3.7.11 by apt, but I am considering switch to newest Ubuntu 
> 19.04 which shipped with GNU Radio version 3.7.13 by apt.
> 
> I am following the tutorial and created my first module gr-howto (This 
> may not be a good name, so I will change the module name in the coming 
> week). I will continue to read tutorials, hopefully I could finish them 
> (from chapter 2 to chapter 7) in the next week.
> 
> I also managed to run the simulation of a simple Verilog module with 
> Verilator, it works as anticipated, you can find it here. This is just a 
> standalone simulation program, in order to let the GNU Radio work with 
> the Verilator-generated file, there are much work to do.
> 
> ## Plan next week
> Finish all the tutorials from chapter 2 to chapter 7.
> 
> Try to make the Verilator related header file available in GNU Radio 
> blocks. A source block like this (flicker.v) would be a good start.
> 
> ## Issue(s)
> The module name gr-howto need to be changed.
> 
> 
> Best regards,
> Bowen
> 
> ___
> 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] Tag propagation policy for tagged stream blocks

[Johannes Demel]

Hey everyone,

I have an issue with how additional tags are handled in 'tagged stream 
blocks'.
E.g. think of a 'FEC Tagged Encoder'. It does handle the length tag but 
what happens to other tags? They are left untouched. This results in a 
situation where a rate change basically makes all other tags disappear 
because these tags will be out of range for all other blocks down the line.
Right now, the options are to not use tags, implement custom blocks that 
exhibit the desired behavior, or implement the desired behavior in the 
GR source. Though, that'll force users to permanently move to a 
different GR source. A situation that is really undesirable.

What I'd like to have is a tag propagation policy that takes all tags in 
range and moves them to the correct output range. Maybe all of them to 
the same position as the length tag. Or a policy that honors the length 
tag position and the rate change for the currently processed samples.
Maybe we could switch between the current and the new tag propagation 
policy.
Since this might be a change that has quite some impact I'd like to 
discuss it and decide later how I'll move forward.

Cheers
Johannes
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [EXT] Re: Need support for USRP2

[Johannes Demel]

Hi Chesir,

I saw similar behavior with very recent X310s with UBX daughterboards. 
It did help to revert to an earlier UHD version [0]. Maybe the issue is 
related. Maybe it is not.

Cheers
Johannes

[0] https://github.com/EttusResearch/uhd/issues/257

Am 02.04.19 um 16:04 schrieb Chesir, Aaron M.:
> Marcus,
> 
> I mis-spoke: I am using a common **receiver** application, and I am 
> comparing the received spectrum when using either the N21 or the USRP2 
> as the transmitter.
> 
> Attached are the screen shots of the parameters of the UHD USRP Sink 
> block, which is common when using either of the two boxes to transmit 
> (other than the IP address).
> 
> Attached also are the results of executing “uhd_usrp_probe” for each of 
> the two boxes.
> 
> I do not understand why I am seeing a healthy spectrum when receiving 
> from the N210 transmitter, but nothing when receiving from the USRP2 
> transmitter.
> 
> Help.
> 
> Thanks,
> 
> Aaron
> 
> *From:*Marcus D. Leech 
> *Sent:* Tuesday, April 2, 2019 9:34 AM
> *To:* Chesir, Aaron M. ; discuss-gnuradio@gnu.org
> *Subject:* Re: [EXT] Re: [Discuss-gnuradio] Need support for USRP2
> 
> On 04/02/2019 09:20 AM, Chesir, Aaron M. wrote:
> 
> When I generate a known good signal in the ISM band (902 MHz), I can
> use any other receiver with GRC and a good spectrum will be
> displayed. When I use the USRP2 with GRC, to receive and
> characterize energy , GRC offers no complaints, but GRC indicates no
> reception of any signal energy.
> 
> What daughtercard do you have installed?  What gain setting are you using?
> 
> 
> 
> *From:*Discuss-gnuradio
> 
>  *On
> Behalf Of *Marcus D. Leech
> *Sent:* Tuesday, April 2, 2019 9:06 AM
> *To:* discuss-gnuradio@gnu.org 
> *Subject:* [EXT] Re: [Discuss-gnuradio] Need support for USRP2
> 
> On 04/02/2019 09:00 AM, Chesir, Aaron M. wrote:
> 
> Folks,
> 
> Apparently the USRP2 is no longer supported by GNUradio Companion.
> 
> Do any of you have the source files that would allow one to use
> gr_modtool to build a GRC block for the USRP2: One to transmit
> and one to receive?
> 
> Thanks,
> 
> Aaron
> 
> That isn't true.  You can even still use USRP1 with Gnu Radio.
> 
> 
> 
> 
> *From:* Discuss-gnuradio
> 
>  *On
> Behalf Of *Neel Pandeya
> *Sent:* Saturday, March 16, 2019 10:37 PM
> *To:* krist...@skypro.be 
> *Cc:* GNURadio Discussion List 
> 
> *Subject:* [EXT] Re: [Discuss-gnuradio] forum to learn more
> about signal-processing and SDR ?
> 
> Hello Kristoff:
> 
> These pages have links to resources that might be helpful to you.
> 
> https://kb.ettus.com/Suggested_Videos
> 
> https://kb.ettus.com/Suggested_Reading
> 
> --Neel Pandeya
> 
> On Sat, 16 Mar 2019 at 21:01, Ali Dormiani
> mailto:sdorm...@eng.ucsd.edu>> wrote:
> 
> This book is also a great starting point and reference.
> 
> Digital Signal Processing by Oppenheim and Schafer
> 
> Also, here is a fun visual way of getting an alternative
> understanding of Fourier transforms.
> 
> https://www.youtube.com/watch?v=spUNpyF58BY
> 
> Have fun,
> 
> Ali
> 
> On Sat, Mar 16, 2019 at 2:24 PM Albin Stigö
> mailto:albin.st...@gmail.com>> wrote:
> 
> This book is a very good starting point:
> 
> http://www.dspguide.com
> 
> dsp.stackexchange.com  is
> a good place for questions.
> 
> Good luck.
> 
> Albin SM6WJM
> 
> On Sat, Mar 16, 2019, 22:20 Kristoff  > wrote:
> 
> Hi,
> 
> 
> One of the reasons I am currently using GNU Radio is
> to learn more about
> signal-processing and SDR.
> 
> As the "discuss-gnuradio" list is about gnuradio
> itself, what would be a
> good mailing-list, newsgroup or forum to ask more
> generic questions
> about signal-processing?
> 
> 
> 
> 
> Kristoff (ON1ARF)
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

Re: [Discuss-gnuradio] [Announcement] Ctrlport is broken -> potential candidate for removal in 3.8 -> RPC discussion

[Johannes Demel]

Hi Marcus,

it seems like Thrift is a painful dependency. So, this is a pro ctrlport 
removal. Though, what else does ctrlport removal entail?
Is it really only used for monitoring and control?
Just for clarification, the zeromq blocks are not affected?
How will the performance monitor be preserved? I really like to look at 
the statistics to get a first idea where to look for problems and 
analyze my system with it.

Also, in case ctrlport is removed, we should have a GREP to discuss what 
we want and how we want ctrlport back in some other form.

Cheers
Johannes

Am 24.03.19 um 20:26 schrieb Marcus Müller:
> Dear GNU Radio community,
> 
> we've got an outstanding breakage in our controlport infrastructure.
> Since fixing it seems to involve architectural changes to what
> controlport does, and since making these changes would quite possibly
> break the semantics of using controlport anyway, we're considering
> removing Controlport from the GNU Radio 3.8 release (this does NOT
> apply to 3.7).
> 
> The negative effect of that would obviously be that we'd lose
> controlport (which I'm not going to introduce here; if you don't know
> what it is, you haven't been using it). We would *not* lose the
> performance counters, just the default way of querying them.
> 
> The most important upside would be the ability to remove the Apache
> thrift dependency. Thrift has been the single worst thing we've relied
> on for as long as I can remember in terms of availability and
> consistency across platforms. In fact, different distros build
> completely different configurations of thrift, and noone seems to be
> able to build a "fully featured" thrift.
> 
> Another aspect to this is that albeit controlport is pretty cool in
> theory – an adaptable RPC server within GNU Radio, with pluggable RPC
> backends – its adoption has been slow to say the least, and it doesn't
> really tie neatly into any GNU Radio applications I'd be aware of.
> 
> So, lest someone fixes the bug (I'll be describing it below), I'd
> recommend we remove Controlport alltogether, and remove the thrift
> dependency. I still stand by the very idea of controlport – having RPC
> access to what a flow graph does – but in the end, there's a discussion
> that we need to have:
> 
> How do we want to do RPC in a way that enables us to make GNU Radio far
> more machine-agnostic than it is? How does one not only allow for
> gathering of statistics and calling of functions, but build an RPC
> framework that makes heterogeneous and distributed GNU Radio really
> feasible?
> 
> We've been addressing the question of what the scheduler needs to
> become at the heterogeneous compute working group at GRCon'18. To
> conclude, we need to get away from the "one buffer type fits all" and
> "all blocks are born equal and are just individual OS threads" towards
> domain-specific subschedulers and buffer managers. This is where this
> needs to tie in.
> 
> Hence: Is anyone seriously using ControlPort and needs it for 3.8?
> Please raise a metaphorical hand on the mailing list or write a private
> one in response to this email.
> 
> Best regards,
> Marcus
> 
> --
> 
> Bug: clang correctly has been complaining for quite a while now that
> the RPCAggregator stores a reference to a temporary object. It seems
> that in the past this just worked by chance – probably, libc never
> really got around to reassign the memory of these temporary objects and
> all lived happily everafter. However, now on multiple platforms, we
> just see aborts in various tests due to access to freed memory.
> Probably memory protection just got smart enough to kick some sense
> into this code.
> All is fine as long as one doesn't actually use the code in question.
> 
> 
> ___
> 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] GSOC - Introduction and Project Idea Discussion

[Johannes Demel]

Hi Mayank,

I'm glad you're interested in optimized codes.

There are quite a lot of comms standards out there. They all come with 
their standardized codes. Unlike their general definition, standards use 
a small subset of all possible configurations a code might have.
e.g. in general frozen bits in polar codes just need to have fixed 
values. In practice, frozen bits are all set to '0'. This simplifies 
decoders. Also, you could identify possible decoder functions that would 
benefit from specialization. This might be facilitated via templates or 
different implementations. Probably a combination of different 
techniques will be applied.

This project may be approached in 2 different ways. Others may comment 
on these options.
1. Choose a specific standard code and implement it such that encoder 
and decoder exhibit maximum throughput/ minimum latency.
2. Find high performance implementations of standard codes and integrate 
them into the FECAPI. Make sure they seamlessly integrate into FECAPI.
This might encompass discussions on how to integrate these 
implementations. Technical issues might come up but also license issues. 
Also, it would be challenging to add multiple new dependencies to GNU Radio.

In most cases FEC in comms standards include:
- encoder
- decoder
- puncturing
- interleaver

All in all, an information word goes into the encoder and a 'rate 
matched' codewords is emitted. On the decoder side a received vector 
represented as LLRs goes into the decoder and a decoded information word 
goes out.

Clearly, the focus should be on the decoder in terms of performance 
because we expect this component to be the one with the heaviest load.
Though, the other parts of the FEC standard should be implemented as well.

Cheers
Johannes


Am 06.03.19 um 18:52 schrieb Mayank Jhamtani:
> Hello all,
> My name is Mayank, and I am interested to participate in GSoC'19 as a 
> student.
> 
> I would want to work on the project "Standardized High Throughput FEC 
> Codes". This project interests me because I have been studying coding 
> theory for the past two years, and I would love to work on implementing 
> the same. I also have decent experience of coding in C++.
> I am currently familiarizing myself with GNU Radio, and the gr-fec API 
> in particular.
> 
> Also, I would be grateful if someone could clarify the exact expected 
> outcomes of the project idea, or give any other useful pointers, so that 
> I can better orient my efforts.
> 
> Regards,
> -Mayank
> 
> ___
> 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] Ettus E310 & MIMO -- data rate?

[Johannes Demel]

Hi Rob,

Am 26.02.19 um 15:51 schrieb Rob Heig:
> Hi,
> 
> I've bought an Ettus E310 board and I am trying to use it for a MIMO 
> project, but I am encountering several issues.
> 
> In particular, I have created a GNU Radio design, compiled it as Python 
> script (as illustrated on the page 
> https://kb.ettus.com/Streaming_processed_data_from_the_E31x_with_GNU_Radio_and_ZMQ),
>  
> modified it (because it was complaining due to a
> TypeError: push_sink_make() takes at most 5 arguments (6 given)
> error with the ZMQ sink) and scp'd to the board.
> 
> What I've found is
> (1) I cannot set an arbitrary sampling rate (for instance 9.1428M), but 
> I am required to set e.g. 4M.
USRPs, like every hardware, is constraint in terms of available sampling 
rates. You should stick with power of 2 divides of the master clock 
rate. Otherwise, the CIC filters on the USRP will corrupt your signal.

> (2) even with small sampling rates (like 2M), and despite a 10MB buffer 
> in between the USRP source and the ZMQ sink, the system keeps overflowin
> 
> The design I'm using is depicted here: https://ibb.co/GVJxwcm
> 
> - Am I doing anything wrong?
> - What is the sampling rate I am supposed to achieve?
> 
> Thanks a lot in advance!
> Best,
> Rob
> 
> ___
> 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] TDD mode with USRPs in GNU Radio

[Johannes Demel]

Hi Andy,

thanks for your answer and help. That's the pointer I was looking for.

Just for clarification, I' refering to this schematic:
https://files.ettus.com/schematics/ubx/ubx.pdf

The 'SKyWorks SKY13350-385LF' switch is this SPDT component in the TXPA 
block?

I expect a configuration with separate antennas for TX and RX. But since 
isolation between TX and RX chains is limited by the switch, this is the 
component I need to worry about?
Otherwise I'd just separate my TX and RX antennas spatially. But that 
doesn't make sense in my case since the critical component is this 
switch in my case.

I aim at working in the 3.7GHz band. Thus, I assume that my receive 
signal goes through the VMMK-3603 LNA in the RXLNA block in the 
schematic. I wonder how that component right after the RX2 SMA works? I 
assume this is a Skyworks AS236-321LF as shown on page 11 of the schematic.
https://store.skyworksinc.com/Products/Detail/AS236321LF-Skyworks-Solutions-Inc/88944/

Are there in fact 2 switches concatenated? Would it be appropriate to 
just add up their isolation values?

Another thought, would it be possible to configure a USRP in GR such 
that it does continuously receive on TX/RX and then switch for the 
duration of a transmit burst and switch back afterwards? Of course, 
preferably this happens automagically.
This thread [0] suggests that there is some kind of control. But so far, 
I didn't find a definite way to tell if this covers my case with GNU 
Radio. Also, in [1] it sounds like switching is done automagically. 
Though, I wonder if I can just use 'UHD: USRP Sink' and 'Source' or if I 
need to use the Async Sink?

Cheers
Johannes

[0] 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-October/050112.html
[1] 
https://stackoverflow.com/questions/39321262/switching-usrp-from-rx-to-tx-using-gnuradio

Am 25.02.19 um 20:30 schrieb Andy Walls:
> 
>> Date: Mon, 25 Feb 2019 10:29:56 +
>> From: Johannes Demel
>> To: "discuss-gnuradio@gnu.org" 
>> Subject: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio
>>
>> Hi all,
>>
>> I plan to implement a TDD system with GNU Radio and X310s w UBX160s.
>> My
>> lab setup is as follows:
>> - multiple USRPs (start with 2, extend to more)
>> - each USRP shall use 1 TX and one RX port. Preferably on one
>> daughterboard in order to extend it to MIMO later on.
>>
>> At the moment the receiver runs continuously. While TX bursts happen
>> occasionally. I'd like to turn up TX power as much as possible. But
>> I'm
>> concerned that this will damage the RX frontend. Especially if the
>> RX
>> gain is set to some high value too. Should I be concerned about that?
> 
> Yes.
> 
> https://kb.ettus.com/UBX
> 
> "TX Power (Max)
> 
>   10 MHz - 3 GHz: 20 dBm
>   3 - 6 GHz: 8 - 20 dBm"
> 
> "Input Power Levels
> 
> The maximum input power for the UBX is -15 dBm."
> 
> 
> The TX chain is isolated from the Rx chain by a SKyWorks SKY13350-385LF
> switch.
> https://files.ettus.com/schematics/ubx/ubx.pdf
> http://www.skyworksinc.com/Product/712/SKY13350-385LF
> 
> which claims typical isolation of 25 dB at 3 GHz on the webpage, but
> the datasheet indicates 20 dB is actually typical and 17 dB is minimum.
> UBX-160 board design, if not done right, can degrade that.
> 
> 17 dB of isolation is does not cover the 35 dB difference between max
> TX power and max Rx input power.
> 
> 
>> Or
>> does the USRP take care of that automatically? e.g. turn down RX
>> gain
>> during transmission?
> 
> I don't think so.
> 
> 
>> Even if a transmission is received at the same receiver, I'd expect
>> my
>> RX DSP chain to just demodulate that burst and later on this packet
>> would be discarded.
> 
> That's my experience with WBX-120 boards installed in a working
> system: the radio can hear itself.
> 
> 
>>   Also, I'd envision a block that 'blanks' my RX
>> samples whenever TX is expected.
> 
> It's easy enough to throw away these packets at the MAC layer.
> Receiving them is also a rudimentary check for a continuous built in
> test to detect if the transmitter has completely failed.
> 
> 
>> All in all the questions are:
>> - do I need to implement some logic in GR to turn down RX gain (or
>> shut
>> off RX) during a TX burst?
> 
> Given the numbers above, I would think you need to keep the gain down.
> 
> 
>> - does UHD take care of that?
> 
> I don't think so.
> 
> 
>> - If I need to take care of that, how did you guys handle that
>> problem?
> 
> Don't run the RX chain at full gain.
> 
> Put an LNA and limiter out in front of the USRP's Rx port.
> 
> And if you're using one antenna for both Tx and Rx, on the TX/RX and
> RX2 ports respectively, you'll need a PIN diode RF T/R switch out in
> front of the USRP as well.
> 
> Regards,
> Andy
> 
>> Cheers
>> Johannes
>>
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] TDD mode with USRPs in GNU Radio

[Johannes Demel]

Hi all,

I plan to implement a TDD system with GNU Radio and X310s w UBX160s. My 
lab setup is as follows:
- multiple USRPs (start with 2, extend to more)
- each USRP shall use 1 TX and one RX port. Preferably on one 
daughterboard in order to extend it to MIMO later on.

At the moment the receiver runs continuously. While TX bursts happen 
occasionally. I'd like to turn up TX power as much as possible. But I'm 
concerned that this will damage the RX frontend. Especially if the RX 
gain is set to some high value too. Should I be concerned about that? Or 
does the USRP take care of that automatically? e.g. turn down RX gain 
during transmission?
Even if a transmission is received at the same receiver, I'd expect my 
RX DSP chain to just demodulate that burst and later on this packet 
would be discarded. Also, I'd envision a block that 'blanks' my RX 
samples whenever TX is expected.

All in all the questions are:
- do I need to implement some logic in GR to turn down RX gain (or shut 
off RX) during a TX burst?
- does UHD take care of that?
- If I need to take care of that, how did you guys handle that problem?

Cheers
Johannes
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio