[pskmail] Re: FW: FW: Re: Fldigi

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Mon, 9 Apr 2012 09:46:05 +1000

I think this is an interesting thread and a question worth posing.

As always, it is a question of choices since resources are not infinite.

If we step back, and look at the direction taken by Pskmail over the past
few years, one of its key objectives has been interoperability.

And today I believe I can safely say that we have the only NO external
hardware solution that runs clients across four major platforms, namely
Linux, Apple OS X, Windows and Android.

They are all interoperable AND none of them mandates an external hardware.
I have had full Pskmail sessions using only my phone and my rig by using
audio coupling.

The key drivers of this success in my opinion have been Open Source AND
hardware/OS abstraction. Even the Android version is reusing a significant
amount of the PC version's code.

At the other hand of the scale from this level of abstraction is a more
hardware, OS specific solution like the boxes you mentioned above. These
are attractive and often very well designed platforms and I did consider at
one point developing Pskmail for the Nue Psk platform.

Here is my take on the pluses and minuses of the abstraction approach:

++ re-usability of code across platforms AND time (hardware chips go
obsolete regularly and box platforms tend to be rather short lived).

++ cost reduction as we leverage massive volumes of production versus a
very narrow user base. Example is now an Android telephone can be bought
for less than $70 and run Pskmail in full, including all the modes we have
in the list.

- poor cpu utilization since all the abstraction levels induce overheads

-- variability of hardware introduces constraints and reduces performance.

On the common platforms (Intel based PCs, Android phones etc...) there is a
fast trend of cost down AND cpu power increase at the same time, meaning
that the available abstract platforms are getting cheaper and cheaper
'while NET available CPU power (after abstractions) is increasing.

The price we "pay" for this is poorer peak performance. Although an Intel
processor for example is more than powerful enough for the processing we
need (as a reference the I7 is producing 128K MIPS versus less than 7K MIPS
for a quad core DSP used in one of the "latest hardware modem",
instructions efficiency aside), the variability of the chain from sound
card to hardware driver to o/s to final program creates constraints that
restrict the data rates we can practically reach over noisy channels.

Top performance is possible but with a limited set of hardware available on
these common platforms.

But also let's be honest, we do not have anywhere near the software design
capability when compared with these commercial solutions. It is a hobby
after all and it is supposed to be fun.

And higher data speed can be fun I agree, hence the recent developments in
that area.

But an interesting point though: I have spent a fair bit of time developing
faster modes reaching up to 1760 WPM @ 2400Hz bandwidth, with FEC (or
3200WPM without), but I haven't had ANY feedback on the faster modes for
the HF Ham bands.

I had excellent, quality feedback for the targeted FM modes or MARS
channels on the other hand.

This is telling me that the need for higher data rates on HF HAM bands must
not be that critical otherwise I would have received more feedback,
positive or negative.

So in summary here is my view: since we only have part time development
capabilities, I have chosen to spend my development time using the most
widely available open hardware and software platforms I could access. I
will continue for a while to work on higher speeds, but in the context of
these open platforms.

I believe that this is the most effective way I can help the most people
use that solution.
Of course any proposed addition of resources for developing hardware or
other software solutions would be welcomed.

All the best,

73, John (VK2ETA)


On 09/04/2012 6:16 AM, "Jack Chomley" <radio@xxxxxxxxxxxx> wrote:

Other related posts: