While most projects we see with the ESP32 make use of its considerable wireless capabilities, the chip can be connected to the wired network easily enough should you have the desire to do so. [Steve] liked the idea of putting his ESP32s on the wired network, but found the need for a secondary power connection burdensome. So he took it upon himself to modify some cheap Power Over Ethernet (PoE) hardware and create a single-cable solution (Google Translate).
[Steve] bought a PoE module intended for security cameras and ran a close eye over the board to figure out what kind of hardware it was using to generate the nominal 12 V output. He identified an MP2494 step-down converter, and with the datasheet in hand found how the output voltage is configured by changing the values of resistors in the circuit. Swapping out the stock 21.5 kΩ resistor for a 57.1 kΩ one changed the output of the converter to the 5 V necessary for his electronics.
But of course that was only half of the problem solved; he still had to connect the Ethernet side of the PoE device to the Waveshare LAN8720 board that’s providing Ethernet for the ESP32. So he removed the RJ45 jack from the LAN8720 completely, and wired that directly to the connector on the PoE board. Helpfully, the PoE board had all the pins labeled on the bottom side so this wasn’t nearly as tricky to figure out as you might expect (if only it was always that easy).
We’ve previously covered the Waveshare LAN8720 board for anyone who’s interested in the ins and outs of getting their ESP32 talking Ethernet. If you’re wondering how you can put PoE to work for you, our very own [Jonathan Bennett] has been showing off his home Raspberry Pi infrastructure which makes extensive use of the new PoE hat.
In systems where there are multiple participants who need to interact with a shared resource some sort of concurrency protection is usually appropriate. The obvious technique is to use locking (and fun words like “mutex”) but this adds a constant performance hit as every participant needs to spend time interacting with the lock regardless of the number of other participants. It turns out this is actually a Big Problem that garners original research, but there are techniques that can yield great effect without a PhD. Years ago [Marc] posted a great walkthrough of one such method, exponential backoff with jitter, to Amazon’s AWS blog which is a great introduction to one such solution.
The blog post was written specifically to deal systems using a specific technique called optimistic concurrency control (OCC) but that doesn’t mean the advice isn’t generally applicable. OCC refers to a method where each writer checks for a write collision only after performing the write (but before committing it), which works well in scenarios where writes are relatively uncommon. [Marc] observed that even in systems where this is a safe assumption things bog down significantly when there are too many writers clamoring for attention all at once.
The traditional solution to such a problem is for each writer to pause for an exponentially increasing amount of time before trying again, but as writers come back in big groups the same problem can recur. He provides a discussion of simple modifications to that strategy which result in significantly reduced wait times for writers.
Problems like this are not especially relevant for single Arduino sensor networks, but even small groups of systems can have concurrency trouble and it’s nice to see such an accessible write up with solutions which are viable even for simple systems. Bonus points to [Marc] for posting source to his test tool online. It doesn’t require anything outside of your computer to run (no AWS required) so if you have any brainwaves about speeding up multi-writer environments it might make a nice test environment! Maybe don’t mention the blog post in your PhD applications though.
We’ll go out on a limb and assume that anyone reading these words is probably familiar with the classic
ping command. Depending on which operating system you worship the options might be slightly different, but every variation of this simple tool does the same thing: send an ICMP echo request and wait for a response. How long it takes to get a response from the target, if it gets one at all, is shown to the user. This if often the very first step to diagnosing network connectivity issues; if this doesn’t work, there’s an excellent chance the line is dead.
But in the modern web-centric view of networking,
ping might not give us the whole picture. But nature it doesn’t take into account things like DNS lookups, and it certainly doesn’t help you determine what (if any) services the target has available to you. Accordingly, [Liu Zhiyong] has come up with a tool he calls “pingms”, which allows you to check web server latency right from your browser.
Rather than relying on ICMP, pingms performs a more realistic test. It takes the list of targets from the file “targets.js” and connects to each one over HTTP. How does it work? The code [Liu] has come up with will take each target domain name, append a random number to create a gibberish filename, and then calculate how long it takes to get a response when trying to download the file. Obviously it’s going to be getting a 404 response from the web server, but the important thing is simply that it gets the response.
With this data, [Liu] has come up with a simplistic but very slick interface which shows the user the collected data with easy to understand color-coded graphs. As interesting as it is to see how long it takes your favorite web sites or service providers to wake up and start talking, watching the colored bars hop up and down the list to sort themselves is easily our favorite part of pingms.
[Liu] has released pingms under the GPLv3 license, so if you’re looking to utilize the software for your own purposes you just need to provide a list of test targets. If you need to perform low-level diagnostics, check out this handy network tester you can build for cheap.
When moving into a new house, it’s important to arrange for the connection of basic utilities. Electricity, water, and gas are simple enough, and then it’s generally fairly easy to set up a connection to an ISP for your internet connection. A router plugs into a phone line, or maybe a fiber connection and lovely packets start flowing out of the wall. But if you’re connected to the internet through an ISP, how is the ISP connected? [Kenneth] answers this in the form of an amusing tale.
It was during the purchase of data centre rack space that [Kenneth]’s challenge was laid down by a friend. Rather then simply rely on the connection provided by the data centre, they would instead rely on forging their own connection to the ‘net, essentially becoming their own Internet Service Provider.
This is known as creating an Autonomous System. To do this involves several challenges, the first of which is understanding just how things work at this level of networking. [Kenneth] explains the vagaries of the Border Gateway Protocol, and why its neccessary to secure your own address space. There’s also an amusing discussion on the routing hardware required for such a feat and why [Kenneth]’s setup may fall over within the next two years or so.
It’s not for the faint hearted, and takes a fair bit of paperwork, but [Kenneth] has provided an excellent guide to the process if you really, really just need to own your own corner of the internet. That said, there are other networking tricks to cut your teeth on if you’d like a simpler challenge, like tunneling IP over ICMP.
The mid-1980s were a time of drastic change. In the United States, the Reagan era was winding down, the Cold War was heating up, and the IBM PC was the newest of newnesses. The comparatively few wires stitching together the larger university research centers around the world pulsed with a new heartbeat — the Internet Protocol (IP) — and while the World Wide Web was still a decade or so away, The Internet was a real place for a growing number of computer-savvy explorers and adventurers, ready to set sail on the virtual sea to explore and exploit this new frontier.
In 1986, having recently lost his research grant, astronomer Clifford Stoll was made a computer system admin with the wave of a hand by the management of Lawrence Berkeley Laboratory’s physics department. Commanded to go forth and administer, Stoll dove into what appeared to be a simple task for his first day on the job: investigating a 75-cent error in the computer account time charges. Little did he know that this six-bit overcharge would take over his life for the next six months and have this self-proclaimed Berkeley hippie rubbing shoulders with the FBI, the CIA, the NSA, and the German Bundeskriminalamt, all in pursuit of the source: a nest of black-hat hackers and a tangled web of international espionage.
Continue reading “Books You Should Read: The Cuckoo’s Egg”
While there are plenty of hackers that hack just for the love of it, it’s no secret that many of us are looking to hit it big someday. Tales of the businesses like HP and Apple that started in someone’s garage inevitably lead to musings like, “Hey, I’ve got a garage!” and grand plans to turn that special idea into the Next Big Thing™. Many will try, most will fail for one reason or another, but hope springs eternal, and each new widget seems to start the entrepreneurial cycle again.
But for as much pressure as we may feel to be the next Packard, Wozniak, or Musk, not everyone is cut out to be the boss. Some of us have no interest in or aptitude for business — we don’t want to hire or fire people, we don’t want to wheel and deal, and we certainly don’t want to worry about salesmanship. Some of us just want to abstract all that complexity away and just find a job, preferably one that leverages the things we love to do.
Continue reading “Ask Hackaday: Selling Yourself as a Hacker”
[Victor Frost] has a deep voice and a fancy top of the line camera. While one would assume this to be a more than generous situation for life to put a person in; it’s got its own set of problems. Mainly that his fantastic fancy camera uses the most modern version of the popular h.264 encoding scheme, h.265. Gasp!
While that too seems like a pro, unfortunately h.265 doesn’t play as nice with his editing software. The solution seems easy, just transcode it and get on your way. However, when you start talking about transcoding 4K video from a top-of-the line source and retaining the quality. Well… It can bring a processor to its knees. Since he’d rather be playing overwatch than transcoding video on his main computer, he decided to offload and automate the drudgery to his spare.
That’s how the Ingest-a-Tron 9000 came into play. It uses a lot of open source software and, yes, windows batch files to take the files off his camera, process it on one computer, and dump it to another. Now he can game (or edit) while he waits. For those of us who are estranged from Linux thanks to our favorite software, it’s good to know that there are still ways to automate away the pain. Video after the break.
Continue reading “Script Your Way Out Of Video Editing Drudgery”