Engineering for devices used on the body

Wearable technology and BLE device development

We develop your concept for a wristband, sensor-equipped accessory or custom body-worn device using compact electronics, low-power software, BLE communication and mechanical design. In custom wearable product projects, VOMRO addresses the interconnected engineering decisions together, from use case to prototype and from measurement to production preparation.

Joint development of sensor, BLE, battery and mechanical body in a wearable device
Conceptual technical illustration Engineering for body-worn devices
IntegritySensor, energy and mechanics
CommunicationBLE architecture suitable for use
VerificationActual usage profile

Your project, your product

Developed confidentially and delivered with source files.

We may work with a confidentiality agreement (NDA) before sharing technical details. At the end of the project, we deliver the source codes, design files and technical documents we have developed to you.

  • NDA before sharing technical information
  • Clear deliverables agreed at the outset
  • Source and technical files at the end of the project
Our confidentiality and delivery process

VOMRO engineering approach

A small device contains many interconnected design decisions.

Developing a wearable device involves more than shrinking a standard board. Where it is worn, duration of use, movement, perspiration, charging frequency and interaction with the phone all affect the electronic architecture. A larger battery may extend runtime but increases weight and enclosure size; more frequent data transfer may provide faster information while increasing the energy budget. Good design balances these choices around the product's actual function.

Motion recording, vibrating notification to the operator, status monitoring of a physical accessory or transferring sensor data to the phone are examples of different projects. The required data quality and response time in each must be defined from the beginning. VOMRO determines together with the customer which sensor will be used within the scope of the project and why, which functions will remain on the device and what will be verified in the prototype. Technical claims are tied to the measured conditions and the objectives of the project.

01

How the device is worn and used informs the design

Devices worn on the wrist, attached to clothing or mounted on equipment experience different movement and user contact. Housing rotation, a loose strap or a shifted sensor can affect collected data. We define how users put on, remove, charge and clean the device. Feedback needed during setup and use guides the choice of display, light, sound or vibration.

The first version's purpose must also be clear. Demonstrating data collection is different from validating comparable results across users. Operating duration, logging interval, offline operation and target physical dimensions become requirements. Prototype evaluation can then assess the intended behaviour as well as appearance.

  • Position on the body, fixation and movement
  • Initial setup, notification and daily usage flow
  • Concrete function that the first prototype will prove
02

Turning IMU and sensor data into the information your product needs

IMU, which includes accelerometer and gyroscope, can provide motion data; but it is not assumed that the raw data provides a meaningful result directly to the user. The measurement range, sampling rate, physical orientation of the sensor and time information are determined. If filtering, event detection or multiple sensors need to be used together, the examples with which the algorithm will be evaluated are defined. Mechanical layout in the wearable device is part of this data processing decision.

Processor and radio runtime can be reduced by using the sensor's event properties or buffer instead of sending raw data at any time. The impact of this approach on delay and recorded data is examined. Data integrity is checked through the actions and usage examples specified in the prototype. For an idea that claims optical or biological measurement, basic electronic verification does not equate to clinical accuracy or medical device suitability; The purpose and scope of verification are planned separately.

  • Sensor range, sampling, direction and time information
  • Local filtering, event and buffering approach
  • Data quality assessment with defined examples
03

We evaluate battery life with usage profile and measurement

Low-power electronics design treats sleep, sensor reading, computation, logging, BLE transfer and user notifications as separate states. Each state's consumption and daily duration contribute to the energy budget. A vibration motor or frequently illuminated indicator can offset the benefit of a low-sleep-current processor. Battery capacity, usage frequency and enclosure size are evaluated together.

Current over time is measured on the prototype, including initial connection, connection loss, repeated connection searches and extended standby. This reveals unnecessary software wake-ups or peripherals left powered. Battery life is not stated as a definitive figure from catalogue capacity and processor ratings alone; it is explained using a defined usage profile and prototype results. Behaviour during prolonged non-use is also included in product requirements.

  • Power budget allocated to states
  • Measurement of current profile and wake-up causes
  • Operating duration target defined for the intended usage conditions
04

BLE connection, phone behavior and close-to-body antenna

BLE device development selects advertising, connection interval, data volume and reconnection behaviour together. Whether a device stays connected or transfers periodically depends on the product. Phone-connected projects define pairing, user consent, disconnection and recovery of pending data when the app reopens. The displayed connection state is distinguished from the time of the last valid measurement.

The performance of the antenna may be affected by the proximity of the battery, metal parts, housing and human body. The placement that looks appropriate on the board may not produce the same result on the wrist-worn prototype. For this reason, communication is evaluated with the real body of the product and in different usage positions. Rather than assuming a fixed range, the required range, data loss and reconnection behavior are checked through pilot scenarios. Necessary antenna and mechanical revisions are made together.

  • BLE data model, pairing and reconnection
  • Connection parameters according to energy and delay
  • Antenna evaluation with housing and usage position
05

Battery, charging connection and mechanical strength are solved in the same product

A connector, contact charging dock or another suitable charging method is evaluated against intended use. Dirty contacts, reversed placement, forces from cables and device behaviour while charging create mechanical and software requirements. Charging, protection and temperature are evaluated for the selected cell. Internal layout aims to reduce physical risks such as battery compression or strain during assembly.

How it carries the electronic circuit board is as important as the comfort of the body, strap or clip. Sweat, moisture, impact and cleaning expectations are derived from the customer usage scenario. The required sealing approach and verification method are defined at the outset; Seeing a prototype alone is not proof of a degree of protection. Installation, removal, cover assembly and service operations are evaluated with 3D examples. If the mass production method will change, the part design is reviewed accordingly.

  • Charging and protection architecture suitable for the cell
  • Enclosure, strap, clip and contact points
  • Mechanical verification plan according to the usage environment
06

We progress from prototype in real use to production testing

In the first electronic example, sensor, power and connection functions are evaluated separately. In the integrated prototype, these functions are tested together with the body, battery and usage position. Low power, data buffer full, disconnection, and restart scenarios are added to the acceptance list. In the pilot study, different usage examples and installation styles are evaluated and the results of the design are recorded under what conditions.

Production preparation defines how each device is programmed, identified and checked for sensor and communication operation. Test points and fixture access are considered from the first layout, especially on small boards. Prototype PCB and assembly support are offered only for VOMRO-developed customer projects. The Bluetooth product qualification process and external work related to the target market and intended use are planned separately. Development tests are not presented as completed certification or a guarantee of medical accuracy.

  • Progressive verification of sensor, power and RF functions
  • Pilot evaluation with real use cases
  • Programming, identification and production test plan
07

Your original product idea developed confidentially, with source delivery

Before sharing the wearable product's usage idea, mechanical details and data processing approach, we sign NDA upon your request. VOMRO provides customer-specific engineering services; It does not turn the developed project into its own sales product. Initially, the scope, prototype goal, acceptance scenarios and technical deliverables are determined. Findings produced in development are matched with relevant hardware, mechanical and software revisions.

Project source code, editable electronic and mechanical design files and technical documentation are delivered at completion. The build environment, data formats and programming information are specified as deliverables, with third-party licences explained separately. For an initial assessment, share where the device will be worn or carried, what it should measure or do, its phone connection and target operating duration. If no technical drawing exists, we turn these expectations into measurable requirements together.

  • NDA on request before technical details are shared
  • Defined scope, prototype and acceptance criteria
  • Delivery of source, EDA/CAD and technical files at the end of the project

How it works

A clear process from start to delivery.

Not every project looks the same; however, the measurable requirement, controlled revision, and field verification steps remain unchanged.

  1. 01

    We define usage

    We determine the mounting method, sensor purpose, connectivity, and energy targets.

  2. 02

    We design it together

    We develop the electronics, low power software, antenna, charging and mechanical structure.

  3. 03

    We verify by measuring

    We evaluate data, consumption, connectivity and mechanical behavior in real use.

  4. 04

    We deliver the files

    We deliver approved source files, designs and production/test information at project completion.

Frequently asked questions

Before starting the project

The technical scope, deliverables and test plan are clarified together according to the requirements of your project.

Can you develop a custom BLE wristband or sensor accessory?

Yes. Depending on the intended use, we determine the scope of the sensor, power, BLE, embedded software and mechanics. Instead of selling a ready-made product, we develop the customer's device project.

Can you tell us the battery life of the wearable device from the beginning?

An initial target and calculation are established from the usage profile and selected components. Sensor sampling, data transfers and notification frequency affect the result. Runtime assumptions are assessed using prototype current measurements and usage tests.

Can the device collect data when the phone is not connected?

Offline logging and later transfer can be designed where memory, energy and usage requirements permit. Logging duration, timestamps, storage capacity status and recovery of pending data on reconnection are defined at the outset.

Is an electronic prototype of a healthcare idea evidence of medical accuracy?

No. An electronics and software prototype evaluates technical functions. Intended medical use, accuracy claims and required external validation are defined separately; a prototype result does not mean those processes are complete.

Are the design and source codes delivered at the end of the project?

Yes. Source codes, editable design files and technical documents of the project are delivered. File formats and delivery list are determined at the beginning; Third party licenses are disclosed separately.

Let's start with your idea

Let's talk about the product you dream of and the need you want to solve.