<div dir="ltr"><div>Roland,</div><div><br></div>We will review these ideas.<div>Your first point is actually one of our next steps, putting only a single transmit path into its own flowgraph, since that is primarily where the problem lies.</div><div><br></div><div>Thanks for the suggestions,</div><div><br></div><div>Kind regards,</div><div>Glenn<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr">Glenn N. LeBrasseur, P.E.<div><a href="mailto:glennl@pdx.edu" target="_blank">glennl@pdx.edu</a></div><div><br></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Jan 2024 at 00:32, Roland Turner <<a href="mailto:roland@rolandturner.com">roland@rolandturner.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<div>Glenn,</div>
<div><br>
</div>
<div>I am absolutely not a GR expert, but I
wonder whether you aren't missing opportunities to materially
simplify the graph that you're asking GR to plumb, doing which
might allow to avoid the problem if not properly fix it:</div>
<div>
<ul>
<li>Are you able to split the TX and RX paths into separate
processes? This is unsatisfying, but the less complicated a
task you're asking GR to do, the fewer weird things are likely
to happen.</li>
<li>Are you able to remove <b>all</b> of the not strictly
necessary blocks? e.g. you've not mentioned a Lime device in
your setup, but there are LimeSuite blocks. Presumably they're
not being scheduled any CPU time if the device is not
physically present, but why rely on that assumption when it's
in your power to remove it?</li>
<li>Does removing file and GUI sinks avoid the problem? If you,
how many of those can you live without?</li>
<li>Etc.</li>
</ul>
<p>- Roland</p>
<p><br>
</p>
<hr width="100%" size="2">
<p><br>
</p>
</div>
<div>On 4/1/24 16:25, Glenn LeBrasseur via
Ground-Station wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Michelle,<br>
<br>
This is the flowgraph in question:
<div><a href="https://github.com/uniclogs/uniclogs-sdr/blob/maint-3.10/flowgraphs/OreSat0.grc" target="_blank">https://github.com/uniclogs/uniclogs-sdr/blob/maint-3.10/flowgraphs/OreSat0.grc</a><br>
<br>
We have a different repo organization for our ground station
work.
<div><br>
</div>
<div>I can also send our testing notes if you like.<br>
<br>
Thanks so much,</div>
<div><br>
73,<br>
Glenn<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 3 Jan 2024 at 13:28,
Michelle Thompson via Ground-Station
<a href="mailto:ground-station@lists.openresearch.institute" target="_blank"><ground-station@lists.openresearch.institute></a> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div>Greetings all,<br>
<br>
Please read the message below from our
friends at OreSat and speak up if you can
work with them to diagnose the problem
preventing a clean handoff on 11 January. <br>
<br>
OreSat's public repository is here: <a href="https://github.com/oresat" target="_blank">https://github.com/oresat</a><br>
<br>
OreSat's 0.5 website is here: <a href="https://www.oresat.org/satellites/oresat0-5" target="_blank">https://www.oresat.org/satellites/oresat0-5</a><br>
<br>
There are quite a few repositories in
GitHub. Glenn, would you please point out
where the problematic flowgraphs are? <br>
<br>
-Michelle <br>
<br>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<br>
Glenn LeBrasseur <<a href="mailto:gleb2@pdx.edu" target="_blank">gleb2@pdx.edu</a>><br>
Tue, Jan 2, 3:16 PM (21 hours ago)<br>
to me, Andrew<br>
<br>
Hey Michelle,<br>
<br>
If you, or you have anyone who you know
who is knowledgeable with GNU Radio and is
willing to help us with an odd buffering
problem, we would be totally
appreciative. <br>
<br>
Our team here at OreSat is having a bit of
an existential crisis regarding GNU Radio.
We are using a HackRF One for transmit and
a RTL-SDR for receive, to send our fairly
simple GFSK traffic through our ground
station, and we are having packet
buffering problems. The flow graph
communicating through UDP sockets is
behaving strangely when sending the
packets. At first things were fine when
our packets were small, but now varying
the packet size, ever so slightly, is
causing things to go wrong.<br>
<br>
We are totally willing to share our
flowgraphs and testing procedure, as you
know we are totally open source, so they
currently are online at our GitHub site.
We will tell you everything we are doing!<br>
<br>
Anything you could help with would be
great, particularly since we are doing
integration testing right now of our
OreSat 0.5 cubesat, for a handoff on
11-Jan-2024, and this has just cropped up.<br>
<br>
Please let me or Andrew know what's
possible.<br>
<br>
Kind regards and 73,<br>
<br>
Glenn, KJ7SU<br>
<a href="mailto:gleb2@pdx.edu" target="_blank">gleb2@pdx.edu</a><br>
<br>
Glenn N. LeBrasseur, P.E.<br>
<a href="mailto:glennl@pdx.edu" target="_blank">glennl@pdx.edu</a><br>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">Glenn Noel LeBrasseur<br>
<a href="mailto:glenn.lebrasseur@gmail.com" target="_blank">glenn.lebrasseur@gmail.com</a><br>
<br>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote></div>