Forum - Recent Threads

OpenDFM: A utility for getting the logs

SensoredHacker0 — Thu, 16 Jul 2026 03:50:18 GMT

Whose going to carry the boats??
Who is going to carry the logs?

I work with IDEC PLCs. They have some software which was probably really nice in 1982.
yesterday, I was so infuriated when a log download process kept failing, I went off and made my own utility to get logs.

The general gist is that when the OEM supported software looses connection, you loose the entire set of data you had been downloading.
many of our systems are thousands of miles away, on questionably reliable networks. While you might see 20Kpbs down, locally, remote connections even for small files can take hours at 2-4KBps. then to loose it. .. OMG. or the syntax is convoluted AF, or theres no direct way to automate the process via the OEM supported software.

Well last night, I had enough, and delved into the internal operation of remote SD Card reading, via Maintenance Protocol.

How OpenDFM Works

OpenDFM is a multithreaded graphical client for accessing the SD-card filesystem exposed by IDEC PLCs through the maintenance protocol over TCP.

Each PLC is represented by an independent tab and session object. A session stores the controller’s IP address, TCP port, PLC device identifier, current remote working directory, local destination path, cached directory-entry metadata, active transfer state, and synchronization primitives used to prevent overlapping protocol transactions.
Ethernet maintenance communication normally uses TCP port 2101.

At the transport layer, OpenDFM creates a TCP socket to the PLC and exchanges IDEC maintenance-protocol frames. A conventional request contains:

ENQ control byte 0x05
two-byte device identifier, commonly FF
continuation flag
command and subcommand
command-specific payload
XOR-based block-check character
carriage-return terminator 0x0D

The PLC normally responds with an ACK frame beginning with 0x06, followed by the responding device number, completion status, returned data, BCC, and terminator. Negative protocol responses are decoded separately from TCP errors, socket timeouts, truncated frames, and malformed payloads.

SD-card access uses the PLC’s extended FR filesystem command family. Directory enumeration is stateful. OpenDFM first submits a remote path, such as:

/FCDATA01/DATALOG/1-secLog

The path-open request includes the path length and a NUL-terminated path name. The PLC returns the number of directory entries available in the opened directory context. OpenDFM then issues successive entry-read requests, using the observed FR20 sequence, until every directory record has been retrieved. The final request uses the terminating form of the command so the PLC can release the active enumeration context.

Each returned directory record is parsed into structured metadata. Depending on the record format, this includes:

file-versus-directory type
filename length
filename bytes
file size
FAT-style modification date
FAT-style modification time
additional flags or reserved fields

The date and time fields are decoded from their packed filesystem representation. File sizes are converted from the protocol’s hexadecimal ASCII representation into native integers. Filenames are decoded without treating path separators as local filesystem separators until the remote entry has been validated.

The GUI does not directly display raw protocol responses. Parsed entries are converted into application-level directory-entry objects and inserted into a tree or list model. Directory entries can therefore be sorted, selected, recursively traversed, and associated with transfer actions without repeatedly reparsing the original response bytes.

File retrieval is also stateful and block-oriented. OpenDFM opens the selected remote file, determines or receives its expected length, and repeatedly requests the next block. Returned blocks contain protocol framing plus a binary or encoded data payload. The application removes framing, validates the response, extracts the payload, and appends it to a local output stream.

The local file is normally written incrementally rather than buffering the complete remote file in memory. This allows large logs to be downloaded with a bounded memory footprint. The transfer loop tracks:

expected remote file length
bytes requested
bytes received
bytes committed to disk
current remote offset
retry state
elapsed transfer time
effective transfer rate

A transfer is considered complete only when the protocol reports end-of-file or the accumulated byte count matches the size reported during directory enumeration. A short response, zero-length block before the expected end, invalid BCC, unexpected command status, or socket disconnect is treated as a transfer failure rather than silently producing a truncated file.

Folder downloads are implemented as client-side recursive traversal. The PLC provides only the contents of one opened directory at a time. OpenDFM therefore performs a depth-first or breadth-first walk:

Enumerate the selected remote directory.
Create the matching local directory.
Download each regular file.
Queue or recursively enter each sub-directory.
Repeat until no unvisited directories remain.

The remote path is normalized independently from the local path. This prevents a PLC filename containing parent-directory components, absolute-path syntax, or unexpected separators from escaping the selected local download directory.

Because the PLC’s filesystem commands maintain implicit remote state, command ordering is significant. A directory-open operation establishes the context used by subsequent directory-entry reads. Likewise, a file-open command establishes the context used by following block-read commands. If two operations against the same PLC were interleaved, one command sequence could replace the context required by the other.

OpenDFM therefore serializes filesystem transactions per PLC session. A tab may have only one active directory enumeration, file transfer, or recursive operation at a time. This restriction is not primarily due to Ethernet bandwidth; it is required to preserve the PLC’s stateful command sequence.

Concurrency is applied between PLC sessions rather than within one PLC session. Each tab has its own socket activity, protocol state, command lock, transfer worker, and progress reporting path. As a result, PLC A may download a log while PLC B enumerates a directory, provided the two operations use separate sessions.

Blocking socket and disk operations are executed in worker threads so they do not run inside the GUI event loop. The workers publish status updates through a thread-safe queue or framework signal mechanism. The main interface thread consumes those updates and modifies widgets, progress bars, transfer labels, and tab state. GUI objects are not directly manipulated from network workers.

A typical operation therefore crosses several layers:

GUI action-> PLC session controller

-> filesystem operation

-> maintenance-protocol command builder

-> TCP transport

-> PLC response parser

-> directory-entry or file-block decoder

-> local filesystem writer

-> thread-safe progress update

-> GUI model refresh

Error handling is divided by layer. Connection failures identify an unreachable PLC. Protocol failures identify a syntactically valid exchange rejected by the controller. Filesystem failures identify invalid paths, unavailable SD cards, changed directory contents, or interrupted remote file state. Local I/O failures identify permission errors, full disks, invalid filenames, or failed writes.

OpenDFM can also verify that the SD card is mounted before performing filesystem operations by reading the PLC’s SD-card status devices. On FC6A controllers, special relay M8070 indicates SD-card mount status, while special registers such as D8250 and D8251 expose total and free SD-card capacity. These checks are separate from directory enumeration but provide an early indication that a browsing or download request is likely to succeed.

In effect, OpenDFM translates a stateful, request-response filesystem interface into a conventional graphical file browser while preserving the strict transaction ordering, response validation, and per-controller isolation required by the PLCs.

https://github.com/FOSSBOSS/OpenDFM

Are there bugs? HELL YEAH!
Am I going to fix it? hell ye?

Did I really write this whole thing in one night? LOL NO.
Vid:
[View:https://www.youtube.com/watch?v=CEVq5vb5xj4:640:360]

Next up:
Decoding the SV1 security protocol into practical utilities.

RE: OpenDFM: A utility for getting the logs

colporteur — Fri, 17 Jul 2026 17:31:46 GMT

"Our need will be our creator" Plato

It looks like you dug the burr out of the saddle blanket on this one. Hopefully the ride is smooth from here on out.

I can recall a few "Augh fk-it moments" and just committed to fixing it.

RE: OpenDFM: A utility for getting the logs

kmikemoo — Thu, 16 Jul 2026 03:45:40 GMT

I can't play with it, but I like the concept and execution. 👍

RE: Green Brain - Part III - Water Cannon Chaos

DAB — Tue, 23 Jun 2026 19:53:22 GMT

Nice update on a fun project.

Green Brain - Part III - Water Cannon Chaos

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

I promised a water cannon [emoticon:430192c8113e40579ec1750203f80fde][emoticon:021df5b9678b462da4ec897ab36c19a0] for my plants, so I had to deliver, if only for a forum post.

Recap

Green Brain [emoticon:e8b48dd11aa142a1bf769add09114643] is the idea of tracking plant nodes via an industrial CAN bus to ultimately see which plant needs more water cannon [emoticon:021df5b9678b462da4ec897ab36c19a0].

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.

[View:/cfs-file/__key/communityserver-discussions-components-files/453/20260620_5F00_palying_5F00_around_5F00_with_5F00_firing_5F00_the_5F00_cannon.mp4:640:360]

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 [emoticon:112d628d71ee42569896013ddf370112]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:b5062445-537b-4569-88d7-3fdd4acf230e:type=c_cpp&text=static%20HAL_StatusTypeDef%20adc_read_mv%28HX94C_t%20%2Adev%2C%20uint32_t%20channel%2C%20uint32_t%20%2Amv%29%0A%7B%0A%20%20%20%20ADC_ChannelConfTypeDef%20c%20%3D%20%7B0%7D%3B%0A%20%20%20%20c.Channel%20%20%20%20%20%20%3D%20channel%3B%0A%20%20%20%20c.Rank%20%20%20%20%20%20%20%20%20%3D%20ADC_REGULAR_RANK_1%3B%0A%20%20%20%20c.SamplingTime%20%3D%20ADC_SAMPLETIME_640CYCLES_5%3B%20%20%2F%2A%20high%20source%20impedance%20%2A%2F%0A%20%20%20%20c.SingleDiff%20%20%20%3D%20ADC_SINGLE_ENDED%3B%0A%20%20%20%20c.OffsetNumber%20%3D%20ADC_OFFSET_NONE%3B%0A%0A%20%20%20%20HAL_StatusTypeDef%20st%20%3D%20HAL_ERROR%3B%0A%20%20%20%20if%20%28HAL_ADC_ConfigChannel%28dev-%3Ehadc%2C%20%26c%29%20%3D%3D%20HAL_OK%20%26%26%0A%20%20%20%20%20%20%20%20HAL_ADC_Start%28dev-%3Ehadc%29%20%3D%3D%20HAL_OK%29%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20if%20%28HAL_ADC_PollForConversion%28dev-%3Ehadc%2C%20ADC_TIMEOUT_MS%29%20%3D%3D%20HAL_OK%29%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20uint32_t%20raw%20%3D%20HAL_ADC_GetValue%28dev-%3Ehadc%29%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%2Amv%20%3D%20%28raw%20%2A%20HX94C_VDDA_MV%29%20%2F%20ADC_FULL_SCALE%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20st%20%3D%20HAL_OK%3B%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20HAL_ADC_Stop%28dev-%3Ehadc%29%3B%0A%20%20%20%20%7D%0A%20%20%20%20return%20st%3B%0A%7D]\

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:1037263f-8d25-4200-be6e-f8a4c296006e:type=c_cpp&text=%2F%2A%20I%28%C2%B5A%29%20%3D%20V%28mV%29%20%2F%20Rsense%28%CE%A9%29%20%C3%97%201000%20%2A%2F%0Aint32_t%20i_rh%20%3D%20%28int32_t%29%28rh_mv%20%2A%201000U%20%2F%20HX94C_RSENSE_OHMS%29%3B%0Aint32_t%20i_t%20%20%3D%20%28int32_t%29%28t_mv%20%20%2A%201000U%20%2F%20HX94C_RSENSE_OHMS%29%3B]

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.

RE: SolarSense - Part 8 - Interfacing Humidity and Temperature

arvindsa — Tue, 23 Jun 2026 14:53:18 GMT

Oh yes, and also its more immune to noise and induction. I've have to Appreciate whomsoever chose the sponsored kit. Everything except the ArduinoQ was strictly industrial class. Robust.

RE: SolarSense - Part 8 - Interfacing Humidity and Temperature

saramic — Tue, 23 Jun 2026 12:36:30 GMT

nice - I didn't know about the current measurement and the fact that it is there to allow for longer wires - good learning

RE: Green Brain - Part IV - Nodes Well That Ends Well

arvindsa — Mon, 22 Jun 2026 05:18:58 GMT

Love the title

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 [emoticon:98f842990f454422aa6a04953955f9d9].

Recap

Green Brain [emoticon:e8b48dd11aa142a1bf769add09114643] is the idea of tracking plant nodes via an industrial CAN bus to ultimately see which plant needs ~~more water cannon [emoticon:021df5b9678b462da4ec897ab36c19a0].~~ 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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:8df65e7d-b02b-465e-a450-f9bf4d8e919b:type=text&text=ERR%3A%20setBitrate%20failed%20%E2%80%94%20check%20SPI%20wiring]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:b044f4fe-7e9d-412d-8f8c-d829a1d69479:type=c_cpp&text=Serial.print%28F%28%22CANSTAT%20after%20reset%3D0x%22%29%29%3B%20Serial.println%28readCanstat%28%29%2C%20HEX%29%3B%0A%2F%2F%20expect%200x80%20%28config%20mode%29%20%E2%80%94%200x00%2F0xFF%20means%20SPI%20not%20working%0Aif%20%28mcp2515.setBitrate%28CAN_500KBPS%2C%20CAN_CLOCK%29%20%21%3D%20MCP2515%3A%3AERROR_OK%29%20%7B%0A%20%20%20%20Serial.println%28F%28%22ERR%3A%20setBitrate%20failed%20%E2%80%94%20check%20SPI%20wiring%22%29%29%3B%0A%20%20%20%20while%20%28true%29%3B%0A%7D%0A]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3bd20c51-cc0d-4108-b291-07c759d16dad:type=c_cpp&text=uint8_t%20readCanstat%28%29%20%7B%0A%20%20%20%20SPI.beginTransaction%28SPISettings%2810000000%2C%20MSBFIRST%2C%20SPI_MODE0%29%29%3B%0A%20%20%20%20digitalWrite%28MCP_CS_PIN%2C%20LOW%29%3B%0A%20%20%20%20SPI.transfer%280x03%29%3B%20%2F%2F%20READ%20instruction%0A%20%20%20%20SPI.transfer%280x0E%29%3B%20%2F%2F%20CANSTAT%20register%20address%0A%20%20%20%20uint8_t%20val%20%3D%20SPI.transfer%280x00%29%3B%0A%20%20%20%20digitalWrite%28MCP_CS_PIN%2C%20HIGH%29%3B%0A%20%20%20%20SPI.endTransaction%28%29%3B%0A%20%20%20%20return%20val%3B%0A%7D%0A]

What came back:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:160e84d8-f961-4232-afe9-2629ea755ada:type=text&text=CANSTAT%20after%20reset%3D0x0]

The three possible values tell you exactly what is broken:

CANSTAT	Meaning
`0x80`	Chip alive, in config mode — SPI working [emoticon:599cc6d89e2145289084ee73d7cb364b]
`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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:53e955c6-2b95-4202-9be1-a7659ef659c5:type=c_cpp&text=%23define%20NODE_ID%20%20%20%202%20%2F%2F%201%20%2F%2F%203%20%2F%2F%20change%20for%20appropriate%20node%20ID]

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.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:6beab4ab-ecc4-42e5-9be2-f03780f52870:type=text&text=Node%201%20%E2%86%92%20NODE_ID%201%20%E2%86%92%20CAN%20ID%200x101%0ANode%202%20%E2%86%92%20NODE_ID%202%20%E2%86%92%20CAN%20ID%200x102%0ANode%203%20%E2%86%92%20NODE_ID%203%20%E2%86%92%20CAN%20ID%200x103]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:104c152d-9cbd-419f-9acd-046bac48dd8e:type=c_cpp&text=void%20loop%28%29%20%7B%0A%20%20%20%20delay%282000%29%3B%0A%20%20%20%20%2F%2F%20...%20read%20sensor%2C%20transmit%0A%7D]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:9b1bdbea-70e6-43e3-90ce-47ee760ed5c0:type=c_cpp&text=void%20loop%28%29%20%7B%0A%20%20%20%20%2F%2F%20Stagger%20per%20node%20so%20they%20don%27t%20all%20transmit%20simultaneously.%0A%20%20%20%20%2F%2F%20Base%202s%20interval%20%2B%20NODE_ID%20%2A%20300ms%20offset%20keeps%20nodes%20out%20of%20phase.%0A%20%20%20%20delay%282000%20%2B%20NODE_ID%20%2A%20300%29%3B%0A%20%20%20%20%2F%2F%20...%0A%7D]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:da5cb5d5-b46a-4faf-a3de-a2c02379dc7b:type=c_cpp&text=MCP2515%3A%3AERROR%20sendErr%20%3D%20mcp2515.sendMessage%28%26tx%29%3B%0Aif%20%28sendErr%20%21%3D%20MCP2515%3A%3AERROR_OK%29%20%7B%0A%20%20%20%20Serial.print%28F%28%22ERR%3A%20send%20failed%20code%3D%22%29%29%3B%20Serial.println%28sendErr%29%3B%0A%20%20%20%20%2F%2F%20EFLG%20bit%205%20%3D%20TXBO%20%28bus-off%29.%20Reset%20and%20re-enter%20normal%20mode.%0A%20%20%20%20SPI.beginTransaction%28SPISettings%2810000000%2C%20MSBFIRST%2C%20SPI_MODE0%29%29%3B%0A%20%20%20%20digitalWrite%28MCP_CS_PIN%2C%20LOW%29%3B%0A%20%20%20%20SPI.transfer%280x03%29%3B%20SPI.transfer%280x2D%29%3B%20%2F%2F%20READ%20EFLG%0A%20%20%20%20uint8_t%20eflg%20%3D%20SPI.transfer%280x00%29%3B%0A%20%20%20%20digitalWrite%28MCP_CS_PIN%2C%20HIGH%29%3B%0A%20%20%20%20SPI.endTransaction%28%29%3B%0A%20%20%20%20if%20%28eflg%20%26%200x20%29%20%7B%0A%20%20%20%20%20%20%20%20Serial.println%28F%28%22EFLG%3A%20bus-off%20%E2%80%94%20resetting%20MCP2515%22%29%29%3B%0A%20%20%20%20%20%20%20%20mcp2515.reset%28%29%3B%0A%20%20%20%20%20%20%20%20delay%28100%29%3B%20%20%2F%2F%20give%20oscillator%20time%20to%20stabilise%0A%20%20%20%20%20%20%20%20mcp2515.setBitrate%28CAN_500KBPS%2C%20CAN_CLOCK%29%3B%0A%20%20%20%20%20%20%20%20delay%2810%29%3B%0A%20%20%20%20%20%20%20%20mcp2515.setNormalMode%28%29%3B%0A%20%20%20%20%7D%0A%20%20%20%20return%3B%0A%7D]

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):

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:88f644e1-db30-4ca4-9e99-da988f86a0eb:type=c_cpp&text=%2F%2F%20EFLG%200x2D%3A%20bit5%3DTXBO%28bus-off%29%20bit4%3DTXEP%28err-passive%29%20bit2%3DTXWAR%28warning%29%0A%2F%2F%20TEC%20%200x1C%3A%20transmit%20error%20counter%20%20REC%200x1D%3A%20receive%20error%20counter%0Avoid%20printErrors%28%29%20%7B%0A%20%20%20%20uint8_t%20eflg%20%3D%20readReg%280x2D%29%3B%0A%20%20%20%20uint8_t%20tec%20%20%3D%20readReg%280x1C%29%3B%0A%20%20%20%20if%20%28eflg%20%3D%3D%200%20%26%26%20tec%20%3D%3D%200%29%20return%3B%0A%20%20%20%20Serial.print%28F%28%22%20EFLG%3D0x%22%29%29%3B%20Serial.print%28eflg%2C%20HEX%29%3B%0A%20%20%20%20Serial.print%28F%28%22%20TEC%3D%22%29%29%3B%20Serial.print%28tec%29%3B%0A%20%20%20%20if%20%28eflg%20%26%200x20%29%20Serial.print%28F%28%22%20%5BBUS-OFF%5D%22%29%29%3B%0A%20%20%20%20else%20if%20%28eflg%20%26%200x10%29%20Serial.print%28F%28%22%20%5BERR-PASSIVE%5D%22%29%29%3B%0A%20%20%20%20else%20if%20%28eflg%20%26%200x01%29%20Serial.print%28F%28%22%20%5BWARNING%5D%22%29%29%3B%0A%20%20%20%20Serial.println%28%29%3B%0A%7D]

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 [emoticon:752f32bcc91d4a448db162742a877a4a]
Hook it up to LabView

Source

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

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.

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

shabaz — Sun, 21 Jun 2026 22:51:51 GMT

Always a problem insulating the conductors in small connectors!

One way is to replace the heatshrink with rubber tubing (there is a 3-prong tool that expands the rubber sleeve) and put it on each conductor's insulator, then solder as normal, then slide it over (can lubricate to do that if needed).

The more unorthodox method I like is to instead use little pieces of polyamide tape, and tweezers to wrap it around each conductor individually, after soldering. Takes up very little space, so the connector shells go on easily afterwards.

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:3a82ab50-294c-43d3-8b84-b4860dea5e08:type=text&text=arduino-app-cli%20app%20new%20analog_humi_temp%0Acd%20%2Fhome%2Farduino%2FArduinoApps%2Fanalog_humi_temp]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:17fa2e56-b2e4-4d84-8870-4e02377b6b28:type=text&text=vim%20sketch%2Fsketch.ino]

Sketch source code:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:75f881fe-da61-431b-9451-a65a01fd3680:type=c_cpp&text=void%20setup%28%29%20%7B%0A%20%20Monitor.begin%289600%29%3B%0A%7D%0A%0Avoid%20loop%28%29%20%7B%0A%20%20int%20adcTemp%20%3D%20analogRead%28A0%29%3B%0A%20%20float%20voltageTemp%20%3D%203.3%20%2A%20adcTemp%20%2F%201024.0%3B%0A%20%20float%20currentTemp%20%3D%201000%20%2A%20voltageTemp%20%2F%20165.0%3B%0A%20%20float%20temperature%20%3D%20%28currentTemp%20-%204%29%20%2A%20100%20%2F%2016%3B%0A%0A%20%20int%20adcHumi%20%3D%20analogRead%28A1%29%3B%0A%20%20float%20voltageHumi%20%3D%203.3%20%2A%20adcHumi%20%2F%201024.0%3B%0A%20%20float%20currentHumi%20%3D%201000%20%2A%20voltageHumi%20%2F%20165.0%3B%0A%20%20float%20humidity%20%3D%20%28currentHumi%20-%204%29%20%2F%200.16%3B%0A%0A%20%20Monitor.print%28%22Temperature%3A%20%22%29%3B%0A%20%20Monitor.print%28temperature%29%3B%0A%20%20Monitor.print%28%22%5CtHumidity%3A%20%22%29%3B%0A%20%20Monitor.println%28humidity%29%3B%0A%7D%0A]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:c2f4a963-a54d-4fa0-a550-df6e67a3168d:type=text&text=arduino-app-cli%20app%20start%20.]

And logs you can observe using following command:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:c46dc82e-f4d1-4ffb-9300-836fe452aed9:type=text&text=arduino-app-cli%20monitor]

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 #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 [emoticon:e8b48dd11aa142a1bf769add09114643] 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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:49933340-0406-4123-9f21-eba3968f720b:type=json&text=%5B%7B%22node%22%3A2%2C%22temp%22%3A24.5%2C%22hum%22%3A61.0%2C%22seq%22%3A42%2C%22ok%22%3Atrue%2C%22age%22%3A3%7D%2C%0A%20%7B%22node%22%3A3%2C%22temp%22%3A23.1%2C%22hum%22%3A58.0%2C%22seq%22%3A38%2C%22ok%22%3Atrue%2C%22age%22%3A1%7D%5D]

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:7e181e74-5819-4cbc-a050-43136d3e3ae3:type=text&text=LabVIEW%3A%20%28Hex%200xFFFA4723%29%20Type%20mismatch%20between%20JSON%20and%20LabVIEW.]

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

RE: Green Brain - Part III - Water Cannon Chaos

saramic — Sun, 21 Jun 2026 08:49:21 GMT

one of my sons actually - he only took part when I was a total failure and water and mess was involved 🙂

RE: Green Brain - Part III - Water Cannon Chaos

colporteur — Sun, 21 Jun 2026 06:17:52 GMT

I'm curious. I've seen many videos on this site where pets make cameo appearances.

If the figure hiding behind the pump assembly is a spouse, how did you convince them to participate? What function did they serve in the testing?

The only input I get from my significant other is, "when are you going to clean up this room?" the few times she visits my workshop.

RE: Green Brain - Part III - Water Cannon Chaos

kmikemoo — Sun, 21 Jun 2026 03:25:47 GMT

saramic While this didn't quite turn out like you had wanted, it's still a fun feature. I think the water cannon as a dog deterent is a wonderful idea. Maybe I could get my granddog to stop peeing right at the end of the steps - where we also have to walk. 😆

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

DAB — Sat, 20 Jun 2026 19:15:53 GMT

Nice project.

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:

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:36933d69-e330-4234-84b7-22fd761d9347:type=c_cpp&text=%2F%2A%20UV%20index%20in%20tenths%20from%20GUVA%20output%20voltage.%0A%20%20%20Per%20Adafruit%3A%20UV%20index%20%3D%20V_out%20%2F%200.1%20V%20%20%E2%86%92%20%20tenths%20%3D%20uv_mv%20%2F%2010%20%2A%2F%0Auint32_t%20uv_idx10%20%3D%20uv_mv%20%2F%2010U%3B]

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:49af6926-81c8-4294-9c67-ffbd2cd1ad25:type=c_cpp&text=%2F%2A%20UV%20sensor%20%28GUVA%20analog%29%20on%20ADC1%20rank%201%20%28ADC_CHANNEL_5%20%2F%20PA0%29.%0A%20%20%20Scan%20group%20has%204%20ranks%3B%20all%20must%20be%20drained%20on%20every%20conversion.%20%2A%2F%0Aif%20%28o%20%3C%20%28int%29sizeof%28tlm%29%20-%2016%29%0A%7B%0A%20%20%20%20uint32_t%20uv_raw%20%3D%200%3B%0A%20%20%20%20if%20%28HAL_ADC_Start%28%26hadc1%29%20%3D%3D%20HAL_OK%29%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20if%20%28HAL_ADC_PollForConversion%28%26hadc1%2C%2010%29%20%3D%3D%20HAL_OK%29%0A%20%20%20%20%20%20%20%20%20%20%20%20uv_raw%20%3D%20HAL_ADC_GetValue%28%26hadc1%29%3B%0A%20%20%20%20%20%20%20%20%2F%2A%20Drain%20ranks%202-4%20%28HX94C%20RH%2C%20HX94C%20TEMP%2C%20RAIN%20AO%29%20%2A%2F%0A%20%20%20%20%20%20%20%20for%20%28int%20r%20%3D%201%3B%20r%20%3C%204%3B%20r%2B%2B%29%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20if%20%28HAL_ADC_PollForConversion%28%26hadc1%2C%2010%29%20%3D%3D%20HAL_OK%29%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%28void%29HAL_ADC_GetValue%28%26hadc1%29%3B%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20HAL_ADC_Stop%28%26hadc1%29%3B%0A%20%20%20%20%7D%0A%20%20%20%20uint32_t%20uv_mv%20%3D%20uv_raw%20%2A%203300U%20%2F%204095U%3B%0A%20%20%20%20o%20%2B%3D%20snprintf%28tlm%20%2B%20o%2C%20sizeof%28tlm%29%20-%20o%2C%20%22%20uv_mv%3D%25lu%22%2C%20%28unsigned%20long%29uv_mv%29%3B%0A%7D]

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.

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.

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:d50e57cc-bf25-450f-af81-d19139d8bb8d:type=text&text=%23include%20%3CCAN.h%3E%0D%0A%0D%0A%23define%20TX_GPIO_NUM%20%20%205%0D%0A%23define%20RX_GPIO_NUM%20%20%204%0D%0A%0D%0Avoid%20setup%28%29%20%7B%0D%0A%20%20Serial.begin%20%28115200%29%3B%0D%0A%20%20while%20%28%21Serial%29%3B%0D%0A%20%20delay%20%281000%29%3B%0D%0A%0D%0A%20%20Serial.println%20%28%22CAN%20Sender%22%29%3B%0D%0A%0D%0A%20%20%2F%2F%20Set%20the%20pins%0D%0A%20%20CAN.setPins%20%28RX_GPIO_NUM%2C%20TX_GPIO_NUM%29%3B%0D%0A%0D%0A%20%20%2F%2F%20start%20the%20CAN%20bus%20at%20500%20kbps%0D%0A%20%20if%20%28%21CAN.begin%28500E3%29%29%20%7B%0D%0A%20%20%20%20Serial.println%28%22Starting%20CAN%20failed%21%22%29%3B%0D%0A%20%20%20%20while%20%281%29%3B%0D%0A%20%20%7D%0D%0A%7D%0D%0A%0D%0Avoid%20loop%28%29%20%7B%0D%0A%20%20%2F%2F%20send%20packet%3A%20id%20is%2011%20bits%2C%20packet%20can%20contain%20up%20to%208%20bytes%20of%20data%0D%0A%20%20Serial.print%28%22Sending%20packet%20...%20%22%29%3B%0D%0A%0D%0A%20%20CAN.beginPacket%280x12%29%3B%0D%0A%20%20CAN.write%28%27h%27%29%3B%0D%0A%20%20CAN.write%28%27e%27%29%3B%0D%0A%20%20CAN.write%28%27l%27%29%3B%0D%0A%20%20CAN.write%28%27l%27%29%3B%0D%0A%20%20CAN.write%28%27o%27%29%3B%0D%0A%20%20CAN.endPacket%28%29%3B%0D%0A%0D%0A%20%20Serial.println%28%22done%22%29%3B%0D%0A%0D%0A%20%20delay%281000%29%3B%0D%0A%0D%0A%20%20%2F%2F%20send%20extended%20packet%3A%20id%20is%2029%20bits%2C%20packet%20can%20contain%20up%20to%208%20bytes%20of%20data%0D%0A%20%20Serial.print%28%22Sending%20extended%20packet%20...%20%22%29%3B%0D%0A%0D%0A%20%20CAN.beginExtendedPacket%280xabcdef%29%3B%0D%0A%20%20CAN.write%28%27w%27%29%3B%0D%0A%20%20CAN.write%28%27o%27%29%3B%0D%0A%20%20CAN.write%28%27r%27%29%3B%0D%0A%20%20CAN.write%28%27l%27%29%3B%0D%0A%20%20CAN.write%28%27d%27%29%3B%0D%0A%20%20CAN.endPacket%28%29%3B%0D%0A%0D%0A%20%20Serial.println%28%22done%22%29%3B%0D%0A%0D%0A%20%20delay%281000%29%3B%0D%0A%7D]

RE: Making a CAN Network

DAB — Sat, 20 Jun 2026 19:15:05 GMT

Very nice.

RE: Friendly Reminder - On The Line Build Period Ends This Sunday

arvindsa — Sat, 20 Jun 2026 08:22:43 GMT

Aye Aye, All engines, Ahead Full.