| |
ZL3AI > APRDIG 22.09.06 22:35l 229 Lines 11051 Bytes #999 (0) @ WW
BID : 8807-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 27 #21, 3/4
Path: DB0FHN<DB0MRW<DB0FSG<I4UKI<IK1ZNW<I0TVL<TU5EX<IW2OAZ<ZL2BAU
Sent: 060922/2026Z @:ZL2BAU.#87.NZL.OC #:5836 [Waimate] $:8807-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 25
Date: Wed, 20 Sep 2006 09:52:57 +0100
From: "Dave Baxter" <dave_at_emv.co.uk>
Subject: RE: [aprssig] Rant - Cross platform portability
Hi...
I'm more than aware of what can and does get done in a PC (or anything
else) that does audio/soundcard based DSP, yes, the A/D conversion needs to
be done on a timely basis, and yes the "processing" can be batched behind
the scenes.
However..... Of the Ham population, who actually program anything
significant, what percentage of them have the skill's to do that on any
platform/language combination. Of them, who has the spare time and
inclination to learn something totally different, if they don't "need
to"... I suspect a small fraction of 0.1% Good on them though, go roll
with it...
As to Java's IO control, well, it's already been said. Sun's dropping of
native java support for COM port, at about the time of the rise of USB
strangely is a pain. Utilities like RXTX work, but again, there seem to be
several versions skulking about, and not all the new ones work with newer
Java app's. Then you're back in the usual mess, of how to get right down
to the metal as it were, across multiple platforms, so you can never have
true cross platform portability if you are going to use external IO.
As others have said, the main problem for the users, is getting it all
installed up and running, citing LimeWire as a good example of how it
should be done (regardless of what I think of the app itself, and some of
it's users!) It is certainly a "hands off" approach, and sorts out what it
needs, and goes and does it. Sadly, much ham (and an awful lot of
commercial stuff sadly) does not do that.
True SDR however, that's in truth (for a HF RX typically) a multi hundred
MHz A/D with a roofing filter (sometimes not even that, then aliasing
effects can be used to get VHF coverage too!) then ALL IF processing,
filter synthesis and demod etc, right down to baseband is done with DSP.
"True" SDR systems can therefore handle multiple signals and modulation
schemes simultaneously, within the capabilities of the number crunching
hardware involved.
The closest common ham application that can do something similar to that,
are some PSK31 systems, where you can demodulate more than one signal
simultaneously. But, that is done from a low frequency IF, audio in this
case.
The majority of the so ham so called SDR stuff currently about, is computer
controlled analogue RF/IF, down to for example 12kHz, then soundcard DSP.
That is not true SDR. Go look at what Amsat among others are doing in
respect of true SDR. I doubt much will be done in Java, but I could be
wrong. It would certainly be a good way to go for the User Interface part,
but I doubt for the embedded code.
It's not beyond imagination, to have one box that could do just about
everything. PSK31, WJST, CW, APRS as well as "normal" voice comm's, all
running together on the same hardware. Transmitting on one HF band, while
doing that Receiving on another though, is still as much a challenge as it
always was, but numerically not impossible. I guess the closest we have to
that at the moment, on VHF at least is DSTAR, but at a cost.
I'm sure Java will improve over time, but it has a way long way to go yet,
for true "all hardware platform" portability that some may claim it has
now..
Cheers All..
Dave G0WBX
>-----Original Message-----
>From: Gregg Wonderly [mailto:gregg_at_wonderly.org]
>Sent: Tuesday, September 19, 2006 3:53 PM
>To: TAPR APRS Mailing List
>Subject: Re: [aprssig] Rant - Cross platform portability
>
>Dave Baxter wrote:
>>It also is not "real time" critical as DSP code would be,
>and does not
>>need any specific hardware IO, like to control a rig etc.
>It's purely
>>web based.
>
>DSP processing of an AUDIO stream does not have to be done in
>real time. The audio stream needs to be collected without
>loss, and the audio hardware, buffers and OS drivers do this
>for you on PC class computers. You can then just process
>that stream using time sharing software systems. Look at the
>SDR-1000. It is software defined radio which is using
>windows for control of the RF deck. The RF deck converts the
>RF that you are tuned to, into a 44khz wide audio stream
>through frequency conversion. That goes into a high quality
>audio card to miminize loss and maximize performance. But,
>then everything you hear and everything you transmit is
>processed by a non-real time OS environment.
>
>>Of course, if we start to see 10/100 network ports on
>radio's (as much
>>"High End" test RF equipment from the likes of Agilent and R&S is
>>beginning to sport) that would make things a lot easier to do with
>>Java.
>
>Java is not just restricted to network communications. There
>are various APIs for doing serial and parallel port
>communications as has already been brought up in this
>discussion. What was at issue in the previous discussion,
>was the the "free" version for windows that Sun had on their
>web site disappeared. It can still be distributed by those
>who have it. Or, the RXTX project can be used, as can the
>commercial packages.
>
>Gregg Wonderly
------------------------------
Message: 26
Date: Wed, 20 Sep 2006 17:20:04 +0200
From: Gregg Wonderly <gregg_at_wonderly.org>
Subject: Re: [aprssig] Rant - Cross platform portability
Dave Baxter wrote:
>However..... Of the Ham population, who actually program anything
>significant, what percentage of them have the skill's to do that on any
>platform/language combination. Of them, who has the spare time and
>inclination to learn something totally different, if they don't "need
>to"... I suspect a small fraction of 0.1% Good on them though, go roll
>with it...
Dave, this is a good and valid point. Someone with the right knowledge and
background needs to do this work right. My point is that if one person
would do this one time, then everyone could use it everywhere Java runs
with the utilized platform (J2SE vs J2ME for example has some different
capabilities to consider).
>As to Java's IO control, well, it's already been said. Sun's dropping
>of native java support for COM port, at about the time of the rise of
>USB strangely is a pain. Utilities like RXTX work, but again, there
>seem to be several versions skulking about, and not all the new ones
>work with newer Java app's. Then you're back in the usual mess, of how
>to get right down to the metal as it were, across multiple platforms, so
>you can never have true cross platform portability if you are going to
>use external IO.
I understand that this seems bad. But, the point is, that the javax.comm
API design is a fixed thing. You can code to it, and have portability to
all implementations of that API. Sun chose to make that an optional API
rather than an included API. Not sure why, but that's what happened way
back when. So, the developer just needs to find the appropriate
implementation to ship with their application for everyone to use. The SUN
version can be shipped with applications. All of them have native code
libraries that need to be installed correctly etc. That's a little more
labor for the developer to work into their installation task, but not
insurmountable.
>As others have said, the main problem for the users, is getting it all
>installed up and running, citing LimeWire as a good example of how it
>should be done (regardless of what I think of the app itself, and some
>of it's users!) It is certainly a "hands off" approach, and sorts out
>what it needs, and goes and does it. Sadly, much ham (and an awful lot
>of commercial stuff sadly) does not do that.
Yep, many people doing software development in the HAM community don't have
enough training or information, or motivation to get it right. That's a
real problem for many people. Some argue that HAMs ought to be smart
enough to figure it out. I think it's important to not waste unneeded time
in peoples lives just because you can.
>The majority of the so ham so called SDR stuff currently about, is
>computer controlled analogue RF/IF, down to for example 12kHz, then
>soundcard DSP. That is not true SDR. Go look at what Amsat among
>others are doing in respect of true SDR. I doubt much will be done in
>Java, but I could be wrong. It would certainly be a good way to go for
>the User Interface part, but I doubt for the embedded code.
The realtime aspects of audio capturing that are possible with the PC sound
cards, in conjuncting with buffering built into the audio subsystems at the
kernel level (because these are time sharing systems), allows a
non-realtime system to be used to do this audio processing. The visible
effect is a delay in audio caused by the computational time of the audio
processing pipeline. As I mentioned before, this is already visible in our
cellphones. We're learning to talk slower and respond with less
interjection :-)
Doing the audio processing in Java vs C vs C++ vs ASM code is only going to
result in a different latency (audio delay) between the arrival of the
audio and its output to the speakers for your perception (hearing).
The issue is, once it's done in Java, it can be more widely used than if
done in C or C++ or ASM targeted at a specific OS, library or processor
type.
>It's not beyond imagination, to have one box that could do just about
>everything. PSK31, WJST, CW, APRS as well as "normal" voice comm's, all
>running together on the same hardware. Transmitting on one HF band,
>while doing that Receiving on another though, is still as much a
>challenge as it always was, but numerically not impossible. I guess the
>closest we have to that at the moment, on VHF at least is DSTAR, but at
>a cost.
Yep, that's what I'm trying to make apparent. With a little bit of focused
effort, HAM radio could be in charge of the next generation of RF, instead
of all of us sitting around waiting for the manufacturers to decide what we
need. Building new, high class digital equipment with hardware is expensive
and time consuming. Doing it with software means that a lot more people
can take up where others leave off and further explore concepts without
everyone having to build some basic hardware to get to the starting point.
>I'm sure Java will improve over time, but it has a way long way to go
>yet, for true "all hardware platform" portability that some may claim it
>has now..
I think it's all a matter of perception. There's a lot of FUD going around
from 8 year old experiences. Java has come a long way from those early
days. It really can perform quite adequately. I used it for repeater
recording, echolink VOIP GSM codecs (http://javecho.dev.java.net),
enterprise class data processing (30+ database transactions/second) and a
wealth of other things related to satellite communications etc.
Again, I'm really interested in hearing about peoples bad experiences and
trying to understand where all of the negativity comes from.
Gregg Wonderly
------------------------------
Read previous mail | Read next mail
| |
