This is just a quick update regarding the downloads page that has been broken for the greater majority of this year. It's now fixed. Not that there's much there besides BaconCore, but still.
About a month back on my personal Twitter, I made a post about getting my own dial-up system going. I wanted to explain what it took to get everything working as there were quite a few people interested in this project.
My setup consisted of a 1993 Apple PowerBook 160 running System 7.1 (and later a 1998 PowerBook G3 "Wallstreet"), one Raspberry Pi to act as the dial-up server, one virtual machine running Issabel PBX (a CentOS-based Linux distribution intended as an easy-to-use PBX solution), two Grandstream HT701 ATAs, and a US Robotics Sportster 56k modem. And, of course, some phone cable.
The setup was pretty simple, starting out with Issabel PBX running on my desktop computer in VMware Workstation. Once installed, I logged into the web interface, set up two extensions for the two Grandstream HT701s, manually configured both the HT701s via their web interfaces, set up the Raspberry Pi with the US Robotics modem plugged into one HT701, and my PowerBook 160 plugged into the other. On the Raspberry Pi end, I set up minicom on /dev/ttyUSB0 where the modem was active on. On the PowerBook 160, I dialed the Raspberry Pi, and was met with some moderate success. Both devices were able to communicate, but something was very wrong as the handshake almost always failed, or if it did succeed, the connection would almost immediately disconnect. With the basic setup out of the way, it was time to delve a bit deeper and start the troubleshooting process.
The first thing that I thought could be an issue was jitter, or dropped packets. Although everything was running through my LAN, it could still theoretically be an issue. So, I spent several hours adjusting the jitter on Issabel with mixed results. Sometimes it seems like it'd work longer, sometimes it'd seem like it got worse. No matter what, it seemed like regardless of what I tried, jitter didn't appear to be an issue. However, to rule out the possibility of this being an issue down the road, I set up a very small jitter buffer. You want to keep your jitter buffer very small here as the bigger it is, the more latency you'll have.
The next thing I looked into is the codec being used. As we're using our VoIP system to send data through, we want to ensure that we're using something uncompressed and high-quality. However, after having a look at both Issabel and the Grandstream ATAs, both were set to use G.711 U-LAW which is the best codec to use in a situation like this. Again, I didn't see this as the problem and left it alone.
The next thing I decided to try was seeing if I could get any connection going at all by adjusting the link speed manually on the US Robotics modem connected to the Pi instead of letting it determine the speed on its own. At first I tried the absolute lowest it could go, 300 baud, and it still didn't work for some reason. However, upon trying 1200 baud, I finally got a stable connection going.
But still, that was only 1200 baud. I tried 2400 baud and was able to get it connected as well, but it was a lot less stable. The modems would have to retrain almost every few seconds, and the connection would often drop. I refused to believe that 1200 baud was the fastest that this setup could pull a connection at, but it was very late and I was tired, so I stopped working on it for the night.
I slept on it a bit and when I woke up, I thought about something and some friends on Twitter also pointed out exactly what I was thinking: echo cancellation. Most ATAs have some form of it enabled by default, and that could be what's wreaking havoc on the data connection. I got everything set back up, checked the Grandstream ATAs, and sure enough, echo cancellation was enabled on both. Disabled it, tried dialing again without manually specifying a speed, and... success. I brought out the PowerBook G3 which had a much faster modem than the 160 to really test out speeds. Everything was perfect now.
The last step I wanted to do now that all the pieces were together was making the Raspberry Pi automatically answer the calls and provide a terminal over this data connection. This was as simple as installing mgetty and configuring it to listen automatically on /dev/ttyUSB0. With that set, I tried it out one more time and... bingo, we had a real dial-up server.
There is more that can be done with this, such as setting up PPP to allow for direct Internet access through dial-up, but I haven't done this as of yet. If you are interested in getting to that point, there's a great write-up on Doge Microsystems that explains how to go about doing this.
There is also the possibility of doing something even crazier, such as connecting an ATA wirelessly, connecting it using a VPN tunnel at a different location... or both. Essentially, you could have your own dial-up system anywhere if you wanted to get to that point... and that may be a post for a later time.
The Deneb Kaitos main website has had a pretty significant theme refresh for 2020. As you can tell, there's a lot of dark colors and a very lovely shade of pink. This is known as the Sakura theme.
Originally I was thinking about what to do regarding introducing a dark mode theme to the Deneb Kaitos website, and for a while I really just wanted to keep the previous purple theme and make it work with dark mode. Ultimately though, the light pink on dark pink/gray is a color combination that works really well together. I've used a theme like this before with my previous Ultra desktop and I've always been fond of the way that it looked.
Some other design changes have been made, including condensing everything down a bit and straightening some things out that were overlooked back when the website was first brought online in 2017. You may also notice that the post titles are now ALL UPPERCASE. It just fits the overall theme of the website better.
On top of the theme refresh, I'm happy to announce that the Deneb Kaitos main website is now running on the new server and everything is (mostly) working as expected. The only issue is that the Downloads page isn't pretty looking due to an issue that's still being worked out and should hopefully be resolved soon. This server, like Satellaview, is spec'd better so things should generally run smoothly (though smoothness was never an issue with the old web server).
That's all for now. Enjoy the refresh and new servers! As a reminder, if you're a user of Performa, please make sure to migrate over to Satellaview as soon as possible to prevent any data loss.
Also please note that things may continue being a bit rocky over today and tomorrow as I finish up some tasks on this new server. Should any issues occur, it's likely I had to take the website back offline for an issue but it should come back up shortly.
The Deneb Kaitos website will be going down for maintenance & a design refresh starting on 2/13 and ending on 2/14. Satellaview and Performa will be available for use during this downtime and will not be affected by the maintenance.
The Deneb Kaitos server "Performa" will be replaced at the end of February by "Satellaview". This server is already active, and any users of Performa should be able to access it using their login credentials as normal. This is being done as Performa is running an old version of Debian, with LTS support ending later this year. The new server also bumps up the specifications a fair amount, so it should be faster to use.
If you have any important files on Performa, you will be responsible for transferring them over to Satellaview before it is shut down.
The server that runs the Deneb Kaitos website will be updated soon as well; stay tuned. A post will be made after the maintenance is scheduled.