Re: Tutorial on Hier Block and Parameters
The output is echo $PYTHONPATH :/home/grctut/ the folder where I am saving working grc files. However, I am able to use GRC for other purposes normally. I notice that GRC blocks (.yaml files) are in /usr/share/gnuradio/grc/blocks/ folder. Also there is no .grc_gnuradio file in my home directory. However, there is a .gnuradio folder with a prefs folder and config.conf and grc.conf files. prefs folder has a vmcircbuf_default_factory file. -- > > Message: 3 > Date: Sat, 12 Feb 2022 12:07:37 +0100 > From: Volker Schroer > To: discuss-gnuradio@gnu.org > Subject: Re: Tutorial on Hier Block and Parameters > Message-ID: > Content-Type: text/plain; charset=UTF-8; format=flowed > > Yes, that the generated hier block files go to the working directory of > ~/.grc_gnuradio is a known bug. > > See: > https://github.com/gnuradio/gnuradio/pull/5547 > > What is the result of > > echo $PYTHONPATH > > > -- Volker > > Hi, > > I am facing a problem using the tutorial. My installation is from > > repository. > > I am using GRC3.10.1.1(Python3.8.10) on OS Ubuntu 20.04.3LTS. > > When I generate the flow graph, output files are going to the working > > directory and not .grc_gnuradio as mentioned in tutorial. Probably > > because of this, they are not appearing in the block tree of GRC. Also, > > I get these messages on the terminal. > > Warning: vocoder_codec2_decode_ps - option_attributes are for enums > > only, ignoring > > >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums > > only, ignoring > > May not be relevant, but I observe whenever I open the terminal, the > > following line appears before the command prompt. > > PYTHONPATH: command not found > > Please help me in configuring GRC properly. Or do i have to install > > gnuradio in home directory instead of system installation? > > > > -- > > Best Regards, > > vsrk sarma > -- Best Regards, vsrk sarma
Re: [VOLK] Release 2.5.1
On Sat, 12 Feb 2022 11:40:26 +0100 Johannes Demel wrote: > 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. 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
Re: segfault in 3.10.1.1
Hello patient and helpful folks, hope this day finds you well.
Have had some "success", gui runs appears work fine, not calling the
offending functions g_free and ffi_closure_free in
gobject-introspection-1.70.0/girepository/girffi.c
guessing these are the parameter linkages and walking trail for
circuit path for each block etc.?
no idea where this is even called from, wow there is a lot going on...
**
* g_callable_info_free_closure:
* @callable_info: a callable info from a typelib
* @closure: ffi closure
*
* Frees a ffi_closure returned from g_callable_info_prepare_closure()
*/
void
g_callable_info_free_closure (GICallableInfo *callable_info,
ffi_closure*closure)
{
GIClosureWrapper *wrapper = (GIClosureWrapper *)closure;
//g_free (wrapper->ffi_closure.cif->arg_types);
//ffi_closure_free (wrapper->writable_self);
printf("%s ( [callable_info-> dummy1=%d, dummy2=%d, dummy3=%x, dummy4=%x,
dummy5=%x, dummy6=%d, dummy7=%d,
padding[0]=%x,padding[1]=%x,padding[2]=%x,padding[3]=%x], [closure-> ... ]
)\n",__func__,callable_info->dummy1,callable_info->dummy2,callable_info->dummy3,callable_info->dummy4,callable_info->dummy3,callable_info->dummy6,callable_info->dummy7,callable_info->padding[0],callable_info->padding[1],callable_info->padding[2],callable_info->padding[3]);
}
typedef struct _GIBaseInfoStub {
/* */
gint32 dummy1;
gint32 dummy2;
gpointer dummy3;
gpointer dummy4;
gpointer dummy5;
guint32 dummy6;
guint32 dummy7;
gpointer padding[4];
} GIBaseInfo;
/**
* GICallableInfo:
*
* Represents a callable, either #GIFunctionInfo, #GICallbackInfo or
* #GIVFuncInfo.
*/
5.1# gnuradio-companion --log debug
[DEBUG] Starting GNU Radio Companion (3.10.2) (main.py:70)
[DEBUG] Loading platform (main.py:76)
[DEBUG] Loading application (main.py:86)
[DEBUG] Running (main.py:88)
<<< Welcome to GNU Radio Companion 3.10.1.1 >>>
Block paths:
/usr/share/gnuradio/grc/blocks
Loading: "/UNUSED/testing123.grc"
>>> Done
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=6,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=529188, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=6,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=529188, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
Generating: '/UNUSED/testing123.py'
Executing_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=3,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=52,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=76,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=75,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=74,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )g:
/usr/bin/python3 -u /UNUSED/testing123.py
...
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=5,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=4,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=3,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
>>> Done
g_callable_info_free_closure ( [callable_info-> dummy1=2, dummy2=3,
dummy3=1d0b030, dummy4=0, dummy5=1d0b030, dummy6=86468, dummy7=0,
padding[0]=0,padding[1]=0,padding[2]=0,padding[3]=0], [closure-> ... ] )
sh-5.1#
one last question, i've never paid attention to a running
gnuradio-companion, it launces several other processes:
6456 tty2 Sl 0:02 /usr/bin/python3 /usr/bin/gnuradio-companion
6473 tty2 S 0:00 dbus-launch --autolaunch
95afc6e6d7a14382a620df11724dd0ec --binary-syntax --close-stderr
6474 ?Ss 0:00 /usr/bin/dbus-daemon --syslog-only --fork
--print-pid 5 --print-address 7 --session
6476 ?Sl 0:00 /usr/libexec/at-spi-bus-launcher
6480 ?S 0:00
Re: reading rfm69 packet transmission
Hello again,
Just a small update in case someone wants to try this out. I have two
patches to apply to get this working for me. The first,
RFM69-Library-AVR-syncword.patch, is to apply against
fermitron2048/packetdemod and the second, RFM69.patch, is to apply
against nayem-cosmic/RFM69-Library-AVR. My thanks to both
nayem-cosmic and fermitron2048 for their work writing these pieces of
software.
Take care.
Chris
On Thu, Feb 3, 2022 at 12:40 PM Chris Gorman wrote:
>
> Hello All,
>
> I have two rfm69 boards [1] connected to two avrs and they are sending
> messages to each other over the airway. Once I got this working I
> thought it would be fun to inspect the messages being sent with my
> rtl_sdr. I can confirm the message is being sent over serial on the
> receiver.
>
> I went searching on the internet for a way to decode the transmission
> and found some scripts to use gnuradio to do packetdemod on rfm69
> boards [2]. The problem with this setup is it requires me to modify
> the code to the rfm69 [3] to prevent whitening. My software to run
> the avrs isn't the same as the author of the packetdemod's and I can't
> apply his patch. I have looked at the code to see if I am using
> whitening, but as far as I can tell I am not. Regardless when I run
> the packetdemod script, I get 'Invalid packets" instead of my message.
>
> In my inbox this morning I found an email with a reference to packet
> communications with gnuradio [4] and am wondering if I should be using
> this method to decode the transmission between the two rfm69's? I
> will try it out anyway as it seems interesting, but is this the
> correct direction to analyze the transmission between two boards like
> the rfm69s?
>
> Thanks in advance,
>
> Chris
>
> [1] https://www.sparkfun.com/products/12775
> [2] https://github.com/fermitron2048/packetdemod
> [3] https://github.com/nayem-cosmic/RFM69-Library-AVR
> [4] https://wiki.gnuradio.org/index.php?title=Packet_Communications
diff --git a/packetdemod.py b/packetdemod.py
index 1825c64..bdaf828 100644
--- a/packetdemod.py
+++ b/packetdemod.py
@@ -126,7 +126,7 @@ def parsepacket(bits):
invalid_packets += 1
return
syncword = (ord(bytes[0])<<8) + ord(bytes[1])
-if(syncword != 0x2d21):
+if(syncword != 0x2dd4):
print("Invalid packet")
invalid_packets += 1
return
@@ -192,7 +192,7 @@ def decode(values = []):
# Align to sync word for beginning of packet
for i in range(1,50):
-syncword = [0,0,1,0,1,1,0,1,0,0,1,0,0,0,0,1]
+syncword = [0,0,1,0,1,1,0,1,1,1,0,1,0,1,0,0]
tmpbits = bits[i:]
if(cmp(syncword,tmpbits[:16].tolist()) == 0):
bits = bits[i:]
diff --git a/radio.py b/radio.py
index df67922..25e366f 100644
--- a/radio.py
+++ b/radio.py
@@ -81,7 +81,7 @@ def parsepacket(bits):
invalid_packets += 1
return
syncword = (ord(bytes[0])<<8) + ord(bytes[1])
-if(syncword != 0x2d21):
+if(syncword != 0x2dd4):
print("Invalid packet")
invalid_packets += 1
return
@@ -147,7 +147,7 @@ def decode(values = []):
# Align to sync word for beginning of packet
for i in range(1,50):
-syncword = [0,0,1,0,1,1,0,1,0,0,1,0,0,0,0,1]
+syncword = [0,0,1,0,1,1,0,1,1,1,0,1,0,1,0,0]
tmpbits = bits[i:]
if(cmp(syncword,tmpbits[:16].tolist()) == 0):
bits = bits[i:]
diff --git a/RFM69.c b/RFM69.c
index 1a52fc3..83ba45f 100644
--- a/RFM69.c
+++ b/RFM69.c
@@ -59,11 +59,11 @@ void rfm69_init(uint16_t freqBand, uint8_t nodeID, uint8_t networkID)
const uint8_t CONFIG[][2] =
{
/* 0x01 */ { REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY },
-/* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00 }, // no shaping
-/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_5}, // default: 4.8 KBPS
-/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_5},
-/* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_5}, // default: 5KHz, (FDEV + BitRate / 2 <= 500KHz)
-/* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_5},
+/* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_OOK | RF_DATAMODUL_MODULATIONSHAPING_00 }, // no shaping
+/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_1200}, // default: 4.8 KBPS
+/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_1200},
+/* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_5000}, // default: 5KHz, (FDEV + BitRate / 2 <= 500KHz)
+/* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_5000},
//* 0x07 */ { REG_FRFMSB, RF_FRFMSB_433},
//* 0x08 */ { REG_FRFMID, RF_FRFMID_433},
Re: Help with sweep generator
On Fri, Feb 11, 2022 at 01:36:59PM +, e heuchamps wrote: > I have read in a thread in this forum that the sampling rate (usually > denoted by the variable "samp_rate") is just a number representing how > much values are in a period of the signal. This means that, for signal > with frequency "f" or, equivalently, period "T = 1/f", 1 second is equal > to T*f = samp_rate*f values. Don't know where you read that, but it is all wrong... 'samp_rate' is just the number of samples per second. For a signal with frequency 'f' there will be samp_rate / f samples in each period. Ciao, -- FA
Re: [VOLK] Release 2.5.1
On Sat, Feb 12, 2022 at 11:40:26AM +0100, Johannes Demel wrote: > 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. I am not (yet) a user of VOLK, but interested. One thing that usually puts me off when considering to use a library is excessive dependencies. This may be a very naive question but I hope you can provide an answer. Why does a library that provides numerical procedures using vector instructions require anything from boost or C++17 ? Or even file operations at all ? Even if this is just a build time dependency it seems odd... Ciao, -- FA
Re: Tutorial on Hier Block and Parameters
Yes, that the generated hier block files go to the working directory of ~/.grc_gnuradio is a known bug. See: https://github.com/gnuradio/gnuradio/pull/5547 What is the result of echo $PYTHONPATH -- Volker Hi, I am facing a problem using the tutorial. My installation is from repository. I am using GRC3.10.1.1(Python3.8.10) on OS Ubuntu 20.04.3LTS. When I generate the flow graph, output files are going to the working directory and not .grc_gnuradio as mentioned in tutorial. Probably because of this, they are not appearing in the block tree of GRC. Also, I get these messages on the terminal. Warning: vocoder_codec2_decode_ps - option_attributes are for enums only, ignoring >>> Warning: vocoder_codec2_encode_sp - option_attributes are for enums only, ignoring May not be relevant, but I observe whenever I open the terminal, the following line appears before the command prompt. PYTHONPATH: command not found Please help me in configuring GRC properly. Or do i have to install gnuradio in home directory instead of system installation? -- Best Regards, vsrk sarma
[VOLK] Release 2.5.1
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
