Skip to main content
GullySystem
Manufacturing · IoT Device Manufacturer Management Software

One system for device identities, firmware, calibration, provisioning and returns.

Every unit keeps one record from the first flash to the last shipment. It holds the hardware revision, the IMEI or MAC address, the firmware image, the calibration offsets, provisioning, burn-in and any return. Firmware engineers, line testers, support staff and the cloud team read the same page, from the pogo-pin test bed through to the customer site.

  • Identifier formats such as IMEI ranges, MAC blocks and cloud device ID rules entered as you build, with duplicate checks from the first unit
  • Shipped devices, open batches and unresolved returns migrated from the sheets you keep, with a sample of identifiers checked before launch
  • Changes to provisioning steps, fixture fields and carton label layouts handled by GullySystem staff on request, without a developer on your side

Makers of connected sensors, trackers and gateways hold hardware revisions, build batches, device identifiers and firmware builds together, with GullySystem configuring the screens around your line. Each unit keeps its IMEI or MAC address, firmware build, calibration offsets and fixture result from the first flash to the last shipment. Provisioning, shipment and returns attach to that record.

Where it breaks today

What goes wrong before the software.

Revisions and firmware drift apart

Pairing is by habit. A rev C board needs build 2.3.1, yet the line flashes whichever image sits on the shared drive, and the mismatch surfaces only after the unit fails to join a network.

Identifiers live in four lists

One typo breaks it. The label serial, the MAC address in the programmer log and the cloud device ID are copied between sheets by hand, and one transposed digit severs the chain.

Calibration cannot be looked up later

Offsets stay on the device. A thermistor is trimmed at the fixture and the offset is stored only in flash, so support cannot see it when a customer says readings drift.

A bad component lot is hard to bound

A radio lot gets flagged. The affected units sit in three batches shipped to two customers, and nobody can list the serials without opening four spreadsheets.

Provisioning steps are done by hand

Skipped steps surface late. Certificates, keys and SIM activation are applied unit by unit, and a missed step is found only when the customer’s device fails to register on the network.

Returns restart diagnosis from zero

The first hour is wasted. A unit arrives with a one-line complaint, and its build date, firmware and fixture results are scattered across other places that the support engineer must hunt through.

How it runs

How the work flows through it, step by step.

  1. 1

    Hardware and firmware release

    Engineering releases a hardware revision. Its bill of materials is frozen beside the firmware build cleared to run on it, and the pairing is recorded for production to follow.

  2. 2

    Component purchase

    Parts arrive with lot numbers. Reels of chips, radio modules, cells and enclosures are booked in on the purchase order with the reel label’s lot and date code, then shelved by lot.

  3. 3

    Build batch and programming

    A batch opens with its reel lots. Units are programmed over SWD or JTAG with the paired firmware, and the device identifiers are captured at the same moment.

  4. 4

    Test and calibration

    Fixtures check the work. Sleep current, radio output power and sensor readings are measured on the pogo-pin bed, and the calibration offsets are written to the device and saved against the unit.

  5. 5

    Provisioning and burn-in

    Keys or certificates are issued per unit and network activation is logged, while units that need soak time spend it in the burn-in rack before final inspection.

  6. 6

    Shipment and field returns

    Devices ship against the order. The identifiers in each carton are listed on the delivery note, and a unit that comes back is logged and linked straight to its original build, batch and reel lots.

Modules

What is inside.

Every module can be switched on, left out or changed to match how your team already works.

Hardware revisions and bills of materials

One page per PCB spin. It holds the component list, the Gerber package reference, the stencil and the firmware images cleared to run on that revision.

Firmware release register

Every build is registered. Release notes, the file reference and the checksum are stored, together with every unit programmed or updated with that build and the date it was done.

Component purchase and lot receipt

Reels and trays stay traceable. Board parts, radio modules, battery cells and enclosures are received with supplier lot, date code and moisture sensitivity level noted, so an expired reel is never loaded on the SMT line.

Build batches

A batch is opened per run. Reel lots used are linked to it, and quantities built, tested, reworked and scrapped are tracked from the SMT line to packing.

Device identity register

One row per unit. Serial number, IMEI or MAC address and cloud device ID are stored together, and the register refuses a duplicate on entry.

Calibration and fixture results

Numbers stay with the unit. Sensor offsets, radio output readings and pass or fail results are saved for every unit tested on the fixture.

Provisioning and activation log

Nothing secret is stored. The log records which keys or certificates were issued, SIM or network activation, and registration status per device.

Burn-in and final inspection

Racks are tracked by slot. Units are followed through the burn-in racks and then through the final visual check, label check and carton count before packing.

Shipments and customer lists

Cartons carry a list. Devices are packed against an order, their identifiers are printed on the delivery note, and the same list is kept for the customer.

Returns and failure analysis

Every return gets a case. The unit is logged with its build history, the fault found and the repair or replacement, and faults are grouped by batch and firmware.

Solutions inside

The business modules it is built from.

Each one is also available on its own, or inside a system built for you.

  • Bill of Materials

    Each board revision lists its parts and the firmware builds it can run, so a pairing is checked before programming begins.

  • Goods Receipt (GRN)

    Radio modules, cells and enclosures are checked against the order on arrival and booked with supplier lot and date code.

  • Batch and Serial Tracking

    Serial number, IMEI or MAC address and cloud device ID are held per unit, so any one of them finds the other two.

  • Work Order Management

    A batch is released with its reel lots and quantities, then moves from programming through test to packing with counts at each step.

  • Quality Control

    Sensor offsets, radio values and pass or fail outcomes are saved for each unit tested, and failing units are held back from packing.

  • Ticket Management

    A returned unit becomes a numbered case showing its build history, the fault found and the repair or replacement given to the customer.

  • Order Management

    Customer orders are packed with device identifiers listed on the delivery note, and the same list stays on file for the customer.

  • Document Management

    Release notes and file references for each firmware build are filed with the version and visible to production and support.

Services

How we would put it in.

Setup, data migration, integrations and anything built on top.

Who uses it

One system, each person sees their part.

For firmware and hardware engineers

Pair builds with boards. Engineers release revisions, link them to firmware builds, and see which devices in the field run which version without asking the production floor.

For production and test

Open a batch, program and calibrate the units, and record pass or fail against each serial number as it leaves the fixture, so the batch yield is never reconstructed afterwards from memory.

For purchasing and stores

Buy radio modules and cells, record the lots received, and see at once which batches used a lot that the supplier has flagged.

For support

Look up by identifier. Support reads the firmware, calibration offsets and fixture history of a device before answering the customer.

For the owner

Read yield by batch, returns by cause, and the customer orders held up waiting on radio modules or cells.

Reports

The numbers the owner asks for.

  • Devices by hardware revision and firmware build
  • Batch yield at programming, test and burn-in
  • Units carrying a flagged component lot
  • Provisioning failures by step
  • Returns by batch, firmware and fault
  • Shipped devices by customer with identifiers
  • Calibration offsets outside the usual spread
Good fit

Who this is built for.

  • Makers of battery-powered sensors and data loggers that sit in cold rooms, water wells and grain silos for years
  • Builders of asset trackers and fleet telematics units that carry a SIM or an eSIM
  • Manufacturers of smart meters, LoRaWAN gateways and edge controllers installed on poles, panels and farm sheds
  • Start-ups that design a connected device and manufacture it in house or through a contract assembler on an SMT line
  • Companies that provision devices with keys and network activation before shipping them to customers
Honest answer

When it is not the right choice.

Made to fit

Adapted to your business before it goes live.

You are not handed a login and left to it. The product is set up around your records, your people and the tools you already use.

Identifier formats

Your serial scheme drives the setup. MAC address blocks, IMEI ranges and cloud device ID rules are entered, with duplicate checks on every new unit.

Firmware naming

The way you number builds and pair them with revisions is set up so that a mismatch is flagged at the programming step, before a unit leaves the bench.

Fixture and programmer logs

Exports are reviewed first. How your test fixture and programmer write their log files is checked with your engineers so the values can be imported.

Shipped base migrated

Devices already in the field arrive with their IDs and the firmware version last seen, copied from your existing sheets, and we spot-check a sample first.

Works alongside

  • Email
  • Programmer and fixture log files
  • Label printers
  • Cloud device registry
  • Accounting export
Common questions

Questions owners ask before a demo.

Does it update devices over the air?

No. Your cloud platform does that. The software records which firmware each device was built with, and which later updates were applied when the cloud sends that back.

Can it stop a wrong firmware from being programmed?

It can flag a pairing that your engineers have not approved when a batch is opened for programming, before any unit is flashed. The programmer itself stays outside the system.

What if a component supplier recalls a lot?

Search by the radio module or cell lot. The system lists the batches and device identifiers that carry it, with the customers they shipped to and the dates they left.

How do keys and certificates stay safe?

Secret material belongs in your key management system. This records which devices were provisioned and when, and never holds the secrets themselves.

Can a customer receive a list of their device IDs?

Yes. Each shipment lists the identifiers of every unit in the carton, and an export file can go to the customer’s own device registry.

Can it deal with devices built by a contract assembler?

Yes. The assembler’s batches and test files are recorded on the batch, and you still hold the firmware and identity record yourself.

How are existing devices moved in?

Identifiers, shipment dates and known firmware versions are imported from the lists you keep, and support checks a sample of rows before anything goes live. Gaps are listed.

What decides the cost?

Users, product lines and fixture imports decide it. Before any quote reaches you, we walk through the screens using a gateway or sensor node from your own range, with your identifier format.

Wondering what it would cost? Share your requirements and an engineer will come back with a scope.

Book a demo

See IoT Device Manufacturer Management Software with your own data.

Tell us how you run things today. We’ll show you the parts that matter to you and say plainly what would need changing.

  • No obligation
  • A reply within one business day
  • Your details stay private

Start with your requirements

Seven short steps that tell us what you need. An engineer reads them before getting in touch.

Share your requirements