How Open? How Free? OpenBSD? NetBSD?
How open/free will the platform be?
Will I be able to port OpenBSD, compile all of the device drivers, and have the computer/radio run on OpenBSD instead of Linux? (Requiring GPL for some software is fine with me, and even preferred, to make sure it stays open and free.)
(I prefer OpenBSD for all interfaces to the outside world, for its greater security. A radio interface is certainly an interface to the outside world.)
How will the system boot? U-Boot? PXE? Either?
Will it be possible to completely control/configure the system via text-based files, or will the web server be required? If I want to, can I disable the web server, and control it via text-based files in /etc? I don't mind if the GUI is provided for other people to use, but I prefer a traditional text-based interface for myself.
PS Having NetBSD ported to the platform would be another feather in your cap. And you don't have to do the work. The NetBSD folks will do it for you if you are open enough.
PPS I'm interested in helping to develop mobile ad-hoc mesh networking algorithms and protocols. I also do DSP.
PPPS I'm also interested in the next generation radio, which should be capable of roughly 400 kHz - 1 MHz of instantaneous bandwidth, and correspondly higher data rates, perhaps on the microwave bands.
"John D. Hays" <john@...>
On Sun, Mar 1, 2015 at 11:59 PM, dsp_stap@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
Different people have different definitions of these terms. Here is our vision.
NW Digital Radio builds hardware. We depend on many outside software developers, mostly open source, to support our hardware.
NW Digital Radio believes that the Amateur Radio community is best served when that hardware runs software developed by the Open Source community and specifically by amateur radio operators.
Some components, e.g. the AMBE-3000 chip, microprocessors, etc. are protected intellectual property and we will honor established intellectual property law.
NW Digital Radio will publish the source to its drivers and supporting software, with the caveat that NW Digital Radio does not anticipate such limitations, but some hardware components that go into a product come with non-disclosure requirements, in which case we will divulge as much as we are permitted and will document when we are unable to share additional information.
Should NW Digital Radio enter into agreements with commercial customers that require some information and/or code be kept confidential, we will honor those agreements, and treat such as a separate product, but will continue to provide amateur radio products with open access to our hardware and amateur radio specific software as stated above.
Assuming the requisite skill, NW Digital Radio, encourages independent development and support. However, we cannot be liable for any damages that arise out of that development, as it is independent and not under our control. Selection of licenses is up to the authors of the software.
Our current implementation uses U-Boot, but could be subject to change.
There is no requirement to run the web server or a gui. In a complex and evolving system such as the UDRX, control of various components may have varying requirements whether text base configuration files, api, or other mechanisms, we cannot guarantee that implementations (often done by others and adopted by NW Digital Radio) will always meet every user's expectations and preferences.
Even within our small staff we have BSD advocates. With limited resources we will likely settle on a single OS/Distribution for direct delivery on the UDRX. This does not prevent others from providing distributions with accompanying support.
We are very interested in mobile ad-hoc mesh networking and DSP development (especially for modulation and demodulation using I/Q). If you possess the skills, we would love to hear what you have done and what you have in mind.
Our focus for now is getting the UDRX ready for market. We have made provisions for somewhat higher bandwidth in the UDRX, however, in the US we are limited by regulations as well as being good neighbors to other spectrum users.
There are many microwave products out there which provide higher bandwidth at reasonable prices, we have to determine if we would add value with our offerings.
--- John Hays K7VE wrote:
> Some components, e.g. the AMBE-3000 chip,
> are protected intellectual property ...
I understand, and I really don't care. I won't use it. I can use Codec2 instead.
By the way, I'm very pleased that the AMBE chip is not included in the radio by default, forcing all users to pay an AMBE tax, even if they don't plan to use it. That was an excellent design decision! Thank you.
> Some components, e.g. microprocessors, etc.
> are protected intellectual property ...
That's the scary part. And you really didn't answer the question.
As soon as you can say it is really, totally, absolutely, completely open, fully documented, etc., you should emphatically do so. Otherwise, I must assume that you have a Raspberry Pi situation.
So sad, for an otherwise very promising product.
Please alleviate my (and others') fears on this isue as soon as you possibly can.
> We are very interested in mobile ad-hoc
> mesh networking and DSP development
> (especially for modulation and demodulation
> using I/Q). If you possess the skills, we
> would love to hear what you have done
> and what you have in mind.
As far as low-level signal processing goes, my email address should give you a very big clue as to my capabilities and accomplishments.
I've also done very special purpose software defined radios.
I don't have as much experience in designing mobile ad-hoc mesh networking algorithms, but I did work for two years implementing algorithms which others developed for the WIN-T tactical radio system. WIN-T is a mobile ad-hoc mesh networking TCP/IP communication system. All of that work was at layer 2 of the OSI 7-layer network stack, which in fact is the interesting layer.
PS The issue of fully documented radio interfaces is essentially identical to that of microprocessor booting, for all hardware in the radio. I don't need to know the innards of how it works, but I do require a complete interface specification so I can use the product.
PPS It should go without saying that all users always need a complete interface specification; if they don't have a complete interface specification, then how do they properly use the product? It says something very bad about our modern world that interfaces are kept proprietary. I will continue to choose and use products that are completely documented, and refuse to buy and use products that aren't. I hope your product is in the former category. But now I am not sure. Please assure me as soon as you can.
PPPS Send me one of the single board computers so I can port OpenBSD to it. I'll send it back to you when I'm done. Or I'll be happy to send it on to the NetBSD team.
Tom Hayward <esarfl@...>
On Mon, Mar 2, 2015 at 12:17 PM, 'John D. Hays' john@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
NW Digital Radio will publish the source to its drivers and supporting software,Allowing us to see the source isn't terribly useful. To do great
things, we need the code to come with a license that allows free
modification. What license will you use? (If you need help choosing
one, this site is great: http://choosealicense.com/licenses/ )
Healthy open source projects also have a defined process for
integrating changes. This is what has made GitHub so popular. Not only
do they provide a place to store code, they provide a way to suggest,
review, and integrate changes from others. Think about how you will
handle this process.
"Tyrell Jentink, KD7KUJ" <tyrell@...>
>Otherwise, I must assume that you have a Raspberry Pi situation.
What's wrong with the Raspberry Pi? The best I can tell, this sums it up well, and I don't see a real problem: http://www.raspberrypi.org/forums/viewtopic.php?t=55777&p=422729
Don't get me wrong, I hate Broadcom and ARM Holdings as much as the next guy, and I'm aware of the bugs in the OpenGL ES implementation, but I also recognize that I, as a mere mortal, can't do anything about it: I don't have the capability to cast a new die that fixes those problems, so I don't have to care. I guess it would be nice to be able to find said bugs and tell Broadcom how to fix them, but I don't need that capability to write cool software.
---In UniversalDigitalRadio@..., <tyrell@...> wrote :
> What's wrong with the Raspberry Pi?
No documentation. Closed proprietary interfaces.
PS A closed proprietary interface is an inherent contadiction.
"Tyrell Jentink, KD7KUJ" <tyrell@...>
toggle quoted messageShow quoted text
OK, I think I understand: As an OS developer, you find the lack of documentation on hardware to be a major restriction. I can understand that; I'm just not an OS developer, none of my code runs directly on the chip... And there isn't much I can't do in Linux. Honestly, the Raspberry Pi is as open as it's target audience actually needed.
I come from a Geography background, and the lack of openness in the GPS industry, particularly with regard to interfaces, is infuriating: Nothing is truly open, and the best one can hope for is a wide set of APIs typically found in only the most expensive units. Same thing with GSM modem chipsets; The Neo Freerunner was a completely open smartphone except for it's GSM baseband. At least those applications have military and FCC concerns to protect, and while I disagree, I can understand the perspective.
I am suspicious of the UDRX having similar problems, but am generally optimistic... Unlike GPS and GSM, Amateur Radio Operators are SUPPOSED to be trusted with the innards of our equipment. I might not be fully in the know, but I can't imagine anyone benefiting from NOT giving full access to the RF stack. Maybe I'm just not worrying enough.
On Mar 3, 2015 4:56 PM, "dsp_stap@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote: