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:
