Re: Invalid type specifier
Thank you Ron for the bug in 3.10.2.
But after correction and new compilation the error message is
unfortunately still present when I launch GRC.
[*** LOG ERROR #0001 ***] [2022-07-09 17:52:42] [test_bvb] {invalid type
specifier}
Jeff
-
Le 10/07/2022 à 11:57, Ron Economos a écrit :
Are you trying to set the Minoutbuf setting on your block to something
other than 0? There was a bug with that in 3.10.2.
Fixed in 3.10.3.
https://github.com/gnuradio/gnuradio/commit/af6f28e3ba7042ac5eeb8c4b39857cbb15d436a5
Ron
On 7/10/22 01:44, user 1 wrote:
Hello,
I have build a simple test OOT block to learn and play with vectors.
My OOT block written in C++ is between a file data source and a file
data sink.
The gcc compilation is error free. All is OK, my block works fine, the
resulting data are consistent.
However, at the start of the execution in GRC, I get the following
error message:
[*** LOG ERROR #0001 ***] [2022-07-09 17:52:42] [test_bvb] {invalid
type specifier}
Probably something wrong !
I work under:
Ubuntu 20.04.1
GnuRadio 3.10.2
gcc 9.4.0
python 3.8.10
Thank you for your help.
Jeff
Invalid type specifier
Hello,
I have build a simple test OOT block to learn and play with vectors. My
OOT block written in C++ is between a file data source and a file data sink.
The gcc compilation is error free. All is OK, my block works fine, the
resulting data are consistent.
However, at the start of the execution in GRC, I get the following error
message:
[*** LOG ERROR #0001 ***] [2022-07-09 17:52:42] [test_bvb] {invalid type
specifier}
Probably something wrong !
I work under:
Ubuntu 20.04.1
GnuRadio 3.10.2
gcc 9.4.0
python 3.8.10
Thank you for your help.
Jeff
SOLVED - Re: File Source - File Sink data transfer
The problem is solved !
It was a conflict between my 3.9.6 release of Gnu Radio and older files
remaining from previous installations of Gnu Radio.
After a big cleaning, a new compilation and fresh installation of the
3.10.2.0 release, the data transfer works fine.
Thank you to all, specially to Marcus Müller.
jeff
Le 18/05/2022 à 17:26, Marcus Müller a écrit :
Hi!
ah, a first indication for that would be if you can find more of one
libgnuradio-blocks (which aren't just symlinks to each other); `locate
libgnuradio-blocks` is often an easy way to find that.
Note that I'm really not sure this is the explanation. It's just my best
guess what might be the reason that two symbols don't match although
they should.
Best regards,
Marcus
On 18.05.22 17:04, user 1 wrote:
Marcus,
Thank you for your detailed explanation.
My file ~/gnuradio/gr-blocks/lib/file_source_impl.cc is exactly the
same the file you mentionned in your answer.
I checked the .yml and it seems OK too.
To install my 3.9.6 release of Gnuradio from sources, on my Ubuntu
20.04 release, I followed the following procedure:
1) installation of all the needed dependencies:
https://wiki.gnuradio.org/index.php?title=UbuntuInstall#Focal_Fossa_.2820.04.29_through_Impish_Indri_.2821.10.29
2) installation of Volk, then Gnu Radio from sources as described here:
https://wiki.gnuradio.org/index.php/InstallingGR
Maybe files of a previous installation of an old Gnu Radio release are
in conflict with the present installation ?
In this case how can I totally delete them ?
Thank you
Le 18/05/2022 à 13:02, Marcus Müller a écrit :
Hi Jeff,
yeah, that's odd; I was just assuming you were literally typing () in
that field, but that just is the string representation of PMT_NIL,
so: my apologies :)
What's mainly odd is that PMT_NIL is not accepted; it certainly works
for me, and I've checked: There's no code changes in that block's tag
handling, the GRC block or the python bindings, and also not to the
add_item_tag method, between GNU Radio v3.9.6 and what I'm running :/
What's really confusing is this: If you look at the file source's
source code, what it does is check whether you're at the file
beginning AND whether the begin tag is NOT PMT_NIL, and only if
that's the case, it'd actually call the `add_item_tag` method that
fails [1].
279 │ if (d_file_begin && d_add_begin_tag != pmt::PMT_NIL) {
280 │ add_item_tag(0,
281 │ nitems_written(0) + noutput_items
- size,
282 │ d_add_begin_tag,
283 │ pmt::from_long(d_repeat_cnt),
284 │ _id);
285 │ d_file_begin = false;
286 │ }
So, if pmt.PMT_NIL was actually successfully passed to the file
source, this should never be called! But: it does seem to be called.
But it's also being called with something that might very well
actually *be* an instance of pmt_null, just maybe not the one and
only instance of pmt_null that should exist, namely PMT_NIL?!
This all reeks of Static Initialization Order Fiasco, but I'm really
confused on how that could arise here :/ It's a bit as if your
flowgraph's python and your file_source's C++ use a different
PMT_NIL, although in both it should 100% be the same. Looking for
something to hold onto: How did you install your GNU Radio?
Best regards,
Marcus
[1]
https://github.com/gnuradio/gnuradio/blob/v3.9.6.0/gr-blocks/lib/file_source_impl.cc#L279-L286
On 18.05.22 12:13, user 1 wrote:
Hi Marcus,
Thank you for your message.
pmt.PMT_NIL is the default value of add begin tag, but unfortunately
that doesn't work, see the error message (Screenshots 1 and 2).
However, after many trials, if I put under the add begin tag the
values:
pmt.string_to_symbol("file_begin")
or
pmt.string_to_symbol("")
or
pmt.string_to_symbol("whatever_you_want")
finaly the data transfer works fine !
See (Screenshots 4 and 5)
Odd, isn'it ?
Jeff
Re: File Source - File Sink data transfer
Marcus,
Thank you for your detailed explanation.
My file ~/gnuradio/gr-blocks/lib/file_source_impl.cc is exactly the
same the file you mentionned in your answer.
I checked the .yml and it seems OK too.
To install my 3.9.6 release of Gnuradio from sources, on my Ubuntu 20.04
release, I followed the following procedure:
1) installation of all the needed dependencies:
https://wiki.gnuradio.org/index.php?title=UbuntuInstall#Focal_Fossa_.2820.04.29_through_Impish_Indri_.2821.10.29
2) installation of Volk, then Gnu Radio from sources as described here:
https://wiki.gnuradio.org/index.php/InstallingGR
Maybe files of a previous installation of an old Gnu Radio release are
in conflict with the present installation ?
In this case how can I totally delete them ?
Thank you
Le 18/05/2022 à 13:02, Marcus Müller a écrit :
Hi Jeff,
yeah, that's odd; I was just assuming you were literally typing () in
that field, but that just is the string representation of PMT_NIL, so:
my apologies :)
What's mainly odd is that PMT_NIL is not accepted; it certainly works
for me, and I've checked: There's no code changes in that block's tag
handling, the GRC block or the python bindings, and also not to the
add_item_tag method, between GNU Radio v3.9.6 and what I'm running :/
What's really confusing is this: If you look at the file source's source
code, what it does is check whether you're at the file beginning AND
whether the begin tag is NOT PMT_NIL, and only if that's the case, it'd
actually call the `add_item_tag` method that fails [1].
279 │ if (d_file_begin && d_add_begin_tag != pmt::PMT_NIL) {
280 │ add_item_tag(0,
281 │ nitems_written(0) + noutput_items -
size,
282 │ d_add_begin_tag,
283 │ pmt::from_long(d_repeat_cnt),
284 │ _id);
285 │ d_file_begin = false;
286 │ }
So, if pmt.PMT_NIL was actually successfully passed to the file source,
this should never be called! But: it does seem to be called. But it's
also being called with something that might very well actually *be* an
instance of pmt_null, just maybe not the one and only instance of
pmt_null that should exist, namely PMT_NIL?!
This all reeks of Static Initialization Order Fiasco, but I'm really
confused on how that could arise here :/ It's a bit as if your
flowgraph's python and your file_source's C++ use a different PMT_NIL,
although in both it should 100% be the same. Looking for something to
hold onto: How did you install your GNU Radio?
Best regards,
Marcus
[1]
https://github.com/gnuradio/gnuradio/blob/v3.9.6.0/gr-blocks/lib/file_source_impl.cc#L279-L286
On 18.05.22 12:13, user 1 wrote:
Hi Marcus,
Thank you for your message.
pmt.PMT_NIL is the default value of add begin tag, but unfortunately
that doesn't work, see the error message (Screenshots 1 and 2).
However, after many trials, if I put under the add begin tag the values:
pmt.string_to_symbol("file_begin")
or
pmt.string_to_symbol("")
or
pmt.string_to_symbol("whatever_you_want")
finaly the data transfer works fine !
See (Screenshots 4 and 5)
Odd, isn'it ?
Jeff
Re: File Source - File Sink data transfer
Hi Steven, Thank you for your suggestion, but /dev/urandom is an empty file See Screenshot_3 jeff -- Le 16/05/2022 à 16:41, Steven Barbo a écrit : Howdy Jeff. What happens if you use /dev/urandom as file source? On Mon, May 16, 2022 at 9:09 AM user 1 <mailto:gnura...@onditech.com>> wrote: Hello Cinaed, Unfortunately scheme doesn't work, even with a bin file. jeff -- Le 16/05/2022 à 12:06, Cinaed Simson a écrit : > Hi Jeff - the error indicates the file source has the wrong data type, > i.e. it may not be binary data. > > If the input file contains hex numbers, then you need to convert each > hex number to a binary number and concatenate them. > > -- CInaed > > > For instance, 40 hex is equivalent to 0100 binary. > > For instance, > > On 5/16/22 00:46, user 1 wrote: >> Hi, >> >> Somebody could tell me why this simple scheme doesn't work (see the >> screenshots)? >> >> File Source ---> Throttle ---> File Sink >> >> >> I work under Ubuntu 20.04.4 LTS and GnuRadio 3.9.6 >> >> >> This scheme worked fine in the past with previous releases of GnuRadio. >> >> >> Thank you for your help. >> >> >> >> Jeff > -- If something is requisite, how can it possibly be, prerequisite? vanitas vanitatum omnia vanitas later, steve http://umn.edu/~barbo <http://umn.edu/~barbo>
Re: OOT module problem
Hi, I suppose you use gcc under Linux. Il line, try to go to the build directory of your module: ~/gnuradio/my_module/build Then enter: cmake ../ make -B sudo make install sudo ldconfig The -B option of make (Unconditionnaly make all targets) is important to include all your files in the process. Tell us the result. Good Luck ! -- Le 13/05/2022 à 18:34, David Martini a écrit : Dear Community, I'm starting to learn how to write an OOT module. I'm following the tutorial : all the compilation process go well but When I try to run my module i get the following error import test_001 ModuleNotFoundError: No module named 'test_001' The module is present in the block list. see the attached picture. I'm not able to understand where the problem is Thank you for help David
File Source and File Sink under GnuRadio Companion v3.11.0.0
Hello, I'm a beginner and I try to build under GRC, Operating System Ubuntu, a very simple system: File Source ---> Throttle---> File Sink The data transfer runs very well in a previous release of GnuRadio, but with my new installation of GnuRadio v3.11.0.0 the transfer doesn't work anymore. I discover on the File Source symbol new parameters: - Add begin tag, with default content: pmt.PMT_NIL - Offset: 0 - Length: 0 What is missing in my configuration to get the data tranfer OK, like previously ? Thank you
