@GarageBoatBuilder , I’d really like to see some boats built in a garage. Sounds like you’ve tried various RF channels, i’m guessing you’ve used network analyzer apps on your phone to figure out local networks broadcasting SSIDs to get a sense of congestion and which channel(s) make sense to use.
Given your experiments and RF experience, do you suspect the antenna on your specific Maslow controller’s ESP32 module is the problem?
If so, sounds like you’d like an ethernet or USB wired connection. I previously ran 10ft USB cable to a CNC controller, I didn’t provide decent strain relief, so jobs failed enough into frustrating me to make wifi work.
If you’re unable to improve wifi in your env for reason(s), then am wondering if stranded ethernet to an additional raspberry Pi (or similar modest compute with ethernet port) that rides on the Sled, and runs serial port proxy to the Maslow controller over USB cable between the Pi and the stock Maslow controller?
What’s the recommended setup for someone that must run their Maslow wired instead of wifi? Just spit balling possible solutions. Critiques/suggestions welcome if that leads to working solution that helps churn out some garage born boats.
EDIT: I dug around to better understand what Ethernet over USB means, involves, and would enable. https://github.com/MaslowCNC/Maslow_4/pull/983 seems neat, even though USB CDC-ECM support wouldn’t help Windows users?
More details…
AI Generated detailed comparison of Serial-over-USB vs Ethernet-over-USB
Wired USB control options: Serial vs Ethernet-over-USB
Both use the same USB-C data cable and have the same basic USB cable-length / EMI limitations. Ethernet-over-USB improves the software/UI experience, not the physical noise immunity.
| Topic |
USB Serial / COM Port |
Ethernet-over-USB |
| PC sees Maslow as |
COM / serial device |
Network adapter |
| Main use |
G-code, jog, logs, recovery |
Full browser UI over HTTP/WebSocket |
| Normal Maslow Web UI |
Requires serial-aware UI/proxy; may lose features |
Works much like Wi-Fi UI |
| File upload / downloads |
Awkward or not supported by basic serial mode |
Best option; normal HTTP uploads |
| Settings / calibration / files |
May need special serial implementations |
Can reuse normal WebUI paths |
| Diagnostics / raw commands |
Excellent |
Good, but serial is still better for console/debug |
| Windows 11 |
Very easy; CDC serial is native |
Use CDC-NCM or RNDIS; ECM alone is not a good Windows target |
| Linux / Raspberry Pi |
Very easy |
ECM or NCM are good options |
| macOS |
Very easy |
ECM is likely the simplest target; validate NCM/RNDIS behavior |
| Browser compatibility |
Web Serial is mainly Chromium browsers; desktop senders work everywhere |
Any normal browser once network/IP is connected |
| Long-distance approach |
Direct USB gets less attractive as length/noise increases |
Short USB to Pi/controller, then long Cat5e/Cat6 Ethernet |
| Physical EMI advantage |
None versus USB networking |
None versus serial; same USB cable/port |
| Firmware effort |
Lower |
Higher: USB networking, IP config, host compatibility |
| Best near-term fallback |
Yes |
More work |
| Best long-term wired product solution |
Useful backup / recovery path |
Yes |
Recommended architecture
Maslow USB-C composite device
├─ USB CDC Serial → logs, recovery, raw commands, basic G-code control
└─ USB NCM Network → full WebUI, file upload, settings, calibration, live status
For Windows direct USB control, target CDC-NCM, not the current experimental CDC-ECM implementation. For a Raspberry Pi bridge, ECM or NCM can work well: keep USB short near the CNC, then use long wired Ethernet to the user PC.
Bottom line: Serial is the fastest “get me cutting without Wi-Fi” path. USB networking is the better path for preserving the full Maslow browser experience. The experimental Maslow Web Serial work itself hid some HTTP-dependent UI features, while the USB-network approach was designed to keep the existing network UI model.