CADmium Moves CAD To The Browser

For plenty of computer users, the operating system of choice is largely a middleman on the way to the browser, which hosts the tools that are most important. There are even entire operating systems with little more than browser support, under the assumption that everything will be done in the browser eventually. We may be one step closer to that type of utopia as well with this software tool called CADmium which runs exclusively in a browser.

As the name implies, this is a computer-aided design (CAD) package which looks to build everything one would need for designing project models in a traditional CAD program like AutoCAD or FreeCAD, but without the burden of needing to carry local files around on a specific computer. [Matt], one of the creators of this ambitious project, lays out the basic structure of a CAD program from the constraint solver, boundary representation (in this case, a modern one built in Rust), the history tracker, and various other underpinnings of a program like this. The group hopes to standardize around JSON files as well, making it easy to make changes to designs on the fly in whatever browser the user happens to have on hand.

While this project is extremely early in the design stage, it looks like they have a fairly solid framework going to get this developed. That said, they are looking for some more help getting it off the ground. If you’ve ever wanted something like this in the browser, or maybe if you’ve ever contributed to the FreeCAD project and have some experience, this might be worth taking a look at.

CATS mobile transceiver in a 3d-printed case

CATS: A New Communication And Telemetry System

CATS is a new communication and telemetry standard intended to surpass the current Automatic Packet Reporting System (APRS) standard by leveraging modern, super-cheap Frequency Shift Keying (FSK) transceivers rather than standard FM units. The project is in the early stages, but as of this writing, there is a full open source software stack and reference hardware for both Raspberry Pi-based gateway devices and an STM32-based mobile device.

CATS packets are called ‘whiskers!’

From a radio perspective, CATS uses raw FSK rather than the inefficient AFSK used by APRS. A real killer for channel utilization is the PTT time; this is the dead time around a packet APRS requires for ‘keying up’ and ‘keying down.’ The CATS standard is aggressive with PTT timing, enabling the channel to get going on sending the data sooner.

Additionally, compared to APRS, the packet baud rate increases from 1200 baud to 9600 baud. Other key points are using LDPC encoding for forward error correction and data whitening (a useful PDF guide from Ti) to smooth over any burst errors.

One of the neat concepts of APRS is the APRS-IS (APRS Internet service). This enables amateur radio services to be connected over the Internet, vastly improving range. The CATS equivalent is called FELINET (if you’re not spotting all the ‘cat’ references by now, go and get another coffee). Together with the I-gate hardware, FELINET bridges the CATS radio side with the current APRS network. As FELINET expands to more than the current few dozen nodes, APRS services will no longer be required, and FELINET may well replace it. Interestingly, all software for FELINET, the APRS relay, and the I-Gate firmware are written in Rust. We told you learning Rust was going to be worth the effort!

On the reference hardware side of things, the CATS project has delivered a Raspberry Pi hat, which uses a 1 watt RF4463 transceiver and supporting passives. The design is about as simple as it can be. A mobile transceiver version uses an STM32 micro to drive the same RF4463 but with supporting power supplies intended to run from a typical automotive outlet. Both designs are complete KiCAD projects. Finally, once you’ve got some hardware in place and the software installed, you will want to be able to debug it. CATS has you covered with an RTL-SDR I-Gate module, giving you an independent packet log.

APRS is quite mature, and we’ve seen many hacks on these pages. Here’s an earlier APRS IGate build using a Raspberry Pi. Need to hook up your PC to a cheap Chinese transceiver? You need the all-in-one cable. As with many things amateur-radio-oriented, you can get playing cheaply.

FLOSS Weekly Episode 774: Let’s Get Rusty

This week, Jonathan Bennett chats with Herbert Wolverson about Rust! Is it really worth the hype? Should you have written that in Rust? What’s up with “if let some” anyways? And what’s the best way to get started with this exciting language? We also cover comparisons with other languages like Ada, what drives us crazy about Cargo, and the fascinating world of kernel development!

Continue reading “FLOSS Weekly Episode 774: Let’s Get Rusty”

Hackaday Links Column Banner

Hackaday Links: March 10, 2024

We all know that we’re living in a surveillance state that would make Orwell himself shake his head, but it looks like at least one company in this space has gone a little rogue. According to reports, AI surveillance start-up Flock <<insert gratuitous “What the Flock?” joke here>> has installed at least 200 of its car-tracking cameras on public roads in South Carolina alone. That’s a serious whoopsie, especially since it’s illegal to install anything on state infrastructure without permission, which it appears Flock failed to obtain. South Carolina authorities are making a good show of being outraged about this, but it sort of rings hollow to us, especially since Flock now claims that 70% of the population (of the USA, we presume) is covered by their technology. Also, police departments across the country are in love with Flock’s service, which lets them accurately track the movements of potential suspects, which of course is everyone. No word on whether Flock will have to remove the rogue cameras, but we’re not holding our breath.

Continue reading “Hackaday Links: March 10, 2024”

render of the Amiga juggler demo

The Juggler: In Rust

Back on the theme of learning to program by taking on a meaningful project — we have another raytracing demo — this time using Rust on the Raspberry Pi. [Unfastener] saw our previous article about writing a simple raytracer in spectrum BASIC and got inspired to try something similar. The plan was to recreate the famous juggler 3D demo, from the early days of 3D rendering on the Amiga.

The juggler story starts with an Amiga programmer called [Eric Graham] who created ssg, the first ray tracer application on a personal computer. A demo was shown to Commodore, who didn’t believe it was done on their platform, but a quick follow-up with the actual software used soon quelled their doubts. Once convinced, they purchased the rights to the demo for a couple of thousand dollars (in 1986 money, mind you) to use in promotional materials. [Eric] developed ssg into the popular Sculpt 3D, which became available also on Mac and Windows platforms, and kick-started a whole industry of personal 3D modelling and ray tracing.

Anyway, back to the point. [Unfastener] needed to get up the considerable Rust learning curve, and the best way to do that is to let someone else take care of some of the awkward details of dealing with GUI, and just concentrate on the application. To that end, they use the softbuffer and winit Rust crates that deal with the (important, yet frankly uninteresting) details of building frame buffers and pushing the pixels out to the window manager in a cross-platform way. Vecmath takes care of — you guessed it — the vector math. There’s no point reinventing that wheel either. Whilst [Unfastener] mentions the original Amiga demo took about an hour per frame to render, this implementation runs in real-time. To that end, the code performs a timed pre-render to determine the most acceptable resolution to get an acceptable frame rate, achieving a respectable 30 or so frames per second on a Pi 5, with the older Pis needing to drop the resolution a little. This goes to show how efficient Rust code can be and, how capable the new Pi is. How far we have come.

We saw another interesting rust-based raytracer a while back, which is kinda fun. We’ve also covered rust in other applications a few times, like inside the Linux kernel. Finally here’s our guide to getting started with rust, in case you need any more motivation to have a crack at this upcoming language.

A Journey Through Font Rendering

In the wide world of programming, there are a few dark corners that many prefer to avoid and instead leverage the well-vetted libraries that are already there. [Phillip Tennen] is not one of those people, and when the urge came to improve font rendering for his hobby OS, axle, he got to work writing a TrueType font renderer.

For almost a decade, the OS used a map table encoding all characters as 8×8 bitmaps. While scaling works fine, nonfractional scaling values are hard to read, and fractional scaling values are jagged and blocky. TrueType and font rendering, in general, are often considered dark magic. Font files (.ttf) are structured similarly to Mach-O (the binary format for macOS), with sections containing tagged tables. The font has the concept of glyphs and characters. Glyphs show up on the screen, and characters are the UTF/Unicode values that get translated into glyphs by the font. Three critical tables are glyf (the set of points forming the shape for each glyph), hmtx (how to space the characters), and cmap (how to turn Unicode code points into glyphs).

Seeing the curtain pulled back from the format itself makes it seem easy. In reality, there are all sorts of gotchas along the way. There are multiple types of glyphs, such as polygons, blanks, or compound glyphs. Sometimes, control points in the glyphs need to be inferred. Curves need to be interpolated. Enclosed parts of the polygon need to be filled in. And this doesn’t even get to the hinting system.

Inside many fonts are tiny programs that run on the TrueType VM. When a font is rendered at low enough resolutions, the default control points will lose their curves and become blobs. E’s become C, and D’s become O’s. So, the hinting system allows the font to nudge the control points to better fit on the grid. Of course, [Phillip] goes into even more quirks and details in a wonderful write-up about his learnings. Ultimately, axle has a much better-looking renderer, we get a great afternoon read, and fonts seem a little less like forbidden magic.

Maybe someday [Phillip] will implement other font rendering techniques, such as SDF-based text renderers. But for now, it’s quite the upgrade. The source code is available on GitHub.

Building A Weather Display In Rust

We’ve seen a lot of weather displays over the years, and plenty of the more modern ones have been using some form of electronic paper. So what makes this particular build from [Harry Stern] different? The fact that the firmware running on the ESP32 microcontroller at its heart was developed in Rust.

The weather station itself is capable of operating for several months on its rechargeable NiMH battery bank. The Rust section of the project is in two parts, the first of which runs on a server which downloads the weather data and aggregates it into an image. The second part runs on the ESP32 using esp-idf which configures peripherals, turns on and connects to Wi-Fi, retrieves the image from the server, displays the image and then puts the display to sleep. By doing the heavy lifting on the server, the display should be able to run for longer than it would if everything was happening on the ESP32.

The project code is available from this GitHub page which should allow even Rust beginners to follow along, and the case file is also available for those with a 3D printer. [Harry] has a few upgrades planned for future releases as well, including a snap-fit case, a custom PCB, and improved voltage regulator for better battery life, and enhanced error handling for the weather API. And Rust isn’t the only interesting part of this project, either. As prices for e-paper displays continue to fall, more and more of them are found in projects like weather stations and even complete laptops which use these displays exclusively.