Date   
Re: Interface Screen Shot

"k7udr" <bhhoyer@...>
 

The screen shot is in Files

--- In UniversalDigitalRadio@..., "k7udr" <bhhoyer@...> wrote:

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

Re: Interface Screen Shot

Tyler Griffiths <tyler.griffiths@...>
 

I see no pictures...


On Thu, Jun 7, 2012 at 4:50 PM, k7udr <bhhoyer@...> wrote:
 

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




--
Tyler Griffiths
N7UWX

See where I am:
http://map.findu.com/n7uwx-12

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.

--- In UniversalDigitalRadio@..., "k7udr" <bhhoyer@...> wrote:

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

Re: Interface Screen Shot

"k7udr" <bhhoyer@...>
 

Look in Files

--- In UniversalDigitalRadio@..., Tyler Griffiths <tyler.griffiths@...> wrote:

I see no pictures...

On Thu, Jun 7, 2012 at 4:50 PM, k7udr <bhhoyer@...> wrote:

**


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




--
Tyler Griffiths
N7UWX

See where I am:
http://map.findu.com/n7uwx-12

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 Conference

 
06/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

John Ronan <jpronans@...>
 

On 07/06/12 23:54, k7udr wrote:
The screen shot is in Files

Thanks for that.

John
EI7IG

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

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

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.

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
PO Box 1223, Edmonds, WA 98020-1223 
  



On Sat, Jun 9, 2012 at 4:04 PM, VK5ZEA <michaelcarey@...> wrote:
 

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

__._,_

Re: Processor architecture, gnuradio

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

In line.

On Sat, Jun 9, 2012 at 7:41 AM, Darren Long <darren.long@...> wrote:
 

Hi,

Can we get any ideas on what processor architecture,

Marvell PXA168
 

amount of RAM and


Currently 256 MB, may be 512 MB in production, depending on price curve for memory
 

internal storage the device will have, please.

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. 
 

Even the vaguest hints
are welcome at this stage. I'm wondering if gnuradio might find its way
in there somehow.

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.
 

Darren, G0HWW




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


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.

Bryan

On Jun 9, 2012, at 4:04 PM, VK5ZEA wrote:

 

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


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,

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

Check out the new YouTube Channel

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

NWDigtalRadio Video  -- Se Ham Radio Now interview of Bryan Hoyer.

And you can Subscribe to our Tweets... @NWDigitalRadio


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

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

Re: Processor architecture, gnuradio

Darren Long <darren.long@...>
 

Hi John,

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:
 

In line.

On Sat, Jun 9, 2012 at 7:41 AM, Darren Long <darren.long@...> wrote:
 

Hi,

Can we get any ideas on what processor architecture,

Marvell PXA168
 

amount of RAM and


Currently 256 MB, may be 512 MB in production, depending on price curve for memory
 

internal storage the device will have, please.

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. 
 

Even the vaguest hints
are welcome at this stage. I'm wondering if gnuradio might find its way
in there somehow.

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.
 

Darren, G0HWW




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

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.

Bryan

--- In UniversalDigitalRadio@..., Jerald A DeLong <kd4yal@...> wrote:

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

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 

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 
  

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
PO Box 1223, Edmonds, WA 98020-1223 
  

Re: Raspberry Pi D-STAR Gateway

Dennis Rogers <n5vrp.satx@...>
 

Where did you purchase the RaspberryPi in the USA?
Can you send me a link to the ordering site?

Thanks!

Dennis


On Tue, Jun 12, 2012 at 8:42 PM, John D. Hays <john@...> wrote:
 

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
PO Box 1223, Edmonds, WA 98020-1223 
  




--

Dennis, N5VRP
n5vrp.satx@...