Find BLE problems
The symptom looks the same. The cause does not. We find it in pairing, GATT, reconnect, and OTA before it becomes a rewrite.
Most BLE faults show up in one of these forms.
Bonding works on your own desk and fails on a second phone, after a restart, or on one Android version.
The device is there, then it is gone. Reconnect in the background is missing, or the app is stuck in a state it never shows.
Values are missing, duplicated, or out of line with the protocol. The screen then shows a fault that actually sits in the firmware or in the app.
OTA completes in development and stops for customers: mid-transfer, on a weak link, or only on one firmware version.
Does your fault look different, or is it several at once?
Book a Product Discovery Call (opens Calendly in a new tab)Services
Where bonding stops, which platform it hits, and what the user sees.
Services, characteristics, and the places where the app and firmware talk past each other.
Drops, reconnect, and what happens in the background when the app is not in front.
The update flow under the conditions that actually occur in the field.
A finding with the smallest change that hits the fault. A rewrite is not the reflex.
First the trace, then the change.
Notes, the reading of the logs, and code changes belong to your team.
You speak with someone who can read both sides. The fault is not passed back and forth between an app agency and the firmware supplier.
A run on the bench often does not explain the customer case. We ask about the phone, distance, battery, the dropout, and the version that is actually out there.
If one place in pairing or in the update is enough, we do not rebuild the app. Starting over is a proposal when the finding supports it.
Your contact
Founder & Software Architect · Albrecht Apps GmbH
Andrej Albrecht looks for faults where BLE products fail in the field: between the app, the firmware, and what the user can still see. The focus is Android, BLE, and architecture that can be maintained.
We email personal download links in your browser language.
Work
An industrial product needed an app that carries the device state in operation. Unclear state between the app and the machine was the daily work, not a side topic.
Long-running development of a product already in commercial use.
His technical skill and expertise in app development, and in the related BLE communication with sensors in mechanical engineering, have been of inestimable value to our development work.
Martin K., INNIRION GmbH, 2024
He is highly committed and delivered on time.
Michael W., Endios GmbH
A lot of responsibility was given to him, and he handled it very well.
Hendrik R., Quantumfrog GmbH
Process
Which symptom, which phone, which device, and since when.
Pairing, GATT, reconnect, or OTA. Often it is a boundary, not “Bluetooth”.
What fails, under which condition, and what the smallest useful change is.
The place in the app or the protocol that hits the case, with a way to reproduce it.
Not only on the bench. The case the customer sees has to be gone in a repeatable way.
A good fit is a team with a concrete failure that needs a finding before anyone rewrites the app.
A focused look at a known dropout is a different job from a product whose link was never stable on several platforms. Without a symptom and a device, a number is only a guess.
On the Product Discovery Call we say whether an analysis is the next step and how tightly it can be scoped.
FAQ
Place pairing, GATT, reconnect, and OTA in one conversation.
Andrej Albrecht · Founder & Software Architect
Article
The article shows where BLE fails between prototype and production: scan, dropouts, protocol. The newsletter follows with more on how to catch those problems earlier.
Read the article: Why connected devices fail between prototype and production
We sent you a confirmation email. After you confirm, you receive the newsletter.