Tracking Deep-Sky Objects

Astrophotography, and astronomy in general, takes some fairly specialized tools and a high amount of precision. Setting up the equipment can also take a lot of time, especially for amateurs traveling to various locations with their equipment, so anything that can reduce the amount of time spent looking for objects and increasing the amount of time looking at them is a welcome addition, especially since nights where conditions are ideal for these activities can be rare. [Anton] developed this real-time tracking tool for deep sky objects (DSOs) to keep tabs on most of the interesting things out there a telescope can be pointed at.

[Anton] calls his tool the Nova DSO Altitude Tracker and gets its information from SIMBAD, updating every minute for a given location on the planet. With that location data, the program calculates altitude and azimuth for various objects and also helps the user keep track of other important variables like moon illumination and angle above the horizon. It also allows the user to highlight specific objects of interest, making sure they are front and center throughout the session. Each DSO can be selected from a list to display detailed information about it such as its path, time visible in the sky, and other properties.

To get the program running, essentially all that’s required is a computer capable of running Python and a display of some sort. From there it provides a quick view of the best objects to point one’s telescope or camera at without any guesswork. With all of the code available it shouldn’t be too much of a leap to do other things with the underlying software, either, such as tying it into a tracker of some sort like this DIY telescope tracking device we featured a while back.

Satellite Imagery You Can Play With

Satellite imagery is in the news right now, but not all satellite constellations are the preserve of governments. Satellogic operates a series of CubeSats with Earth imaging payloads, and best of all, they maintain an open dataset. [Mark Litwintschik] takes us through using it.

Starting with a script to recover the locations of the satellites, he moves on to the data itself. It’s in a huge S3 bucket, for which parsing the metadata becomes a big data question rather than one of simple retrieval. After parsing he loads the resulting data into a database, from which he can then perform queries more easily. He uses Qatar as his example, and shows us the resulting imagery.

The dataset isn’t comprehensive, it’s obvious that the areas surveyed have been done at the behest of customers. But who knows, your part of the world might be one of the areas in the dataset, and now you have all the tools you need to explore. It certainly beats low-res weather satellite imagery.

Freeing Windows

There have been several attempts to make an unencumbered version of Windows. ReactOS is perhaps the best-known. You could also argue that Wine and its progeny, while not operating systems in the strictest sense of the word, might be the most successful. Joining the fray is Free95, a GPL-3.0 system that, currently, can run simple Windows programs. The developer promises to push to even higher compatibility.

As you might expect, the GitHub site is calling for contributors. There will be a lot to do. The src subdirectory has a number of files, but when you consider the sheer volume of stuff crammed into Windows, it is just a minimal start.

Continue reading “Freeing Windows”

Physical Computing Used To Be A Thing

In the early 2000s, the idea that you could write programs on microcontrollers that did things in the physical world, like run motors or light up LEDs, was kind of new. At the time, most people thought of coding as stuff that stayed on the screen, or in cyberspace. This idea of writing code for physical gadgets was uncommon enough that it had a buzzword of its own: “physical computing”.

You never hear much about “physical computing” these days, but that’s not because the concept went away. Rather, it’s probably because it’s almost become the norm. I realized this as Tom Nardi and I were talking on the podcast about a number of apparently different trends that all point in the same direction.

We started off talking about the early days of the Arduino revolution. Sure, folks have been building hobby projects with microcontrollers built in before Arduino, but the combination of a standardized board, a wide-ranging software library, and abundant examples to learn from brought embedded programming to a much wider audience. And particularly, it brought this to an audience of beginners who were not only blinking an LED for the first time, but maybe even taking their first steps into coding. For many, the Arduino hello world was their coding hello world as well. These folks are “physical computing” natives.

Now, it’s to the point that when Arya goes to visit FOSDEM, an open-source software convention, there is hardware everywhere. Why? Because many successful software projects support open hardware, and many others run on it. People port their favorite programming languages to microcontroller platforms, and as they become more powerful, the lines between the “big” computers and the “micro” ones starts to blur.

And I think this is awesome. For one, it’s somehow more rewarding, when you’re just starting to learn to code, to see the letters you type cause something in the physical world to happen, even if it’s just blinking an LED. At the same time, everything has a microcontroller in it these days, and hacking on these devices is also another flavor of physical computing – there’s code in everything that you might think of as hardware. And with open licenses, everything being under version control, and more openness in open hardware than we’ve ever seen before, the open-source hardware world reflects the open-source software ethos.

Are we getting past the point where the hardware / software distinction is even worth making? And was “physical computing” just the buzzword for the final stages of blurring out those lines?

A CaptionCall Phone Succumbs To Doom, Again

Pour one out for yet another device conquered. This one’s a desk phone for conferences and whatnot, a colour display, a numpad, and a bog standard handset with a speaker and mic. Naturally, also running Linux. You know what to expect – [Parker Reed] has brought Doom to it, and you’d be surprised how playable it looks!

This is the second time a CaptionCall device has graced our pages running Doom — CaptionCall patched out the previous route, but with some firmware dumping and hashcat, root has been acquired once again. [Parker] has upgraded this impromptu gaming setup, too – now, all the buttons are mapped into Doom-compatible keyboard events coming from a single input device, thanks to a C program and an Xorg config snippet. Feel free to yoink for your own Doom adventures or just general CaptionCall hacking!

If you’re interested in the hacking journey, get into the exploitee.rs Discord server and follow the hack timeline from password recovery, start to finish, to Doom, to the state of affairs shown in the video. Now, as the CPU speeds have risen, should the hackerdom switch away from Doom as the go-to? Our community remains divided.

Continue reading “A CaptionCall Phone Succumbs To Doom, Again”

The rust language logo being branded onto a microcontroller housing

Esp-hal, A Stable-API ESP32 HAL Gift For Your Rust Code

Looking to write Rust on the ESP32? You’re in luck, a new challenger has entered the scene, looking to help you write code that lasts – [Scott Mabin] and the team from Espressif have brought us the esp-hal 1.0.0-beta. From a personal project to an Espressif-sponsored one to an effort under Espressif’s wing, [Scott] tells us about the arduous journey of bringing first-class Rust support to ESP32 chips, Xtensa and RISC-V alike.

In particular, esp-hal, with the hal part standing for Hardware Abstraction Layer, focuses on providing you with a stable API to access hardware, making sure your code can remain stable for years to come. For now, you get drivers for GPIO, UART, SPI and I2C, as well as a number of auxiliary features like time and SoC reset, more than enough for a large amount of projects we hackers build with a generic MCU in mind.

Next stop? WiFi and BLE support, of course, an ESP32 just doesn’t feel the same without these two. Rust is a fun and seriously promising language, and it’s a joy to use! So, if you have a wireless-less project in mind and you’re looking for a HAL, try out the esp-hal, it might just be exactly what you need.

If you’re looking for examples, here’s an STM32 touchpad project with Rust firmware, a PIC32 Rust blinky demo, and we’ve even featured larger projects like this ESP32 open-source (reverse-engineered) WiFi MAC stack being written in Rust. In case you missed it, we’ve introduced Rust to you a couple of times, even as far as 2015!

A Web-Based Graphics Editor For Tiny Screens

These days, adding a little LCD or OLED to your project is so cheap and easy that you can do it on a whim. Even if your original idea didn’t call for a display, if you’ve got I2C and a couple bucks burning a hole in your pocket, why not add one? Surely you’ll figure out what to show on it as the project develops.

But that’s where it can get a little tricky — in terms of hardware, adding a screen just takes running a few extra wires, but the software side is another story. Not only do you have to contend with the different display libraries, but just creating the image assets to display on the screen can be a hassle if it’s not something you do regularly. Enter Lopaka, a graphics and user interface editor for electronic projects created by [Mikhail Ilin].

Continue reading “A Web-Based Graphics Editor For Tiny Screens”