tenkan, the number you want already exists. Every packet that arrives carries a received signal strength with it. I don’t have to invent anything. It just never gets shown to you.
Turtley, the answer you were handed is about something else. Battery statistics and signal strength are two different questions, and I’d say the second one is much the easier of the two.
Why you don’t see it, from where I sit on the manufacturing side. The aid has to report it up to the phone, which costs a little airtime and a little battery, and neither the phone nor the fitting app is set up to hand it to you. On iOS I can’t get that number for a hearing device at all.
But the real reason is duller than any of that. Signal strength jumps about constantly in normal use. Put it on a screen and I start getting messages saying my signal is on three bars, is my aid faulty. It isn’t a hard problem. It’s a support cost nobody wants to carry, and I’d be lying if I pretended my side of the industry was any keener on it than the phone makers.
Which is exactly why I’ve found this thread such heavy going. All any of you can report is a yes or a no. Did it drop or didn’t it. Meanwhile the thing that’s actually moving is a continuous number none of us can see, and I’m sat here trying to infer it from where a phone was in somebody’s trousers.
The best anyone has managed is over on the Reddit side of this, where a chap put his hand flat over his pocket and dropped both aids at once. No meter. He built himself an attenuator out of a hand.
I can’t give you hard numbers on range, but I’ve tested Phonak Infinio Sphere (classic) and Philips 9050 (). Same phone left in the same location in my house. With the Spheres I could get to the door of the bedroom before they started glitching. With the Philips I could lie on the bed and listen to a podcast. Pretty good range for both. For practical purposes both have sufficient range for my needs.
tenkan, the number you want already exists. Every packet that arrives carries a received signal strength with it. I don’t have to invent anything. It just never gets shown to you.
Well I wanna see it, so it’d be good if this simple thing was showing as the “packet” arrives in the App.
That’s the comparison I lost a day ago, and you’ve handed it back better than I had it.
Same person. Same phone, same spot in the house. Two sets of aids, two protocols. I had something like that on Friday and then the man who gave it to me came back and said one of his two ears had never been carrying audio at all. So that row went empty, and I’ve been asking for it ever since.
Yours is cleaner, because both sides were actually in use. Phonak Sphere on classic gets you to the bedroom door before it glitches. Philips 9050 on lets you lie on the bed with a podcast. Same house, same phone, same shelf.
One thing I have to ask. I’m asking because not asking it cost me a whole row last week. What was playing on the Spheres when they started glitching? Glitching sounds like something was. I’d still rather have it from you than assume it.
And your last line is the honest one, so I’m keeping it. Both are enough for what you actually do. I’m not chasing enough. I’m chasing where each one gives up, because that’s the bit nobody prints on the box.
Fair. I’d want to see it too, and I’ve no good answer for you.
The number arrives at your aid on every packet. It dies there, because nothing between the aid and your screen was ever built to carry it. The aid would have to report it up, the phone would have to hand it to an app, and on iOS an app can’t get it for a hearing device at all.
So it isn’t a technical problem, it’s a nobody-built-the-plumbing problem, and I already told you why nobody wants to.
The one thing I won’t do is invent a workaround for you. I don’t have one I’d stand behind.
Although this may not be directly related to your topic, I’m sharing this for your reference.
I am using a Pixel 9a and Oticon Intent 1.
Previously, on Android 16, the connection between the left and right ears was very stable, with almost no disconnections.
However, in the recent Android 17 Beta, frequently disconnects (many users on Reddit have also complained about this). Below is my personal experience with my Pixel:
* Disconnections mostly occur during phone calls (at the exact moment of answering), and even more frequently on 4G/5G cellular calls. The probability is lower for WhatsApp phone calls.
* Disconnections are significantly reduced when connected to Wi-Fi.
* The probability of disconnection on either side aligns with what you mentioned—holding the phone in my left hand actually increases the chance of the left hearing aid disconnecting. Even with continuous automatic or manual reconnection attempts, the issue persists, leading to noticeable power consumption and overheating. Both side finally disconnected after several seconds.
* After asking Gemini multiple times, the main conclusions reached were:
* The underlying audio router in Android 17 was rewritten.
* Even within the same series, the modem and radio module differ between the Pixel 9 and 9a.
* The disconnection upon answering calls occurs because the 4G/5G signal suddenly spikes when a call connects (especially in areas with weak reception), which interferes with Bluetooth LE Audio.
* This issue involves firmware and time-division multiplexing signal technologies. Non-A series modems have stronger signals than A-series ones, so non-A series models received a new driver update to resolve it, while the A-series optimization is still in progress.
As of Android 17 QPR2 Beta 3, the situation has improved significantly, though disconnections still occur occasionally. The only difference now is that disconnections happen more often in the left hearing aid, and this no longer seems to have any correlation with the phone’s physic
This is more related to my topic than you think, and it may be the thing that undoes most of it.
Two weeks I’ve spent controlling for hardware, protocol, body position and venue. I never once controlled for the OS build. You’re the first person here to change one and hold everything else still, and the answer came back loud. Android 16 fine, Android 17 beta not fine, same phone, same aids.
Your last sentence is the one I keep rereading. After QPR2 Beta 3 the left side still drops more, but you say it no longer tracks where the phone is. If that holds, then the pocket effect I’ve been mapping for a fortnight was partly the shape of a software fault, and I was measuring a bug and calling it radio.
Two things I want to keep separate, because someone here got caught by this yesterday. What you measured, I’m taking. What Gemini told you about routers and modems and time division, I’m not, and I’d rather say so than quietly use it.
The measured half is already a lot. Drops at the exact moment a call connects. Worse on cellular than on WhatsApp. Better on Wi-Fi. That’s a coexistence problem sitting right next to the radio, and it’s a dimension nobody in this thread has touched, me included.
One question, and it’s the one your last line opens up. After the QPR2 fix, when the left one goes now, is it still during calls? Or has it spread out to any time at all?
Because if it’s still calls, that’s the same fault getting smaller. If it’s any time, that’s something else entirely and I’d want to start again.
Fair enough, and I don’t know is a useful answer. That row stays empty rather than getting a guess in it.
But you’ve handed me something I didn’t ask for and it’s worth more than the thing I did ask for.
Late 2024. Yesterday somebody in this thread showed me the same phone and the same aids behaving completely differently on two Android builds, stable on one and dropping constantly on the next. If a software version can do that, then when a test was run matters as much as what was in it.
And I have never once asked anybody in here for a date.
So my table has this morning’s walks sitting next to a comparison from nearly two years ago, and in late 2024 was a much younger thing than it is now. Yours may be perfectly good. I just can’t tell any more whether it’s describing the same world as the rest of the rows.
That’s the sixth variable I failed to control this week. Streaming or not, indoors or out, which ear, which protocol, which OS build, and now when. Every single one of them was handed to me by somebody else. Not one did I think of first.
So from here dates are compulsory, and the rows I already have get marked date unknown rather than quietly treated as contemporary.
If anybody has retested a classic against LE Audio recently, on current firmware, I’d take that over anything I’ve collected so far.
For what it’s worth, Unitron Moxi V and Galaxy s22 is solid indoors and out regardless of pocket (classic bluetooth), Android 16. I recall it being more subject to opposite-side drop-outs with my galaxy s20, but that may also have been an earlier model of either the Moxi or the Audeo. Signia and Widex drop-outs outside are frequent to the point that I find them too annoying to use, but with the s22 that’s still going to be . I’d have to test them out again so see which side is the problem, but I’d thought it was opposite side.
Roger On drops out if it is sufficiently body-blocked, probably not relevant to you.
Was the Phonak actually streaming audio during those twenty five metres? Or was it the myPhonak app link again, sitting there with nothing on it?
That was one of very few situations when I deliberately tested ranger of podcast streaming using Bluetooth Classic only to my Phonak Audeo Infinio Sphere 90. I didn’t wear sound processor then. That was in April 2025 before Ultra firmware upgrade. Ultra firmware upgrade may change/improve thatba bit.
Two hours ago I said dates were compulsory from now on. Both of you turned up with one without being asked. That’s the fastest a thread has ever fixed me.
Bimodal_user, that closes the row. Podcast streaming, Classic only, processor not worn, twenty five metres through a load bearing wall, April 2025, before the Ultra firmware. I can finally write it down, and I’m writing the firmware caveat down with it because you offered it and I wouldn’t have known to ask.
Neville, yours is the second Classic point and it points the same way. Moxi V on a Galaxy S22, Android 16, solid in and out regardless of pocket.
So the Classic row now reads two steady against one glitchy, and the glitchy one is d_Wooluf’s from late 2024 with no idea what was playing. Oldest and thinnest. I’m not throwing it out, but I know where it sits now.
Your S20 memory I’m taking as a memory, not a datum, because you said yourself the aids may have changed too. Same for which side. You wrote I’d have to test again, so that’s what goes in the notes.
The Signia and Widex line is the part I’d underline though. Frequent enough outdoors that you stopped using them. That’s the second person in two days who told me they gave up rather than that they complained, and giving up doesn’t show in anybody’s return figures.
Roger On dropping when it’s properly body blocked is relevant, by the way. It’s a body between a transmitter and an ear, which is the whole argument. It just isn’t in a pocket.
this allows you to look at all Bluetooth connections or restrict to Classic or - and even just a individual device such as your hearing aids. If you put it in your pocket it can record a graph over time of the strength (RSSI) of the signal as you move around or put parts of your body in the way….
I mean, for what it’s worth we also have dozens of patients in sonova products with classic Bluetooth and no dropout or sound quality complaints these days. The issues we see are actually disconnection or reconnection problems rather than drop outs. That is, no one is losing things mid stream. People come in because the pairing gets lost somehow and they don’t know how to get it back and we have to disconnect and reconnect to the app for them, or we have one guy whose phone just constantly turns off his Bluetooth either altogether or just for phone calls (keeps it on for media?).
* Post-Android 17 QPR3 Improvements: Every new beta build after Android 17 QPR3 has shown progress. Although the left hearing aid still occasionally disconnects, it is no longer triggered by phone calls. However, Bluetooth connection stability on Android 17 Beta remains inferior to official Android 16, where checking the phone menu at any time showed both ears consistently connected.
* QPR1–QPR2 Severity: The issue was most severe in a few beta releases between Android 17 QPR1 and QPR2 (around May to June). It was severe enough that the Oticon Companion app repeatedly threw warnings about continuous disconnections, asking to check the hearing aids, mobile phone, etc.
* Media Streaming vs. Calls: Across all Android 17 beta versions, media streaming and YouTube worked without issues. While WhatsApp calls experienced occasional Bluetooth LE Audio disconnections in one or two beta builds, it was not severe. Calls placed over Wi-Fi also did not disconnect.
* Cellular Call Disconnection: The primary issue occurred without Wi-Fi: the moment a call connected, the connection dropped immediately. At its worst, it disconnected 100% of the time within 2 seconds of answering.
* Troubleshooting Attempts: Previous troubleshooting suggestions did not solve the issue. Changing Bluetooth audio settings in Developer Options (e.g., A2DP settings, disabling mode, LE Audio permission list, A2DP offload, LE Audio hardware offload) had no effect. Forcing 4G instead of 5G or disabling VoLTE also made no difference.
* Temporary Workarounds: The two temporary workarounds previously suggested were using (T-coil) or switching to . ASHA reduced the disconnection probability to around 30–40%, but frequently resulted in audio broadcasting to only one ear.
Current Observations Regarding Left Hearing Aid Disconnections:
As for why the left hearing aid still occasionally disconnects now (unrelated to phone calls), here are a few potentially relevant factors (without drawing definitive conclusions):
* Battery Consumption: Current battery consumption on the left hearing aid is noticeably higher than the right, especially during continuous streaming.
* Hand Position Switch: I used to hold the phone in my left hand (typically hand-held, never in pants or back pockets) to check work messages on WhatsApp. Due to persistent muscle soreness in my left shoulder blade from heavy workload in June, I switched to holding the phone with my right hand.
* Historical Baseline: On Android 16, disconnections were rare, so I did not track whether holding the phone in my left hand had any correlation with left or right ear disconnections.
* Radio Module Hypothesis: I personally suspect this bug is caused by the radio module, although the following explanation was previously provided:
> * Disconnection Trigger Point is “Bluetooth Profile Switching,” Not the App: When playing music or watching videos, Bluetooth uses LE Audio CIS Unicast Sink (a one-way audio channel). When answering or making a call, the system’s low-level Bluetooth Stack must force a protocol switch to Telecom Profile (BAP - Basic Audio Profile two-way call mode) to enable both microphone input and audio output simultaneously.
> * All Calling Apps Invoke the Same Low-Level System Component: Whether using Google’s native Phone app or WhatsApp, any voice call must ultimately request the same Bluetooth hardware controller via Android’s AudioManager and BluetoothHeadsetClient (or the new LE Telecom API).
> * Core Bug (Known AOSP Bug): The primary issue in Android 17 QPR1 Beta 6 stems from bt_stack (the core Bluetooth protocol stack). During the transition from “one-way listening to two-way BAP call mode,” its state machine triggers an ASYNCHRONOUS_DISCONNECT error. The System on Chip (SoC) times out while renegotiating bandwidth, causing a kernel/stack-level crash.
>
And here is reddit link for LE audio (hearing aid) on Android 17:
That answers the question I left open, and it answers it against my own table.
You say the left aid still drops but calls no longer trigger it. So the call-connect spike was software, and the QPR3 builds took it out. I’ll close that row. What’s left is a left ear dropping more than the right for some other reason, and that’s the part I had wrong in public.
The sharpest thing in your post is the hand switch. You held the phone in your left hand until June, then moved to the right because of the shoulder. The left aid still drops more. A same-side effect should have flipped when your hand flipped. It didn’t. So I’ve been treating your case as a direction data point and it isn’t one. I’m pulling it.
Your battery line points the same way. You say the left draws noticeably more than the right during continuous streaming. In my experience an aid burning more power on the same audio is either working harder to hold the link or carrying the relay. Either way that’s the unit, not your pocket. It also gives you a cheap test. Quiet day, no streaming. If the left is still flatter by evening, it’s the unit. If the gap only appears while streaming, it’s the link.
I’m taking your measurements and leaving the low level explanation alone. You quoted it rather than claiming it, and you flagged your own radio module hunch as a hunch. That’s cleaner than I asked for. I still can’t put anything in my table that nobody here measured.
When went to one side only, was that also mostly the left. And on Android 16, was there any left right imbalance at all, or was it clean. I’m asking because both answers change which row this belongs in.
Hooby, yes. That app is the right shape. RSSI over time with the phone in a pocket is the only thing anyone has offered me that shows the moment rather than the aftermath. It won’t name the protocol. But I no longer think the protocol was the right thing to ask for.
That splits the failure into two, and I’ve only been counting one of them.
Everything in my table is mid-stream. Walking, music playing, one ear goes. What you’re describing is a session that never comes back on its own, and someone sitting in your chair because they can’t get it back themselves. Different failure. Different cost. Yours is the one that costs a clinic appointment.
I don’t have a denominator like yours. My whole table is people who came to a thread about dropouts, so of course they dropped out. You’ve got dozens of Sonova patients on Classic and no mid-stream complaints at all, and that’s the first number in this thread that isn’t selected by the question I asked. If mid-stream loss barely presents at clinic scale, then the thing I’ve spent two weeks measuring may be real and rare at the same time.
Someone on the Reddit side of this said something adjacent yesterday. He ranked the protocols and the part I kept was that they differ in how easily a link heals after it drops, not just in how often it drops. You’re saying the healing failure is what walks through your door. Two people who don’t know each other. Same axis. I never measured it.
So I’d rather ask you the clinic question than the physics one. Of the ones who come in with lost pairing, is it concentrated in any particular brand or phone, or does it look flat across whatever walks in. Flat means it’s the pairing model itself. Concentrated means somebody’s implementation, and that one I could act on.
Thanks. That’s the hardware line filled in. I still need the result.
I want to know whether it drops at all, and if nothing happens on a normal walk I want that too. Which pocket. Which ear went first, if one did.
Two more if you have them. Was audio actually streaming, because the link sits idle otherwise and a quiet walk tells me nothing. Indoors or outdoors, since one person here is stable at 18 metres inside and drops at 30 outside.
Your firmware line is worth more than you’d think. Ray6 here runs the same OS generation and watched the behaviour change across builds on hardware he never touched, so I’ve started logging build numbers on every row. Yours is my only Soundgear Amp.
No dropouts is a real answer. I’d log it the same as a failure.
this allows you to look at all Bluetooth connections or restrict to BT Classic or BLE - and even just a individual device such as your hearing aids. If you put it in your pocket it can record a graph over time of the strength (RSSI) of the signal as you move around or put parts of your body in the way….
Wow, great Polish app, I didn’t know about it, thanks! I’ll be experimenting with my connection with Nucleus 8.
Poland
South Carolina