[pskmail] Re: The hardware modem idea (sri, long rant)

  • From: Bernard Dekok <kc9sgv@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Mon, 30 Apr 2012 10:08:56 -0500

Very clear discussion of the hardware TNC question by Per.
I think the following is still pertinent to this thread.
The Winmor virtual TNC question.
It seems it still only runs on Windows and is probably not in the public
domain.

http://groups.yahoo.com/group/LinuxRMS/message/756

<http://groups.yahoo.com/group/LinuxRMS/message/756>KC9SGV


On Mon, Apr 30, 2012 at 8:45 AM, Bernard Dekok <kc9sgv@xxxxxxxxx> wrote:

> Hmmm,
> All links are dead now....?
>
> But Ken, AD5XJ, is one of the developers, it seems.
> Maybe he will divulge more info.
>
>
> On Mon, Apr 30, 2012 at 8:13 AM, Bernard Dekok <kc9sgv@xxxxxxxxx> wrote:
>
>> Hi Per,
>>
>> I have asked this question before, and the discussion was lost somehow:
>>
>> How about using the Winmor virtual TNC as one of the "modes" for PSKMail ?
>> Very stable and very fast.
>> The 1600 HZ version is allowed in the U.S. as long as the control
>> operator (sysop) is at home. (I.e. "attended operations".)
>>
>> It seems that Winmor is free open source and now available on Linux and
>> Mac OS as well.
>>
>> See the OpenMor Project:
>> http://openmor.sourceforge.net
>>
>> KC9SGV
>>
>> On Mon, Apr 30, 2012 at 5:41 AM, Per Crusefalk <per@xxxxxxxxxxxx> wrote:
>>
>>> Hi all,
>>>
>>> A hardware modem has been proposed by some here and so I started
>>> thinking about why we would want that. Using an external modem is of
>>> course the way we have connected computers to external communications
>>> for as long as I can remember but is that still the best way to go about
>>> it?
>>>
>>> The term hardware modem makes me think about a solid, dependable old
>>> tone encoder/decoder like a bell 103 modem. A very simple modem that did
>>> not have a cpu and very rarely caused any trouble. Todays modems are not
>>> like that, they are small computers. For instance the P4 Dragon was
>>> mentioned and it sports a Quad core DSP from Freescale weighing in at
>>> 6400 MIPS. That's a PC you can connect to your PC. As the cost is 1400
>>> euros its not a cheap pc either.
>>>
>>> But, I tried to see both sides of this and so I wrote two columns on a
>>> piece of paper. What are the benefits of using an external modem and
>>> what negative effects can I see?
>>>
>>> Positive effects:
>>> * System testing can be done more effectively when we better define the
>>> hardware that will be used, less surprises with unknown stuff.
>>>
>>> * If we create a custom modem we could have that do stuff without the
>>> pc, like position beacon transmission with a timer.
>>>
>>> * Some very capable modems allow very good transmission speeds.
>>>
>>> * PC requirements can be lowered as the processing is external
>>>
>>> * Radio interfacing standardized so that levels, rfi is possibly better
>>> controlled
>>>
>>> * The concept is known and easy to understand for beginners
>>>
>>> Negative effects:
>>> * There are no "hardware modems" that can handle the modes and the
>>> adaptive use of them we have today.
>>>
>>> * If we use a pactor modem then we will rely upon a proprietary modem
>>> that breaks many of the benefits we have now:
>>> - The android client becomes useless. Today we can work using only a
>>> radio and a phone/tablet. Using a phone, a pactor modem and a radio is
>>> not an improvement.
>>> - Very good narrow, robust modes for QRP stations gone.
>>> - Cost. 1400 euros can be better spent on other things.
>>> - Cost is also a huge barrier to entry for new users.
>>> - We become yet another system that relies on pactor. Other projects
>>> have done that for a long time so we will be many, many years behind
>>> their features.
>>> - I like open source and in the long run I think its likely that the
>>> remaining hardware modem firms will join the likes of AEA, Timewave,
>>> Kantronics e.t.c. and either completely disappear or stay around but
>>> slowly wither and become obsolete. Its hard to compete with free,
>>> especially if the free alternative is better.
>>>
>>> * Creating a custom modem that better supports our modes and needs is a
>>> big project in itself and will have an impact on project progress.
>>> - Support organization needed, production of these beasts??
>>>
>>> * Likely an extra hurdle slowing down waveform progress
>>>
>>> * An extra modem, power supply and cables takes a lot of extra space in
>>> my backpack.
>>>
>>>
>>> Summary:
>>>
>>> Why use an external modem when you still need to connect the PC to do
>>> anything with it? Why not let the PC to do the processing as it's
>>> already up and running? The cost is huge. It takes up extra space on my
>>> boat and requires power. Custom things like position beacon with timer
>>> can be handled just as well by the android client. The concept of using
>>> an external modem is tied to the old model of desktop computing. It does
>>> not translate very well to the modern world where a phone, a bluetooth
>>> interface and an FT-817 in the backpack can be all you need.
>>>
>>> At the moment we are having stability issues with our current choice of
>>> modem software (fldigi). It crashes once a day for me. Moving to a
>>> pactor modem will remove many of the benefits this system has today but
>>> a custom made modem could handle "our" modes. Moving to a custom made
>>> hardware modem that supports the modes we require is a process of
>>> developing a software that can use a dsp to decode and encode the
>>> waveforms we need. That is just what we already do with fldigi so the
>>> challenges are the same. We would need to get that custom modem very
>>> stable (which is exactly what we need with fldigi now).
>>> One idea could be to open a socket on the android client and use a phone
>>> or a tablet as your hardware modem...
>>>
>>> Conclusion:
>>>
>>> The negative effects of using an external modem far outweigh the
>>> positive.
>>>
>>> Sorry about the long rant here but this has been proposed several times
>>> so I needed to think and say a few words about this.
>>>
>>> 73 de Per, sm0rwo
>>>
>>>
>>>
>>>
>>
>

Other related posts: