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.
The TinyTen is a compact, highly portable, and experimental high-frequency (HF) transceiver built around a low-power DSP. It utilizes direct digital synthesis (DDS) for both transmit and receive, covering 160 through 10 meters, with a maximum output power of 1W. The design prioritizes simplicity and small size, featuring a minimalist user interface with a single rotary encoder and a small LCD display. It requires an external computer for initial configuration and incorporates readily available components for easier construction by amateur radio enthusiasts. Despite its experimental nature, the TinyTen aims to deliver a functional and portable HF experience.
Hacker News users discuss the TinyTen transceiver with interest, focusing on its impressive DSP capabilities and small size. Several commenters express admiration for the project's ingenuity and the author's clear explanations. Some discuss the trade-offs of DSP-based radios, noting potential performance limitations compared to traditional analog designs, particularly regarding dynamic range and strong signal handling. Others are curious about the specifics of its DSP implementation and the choice of components. A few share personal experiences with similar projects and offer suggestions for improvements or alternative approaches. The overall sentiment is positive, with many praising the project as a fascinating example of modern radio design.
WebFFT is a highly optimized JavaScript library for performing Fast Fourier Transforms (FFTs) in web browsers. It leverages SIMD (Single Instruction, Multiple Data) instructions and WebAssembly to achieve speeds significantly faster than other JavaScript FFT implementations, often rivaling native FFT libraries. Designed for real-time audio and video processing, it supports various FFT sizes and configurations, including real and complex FFTs, inverse FFTs, and window functions. The library prioritizes performance and ease of use, offering a simple API for integrating FFT calculations into web applications.
Hacker News users discussed WebFFT's performance claims, with some expressing skepticism about its "fastest" title. Several commenters pointed out that comparing FFT implementations requires careful consideration of various factors like input size, data type, and hardware. Others questioned the benchmark methodology and the lack of comparison against well-established libraries like FFTW. The discussion also touched upon WebAssembly's role in performance and the potential benefits of using SIMD instructions. Some users shared alternative FFT libraries and approaches, including GPU-accelerated solutions. A few commenters appreciated the project's educational value in demonstrating WebAssembly's capabilities.
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.