56k modems' upstream speeds were limited to 33.6kbps due to analog-to-digital conversion at the phone company. However, downloads could reach 56kbps because they leveraged a mostly-digital path from the telco's server to the user's modem. This asymmetry existed because the phone company's infrastructure used digital signals internally, even for analog phone calls. The digital audio was converted to analog only at the last mile, at the user's local central office. This meant a 56k modem downloading data was essentially receiving a slightly-modified digital signal, bypassing much of the analog conversion process and thus achieving higher throughput. Uploads, originating from the analog modem, had to be fully digitized at the central office, resulting in the lower speed.
Ggwave is a small, cross-platform C library designed for transmitting data over sound using short, data-encoded tones. It focuses on simplicity and efficiency, supporting various payload formats including text, binary data, and URLs. The library provides functionalities for both sending and receiving, using a frequency-shift keying (FSK) modulation scheme. It features adjustable parameters like volume, data rate, and error correction level, allowing optimization for different environments and use-cases. Ggwave is designed to be easily integrated into other projects due to its small size and minimal dependencies, making it suitable for applications like device pairing, configuration sharing, or proximity-based data transfer.
HN commenters generally praise ggwave's simplicity and small size, finding it impressive and potentially useful for various applications like IoT device setup or offline data transfer. Some appreciated the clear documentation and examples. Several users discuss potential use cases, including sneaker authentication, sharing WiFi credentials, and transferring small files between devices. Concerns were raised about real-world robustness and susceptibility to noise, with some suggesting potential improvements like forward error correction. Comparisons were made to similar technologies, mentioning limitations of existing sonic data transfer methods. A few comments delve into technical aspects, like frequency selection and modulation techniques, with one commenter highlighting the choice of Goertzel algorithm for decoding.
Summary of Comments ( 95 )
https://news.ycombinator.com/item?id=43282668
Several Hacker News commenters pointed out that the article's title is misleading. They clarified that 56k modems didn't rely on digital phone lines in the way the title implies. Instead, they exploited the fact that the trunk lines between central offices were digital, while the "last mile" to the user's home remained analog. This allowed the modem to receive data digitally at the CO's end and convert it to analog for the final leg, maximizing the speed within the constraints of the analog local loop. Some users also shared anecdotal memories of early modem technology and discussed the limitations imposed by analog lines. One commenter noted the importance of echo cancellation in achieving these higher speeds. A few commenters discussed related topics like the technical reasons behind the asymmetry of upload and download speeds and the different standards used for upstream communication.
The Hacker News post "56k modems relied on digital trunk lines" has generated a moderate number of comments, mostly focusing on clarifying technical details and sharing personal anecdotes related to dial-up modem technology.
Several commenters delve into the specifics of how PCM (Pulse Code Modulation) encoding is used in the phone system and how this relates to the asymmetric speeds of 56k modems. They explain that the upload speed was limited by the analog-to-digital conversion process at the user's end, while the download speed could take advantage of the digital signal already present in the trunk lines. This discussion includes nuances like the use of µ-law and A-law companding in different regions, affecting the achievable bitrates.
Some comments offer corrections or expansions on the original article's points. For example, one commenter clarifies that not all calls were digitized end-to-end, especially for international calls, and that the digital sections were typically within the telco's network rather than extending all the way to the user's home. Another points out the role of echo cancellation in enabling full-duplex communication. There's also discussion about the limitations imposed by regulations on the maximum power output of modems, a factor that contributed to the speed cap of 56k.
A few comments offer personal recollections of working with or experiencing dial-up technology. These anecdotes add a human element to the technical discussion, highlighting the frustrations and limitations of the technology, such as the susceptibility to noise and the difficulty of achieving the theoretical maximum speed. One user even recalls the specific model of modem they used.
A couple of comments touch on related topics like the use of ISDN and the evolution of DSL technology. While these are not central to the main discussion, they provide additional context about the broader landscape of data communication technologies during that era.
While there isn't one single "most compelling" comment, the collection of comments provides a valuable supplement to the original article, offering greater technical depth and personal perspectives on the intricacies of 56k modem technology.