BBS inefficiency -vs- PACSAT protocol
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 packet.
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 protocol:
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.
Bob, WB4APR
participants (1)
-
Robert Bruninga