Normal WiFi is not what you want to send video from your quadcopter back to the first-person-view (FPV) goggles strapped on your head, because it’s designed for 100% correct, two-way transmission of data between just two radios. Transmission of analog video signals, on the other hand, is lossy, one-way, and one-to-many, which is why the longer-range FPV flights all tend to use old-school analog video transmission.
When you’re near the edge of your radios’ range, you care much more about getting any image in a timely fashion than about getting the entire video sequence correctly after a delay. While WiFi is retransmitting packets and your video is buffering, your quadcopter is crashing, and you don’t need every video frame to be perfect in order to get an idea of how to save it. And finally, it’s just a lot easier to optimize both ends of a one-way transmission system than it is to build antennas that must receive and transmit symmetrically.
And that’s why [Befinitiv] wrote wifibroadcast: to give his WiFi FPV video system some of the virtues of analog broadcast.
Continue reading “Wifibroadcast Makes WiFi FPV Video More Like Analog”
Ethernet has been around since the mid-70s, but if you think it was always Cat5 and 10BaseT, you’d be sorely mistaken. The first ethernet was built with coaxial cable, vampire taps, AUI adapters, and a whole bunch of other network hardware that will make wizened networking veterans cringe. [Matt] had heard about these weird physical layers back when he started building networks in 1997, but he had never seen one. Now it’s an ancient and forgotten footnote in the history of computer networking. Is it possible to build a Thicknet in this modern era? It turns out, yes, it’s possible. It’s not easy, though.
The network [Matt] is building is a true 10Base5, or Thicknet, network. The backbone of this network is a coaxial cable 9.5mm in diameter. [Matt] discovered that while the common belief that Thicknet used RG-8/U cable. This appears to be incorrect, as the connectors for this cable – vampire taps that pierced the insulation and shield of the cable – are designed for cable manufactured by Belden, part number 9880.
[Matt] assembled the cable, vampire taps, AUI cables, and even found a few ISA NICs that would still work with a reasonably modern computer. He even went so far as to build a USB Ethernet adapter with an AUI interface. This impossibly retro device uses a standard USB to 10BaseT Ethernet adapter, with a chip designed to convert 10BaseT to AUI hacked onto a circuit board. That in itself is an incredible piece of engineering, with a handful of power supplies to get the correct 2.5, 3.3, 5, and 12 Volts to the right places.
As far as exercises in computing history go, [Matt] is at the top of his game. In the process of building it, he also figured out why no one uses Thicknet anymore; once it’s in place, you can’t change it, the cable is big, bulky, and the connectors are terrible. Still, it’s an amazing example of how far we’ve come.
[Alessandro] is an unlucky VoIP PBX administrator that frequently has to deal with very, very dumb network policies. Often times, he’ll have to change something on his setup which requires him to go out to his client’s location, or ask a client to use Teamviewer so the appropriate change can be made from behind a firewall.
This isn’t the solution to the problem. It will, however, fix the problem. To get around these firewalls, [Alessandro] is using the voice channels he already has access to for changing configurations on his VoIP boxes.
The implementation of this uses the AX.25 amateur radio modules that can be found in just about every Linux distro. This, and an Alsa loopback device, allows [Alessandro] to access a terminal over a voice-only network. Is it a hackey kludge? Yep. Is it just a little bit dumb? So are the network policies that don’t allow [Alessandro] to do his job.
This build isn’t too dissimilar than a bunch of modems from the old BBS days, albeit with vastly more powerful software. [Alessandro] says you’re only going to get about 38400bps out of this setup, but it beats begging for help for remote access.
If you’ve ever been to a capture the flag hacking competition (CTF), you’ve probably seen some steganography challenges. Steganography is the art of concealing data in plain sight. Tools including secret inks that are only visible under certain light have been used for this purpose in the past. A modern steganography challenge will typically require you to find a “flag” hidden within an image or file.
[Anfractuosus] came up with a method of hiding packets within a stream of network traffic. ‘Timeshifter’ encodes data as delays between packets. Depending on the length of the delay, each packet is interpreted as a one or zero.
To do this, a C program uses libnetfilter_queue to get access to packets. The user sets up a network rule using iptables, which forwards traffic to the Timeshifter program. This is then used to send and receive data.
All the code is provided, and it makes for a good example if you’ve ever wanted to play around with low-level networking on Linux. If you’re interested in steganography, or CTFs in general, check out this great resource.
If internet service providers go down, how are we going to get our devices to communicate? Project Byzantium aims to create an “ad-hoc wireless mesh networking for the zombie apocalypse.” It’s a live Linux distribution that makes it easy to join a secure mesh network.
[B1tsh1fter] has put together a set of hardware for running Byzantium on Pis in emergency situations. A Raspberry Pi 2 acts as a mesh node, using a powerful USB WiFi adapter for networking. Options are provided for backup power, including a solar charger and a supercapacitor based solution.
The Pi runs a standard Raspbian install, but uses packages from the ByzPi repository. This provides a single script that gets a Byzantium node up and running on the Pi. In the background, OLSR is used to route packets through the mesh network, so that nodes can communicate without relying on a single link.
The project has a ways to go, but the Raspberry Pi based setup makes it cheap and easy to get a wide area network up and running without relying on a single authority.
The idea of a pirate box is pretty simple. All you need is a tiny Linux system with a WiFi adapter, a bit of storage space, and the software that will allow anyone to upload a few files to the server and an interface that will let anyone on the network download those files. In practice, though, a pirate box is a mess of wires and power adapters – not the pocketable device a WiFi file sharing box should be.
[Chris] came up with a much smaller file sharing beacon. It’s not based on a router; instead, [Chris]’ build uses an ez Share WiFi microSD adapter. It’s a device meant to push pics taken by a digital camera up to the Internet, but by configuring the software just so, up to five users can connect to the adapter and pull files down from a microSD card. The build only requires putting power to the correct pins. A LiPo battery and charge controller takes care of this problem.
There are a few shortcomings to this project – [Chris] doesn’t know how to upload files to the device. Maybe someone sufficiently clever can figure out how to make that work. Still, if you’re ever in a situation where you’d like to share some files with people in the same building, this is the device you need.
Thanks [Jake] for the tip.
The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.
The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.
[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.
The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.
Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.