[pskmail] Re: server install
- From: "karel Fassotte" <karel.fassotte@xxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Wed, 20 Dec 2006 12:24:09 -0500
Thanks Rein for the answer, hello all.
I am not directly refering to the PSK64 and PSK125 but more likely to
the 188-110a/b or a similar OFDM protocoll. The PSK modes are to slow
your right.
The Q15X25 protocoll seemed very promissing to use IP traffic via
AX25, slow but for some use effective (text based browse,
interactive!) but we found that the Q15X25 for the kernell development
stopped and a proporly working Linux version we did not find. Does
anybody know more about it??
IP traffic via 188-110a/b would be very attractive for us, as it would
be an alternative to satelite IP in remote regions. Operational costs
are a real concern as they go up to 2000USD for a 64kbs connectivity.
This makes it realy prohibitive.
Yes your right we should not lose the principal scope of the project,
however only textbased email is nut sufficient for us.
What about the mobiles? We have gathered already a lot of information
about mobile HF radio. The trick lays in the mobile antenna design. We
found out that the signal to noise could be improved using specialy
designed antenna systems. These antennas are horizontal endfed
antennas and not vertical whips as many use. This is off cource is
only truth if you want mobile NVIS communications, not realy more the
1000km. We could maintain for hours voice and packet connectivity on
the move. The trick here is that you need several geografical spaced
HF radio gateways, using ALE to improve link performance. Also without
the use of several fixed base stations we could maintain a link of
realy good quality. Signal levels of more that 25dB could be obtained
on both sides. Carefull design and tuning of the antenna is important.
Because lower frequencies are used for NVIS, the antenna should have a
coil in the top of the antenna instead of in the base of middle of the
antenna. This makes the radiation performance much better, the biggest
current should be located in the center, end of the antenna, not at
the feed point!. We used a whip antenna on the center of the pickup
car, bended backwards and coupled a coil to the top of the antenna,
the coil simply vertical mounted to use it also as a way to fix the
antenna in position.
Greetings Karel
HC1AKP
2006/12/20, Rein Couperus PA0R <rein@xxxxxxxxxxxx>:
On Tue, 2006-12-19 at 06:30 -0500, karel Fassotte wrote:
> yes Ralph and all, the suggestion to switch between, PSK64, PSK125 and
> faster modes like the 188-110a/b modems would be very attractive.
> I also suggest to integrate an IP interface to have a slow IP access
> to the internet.
Hi Karel & all¸
With the next version of pskmail you can manually switch between PSK63
and PSK125 during a connection. This feature is experimental, and I am
thinking about a way to do it automatically.
With regard to the IP interface the following:
* What exactly do you mean by 'IP interface' ? Interface between what?
* If you mean a socket with a transparent connection to the internet the
following issues need some thinking:
Speed
=====
In 1200 Bd packet radio the tcp/ip solution does not really work well.
That solution was to transport ip packets via a slow, overhead-prone
ax25 system.
That solution adds considerable overhead to the already ineffective
packet delivery system based on am addressing/routing system that used
ham radio calls (including the possibility to include up to 6
digipeaters in the heading). On 56k systems this is ok, although VERY
ineffective.
Pskmail does not use 1200 Bd but 125 Bd (PSK125). A factor of 10 less.
Timing
======
The timing requirements differ tremendously between TCP/IP and Pskmail.
With IP you are talking milliseconds, Pskmail uses seconds. A factor of
1000. This is the main reason for using agents (or gateways) in the
server to interface pskmail with the IP world. These agents look like an
IP socket to the internet, and like pskmail protocol to the air
interface. They decouple two vastly different worlds.
The trick is to strip as much overhead as possible, leaving maximum
bandwidth for the application. This also means that you want a connected
system, where address/routing information is handled once per
connection, not as part of every packet sent. This again implies a 1:1
relationship between client and server.
Be specific, not universal
==========================
Every application has its own characteristics, and in order to use the
scarce resources of pskmail we will have to optimize communication for a
specific application.
This means we have to settle for a finite list of applications for
pskmail. The socket approach would be much easier to implement, but it
will not work.
So one exercise will be to fix the application scope of pskmail.
Do you need telnet? Ftp? What are the priorities? What should an
application look like to the user? What should it accomplish?
One example is the email facility in pskmail. The user interface is
'evolution', which every operator is familiar with. Still, evolution
would not work with a universal socket in pskmail, it would simply time
out.
The constraint is the bandwidth. Pskmail is conceived as a QRP system
for mobile clients, so the less bandwidth the better.
something to think about over Xmas?
73,
Rein PA0R
Other related posts:
