Weighing scale integration

# Job Description — Scale & Hardware Integration Engineer (Contract / Contract-to-Hire) **Company:** CattleXpert **Role:** Weigh-Scale / Serial-Device Integration Engineer **Engagement:** Contract or contract-to-hire, remote OK (must overlap US working hours; occasional on-site at a feedyard for live hardware testing is a plus) **Reports to:** Engineering lead, CattleXpert core platform ## The problem we need solved CattleXpert is feedyard/cattle-management software. A critical part of our daily workflow is reading live weights from cattle scales into the application — at induction, processing, feed-truck loading, and shipping. **This integration is currently unreliable**, and weighing problems directly disrupt our customers' operations. We are looking for an engineer who has done real-world third-party hardware integrations — specifically **serial/TCP weigh-scale indicators** — to come in, understand our existing implementation, stabilize it, and help us define a reliable long-term setup and troubleshooting process. This is a hands-on engineering role *and* a knowledge-transfer role: we want someone who can both fix the code and tell us what a correct, maintainable scale integration looks like. ## What you'll be working with (our current stack) - **Language/platform:** C# / .NET (Framework), legacy ASP.NET WebForms web app plus a Windows companion application. - **Hardware access:** Because the browser can't access serial ports, a local Windows process (`CattleXpertWindowsWrapper`) hosts a **WebSocket server** (SuperSocket). The web UI requests a weight over WebSocket; the Windows process opens the COM port, reads the indicator, parses the weight, and pushes it back. There is also a direct serial path in our smart-client (`ScaleIntegration.cs`). - **Transports:** RS-232 **serial** (COM port — baud rate, data bits, parity, stop bits all configurable) and **TCP/IP** (IP:port). - **Indicators we support today:** Avery Weigh-Tronix 640 / 640PC / 104, Digi-Star EZ2400 / Z320, generic ASCII serial indicators, plus EID (RFID tag) readers. - **Configuration:** Database-driven (SQL Server stored procedures) and managed through an in-app "Device Setup" admin screen that maps each workstation to a scale, port, and protocol-framing parameters (start char, end char, data start position, data size, lookup text, etc.). ## What you'll do 1. **Learn and document the current integration** end to end — the WebSocket bridge, the serial read/parse code, and the device-configuration data model — and produce a clear architecture write-up our team can maintain. 2. **Stabilize weight capture.** Concretely, we know we need: - **Stable-weight / motion detection** so we record a settled weight, not the first value off the wire. - **Timeouts, reconnect, and retry logic** so a dropped cable or power-cycled indicator recovers gracefully instead of hanging. - **Robust frame parsing** that handles partial messages, decimals, negative/tare values, and lb/kg units — replacing today's fragile fixed-position substring logic. - **Logging and an audit trail** of what was sent/received, so field issues are diagnosable. 3. **Consolidate duplicated code.** There are currently three near-identical copies of the scale-reading logic; unify them into one tested component. 4. **Validate against real hardware** (or realistic simulators) for each supported indicator, and produce a per-indicator setup/troubleshooting guide (cabling, port settings, expected data format, common failure modes). 5. **Advise on architecture** — tell us whether the WebSocket-bridge approach is the right long-term design or whether there's a more reliable pattern. ## Must-have experience - Proven, **shipped integrations with industrial/measurement serial devices** — weigh-scale indicators strongly preferred (Avery Weigh-Tronix, Digi-Star, Rice Lake, Gallagher, Tru-Test, or equivalent). - Deep, practical **RS-232 / serial communication** knowledge: baud/parity/data bits/stop bits/flow control, framing and terminators (STX/ETX/CR/LF/EOT), and reading vendor protocol/datasheets to reverse-engineer a data format. - **C# / .NET**, including `System.IO.Ports.SerialPort`, its threading/event model, and thread-safe handling of streaming data. - Experience designing **stability detection, timeouts, reconnect/retry, and error handling** for flaky physical hardware. - Ability to **debug at the wire level** — serial sniffers, loopback testing, hex-dump analysis of live streams. - Comfortable working in a **legacy codebase** (WebForms / WCF / stored-procedure-driven config) and improving it surgically without a full rewrite. ## Nice to have - TCP/IP serial-over-Ethernet device servers (e.g., Moxa/Lantronix) and socket programming. - EID / RFID tag reader integration in a livestock or industrial context. - SuperSocket or other C# WebSocket server libraries. - Background in agriculture, feedyard, livestock, or industrial-weighing software. - Experience building hardware simulators/mocks for automated regression testing. ## How we'll evaluate fit Be ready to talk through a real scale integration you've done: how you discovered the indicator's data format, how you decided a reading was "stable" and safe to record, and how you handled disconnects and bad data in production. We value concrete war stories over framework buzzwords. ## Deliverables (first engagement) - Architecture + protocol documentation of the current scale integration. - A unified, tested weight-capture component with stability detection, timeouts, reconnect, logging, and correct unit/decimal handling. - Verified support and a setup/troubleshooting guide for each currently supported indicator. - A recommendation on the long-term architecture.