Acquisition and data validity
Implement sensor drivers, settling time, sampling schedules, units and timestamps. Distinguish a valid reading from warm-up, missing data, out-of-range input or a sensor fault.
Embedded software
development.
From sensor inputs.
To dependable device behaviour.
Translate a monitoring requirement into firmware that can be integrated, tested and maintained on the selected hardware. Hitelecom scopes acquisition, device states, communications and diagnostic behaviour around the measurement and deployment. Define what happens when a sensor is unavailable, a connection is interrupted or power returns. Local configuration, remote updates and security functions are designed into the project where required; their implementation depends on the board, memory and receiving system.
FirmwareDefined device behaviourDocument states, interfaces and timing
IntegrationHardware and data pathsConfirm components, protocols and payloads
VerificationAgreed acceptance testsCover expected operation and relevant faults
Engineering focus
Device behaviour.
Specified for field operation.
An embedded project needs more than a working payload. Specify the timing, state transitions, retained data and recovery behaviour that make the device useful in the field.
Event and reporting logic
Separate measurement, event evaluation and periodic reporting. Define hysteresis, persistence, event priority and repeat notifications around the operating workflow.
Power-state engineering
Coordinate MCU sleep, peripheral supplies and modem activity. Measure current by operating state and evaluate the duty cycle on the actual board.
Communication lifecycle
Specify network attachment, session management, bounded retries and reconnection. Agree payload versions, units, device identity and the compatible receiving path.
Local records and continuity
Where memory permits, design record queues, sequence numbers and restart behaviour. Make buffer capacity, overwrite rules and handling of late data explicit.
Commissioning and configuration
Define installation settings, validation rules, authorised access and restore behaviour through the selected local or remote interface. NFC or Bluetooth requires compatible hardware.
Firmware integrity and updates
Where included, specify image authenticity, version compatibility, update storage and interruption handling. Bootloader, rollback and credential protection require a reviewed hardware/software design.
Diagnostics and release evidence
Expose useful reset causes and fault states, and produce a controlled build with test results. Agree source access, dependency records, loading instructions and maintenance responsibilities.
Project planning
Write the behaviour. Then test the device.
A firmware brief should connect each requirement to a hardware interface and a verification method.
01↗
Review the hardware baseline
Confirm schematics, components, memory, interfaces and available prototypes. Identify dependencies on third-party code or module firmware.
- Project inputs
- Hardware revision · Components · Toolchain · Third-party dependencies
02↗
Specify operational states
Describe acquisition, reporting, power modes, configuration and fault recovery with measurable acceptance conditions.
- Project inputs
- State transitions · Timing · Power targets · Fault cases
03↗
Plan release and handover
Agree test fixtures, firmware loading, version control, source rights and post-release support.
- Project inputs
- Test evidence · Release package · Source terms · Support scope
Applications
Firmware for real devices. Tasks that can be verified.
Explore device-specific development briefs rather than a universal firmware package. The examples connect a practical monitoring task to required inputs, proposed software outputs and an acceptance check. Supported sensors, radios and interfaces are selected for each project.
12 application areas / 36 project tasks
Illustrative environments, not evidence of customer installations. Project suitability is assessed against the agreed requirements.
01Cold-chain and laboratory recorders3 +
Preserve the meaning and sequence of temperature records during changing measurement and connection conditions.
Scheduled temperature records
+
Keep acquisition timing independent of when a network upload succeeds.
- Required inputs
- Probe interface, clock source, sample and report intervals.
- Scope & outputs
- Timestamped records and an explicit sampling state machine.
- Acceptance checks
- Compare record spacing and timestamps against the test clock.
- Engineering considerations
- Clock correction and restart must not silently relabel older samples.
Excursion event handling
+
Turn a configured temperature limit into a traceable device event.
- Required inputs
- Limits, hysteresis, persistence and notification policy.
- Scope & outputs
- Event start/clear messages linked to the underlying readings.
- Acceptance checks
- Replay rising and falling test temperatures around each limit.
- Engineering considerations
- A threshold event is monitoring information, not regulatory compliance by itself.
Interrupted-link data retention
+
Retain the agreed record history while the receiving path is unavailable.
- Required inputs
- Available memory, outage duration and overwrite policy.
- Scope & outputs
- A bounded queue with record sequence and upload behaviour.
- Acceptance checks
- Disconnect, fill the queue, restart and reconcile delivered records.
- Engineering considerations
- Storage capacity and any data-loss exceptions must be stated.
02Tilt and structural monitoring nodes3 +
Define reference settings and event behaviour for racks, poles and other monitored structures.
Reference and zero management
+
Keep the installation reference separate from subsequent measured movement.
- Required inputs
- Sensor axes, mounting direction and allowed zero procedure.
- Scope & outputs
- Stored reference settings and reference-change records.
- Acceptance checks
- Apply known orientation changes before and after a restart.
- Engineering considerations
- Zero changes require an agreed authorisation and recovery procedure.
Persistent movement events
+
Distinguish brief disturbances from the movement condition the project needs to report.
- Required inputs
- Angles, persistence time, hysteresis and measurement schedule.
- Scope & outputs
- Configurable evaluation states and event identifiers.
- Acceptance checks
- Replay transient, persistent and recovering angle sequences.
- Engineering considerations
- Filtering must not be described as an engineering safety assessment.
Priority event transmission
+
Report a selected movement event without losing scheduled status information.
- Required inputs
- Radio behaviour, event priority and retry constraints.
- Scope & outputs
- A bounded event queue and reporting sequence.
- Acceptance checks
- Trigger an event during a scheduled upload and a link outage.
- Engineering considerations
- Actual delay depends on detection timing and the available network.
03Motor and machine vibration nodes3 +
Structure vibration acquisition around the selected sensor, machine duty and processing requirements.
Defined acquisition windows
+
Capture repeatable data blocks for the agreed operating condition.
- Required inputs
- Sensor bandwidth, sampling rate, window length and axes.
- Scope & outputs
- Window scheduling, acquisition buffers and data-validity flags.
- Acceptance checks
- Compare captured samples with the agreed stimulus or reference.
- Engineering considerations
- Aliasing, sensor mounting and usable bandwidth remain part of system design.
On-device signal features
+
Implement selected time- or frequency-domain calculations where specified.
- Required inputs
- Required features, units, windowing and processing budget.
- Scope & outputs
- Documented calculations and versioned result fields.
- Acceptance checks
- Run reference waveforms through implementation and comparison scripts.
- Engineering considerations
- RMS or spectral features do not by themselves diagnose a failure.
Triggered records and summaries
+
Combine routine summaries with selected detailed recordings.
- Required inputs
- Trigger rule, pre/post-event storage and uplink capacity.
- Scope & outputs
- A defined summary/event/raw-record transfer policy.
- Acceptance checks
- Exercise quiet, steady-running and triggered test cases.
- Engineering considerations
- Memory, processing and radio budgets limit retained raw data.
04Gas and air-quality instruments3 +
Make sensing status visible alongside concentration values and environmental channels.
Sensor warm-up and validity
+
Avoid presenting start-up or unavailable measurements as valid concentrations.
- Required inputs
- Sensor response states, warm-up requirements and fault outputs.
- Scope & outputs
- A validity model carried with every relevant measurement.
- Acceptance checks
- Test start-up, sensor removal and specified fault responses.
- Engineering considerations
- Detection principle and hazardous-area suitability belong to the supplied hardware.
Multi-channel timing
+
Coordinate gas, temperature, humidity and particle channels with different response behaviour.
- Required inputs
- Channel interfaces, settling times and sample schedules.
- Scope & outputs
- Per-channel timestamps, units and status fields.
- Acceptance checks
- Check channel alignment and unavailable-channel handling.
- Engineering considerations
- Channel independence must remain visible in the receiving data model.
Service and calibration settings
+
Implement authorised coefficient and service-state handling where included.
- Required inputs
- Calibration method, coefficient format and access rules.
- Scope & outputs
- Versioned settings, range checks and service records.
- Acceptance checks
- Load valid and invalid settings and verify restore behaviour.
- Engineering considerations
- Firmware settings do not replace traceable calibration or sensor qualification.
05Water, pressure and level terminals3 +
Represent measurements and site events without hiding interface or process failures.
Process-channel acquisition
+
Convert selected pressure, level and auxiliary inputs into consistent records.
- Required inputs
- Electrical interface, scaling, units and invalid-input rules.
- Scope & outputs
- Channel mapping with raw/status and engineering values.
- Acceptance checks
- Apply known electrical or protocol inputs across the configured range.
- Engineering considerations
- Sensor accuracy and process suitability are separate from numeric scaling.
Level-event stability
+
Scope damping and persistence around changing water-level conditions.
- Required inputs
- Expected fluctuations, threshold policy and reporting needs.
- Scope & outputs
- Documented event states with configurable evaluation settings.
- Acceptance checks
- Replay waves, sustained rises and recovery sequences.
- Engineering considerations
- Do not hide rapid changes without an agreed measurement objective.
Pulse and flow-related totals
+
Maintain the agreed counter and rollover behaviour for compatible pulse sources.
- Required inputs
- Pulse characteristics, scaling, restart and reset rules.
- Scope & outputs
- Counters, totals and reset identification in the payload.
- Acceptance checks
- Inject known pulse counts through restart and rollover tests.
- Engineering considerations
- Flow accuracy depends on the external meter and installation.
06Asset trackers and mobile equipment3 +
Balance position acquisition, movement events and reporting against the intended operating profile.
Movement-based operating states
+
Switch between stationary and moving profiles using the selected motion source.
- Required inputs
- Motion input, state thresholds and wake/sleep policy.
- Scope & outputs
- A documented movement state machine and timestamps.
- Acceptance checks
- Run stationary, movement and intermittent-motion sequences.
- Engineering considerations
- Motion detection capability depends on the installed sensor.
Position acquisition budget
+
Limit acquisition attempts and describe unavailable-position results explicitly.
- Required inputs
- Positioning hardware, time budget and validity criteria.
- Scope & outputs
- Position records with source, time and validity status.
- Acceptance checks
- Test valid fixes, blocked reception and timeout behaviour.
- Engineering considerations
- The firmware cannot guarantee location accuracy or satellite visibility.
Journey record continuity
+
Keep device time, events and position records coherent during coverage gaps.
- Required inputs
- Record types, queue budget and journey boundaries.
- Scope & outputs
- Ordered records with identity and duplicate-handling rules.
- Acceptance checks
- Replay a route with outages, restarts and delayed uploads.
- Engineering considerations
- Location and operational data need agreed access and retention policies.
07Weather, soil and solar field nodes3 +
Coordinate multiple outdoor sensors with supply constraints and maintainable measurement timing.
Mixed-sensor scheduling
+
Schedule sensors with different power-up and settling needs.
- Required inputs
- Sensor list, supply controls and measurement timings.
- Scope & outputs
- A channel schedule and per-channel validity records.
- Acceptance checks
- Observe supply sequencing and known sensor responses.
- Engineering considerations
- Supported probes and interfaces are part of the hardware baseline.
Supply-aware reporting
+
Define behaviour when available energy changes.
- Required inputs
- Supply measurement, operating limits and priority policy.
- Scope & outputs
- Normal, reduced-duty and recovery states where specified.
- Acceptance checks
- Sweep supply conditions and verify transitions and retained settings.
- Engineering considerations
- A power policy does not establish unattended runtime without an energy assessment.
Field commissioning checks
+
Provide installation-time visibility of channels and the receiving path.
- Required inputs
- Commissioning interface, test records and permitted settings.
- Scope & outputs
- An agreed service mode and installation checklist.
- Acceptance checks
- Complete a representative point-to-platform commissioning test.
- Engineering considerations
- Service mode access and its effect on normal records must be defined.
08Gateways and multi-device collectors3 +
Translate specified field records while preserving identity, status and timing.
Field protocol mapping
+
Map supported field registers or frames to a stable application schema.
- Required inputs
- Protocol revision, register map and payload examples.
- Scope & outputs
- Versioned channel mapping and error responses.
- Acceptance checks
- Exercise normal values, exceptions and unsupported fields.
- Engineering considerations
- Modbus or other protocols require the corresponding hardware and agreed implementation.
Radio-device record handling
+
Handle records from the specified radio devices and receiving configuration.
- Required inputs
- Radio hardware, frame definitions and device identifiers.
- Scope & outputs
- Parser rules and device/channel associations.
- Acceptance checks
- Feed valid, malformed, duplicate and unknown-device frames.
- Engineering considerations
- LoRa is not automatically LoRaWAN; compatibility is established per system.
Backhaul recovery and queues
+
Separate field collection from onward connection availability.
- Required inputs
- Backhaul, queue capacity and reconnect policy.
- Scope & outputs
- Bounded queues, status records and retry limits.
- Acceptance checks
- Interrupt backhaul while field records continue to arrive.
- Engineering considerations
- Delivery guarantees must match the complete receiving path.
09Utility meters and cabinet inputs3 +
Give counters and discrete states clear electrical and temporal meaning.
Meter pulse counting
+
Capture compatible meter pulses and preserve totaliser state.
- Required inputs
- Pulse width, frequency, polarity and persistence requirement.
- Scope & outputs
- Debounce, totalisation and non-volatile storage strategy.
- Acceptance checks
- Inject a counted sequence at the agreed input limits.
- Engineering considerations
- External meter characteristics set the usable input envelope.
Contact-state events
+
Interpret door, dry-contact or equipment-state inputs consistently.
- Required inputs
- Input circuit, normal state, debounce and event policy.
- Scope & outputs
- State transition records with timestamps and fault handling.
- Acceptance checks
- Test bounce, repeated changes and restart conditions.
- Engineering considerations
- A monitoring input is not a certified protection or interlock function.
Cabinet condition summaries
+
Combine input states and selected environmental channels in one record.
- Required inputs
- Channel priorities, status combinations and report schema.
- Scope & outputs
- A versioned summary with explicit missing-data fields.
- Acceptance checks
- Compare each state combination with the interface definition.
- Engineering considerations
- Keep measured conditions separate from inferred equipment status.
10Building and facility monitoring devices3 +
Coordinate environmental and occupancy-related inputs around an agreed operational use.
Multi-function room devices
+
Schedule environmental, light and presence inputs without losing channel identity.
- Required inputs
- Installed sensors, trigger inputs and sample requirements.
- Scope & outputs
- Independent channel records and a defined combined payload.
- Acceptance checks
- Exercise each channel alone and in concurrent operation.
- Engineering considerations
- Presence data does not establish identity or guaranteed occupancy counts.
Installation configuration profiles
+
Apply site-specific settings through the supported commissioning interface.
- Required inputs
- Room identifiers, configuration fields and permitted tools.
- Scope & outputs
- Validated profiles with revision and restore behaviour.
- Acceptance checks
- Load, reject, retain and restore representative profiles.
- Engineering considerations
- NFC, Bluetooth or wired setup is included only for compatible hardware.
Exception and heartbeat records
+
Make offline, stale and abnormal states distinguishable at the receiver.
- Required inputs
- Heartbeat interval, status bits and stale-data policy.
- Scope & outputs
- Device status messages and channel-health information.
- Acceptance checks
- Simulate unavailable sensors and interrupted communications.
- Engineering considerations
- A receiver can only assess connectivity after its agreed timeout.
11Industrial equipment retrofit interfaces3 +
Integrate existing equipment data without silently assuming control authority.
Legacy data acquisition
+
Read the specified equipment interface and convert it into monitoring records.
- Required inputs
- Interface documents, electrical levels and permitted access.
- Scope & outputs
- A read-only acquisition path where agreed.
- Acceptance checks
- Compare representative values with the equipment reference.
- Engineering considerations
- Access must respect equipment limits and existing operating procedures.
Counter and cycle observations
+
Capture cycle events from supported signals for operational reporting.
- Required inputs
- Trigger signal, cycle definition and restart handling.
- Scope & outputs
- Timestamped events and counters with explicit reset rules.
- Acceptance checks
- Replay representative operating cycles and interrupted sequences.
- Engineering considerations
- Cycle observations do not automatically establish utilisation or process quality.
Optional command boundaries
+
Define explicit request, acknowledgement and timeout behaviour if remote commands are included.
- Required inputs
- Allowed commands, authorisation and equipment safeguards.
- Scope & outputs
- A documented command state machine and audit fields.
- Acceptance checks
- Exercise accepted, rejected, repeated and timed-out commands.
- Engineering considerations
- Safety-related control requires a separately assessed architecture.
12OEM device integration and release variants3 +
Keep customer-specific behaviour traceable to the correct hardware and release.
Customer protocol variants
+
Adapt payloads and configuration for a named receiving platform.
- Required inputs
- Endpoint, schema, authentication and test access.
- Scope & outputs
- Versioned integration settings and representative messages.
- Acceptance checks
- Perform an agreed end-to-end interoperability test.
- Engineering considerations
- Third-party service access and ongoing subscriptions are separately defined.
Factory provisioning firmware
+
Support agreed identity loading and production verification steps.
- Required inputs
- Serialisation rules, fixture interface and test limits.
- Scope & outputs
- Provisioning commands and pass/fail result records.
- Acceptance checks
- Run a defined batch of known-good and known-fault cases.
- Engineering considerations
- Credentials and manufacturing access require controlled handling.
Controlled update paths
+
Implement the update and recovery design selected for the platform.
- Required inputs
- Memory layout, image signing and interrupted-update requirements.
- Scope & outputs
- Bootloader/update logic and release instructions as contracted.
- Acceptance checks
- Test rejected images, power interruption and recovery on actual hardware.
- Engineering considerations
- Rollback, secure boot and vulnerability maintenance are not automatic inclusions.
Scope & specifications
Development scope. Tied to the hardware revision.
The firmware specification is project-specific; these items define the engineering deliverable.
| Service type | Custom embedded firmware and agreed integration work |
|---|---|
| Hardware baseline | Named board revision, components and supported interfaces |
| Software environment | Agreed MCU or processor, toolchain, RTOS or bare-metal approach |
| Functional scope | Acquisition, state logic, configuration and communication requirements |
| Power targets | Measured acceptance conditions for the specified hardware and duty cycle |
| Fault recovery | Defined timeouts, retry limits, watchdog interaction and diagnostic records |
| Security and updates | Requirements and verification scope expressly included in the contract |
| Testing | Representative hardware, test cases and required evidence |
| Deliverables | Firmware binaries, loading instructions and documentation as contracted |
| Source and support | Source delivery, third-party licences, maintenance and change terms agreed in writing |
Integration & handover
From prototype firmware. To a controlled release.
Agree the evidence and files needed for integration and maintenance.
Confirm requirements
Review interfaces and state behaviour against the available hardware and project priorities.
Integrate and verify
Develop on the agreed platform and test normal operation, relevant faults and recovery conditions.
Release and handover
Deliver the contracted firmware package, release information and documentation with explicit source and support terms.
FAQ
Answers for
your project.
Resolve the technical scope, interfaces and acceptance conditions before committing to a deployment.
Can existing firmware be extended rather than rewritten?
Yes, where the source, build environment, modification rights and suitable test hardware are available. The initial review identifies reusable drivers and application logic, hardware dependencies and missing verification evidence.
What information is needed to quote a firmware project?
Provide the board revision, schematics, components, existing source if available, interface documents and expected state behaviour. Include timing, power, record-retention and recovery requirements with the proposed acceptance hardware.
How are sampling, reporting and alerts separated?
Sampling creates measurements, event logic evaluates defined conditions, and reporting sends records through the receiving path. Each has its own timing and failure behaviour; an event does not imply a guaranteed end-to-end notification delay.
Can a device retain records while offline?
Local buffering can be scoped where storage and power permit. Specify capacity, sequence identifiers, overwrite policy, restart behaviour and how late or duplicate records are handled by the receiving system.
Does firmware development include signal processing?
Selected calculations can be included with documented inputs, units and reference tests. Processing capacity, sensor bandwidth and data quality determine feasibility. Feature extraction is distinct from validated fault diagnosis or prediction.
Can firmware extend battery or solar autonomy?
Power-state and communication scheduling can be evaluated on the selected hardware. Runtime depends on the complete power system, sensing loads, network conditions and environment; it requires a defined energy budget and supporting measurements.
Are MQTT, Modbus or LoRaWAN automatically included?
No. Select the protocol and compatible hardware for the project, then define the exact revision, message mapping and test endpoints. LoRa radio support alone does not establish LoRaWAN compatibility.
How are update failures handled?
The update design should define image verification, version compatibility, storage layout and recovery after interruption. Dual-image storage or rollback needs sufficient memory and an implemented bootloader; its behaviour is tested on the supplied hardware.
What security work is included?
Specify authentication, credential provisioning, authorised settings, image verification and diagnostic access as requirements. Security testing, vulnerability response and any external certification are separately agreed deliverables.
Will we receive source code and a reproducible build?
Source delivery, toolchain versions, build instructions, dependency records and modification rights are stated in the agreement. Third-party components remain subject to their licences; ownership is not inferred from a firmware binary.
How is firmware accepted?
Use a requirements-to-test matrix on named hardware revisions. Include normal operation, boundary inputs, communication outages, power interruptions, persistence and recovery, with recorded expected and actual results.
Why is there no standard product datasheet?
This is a development service. A firmware requirements specification, interface definition and acceptance plan define the work; a fixed product datasheet would not describe the customer-specific hardware and behaviour accurately.
Discuss your project
Define your requirements.
Build the right scope.
Share the board revision, components and required device behaviour. Include available firmware, interface documents and acceptance priorities for technical assessment.
sales@hitelecom.cn ↗