Not my build but Japanese electronics twitter is lit.

https://x.com/EMakerDragon/status/2108935034191352114/photo/1

Haven’t really seen something like this before. Job posting for embedded SWE for Ford, it specifically says no CS majors.

As someone who once, like many others, have asked in this sub whether a CS major would be welcomed or could get a job as an embedded SWE, this is discouraging to see, even though I know most others companies won’t do this.

I want to say tho, I once doubted if I could enter this field because I see people with CE and EE degrees thrive in embedded, and my coursework never taught me anything relating to hardware.

Now I work as an embedded SWE at a fortune 200 company, although not in an industry I desire. Another caveat is that I never write any bare metal code or work with registers, I implement control systems, but I still work with hardware all the time and my title is embedded SWE.

Not too sure what the point of this post is honestly, ig one question I have is that could this just be a case of the hiring manager looking down on CS degrees?

Edit: guys, at the end of the day, I’m just sad that they are not giving CS majors a chance at all. Yes I understand that CE and EEs take coursework more aligned with the field of embedded, but there are tons of CS people who go out of their way to take embedded courses/learn in their own time.

And yeah, I also understand that the web dev cs people who spam apply to everything aren’t helping. There is probably no good solution to this problem.

But damn yall EEs have such huge egos, yall treat cs majors like how stem majors treat liberal arts majors…

Hi all,

I salvaged the hydraulic unit from an automatic parking barrier: a 36V brushless motor driving a small oil pump that moves two hydraulic cylinders. I want to reuse it for a robotic arm, but the original control board is closed, so I want to replace it with my own PCB.

Situation:

∙	The motor has only 3 phase wires, no hall sensors or encoder.

∙	The only encoder in the system is on the barrier arm, not on the motor.

∙	The pump may have to start under load, with oil already pressurized.

∙	I haven’t measured the current yet. I’ll check what the original board draws and the motor’s winding resistance, and add the numbers.

Constraints:

∙	Low cost.

∙	No ready-made modules or boards: I want to design the PCB myself.

∙	I’ve never made a motor controller at this voltage and power. I’m comfortable with PCB design and firmware, but new to power stages.

What I’d like your advice on:

1.	Which MCU, gate driver and MOSFETs would you pick, and why?

2.	How would you handle motor control and start-up under load?

3.	What are the common mistakes at 36V that I should avoid in layout and protection?

I’ll attach a photo of the original board. Thanks!

Could someone with Keil C51 build a small open-source 8051 project for me?

I'm fixing a power-off bug on an Android car head unit (CVD1810-WJ board, Cmsemicon CMS8S6990 MCU).

There is an MIT-licensed rebuild of its firmware:

https://github.com/NCHILLC/cvd1810-wj-mcu-firmware

The author states it only fits the chip's 12 KB with Keil C51 at OPTIMIZE(9,SIZE). The evaluation linker stops at 2 KB and SDCC gives about 15 KB.

With Keil C51 at C:\Keil_v5, from the repo root in PowerShell:

mkdir obj, lst; .\build_variant.ps1 -Define NOTURNO_SLEEP_FIX

It should report about 12.2 KB and write obj\CM68.hex. Could you send me that file and the "Program Size" line it prints?

Hi everyone,

I've released ModbusLens v2.4.0, and this update is focused on making the tool more useful for real-world Modbus troubleshooting.

The biggest change is multiple devices in one workspace. You can now work with several PLCs, energy meters, remote I/O modules, or other Modbus devices from the same window.

What's new?

1. Multi-device workspace

• Manage multiple Modbus TCP, RTU-over-TCP, and serial devices in one window.
• Each device has its own Unit ID and configuration.
• Devices sharing a physical communication link, such as meters behind a gateway or multiple devices on an RS-485 bus, can share one connection.
• All tools now operate per device, including Tags, Trend, Address Table, Raw Data, Scripts, Scanner, and Diagnostics.

2. Calculated tags

Tags can now use expressions based on other tags' values. They're recalculated after each polling cycle without generating additional Modbus traffic.

Calculated values can also be used in trends, alarms, scripts, the Overview tab, and CSV exports.

3. Better register inspection and scanning

• Bit View: Inspect individual bits in a register and write individual bits directly.
• Redesigned Scanner: A color-coded results grid replaces the old text log, with pagination for large address ranges.
• Create Tags From Scan: Convert scan results directly into Tags rows.
• CSV export: Export results from Scanner, Find Devices, and Serial Discovery for further analysis in Excel.

4. Improvements for real-world communication links

I've also fixed several issues that matter when working with actual devices:

• Replies on shared RS-485 lines and RTU-over-TCP gateways are matched to their corresponding requests, helping prevent incorrect responses from being reported as successful reads.
• TCP auto-reconnect now detects dropped connections more reliably.
• Scanner timeouts no longer abort the entire scan. Inconclusive addresses are marked separately so the remaining range can still be scanned.
• Script tag reads and writes now target the correct registers.
• Theme changes no longer force an immediate disconnection of live devices.

Other additions include workspace auto-save, persistent per-device write bounds, transparent serial-to-Ethernet gateway support, and a gateway mode that forwards requests to a downstream serial device and returns its actual response.

Get ModbusLens

GitHub Releases: https://github.com/CraftParking/ModbusLens/releases

Source code: https://github.com/CraftParking/ModbusLens

ModbusLens is an ongoing project, and I'm interested in feedback from people who work with PLCs, SCADA systems, energy meters, remote I/O, and industrial communication networks.

Bug reports, suggestions, and practical feedback are welcome.

I’ve been working on an AR game for the esp32s3 XIAO board and round screen and realized that I could use the pose estimation from the board to create an object scanner / mesher using space carving and marching cubes. The space carving algorithm uses different views of the object to create voxels weighted by how many views it was visible from and agreed on its position. Then marching cubes uses a LUT to create triangle mesh out of the voxels. The hardest part was getting the camera feed to change resolution from 240x240 to match the round screen for the video feed to a higher resolution for the pictures used for space carving, but with some AI help I got it working. The results are not great and I’m sure I can optimize it to get it a bit better but for a 20$ setup it’s not bad. A possible use case is to quickly create a mesh from small objects that you find while hiking or just to create a digital twin of little trinkets. I’m sure a smartphone could do this with much better results but where is the fun in that. If people are interested I’ll try to share the code which uses my gfx library which I’ve been working on for a minute.

We’re trying to bring an old Thermo Scientific XSeries II ICP-MS back to life and are stuck with what looks like an embedded computer/QNX issue.

The Windows PC is running PlasmaLab 2.6.2.337, while the embedded computer appears to have XSERIES Supervisor 2.5.10.

During boot, the embedded computer detects its SanDisk SDCFH-00 Rev DH X CompactFlash storage, performs a filesystem check, but then fails with:
Unable to start "supervise" (8)

We checked supervise.dat and it appears to be a 32-bit x86 ELF executable for QNX.

There is also a Thermo updater on the Windows PC that transfers files to the embedded computer through COM2, but it doesn’t seem to report which Supervisor version is currently installed.

Originally we suspected a PlasmaLab/Supervisor version mismatch, but since the embedded computer itself cannot start supervise, I’m now thinking the issue could instead be corrupted files, a failing CompactFlash card, missing dependencies/configuration, or another embedded-system problem.

Our current plan is to remove the CompactFlash card, make a complete image of it first, keep the original untouched, and inspect/work from a clone.

Has anyone worked with an XSeries II, PlasmaLab, or XSERIES Supervisor before?

Also, does anyone know exactly what QNX error (8) means when starting an executable?

Would you investigate the CompactFlash/embedded system first, or is there still a realistic chance that updating/matching PlasmaLab on the external PC could solve this?

Any old service manuals, recovery software, Supervisor files, or experience with these systems would be extremely helpful.

I can also provide photos of the boot sequence, embedded computer, CompactFlash card, updater, and exact error screens.