Forum - Recent Threads

Misaz’s Forum #5: Experimenting with Thermocouple

misaz — Sun, 21 Jun 2026 22:33:34 GMT

Hi. I welcome you to next part of my series about my experiments with industrial sensors. In this part I will look at thermocouple. As part of kit, I’ve got kit of five K-Type thermocouple. Compared to previously described sensor, thermocouple is complete opposite. It do not produce current output, instead it produces voltage output, and instead of getting decent industrial reliable output, it actually generates only few millivolts. While previous sensor was providing absolute value, thermocouples provide relative output to some reference called cold junction. It is temperature on connector where different metal touch each other. Sensor provides temperature difference between probe and this connector. To get absolute measurement, we need to measure one of these temperatures by different sensor. But Let’s begin simply. Let’s start with multimeter again.

As a first experiment I connected multimeter in mili-voltmeter mode directly to sensor:

And when I heated a probe a little I’ve got slightly higher voltage:

Note that measurements are not in V. They are in mV. So, it is 0,00023V actually. Very low voltage!

I tried Fluke online calculator at: www.fluke.com/.../thermocouple-voltage-to-temperature-calculator

As you can see, such small voltage difference correspond to 5,810 °C temperature difference between cold junction and thermocouple. It corresponds to difference between room temperature about 29°C these days and my finger temperature around 36°C.

Let’s try digitally

For using thermocouples in real, we need to deal with two problems. Very low voltage and need for second sensor. Back in 2022, there were Experimenting with Thermistors competition which I joined. Thermistors are one of the possible solutions for second sensor need. Additionally, as part of Experimenting with Thermistor I created board with 24-bit ADC with PGA which can nicely measure both thermistor and thermocouple. It is built around MAX11410 ADC chip. I reused it for this project. The idea was to reuse current part for thermistor and reference:

Chip has build int constant current generator, which can generate current like 50uA and pass it from port like AIN4 here. This current flow down through thermistor and 22k precise (0,1% tolerance resistor) which generates reference (REF1). This can nicely measure thermistor relatively to known reference without any precise voltage reference (50uA current is also imprecise).

For thermocouple I had plan to use another two channels of my board like Maxim showcase in ADC chip datasheet (however I used AIN7 and 8 since 4, 5, 6 are already occupied):

For this measurement, I actually need precise voltage reference. My idea was to use builtin reference, measure precise resistor using it, estimate it’s error and compensate thermocouple voltage measurement with this knowledge.

I connected everything:

Note that thermistor end (two thin black wires ending on yellow connector) touches cold junction of thermocouple.

Failed

However, my experiment failed. I migrated my MAX11410 library to Arduino Uno Q, adjusted code to do measurements as needed, but if for some reason returned full scale voltage in nearly all cases. As part of troubleshooting, I tried run the same experiment which I run back in Experimenting with Thermistors era, on same board, with same code, with disconnected other new parts and it still produce bad numbers.

I am not sure what happened to my ADC board, but I am, no longer do even basic voltage measurements with it. After few hours of troubleshooting, I gave up.

And since time is running out. This is end of my experimenting here. In next part, I will summarize all my efforts.

Misaz’s Forum #4: Digital measurement of Analog output

misaz — Sun, 21 Jun 2026 22:30:50 GMT

Hello Element14 community.

In this forum I will show another play with Omega’s HX94C industrial humidity and temperature sensor with analog output. Today, I will convert analog current output to digital form using Arduino Uno Q.

How to do that is briefly explained in printed manual which come with sensor:

The missing part is “TEMP METER OR RECORDER”. Diagram highlights that it needs some resistor to measure. This is exactly what we need for converting current output to voltage measurable by ADC. Question is what value? The answer is ohm law. We need to map 20mA to 3.3V measured by Arduino UNO Q. Formula is: R = U / I. U is voltage we want to get (3.3V) at maximum current (0.020 A). 3.3 / 0.020 = 165 which means that we need about 165 ohm resistor. I do not have 165 ohm resistor, however I have lot of 330 ohm, so I will use two of them in parallel which result in exactly 165 ohm resistance. Connection is as follows:

In real life:

Now let’s write sketch. Arduino Uno Q support more or less same sketches as older Arduino Unos. Difference is only in using Monitor instead of Serial because it needs utilize interconnection between chips. You can create new app in App Lab by clicking or in terminal:

arduino-app-cli app new analog_humi_temp
cd /home/arduino/ArduinoApps/analog_humi_temp

Then you can edit sources using your favourite editor. Sketch is in sketch/sketch.ino:

vim sketch/sketch.ino

Sketch source code:

void setup() {
  Monitor.begin(9600);
}

void loop() {
  int adcTemp = analogRead(A0);
  float voltageTemp = 3.3 * adcTemp / 1024.0;
  float currentTemp = 1000 * voltageTemp / 165.0;
  float temperature = (currentTemp - 4) * 100 / 16;

  int adcHumi = analogRead(A1);
  float voltageHumi = 3.3 * adcHumi / 1024.0;
  float currentHumi = 1000 * voltageHumi / 165.0;
  float humidity = (currentHumi - 4) / 0.16;

  Monitor.print("Temperature: ");
  Monitor.print(temperature);
  Monitor.print("\tHumidity: ");
  Monitor.println(humidity);
}

And then you can run it by clicking Run in App lab, or in command line:

arduino-app-cli app start .

And logs you can observe using following command:

arduino-app-cli monitor

It should look as follows:

And that’s it. Outputs from industrial analog sensor are now in hands of modern fully digital Arduino Uno Q. In next part I will look to other sensor kit: Omega’s K-Type Thermocouple.

Misaz’s Forum #3: Analog measurements without any digital part

misaz — Sun, 21 Jun 2026 22:16:19 GMT

Hi. I welcome you to my third forum post as part of my participation in On The Line Design Challenge. In this post, I will show how to measure temperature and humidity using it with using just sensor, power supply, and two multimeters (one for temperature, second for humidity).

Current Outputs

The variant of sensor which we received as part of competition has current output. It works as current limiter. Sensor has no ground connection. It connects just to high voltage of power supply which need to be higher then 6V and maximum is listed as 30V. The sensor consume energy from this source and limit’s own power consumption based on measured properties. Output is in the range 4 – 20mA, so sensor always consume at least 4mA which it uses for its own operation. Remaining current is “wasted” for indicating measured value.

Let’s measure some currents which corresponds to humidity and temperature measured by the sensor. Schematics of connection is following. As I mentioned, power pins of sensor (1 and 2) goes to positive voltage of power supply, output of sensors (3 and 4) are connected via amperemeters to negative pin of power supply.

In reality when powered:

Converting Milliamperes to Temperature and Humidity

Formulas for converting measured current (mA) to real values are mentioned in printed manual which come with sensor:

I measured 7.77 mA on temperature output channel, and 13.020 mA on humidity channel. Let’s pass it to formulas:

°C = (7,77 – 4) * (100 / 16) = 23.5625 °C

%RH = (13,020 – 4) / 0,16 = 56.375 %

Misaz’s Forum #2: Breadboarding Industrial Temp + Humidity Sensor

misaz — Sun, 21 Jun 2026 22:14:41 GMT

Hi. I welcome you to my second forum post as part of my participation in On The Line Design Challenge. In this post, I will describe how I prepared Omega HX94 humidity + temperature sensor to enable experimenting with it on breadboard.

Preparing Cable

First step is preparing cable for connecting sensor. It could be definitely done in hacky way, but I tried less hacky way and actually used connector which was bundled in package and mounted it to ethernet cable.

Process is explained in printed manual which come with the sensor:

First step is separating connector by unscrewing tiny screw on side:

Then you can solder, wires to four contacts inside connector.

As you can see, I did not forget about heatshrink, however since contact are large, I need to heat them a lot and heartstring sooner then I needed.

Next step is pulling other part of connector from other side of cable:

Then you can push parts together and fit back small screw.

Another end I made breadboard friendly:

Across whole process, it is good idea to check for open connections and short circuits, but I was lucky this time. This is a result. Now my sensor is breadboarded:

It is sensor with analog output, so next time, I will try it with power supply and multimeter. These two are enough to obtain reading from it.

Misaz’s Forum #1: Kit Unboxing

misaz — Sun, 21 Jun 2026 22:12:40 GMT

Hello Element14 community. Welcome you to my first forum post about kit which I received as part On The Line Design Challenge. I started experimenting pretty late this time and writing I started even later, so this time, I post everything on last day :)

Motivation

My motivation was mainly to play with industrial sensors. Most probably everybody can measure temperature with DHT22 nowadays, but over the time I learnt that in electronics, things are not black and white, but rather different technologies have some pros and cons. So as part of challenge, I want to discover offered high quality industrial humidity sensor with analog output, thermocouples and CAN bus.

Unboxing

Kit come at time. Contained everything I expected + Element14 swag (stickers, letter). The most expensive and interesting part is this analog temperature + humidity sensor from Omega. It comes in large box which contained mounting accessors, cable connector, wall mount accessories and PRINTED MANUAL. Really cool.

Second most interesting part of kit for me is pack of 5 K-type thermocouples:

Another part is CAN PHY Shield. It is powered by chip from Maxim Integrated, so it is shield and evaluation kit in one:

Finally there is some compute. It is not that interesting to me, because I already have and play with the same one. You can read my initial impressions from my first Uno Q here.

Finally, Molex pre-crimped cables as a goodie in the kit:

In next forum post, I will prepare temperature and humidity sensor for operation.

Green Brain - Part V - LabView visualisation

saramic — Sun, 21 Jun 2026 16:50:40 GMT

had never heard of NI LabVIEW before this challenge but after watching some overviews and tutorials it is clearly an industry standard, so I thought I would give it a go.

Recap

Green Brain 🌿 is the idea of tracking plant nodes via an industrial CAN bus

Green Brain - Part I - CAN bus introduction
Green Brain - Part II - Dev setup
Green Brain - Part III - Water Cannon Chaos
Green Brain - Part IV - Nodes Well That Ends Well

Connecting to LabVIEW

The UNO Q already runs a Python Flask REST API that serves the live sensor readings as JSON at pollyanna.local:8080/.../nodes:

[{"node":2,"temp":24.5,"hum":61.0,"seq":42,"ok":true,"age":3},
 {"node":3,"temp":23.1,"hum":58.0,"seq":38,"ok":true,"age":1}]

That means LabVIEW just needs to poll an HTTP endpoint — no new code on the hardware side at all.

What I tried — HTTP GET with JSON parsing

LabVIEW has a built-in HTTP Client GET VI under Data Communication → Protocols → HTTP Client. Getting the raw JSON string back from the API worked fine.

The stumbling block was parsing it. LabVIEW’s Unflatten From JSON needs a type input — an array-of-clusters constant whose structure exactly matches the JSON. You build it outside-in: place an Array Constant shell first, then drop a Cluster Constant inside it, then add typed constants for each field with labels matching the JSON keys exactly.

I got as far as the HTTP response but hit a type mismatch error:

LabVIEW: (Hex 0xFFFA4723) Type mismatch between JSON and LabVIEW.

The debug approach suggested on the NI forums is to wire the cluster-array constant to Flatten To JSON first and compare its output to the real API response — whatever differs is the mismatch. I ran out of time to track mine down fully, but it is close.

Other ways to connect sensors to LabVIEW

For reference, here is how the options compare — from simplest to most capable:

Approach	How	Good for
VISA Serial	Arduino → USB → LabVIEW VISA Read VI	Quick bench work, no network needed
TCP stream	UNO Q opens a socket, streams CSV	Low latency, one-to-one
HTTP REST	LabVIEW polls a URL (what I used)	Already have a server running
MQTT	UNO Q publishes, LabVIEW subscribes	Multiple consumers, buffered
NI DAQmx	NI hardware plugs straight in	Precision timing, industrial use

For temperature monitoring the timing requirements are relaxed, so all of these work in practice. HTTP polling was the natural fit here since the REST API already existed.

Green Brain - distributed greenhouse control platform

Source

https://github.com/saramic/green-brain

Green Brain - Part IV - Nodes Well That Ends Well

saramic — Sun, 21 Jun 2026 14:40:22 GMT

I had built up some proto board nodes for the distributed greenhouse control platform — it was time to wire them all up together and get them talking. It did not go smoothly 😅.

Recap

Green Brain 🌿 is the idea of tracking plant nodes via an industrial CAN bus to ultimately see which plant needs ~~more water cannon 🔫.~~ well watering.

Green Brain - Part I - CAN bus introduction
Green Brain - Part II - Dev setup
Green Brain - Part III - Water Cannon Chaos

Three nodes, one bus

So far I had tested two nodes talking to each other on a work bench. Adding a bunch of twisted pair wiring and a third node to form a proper little network seemed straightforward — it was far from it.

The symptoms were baffling. The first two nodes would work, then one of them would drop off and I would have only one node, and sometimes no nodes would appear at all after some time. This went on in circles for a while, not to mention some circuit board issues early on that prevented two boards working altogether.

All the nodes set up in a greenhouse. You can see they are all connected with twisted pair. Clearly plywood is not the best for a humid greenhouse but I have a future use for the stands

Problem 1 — bad wiring and cold solder joints

The first and most humbling issue: bad physical connections.

Node 1 would print this at startup and hang:

ERR: setBitrate failed — check SPI wiring

I had checked the wiring visually — it looked fine. But to get a more precise diagnosis I added a register read before calling setBitrate, directly checking the CANSTAT register on the MCP2515 chip over SPI:

Serial.print(F("CANSTAT after reset=0x")); Serial.println(readCanstat(), HEX);
// expect 0x80 (config mode) — 0x00/0xFF means SPI not working
if (mcp2515.setBitrate(CAN_500KBPS, CAN_CLOCK) != MCP2515::ERROR_OK) {
    Serial.println(F("ERR: setBitrate failed — check SPI wiring"));
    while (true);
}

Where readCanstat() does a raw SPI read of register 0x0E:

uint8_t readCanstat() {
    SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));
    digitalWrite(MCP_CS_PIN, LOW);
    SPI.transfer(0x03); // READ instruction
    SPI.transfer(0x0E); // CANSTAT register address
    uint8_t val = SPI.transfer(0x00);
    digitalWrite(MCP_CS_PIN, HIGH);
    SPI.endTransaction();
    return val;
}

What came back:

CANSTAT after reset=0x0

The three possible values tell you exactly what is broken:

CANSTAT	Meaning
`0x80`	Chip alive, in config mode — SPI working ✅
`0xFF`	MISO floating high — chip not connected or MISO wire missing
`0x00`	MISO pulled low — CS not going low, or SCK missing, or a short to GND

Getting 0x00 meant the chip was never being selected. After going back with a multimeter and checking continuity on every pin, I found a bad joint on the CS (D10) header pin — it looked soldered but wasn’t making contact. A quick reflow fixed that joint, but 0x00 persisted. I tried loopback mode (which needs no CAN bus wiring at all — the chip loops internally) and still got the same result. That ruled out everything external. The MCP2515 chip itself, or its crystal, was dead. As I didn’t have a spare module to swap out, I swapped with another node, to confirm the module was working, which it was - so there is an issue in some of my wiring on that node - will fix that before I start watering any plants with this system, for sure .

The lesson: when SPI doesn’t work, measure before you guess, and work inward. The CANSTAT read costs two lines of code and points at which layer is broken — wiring, connection, or chip — without having to guess.

The node is a simple build centered around an Arduino Nano and connected to a number of sensors and the CAN transceiver. I have a “USB C” charger/power driver — unfortunately I went cheap from China and they are not true USB C but just a cheap power cable with a USB C connector - you get what you pay for

Problem 2 — duplicate node IDs

Setting node 1 aside with its wiring still unresolved, I focused on getting nodes 2 and 3 reliably onto the bus. But the dashboard still only showed one node.

The cause was embarrassingly simple. The NODE_ID in the firmware is a compile-time #define:

#define NODE_ID    2 // 1 // 3 // change for appropriate node ID

I had been flashing both nodes from the same file without updating the constant each time. Both nodes were broadcasting as node 2 on CAN ID 0x102.

CAN bus arbitration is based on the message ID. When two nodes try to transmit the same CAN ID at the same time, both think they are winning arbitration (the ID bits are identical so neither detects a collision in the arbitration phase) — but their payload bytes differ. The result is a corrupted frame, which every node on the bus detects as an error. Error counters start climbing on all nodes, and the bus degrades.

The fix is obvious in hindsight: flash each node with the correct ID.

Node 1 → NODE_ID 1 → CAN ID 0x101
Node 2 → NODE_ID 2 → CAN ID 0x102
Node 3 → NODE_ID 3 → CAN ID 0x103

Problem 3 — all nodes transmitting simultaneously

With unique IDs, both nodes came up and were visible on the dashboard. But after a minute or two, node 3 would drop off. Then reappear. Then drop off again.

CAN bus handles collisions via arbitration — when two nodes try to transmit at the same moment, the node with the lower ID wins and the other backs off and retries. This is elegant and normally fine. The problem is that my original code used a flat delay(2000) in every node’s loop:

void loop() {
    delay(2000);
    // ... read sensor, transmit
}

If both nodes power up at roughly the same time (same power rail), they stay locked in sync and collide on every single cycle. CAN arbitration resolves each collision, but node 3 (higher CAN ID = 0x103) always loses — it backs off every single time. Under repeated arbitration losses the MCP2515 starts accumulating transmit errors in its internal TEC (Transmit Error Counter).

TEC > 96: warning threshold
TEC > 127: error-passive (node still transmits but with passive error flags)
TEC = 255: bus-off — node stops transmitting entirely

The fix: stagger the transmission timing per node so they are naturally out of phase with each other:

void loop() {
    // Stagger per node so they don't all transmit simultaneously.
    // Base 2s interval + NODE_ID * 300ms offset keeps nodes out of phase.
    delay(2000 + NODE_ID * 300);
    // ...
}

Node 2 now transmits every 2.6 s, node 3 every 2.9 s — and when node 1 is eventually fixed, it will slot in at 2.3 s. They drift in and out of alignment over time but never stay locked together.

Problem 4 — no recovery when a node goes bus-off

Even with staggered timing, occasional collisions can still accumulate errors, especially at 500 kbps with the MCP2515’s tight 8-time-quanta bit timing at 8 MHz. Once a node hits bus-off it stops transmitting and the original code had no recovery logic — the node would stay silent forever until manually reset.

The fix: read the EFLG (Error Flag) register after any failed send and reset the chip if the bus-off bit is set:

MCP2515::ERROR sendErr = mcp2515.sendMessage(&tx);
if (sendErr != MCP2515::ERROR_OK) {
    Serial.print(F("ERR: send failed code=")); Serial.println(sendErr);
    // EFLG bit 5 = TXBO (bus-off). Reset and re-enter normal mode.
    SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));
    digitalWrite(MCP_CS_PIN, LOW);
    SPI.transfer(0x03); SPI.transfer(0x2D); // READ EFLG
    uint8_t eflg = SPI.transfer(0x00);
    digitalWrite(MCP_CS_PIN, HIGH);
    SPI.endTransaction();
    if (eflg & 0x20) {
        Serial.println(F("EFLG: bus-off — resetting MCP2515"));
        mcp2515.reset();
        delay(100);  // give oscillator time to stabilise
        mcp2515.setBitrate(CAN_500KBPS, CAN_CLOCK);
        delay(10);
        mcp2515.setNormalMode();
    }
    return;
}

Note the delay(100) after reset — the original code had only 10 ms here, which is sometimes not enough for the MCP2515’s oscillator to stabilise before you start writing configuration registers.

Seeing errors before they become a problem

To understand what is happening on the bus in real time, I added a helper that reads and prints EFLG and TEC after every successful transmission, but only if something is non-zero (so normal output stays clean):

// EFLG 0x2D: bit5=TXBO(bus-off) bit4=TXEP(err-passive) bit2=TXWAR(warning)
// TEC  0x1C: transmit error counter  REC 0x1D: receive error counter
void printErrors() {
    uint8_t eflg = readReg(0x2D);
    uint8_t tec  = readReg(0x1C);
    if (eflg == 0 && tec == 0) return;
    Serial.print(F(" EFLG=0x")); Serial.print(eflg, HEX);
    Serial.print(F(" TEC=")); Serial.print(tec);
    if (eflg & 0x20) Serial.print(F(" [BUS-OFF]"));
    else if (eflg & 0x10) Serial.print(F(" [ERR-PASSIVE]"));
    else if (eflg & 0x01) Serial.print(F(" [WARNING]"));
    Serial.println();
}

With this in place you can watch TEC climbing before the node goes quiet — it gives you a warning rather than a silent disappearance.

What I learned

Getting even two CAN nodes reliably talking to a master required solving four separate problems: a cold solder joint that looked fine visually, duplicate node IDs from a careless flash, synchronised timing that caused constant arbitration collisions, and no recovery from the bus-off state those collisions eventually caused. None of them were obvious until I had the right instrumentation in place. Node 1 remains a work in progress.

The core lesson is that CAN bus is robust but unforgiving about setup: it handles arbitration and error detection in hardware, but the hardware needs clean wiring, unique IDs, and a firmware that knows how to recover from error states.

Another thing I learned from my last Design Challenge is not to leave the build till too late. I had a fair bit of time to get these stands and circuit boards done. I was hoping to get more sensors on there, including the K-type thermocouples but some late shipment and a busy few weeks means all I got is a DHT11 temperature and humidity sensor.

Fix node 1’s wiring
maybe take some time out to actually grow some plants 😆
Hook it up to LabView

Source

https://github.com/saramic/green-brain

SolarSense - Part 8 - Interfacing Humidity and Temperature

arvindsa — Sun, 21 Jun 2026 05:43:13 GMT

Recap:

I'm building a smart solar monitoring system that uses three panels with a clean reference to eliminate weather effects and directly measure dust-induced losses in real time. One panel stays pristine as a baseline, and comparing the two under identical sky conditions gives a performance ratio that reveals soiling immediately. The goal is to use environmental sensors and edge AI to predict exactly when cleaning is needed, before efficiency drops enough to impact revenue. This beats fixed-schedule cleaning or waiting for output to degrade.Also this is complementary to my Master's thesis of a minute Shape memory Alloy based solar panel cleaning robot

Time is short, So i will jump straight into the points and avoid good formatting of this post. I have SEN66, BMP280 in my board and yet why am i using another sensor for Relative Humidity and Temperature? I needed something that could live away from the PCB, immune to internal heats etc, a probe on a cable, pointed at the actual outdoor air, unaffected by what is happening inside the enclosure. The Omega HX94C is exactly that. It is an industrial-grade transmitter, NEMA 4 rated, with two completely independent 4-20 mA current loops: one for relative humidity (0–100 %RH at 4–20 mA) and one for temperature (0–100 °C at 4-20 mA). You run a pair of wires out to it, excite the loop from your rail voltage, and measure the current. The Current based measurement means, length of wire will not matter, as opposed to voltage based measurement where the voltage will drop along the wire.

I am using a TPS61040DBVT boost converter to get a 12V, HX94C requires excitation voltage of 6-36V for its working. Next is choosing the shunt resistor to measure the full range of 4-20mA. At 150Ohm ressitor

At 4 mA: V = 0.004 × 150 = 0.60 V
At 20 mA: V = 0.020 × 150 = 3.00 V

This is within the range of STM32's ADC

The Firmware

Just like my previous post of the UV sensor, I am simply reading the ADC values for both using

static HAL_StatusTypeDef adc_read_mv(HX94C_t *dev, uint32_t channel, uint32_t *mv)
{
    ADC_ChannelConfTypeDef c = {0};
    c.Channel      = channel;
    c.Rank         = ADC_REGULAR_RANK_1;
    c.SamplingTime = ADC_SAMPLETIME_640CYCLES_5;  /* high source impedance */
    c.SingleDiff   = ADC_SINGLE_ENDED;
    c.OffsetNumber = ADC_OFFSET_NONE;

    HAL_StatusTypeDef st = HAL_ERROR;
    if (HAL_ADC_ConfigChannel(dev->hadc, &c) == HAL_OK &&
        HAL_ADC_Start(dev->hadc) == HAL_OK)
    {
        if (HAL_ADC_PollForConversion(dev->hadc, ADC_TIMEOUT_MS) == HAL_OK)
        {
            uint32_t raw = HAL_ADC_GetValue(dev->hadc);
            *mv = (raw * HX94C_VDDA_MV) / ADC_FULL_SCALE;
            st = HAL_OK;
        }
        HAL_ADC_Stop(dev->hadc);
    }
    return st;
}

Once I have the millivolt reading from the shunt, the math is straightforward:

/* I(µA) = V(mV) / Rsense(Ω) × 1000 */
int32_t i_rh = (int32_t)(rh_mv * 1000U / HX94C_RSENSE_OHMS);
int32_t i_t  = (int32_t)(t_mv  * 1000U / HX94C_RSENSE_OHMS);

The results

The HX94C contributes six tokens: hx_ok (both loops healthy), hx_rh (tenths of a %RH), hx_t (centi-°C), hx_rhi / hx_ti (the two loop currents in tenths of a mA, kept for diagnostics) and hx_flt (the fault bitmask). Decoding the HX94C fields across those samples:

hb	RH loop	RH	Temp loop	Temp
51	15.5 mA	71.7 %	8.3 mA	26.8 °C
52	15.7 mA	72.8 %	8.4 mA	27.8 °C
53	15.0 mA	68.7 %	8.7 mA	29.2 °C
54	15.5 mA	72.1 %	8.3 mA	27.0 °C

BTW, hb is heartbeat that comes every 5second

Final Notes

It's time to submit project, and Will invest time in writing the final post. Feel free to ask questions if i missed anything.

Green Brain - Part III - Water Cannon Chaos

saramic — Sat, 20 Jun 2026 14:39:25 GMT

I promised a water cannon 💦🔫 for my plants, so I had to deliver, if only for a forum post.

Recap

Green Brain 🌿 is the idea of tracking plant nodes via an industrial CAN bus to ultimately see which plant needs more water cannon 🔫.

the idea and the gear

I had the gear for a water cannon. My wife wanted an indoor plant watering system for Christmas so I got her one. But what present is complete without some extra DIY in case I could build one myself. As such I had a few small pumps around. I also had a servo driven X-Y pan and tilt module. How hard can it be to hook that up and make a water cannon.

As an aside, I am also super grateful for a bunch of gear that Element 14 sent to me as a selected challenger.

The pressure is on to use as much of this gear as I can.

Water and electronics

Well there was a lot of learning to be had:

no matter how well you think you seal things - water will still leak. Although I didn’t go all out with silicon, I thought that tight fitting vinyl tubing, electrical tape and relatively low water pressure would be OK — it was not
Water brings in fluid dynamics and things like head, flow, nozzle shapes and the like. Clearly my pump could not initially pump up 300mm of head so I moved the motor closer to the nozzle. There would also be time required to refill the tubing up to the nozzle, as once the pump stops the tube empties. Gardening nozzles from a local hardware are only so good at firing a stream of water
Even small hoses can be stiff enough to move the servos
Pan and Tilt movement requires some planning in how everything interacts. My platform got tangled in the hose, and the wiring also got stuck every so often for the servos as everything moved around
Water is heavy and the motion of water in a hose can change the weight balance of everything and move things around
With all this chaos, I was not bringing the UNO Q anywhere near this water cannon
Noise, pump motors can produce noise, and that noise can be picked up by the servos and move them haywire around the place

It was this last point that really killed this feature. I had removed the servo library entirely, moved the pump power onto a completely separate circuit isolated by a relay — and still the servos would pan to the right and tilt to the top. Stripping down to a pure diagnostic sketch (no servo code at all) revealed the culprit: the servo signal pins were floating high-impedance inputs, acting as antennas and picking up the pump motor’s EMI directly? maybe? ¯_(ツ)_/¯. Even with no code driving them, the servo controllers saw enough noise to chase a position. I ran out of steam getting this to behave reliably with the full mechanical assembly.

community.element14.com/.../20260620_5F00_palying_5F00_around_5F00_with_5F00_firing_5F00_the_5F00_cannon.mp4

I was hoping to re-use the water cannon as a dog deterrent from scratching a door. I think neither the dogs nor the plants will be seeing any water cannon any time soon.

The only clever things I did was write to EEProm to see if a reboot was happening when the pump kicked in and use the Omega temperature probe to hold the tube that fed water to the pump.

I have some MAX6675 which would be cool to connect to the K-Type Thermocouples
there is the Omega Temperature probe
and I am hoping to at least visualise a little bit of this on NI LabView

oh and there is like 24 hours left 🤞

Source

https://github.com/saramic/green-brain

5 RPC power conditioning

pandoramc — Sat, 20 Jun 2026 01:40:24 GMT

Introduction

The cooling system is not only temperature dependable, but the system also requires a device that allows temperature reduction in fluids mainly. This device is known as compressor, it takes a refrigerant gas in a closed loop and circulates it throughout a pneumatic circuit. Additional components are necessary in the circuit because compression and decompression can increase or decrease the temperature of the interchange chamber. The challenge here now is how to use a low-level digital signal to activate a high-power AC load. The solution is a solid-state relay (SSR).

{gallery}Design Platform

Figure 1. Design platform

Methodology

Why use an SSR compared with an electromechanical relay (EMR)?

The EMR requires a specific power supply such as 5VCD or 12VCD. In the Arduino UNO Q system, the digital terminals are controlled by the microcontroller system. According to the datasheet, some I/O pins are 5VCD tolerant, but they only generate up to 4VCD, which voltage is not sufficient to activate the relay. As you may wonder, is there any option to activate the EMC with lower voltage? There are EMC in the market that activates the coil with 3VCD with a 25Ω internal resistance, consequently, it is possible to use this kind of relays. On the other hand, the I/O has a limit of 20 mA maximum of current to be sourced; the 3VCD@25 Ω consumes 120 mA, this means that the I/O pin of the microcontroller will be damaged operating in these conditions. Additionally, the AC loads could create an electric arc when the load is disconnected from the mechanical switch. This arc could discharge in the control signal and damage all the system, requiring isolation or anti arc PCB for high-current loads.

{gallery}I/O features

Figure 2. Microcontroller I/O characteristics

The assembled compressor has ¼ HP, which it represents a load of 186.5 W for a pure resistive load. But the compressor has additional features like inductive and capacitive behavior. This means that a compressor requires a better switch capacity according to the power factor (PF). I considered a PF=0.5, this means that the current will be about 3A@120VAC. An EMC of 12VCD can handle a load of 10A@125VAC but it requires an additional power supply in the system. In order to minimize the possible arc generation derived of switching and avoiding additional components in the system for power conditioning, an SSR is a better option. The SSR for AC loads has semiconductor elements to reach high commutation frequency and these elements reduce the arc generation risk for the power required in this system. An additional feature is the isolation between control and power stages; it allows easy maintenance for the systems and ensures security.

Figure 3. SSR internals (FOTEK SSR Series datasheet)

I implemented the example of blink LED using the RPC interface changing the digital pin 12. This perspective was used with the SSR since the example creates a web user interface by WebUI Arduino brick to turn on/turn off the SSR with a 3V3 digital control signal.

{gallery}SSR test

Figure 4. SSR test and heat sink assembly

#include <Arduino_RouterBridge.h>

void setup() {
    pinMode(D12, OUTPUT);
    // Start with the LED OFF (HIGH state of the PIN)
    digitalWrite(D12, HIGH);

    Bridge.begin();
    Bridge.provide("set_led_state", set_led_state);
}

void loop() {}

void set_led_state(bool state) {
    // LOW state means LED is ON
    digitalWrite(D12, state ? LOW : HIGH);
}

The future

Once the construction blocks are ready, it is time to implement the monitoring system and test the data sharing and control-aided cooling system. At this stage, it is possible to view the data on the UT325F thermometer and capture the data in the Arduino UNO Q for storage. The monitoring system must be implemented in order to view the data using the same web interface system. On the other hand, I had problems with serial port access in the Arduino App Lab, but there are other options such as Inter Process Communication (IPC) to create a data sharing service in the network.

Figure 5. Isolated monitoring cooling system

Friendly Reminder - On The Line Build Period Ends This Sunday

JoRatcliffe — Fri, 19 Jun 2026 15:29:02 GMT

Hi all, just a quick reminder that the deadline for final project write-ups is midnight UK time this Sunday (21st June) so you have just a couple more days to go.

Have a good weekend and looking forward to seeing everyone's final updates before the build period of this design challenge ends!

Making a CAN Network

taifur — Fri, 19 Jun 2026 12:47:28 GMT

Controller Area Network (CAN) is a robust, reliable, and real-time communication protocol widely used in industrial automation and embedded systems. CAN enables multiple nodes to communicate over a single two-wire bus without requiring any central host. A CAN node can be any independent sensor or actuator unit. CAN networks are extensively used in process automation, industrial machinery, and robotic systems. It has very high noise immunity and requires only two wires for communication.

My project involves a CAN network where there will be an ESP32-based CAN node and a CAN gateway based on Arduino UNO Q and MAX33041E CAN transceiver shield from Analog Devices. The ESP32-based node collects sensor data and transmits it over the CAN bus to the central CAN gateway.

The ESP32 has a built-in CAN bus-compatible controller as TWAI which stands for Two-Wire Automotive Interface, it doesn’t have a built-in CAN transceiver, so we must use an external one to connect to a CAN network. So, in my project, I am using the MCP2551 CAN transceiver module to make a CAN node using an ESP32 microcontroller. The MCP2551 transceiver converts the CAN controller's digital TX/RX signals into the differential CANH/CANL bus signals.

I connected the VCC pin of the MCP2551 module to the VIN of the ESP32. Then, connect the GND pin to the ground. Next, connect the TX to GPIO5 and the RX to GPIO4 on the ESP32.

The next step is to connect the CAN Bus High and CAN Bus Low signals to the bus. I connected the CANH and CANL signals directly to the screw terminal on the MAX33041 Shield Evaluation Kit.

For programming the ESP32 module for CAN communication, I installed the following library:

For sending the test message on the CAN bus, I used the following test code.

#include <CAN.h>

#define TX_GPIO_NUM   5
#define RX_GPIO_NUM   4

void setup() {
  Serial.begin (115200);
  while (!Serial);
  delay (1000);

  Serial.println ("CAN Sender");

  // Set the pins
  CAN.setPins (RX_GPIO_NUM, TX_GPIO_NUM);

  // start the CAN bus at 500 kbps
  if (!CAN.begin(500E3)) {
    Serial.println("Starting CAN failed!");
    while (1);
  }
}

void loop() {
  // send packet: id is 11 bits, packet can contain up to 8 bytes of data
  Serial.print("Sending packet ... ");

  CAN.beginPacket(0x12);
  CAN.write('h');
  CAN.write('e');
  CAN.write('l');
  CAN.write('l');
  CAN.write('o');
  CAN.endPacket();

  Serial.println("done");

  delay(1000);

  // send extended packet: id is 29 bits, packet can contain up to 8 bytes of data
  Serial.print("Sending extended packet ... ");

  CAN.beginExtendedPacket(0xabcdef);
  CAN.write('w');
  CAN.write('o');
  CAN.write('r');
  CAN.write('l');
  CAN.write('d');
  CAN.endPacket();

  Serial.println("done");

  delay(1000);
}

SolarSense - Part 7 - Reading the Sky - UV Sensor Interface on STM32

arvindsa — Fri, 19 Jun 2026 09:24:06 GMT

Recap:

Why UV?

The obvious answer you might think is "because UV degrades solar panels like so many other things." And yes, that is absolutely true. UV radiation is the primary driver of photovoltaic cell degradation over years of operation. The casing yellows, the anti-reflection coating breaks down, Tracking cumulative UV dose over time gives a solid predictor for long-term efficiency loss that has nothing to do with dust.

But for this project, That would not be the answer, UV degradation is established fact and there is no point in doing any research on it. But what is interesting is that Solar irradiance (energy per unit area) and UV index do not move in together. Clouds scatter and absorb visible light far more aggressively than they block UV — there are days where the sky looks completely overcast and the UV index is still punishing. The panels see almost no visible light but a significant UV dose. If my model only tracks panel output and misses UV, it cannot distinguish "sky is genuinely dark" from "sky is bright but the panel surface is blocked." UV gives the model context about what the actual sky condition is, independent of what the panels are producing.

The key insight: UV index is a proxy for the radiative environment that survives cloud cover in a way that visible irradiance does not. That independence is exactly what makes it useful as a model input. Now, I have to emphasize that the UV is not an authoritative indicator for passing clouds etc but it will be helpful.

What the GUVA Sensor Actually Does

The GUVA-S12SD is a GaN-based Schottky-type photodiode that is sensitive from roughly 240 nm to 370 nm. That range covers UV-B (280–315 nm) and most of UV-A, but the response peaks around 360 nm and falls to near zero before 400 nm — so visible light is well and truly rejected. The sensor is genuinely seeing UV, not just acting as a general light sensor with a blue filter.

What the chip itself produces is a current proportional to incident UV intensity. The datasheet specifies a responsivity of 0.14 A/W at 300 nm and a photocurrent of 26 nA per UV index unit under sunlight conditions. On the Adafruit breakout module, this current feeds into an op-amp circuit that amplifies it to a usable voltage level. Adafruit’s documentation states the conversion as: V_out = 4.3 × I_photodiode_in_µA

Condition	Approximate V_out	UV Index
Dark / indoors	0.05 – 0.15 V	0 – 1
Overcast outdoor	0.15 – 0.40 V	1 – 4
Hazy sun	0.40 – 0.80 V	4 – 8
Clear noon Kerala summer	0.90 – 1.40 V	9 – 14

My 0.3 V reading at test time is UV Index 3 exactly right for indoors near a window. The formula to compute UV index from the output voltage is simply dividing by 0.1 V, or in firmware:

/* UV index in tenths from GUVA output voltage.
   Per Adafruit: UV index = V_out / 0.1 V  →  tenths = uv_mv / 10 */
uint32_t uv_idx10 = uv_mv / 10U;

The Code

There are two pieces of setup required before any ADC conversion can be usable on the STM32L4. The first is the calibration call unlike older STM32 families, the L4’s ADC has an internal calibration routine that must be run once at startup before the first conversion. It writes offset correction values to the ADC’s internal registers and takes only a few microseconds. Without it, readings come out inaccurate. This goes right after MX_ADC1_Init():

HAL_ADCEx_Calibration_Start(&hadc1, ADC_SINGLE_ENDED);

After that, reading the UV channel each telemetry tick is straightforward. The ADC is in scan mode with four ranks, which means all four channels are sequenced on every trigger — you cannot read just rank 1 in isolation. You have to drain all four values or the next conversion starts out of step.

The Conversion Rank in CubeMX

/* UV sensor (GUVA analog) on ADC1 rank 1 (ADC_CHANNEL_5 / PA0).
   Scan group has 4 ranks; all must be drained on every conversion. */
if (o < (int)sizeof(tlm) - 16)
{
    uint32_t uv_raw = 0;
    if (HAL_ADC_Start(&hadc1) == HAL_OK)
    {
        if (HAL_ADC_PollForConversion(&hadc1, 10) == HAL_OK)
            uv_raw = HAL_ADC_GetValue(&hadc1);
        /* Drain ranks 2-4 (HX94C RH, HX94C TEMP, RAIN AO) */
        for (int r = 1; r < 4; r++)
        {
            if (HAL_ADC_PollForConversion(&hadc1, 10) == HAL_OK)
                (void)HAL_ADC_GetValue(&hadc1);
        }
        HAL_ADC_Stop(&hadc1);
    }
    uint32_t uv_mv = uv_raw * 3300U / 4095U;
    o += snprintf(tlm + o, sizeof(tlm) - o, " uv_mv=%lu", (unsigned long)uv_mv);
}

The Readings

Just Like in the measurement of the temperature at the thermocouple, I do not have a calibrated UV source or measurement system. So I am going to just see if the multi-meter reading of signal output is same as what STM32 picks up.

Final Notes

One line of calibration code. That is the whole lesson here. HAL_ADCEx_Calibration_Start on the STM32L4 is not optional.

The UV sensor is live and reading sensibly. Next I want to run it through a full day outdoors and plot the curve rising from low values before sunrise, peaking around local solar noon, dropping back. If the curve shape looks right and correlates with what I would expect for the season and latitude, I will be satisfied that the sensor is working correctly.

After that, the environmental sensors BMP280 and the HX94C are next in the queue. The ADC scan group already has the HX94C analog channels wired up, it is just waiting for code similar to what I did here. The sensing stack is getting close to complete. I am yet to solder the BMP280. I am hesitant because deep down in my heart, It feels like pressure is not going to be an useful parameter.

SolarSense - Part 6 - Reading the Heat at K Type Thermocouple using MAX31855.

arvindsa — Fri, 19 Jun 2026 06:24:41 GMT

Recap

Why a Junction Thermocouple?

If you read Part 1, you would have seen that in the Proof of Concept I was already using the SEN66 for ambient temperature. And going forward I am planning to use the Omega HX94C sensor for temperature and relative humidity — it is a more accurate sensor for ambient conditions and handles the Kerala humidity far better.

So then, why do I also have a thermocouple on each panel? Because a thermocouple measures surface temperature, not ambient. What I want to know is how hot the panel itself gets, not the air around it. The two are very different. A panel sitting under direct sun in Kerala can be 20–30°C hotter than the air temperature. That heat is not just a background condition, it directly affects the panel's output. Crystalline silicon panels lose roughly 0.4% of their output per degree Celsius of cell temperature rise. Over a full day of sun exposure that is a measurable and significant drop.

The key insight: I am not just monitoring soiling. I am studying what long-term heat exposure does to each panel's efficiency over time. If one panel consistently runs hotter than the others. maybe due to its mounting position, or partial shade that creates hotspot effects that shows up in the data as a slow efficiency drift that has nothing to do with dust. Without the surface temperature measurement I would not be able to separate that from actual soiling. Now, these are just my hypothesis, and hope to get it proven. What better way to make use of the OmegaDwyer 5SRTC-TT-K-24-72 Thermocouple, K, 0 °C, 260 °C, 80 ", 2 m (Pack of 5)

The PCB has three MAX31855KASA+ thermocouple amplifier chips, one per panel with K-type thermocouple inputs. For now, I am going to solder only one chip. I actually found that the module is cheaper than the chip itself, so I just harvested it from the module.

Interfacing with MAX31855

The MAX31855 is a single-chip thermocouple amplifier with SPI output. You wire a K-type thermocouple to the two input pins, and the chip handles the cold-junction compensation internally using a temperature sensor on the die itself. What comes out of the SPI port is a fully compensated temperature reading. No lookup tables, no Seebeck coefficient math in firmware. The chip does it all.

The catch? It is completely read-only. There are no configuration registers. No setup. No init sequence. You pull CS low, clock out 32 bits, release CS, and you have your reading. That is the entire protocol.

Those 32 bits break down like this:

The three fault bits in [2:0] tell you exactly what is wrong with the thermocouple wiring. OC means nothing is plugged in. SCG and SCV mean the wire is touching something it should not. When any of these are set, bit 16 goes high and the thermocouple reading in [31:18] is cleared to zero. Here is the Descriptions from the Datasheet

Touching a Dusty Part of CubeMX and Extracting Data from SPI Frame

Usually, in CubeMX I rarely configure settings of SPI, I just make it the default settings of 8Bits per SPI frame.But 32Bits is frame size? My LORA Module required 16bits frame. So either make it 32bus for now, then manage it when i actually start using lora or I can make it future proof now. So, Math Says 32 bits is just two 16-bit transfers. HAL can do two back to back with CS held low. No reconfiguration needed, no disruption to the lora driver. and I had to keep the SPI Clock speed at 5Mhz as limited by the MAX31855. To set these, I went to a part of CubeMX where I have rarely been.

This settings translate to

hspi1.Instance               = SPI1;
hspi1.Init.Mode              = SPI_MODE_MASTER;
hspi1.Init.Direction         = SPI_DIRECTION_2LINES;
hspi1.Init.DataSize          = SPI_DATASIZE_16BIT;
hspi1.Init.CLKPolarity       = SPI_POLARITY_LOW;   /* CPOL = 0 */
hspi1.Init.CLKPhase          = SPI_PHASE_1EDGE;    /* CPHA = 0 */
hspi1.Init.NSS               = SPI_NSS_SOFT;
hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16; /* 80MHz/16 = 5MHz */
hspi1.Init.FirstBit          = SPI_FIRSTBIT_MSB;
HAL_SPI_Init(&hspi1);

The actual read in the driver then looks like this:

static HAL_StatusTypeDef read_raw(MAX31855_t *dev, uint32_t *raw)
{
  uint16_t w[2];
  HAL_GPIO_WritePin(dev->cs_port, dev->cs_pin, GPIO_PIN_RESET);
  HAL_StatusTypeDef st = HAL_SPI_Receive(dev->hspi, (uint8_t *)w, 2, SPI_TIMEOUT_MS);
  HAL_GPIO_WritePin(dev->cs_port, dev->cs_pin, GPIO_PIN_SET);
  if (st == HAL_OK)
    *raw = ((uint32_t)w[0] << 16) | w[1];
  return st;
}

For the Thermocouple temperature i used the code to extract the data from the SPI Frame

int32_t t = (int32_t)(int16_t)(raw >> 16) >> 2;

and for the Cold junction

int32_t c = (int32_t)(int16_t)(raw & 0xFFFF) >> 4;

The Full Driver

here is the driver's

/**
 * @file    max31855.h
 * @brief   Driver for the Maxim MAX31855 SPI thermocouple amplifier.
 *
 * SolarSense populates three MAX31855KASA+ (K-type) on SPI1:
 *   
 * The device is read-only; no configuration registers exist. One 32-bit
 * SPI frame (two 16-bit HAL transactions) yields the thermocouple temp
 * (0.25 °C/LSB) and the on-chip cold-junction temp (0.0625 °C/LSB), plus
 * three open/short fault bits.
 */
#ifndef MAX31855_H
#define MAX31855_H

#include "stm32l4xx_hal.h"

/* Fault bits returned in the faults byte (mirrors hardware bits [2:0]). */
#define MAX31855_FAULT_OC   0x01U  /* thermocouple open circuit   */
#define MAX31855_FAULT_SCG  0x02U  /* thermocouple shorted to GND */
#define MAX31855_FAULT_SCV  0x04U  /* thermocouple shorted to VCC */

typedef struct {
    SPI_HandleTypeDef *hspi;
    GPIO_TypeDef      *cs_port;
    uint16_t           cs_pin;
    uint8_t            present;   /* 1 after a successful Init() SPI probe */
} MAX31855_t;

/* Bind the driver to an SPI bus and a software CS pin. Performs one SPI
   read to confirm the device is wired. Sets present = 1 on success. */
HAL_StatusTypeDef MAX31855_Init(MAX31855_t *dev, SPI_HandleTypeDef *hspi,
                                GPIO_TypeDef *cs_port, uint16_t cs_pin);

/* Read thermocouple and cold-junction temperatures (tenths of °C, signed)
   and the fault byte. Any output pointer may be NULL.
   Returns HAL_OK on a clean read; HAL_ERROR if the SPI transaction fails.
   A non-zero *faults value means the thermocouple has a wiring fault and
   *tc10 is unreliable, but *cj10 (board ambient) remains valid. */
HAL_StatusTypeDef MAX31855_Read(MAX31855_t *dev,
                                int32_t *tc10, int32_t *cj10,
                                uint8_t *faults);

#endif /* MAX31855_H */

```

/**
 * @file    max31855.c
 * @brief   Driver for the Maxim MAX31855 SPI thermocouple amplifier.
 */
#include "max31855.h"

#define SPI_TIMEOUT_MS 10U

/* Pull CS low, clock out 32 bits as two 16-bit HAL frames, release CS. */
static HAL_StatusTypeDef read_raw(MAX31855_t *dev, uint32_t *raw)
{
    uint16_t w[2];
    HAL_GPIO_WritePin(dev->cs_port, dev->cs_pin, GPIO_PIN_RESET);
    HAL_StatusTypeDef st = HAL_SPI_Receive(dev->hspi, (uint8_t *)w, 2, SPI_TIMEOUT_MS);
    HAL_GPIO_WritePin(dev->cs_port, dev->cs_pin, GPIO_PIN_SET);
    if (st == HAL_OK)
    {
        /* SPI1 is MSB-first 16-bit mode, so w[0] = bits[31:16], w[1] = bits[15:0]. */
        *raw = ((uint32_t)w[0] << 16) | w[1];
    }
    return st;
}

HAL_StatusTypeDef MAX31855_Init(MAX31855_t *dev, SPI_HandleTypeDef *hspi,
                                GPIO_TypeDef *cs_port, uint16_t cs_pin)
{
    dev->hspi    = hspi;
    dev->cs_port = cs_port;
    dev->cs_pin  = cs_pin;
    dev->present = 0;

    /* No config registers to write; probe by doing one SPI read. */
    uint32_t raw;
    if (read_raw(dev, &raw) != HAL_OK)
        return HAL_ERROR;

    dev->present = 1;
    return HAL_OK;
}

HAL_StatusTypeDef MAX31855_Read(MAX31855_t *dev,
                                int32_t *tc10, int32_t *cj10,
                                uint8_t *faults)
{
    uint32_t raw;
    HAL_StatusTypeDef st = read_raw(dev, &raw);
    if (st != HAL_OK)
        return st;

    if (faults)
        *faults = (uint8_t)(raw & 0x07U);

    /* Thermocouple temp: bits[31:18], 14-bit two's complement, 0.25 °C/LSB.
       Cast top half to int16_t (sign bit preserved), arithmetic-right-shift
       by 2 to drop the reserved bit and FAULT bit.
       Tenths: raw14 × 0.25 × 10 = raw14 × 5 / 2. */
    if (tc10)
    {
        int32_t t = (int32_t)(int16_t)(raw >> 16) >> 2;
        *tc10 = (t * 5) / 2;
    }

    /* Cold-junction temp: bits[15:4], 12-bit two's complement, 0.0625 °C/LSB.
       Same trick on the bottom half; shift right 4 drops reserved + fault bits.
       Tenths: raw12 × 0.0625 × 10 = raw12 × 10 / 16. */
    if (cj10)
    {
        int32_t c = (int32_t)(int16_t)(raw & 0xFFFFU) >> 4;
        *cj10 = (c * 10) / 16;
    }

    return HAL_OK;
}

this plus a lot of Serial print commands, Get the output

Now, the serial port is going to output a lots of data because I just put in the template for all sensors so that i can test it out with the LabView. But the tc3_c and tc3_cj are the numbers that matter. But it was not right, It showed 305 and 308 which means it is 3.05 and 3.08deg respectively (look at the top few lines of the serial). I simply multiplied the value in the code by 10 to get 3070 and 3080 respectively.There was nothing logical i know or found to make this multiplication, but it simply made sense to do it. I tried holding the junction with my hand and the temperature rose accordingly.

How Accurate am I reading it?

This is going to be a difficult one to answer because I do not have a True Reference or A Calibrated device to measure and check. But for now, I tired reading at the tip of my TS101 soldering station set at 210 deg C, I got 185 degC. Now, the Tip might not be exactly 210deg depending on where the control sensor of the soldering iron is, but I am gonna see if calibrating it it by a combination of Boiling water and Ice will be helpful. That i will document in the last post.

Final Notes

This being a stretch goal, I completed it before even completing my primary goals just because it was easy and convenient. But at this time of writing the post I have completed all of them and I am collecting data from the final device. More posts to come.

Measuring temperature using Omega K-Type Thermocouple

taifur — Thu, 18 Jun 2026 06:22:25 GMT

For my project, the measurement of a machine temperature is required. A thermocouple is one of the best sensors for measuring the temperature of an electrical machine. Thanks to Omega for sending several K-type thermocouples as a part of the Challenger kit. These thermocouples are capable of measuring from -200°C to 1250°C. For measuring temperature using any microcontroller, we need to use an amplifier and signal conditioning circuit like MAX31855 or MAX6675. As the thermocouples came without any amplifier module, I managed a MAX6675 module to connect the thermocouple with the ESP32. The following image shows my connection of the thermocouple with the amplifier module.

Then I connected the ESP32 module with the amplifier module as shown in the following image.

The

ESP32 module was programmed using Arduino IDE. I installed the MAX6675 Arduino library.

Then uploaded the following test code to the ESP32 module:

#include "max6675.h"

int thermoDO = 19;
int thermoCS = 23;
int thermoCLK = 5;

MAX6675 thermocouple(thermoCLK, thermoCS, thermoDO);

void setup() {
  Serial.begin(9600);

  Serial.println("MAX6675 test");
  // wait for MAX chip to stabilize
  delay(500);
}

void loop() {
  // basic readout test, just print the current temp
  
  Serial.print("C = "); 
  Serial.println(thermocouple.readCelsius());
  Serial.print("F = ");
  Serial.println(thermocouple.readFahrenheit());
  
  // For the MAX6675 to update, you must delay AT LEAST 250ms between reads!
  delay(1000);
}

At room temperature, without connecting anything, the thermocouple, I got the following response in the serial terminal:

I connected my hot soldering iron tip to the thermocouple and got the following data.

I noticed the temperature has increased, but I am not sure whether this is the correct temperature or if I need calibration. I will try to find it later.

4 Communication rocks!!!

pandoramc — Tue, 16 Jun 2026 01:58:24 GMT

A computer system is not able to process an analog signal. Despite this fact, a digital system, such as a processor, can process an enormous amount of data to make decisions about physical variables. How is a physical phenomenon described by the data stored in a memory section? The answer is simple but quite difficult to implement. An analog-to-digital converter is required to take an analog signal and convert it to digital data. This process involves a time-based sampling to observe the phenomenon, quantify the observed value and assign a digital code that is representative for the digital system.

Figure 1 Analog-to-Digital convertion representation

One of the most important components in signal processing, whether analog or digital, is the signal conditioner. A signal conditioner is part of the sensing system since it converts a phenomenon into a voltage response. There are many types of temperature transducers that detect changes in the environment such as RTDs and NTCs. This time, thanks to the On the Line Design Challenge, there are K-type thermocouples. In my last blog I wrote about the probe mounting for harsh environments and fluid isolation. However, a question arose: How can I connect the probe to store data in the processor memory when the sensing stage provides some mV/°C and the dynamic range of the ADCs is huge compared with the thermocouple response? An example considered is for a 1V1 ADC_REF (silicon gap) for a 10-bit resolution ADC. In this case, the minimum detectable value is around 1.07 mV, but the ADC_REF must be small to detect small changes in temperature. This is not feasible for the measurement system using the default references on the board for each channel required.

Methodology

After exploring multiple options for creating an interface between the thermocouple and the data storage, I decided to use a commercial option to acquire temperature data. The first option I considered was using the DeviceNet protocol with an Allen Bradley PLC. Although the 1769-32E CPU is not recommended for new designs, it can perform interesting tasks. At least four thermocouples can be connected using the 1769 Thermocouple module, but the connection of Cold Junction Compensation (CJC) is required for the correct measurement of the environment. On the other hand, special thermoblocks and wire extensions are required for the connection with the module since a small wiring variation can induce offset and/or non-linearities in the measurement. Another option is to use temperature transmitters or analog front ends (AFE). While these elements have the same inconvenience of the thermocouple module for wiring, most of the AFE found has a temperature range above 0 °C. For test purposes are useful, but in the future the system requires measurement below this magnitude. The last option is the UT325F of UNI-T thermometer system. This equipment has up to 4 channels in multiple kinds of probes; it is possible to adjust the temperature offset since the CJC is internal and it has a Windows/Android application to capture data.

{gallery}Interfaces

Figure 2 Data acquisition assembly options for thermocouple connection

As you wonder, I asked myself a question, is it possible to get data in the Arduino UNO Q Linux system? The answer, YES!!!

I did a lot of tests capturing the data and recognizing patterns in the received frame. The procedure consisted of the connecting and disconnecting the probes in each channel of the thermometer. I recognized some number patterns heating the probe with my hand, but I was not able to understand it at all. Aided by an AI tool I recognized two important patterns the data is transmitted in little endian while the CRC is transmitted in big endian. The data is repetitive, but I am not sure why at the moment to write this blog. And the third pattern recognized completely by me is to inform if a probe is connected to a specific channel. This task was in a PC since the equipment has a CH340 USB-to-UART variant which Arduino UNO Q Linux image has not a driver to handle communication. This was solved compiling and installing a driver available here: https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers/linux

And the results were incredible

Figure 3 Project transfer from the Arduino UNO Q to the PC by ssh copy

Figure 4 Serial port frame capture with data decoding

import serial
import struct
import time
from datetime import datetime

SERIAL_PORT = '/dev/ttyCH341USB0'
BAUD_RATE = 115200
TIMEOUT = 1
FRAME_LEN = 56

def compute_checksum(data):
	"""Calculate big-endian 16-bit checksum"""
	total = sum(data) & 0xFFFF					# 16-bits CRC
	return total.to_bytes(2, 'big')

def parse_temperature(frame):
	"""
	Extract 4 Float numbers in little endian format
	Initial index is equal to 5
	"""
	start = 5
	floats = []
	for i in range(4):
		b = frame[start + i*4 : start + i*4 + 4]
		if len(b) == 4:
			val = struct.unpack('<f', b)[0]
			floats.append(val)
		else:
			floats.append(None)
	return floats

def parse_connected(frame):
	"""
	Verify that a Thermocouple N has a connected sensor
	Each bytes illustrates that the channel has a connected thermocouple if
	the code is 0x00, or 0x30 if not
	"""
	start = 21
	channels = []
	for i in range(4):
		v = frame[21 + i]
		if v == 0x00:
			channels.append(True)
		else:
			channels.append(False)
	return channels

def read_and_validate(ser):
    """Serial port data reading. If the received frame is valid then return it"""
    buffer = bytearray()
    while True:
        byte = ser.read(1)
        if not byte:
            continue
        buffer.append(byte[0])

        if len(buffer) >= 2 and buffer[-2] == 0xAA and buffer[-1] == 0x55:
            while len(buffer) < FRAME_LEN:
                b = ser.read(1)
                if not b:
                    break
                buffer.append(b[0])
            if len(buffer) >= FRAME_LEN:
                frame = buffer[-FRAME_LEN:]
                data_part = frame[:-2]
                recv_checksum = frame[-2:]
                calc_checksum = compute_checksum(data_part)
                if recv_checksum == calc_checksum:
                    return frame
                else:
                    print("Wrong checksum")
                    buffer.pop(0)
            else:
                buffer.clear()
        else:
            if len(buffer) > FRAME_LEN * 2:
                buffer = buffer[-FRAME_LEN:]


def main():
	try:
		ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=TIMEOUT)
		dFile = open("data.csv", "w")
		dFile.write("t,T1,T2,T3,T4\n")
		while True:
			ser.reset_input_buffer()
			frame = read_and_validate(ser)
			if frame:
				print("Received Frame [hex]:", ' '.join(f'{b:02x}' for b in frame))
				print("╔═════════════════════════╗")
				temps = parse_temperature(frame)
				valid = parse_connected(frame)
				dFile.write(f"{datetime.now().strftime('%Y-%m-%d %H:%M:%S')},")
				for i in range(0, len(temps)):
					if(valid[i] == True):
						print(f"║ Temperature {i + 1}: {temps[i]: 5.1f} °C ║")
						dFile.write(f"{temps[i]},")
					else:
						print(f"║ Temperature {i + 1}:  NaN  °C ║")
						dFile.write(f"NaN,")
				print("╚═════════════════════════╝", end="\033[F\033[F\033[F\033[F\033[F\033[F")
				dFile.write("\b\n");
				time.sleep(1)
	except serial.SerialException as e:
		print(f"Serial por error: {e}")
	except KeyboardInterrupt:
		print("\nExecution stopped by the user")
	finally:
		if 'ser' in locals() and ser.is_open:
			ser.close()
		if 'dFile' in locals() and not dFile.closed:
			dFile.close()

if __name__ == "__main__":
	main()

The future

Now, it is time to integrate the RCP interface for the usage of the microcontroller to activate the compressor. Actually, the implemented script can receive data, process and write a CSV file to be stored in memory for future consult and analysis, but it is not able still to make decisions. The last test will consist of data sharing between the processor and microcontroller to test the system threshold and hysteresis for a full-operation test.

{gallery}achievements

Figure 5 Actual temperature data storing achievement

SolarSense - Part 5 - Making an Live Dashboard using Lab View

arvindsa — Sat, 13 Jun 2026 08:57:22 GMT

Recap:

Hello Lab View, Haven't seen you since my Undergrad

The last time I used Lab View was during my Undergraduate academics in Control Lab, I never was a fan of high level graphical style programming plus all of my work never required Lab View, so I was happy until this challenge came up. On the bright side, I am happy to say that there is Community version available. I don't remember seeing the community when I used it. Without any research of what is the difference between Community vs Professional was, I went to the community version. Obviously to activate the Community version, I had to create an account. It was No mess, No Fuss Installation.

In this post, the aim will be to create a dashboard to show values published by the Arduino Q via TCP packets. These will include, the Solar panel outputs, The Environmental parameters such as UV, AQI, Humidity and then the system parameters such as battery, Error flags etc.

Getting A Gauge up and Running

The Python Code

I made a quick code to keep sending values 4 times a second. Apologies for no comments.

import math
import socket
import threading
import time

HOST = "0.0.0.0"
PORT = 9000
UPDATE_INTERVAL = 0.25


def read_value(t: float) -> float:
    return round(50 + 45 * math.sin(t / 3.0), 2)


def handle_client(conn: socket.socket, addr) -> None:
    print(f"[+] client connected: {addr}")
    start = time.monotonic()
    try:
        while True:
            value = read_value(time.monotonic() - start)
            conn.sendall(f"{value}\r\n".encode("ascii"))
            time.sleep(UPDATE_INTERVAL)
    except (ConnectionResetError, BrokenPipeError, OSError):
        pass
    finally:
        conn.close()
        print(f"[-] client disconnected: {addr}")


def main() -> None:
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as server:
        server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        server.bind((HOST, PORT))
        server.listen()
        print(f"Gauge TCP server listening on {HOST}:{PORT}  (Ctrl+C to stop)")
        try:
            while True:
                conn, addr = server.accept()
                threading.Thread(
                    target=handle_client, args=(conn, addr), daemon=True
                ).start()
        except KeyboardInterrupt:
            print("\nShutting down.")


if __name__ == "__main__":
    main()

The Front Panel of Lab View

A Plain Gauge with range 0-100 and a Stop button

Block Diagram

When Creating a VI, it opens two window, one is the UI Editor and the other is the Block Diagram Editor. The Block diagram is where is the logic is executed. I Referred to the YouTube video https://www.youtube.com/watch?v=LMtdLqmRnVU to make the TCP Communication logic. One thing to note is that for all Inputs and Outputs to work in a loop, it has to be in the loop, else only the value of input at the start of first iteration of the Loop will be used. Any changes or presses to the Buttons will not be considered.

The Result

10mins into Lab View, I have a live dashboard.

Building the Actual Panel

To get a full picture of the situation I need to have the following data

Variable	Type	Unit	Range
panel_efficiency[0]	DBL	%	0–100
panel_efficiency[1]	DBL	%	0–100
panel_efficiency[2]	DBL	%	0–100
soiling_ratio	DBL	%	5.0–29.0
battery	DBL	%	0–100
tank_level	DBL	%	0–100
humidity	DBL	%	10–70
temperature	DBL	°C	13–37
uv	DBL	Index	2.0–8.0
aqi	INT	µg/m³	20–80
status_ok	INT	—	0 or 1
error	INT	—	0 or 1

These data will be sent as a JSON over TCP. For testing, i will be randomizing the values such that they oscillate between minimum and maximum.

{
  "panel_efficiency": [25.5, 24.8, 22.3],
  "soiling_ratio": 15.2,
  "humidity": 65.0,
  "temperature": 28.5,
  "uv": 6.2,
  "aqi": 55,
  "battery": 78.4,
  "status_ok": 1,
  "error": 0,
  "tank_level": 78.4
}

The Front Panel

The Block Diagram

www.youtube.com/watch

This is where I started running into trouble. I initially thought the Unflatten from JSON block would simply split the JSON into key–value pairs, but it wasn’t that straightforward. I had to declare the structure of the expected JSON format using a cluster definition—the long vertical box to the left of the while loop. I was able to get this working by referring to a YouTube video https://www.youtube.com/watch?v=kx1E5QnnLy0. However, I ran into another issue when declaring a Boolean. For some reason, I couldn’t find the Boolean type. To save time, I modified the Python code to send the status flags as 0/1 integers instead of Booleans.

I assumed I could use an integer-to-Boolean conversion block while reading the JSON from the server, but I couldn’t find such a block either. As a workaround, I ended up using the “If Not Equal” comparison block instead. I also noticed that the UI started being slow. Not sure why.

community.element14.com/.../LabVIEW_5F00_DxuZ83tJQ9.mp4

The Final Working

I have not been able to get the XY Graph to work yet, But to me, It's a stretch goal which i added impromptu Hopefully I should get it working by the deadline.

Final Notes.

I had some time reminiscing my college days using Lab View, fighting with my classmates to claim the limited number of floating license of Lab VIew, Coordinating with my friends so that They will claim the license the second I surrender mine back into the common pool, Getting the dashboard to work was probably the easiest part, but I still had fun. The PCB for the data collection has completed fabrication and is on the way, it should be with me in a day or two, I am still using the old POC to keep the data collection alive till then.

Smart Ventilation Motor Monitoring System #5 Getting Started with CAN Protocol on XMC4200 Platform2GO in Arduino

fyaocn — Fri, 12 Jun 2026 03:21:40 GMT

1 Getting start with CAN

For test CAN in the other end, XMC4200 platform2go is used

CAN (Controller Area Network) is for industrial and automotive embedded communication. It’s a robust, multi-master serial protocol designed for reliable real-time data exchange between microcontrollers, sensors, and actuators—even in electrically noisy environments. Infineon XMC4200 Platform2GO with the Arduino IDE can give a quick glance.

2 CAN in a glance

CAN was developed by Bosch in the 1980s for automotive applications, but it’s now used widely in industrial automation, robotics, and aerospace. Key features,

No single “master” device; any node can send data when the bus is free.

Error resilience: Built-in error checking, arbitration, and retransmission to ensure data integrity.

Two message formats: Standard CAN (11-bit ID): Shorter, faster identifiers for simple systems and Extended CAN (29-bit ID): Longer identifiers for complex networks with many nodes.

Flexible data length: Classic CAN supports up to 8 bytes of data per packet; newer CAN FD extends this to 64 bytes.

For the XMC4200, the on-chip CAN peripheral is fully supported by Infineon’s Arduino core, making it easy to prototype CAN applications without low-level register programming.

CANH and CANL are two wires for communication on 12V or 24V bus.

3 USING ARDUINO IDE

Using Arduino is quick start for can

#include <CAN.h>
void setup() {
  Serial.begin(9600);
  while (!Serial);

  Serial.println("CAN Sender");

  // start the CAN bus at 500 kbps
  if (!CAN.begin(500E3)) {
    Serial.println("Starting CAN failed!");
    while (1);
  }
}

void loop() {
  // send packet: id is 11 bits, packet can contain up to 8 bytes of data
  Serial.print("Sending packet ... ");

  CAN.beginPacket(0x12);
  CAN.write('h');
  CAN.write('e');
  CAN.write('l');
  CAN.write('l');
  CAN.write('o');
  CAN.endPacket();
  Serial.println("done");
  delay(1000);
  CAN.beginExtendedPacket(0xFFF);
  CAN.write('w');
  CAN.write('o');
  CAN.write('r');
  CAN.write('l');
  CAN.write('d');
  CAN.endPacket();

  Serial.println("done");

  delay(1000);
}

The code is simple , put loop code in the the CAN bus

serial.begin(9600): Initializes the UART serial port at 9600 baud for debug messages.
CAN.begin(500E3): Initializes the CAN bus at 500 kbps, one of the most common baud rates for automotive and industrial applications. If initialization fails (e.g., hardware issue), the code prints an error and stops.

Then in loop

CAN.beginPacket(0x12): Starts a new standard CAN packet with the 11-bit identifier 0x12.
CAN.write(): Adds data bytes to the packet. Here, we’re sending the ASCII characters 'h', 'e', 'l', 'l', 'o' (5 bytes total, well within the 8-byte limit).
CAN.endPacket(): Finalizes and sends the packet over the CAN bus.

Then in extend

CAN.beginExtendedPacket(0xFFFFF): Starts an extended CAN packet with the 29-bit identifier 0xFFFFF. This is useful when you need more unique IDs for a large network of devices.
The rest works the same way: we send the characters 'w', 'o', 'r', 'l', 'd' as data bytes.

4 Test for CAN on XMC4200

Baud Rate Matching: All devices on the CAN bus must use the same baud rate. 500 kbps is standard for automotive, 125 kbps is common for industrial applications.

Termination Resistors: Always add 120Ω resistors at the two ends of the CAN bus to eliminate signal reflections. This resistor is soldered in this board.

Common Ground: All devices on the bus must share a common ground reference for reliable communication. Although only two line is enough for communication.

The test result is output in serial terminal

Now it is ready for the CAN bus run as expected.

SolarSense - Part 4 - CAN Protocol Deep Dive and Implementation

arvindsa — Wed, 10 Jun 2026 06:23:28 GMT

Recap

Why CAN?

Because I CAN.. Alright i will stop with the Pun. Why have CAN to say if a panel is soiled or clean? The real challenge comes during the AI training phase. Since I need to experiment with different timeframes of statistical compression (avg, max etc). I need to collect massive amounts of raw sensor data from the three panels over weeks or months to train an edge AI model that can predict soiling. That data volume cannot flow over regular wireless. I am talking about 10 sensor types updating at different rates, with measurements from multiple sample points. LoRa bandwidth would be a bottleneck. WiFi demands power and gets unreliable outdoors. Both add latency and packet loss that corrupt the data stream. Coming to think of it, it is like Stock trading, you need to identify the right timewindow to calculate the indicators of performance.

My plan is to eventually deploy the measurement station at a remote location on a rooftop or pole - away from the gateway for safety and unobstructed sky access. The CAN bus with shielded twisted pair can run 50+ meters reliably without the noise and dropout issues of wireless. That cable will carry all the raw telemetry at full fidelity back to the gateway for logging and later analysis.

CAN also gives me a standardized, well understood protocol. Building custom serial handling for this much data would be error prone and hard to debug. CAN peripheral support is built into the STM32 hardware. The protocol itself enforces packet integrity with checksums and acknowledgments. If a frame gets corrupted, i know about it instead of silently logging garbage.

Stress testing my implementation early on a controlled bus lets me validate reliability before field deployment. If the CAN implementation fails during a rainstorm in Kerala, i will lose months of data. Better to find problems in the lab.

Once the model is trained and deployed remotely, the picture changes completely. At that point, the edge device runs the AI inference on all the raw sensor data locally and only sends back the results - a simple alert saying clean or soiled, confidence level, maybe a status update every hour. That traffic is tiny and LoRa is perfect for it. A few kilobytes per day over LoRa is completely practical. So the architecture splits nicely: CAN for the high bandwidth data collection phase, LoRa for the low bandwidth deployment phase.

The Protocol Design

The protocol uses classic CAN - standard 11-bit IDs and 8-byte payloads at 500 kbps. I avoided CAN FD because the older Nucleo boards do not support it well, and 500 kbps is more than enough for my use case.

I organized the data into three traffic classes by update frequency:

Fast (1 Hz): Panel voltages and currents - these change every second as clouds pass. Four frames, one for each panel and one for UV.

Medium (0.2 Hz): Thermocouple and battery data. These are stable unless the environment shifts significantly.

Slow (0.1 Hz): Air quality, pressure, humidity, temperature, and rain detection. These sensors are sluggish and do not need to be read faster anyway.

The diagnostics channel runs at 1 Hz in both directions - time sync from the gateway to the panel, and a heartbeat from the panel back with sequence numbers and error flags. And of-course these frequency are quite aggressive, and I hope to reduce them down soon within a day or two of data collection. Aha, That gives me an idea. i should be able to set the frequency over CAN Bus. Rather than reprogram it. Why did i not think of that?

The Data Structures

Looking at the code, each sensor type has its own struct. For example, a panel measurement looks like this:

typedef struct {
    uint16_t v_mv;   // voltage in millivolts
    int32_t  i_ua;   // current in microamps
    int32_t  p_uw;   // power in microwatts (calculated at gateway)
} SS_Panel_t;

All the fixed point scaling is documented in one place so there is no guessing. Voltage is in mV, current in microamps, temperature in degrees times 10 or times 100 depending on the sensor. This keeps the integers and avoids floating point over the bus.

The frame layout is compact. A panel reading takes 6 bytes: 2 for voltage, 4 for current. The gateway computes power on arrival, so we do not waste payload space transmitting it. Total bus load at worst case is only 0.15 percent of 500 kbps capacity - we could handle backfill replays of thousands of missed frames per second if the SD card goes offline temporarily.

The Sender - F103 Nucleo

The Nucleo-F103RB is the first Nucleo board I purchased some 10 years ago when I started my STM32 Journey. but it has a CAN peripheral it may be the older BX standard, lower frame size but that is all i need. The sender firmware is split into two modes.

Loopback mode runs a stress test. All 10 frame types are sent as fast as the CAN peripheral can push them - roughly one frame per millisecond - and the firmware waits for each echo before sending the next. If the byte stream matches exactly, the LED stays on. If anything corrupts, it goes dark. Running this for roughly an hour gives me confidence the pack and unpack functions are symmetric. Truth be said, i stress tested because I wanted to see the limits out of pure curiosity.

Normal mode transmits at the actual needed frequency. One second pulse ticks at 1 Hz and sends all four fast frames. Every five seconds the medium frames go out. Every ten seconds come the slow frames. This matches the data collectors which do not need constant reads anyway.

The pack functions are straightforward - memcpy the struct fields into the eight byte buffer in little-endian order. Here is what the pack function actually does under the hood:

void can_pack_panel(SS_Panel_t *p, uint8_t *buf)
{
    buf[0] = (p->v_mv) & 0xFF;         // voltage low byte
    buf[1] = (p->v_mv >> 8) & 0xFF;    // voltage high byte
    buf[2] = (p->i_ua) & 0xFF;         // current byte 0
    buf[3] = (p->i_ua >> 8) & 0xFF;    // current byte 1
    buf[4] = (p->i_ua >> 16) & 0xFF;   // current byte 2
    buf[5] = (p->i_ua >> 24) & 0xFF;   // current byte 3
}

and

SS_Panel_t p = { .v_mv = 5500, .i_ua = 175000 };
can_pack_panel(&p, tx_buf);
tx_frame(SS_ID_PANEL1, 6);

This generates 6 bytes on the wire: voltage takes 2 bytes, current takes 4 bytes, all in little-endian byte order. So a voltage of 5500 mV becomes 0x5C 0x15 on the wire (5500 = 0x157C, but reversed for little-endian).

The Receiver - Arduino Q with STM32U585

As i covered in Part , the Arduino Q was jealous of my relation with STM32 and so he had Zephyr and arduino-router locking me out of the CAN. The solution was to take control of the STM32U585 directly using STM32HAL. Once i disabled the arduino-router service, i could flash bare metal firmware. Cut out the middle man I say.

The receiver listens passively on the bus. When a frame arrives, it checks the ID and dispatches to an unpack function. The unpack function mirrors the pack logic - it extracts the bytes in little-endian order and reconstructs the struct:

void can_unpack_panel(uint8_t *buf, SS_Panel_t *p)
{
    // voltage from bytes 0-1
    p->v_mv = buf[0] | (buf[1] << 8);        
    // current from bytes 2-5
    p->i_ua = buf[2] | (buf[3] << 8) | (buf[4] << 16) | (buf[5] << 24); 
    // compute power
    p->p_uw = (p->v_mv * p->i_ua) / 1000;  
}

When 6 bytes arrive from the CAN bus, the unpack function reassembles them back into the struct. So the bytes 0x5C 0x15 become 5500 mV again, and 0xF8 0xAB 0x02 0x00 becomes 175000 microamps. Then it computes power on the fly by multiplying voltage times current and dividing by 1000.

The dispatch loop in the receiver routes each frame type to its unpack function:

switch (id) {
case SS_ID_PANEL1: {
  SS_Panel_t p; 
  can_unpack_panel(rxData, &p);
  printf("[%06lu] RX 0x101 P1_REF  V=%umV  I=%ldµA  P=%ldµW\r\n",
         tick, p.v_mv, p.i_ua, p.p_uw);
  break;
}
case SS_ID_PANEL2: {
  SS_Panel_t p;
  can_unpack_panel(rxData, &p);
  printf("[%06lu] RX 0x102 P2_SOIL V=%umV  I=%ldµA  P=%ldµW\r\n",
         tick, p.v_mv, p.i_ua, p.p_uw);
  break;
}
case SS_ID_THERMO: {
  SS_Thermo_t t;
  can_unpack_thermo(rxData, &t);
  printf("[%06lu] RX 0x201 TC      surface=%.1fC  cold=%.1fC\r\n",
         tick, t.surface_c10 / 10.0f, t.cold_c10 / 10.0f);
  break;
}
}

Each frame ID has a unique handler. When a panel frame arrives, it unpacks to a panel struct and prints the voltage, current, and computed power. When a thermocouple frame arrives, it unpacks to a thermo struct and prints temperatures. This is where the computation happens - the sender does not transmit power at all.

Transceiver Hardware

The F103 Nucleo uses the Waveshare RS485/CAN Shield which sits on top and breaks out the CAN TX and RX lines. This shield has an onboard 120 ohm termination resistor already built in.

The Arduino Q runs the MAX33041EVAL shield which also has CAN transceiver circuitry. When i first connected the two boards, nothing worked. Frames were not getting through at all.

I added a common ground wire between the two boards since CAN is a differential bus and needs a shared reference. That did not fix the communication, but i kept it anyway.

The real issue was the termination resistors. I pulled out the multimeter and checked. The Waveshare board measured 120 ohms. The MAX33041EVAL measured 60 ohms. Google Search AI said "Having different termination values on the same bus creates an impedance mismatch - the signal reflections get mangled and frames corrupt or disappear entirely."

The MAX33041EVAL has jumpers that can change its termination. I adjusted them to disable the 60 ohm termination and enable 120 ohm instead, matching the Waveshare side. Once both sides had 120 ohm, communication became rock solid immediately.

Here are the multimeter readings that showed the problem and the fix:

On the Waveshare CAN Shield

On MAX33401EVAL Board with default Jumpers

On MAX33401EVAL Board with changed Jumpers

Jumper Details as per: https://www.analog.com/media/en/technical-documentation/data-sheets/max33041eshld.pdf

The star mark refers to the default position of jumpers when shipped. So I had to just change the position of the JU7 and JU8

Putting It Together

To test the whole system

Mount the Waveshare RS485/CAN Shield on the F103 Nucleo
Mount the MAX33041EVAL shield on the Arduino Q
Configure the MAX33041EVAL jumpers to disable termination (check the datasheet for which jumpers)
Wire CAN_H and CAN_L from the Waveshare board to the MAX33041EVAL board via shielded twisted pair
Compile and flash both boards
Open two serial terminals one directly, and the other via SSH terminal of ArduinoQ. Still using the same python script as in my Part 2

The F103 prints what it is sending. The Arduino Q prints what it is receiving. If both match line by line, the protocol is working. If frames are getting dropped or corrupted, check that the jumpers on the MAX33041EVAL are set correctly.

community.element14.com/.../2026_2D00_06_2D00_09-20_2D00_11_2D00_40.mp4

Here is a video captured using another App i am experimenting OBS studio. It did allow me to capture just the windows i am interested in without showing others.

What Comes Next

The protocol and firmware are solid. The next step is to integrate the actual sensor readings - right now i am transmitting dummy test data. The STM32L476 on the data collection PCB will read from the INA219B current sensors, the MAX31855 thermocouple interface, the BME280, SEN66, and HX94C humidity sensor, then pack them into CAN frames.

Once that is working, i need to add SD card logging on the collection board as a backup, and implement the time sync heartbeat so the two boards stay in sync. Then the real fun begins - taking all that sensor data and training an edge AI model to predict when the panels need cleaning. The infrastructure is getting solid. The CAN bus is proving to be the right choice - reliable, well understood, and not overkill for the data rates we need.

Final Notes

Building a custom protocol is not something to take lightly. But for a closed system like this where i control both ends, it is worth the effort. The payoff is a bus that handles exactly what i need and nothing more. The stress test gave me the confidence that the implementation works. Next post will be about actually running the sensor board and seeing real data flow across the CAN bus.

There is also a problem with the Arduino Q's STM32 sort of not accepting the CAN frames after few flash attempts, But the problem went out when I restarted the ArduinoQ. The problem is sporadic but I haven't been find the root cause of the problem yet.

3 The newest system setup

pandoramc — Tue, 09 Jun 2026 00:28:55 GMT

Introduction

For the newest setup it is required to have a cooling system to do temperature testing. This is achieved by integrating of new components in order to reproduce the results of the first system here and improve the system usability. A copper coil will be used to cover the electrolyte container and mount the thermocouples. Some of the necessary materials are a compressor, a condenser, a dry filter, and so on. Once the system is assembled, the thermocouples must be mounted to monitor the temperature. Despite the thermocouples are insulated, the bead and Chromel and Alumel in the sensing terminal are not. On the other hand, the fluids used in the process could damage the probe if it has overexposing conditions.

Figure 1. Materials for the newest setup

Methodology

To avoid this, the temperature probe is assembled on a thermowell. A thermowell is an accessory for the temperature probe that isolates the sensor from the environment. Unfortunately, the sensor bead and air inside the thermowell must interact with the thermocouple measurement. To prevent this, thermal paste is added to the thermowell to displace the air and facilitate thermal coupling.

{gallery}Thermal coupling

Figure 2. Thermowell assembly for environmental insulated measurements

Currently, the Arduino UNO Q operates with a power consumption of about 2.5 W. Initially, we used a 13-port USB hub to connect the accessories and power adapter. However, this configuration caused the board to reboot and produce errors during continuous usage. The initial hypothesis was that excessive port usage caused a peak current or memory access violation. Consequently, a hub with fewer ports than the original was used. This time, a hub with five ports has better stability over time. The available ports on the hub are HDMI, two USB-A ports, an Ethernet connection, and a USB-C power supply connection.

{gallery}GUI captures

Figure 3. GUI terminal captures of past development

Figure 4. Power measurement from power supply

The future

This setup provides access to the board through a graphical user interface. Developers interacts with the Arduino App Lab to create new applications using Python for the Linux interface and Arduino code for the microcontroller system. Now, a new challenge has been reached, how to interact with thermocouples? Thermocouples have a low voltage response to temperature, and the usage of different wiring systems could create new cold junctions in the measurement system. To mitigate this issue, special wires are required, such as K-type thermocouple extenders and/or compatible thermoblocks to avoid interference with the measurement. Hoever, this is a quite complicated situation since the temperature transmission system only guarantees the measurement for temperatures above 0°C(32 °F). This is according to the polynomial function implemented in the conditioning blocks. For our purposes, we need to measure temperatures below the mentioned temperature. At this moment, we can transmit the temperature using an interesting setup using Omega products, but it is still being tested.

{gallery}Connections

Figure 5. Building blocks for the temperature measurement

Forum#4: Adapting the Sentinel Vision Model for Industrial Defect Detection (ILS)

skruglewicz — Sun, 07 Jun 2026 04:13:59 GMT

Forum#4: Adapting the Sentinel Vision Model for Industrial Defect Detection (ILS)

Hello fellow challengers! Welcome to my 4th update.

In my original application, I proposed a specific goal for my Industrial Defect Detection (ILS) system: "I will deploy a quantized MobileNet-SSD model within a headless Docker container to detect safety gear (glasses/vests) and 'Red Zone' incursions. To manage the 2GB RAM limit and avoid swap exhaustion, the vision pipeline will use a motion-triggered inference engine."

Today, I’m excited to share the step-by-step progress of this experiment using the Arduino UNO Q, focusing on how to securely deploy a custom vision "Brick" while strictly managing hardware resources.

1. Hardware Setup: Using a USB Camera on the UNO Q

The new Arduino UNO Q features a fantastic dual-brain architecture. It pairs an STM32 microcontroller (for real-time hardware control) with a Qualcomm Dragonwing quad-core processor running a full Debian Linux OS.

Because we have a full Linux environment, adding "eyes" to the system is incredibly straightforward:

The Connection: The UNO Q features a high-speed USB-C port. By using a standard USB-C hub or a USB-A to USB-C adapter, I plugged in a standard UVC (USB Video Class) webcam.
The OS Layer: Linux natively recognizes the camera. It automatically mounts it to /dev/video0. There is no need for complex microcontroller camera drivers; the MPU treats it exactly as a desktop computer would!

2. The Strategy: Motion-Triggered Inference

The Challenge: The UNO Q has 2GB of RAM. A continuous video feed running through a deep learning object detection model (like MobileNet-SSD) can easily consume 1.5GB+. When Linux runs out of RAM, it uses "swap" space on the eMMC storage. Constant swapping will quickly wear out the flash memory and crash the system (Swap Exhaustion).

The Novice-Friendly Solution: Imagine a security guard staring at an empty hallway. Instead of staring intently 100% of the time, the guard only focuses when they see movement. We will do the same:

The camera captures frames.
A lightweight "Motion Detection" algorithm compares the current frame to the previous one. This uses almost zero RAM.
If movement is detected, it "wakes up" the heavy AI model to check for Safety Vests, Glasses, or Red Zone incursions.

Data Flow Diagram

flowchart TD
    A[USB Camera /dev/video0] --> B(Capture Frame)
    B --> C{Is there Motion?}
    C -- No --> B
    C -- Yes --> D[Trigger AI Inference]
    D --> E[Quantized MobileNet-SSD]
    E --> F{Objects Detected?}
    F -- Safety Gear Missing --> G[Log Safety Violation]
    F -- Red Zone Breach --> H[Trigger Alarm on STM32 MCU]
    F -- All Clear --> B

3. Creating the Custom "Brick" Model

In the Arduino App Lab ecosystem, a "Brick" is a modular block of software. We are building a Custom AI Vision Brick.

To make this fit in our 2GB limit, we use a technique called Quantization. Normally, AI models use 32-bit floating-point numbers (high precision, large file size). By quantizing the MobileNet-SSD model to INT8 (8-bit integers), we shrink the model footprint from ~20MB down to ~4MB, drastically reducing the RAM required to load the model into memory while maintaining enough accuracy to detect high-contrast items like neon safety vests.

4. Step-by-Step Implementation Guide

Here is how I designed, coded, and implemented this on the UNO Q.

Step 1: Prepare the Headless Docker Environment

"Headless" simply means we are running the software in the background without a graphical desktop (no windows, no mouse pointer). This alone saves about 400MB of RAM!

We write a Dockerfile that installs only the bare minimum: Python, OpenCV (headless version), and our AI runtime (like TensorFlow Lite).

Step 2: The Motion-Triggered Code Logic

Here is a simplified look at the Python script running inside our Docker container. Notice how we only invoke the heavy detect_objects function if the motion threshold is met.

import cv2
import time

# Initialize USB Camera
cap = cv2.VideoCapture(0)
ret, frame1 = cap.read()
ret, frame2 = cap.read()

while cap.isOpened():
    # 1. Calculate absolute difference between frames for motion
    diff = cv2.absdiff(frame1, frame2)
    gray = cv2.cvtColor(diff, cv2.COLOR_BGR2GRAY)
    blur = cv2.GaussianBlur(gray, (5,5), 0)
    _, thresh = cv2.threshold(blur, 20, 255, cv2.THRESH_BINARY)
    
    # 2. Find contours of the motion
    contours, _ = cv2.findContours(thresh, cv2.RETR_TREE, cv2.CHAIN_APPROX_SIMPLE)
    
    motion_detected = False
    for contour in contours:
        if cv2.contourArea(contour) > 5000: # Adjust sensitivity here
            motion_detected = True
            break
            
    # 3. Trigger the Heavy AI Model ONLY if motion is found
    if motion_detected:
        print("Motion detected! Triggering MobileNet-SSD...")
        # --> Run Quantized INT8 Inference Here <--
        # results = run_mobilenet_ssd(frame1)
        # check_red_zone_incursion(results)
    
    # Update frames
    frame1 = frame2
    ret, frame2 = cap.read()
    
    # Small sleep to free up CPU cycles
    time.sleep(0.1)

Step 3: Deployment with Strict RAM Limits

To absolutely ensure we never hit swap exhaustion, we deploy our container using Docker Compose with strict memory limits enforced.

# docker-compose.yml
version: '3.8'
services:
  sentinel_vision:
    build: .
    devices:
      - "/dev/video0:/dev/video0" # Passthrough the USB camera
    deploy:
      resources:
        limits:
          memory: 800M # Strictly limit the container to 800MB RAM
    restart: unless-stopped

Step 4: Connecting MPU to MCU (The Output)

When the Linux side (MPU) detects a missing safety vest or a Red Zone incursion, it sends a simple serial payload to the real-time STM32 microcontroller (MCU) side of the UNO Q. The MCU then instantly flips a relay to sound an alarm or halt a machine, with zero latency!

Conclusion

By combining a headless Docker architecture, an INT8 quantized MobileNet-SSD model, and a motion-triggered inference gate, we completely bypass the standard bottlenecks of edge AI. We keep RAM usage under 1GB, protect the onboard eMMC from swap wear, and maintain rapid response times for industrial safety.

I would love to hear your feedback! 1. Has anyone else experimented with INT8 quantization on the UNO Q?

2. Are there better algorithms than cv2.absdiff for lightweight motion triggering in varying industrial lighting?

Let me know your thoughts below!

Forum#5: UNO Q & Grove Starter Kit V3 - Building the Safety Alert System (ILS)

skruglewicz — Sun, 07 Jun 2026 04:10:13 GMT

Forum #5: UNO Q & Grove Starter Kit V3

Hello fellow challengers

Building on my Forum #4 post—where I outlined using the Arduino UNO Q's AI vision capabilities to detect safety gear (glasses/vests) and Red Zone incursions—it’s time to bring that system into the physical world. Detection is only half the battle; we need to instantly alert operators when a safety breach occurs.

For this phase, I will be using the Grove Starter Kit V3 by connecting (piggybacking) its Base Shield onto our Arduino UNO Q. Here is my extensive, step-by-step novice-friendly guide to designing, coding, and implementing this alert system using the Arduino App Lab.

1. Hardware Integration: Piggybacking the Base Shield on the UNO Q

What does "piggybacking" mean? The Grove Base Shield V3 is an expansion board (a "shield"). The Arduino UNO Q maintains the classic UNO form factor and pin layout. "Piggybacking" simply means we align the male pins on the bottom of the Grove Base Shield with the female headers on the top of the UNO Q, and press them firmly together.

Why use the Base Shield?

Instead of dealing with messy wires, resistors, and breadboards, the Base Shield gives us neat, plug-and-play "Grove connectors." We just use the provided 4-pin cables to snap our sensors and output devices into the board.

2. Selecting the Ideal "Alert" Modules

While the Grove Kit is known for its "sensors" (which take data in), for an alert system, we need "actuators" (which put data out). To create a robust, multi-sensory alert system, I have selected the following components from the Grove Starter Kit V3:

Grove - Red LED (Visual Beacon): A flashing red light is the universal sign of danger. This will catch the operator's eye immediately.
Grove - Buzzer (Audio Siren): Factories and workspaces can be distracting. A loud, piercing auditory alarm ensures the alert is heard even if the operator isn't looking at the system.
Grove - LCD RGB Backlight (Status Display): We need to tell the operator why the alarm is going off. Is it a missing vest? A Red Zone incursion? This screen will display the exact text and change its backlight color to red during an emergency.
Grove - Button (Reset Sensor): A physical input sensor. Once the operator acknowledges the alarm and corrects the safety issue, they press this button to silence the system.

3. Data Flow & System Architecture

Before we code, it helps to visualize how information travels through our system. The UNO Q is special because it has a "Dual-Brain": a Qualcomm processor (for AI) and an STM32 microcontroller (for hardware).

Here is the flowchart of our logic:

========================================================================
                      SYSTEM DATA FLOW DIAGRAM
========================================================================

 [ USB Camera ] --> Captures video feed of the work zone
       |
       v
 +---------------------------------------------------+
 |                  ARDUINO UNO Q                    |
 |                                                   |
 |  1. QUALCOMM MPU (Python via App Lab)             |
 |     - Runs AI Object Detection (Glasses/Vest)     |
 |     - Detects "Red Zone" Incursion                |
 |            |                                      |
 |            v (Arduino Bridge API triggers alert)  |
 |            |                                      |
 |  2. STM32 MCU (C++ Sketch via App Lab)            |
 |     - Receives "ALERT" signal                     |
 |     - Controls the Grove hardware pins            |
 +---------------------------------------------------+
       | (Signals sent through Base Shield)
       v
 +---------------------------------------------------+
 |             GROVE BASE SHIELD V3                  |
 +---------------------------------------------------+
       |               |               |             |
   (Port D2)       (Port D3)       (Port I2C)    (Port D4)
       |               |               |             |
       v               v               v             v
   [Grove LED]   [Grove Buzzer]  [Grove RGB LCD] [Grove Button]
  (Visual Alert)  (Audio Siren)  (Text Warning)  (Reset Input)
========================================================================

4. Step-by-Step Implementation Instructions

Step 1: Connect the Hardware

Unplug your UNO Q from power.
Align and press the Grove Base Shield V3 onto the top of the UNO Q.
Using the Grove cables, connect the Grove LED (with a Red bulb) to port D2.
Connect the Grove Buzzer to port D3.
Connect the Grove Button to port D4.
Connect the Grove RGB LCD to any of the I2C ports.

Step 2: Open Arduino App Lab

Connect the UNO Q to your computer via USB-C.
Launch Arduino App Lab.
Create a new "App". App Lab will open a dual-pane window. We will be working in the C++ Sketch pane, which controls the Base Shield hardware.

5. Coding Examples: Sketches for Each Sensor/Module

Below are the beginner-friendly C++ sketches for each individual module so you can understand how they work in isolation. Note: In App Lab, these are standard Arduino C++ commands.

A. The Visual Beacon (Grove LED)

// --- GROVE LED SKETCH ---
// This sketch flashes the LED to simulate an emergency beacon.

// 1. Define the pin where the LED is connected
const int ledPin = 2; // Port D2 on the Base Shield

void setup() {
  // setup() runs once when the board turns on.
  // We tell the UNO Q that the ledPin is an OUTPUT (sending electricity out)
  pinMode(ledPin, OUTPUT); 
}

void loop() {
  // loop() runs over and over forever.
  digitalWrite(ledPin, HIGH); // Turn the LED ON (HIGH = electricity flowing)
  delay(500);                 // Wait for 500 milliseconds (half a second)
  digitalWrite(ledPin, LOW);  // Turn the LED OFF (LOW = no electricity)
  delay(500);                 // Wait for 500 milliseconds
}

B. The Audio Siren (Grove Buzzer)

// --- GROVE BUZZER SKETCH ---
// This sketch sounds a repeating alarm tone.

const int buzzerPin = 3; // Port D3 on the Base Shield

void setup() {
  pinMode(buzzerPin, OUTPUT); // The buzzer receives signals, so it's an OUTPUT
}

void loop() {
  digitalWrite(buzzerPin, HIGH); // Turn buzzer ON (makes a loud beep)
  delay(200);                    // Wait 0.2 seconds
  digitalWrite(buzzerPin, LOW);  // Turn buzzer OFF
  delay(200);                    // Wait 0.2 seconds
}

C. The Status Display (Grove RGB LCD)

// --- GROVE RGB LCD SKETCH ---
// This sketch changes the screen color to Red and prints a warning.

// We need to include special libraries (instruction manuals) for the screen and I2C communication.
#include <Wire.h>
#include "rgb_lcd.h"

rgb_lcd lcd; // Create an LCD object to control the screen

void setup() {
  // Initialize the screen: 16 columns and 2 rows of characters
  lcd.begin(16, 2);
  
  // Set the backlight color to RED (Red, Green, Blue values from 0-255)
  lcd.setRGB(255, 0, 0); 
  
  // Print our warning message on the top row
  lcd.print("! ALARM ACTIVE !");
  
  // Move the invisible cursor to the start of the bottom row (column 0, row 1)
  lcd.setCursor(0, 1);
  lcd.print("RED ZONE BREACH");
}

void loop() {
  // Nothing needs to loop here, the text stays on the screen!
}

D. The Alarm Reset (Grove Button)

// --- GROVE BUTTON SKETCH ---
// This sketch reads the physical world (sensor input) to check if a button is pressed.

const int buttonPin = 4; // Port D4 on the Base Shield

void setup() {
  pinMode(buttonPin, INPUT); // The button sends data IN to the board
  Serial.begin(9600);        // Open a communication line to our computer screen
}

void loop() {
  // Read the state of the button (HIGH = pressed, LOW = unpressed)
  int buttonState = digitalRead(buttonPin);
  
  if (buttonState == HIGH) {
    Serial.println("Reset Button Pressed!"); // Send a message to the computer
  }
  delay(100); // Small delay to prevent reading the button too fast
}

6. The Final Implementation: Bringing it All Together

In a real-world scenario on the UNO Q, the AI camera detects the missing safety glasses and flips an internal variable to true. Here is the combined App Lab C++ sketch that pulls all our modules together into one cohesive safety system!

// ====================================================================
// FULL SAFETY ALERT SYSTEM SKETCH (Arduino App Lab C++)
// ====================================================================

#include <Wire.h>
#include "rgb_lcd.h"

// Define Hardware Pins
const int ledPin = 2;
const int buzzerPin = 3;
const int buttonPin = 4;

// Initialize LCD
rgb_lcd lcd;

// This variable acts as our system state. 
// In a full App Lab project, the Python AI script would change this variable 
// via the Arduino Bridge when it detects a missing hardhat or Red Zone breach.
bool alarmTriggered = true; 

void setup() {
  // Configure Pins
  pinMode(ledPin, OUTPUT);
  pinMode(buzzerPin, OUTPUT);
  pinMode(buttonPin, INPUT);
  
  // Start LCD and default to a Green "Safe" state
  lcd.begin(16, 2);
  setSafeState();
}

void loop() {
  // Check if the operator pressed the reset button
  int buttonState = digitalRead(buttonPin);
  if (buttonState == HIGH && alarmTriggered == true) {
    // If button pressed during an alarm, clear the alarm
    alarmTriggered = false;
    setSafeState();
  }

  // If the alarm is active, flash the lights and sound the buzzer
  if (alarmTriggered == true) {
    triggerAlarmCycle();
  }
}

// Custom function to handle the "All Clear" state
void setSafeState() {
  digitalWrite(ledPin, LOW);    // Turn off LED
  digitalWrite(buzzerPin, LOW); // Turn off Buzzer
  
  lcd.setRGB(0, 255, 0);        // Set LCD to Green
  lcd.clear();                  // Clear old text
  lcd.print("SYSTEM SECURE");   // Print safe message
  lcd.setCursor(0, 1);
  lcd.print("Monitoring...");
}

// Custom function to handle the flashing/beeping of the alarm
void triggerAlarmCycle() {
  // Set LCD to Red and display warning
  lcd.setRGB(255, 0, 0);
  lcd.setCursor(0, 0);
  lcd.print("! SAFETY ALERT !");
  lcd.setCursor(0, 1);
  lcd.print("ZONE BREACH     ");

  // Flash ON
  digitalWrite(ledPin, HIGH);
  digitalWrite(buzzerPin, HIGH);
  delay(300);
  
  // Flash OFF
  digitalWrite(ledPin, LOW);
  digitalWrite(buzzerPin, LOW);
  delay(300);
}

Conclusion

By utilizing the Grove Base Shield V3, we bypass complex wiring and focus strictly on logic and implementation. The dual architecture of the UNO Q allows the heavy lifting of AI detection to occur behind the scenes, seamlessly triggering our STM32 microcontroller to fire off real-world visual, auditory, and textual alerts using our Grove actuators.

I'd love to hear feedback from other challengers! Have any of you experimented with adding the Grove Smart Relay to actually shut down machinery during a Red Zone incursion?

Looking forward to your comments!

SolarSense - Part 3 - PCB Schematics Walkthrough

arvindsa — Sun, 07 Jun 2026 04:00:31 GMT

Recap:

I’m developing a smart solar monitoring system that uses a clean reference panel to eliminate weather effects and directly quantify dust-induced losses in real time. With edge AI and environmental sensing, the goal is to predict the right moment to cleanbefore efficiency drops enough to matter.

Sunday Arrives, Time for a leisurely writing session. The Data collection unit has to survive the forces unleashed by mother nature. I am not talking about hurricane but since i am living in Kerala, India where the weather ranges from dry to 100% humidity, heavy monsoon rainfall, temperatures upto 50deg C (which means inside a casing it can go upto even 60deg). TO me this project is close to heart and therefore i decided to invest in a good PCB. In this Post I shall walk you through the design of the schematics.

Sheet 1: Panel Current Measurement and MPTT Charger

The Primary aim would be to measure the current of the clean and unclean panel under different environmental sensor reading. Ideally, if a solar panel is uniformly soiled, only the current output should decreased as opposed to reduction in voltage, only when one of the cells inside it is covered, the voltage produced by that drops leading to a drop in the overall voltage output of the panel. SO under that assumption, i am gonna wire the 3 panels in parallel with an SS14 Diode to prevent the clean panels output back-powering the unclean one. The Current is measured by a 100mOhm 1% resistor, 2W 2512 Package. Using INA219B (not INA219A) which has a differential output of +-320mV, it can measure upto 3.2mA, with each panel expected upto 300mA, it is way over the necessary point.

The INA219 in 12-bit mode with PGA = /1 (32 mV full-scale differential) will provide - full-scale / 2^15 = 3.2 A / 32768 = 97.6 µA per LSB (appx)

To Charge the LiPo for self powering, I am using the popular CN3791. Not the best, but fastest to source. The key specification is that it regulates the panel input to approximately 80 % of the open-circuit voltage

Programming the charging current:

The charge current is set by a resistor on the PROG pin: R_PROG = 2800 / I_CHG (Ω) For a 1 A charge current: R_PROG = 2.8 kΩ -> use 2.7 kΩ standard.

For a 500 mA charge current: R_PROG = 5.6 kΩ. I am targeting 500 mA for now because the panel I have is small, so R_PROG = 5.6 kΩ.

Panel input capacitor:

The CN3791 datasheet recommends a bulk cap on VIN. A 47 µF electrolytic in parallel with 100 nF ceramic. The CN3791 has a relatively slow MPPT loop, so you need enough bulk capacitance to stop the input rail from collapsing during transients. I will be adding that electrolytic cap soon.

Sheet 2: Power Management

Starting off with MAX17048 to keep track of the LiPo to ensure that the system is having enough power. Based on a crude calculations, using a 2000mAH battery should have enough power to run the system for roughly 30~40 hours. So It should get two session with sunshine, hopefully enough to charge it. In case the Battery drops low, i will get to know via the comms and then i can go swap it out, For the HX94C requires an excitation voltage between 6~30V and i decided to go with 12V and so i use a TPS6104 To boost the LiPo to 12V, and for enough efficiency, AP2112 for the 3.3V rail. Also added in a TPS63020 circuit to test it out. it is not an important part to this circuit but i wanted to trial the circuit for another project. :D

Sheet 3: STM32L476RGT6

This Choice of MCU was thankfully easy, as i had many STM32s on hand and STM32L476RGT6 was the best suited MCU with CAN Controller. I am using a CR2032 Battery for RTC Power for the STM32 to keep track of time.

Sheet 4: Communications and Display

I am using the Waveshare RS485/CAN shield for initial prototyping and have broken out the CAN_TX and CAN_RX lines as global labels connected to the STM32 FDCAN peripheral. For long term storage, as a backup in case comms fail, i am using a Micro SD Card, will be using the SDMMC mode rather than the SPI mode. This will be new to me so I am excited to make the code for it. The OLED is only for Debug purposes and not for actual deployment. Thinking few months down the line, i do want to deploy a few of the panels in different locations to actually test the AI model. It will be remote enough that i cant pull a CAN bus to it, So i have added support for WioSX1262 Lora. With a Power usage of 120mA (396mW) it still is comfortable within the limit of my power budget.

Why am i use CAN if i can use Lora? For making an AI model the more data i have it is better, and to figure out the best feature extraction parameters, i need to experiment with the RAW data, which means lots of Frequent Data, Lora is not built for that, but while deploying the AI model, features are calculated and classification done on the edge device, LORA only transmits the status updates, not the entire data. Therefore LoRa will work there.

Sheet 5: Sensors

To Interface the OmegaDwyer 5SRTC-TT-K-24-72 Thermocouple, K, 0 °C, 260 °C, 80 ", 2 m (Pack of 5) sensors i am using MAX31855. For now i am gonna be using only 1 to keep track of the temperature of one solar panel, but i put in more of this as DNP just to ensure future use. Maybe LiPO temperature? BMP280 to Keep track of Pressure. Thankfully looking at the I2C Addesses, there does not seem to be any conflicts and i can keep all of them in one I2C bus, there is an issue that SEN66 communicates only at 100 kHz I2C only. but that's alright it can be handled in the code. I an extra I2C connector for future use.

OmegaDwyer Humidity Sensor, CURRENT, 30V, W/4P CONN requires a sense resistor for each Relative Humidity and Temperature. This sensor is one of the best for both RH and Temperature even though Temperature can be measured by BMP and SEN66. As per their Datasheet to get a ADC reading between 0-3.3V i have use 150Ohm Resistors.

I also added a rain detector connector with a digital and analog pin capability again in case i need to extend the model further - The rain detection module is like https://arduinogetstarted.com/tutorials/arduino-rain-sensor

Last but not the least, as a secondary source of Incident light, an alternative for clean panel is the UV Sensor which works on Analog. I added a connector to it,

0x3C — SSD1306 OLED
0x40 — INA219 (panel current/voltage)
0x6B — SEN66 (air quality)
0x76 — BMP280 (pressure, ambient temperature)

Sheet 0: The Root Sheet gluing everything together

Here is the final architecture

Final Notes

This PCB is a leap of faith, usually i breadboard some of the circuits before i make a PCB and in particular i have not used the HX94C sensor yet, but no first design of PCB is perfect, so let's bank on one more round of PCB design. I am gonna verify the circuit again before layout and Fab. Tomorrow I will finish the CAN receiver and benchmark the data speeds and throughput.

Update: PCB Layout and Routing

Hey, I managed to place and route all the components, I gave the order to manufacture via PCB Way in white Soldermask. I chose white because, it would absorb heat less and therefore should remain cool(er)

SolarSense - Part 2 - Can Arduino CAN?

arvindsa — Sat, 06 Jun 2026 18:43:23 GMT

I spent a lot of time last month cleaning up my projects. I almost lost lost track of time. Now to convert the POC I made into a reliable data collection powerhouse, ArduinoQ running Zephyr on STM32 is new to me. Linux part i can handle.

Recap:

SolarSense - Part 1 - Introduction, The POC Built and The Plan

Setting Up Arduino Q

I downloaded AppLab quickly from the official website, connected the Arduino Q via a USB-C and blasted away through the configuration screen. In this regard, it was easy, although the update took time.

And it is always an Ritual that i need to blink an LED whenever i get a new hardware and so I used the example. I have to admit it, Using Zephyr , An Python Code and RPC connection between them just to blink LED is like using cannon to Kill a mosquito.

Internet Research to Answer the Question

After Looking at some Internet on how to get CAN to work, I came to a conclusion that ArduinoQ cannot run the CAN Controller on the STM32

And so the challenge begins. If i cannot easily interface the CAN Peripheral on STM32 then my next idea became to have an additional board like Teensy 3.2 or my Nucleo F303Re which as a CAN Peripheral as a bridge between ArduinoQ and the MAX33041E. Then the number of bridges made me uneasy. Imagine Q's Qualcomm Chip -> Q's STM32 Chip -> Nucleo F303RE -> MAX33041E -> CAN Bus. It was ridiculous. I looked if i can break the Qualcomm's Bridge and somehow run the STM32 using STM32HAL. I came to know that the Linux installation contains OpenOCD and Zephyr's Documentation that the Physical connection between MPU and MCU is LPUART managed by an arduino-router service on the linux

Taking Control of the STM32 from the hands of Qualcomm Chip

Step 1: Disable arduino-router Service

I connected to the ArduinoQ's terminal via SSH ssh arduino@<boardname>.local where boardname is the name you gave it while setup. The Password is again the same as you gave in the setup

sudo cp /etc/systemd/system/arduino-router.service \
        /home/arduino/arduino-router.service.bak
sudo rm /etc/systemd/system/arduino-router.service
sudo systemctl mask arduino-router
sudo systemctl daemon-reload
sudo pkill -9 -f arduino-router

I ensured that i restarted the Q to ensure that the service does not pop up back again.

Step 2: Setting up the STM32MX Project

From the Schematics of Arduino Q here: https://docs.arduino.cc/resources/schematics/ABX00162-schematics.pdf , I got the full chip code - STM32U585AII6TR, set up the project on STM32MX with the clock and just LPUART, LED, CAN

The clock values as as below

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState       = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState   = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource  = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM       = 1;
RCC_OscInitStruct.PLL.PLLN       = 10;
RCC_OscInitStruct.PLL.PLLR       = 1;   // 16 * 10 / 1 = 160 MHz

I generated the code, starting with a simple blink. btw, Flash latency must be FLASH_LATENCY_4 at VOS1 / 160 MHz — anything lower causes a hard fault on the first cache miss.

Step 3: The Blinking Ritual

The onboard LED is on PH10, active-HIGH

/* MX_GPIO_Init USER CODE section */
__HAL_RCC_GPIOH_CLK_ENABLE();

GPIO_InitTypeDef GPIO_InitStruct = {0};
GPIO_InitStruct.Pin   = GPIO_PIN_10;
GPIO_InitStruct.Mode  = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull  = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOH, &GPIO_InitStruct);

/* Main loop */
HAL_GPIO_TogglePin(GPIOH, GPIO_PIN_10);
HAL_Delay(500);

Step 4: Setting up the LPUART1

/* USER CODE BEGIN Includes */
#include <stdio.h>
/* USER CODE END Includes */

/* USER CODE BEGIN 2 */
char tx_buf[64];
/* USER CODE END 2 */

/* Main loop */
int len = snprintf(tx_buf, sizeof(tx_buf), "hello from STM32\r\n");
HAL_UART_Transmit(&hlpuart1, (uint8_t *)tx_buf, len, 100);

#!/usr/bin/env python3
import serial, sys

ser = serial.Serial('/dev/ttyHS1', 209700, timeout=5)
print(f"Listening on /dev/ttyHS1 at 209700 baud...")
try:
    while True:
        line = ser.readline()
        if line:
            print(line.decode('utf-8', errors='replace').strip())
except KeyboardInterrupt:
    ser.close()

Step 5: Now ArduinoQ CAN

The STM32 has CAN pins on PA11 (RX) / PA12 (TX). Before connecting to a real bus, verify the peripheral and transceiver with an external loopback test. External loopback drives the TX pin through the transceiver while simultaneously receiving
the frame internally. The STM32 provides its own ACK, so it keeps transmitting even with no termination resistor or other node on the bus. And Ensure that the Jumpers are all in default positions as https://www.analog.com/media/en/technical-documentation/data-sheets/MAX33041ESHLD.pdf except for JU11, you need to switch it to the 3.3V side so that it can receive the power from Arduino Q's 3.3V

FDCAN_FilterTypeDef sFilterConfig;
sFilterConfig.IdType       = FDCAN_STANDARD_ID;
sFilterConfig.FilterIndex  = 0;
sFilterConfig.FilterType   = FDCAN_FILTER_MASK;
sFilterConfig.FilterConfig = FDCAN_FILTER_TO_RXFIFO0;
sFilterConfig.FilterID1    = 0x000;
sFilterConfig.FilterID2    = 0x000;  // mask=0 → accept all standard frames
HAL_FDCAN_ConfigFilter(&hfdcan1, &sFilterConfig);
HAL_FDCAN_Start(&hfdcan1);

// User Loop
FDCAN_TxHeaderTypeDef txHeader;
uint8_t canTxData[8] = {0xDE, 0xAD, 0xBE, 0xEF, 0x01, 0x02, 0x03, 0x04};
txHeader.Identifier         = 0x123;
txHeader.IdType             = FDCAN_STANDARD_ID;
txHeader.TxFrameType        = FDCAN_DATA_FRAME;
txHeader.DataLength         = FDCAN_DLC_BYTES_8;
txHeader.ErrorStateIndicator = FDCAN_ESI_ACTIVE;
txHeader.BitRateSwitch      = FDCAN_BRS_OFF;
txHeader.FDFormat            = FDCAN_CLASSIC_CAN;
txHeader.TxEventFifoControl = FDCAN_NO_TX_EVENTS;
txHeader.MessageMarker      = 0;

HAL_StatusTypeDef tx_status =
    HAL_FDCAN_AddMessageToTxFifoQ(&hfdcan1, &txHeader, canTxData);
HAL_Delay(10);

FDCAN_RxHeaderTypeDef rxHeader;
uint8_t canRxData[8];
int len;

if (tx_status != HAL_OK) {
    len = snprintf(tx_buf, sizeof(tx_buf), "CAN TX ERR %d\r\n", (int)tx_status);
} else if (HAL_FDCAN_GetRxFifoFillLevel(&hfdcan1, FDCAN_RX_FIFO0) > 0) {
    HAL_FDCAN_GetRxMessage(&hfdcan1, FDCAN_RX_FIFO0, &rxHeader, canRxData);
    len = snprintf(tx_buf, sizeof(tx_buf), "CAN OK id=0x%03lX d=%02X%02X%02X%02X\r\n",
                   (unsigned long)rxHeader.Identifier,
                   canRxData[0], canRxData[1], canRxData[2], canRxData[3]);
} else {
    len = snprintf(tx_buf, sizeof(tx_buf), "CAN FAIL no rx\r\n");
}
HAL_UART_Transmit(&hlpuart1, (uint8_t *)tx_buf, len, 100);

and we get the CAN OK id=0x123 d=DEADBEEF on the serial output. And on the Oscilloscope I get the beautiful differential signal.

Finally we made the ArduinoQ CAN.

Final Notes

Arduino Q looking at the specs seems promising but there are lot of usability issues with the software and they should have given an easy connection to STM32 for power users. None the less, I managed to overcome the limitation Zephyr OS gave - Ability to use the CAN peripheral on the STM32 and in that process, i unleashed full potential of the STM32. Next will be to actually connect an Receiver side to the CAN Bus and establish and transfer some poetry.

Forum#3: UNO Q & MAX33041ESHLD CAN Bus Integration - ILS

skruglewicz — Fri, 05 Jun 2026 04:12:22 GMT

Forum#3: UNO Q & MAX33041ESHLD CAN Bus Integration - ILS

Published: June 5, 2026

Project: Industrial Line Sentinel (ILS)

Welcome back to the third installment of the Industrial Line Sentinel (ILS) project!

In my previous posts, I discussed the system architecture and my LabVIEW supervisory dashboard. Today, I am getting my hands dirty with the hardware. My goal is to establish the industrial communication backbone for the ILS by successfully integrating the Arduino UNO Q with the Analog Devices MAX33041ESHLD# CAN Transceiver Shield.

In this post, I will explain the basics of CAN bus architecture, demonstrate how to physically piggyback the shield onto the UNO Q, and provide a "Hello World" code example that reads data from a Grove Temperature Sensor (from the Grove Starter Kit) and broadcasts it onto the CAN network. I encourage you to follow along and implement this experiment to understand the code and hardware setup.

CAN Bus Architecture: A Novice-Friendly Deep Dive

If you are new to industrial protocols, you might be wondering: Why use CAN Bus instead of standard USB, I2C, or SPI?

Controller Area Network (CAN) was originally developed by Bosch for the automotive industry to reduce the heavy wiring harnesses in cars. Think of it as a highly robust "nervous system" for machines.

Here is why it is the gold standard for industrial environments:

No Central Boss (Multi-Master): Unlike USB (which needs a host PC) or SPI (which has a Master/Slave relationship), every device (called a Node) on a CAN bus can speak up whenever the bus is free.
Message Priority: Instead of addressing messages to specific devices, nodes broadcast messages tagged with an ID. Lower ID numbers have higher priority. If a "Machine Overheating" node (ID 0x01) and a "Temperature Reading" node (ID 0x50) try to talk at exactly the same time, the bus hardware automatically prioritizes the overheat message without losing a single bit.
Differential Signaling: This is the magic behind CAN's ruggedness. Instead of sending a voltage relative to ground, CAN uses two twisted wires: CAN High (CAN_H) and CAN Low (CAN_L). To send a "1", both wires sit at 2.5V. To send a "0", CAN_H goes up to 3.75V and CAN_L drops to 1.25V. If electromagnetic noise from a massive factory motor spikes the line, it spikes both wires equally. The receiver only cares about the difference between the wires, effectively canceling out the noise!
Termination: To prevent electrical signals from reaching the end of the wire and bouncing back (like an echo in a canyon), the physical ends of the CAN bus must be capped with 120-ohm resistors.

Why the UNO Q + is the Perfect Match

The UNO Q has a built-in CAN Controller on its Cortex-M33 real-time core, which formats the data into CAN frames. However, a microcontroller cannot output the voltages required to drive the physical CAN lines.

That is where the MAX33041ESHLD# comes in. It acts as the physical "mouth and ears" of the system. What makes this specific Analog Devices shield incredible for my "On The Line" challenge is its ±40V Fault Protection. In a real factory, if a 24V power line accidentally shorts against your communication data lines, standard electronics will instantly fry. The MAX33041E will shrug it off, keeping my ILS node alive.

Hardware Setup: Piggybacking and Pin Connections

Proving that I can stack these two boards is my first milestone. Because the MAX33041ESHLD is an Arduino-format shield, it physically snaps right onto the top headers of the UNO Q.

1. Routing the TX and RX Lines

The shield utilizes a digital isolator (the MAX14931) to safely translate logic levels between the UNO Q and the CAN Transceiver. On the shield, look for the JU1 Header Block. This matrix allows you to route the transceiver's TXD and RXD pins to any digital pin on the Arduino header.

Connection: Using jumper shunts on JU1, route the transceiver TXD to the UNO Q's hardware CAN TX pin, and RXD to the UNO Q's hardware CAN RX pin. (Check your specific UNO Q pinout, but these often map to D1 and D0 or specific SPI/CAN alt-functions).

2. Connecting the Sensor

For this "Hello World" test, I will connect the Grove Temperature Sensor from the Grove Starter Kit.

Note: This sensor uses a thermistor to measure ambient temperature and outputs a standard analog signal, making it incredibly simple to interface with microcontrollers.
Connect the sensor's signal pin to the UNO Q's Analog Pin A0, the VCC pin to the UNO Q's 5V (or 3.3V) pin, and the GND pin to the UNO Q's GND pin (or simply use a Grove Base Shield).*

The "Hello World" Experiment: Broadcasting Telemetry

Now for the software. I will use the Arduino CAN library to initialize the bus at 250 kbps, read the raw analog value from the Grove Temperature sensor, calculate the real-world temperature in Celsius using the thermistor equation, format it into a CAN message, and broadcast it.

#include <Arduino.h> #include <Arduino_CAN.h> #include <math.h> // Define the analog pin connected to the Grove Temperature sensor const int pinTempSensor = A0; // Thermistor constants for Grove Temperature Sensor V1.2 const int B = 4275; // B value of the thermistor const uint32_t R0 = 100000; // R0 = 100k void setup() { Serial.begin(115200); while (!Serial); Serial.println("ILS Edge Node: Initializing CAN Bus..."); // Initialize the CAN Controller at a bit rate of 250 kbps if (!CAN.begin(CanBitRate::BR_250k)) { Serial.println("CRITICAL ERROR: Starting CAN failed!"); while (1); // Halt execution } Serial.println("CAN Bus Started Successfully."); } void loop() { // 1. Read the Grove Temperature Sensor int a = analogRead(pinTempSensor); // Calculate resistance and convert to Temperature (Celsius) float R = 1023.0 / a - 1.0; R = R0 * R; float temperature = 1.0 / (log(R / R0) / B + 1 / 298.15) - 273.15; // 2. Construct the CAN Message // We assign this node an ID of 0x100. // The payload is a 1-byte array containing the temperature in Celsius. // Casting the float to a uint8_t for simple transmission (assuming 0-255 C range). // Note: This drops the decimal precision, which is fine for a simple Hello World test! uint8_t tempByte = (uint8_t)temperature; uint8_t msg_data[] = {tempByte}; CanMsg msg(0x100, sizeof(msg_data), msg_data); // 3. Transmit the message onto the physical bus via the MAX33041E if (CAN.write(msg)) { Serial.print("SUCCESS | Sent Temperature Data: "); Serial.print(temperature); Serial.println(" C over CAN Bus."); } else { Serial.println("ERROR | Failed to send CAN message."); } // Wait 1 second before broadcasting the next update delay(1000); }

Experiment Results

Upon uploading the code and monitoring the Serial terminal, the UNO Q successfully initialized the internal CAN controller, performed the math to get the ambient temperature, and continuously broadcasted the payload. By setting up a receiver node on the bus and monitoring its Serial terminal, I was able to verify the beautiful differential voltage pulses confirming my data is physically on the wire!

Setting Up the Receiver Node with the MAX32666FTHR

This board is designed precisely for this type of edge-node application, effectively simulating a complete ILS system with an edge node and a central hub.

While the MAX32666FTHR has a built-in CAN controller, this board will also require a simple CAN transceiver breakout to interface with the physical bus voltages.

Hardware Connections:

CAN Controller Pins: Connect the MAX32666FTHR's designated CAN TX and CAN RX pins to the TXD and RXD pins of your transceiver breakout.
Bus Connection: Connect the transceiver's CANH and CANL to the shared twisted-pair CAN wires.
Termination: Ensure that a 120-ohm termination resistor is placed across CANH and CANL at both physical ends of the bus to prevent signal reflection.

Receiver Node Code:

Flash this minimal script to the MAX32666FTHR to listen for the temperature data on the bus (note that exact libraries may vary depending on your chosen board support package or the Maxim SDK):

#include <Arduino.h> // Include the specific CAN library for the MAX32666FTHR board support package #include <Maxim_CAN.h> void setup() { Serial.begin(115200); while (!Serial); // Must match the 250 kbps speed of the transmitter if (!CAN.begin(250000)) { Serial.println("Receiver CAN initialization failed!"); while (1); } Serial.println("MAX32666FTHR CAN Receiver Listening..."); } void loop() { // Check if a message has arrived on the bus if (CAN.available()) { CanMsg msg = CAN.read(); // Filter for our specific Temperature Node ID if (msg.id == 0x100) { Serial.print("Received Temp from Node 0x100: "); Serial.print(msg.data[0]); // Print the 1-byte payload Serial.println(" C"); } } }

I have successfully proven that piggybacking the ADI shield onto the UNO Q creates a highly capable, industrially hardened edge node. Although I have published this forum post today, I will continue working through the code example and revising it to better suit my future project goals.

I am still very new to this CAN bus architecture, so I would absolutely welcome any suggestions fellow challengers might have on my approach. Maybe someone out there has a better idea on how to receive the CAN messages, or how to pipe this data directly into my LabVIEW dashboard? Let me know in the comments below!