Raspberry Pi D-STAR Gateway
"John D. Hays" <john@...>
I've been working on a port of Jonathan's gateway and pcrepeatercontroller software to the ARM processor for the coming UDR56K (http://nwdigitalradio.com) digital radio. It has been running for a couple of months on KF7UFZ gateway (currently B).
I received my $35 Raspberry Pi (http://www.raspberrypi.org) Linux computer yesterday and this evening I had a few minutes after work and copied my port and configuration files over to the Raspberry Pi. I am successfully testing ircDDBGateway with GMSKRepeater (NQMHS board/DUTCH*Star beta firmware). I connected to REF001C to get some traffic and successfully made contacts with 3-4 stations.
I don't happen to have an Icom RP2C here at the shack to test, but Jonathan's ircDDBGateway does support it as a controller. root@raspberrypi:~# cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 7 (v6l) BogoMIPS : 697.95 (The UDR56K processor shows 1064.96 BogoMIPS)
Features : swp half thumb fastmult vfp edsp java tls CPU implementer : 0x41 CPU architecture: 7
CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7
Hardware : BCM2708 Revision : 0002 Serial : 0000000099172048
top - 18:23:37 up 48 min, 2 users, load average: 0.00, 0.02, 0.11 Tasks: 58 total, 1 running, 57 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 3.0%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 190836k total, 180472k used, 10364k free, 6084k buffers
Swap: 0k total, 0k used, 0k free, 149508k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1102 root 20 0 82812 4608 2444 S 2.3 2.4 1:04.42 ircddbgatewayd 1187 root 20 0 40624 3008 2028 S 1.0 1.6 1:11.46 gmskrepeaterd
1253 root 20 0 2608 1152 936 R 1.0 0.6 0:00.09 top 491 root 20 0 1712 504 424 S 0.3 0.3 0:01.41 ifplugd
1 root 20 0 2076 700 608 S 0.0 0.4 0:00.69 init CPU utilization when keyed up is ircDDBGateway 9+% GMSKRepeater 4+% Operating System is Debian Squeeze (both platforms), for the Raspberry Pi I needed to install portaudio19-dev My Pi is housed in this box http://www.adafruit.com/products/859 and I'm powering it with http://www.amazon.com/gp/product/B004911E9M
John D. Hays K7VE
|
|
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.
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:
So have fun and we at NW Digital Radio will keep "heads down" on getting the product to market.
John D. Hays K7VE
|
|
Re: GPL source code
Jerald A DeLong <kd4yal@...>
Bryan,
Thank you for the information. Would you foresee Amateur Community participation in future firmware releases? Jerry, KD4YAL
|
|
Re: GPL source code
"k7udr" <bhhoyer@...>
As the product is still in active development, the information you need will not be released until a month or two after first customer shipped. Thanks for your patience.
toggle quoted messageShow quoted text
Bryan
--- In UniversalDigitalRadio@yahoogroups.com, Jerald A DeLong <kd4yal@...> wrote:
|
|
Re: Processor architecture, gnuradio
Darren Long <darren.long@...>
Hi John,
toggle quoted messageShow quoted text
Thanks for the info. I hadn't got my hopes up for using the rig as an SDR, but I was mostly curious about what software I might be able to run on it, and what other gadgets I might connect to its multitude of ports. Having a bunch of USB attached SDRs and knowing that radios like the Ettus USRP E100 run gnuradio on ARM architecture made me wonder what else could be bolted on to keep the CPU busy when it's not thrashing away on 70cm. I've been using a Sheevaplug for a number of years running Debian and have been through a fair range of Nokias Linux devices too. I have worked my way through a number of failed SD cards in that time-frame with those devices, but the MTDs used in them have never let me down. I assume the SD card would be accessible enough to replace in case of failure, even if it was too awkward to swap on a regular basis. It may be time to see if I can get the Sheevaplug to do anything useful with the Funcube Dongle SDR and other gadgets. Keep up the good work, Cheers, Darren, G0HWW
On 10/06/12 01:22, John D. Hays wrote:
|
|
GPL source code
Jerald A DeLong <kd4yal@...>
Good Morning,
I am interested in your product and I would like to know were I could download the following: * complete toolchain that made the kernel and applications be compiled (gcc, binutils, libc) * tools to build a custom firmware. * kernel sources with patches to make it run on this specific hardware, this does not include binary drivers Thank you very much in advance for your answer. Best regards, Jerald A DeLong, KD4YAL
|
|
Check out the new YouTube Channel
"John D. Hays" <john@...>
NWDigtalRadio Video -- Se Ham Radio Now interview of Bryan Hoyer.
|
|
Re: USB touch screen
"William Stillwell - KI4SWY" <wkstill@...>
I would use a friendly arm to connect to the udr :P
From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of VK5ZEA
Sent: Saturday, June 09, 2012 7:05 PM To: UniversalDigitalRadio@... Subject: [UniversalDigitalRadio] USB touch screen
Hi Everybody,
|
|
Re: USB touch screen
Bryan Hoyer <bhhoyer@...>
The USB Ports are powered by a 12 to 5V buck regulator and specced for the full 500ma x 4 = 2A.
toggle quoted messageShow quoted text
Bryan
On Jun 9, 2012, at 4:04 PM, VK5ZEA wrote:
|
|
Re: Processor architecture, gnuradio
"John D. Hays" <john@...>
In line.
On Sat, Jun 9, 2012 at 7:41 AM, Darren Long <darren.long@...> wrote:
Marvell PXA168
Currently 256 MB, may be 512 MB in production, depending on price curve for memory
microSD - probably 4 GB. It is user replaceable (not recommended), but not easily accessed (internal) -- watch for tested Manufacturer / Model. Not all microSD are recommended for a boot device. I have a 8 GB in my lab bench unit, loaded with a development chain (compiler, linker, libraries), OS, and many applications and haven't hit 2 GB yet.
It is not a software defined radio. Modulation is performed inside the RF-IC. We really like what SDR does, but for VHF/UHF+ digital modulation there are well known techniques and the RF-IC supports most of them. Using built-in modulators keeps part count and cost down.
John D. Hays K7VE
|
|
Re: USB touch screen
"John D. Hays" <john@...>
I would recommend powering it separately (either directly or through a USB hub), but the USB connection is there and its a matter of having a driver (Debian Linux). A simple text based interface would put less tax on the processor, but I have run X-Windows over Ethernet to an external system without a problem.
toggle quoted messageShow quoted text
There is also the option of the Web interface on WiFi to an iOS or Android device (phone or tablet), or possibly custom application written to do the same over those devices. The CPU on the radio is from the same manufacturer as this
http://www.mimomonitors.com/products/mimo-plug -- though a different generation and slower (800 Mhz.) speed.
John D. Hays K7VE
On Sat, Jun 9, 2012 at 4:04 PM, VK5ZEA <michaelcarey@...> wrote:
|
|
USB touch screen
"VK5ZEA" <michaelcarey@...>
Hi Everybody,
I know it's early days and all... and I'm probably thinking way too much this early on in development... I've been thinking of ways to control the UDR56K-4 without having a PC connected. Would the processor in the radio be powerful enough to drive a USB connected touch screen... something like the Mimo Monitors products? A very functional but simple control system could be quite easy to come up with that works on a small LCD screen. Just an idea... Michael. VK5ZEA
|
|
Processor architecture, gnuradio
Darren Long <darren.long@...>
Hi,
Can we get any ideas on what processor architecture, amount of RAM and internal storage the device will have, please. Even the vaguest hints are welcome at this stage. I'm wondering if gnuradio might find its way in there somehow. Darren, G0HWW
|
|
Re: Interface Screen Shot
John Ronan <jpronans@...>
On 07/06/12 23:54, k7udr wrote:
The screen shot is in FilesThanks for that. John EI7IG
|
|
Call for Technical Papers at 2012 ARRL/TAPR DCC (Digital Communications Conference), Atlanta, GA
Mark Thompson <wb9qzb_groups@...>
Papers Requested for ARRL/TAPR Digital Communications Conference06/01/2012 Amateurs are invited to submit technical papers for presentation at the 31st Annual ARRL and TAPR Digital Communications Conference to be held September 21-23, 2012 at the Sheraton Gateway Airport Hotel in Atlanta, Georgia. These papers will also be published in the Conference Proceedings (you do not need to attend the conference to have your paper included in the Proceedings). The submission deadline is July 31. Please send papers to: Maty Weinberg, ARRL, 225 Main St, Newington, CT 06111. Or you can make your submission via e-mail to: maty@.... For more information about the conference, see the Tucson Amateur Packet Radio www.tapr.org/dcc, or call 972- 671-8277.
|
|
Re: Interface Screen Shot
"k7udr" <bhhoyer@...>
Look in Files
toggle quoted messageShow quoted text
--- In UniversalDigitalRadio@yahoogroups.com, Tyler Griffiths <tyler.griffiths@...> wrote:
|
|
Re: Interface Screen Shot
"k7udr" <bhhoyer@...>
Don't read too much into the table entries. That system was set up for software testing using an external 1200 TNC on my existing 220 Gateway.
toggle quoted messageShow quoted text
--- In UniversalDigitalRadio@yahoogroups.com, "k7udr" <bhhoyer@...> wrote:
|
|
Re: Interface Screen Shot
Tyler Griffiths <tyler.griffiths@...>
I see no pictures...
toggle quoted messageShow quoted text
On Thu, Jun 7, 2012 at 4:50 PM, k7udr <bhhoyer@...> wrote:
|
|
Re: Interface Screen Shot
"k7udr" <bhhoyer@...>
The screen shot is in Files
toggle quoted messageShow quoted text
--- In UniversalDigitalRadio@yahoogroups.com, "k7udr" <bhhoyer@...> wrote:
|
|
Interface Screen Shot
"k7udr" <bhhoyer@...>
This is a quick screen shot of what the interface for winlink mail looks like. There will be more detail in the upcoming app note on the website.
Let's walk thru it. When I sit at my home station doing RMS mail I typically have a TNC connected to the serial port/radio and the following windows open. An email client A console window to control connecting A spreadsheet of local gateways containing frequency and other parameters Now with the UDR 56K on the network I just open a browser window and point to the IP Address. The email client is on another tab. It's neomail, a free webmail program but you could configure your regular email client to handle things. The lower left frame is the control console. It's shell in a box and has sshed into the UDR. On shipping software, this will default to display only, but you can enable it in preferences and drive everything from the command line. The right frame is also shell in a box running ax25spy. I love this feature. When I run airmail I can see the process but I can't see any other packet traffic. This way I get both at the same time. Think of it as a debug window. And finally the upper left has a table which contains my local gateway info. The difference here is that it actually controls the radio, so all I have to do is click on a gateway and the frequency switching and connection is automatic. I can even check one or more gateways and have the system auto-connect to each of them in succesion. You can export/import the table in csv format. Lots more to come in the months ahead including multi-user login support. Bryan
|
|