Today I learned about existence of Local Interconnect Network or LIN bus. It is a set of specifications defining a network communication system describing everything from raw voltage levels up to logical communication data protocol. A LIN network has up to sixteen devices: one controller and up to fifteen peripherals, and they communicate via asynchronous serial over a shared wire. At a high level, there’s a lot of resemblance to how serial bus servos work, but LIN came from the automotive field.

As car components got more sophisticated, basic on/off or analog voltage was no longer enough to convey status. They needed an actual data network protocol, and the industry has settled on CAN bus. While capable and robust, CAN bus is overkill for basic functions. LIN bus is a simpler protocol that trades capability for less expensive implementation hardware. A focus on simplicity meant the LIN steering group decided their job here was done and is now a mature standard also known as ISO 17987.

Based on my limited reading, I understand the division of labor for an illustrative modern car driver’s door would be something like this:

• A host controller connected to the car’s CAN bus communicating with the rest of the car, and connected to other devices inside the door via LIN bus.
• A microcontroller monitors all the power window switches and report their status to the door host via LIN.
• A microcontroller manages the power window motor based on commands received from door host via LIN.
• Repeat for power door locks, and power mirrors.
• Other sensor inputs like whether door latch is closed.
• Other control outputs like illuminating puddle lights.

Given the close proximity of these devices to each other inside the door, full signal integrity robustness of CAN bus was not strictly necessary. LIN bus modularity means fewer wires. For example, wires that would otherwise be necessary if the host controller had to monitor each power window switch individually could now be replaced by a single LIN data wire. It also simplifies adding/removing functionality for higher/lower trim levels in a product line, and reduce cost of adapting to regional differences like left- or right-hand drive.

That’s all great for automobile manufacturers. But since LIN bus is simpler than CAN bus, it also lowers the barrier to repurposing automotive components for hobbyist projects. A quick look on Arduino forums found several threads discussion LIN bus devices, and there exists affordable breakout boards (*) to interface with microcontrollers. This could be an entryway into a lot of fun.

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

I recently learned about a particular bit of engineering behind AHEAD (“Advanced Hit Efficiency and Destruction”) ammunition, and I was impressed. It came up as part of worldwide social media spectating on the currently ongoing Russian invasion of Ukraine. History books will note it as the first “drone war”, with both sides using uncrewed aircraft of all sizes for both strike (bombing) and reconnaissance (spying). Militaries around the world are taking notes on how they’d use this technology for their own purposes and deny the enemy use of theirs. “Deny” in this context ranges anywhere from electronic jamming to physically shooting them down.

“Just shoot them down” is actually a lot easier said than done, especially for small cheap multirotor aircraft like the DJI Mavic line widely used across the front. They have a radio range of several kilometers carrying high resolution cameras that can see kilometers further. Shooting anti-aircraft missiles to take them down is a financial loss: the quadcopter cost a few thousand US dollars, far less than the missile. And that’s if the missile even works: most missiles are designed to go against much larger targets and have difficulty against tiny drones. Every failed shot caught on camera gets turned into propaganda.

When missiles are too expensive, the classic solution is to use guns to throw chunks of metal at it. But since these are tiny drones flying several kilometers away, it’s nearly impossible to hit them with a single stream of bullets. The classic solution to that problem is to use some sort of scatter-shot. A shotgun won’t work over multi-kilometer distances (skeet shooting uses shotguns at a distance of a few tens of meters) so the answer is some sort of airburst ammunition: cannon shells that fly most of the way as an aerodynamic single piece then explode into tiny pieces, hoping to hit the target with some fragments.

OK great, but when should the shell burst apart? “Have it look for the drone!” is a nonstarter: even if something smart enough to detect a drone can be miniaturized to fit, it would be far more expensive than a dumb shell. The cheap solution is a timer: modern technology can make very accurate and precise timers, durable enough to be fired out of a cannon, at low cost.

It’s pretty easy to set a timer before the shell is fired, but what do we set the timer to? If it detonates too early, the fragments disperse too much to take down the target. Detonating too late is… well… too late. If the shooting cannon has a radar to know the distance to target, in theory we could divide distance by speed to calculate a time. But what speed do we use in that math? Due to normal manufacturing tolerances, each cannon shell will be a tiny bit faster or slower relative to another. Narrowing the range of tolerance is possible but expensive, opposite of the desire for cheap shells. It’d be nice to have a system that can automatically compensate for the corresponding variation.

Enter AHEAD. It removes one uncertainty by measuring the velocity of each shell as it is fired then sets the timer after that. Two coils just past the end of the barrel can sense the projectile as it flies past. Its actual velocity is calculated from the time it took for the shell to go from one coil to the next. That information feeds into calculation for the desired timer countdown. (A little more sophisticated than distance divided by velocity due to aerodynamic drag and other factors.) Then a third coil wirelessly communicates with the shell (which, as a reminder, has already left the barrel) telling it when to scatter into tiny pieces.

When I read how the system worked, I thought “Hot damn, they can do that?” It felt like something from the future, even though the Wikipedia page for AHEAD said it’s been under development since 1993 and first fielded in 2011. The page also included this system cross-section image (CC BY-SA 4.0):

It shows the three coils in red: two smaller velocity measurement coils followed by the larger inductive timer programming coil. Given the 35mm diameter of the shell, there seems to be roughly 100mm between the two velocity measurement coils. Wikipedia page for an AHEAD-capable weapon lists the muzzle velocity around 1050 meters per second, which calculates out to ~95 nanoseconds to cover the distance between those two coils. The length of the shell is a little over five times the diameter, and the inductive communication coil is somewhere towards the back so call it 5*35 = 175mm from tip of shell to inductive coil. The distance from second velocity coil to programming coil is roughly the diameter of the shell at 35mm. 175 + 35 = ~210mm distance. That implies in the neighborhood of 200 nanoseconds from the time the tip clears the second coil, to the time the two inductive communication coils line up. That 200ns is my rough guess as to the time window for the computer to perform its ballistic calculations and generate a timer value ready to transmit. That transmission itself must take place within some tens of nanoseconds, before the communication coils separate. That is not a lot of time, but evidently within the capability of modern electronics.

Here’s a YouTube video clip from a demonstration of an AHEAD-armed system firing against a swarm of eight drones. Since it’s a sales pitch, it’s no surprise all eight drones fell from the sky. But for me, the most telling camera viewpoint was towards the end, when it showed the intercept from a top-down camera view. We can see the airburst pattern to the left of the screen and the target swarm to the right. From this viewpoint, the top-down variation is due to aerodynamic and other effects and the left-right variation is due to shell-to-shell variation plus aerodynamic and other effects. To my eyes, the airbursts are in a circle, which I inferred to mean the system successfully compensated for shell-to-shell variation.

I’m not very knowledgeable about military hardware so I don’t know how this system measures up against other competitors for military budgets. But from a mechanical and electronics engineering perspective I was very impressed there is a way to set the fuze timer after the shell has been fired.

This blog is a project diary, where I write down not just the final result, but all the distractions and outright wrong turns taken on the way. I write a much shorter summary (with less noise) for my projects in the README file of their associated GitHub repository. As much as I appreciate markdown, it’s just text and I have to fire up something else for drawings, diagrams, and illustrations. This becomes its own maintenance headache. It’d be nice to have tools built into GitHub markup for such things.

It turns out, I’m not the only one who thought so. I started by looking for a diagram tool to generate images I can link to my README files, preferably one that I might be able to embed into my own web app projects. From there I found Mermaid.js which looked very promising for future project integration. But that’s not the best part: Mermaid.js already have their fans, including people at GitHub. About a year ago, GitHub added support for Mermaid.js charts within their markdown variant, no graphic editor or separate image upload required.

I found more information on how to use this on GitHub documentation site, where I saw Mermaid is one of several supported tools. I have yet to need math formulas or geographic mapping in my markdown, but I have to come back to take a closer look into STL support.

As my first Mermaid test to dip my toes into this pool, I added a little diagram to illustrate the sequence of events in my AS7341 spectral color sensor visualization web app. I started with one of the sample diagrams on their live online editor and edited to convey my information. I then copied that Mermaid markup into my GitHub README.md file, and the diagram is now part of my project documentation there. Everything went through smoothly just as expected and no issues were encountered. Very nice! I’m glad I found this tool and I foresee adding a lot of Mermaid.js diagrams to my project README in the future. Even if I never end up integrating Mermaid.js into my own web app projects.

Artists explore where the mainstream is not. That’s been true for as long as we’ve had artists exploring. Early art worked to develop techniques that capture reality the way we see them with our eyes. And once tools and techniques were perfected for realistic renditions, artists like Picasso and Dali went off to explore art that has no ambition to be realistic.

This evergreen cycle is happening in computer graphics. Early computer graphics were primitive cartoony blocks but eventually evolved into realistic-looking visuals. We’re now to the point where computer generated visual effects can be seamlessly integrated into camera footage and the audience couldn’t tell what was real and what was not. But now that every CGI film looks photorealistic, how does one stand out? The answer is to move away from photorealism and develop novel non-photorealistic rendering techniques.

I saw this in Spider-Man: Into the Spider-Verse, and again in The Mitchells vs. the Machines. I was not surprised that some of the same people were behind both films. Each of these films had their own look, distinct from each other and far from other computer animated films. I remember thinking “this might be interesting to learn more about” and put it in the back of my mind. So when this clip came up as recommended by YouTube, I had to click play and watch it. I’m glad I did.

From this video I learned that the Spider-Verse people weren’t even sure if audience would accept or reject their non-conformity to standards set by computer animation pioneer Pixar. That is, until the first teaser trailer was released and received positively to boost their confidence in their work.

I also learned that they were created via rendering pipelines that have additional stylization passes tacked on to the end of existing photorealistic rendering. However, I don’t know if that’s necessarily a requirement for future exploration in this field, it seems like there’d be room for exploring pipelines that skip some of the photorealistic aspects, but I don’t really know enough to make educated guesses. This is a complex melding of technology and art. It takes some unique talent and experience to pull off. Which is why it made sense (in hindsight) that entire companies exist to consult for non-realistic rendering, with Lollipop Shaders the representative in this video.

As I’m no aspiring filmmaker, I doubt I’ll get anywhere near there, but what about video game engines like Unity 3D? I was curious if anyone has explored applying similar techniques to the Unity rendering pipeline. I looked on Unity’s Asset Store under the category of VFX / Shaders / Fullscreen & Camera Effects. And indeed, there were several offerings. In the vein of Spider-Verse I found a comic book shader. Painterly is more like Mitchells but not in the same way. Shader programmer flockaroo has several art styles on offer, from “notebook drawings” to “Van Gogh”. If I’m ever interested in doing something in Unity and want to avoid the look of default shaders, I have options to buy versus developing my own.