[pskmail] Ecuador's emergency network

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Mon, 31 Jan 2011 18:06:06 +1100

Karel,

Responding to your two previous emails:

1. Creating a new software modem (with out without specs) is not a
trivial exercise. It could easily be several man-weeks and more likely
man-months to get is coded, tested, optimized and debugged.

2. Producing a derivative of an existing modem like I did when I
developed the robust version of PSK for the Pskmail application can
limit the effort to several man-weeks but I don't see it being below
that.

3. Integrating the Winmor TNC with Pskmail would work for Windows and
would require a fair amount of work (man weeks), but would not be a
trivial affair at all for Linux (read complicated and most likely not
reliable in my opinion).

4. To take full benefit of the speed of fast modems Pskmail would
need to be optimized for that purpose. This would be in the order of a
few man-weeks (I would *guess* 2 to 6 man-weeks).

5. Just to make sure you don't interpret the previous points as a
selling speech, I personally don't have the time to do any of the
above. If you have to source such a capability, the typical "profile"
of persons developing such modem software is that of a DSP engineer
(although many others can be competent in the matter due to personal
interest such as you find in the HAM sphere).


The above should give you an idea of the efforts ahead for your
investigation, as you requested.

But at the end this is the beauty of open source: other people's
solutions are available as a starting point for new needs. This is
exactly what happened with the Intermar version of Pskmail, which is
focussed on Sailor's needs (see www.pskmail.eu) or with the
development o fthe PSK Robust modes in Fldigi.


6. I don't understand your comments about compression/decompression on
the fly. Pskmail does have compression and decompression on the fly.
This is totally transparent to the user. You must tick the "Compress
OTA" box in the preferences to enable it.

7. I agree with you the software modems have and will continue to gain
place vs hardware ones in the HAM community (I am not speaking about
commercial applications here).

8. Maybe you have or your group has done the simulation and/or field
trials and you may have a good handle on the priority of that speed
issue versus the rest, as in for example, topology of the network
(with/without internet, central server vs distributed, number of
parallel networks, routing, types of messages as in message/document
passing vs email passing vs web pages vs others), volume of messages,
expected time distribution of messages, maximum message latency
acceptable, robustness in regards to installation of the applications
on various PC brands and with different hardware capabilities, ease of
field usage, training requirements, effectiveness versus (and
integration with) voice networks during different grades of
emergencies, etc... but that is not visible to us.

So in my opinion, and based on what I consider limited information
supplied, I would seriously weight how much that speed issue is
important versus your other criteria.

I am totally convinced that the success of the deployment and the
continued use of such a system on such a scale will most likely be
related to a number of criteria, which all need to be addressed,
rather than a single issue of *raw data speed*. Therefore I really
feel that if development time is spent it would need to be across a
number of points, not just raw data speed, to make the application a
good fit for your situation.


Hope this helps,

Regards,

John (VK2ETA)


On Mon, Jan 31, 2011 at 1:36 PM, karel Fassotte
<karel.fassotte@xxxxxxxxx> wrote:
> Larry first it will not be my money. If so I woud like to see some benfits.
> In this case it will be no commercial project I am working on.
> Thanks Larry for being so direct about the money and my mouth.
> I think its not oanly the resources the economics, that make it feasinable
> or not. Yu must see the need for it. If PSKMAIL is fast enough for the users
> now, there will be no motivation to get to a more rapid speedy modem.
> The pactor III modems can do the job also, but that makes the burden much
> higher for the amateurs. Another hardware another modem.
> I think sound cards got so sofisiticated the software solutions will gain
> terrain.
> Larry
> I am not sitting back but I am investigating possibilities. If we can get
> the picture complete we can see what we can do.
> If were are talking about money how much would it cost to bind the different
> advanced modems to the PSKmail??
> F.I. the WINMOR, OFDM/PSK specifications are well documented, also the
> 188-110 modems are documented and some software sourcecode is available.
> What woud be a reasonable timeline?
> Larry and others now its your turn, inviting you to get the clear picture.
> greetings
> Karel
> HC1AKP
>
> 2011/1/30 Larry Levesque <ka1vgm@xxxxxxxxx>
>>
>> On Sun, Jan 30, 2011 at 05:40:53PM -0500, karel Fassotte wrote:
>> > Needs: a message 1KB, 2KB, shoud be handled in 1 minute, to maintain
>> > channel
>> > capacity.
>> >
>> > I wish PSKMAIL to integrate a faster modem, like WINMOR capable of
>> > handling
>> > a message in 1 minute. Simple and fast.
>> >
>> > I am aware of the fact that I a not in the position to urge a solution,
>> > but
>> > however I would like to discuss possiblities to get it done. The authors
>> > of
>> > FLDIGI, tell me that they have no plans doing so but.... I would like
>> > FLDIGI, PSKMAIL be the solutions for reasons of open source,
>> > multiplatform.
>> >
>> > Please let me know all what you think about my proposal and the
>> > possiblities
>> > to have it done.
>> > I woud like to stop dreaming and get the networks running.
>> >
>> > greetings
>> > Karel
>> > HC1AKP
>> >
>> >
>> >
>> >
>>
>>
>> I say you need to find and pay a programmer to do this. If you are not
>> willing to put your money where your mouth is, just sit back and wait.
>>
>>
>>
>>
>> --
>> Larry Levesque
>> KA1VGM
>>
>>
>
>

Other related posts: