Engines on Precomputing.com

AltSql Core and Six Prototypes Built Around It

Thu, 01 Oct 2026 00:00:00 +0000

AltSql Core is the engine the project started with. It keeps key-value data and time-series readings on a device, answers SQL on a gateway, and copies the same records to both, byte for byte. It is the foundation, and it goes onto real chips first.

Around it now sit six prototypes. Each takes Core’s idea to one more problem in how devices keep, search and share their data. Each is small: one C file of 931 to 1,923 lines, with its own tests, measured results and a live demo on the live demo page.

AltSql Ask Puts One SQL Question to 500 Simulated Machines and Brings Back Only the Answers

Thu, 01 Oct 2026 00:00:00 +0000

An engineer wants to know which machines ran hot last night. The usual way is to pull every machine’s readings to a server first and ask there. That moves every raw reading, and on a slow or costly link the moving is the expensive part.

AltSql Ask turns that around. The gateway takes an ordinary SQL question and compiles it into a small program. It sends that program to every device. Each device runs it against its own records and sends back its share of the answer, and the gateway merges the shares into the rows the same SQL would have given over all the raw data.

AltSql Vector Teaches a Device What a Healthy Motor Sounds Like, in 32-Byte Fingerprints

Thu, 01 Oct 2026 00:00:00 +0000

A vibration sensor on a motor hears a lot. Most of it is the motor doing its job. The useful part is the moment the sound changes into something new, like a bearing starting to wear. Sending every sample to a server to find that moment costs bandwidth the device often does not have.

AltSql Vector lets the device do the listening. Every 1.6 seconds it splits what it hears into 32 frequency bands and turns that into a fingerprint of 256 bits, which is 32 bytes. It keeps fingerprints of the states it has been taught, such as idle, running and loaded. For each new fingerprint it finds the closest one it knows and names the state. When nothing it knows is close enough, it flags the pattern as one it was never taught.

AltSql Wave Keeps Raw Vibration Bursts on the Device, Lossless, and Sends Only Their Features

Thu, 01 Oct 2026 00:00:00 +0000

When a pump’s bearing starts to fail, an analyst wants two things. A quick figure to spot it, and the raw signal to understand it. Devices usually keep one or the other. They send summary figures and throw the signal away, or they send the signal and pay for every byte of it.

AltSql Wave keeps both. A sensor records a short burst of vibration, compresses it without losing a bit and stores it on the device, where the bursts stay for as long as its flash holds them. While the samples arrive, it works out the figures an analyst looks at first, such as RMS, peak and kurtosis, and the level in a few frequency bands. Only those figures go to the gateway, where SQL can search them. When a row looks interesting, the gateway fetches the raw burst behind it, checked against its CRC-32.

AltSql Mesh Keeps Twelve Devices on One Table on a Simulated Farm With No Signal and No Gateway

Thu, 01 Oct 2026 00:00:00 +0000

Some places have no mobile coverage and nowhere to put a gateway. A big sheep farm is one. The people working it still need the same picture: which troughs are low, which gates are open, what jobs are waiting and how many sheep are where.

AltSql Mesh gives every device its own copy of one shared table. Each device writes to its copy as its owner works. Whenever two devices come within radio range they bring each other up to date, over a link that may lose messages. No device is in charge and nothing waits for a server. Once every change has reached every device, all of them hold the same table, row for row, and any device with the memory for it can answer SQL about it.

AltSql Realtime Meets a 10 ms Deadline on a Simulated Flash Chip That Takes 45 ms to Erase

Thu, 01 Oct 2026 00:00:00 +0000

A controller runs its loop 100 times a second. Every cycle it saves a value and logs a row, and those writes have to finish within 10 ms. The trouble is the flash chip. Before it can reuse a sector it has to erase it, and on the chip the demo models, a Winbond W25Q32FV, an erase takes 45 ms typically and up to 400 ms at the slowest its datasheet allows. A storage engine that erases inside a write will, sooner or later, make the loop miss its deadline.

AltSql Instant: A Battery-Free Sensor on MRAM Saved 1,428 Readings in a Simulated Minute, Against 220 for AltSql Core on Flash

Thu, 01 Oct 2026 00:00:00 +0000

Some sensors have no battery. A small solar cell charges a capacitor, and when it is full the sensor wakes and works until the charge runs out. Then the power goes, wherever the sensor happens to be. It might be between readings or in the middle of writing one. Every bit of energy spent on storage is a reading not taken.

Flash memory makes this hard. It writes in pages and has to erase before it can write again, so a storage engine for flash keeps a log and cleans it up later. MRAM and FRAM work differently. They write single bytes, need no erase and keep what was written the moment the write ends.