Job Opportunities at Planet Labs!
Hi Folks, I've got some great opportunities I'd like to let you know about: The first is a Senior Satellite Communication Engineer (SDR). Our current constellation of satellites (200+) and ground stations communicate in the S and X bands, running at 64kb/s, 500kb/s, and 1.5+Gb/s (not a typo). And no surprise, we're working on new radios too. https://boards.greenhouse.io/planetlabs/jobs/4234415 We're also looking for a Senior RF Systems Engineer https://boards.greenhouse.io/planetlabs/jobs/4233885 And a Senior Flight Software Engineer. If you have experience with embedded systems, Linux, and microcontrollers, and like the idea of writing software that runs in orbit, this one could be for you: https://boards.greenhouse.io/planetlabs/jobs/4224485 (These jobs are based in the San Francisco Bay Area.) For those of you not familiar with Planet, we design, build, and operate the largest constellation of imaging satellites in history. We are both a space company and a data company all rolled into one. Eric
Re: File Source - File Sink data transfer
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: Determining peak instantaneous power in waveform
Hi Ron -- Your papr.c program looks like it will do just what I want. I'll grab it. Thanks again for the help you provide! John On 5/18/22 00:23, Ron Economos wrote: I have a block that may be useful for you. It just prints the peak IQ level. It's usually placed just before a hardware sink block. https://github.com/drmpeg/gr-iqlevels The output looks like this: peak real = +1.631239e-01, -1.961090e-01, 0, 0 peak imag = +2.698523e-01, -1.962542e-01, 0, 0 It's printing the maximum I and Q level in both positive and negative directions and the total number of times they exceeded +/- 1.0. I also have an offline program that does PAPR calculations. It just takes a float IQ file as input. https://github.com/drmpeg/dtv-utils/blob/master/papr.c The output looks like this: Peak magnitude = 0.869561 average power = 0.040009514, peak power = 0.756135583 @ 121986288 Maximum PAPR = 12.764364 percentage above 0 dB = 36.79375350 percentage above 1 dB = 28.40112150 percentage above 2 dB = 20.49609423 percentage above 3 dB = 13.58977407 percentage above 4 dB = 8.10234174 percentage above 5 dB = 4.22610082 percentage above 6 dB = 1.86289176 percentage above 7 dB = 0.66361316 percentage above 8 dB = 0.18129208 percentage above 9 dB = 0.03537920 percentage above 10 dB = 0.00439378 percentage above 11 dB = 0.00032525 percentage above 12 dB = 0.1121 peak real positive = 0.840840, peak imaginary positive = 0.798450 peak real negative = -0.791407, peak imaginary negative = -0.821772 peak real positive @ 1703752736, peak imaginary positive @ 1624430697 peak real negative @ 1846543928, peak imaginary negative @ 2753521145 Ron On 5/17/22 12:44, John Ackermann N8UR wrote: Hi -- I have broadband HF data recorded off the air (ham radio bands 384 kHz wide) and am trying to figure out what sort of gain settings I need to play it back on a USRP without distortion. My worry is the way multiple fairly strong signals could add together in phase to create momentary spikes way higher than the visible average (I think this is called crest factor in digital signals?). Is there a (relatively) straightforward way to measure this with Gnuradio blocks? If so, can anyone point me in the right direction to build a GRC flow graph to read an IQ file and print out the peak instantaneous power seen in the file, relative to 100% (ie, I don't need calibrated numbers, just to know how to set the gain in Gnuradio for undistorted playback). Thanks! John
Re: OOT module library name
I meant make your local project directory a git repository with git init, git add and git commit. That will suppress the "compat-xxx-xunknown" file name (and change it to a commit hash). But changing the VERSION_PATCH is a better solution. In fact, I changed gr_modtool to default to that now (but it's only in 3.10 and later). https://github.com/gnuradio/gnuradio/commit/6c36e38ce843476f214b716b25e001e96336fc58 Ron On 5/18/22 05:22, Wojciech Kazubski wrote: Make your project a git repository. Ron The project is already on github: https://github.com/wkazubski/gr-gnMAX2769 On 5/17/22 07:35, Wojciech Kazubski wrote: Hello! When I build (on Linux) a GNU Radio OOT module, written in C++, the library file is named like this: libgnuradio-modulename.so.v0.2-compat-xxx-xuknown The name is the same for versions 0.2.0, 0,2.1, ... which makes conflicts when the library is updated by a package manager. How to change library name to somtething shorter and with full version number like: libgnuradio-modulename.so.0.2.0 ? Wojciech I found a similar problem here: https://github.com/dl1ksv/gr-funcube/issues/2 It was solved by changing VERSION_PATCH from git to 0 After changing this, the library version is OK. Wojciech
Re: OOT module library name
> Make your project a git repository. > > Ron > The project is already on github: https://github.com/wkazubski/gr-gnMAX2769 > On 5/17/22 07:35, Wojciech Kazubski wrote: > > Hello! > > When I build (on Linux) a GNU Radio OOT module, written in C++, the > > library > > file is named like this: > > libgnuradio-modulename.so.v0.2-compat-xxx-xuknown > > The name is the same for versions 0.2.0, 0,2.1, ... which makes conflicts > > when the library is updated by a package manager. > > > > How to change library name to somtething shorter and with full version > > number like: > > libgnuradio-modulename.so.0.2.0 ? > > > > Wojciech I found a similar problem here: https://github.com/dl1ksv/gr-funcube/issues/2 It was solved by changing VERSION_PATCH from git to 0 After changing this, the library version is OK. Wojciech
Re: File Source - File Sink data transfer
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
