Hardware Pilot

AltSql Core works in simulation. The proof that matters next is on real hardware, and the most useful hardware is a real product. A pilot fits AltSql Core to one of your product lines and runs it on your own board, against your own data.

Where things stand. The engine, its tests and its live demo run on a PC today. AltSql Core compiles for Arm Cortex-M0+, M4 and M33 and for RISC-V, but it has not run on a microcontroller yet. Its Beta puts it on real boards first, and pilots follow. Planning one can start now.

Who Should Bring a Pilot

A pilot fits a device that matches most of this:

  • A microcontroller that keeps readings and settings in flash memory.
  • A link that drops, costs money per byte or carries very little, such as a cellular modem on the road or one LoRaWAN message a day.
  • Power that can go at any moment, in the middle of a write.
  • A gateway that should answer questions about the data in SQL.
  • Converter code between the device and the gateway that somebody has to keep working for years.

Machine monitoring, cold chain and agriculture are the three cases the Alpha demo covers. The case studies show each one: an overheat alarm handled on the sensor, a truck logger with no coverage and a soil sensor that runs its own valve.

What to Bring

One product line, described in a few lines:

  • The chip and its flash: the part, the sector size and how much flash the data can have.
  • Memory to spare: how much RAM the engine can use. A sensor build should budget about 2.5 KB, stack included: the Alpha’s figure, compiled for a Cortex-M4 and not yet run on one.
  • The data: which sensors, how often each is read, and the settings the device keeps.
  • The link: Wi-Fi, cellular, LoRaWAN or something else, and how much it can carry.
  • The decisions: what the device should decide on its own, such as an alarm, a valve or a record of an excursion.
  • The questions: what the gateway, or the people behind it, need to ask of the data.

How a Pilot Would Run

  1. A first conversation about the product line and what a good result would be.
  2. A set-up for your device: where the data lives in flash, which series it keeps, the rules it runs and what it sends over the link.
  3. AltSql Core on your board, built for your chip, with the power cut again and again while it writes.
  4. Your gateway keeps the same records and answers SQL over them.
  5. A written result: code size, RAM and stack, time per operation, bytes sent over the link, flash wear, and the outcome of every power cut.

If the gateway also needs to ask a whole fleet a question and get back only the answers, AltSql Ask can be added once its own Beta, with programs signed by the gateway, has run on real boards.

Ready Now, and After the Beta

  • Ready now: AltSql Core’s Alpha, tested in simulation, with its live demo, the technical brief, and the Alpha report on request. The first two steps can start today.
  • After AltSql Core’s Beta: flash drivers for five chip families (Arm Cortex-M0+, M4 and M33, RISC-V and Xtensa), a rig that cuts the power for real, the set-up generator, and every figure measured again on real chips. Steps 3 to 5 need these.

Before You Write

The technical brief sums up what AltSql Core supports, the memory it needs and its known limits on one page. The Alpha results have the detail, and the live demo runs the engine on three simulated devices in your browser.

Discuss a Pilot

Write to [email protected] with your product line in a few lines: the chip, the flash, the link and what the device should decide. The Alpha report, with every figure and how it was measured, goes to device makers on request.