Command interface about stabilizer HOT 9 CLOSED

IMHO a JSON command/payload structure that passes the (JSON) payload on to various handler functions sounds like it will do everything we need, and give a good reward/effort ratio.

from stabilizer.

My suggestion and preference is to go to MQTT (or something else if there are good alternatives) as soon as possible. To me this seems much better for a bunch of reasons and it was the plan (#3) all along. There is the beginning of a no-std mqtt parser and some potentially reusable server code that may help. ffi-ing the paho bindings is probably not worth it. It doesn't look too hard to implement the rest. @astro seemed interested and I know @gkasprow has used mqtt for several of his projects. It would be great if we could get a student to lead this. no-std MQTT is a key building block for embedded Rust and I am pretty sure it would receive wide usage (certainly much wider than another cutsom json req-resp).

from stabilizer.

I used MQTT from Arduino libs. It is also STM32duino so porting should be trivial. But it is not RUST...

from stabilizer.

Or CoAP: Several implementations in Rust and no_std.

from stabilizer.

And now there is embedded-mqtt, thanks to @ryan-summers for pointing it out.

from stabilizer.

Do you have any examples for what you would consider a well-designed interface using MQTT?

I am primarily interested in two interfaces for Stabilizer:

• A way to set system parameters such as IIR coefficients, reset error indicators, etc., easily extensible for different hardware variants (e.g. via an RPC-like interface), and
• high-rate real-time streaming of data (at least one 16 bit channel at the full 1 MS/s rate continuously).

MQTT's pub-sub messaging model doesn't seem to be a good match for either, because of the obvious impedance mismatch in the first case, and the data rate in the second (particularly considering the limited on-device computing power).

from stabilizer.

Mqtt is perfectly fine for the first use case (IIR configuration, streaming configuration, flag management, enable/disable, commands, request-response) and also for status monitoring at ~Hz rate.
What do you mean by impedance mismatch? Compared to the requirements this device has a massive amount of unused computing power. It can easily saturate the Ethernet link and could also overwhelm any MQTT broker.

For full/high rate streaming data I see few other options than custom binary (using one of the many serialization options in rust). But streaming is not really within the scope of this issue. And JSON for streaming full-rate data is a terrible idea.

from stabilizer.

E.g. look at the AWS IoT Core mqtt topic design guide.

Example:

• application is sinara or artiq
• context is e.g. opticlock
• thing-name is the name of a Stabilizer/Booster/Thermostat, e.g. clk-fiber

And then you could have the following MQTT topics (PUBLISH/SUBSCRIBE from device perspecitve):

• publish ADC/DAC telemetry: dt/sinara/opticlock/clk-fiber/analog
• publish filter error flags, digital state, counters dt/sinara/opticlock/clk-fiber/state
• subscribe IIR coefficients and filter configuration: dt/sinara/opticlock/clk-fiber/iir1
• subscribe to streaming configuration (target IPs, rate, etc): dt/sinara/opticlock/clk-fiber/stream
• subscribe to save-settings or reset commands: cmd/sinara/opticlock/clk-fiber/req
• publish to the command results to cmd/sinara/opticlock/clk-fiber/res

Payloads TBD but could well be some JSON for e.g. straight telegraf/influxdb ingest or AWS IoT core compat.

from stabilizer.

Forked into individual issues (see above).

from stabilizer.