Firmware customisation — the behaviour your deployment expects
USB VID and PID, default video or audio mode, LED behaviour, boot splash and versioned field updates, written for your programme and released as a build number. This page sets out what firmware can change, the release and validation sequence, and how updates are handled after delivery.
To IT teams, integrators and brand owners whose deployment has rules,
Tittron — the B2B division of FlykanTech — invites you to specify how the hardware behaves, not only how it looks. A dock that enumerates under your USB identifiers, a KVM that powers up into the input your operators use, a converter that boots at the mode your imaging process expects: these are firmware decisions, and they are the difference between hardware that works and hardware that works the way your organisation works.
Firmware is written in-house by the team that maintains the platform, so a change is not a request passed to a third party and hoped for. Each programme gets its own released build, with a version number, a change list and a rollback path, and that build is what production units ship with.
Tell us the behaviours your deployment depends on. We will tell you which are firmware changes, which need hardware, and what each costs in lead time and minimum order quantity.
The Tittron teamB2B division of FlykanTech · www.tittron.com
What the service actually solves
Firmware customisation covers everything the product decides on its own: how it identifies itself to a host, what state it starts in, how it signals status, and how it behaves when something changes underneath it. None of it requires new hardware, and all of it is invisible until the unit is plugged in and does the right thing.
This is the layer that makes fleet deployment possible. A thousand docks that enumerate with the same identifiers, start in the same mode and signal status the same way can be managed by policy, imaged and monitored. A thousand docks with default behaviour have to be handled one at a time.
Every programme gets a released build rather than a one-off patch. That build has a version number, is tested against the hardware revision it ships on, is documented in a change list, and can be re-flashed in the field — so a deployment can be updated without being returned.
From behaviour brief to released build
-
01
Behaviour brief
List the behaviours your deployment depends on — identifiers, startup mode, LED meaning, update handling — and the hosts and operating systems involved. We confirm which are firmware-level and which need hardware.
- Accepts a policy document, a support ticket history or a plain list of requirements
- We flag anything that conflicts with a certification or a platform limit
- Host OS versions matter: we test against the ones you actually run
-
02
Feasibility and scope
Each requested behaviour is classified as a firmware change, a hardware change or not possible on that model, with the effort and lead time attached. You choose the set to build.
- Written scope note before any engineering starts
- Effort and lead time stated per behaviour, not as one block
- Alternative models suggested where they fit the brief better
-
03
Build and internal test
The firmware is written, built and tested against the exact hardware revision the programme ships on, including the edge cases your brief implies — hot-plug, sleep and resume, unplugged hosts.
- Build tied to a hardware revision, stated in the release note
- Hot-plug, suspend/resume and unplugged-host behaviour tested explicitly
- A test build is shipped to you before release, not after
-
04
Validation in your environment
You test the candidate build on your own hosts, with your own peripherals and your own software stack. Findings come back as a change list rather than a rejection.
- Test units or a field-update package, whichever suits your setup
- Findings returned as an itemised list with severity
- One revision round included in the engineering scope
-
05
Release and versioning
The validated build is released with a version number, a change list and the update package, and becomes the build that production units ship with.
- Version number and change list issued with the release
- Update package and flashing instructions included
- The released build is stored against your programme reference
-
06
Field updates after delivery
Later changes are released as new versions against the same programme, with a documented update path and a rollback option, so units already deployed can be brought forward without being returned.
- Versioned updates with a documented flashing procedure
- Rollback to the previous version where the platform allows it
- Update packages delivered through your support channel or ours
The numbers, at a glance
| Minimum order quantity | 200–500 pieces for a custom build, depending on the model |
|---|---|
| Scope note | Within three working days of a complete brief |
| Candidate build | 2–4 weeks from scope sign-off |
| Release after validation | 1 week from your approval of the candidate build |
| USB identifiers | Your own VID/PID where you hold one; otherwise a dedicated PID under our VID |
| Versioning | Released build per programme, with change list and rollback path |
| Field updates | Versioned update packages with documented flashing procedure |
| Warranty | Two years; firmware support for the life of the programme |
The figures below are typical values. The quotation states the exact minimums, lead time and commercial terms for your specific programme.
What we actually do
USB identity
VID and PID assignment, device and manufacturer strings, serial-number scheme and descriptor layout, so units enumerate predictably under your asset management and your imaging process.
Default operating mode
Default video input, resolution and EDID behaviour, default audio routing, and startup state — set so the unit does the right thing the moment it is connected.
LED and status behaviour
LED colour, brightness and patterns mapped to the meanings your operators use, including idle, active, fault and firmware-update states.
Update and recovery paths
Field update mechanism, version reporting, failsafe recovery and rollback, so a deployed fleet can be brought forward or back without a return shipment.
Three ways programmes usually start
Identity package
USB VID/PID, device strings and serial scheme. The smallest package, and the one that makes asset management and imaging work at fleet scale.
Behaviour package
Default video or audio mode, EDID handling, LED meanings and power-on state — the set that makes the hardware match how your organisation actually uses it.
Managed programme
Everything above plus versioned release management, signed update packages and a documented rollback path for units already in the field.
Who this invitation is for
Corporate and education IT
Fleets that image, monitor and manage endpoints by policy, where a device that enumerates unpredictably becomes a support cost per desk.
Control rooms and studios
Environments where the startup state, the input default and the status indication are part of the operating procedure rather than a preference.
Distributors and brand owners
Programmes where the branded product should also behave distinctly — startup behaviour and status signalling included in the brand experience.
System integrators
Installations where firmware behaviour is specified in the integration document and has to be identical across every unit on the site.
The resources behind it
These sit inside the same organisation — that is why the work can be quoted, built and shipped as one programme.
Firmware team in-house
The engineers who write your build maintain the platform it runs on, so a behaviour change is resolved in the same team rather than escalated across companies.
One plant, every family
Firmware is flashed during production in the same plant that builds the hardware, so a released build ships on the units rather than being applied afterwards.
Certification awareness
Changes that touch radio, EMC or safety-relevant behaviour are assessed against the certified build, and re-tested where the change makes that necessary.
Cloud Disk and documentation
Released builds, update packages, flashing instructions and change lists stored on your programme’s Cloud Disk, so your support team can pull them without asking.
Commercial terms
| Scope note | Free, within three working days of a complete brief, and binding on cost |
|---|---|
| Engineering charge | Quoted per behaviour set; no charge where the change is a configuration already supported by the platform |
| Minimum order quantity | 200–500 pieces for a custom build, stated in the scope note |
| Payment terms | T/T in advance for first orders; terms reviewed from the second order onwards |
| Version control | Released build stored against your programme; updates released as new versions |
| Confidentiality | NDA on request — your requirements and build stay with us |
| Support | Firmware support for the life of the programme, including field update packages |
| Warranty | Two years on hardware; firmware behaviour covered for the released build |
Standard terms for a first programme. Framework agreements, payment terms and exclusivity are open to discussion from the second order onwards.
What buyers ask first
Do I need my own USB Vendor ID?
No. If your organisation already holds a VID from USB-IF we will use it and assign PIDs under it. If not, we allocate a dedicated PID under our own VID for your programme, which gives you the same enumeration behaviour without the registration process.
Will a firmware change break the certification?
Most behaviour changes do not affect the certified build. Changes that touch radio behaviour, EMC-relevant timing or safety functions are assessed first and re-tested where needed — and the scope note tells you which category your change falls into before you pay for it.
Can we update units that are already deployed?
Yes, where the platform supports field update. You receive a versioned update package and a documented flashing procedure, and your support team can apply it without returning hardware. Rollback to the previous version is available on platforms that support it.
What happens when we place a repeat order next year?
The released build is stored against your programme reference, so a repeat order ships on the same build unless you ask for a new version. If the hardware revision has moved on in the meantime, we re-validate your build against it before shipping.
Is there a minimum for firmware-only changes?
Yes — usually 200 to 500 pieces, because production has to run a dedicated flashing step for your build. Below that, we can often supply the standard build plus a field update package you apply yourself, which we will say plainly if it is the cheaper route.
Specify how the hardware should behave
Send the behaviours your deployment depends on. You will receive a scope note, the lead time and the minimum for a custom build.