[Ground-station] Question for ORI:

[Leffke, Zachary]

Hi Bruce,
Thanks for the response.  I think that all makes sense to me.  I guess I’m just saying (IMHO) we shouldn’t COMPLETELY shy away from say a reference design for a ground station that uses something like an RTL-SDR or FunCube dongle just because they use proprietary hardware, given their popularity and in order to stay ‘relevant to the masses’ …… Also I realize I’m harping a bit on the proprietary chips and such more for something like open hardware designs…..completely agree the protocols involved should be free and clear of any kind of patent, IP protection, etc.....ideally there should be many ways to ‘skin the cat’ there for implementation (RFICs, SDRs, etc).

Back on the LoRa specific topic, and as far as reverse engineering (for better or worse), just thought I’d mention this:  https://github.com/BastilleResearch/gr-lora (might be outdated, hasn’t been updated in 4 years or so, but maybe useful to someone looking at ‘LoRa from space’ even if the above isn’t specifically for space applications).


-Zach, KJ4QLP
--
Research Associate
Aerospace & Ocean Systems Lab
Ted & Karyn Hume Center for National Security & Technology
Virginia Polytechnic Institute & State University
Work Phone: 540-231-4174
Cell Phone: 540-808-6305

From: Bruce Perens <bruce at perens.com>
Sent: Thursday, April 1, 2021 5:52 PM
To: Leffke, Zachary <zleffke at vt.edu>
Cc: ground-station at lists.openresearch.institute
Subject: Re: [Ground-station] Question for ORI:



On Thu, Apr 1, 2021 at 1:46 PM Leffke, Zachary via Ground-Station <ground-station at lists.openresearch.institute<mailto:ground-station at lists.openresearch.institute>> wrote:
So my question is, given that RTL-SDRs are so prolific (same for funcube dongles, though maybe to a lesser extent), does it REALLY matter if the ICs are proprietary?  Isn’t what actually matters is that the drivers needed to use them are open source?

Well, you sort of answered your own question, since it's problematical for you to incorporate them in a design.

ICs are a big problem in general. Intel has the infamous system management processor in their chip which seriously degrades the security of your platform unless you use reverse-engineered stuff to turn it off (given that you are not the US government, to whom the method is deliberately disclosed). Although what is in there is mostly figured out through reverse engineering, it is not publicly documented. The Raspberry Pi 3 boots from the GPU which is an entire undocumented CPU on the die, I don't know if 4 is the same. And in general you have no idea what is in your IC, which is a security issue that could fill books.

So, what do we do in the name of holding up standards for openness? Mainly a design-in policy: Avoid chips that require BLOBs and proprietary libraries to work. Prefer to design in ICs where you can download all of the documentation over the web. Avoid chips where the only possible configuration data available is generated by a piece of proprietary software, and it's not otherwise documented. There are a lot of those in the RF world. Where a chip is available with an Open Source driver but not public documentation, especially if the driver is the result of reverse-engineering (which is the case for RTL), we should prefer ones that are documented.

Then there is the issue of intercommunication. We need higher standards for design-in there. Intercommunication protocols, modulations, etc. should be publicly documented and usable without having to execute any sort of patent licensing. Where standards are designed-in, they should not include royalty-bearing patents.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20210401/ba6bf60a/attachment-0001.html>