Topics

3rd Party Development for the UDR56K (Was: GPL source code)

"John D. Hays" <john@...>
 

As Bryan stated, we will not be delivering any kernel patch or driver source code before product release.  This code is under active development and test, and is often the case in such development it may make significant changes before the product is released.  It would be a disservice to external developers, who do not participate in our internal development process, to provide code that may send them down a path that could suddenly take an unexpected turn.

At some point, the code base will be placed in a public repository (like SourceForge) where others can not only retrieve it but get updates as they are released.

We are aware that there is always a desire when something new is coming out to get a jump on a 'cool' project that has been waiting for the product.  However, as a company we need to stay focused on getting the product ready for market.  The good news is things are progressing nicely and we will give updates over the next weeks and months as we get closer to release.

Our thinking is that we will have several communities of users for the product:

1. Application users.  These are customers who want a specific application such as a D-STAR radio for DD or DV, an APRS terminal, an AMPRNET node, etc. and are looking for pre-built applications with easy configuration and operation, that are basically plug and play. For these users we need a very well defined offering that we are confident will be usable and reliable.   These users' need for source code is generally non-existent other than for the assurance the code is available in both binary and source form.

2. Infrastructure builders.  These are customers who likewise need "plug and play" solutions whether that be a RMS Gateway, APRS iGate, D-STAR Gateway, AMPRNET Gateway, or similar. Again source code is for understanding how it works and the assurance that it is there for a rebuild or modification, if needed.  These folks also need integration information on how to connect their piece of infrastructure into other infrastructure.  They need application notes, recipes, and examples, e.g. how do I use the UDR56K to support my current 1200 baud, 2 meter, APRS node and extend it cover higher speeds at 70cm?  How do I build a large, regional packet network backbone? How do I add a UDR56K to my existing D-STAR stack?  How can I make a regional Digital Voice network with many access points and repeaters that are bound together to create one large "virtual repeater"?

3. Visionaries, Experimenters, Accessory Builders, and Application writers.  These are the folks that really need access to source code, because they may need to add a driver, write a new protocol handler, create a new way to integrate additional technology.  There needs to be a reliable source of code, documentation, and examples for them to adopt, modify, and understand.  This is probably the smallest group, and potentially the inventors of better ways to accomplish what the application user and infrastructure builder is trying to achieve. Where NW Digital Radio is different, is we want to enable these folks, for the advancement of the art of Amateur Radio.  Most companies don't want you modifying their "competitive advantage" and "proprietary secrets" -- most of what will make our product work from day one is built using or building upon the work of others who have shared their talents through open source.  Our goal is to extend that wonderful gift back to the community and hopefully the community will reward us for it, by buying our products and enabling others.

The question has been raised if 3rd parties will have the opportunity participate in the creation of these components?  The answer to that is an enthusiastic "Yes!" We just ask that you allow us to bring our product(s) to a deliverable state and to roll out the enabling tools when the time is right.

There is very little "firmware" in the sense of a traditional embedded device, most things run under the OS, either as applications or as components in the drivers for hardware.  There may be some low level "bit twiddling" that is closer to traditional firmware and we can talk about that when someone has a specific need.

We will review 3rd party components for "fit" in our standard delivery and add them if it makes sense.  Individuals are always welcome to take advantage of the open platform for their own components.

One of the perils of our approach is that support of the product(s) we produce grows with open access, and can be costly unless we limit our direct efforts. (Such costs would need to be reflected in product price or performed for a fee, neither of which is appealing.)  We are going to have to some guiding principles.

1. If we build and deliver it, including unmodified binary code, we have an obligation to support it.

2. There will be many applications added to the built-in computer by customers and users.  We won't help you port or debug applications that have no direct bearing on the product's primary purpose and we reserve the right to say "that application is outside of our interest."  E.g. if you install an application or widget that is not from us, you should expect to get support from whomever you obtained it. 

3. If you (re-)compile it, substitute components, or add your own hardware and break it, you get to fix it.  We aren't going to protect you from yourself and aren't obligated to rescue you.

4. If you are developing some super new application, porting some useful application, or building a new add-on and we decide its "going to add enough value to justify the work" we will consult with you as time permits. (Extremely limited right now.)

5. There may be some things in the kernel patches and drivers that don't make sense.  We likely won't tell you why we did it that way, and if you change it, you might break it (see principle number 3). The reality of using some advanced/modern components is that there may be "quirks" that we have to work around and some "upstream" vendors are very picky about what we say.  We are committed to openness, customer support, and sharing -- we are not committed to being sued. 

6. This forum is a good place to support one another and we do read it.

With all of that said, we know some of you are still eager to start working on something... :)

Here's what I will offer for now.  Not much you can do today that interfaces directly with the radio board, but if you have applications that run on the computer side, that only talk to peripherals (and kernel AX.25) and want to give it a go:

Pick an ARM based board to test/run your application.  We did some early development using the Sheeva Plug (our processor is 800 Mhz and ARMv5).  I'll be receiving a Raspberry Pi tomorrow and out of curiosity will test some of my compiled applications, e.g. ircDDBGateway on it.

We are using Debian/Squeeze (kernel 3.2.5 from http://kernel.org at the present time) based distribution.  So far, standard ARMEL versions of packages (apt-get / .deb) seem to load and run.  You can load and run a native compiler / linker  or use a cross compile chain of your choice, we are using a recent version from Mentor Graphics for kernel work. (They have downloadable versions.)  I use a 32bit Debian Squeeze on AMD64 in a virtual machine for development and copy to the ARM board, it's much faster using multiple processors and lots of memory for compile and link.

So have fun and we at NW Digital Radio will keep "heads down" on getting the product to market.



John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223