>> It is extremely inefficient to attempt to logon
>> to [the ISS] BBS over Europe/USA since it blocks
>> other users from the more efficient digipeater
>> mode designed for those high density areas.
> This Apples and Oranges comparison. There is a huge
> difference between a Store-And-Forward Mail box and an
> Unacknowledged Broadcast packet. With an Unproto
> Packet you never know if anyone heard your one-way
Ah, but you do. You see it in the downlink. Congestion on the
ISS packet system is only on the uplink. Rarely if ever on the
downlink. If you see it in the downlink, then everyone else and
the recepient should have seen it too... Very efficient without
needing ACKS and RETRIES and CONNECTIONS, and CONNECT REQUESTS,
and TIMEOUTS, and REJECT packets..
> Store-And-Forward packet mail has a whole different
> set of uses. We used Packet Mail on Space Station Mir
> for 10+ years....
Yes, but back then the crew had no other alternative for email.
Now they have easy email 24/7. But I agree, it "works" fine,
but one has to be careful how we define "works". Over the USA
or Europe, it only works for one user and only if that user has
killowatts of ERP to step on all other packets to complete his
connection (or lives in Hawaii, or other island nation
surrounded by no other users within 1200 miles).
> The ISS Packet Mail project never caught on
> because we had Hardware and software problems
> with the TNC's and we never were assigned
> a dedicated Laptop. ... The current system can
> only support 1 mail box user at a time.
But even with only one, in a congestion environment and the
requirement for ACKS of every line received, the success rate
for the average user is so low and frustration level so high,
that it is impractical for the common user and all the lost
packets and retries consume the entire pass at the expense of
everyone else on frequency.
> Marex has received initial approval to upgrade the
> system to a Kantronics System that will support 5+
> mail box users and also includes full remote control
> from ground System Operators.
A worthy goal, but that will only multiply the existing
impracticality by a factor of 5 in QRM and virtually nothing
will get through (unless there is a drastic change to the
protocol). That is why ALL flying BBS's since the mid 1980's
use the PACSAT protocol which avoids all of the congestion
issues of the normal AX.25 CONNECTED style BBS. The PACSAT
1) Continuously streams the MAIL List.
2) Allows everyone to capture the MAIL list passively without
having to transmit a single packet.
3) Everyones software captures every line from every file on the
BBS and builds its own copy of the files. (still passively
without transmitting a single packet).
4) As needed stations can requist "fills" of missing lines.
Still all other stations also capture these "fills" to minimize
the number of requests and repeats.
5) Ground software automatically manages the access to avoid
user congestion on the uplink and software contributes to equal
sharing of the BBS.
6) Discourteous users can not easily hog the asset.
The result was the PACSAT protocol that allowed multiple
accesses, by dozens of stations able to download megabytes per
day and was efficient, and completely avoided all the ACK
problems of terrestrial BBS's when flown in space. Every
digital satellite since AO16 has used the PACSAT protocol for
their store-and-forward BBS's: AO16, LO18, KO23, KO25, IO26,
UO22, GO32, AO51 and others. There are very good, published and
well thought our reasons for this.
> If you would like to see a multiple user Mail box
> on ISS please help support Marex, it's a
> long road into space. My next hardware demo is
> scheduled for Moscow in June 2008.
This sounds like a great project, but only if such a multi-user
BBS will take advantage of the lessons learned for more than 20
years in Amateur Space and avoid any BBS that requires
line-by-line acknowledgment. If they can implement the
multi-user scheme as used on the PACSATS for the last 20 years,
then that will be a great advantage to users by at least an
order of magnitude.