Build Your Own Dial-Up ISP – Now With Modem Pool!

May 30, 2020 by Lewin Day 54 Comments

When it was the only viable option, the screech and squeal of dial-up internet was an unwelcome headache to many. But now that its time has passed, it’s gained a certain nostalgia that endears it to the technophiles of today. [Doge Microsystems] is just one such person, who has gone all out to develop their very own dial-up ISP for multiple clients.

The retro network is based on an earlier single-device experiment, with a Raspberry Pi 3B acting as the dial-up server. It’s hooked up to four modems, three of which are connected over USB-serial adapters implementing hardware flow control.

Obviously, four analog phone lines are hard to come by in this day and age, so [Doge] uses Asterisk along with a series of Linksys SIP devices to create their own PBX network. Each modem gets a phone line, with four left over for clients to dial in.

To connect, users can either call a certain modem directly, or dial a special number which rings the whole pool. Thanks to mgetty, each modem is set up to answer on a different number of rings to allow the load to be shared. Once connected, a PPP daemon handles connecting the user to the Internet at large.

While it’s unlikely we’ll all be ringing [Doge]’s house to get our next YouTube fix, owning your own dial-up ISP is certainly an admirable feat. We’d love to see it deployed in the field sometime, perhaps at a hacker conference or Burning Man-type event. Of course, if you’ve got your own old-school network pumping data, be sure to let us know! Video after the break.

Continue reading “Build Your Own Dial-Up ISP – Now With Modem Pool!” →

Raspberry Pi 4 Gets Its 8 Gigs

May 28, 2020 by Mike Szczys 121 Comments

What began as a rumor becomes reality. This morning [Eben Upton] announced that the newest flavor of the Raspberry Pi 4 comes with 8 gigabytes of RAM and a sticker price of $75, roughly twice that of the base model which is now pegged at 2 GB of ram.

Originally released on June 23rd of last year, the Pi 4 came with three different options for 1, 2, or 4 GB of memory. But just a few days later, Hackaday reported on an Easter egg in the user guide that referenced an 8 GB option.

So why didn’t this version get released in 2019? That’s the crazy thing about this story. In the announcement [Eben] mentions that the Pi’s design is capable of addressing up to 16 GB of LPDDR4 SDRAM (we say bring it, but that’s a discussion for a different day). It took a year to get here because there wasn’t a source available for this 8 gig version until Micron began manufacturing the chip earlier this year.

Also addressed in this announcement is a looming changeover that was bound to happen eventually: the move from 32-bit to 64-bit operating systems on the Pi. While a 32-bit image can access all of this larger memory across multiple process, it can’t devote more than 3 GB to a single Linux process because of address space limitations. Simply put, you need more bits to access the higher addresses. Moving to a 64-bit system accomplishes that, something you can do by running unofficial builds on the Pi, but the official build didn’t support it until today’s announcement of a 64-bit beta image.

This is inevitable, not purely because of this memory limitation, but because we’ve seen examples where the juggernaut of Linux development has its own eye on a 64-bit future. Official images for Raspberry Pi have always been 32-bits, and remain so for now, but the wind is beginning to blow for this and future hardware offerings that are bumping up against limitations. Along with the news of this impending architecture switch over, the official operating system has also gotten a name change: Raspbian will henceforth be known as Raspberry Pi OS.

When [Jenny List] first reported on the 8 GB rumors last June, she speculated that today’s announcement would happen on February 29th of this year. Why the leap day? It happened to be the 8th birthday of Raspberry Pi and synced up nicely with an 8 GB surprise. Today’s announcement drops the morsel of trivia that the foundation was indeed planning on that date, but missed it by three months due to supply chain disruption associated with the coronavirus pandemic that prevented them from sourcing all the parts necessary for the new power supply design included in this revision.

We’d love to hear your thoughts on this move. Do you need 8 GB on your Pi, and does the 3 GB limitation of a 32-bit kernel matter to you? Let us know in the comments below.

Ewon Is An Expressive Robot With Google Assistant

May 26, 2020 by Al Williams 2 Comments

Had too much self-quarantine? [Sharathnaik] had, so he decided to build a robot companion named Ewon. Using a Raspberry Pi, Ewon isn’t a robot that moves around, but rather an expressive Google assistant. Using some servo-driven ears and a display, Ewon reacts to you based on keywords you use in your queries. For example, it might perk up and smile at the mention of ice cream. Or look unhappy if you mention sadness.

The project is simple because of the Google Assistant API. However, we liked the 3D printed body and some of the additional features the robot adds.

Continue reading “Ewon Is An Expressive Robot With Google Assistant” →

Boot Your Pi Over USB

May 25, 2020 by Al Williams 50 Comments

Historically, booting a Raspberry Pi required an SD card. However, if you follow [tynick’s] instructions, you can get a Pi 4 to boot from the USB port. Combine it with a small solid state disk drive, and you’ll get great performance, according to his post.

The caveat is this depends on a beta bootloader and, of course, you’ll still have to boot from an SD card at least once to load that bootloader. If you were deploying something serious, you’d probably want to make sure the bootloader is suitable for your needs.

Continue reading “Boot Your Pi Over USB” →

ZRAM Boosts Raspberry Pi Performance

May 20, 2020 by Al Williams 18 Comments

Linux is a two-edged sword. On the one hand, there’s so much you can configure. On the other hand, there’s so much you can configure. It is sometimes hard to know just what you should do to get the best performance, especially on a small platform like the Raspberry Pi. [Hayden James] has a suggestion: enable ZRAM and tweak the kernel to match.

Although the post focuses on the Raspberry Pi 4, it applies to any Linux system that has limited memory including older Pi boards. The idea is to use a portion of main memory as a swap file. At first, that might seem like a waste since you could use that memory to, you know, actually run programs. However, the swap devices are compressed, so you get more swap space and transfers from these compressed swap devices and main memory are lightning-fast compared to a hard drive or solid state disk drive.

Continue reading “ZRAM Boosts Raspberry Pi Performance” →

Alexa, Shoot Me Some Chocolate

May 11, 2020 by Kristina Panos 10 Comments

[Harrison] has been busy finding the sweeter side of quarantine by building a voice-controlled, face-tracking M&M launcher. Not only does this carefully-designed candy launcher have control over the angle, direction, and velocity of its ammunition, it also locates and locks on to targets by itself.

Here comes the science: [Harrison] tricked Alexa into thinking the Raspberry Pi inside the machine is a smart TV named [Chocolate]. He just tells an Echo to increase the volume by however many candy-colored projectiles he wants launched at his face. Simply knowing the secret language isn’t enough, though. Thanks to a little face-based security, you pretty much have to be [Harrison] or his doppelgänger to get any candy.

The Pi takes a picture, looks for faces, and rotates the turret base in that direction using three servos driven by Arduino Nanos. Then the Pi does facial landmark detection to find the target’s mouth hole before calculating the perfect parabola and firing. As [Harrison] notes in the excellent build video below, this machine uses a flywheel driven by a DC motor instead of being spring-loaded. M&Ms travel a short distance from the chute and hit a flexible, spinning disc that flings them like a pitching machine.

We would understand if you didn’t want your face involved in a build with Alexa. It’s okay — you can still have a voice-controlled candy cannon.

Continue reading “Alexa, Shoot Me Some Chocolate” →

A More Open Raspberry Pi Camera Stack With Libcamera

May 11, 2020 by Roger Cheng 15 Comments

As open as the Raspberry Pi Foundation has been about their beloved products, they would be the first to admit there’s always more work to be done: Getting a Pi up and running still requires many closed proprietary components. But the foundation works to chip away at it bit by bit, and one of the latest steps is the release of a camera stack built on libcamera.

Most Linux applications interact with the camera via V4L2 or a similar API. These established interfaces were designed back when camera control was limited and consisted of a few simple hardware settings. Today we have far more sophisticated computational techniques for digital photography and video. Algorithms have outgrown dedicated hardware, transforming into software modules that take advantage of CPU and/or GPU processing. In practice, this trend meant bigger and bigger opaque monolithic pieces of proprietary code. Every one a mix of “secret sauce” algorithms commingling with common overhead code wastefully duplicated for each new blob.

We expect camera makers will continue to devise proprietary specialties as they seek a competitive advantage. Fortunately, some of them see benefit in an open-source framework to help break up those monoliths into more manageable pieces, letting them focus on just their own specialized parts. Leveraging something like libcamera for the remainder can reduce their software development workload, leading to faster time to market, lower support cost, and associated benefits to the bottom line that motivates adoption by corporations.

But like every new interface design borne of a grandiose vision, there’s a chicken-and-egg problem. Application developers won’t consume it if there’s no hardware, and hardware manufacturers won’t implement it if no applications use it. For the consumer side, libcamera has modules to interop with V4L2 and other popular interfaces. For the hardware side, it would be useful to have a company with wide reach who believes it is useful to open what they can and isolate the pieces they can’t. This is where the Raspberry Pi foundation found a fit.

The initial release doesn’t support their new High-Quality Camera Module though that is promised soon. In the short term, there is still a lot of work to be done, but we are excited about the long term possibilities. If libcamera can indeed lower the barrier to entry, it would encourage innovation and expanding the set of cameras beyond the officially supported list. We certainly have no shortage of offbeat camera sensor ideas around here, from a 1-kilopixel camera sensor to a decapped DRAM chip.

[via Hackster.io]