2
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://aus.social/@jpm" class="u-url mention">@<span>jpm</span></a></span> I think you are, partly because of the caution with which you approach the topic.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@chrisgj198" class="u-url mention">@<span>chrisgj198</span></a></span> <span class="h-card" translate="no"><a href="https://aus.social/@jpm" class="u-url mention">@<span>jpm</span></a></span> I do feel that I&#39;m not skilled enough to properly attempt this</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://aus.social/@jpm" class="u-url mention">@<span>jpm</span></a></span> True, but the inverse square law is pretty effective, if you don&#39;t vastly exceed the power that you need. Maybe attenuating one of the signals *before* mixing would give more certainty that the signal that you don&#39;t want to escape doesn&#39;t exist anywhere at high power.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@chrisgj198" class="u-url mention">@<span>chrisgj198</span></a></span> <span class="h-card" translate="no"><a href="https://aus.social/@jpm" class="u-url mention">@<span>jpm</span></a></span> my understanding (based on talking to someone who worked with GNSS emulators) is that it&#39;s particularly difficult to limit the power of GNSS transmissions, seeing as receivers will pull them from well below the thermal noise floor</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://aus.social/@jpm" class="u-url mention">@<span>jpm</span></a></span> I was more thinking of how it would behave in its natural environment, where the serial port is inaccessible. I agree that during investigations you should limit the power of any transmissions such that nobody else notices them.</p>
<p><span class="h-card" translate="no"><a href="https://social.treehouse.systems/@rcombs" class="u-url mention">@<span>rcombs</span></a></span> beats me</p><p>but i also would expect the SBU to know basic shit like this already. to the best of my knowledge the devices i have are of little operational interest, Ukrainian electronic warfare is far ahead of what these devices can tolerate</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@gamingonlinux" class="u-url mention">@<span>gamingonlinux</span></a></span> 🥂</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@chrisgj198" class="u-url mention">@<span>chrisgj198</span></a></span> <span class="h-card" translate="no"><a href="https://aus.social/@jpm" class="u-url mention">@<span>jpm</span></a></span> i could also just feed it the ublox binary messages; same result for less effort (with the caveat that i don&#39;t know if the ublox module will actually emit such long messages in any practical environment)</p><p>i _really_ don&#39;t want to mess with GNSS signals too much, since if they leak i&#39;ll get a not-so-friendly visit from Ofcom and it&#39;ll be 100% deserved</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> military-grade code!</p>