NEW Brymen Bluetooth BM787BT Multimeter

[EEVblog]

No local saving on iPhones allowed.

After forwarding your problem below to R&Ds, I heard that iPhone does not allow our APP logging data to be saved locally. Since Apple enforces strict rules and limitations on how local data storage is handled, our APP logging data can be saved only to iCloud instead.     

[joeqsmith]

No local saving on iPhones allowed.

After forwarding your problem below to R&Ds, I heard that iPhone does not allow our APP logging data to be saved locally. Since Apple enforces strict rules and limitations on how local data storage is handled, our APP logging data can be saved only to iCloud instead.     

Doesn't the iPhone allow saving it to local? 

Yes it does, but the iCloud lets me easily access it from the lab.

   Did they change the application to remove that feature?   You had stated that is was the same code for both platforms.  Does this suggest that the Android will not save locally in the future?   

[joeqsmith]

While sitting here, one of the phones made some sort of chime noise.   I looked on the screens and saw nothing unusual.   Wi-Fi is off and they are both still at 100% charge.  What ever it did, it does not appear to be effecting the data collection.  I think this is day 4 of the second run.

After running all these tests with the cell phones, while the hardware seems stable, the OS and software does not seem very robust.   The idea that you would even need an internet connection to log data would be a major blow. 

[Rubo]

The idea that you would even need an internet connection to log data would be a major blow.

Welcome to 2025 

https://www.kohler.com/en/products/toilets/shop-toilets/numi-2-0-one-piece-elongated-smart-toilet-dual-flush-30754-pa?skuId=30754-PA-0

Never thought a toilet would need an app 

This is from 2020: https://med.stanford.edu/news/all-news/2020/04/smart-toilet-monitors-for-signs-of-disease.html

The toilet automatically sends data extracted from any sample to a secure, cloud-based system for safekeeping. In the future, Gambhir said, the system could be integrated into any health care provider's record-keeping system for quick and easy access.

   

[joeqsmith]

I checked on the test last night and one of the meters had turned off.   I am using the Eneloop AAAs.  They seem to allow about 4-days of operation.   I connected the Motorola Tracphone to the PC to pull down the data it's battery voltage was down to 32%.   It was at 100% when I checked it in the morning.   I am thinking that ding notifier had something to do with it.   This is how I lost the data last time with this same phone.   So, it's not the charger or cable.  Something else is going on with this particular phone that it will not run for extended times.   I tuned the backlight way down in hopes of improving it.  At least this time I caught it in time so we have the data.


The second meter was powered down when I checked today.  So it ran a little longer with the same batteries.  The Eveready Energizer Max that the meters were shipped with do much better.   I wonder if they would consider lowering the threshold for NiMH.   

The bigger problem is that Unnecto phone seems to be hung.  It also looks like the phone had tried to connect to the internet to update.  Maybe that was the ding notifier I heard.  It typically takes several minutes to prompt me for a file name, but it's shown the busy spinner for a little over an hour now.   With 4 days of data in jeopardy, I plan to leave it at least another hour in hopes that it completes. 

[robert.rozee]

my own (albeit limited) experience with bluetooth is that it is:
- fine for keyboards and mice, where the odd lost report doesn't matter too much,
- moderately ok for audio, although many devices seem to become flakey over time as they age; i have yet to encounter a sound bar where the bluetooth didn't fail eventually and need to be replaced with a wired connection,
- too unreliable for data connections where 100% integrity is paramount.

might Bryman been better off (1) sticking to IR transmission of data, and (2) designing a recessed tray that holds a micro SD card that slides deep into the meter for logging data - the tray would be long enough such that it did not compromise CAT ratings.

as an observer of this thread, while the bluetooth data logging and graphing is technically interesting, it seems to not be a feature that is suitable for use in any serious/professional environment.


cheers,
rob   :-)

[joeqsmith]

From my experience with these cell phones, I 100% agree with you.   I have done a fair amount of data logging over extended times using BLE with custom software running on a PC.  Even the new Brymen meter is very stable when used this way.   Even with the PC, I certainly would not use it for life support.   

We have talked about user accessible memory cards before and the problems with safety and sealing.   IR wise, now you are talking about adding a physical interface to the cell phone and much shorter distances.  Again, I can't see this happening.  Having ZERO knowledge of writing applications for any cell phone, I wonder if there is some reasons they chose to architect the software this way.  Anytime I log data, I first setup the file and then stream the data to it.  If power is lost,  the data up to that point is still saved.   

It's been another hour and the Brymen application is still hung.  I'll give it another hour but it looks like we lost 4 days of data again.   

1)Application's sample rate slows down while logging for extended periods
2)Phone drops connection at random (not battery, low signal or outside RF interference)
3)Unable to reconnect after a connection was made (requires restarting the application)
4)Recorded data is 10x higher than actual and outside of meters range *1
5)If phone powers off due to low battery, data is lost *2
6)Application hangs when trying to save data

*1 This last round of testing, using both meters for 4 days, the problem did not replicate with the latest updates from 7/11/25.

*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM.

****
I gave their application a full 3 hours to recover but no luck.  The app was non-responsive to the touch screen.   The only option was to force it to close.   So far I have lost about half of the data I had planned on collecting before providing Brymen any feedback.

[iMo]

So it is not about crappy BT per se, but the crappy app in the phone and/or meter. It needs a lot of finetuning to get it working reliably (it took 7 years with the app I mentioned above).

PS: a simplified version on his github for android developers - https://github.com/kai-morich/SimpleBluetoothTerminal

You may look at how is the format of the raw data your meter is transmitting like, and perhaps logging it as the text or hex via the terminal is the reliable way to go.

[joeqsmith]

So it is not about crappy BT per se, but the crappy app in the phone and/or meter. It needs a lot of finetuning to get it working reliably (it took 7 years with the app I mentioned above).

PS: a simplified version on his github for android developers - https://github.com/kai-morich/SimpleBluetoothTerminal

You may look at how is the format of the raw data your meter is transmitting like, and perhaps logging it as the text or hex via the terminal is the reliable way to go.

As I said, all of the meters (including the new Brymen) work fine when used with my own custom software.  Brymen has open sourced the protocol so anyone can view it.   

In this case, I think the problems are mostly with cell phone applications, not the Brymen hardware or firmware.   

[joeqsmith]

The phone disconnected with the meter still powered up (#2) after a few hours.  The odd thing is I count not get the phone to reconnect, even after restarting the application and power cycling the meter.   Basically it detects the meter advertising, starts the link process, then fails stating the meter is disconnected.   I tried 5 time to reconnect and always the same problem.   So I turned on the Ethernet connection and as soon as I did, the phone connects to the meter.       Maybe it was a coincident.  All the other testing was performed with the Ethernet disabled to avoid updates and other variables.   The was with the BLU G64.   I'll leave the Ethernet active and see if the connection will stay up.     


1)Application's sample rate slows down while logging for extended periods
2)Phone drops connection at random (not battery, low signal or outside RF interference)
3)Unable to reconnect after a connection was made (requires restarting the application)
4)Recorded data is 10x higher than actual and outside of meters range *1
5)If phone powers off due to low battery, data is lost *2
6)Application hangs when trying to save data

*1 This last round of testing, using both meters for 4 days, the problem did not replicate with the latest updates from 7/11/25.

*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM.

[EEVblog]

*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM.

NVM data wear. Continuously appending the file for every sample would be a bad idea.
But yes, it should do this by buffering, so pick a number like 1000 samples before appending. Worst case you lose 1000 samples.

[joeqsmith]

*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM.

NVM data wear. Continuously appending the file for every sample would be a bad idea.
But yes, it should do this by buffering, so pick a number like 1000 samples before appending. Worst case you lose 1000 samples.

My desktop PC is from 2016 and uses SSD.  I treat the drive no differently than any other.   All of my vintage TE which was Windows based was also converted to SSD and again, they get no special treatment.  In that case, the drives handle the wear leveling.   I am surprised a modern cell phone it's actually a concern.   Consider people toss them out after a few years anyway.       

I suspect keeping it all in RAM is also the cause of the slow down.  I wonder if the OS is swapping the RAM to NVRAM.  The following is from one test.  The first set is at the beginning, the second at the end.

2025-07-15,21:52:51.124,BM78xBT,#channel1,Resistance,0.9999,k,Ω
2025-07-15,21:52:51.329,BM78xBT,#channel1,Resistance,0.9999,k,Ω
2025-07-15,21:52:51.542,BM78xBT,#channel1,Resistance,0.9999,k,Ω
2025-07-15,21:52:51.741,BM78xBT,#channel1,Resistance,0.9999,k,Ω
2025-07-15,21:52:51.949,BM78xBT,#channel1,Resistance,0.9999,k,Ω


2025-07-17,19:00:27.640,BM78xBT,#channel1,Resistance,0.9998,k,Ω
2025-07-17,19:00:29.291,BM78xBT,#channel1,Resistance,0.9998,k,Ω
2025-07-17,19:00:31.149,BM78xBT,#channel1,Resistance,0.9998,k,Ω
2025-07-17,19:00:33.003,BM78xBT,#channel1,Resistance,0.9998,k,Ω
2025-07-17,19:00:34.860,BM78xBT,#channel1,Resistance,0.9997,k,Ω
2025-07-17,19:00:36.719,BM78xBT,#channel1,Resistance,0.9998,k,Ω

Consider that the early versions would only run on 1 of the 3 phones I have.  They have made some very big improvements in the last few months.  The loss of data and the fact it can't keep up IMO are the biggest problems they face. 

[iMo]

.. also, as a test, try to switch off the WIFI in your phone (as well as switch off WIFI in your router)..and do power the phone with the charger while logging (with old batteries there might be a voltage drop while TXing via the BT or wifi)..
If I were you I would try the android app I mentioned above (replay #199) - it should be no problem to log your ascii data with it (and we may help with setting it up).

[joeqsmith]

.. also, as a test, try to switch off the WIFI in your phone (as well as switch off WIFI in your router)..and do power the phone with the charger while logging (with old batteries there might be a voltage drop while TXing via the BT or wifi)..
If I were you I would try the android app I mentioned above (replay #199) - it should be no problem to log your ascii data with it (and we may help with setting it up).

I have posted a few times about turning off wifi and running the phones of a charger.  Readings not your strong point?   

As far as using some standard software to talk with the BM78xBT, Dave provided a link to their protocol specification.  It's not some simple ASCII data as you seem to think.  It may be possible to modify the software to support the Brymen. 

[joeqsmith]

The bigger problem is that Unnecto phone seems to be hung.  ...  shown the busy spinner for a little over an hour now.   ...

I thought I would be a little smarter and save the data before there was a problem.   Both meters/phones were collecting the data as normal.  I stopped the BLU/BM786 and saved with no problem.    When I did this with the BM788BT/Motorola,  it hung as I saw with the Unnecto last time.   It's been displaying the spinner for about an hour now.  I'll let it continue for the remainder of the day and just see if it ever shakes loose.  In the mean time, I restarted the test with the Unnecto phone.   Loosing 50% of my data is a real pisser.  I assumed it was related to these really long collections but this was only about a day and again, everything was normal at the time I stopped the collection.   


1)Application's sample rate slows down while logging for extended periods
2)Phone drops connection at random (not battery, low signal or outside RF interference)
3)Unable to reconnect after a connection was made (requires restarting the application)
4)Recorded data is 10x higher than actual and outside of meters range *1
5)If phone powers off due to low battery, data is lost *2
6)Application hangs when trying to save data

*1 This last round of testing, using both meters for 4 days, the problem did not replicate with the latest updates from 7/11/25.

*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM.

[joeqsmith]

Since receiving the last update from Brymen, I was able to collect about 100 hours of data using various combinations of the three cell phones and two meters.  While various problems caused me to loose about 40% of the data,  the 10x fault never happened.      Readers should be aware that that this fault was what they were attempting to address.   


1)Application's sample rate slows down while logging for extended periods
2)Phone drops connection at random (not battery, low signal or outside RF interference)
3)Unable to reconnect after a connection was made (requires restarting the application)
4)Recorded data is 10x higher than actual and outside of meters range *1
5)If phone powers off due to low battery, data is lost *2
6)Application hangs when trying to save data

*1 Fixed as of 7/11/25
*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM

[joeqsmith]

Looking at two of the data sets from the last round of testing with the latest updates.   Showing the start and end entries and how many samples were collected for the set. 

2025-07-15,08:51:55.369,BM78xBT,#channel1,Resistance,0.9999,k,Ω
2025-07-18,15:48:10.532,BM78xBT,#channel1,Resistance,0.9998,k,Ω
416,065

2025-07-21,00:49:12.378,BM78xBT,#channel1,Resistance,0.9999,k,Ω
2025-07-21,07:01:51.649,BM78xBT,#channel1,Resistance,0.9999,k,Ω
56,381

We can see that the longer it runs, the slower it gets.  The second set is for only 6hr 10mins.    370 mins @ 5Hz = 108,000 samples.  Basically, half the expected data was lost.   

The attached image is showing 11 hours of data collected with the PC.  The graph is plotting the time between messages received.  There was one sample that required 2 seconds, but for the most part it is at the expected 5Hz and there is no sign of it slowing down.   It's hard to believe that a cell phone would not have the hardware needed to keep up with it.   

[joeqsmith]

Added the ability to trend the time between samples from the cell phone logs.  Showing two different cell phones.   Guessing that the less RAM available, the meter will slow down much earlier in the log.   

I have been testing with my custom application and am finding that the it will also disconnect at random.  I suspect #2 may not be a problem with the cell phone.  The second plot is again showing the time between samples when logging with the PC.  After 16 hours, the connection dropped.  Notice how the sample rate remained consistent over the entire run.   There was one sample where it timed out at 10 seconds but recovered.   I thought that early delay may have been a clue as to way the connection dropped but repeating this test, I did not detect the same timeout prior to the drop.   

[joeqsmith]

Looking at all of the data sets collected with the latest updates,  there were two cases where something happened that caused a very long delay between samples.  One over 35 seconds, the other 22 seconds.  From the slope of the change in sample rate, this was from two different cell phones. In both cases, their application managed to recover.   Looking at the resistance measured, the long delays had no effect. 

Note you can see one setup has less noise than the other.  I am using two different meters and resistors.

[joeqsmith]

There were 11 files total that were captured.  Plotting the resistance for all of them, you can see they stay within 1.0002k - 0.9995k.  You may remember my mentioning opening the leads during one run.  This is the glitch shown in the data.   

[joeqsmith]

I heard back from Brymen who explained what was happening with the 10x fault.   I have never seen it since their latest updates and believe this has now been addressed.   Brymen has began working on the random dropped connection and loss of data.   I provided them with some details about what I am seeing with the PC.

[joeqsmith]

BLE experts.  From the following statements:

Once connected, advertising is no longer used for communication between connected devices. Instead, devices communicate with each other at a periodic interval known as the connection interval. At each connection interval, a connection event takes place in which the Central sends a packet and the Peripheral responds with a packet.

If there’s data to be sent by either side, they send it in the packet. If there’s no data, then an “empty packet” is sent. If there’s enough data to be sent by either side, multiple back-to-back packet exchanges may occur during a single connection event. These packet exchanges serve as a handshake to maintain the wireless connection even if no application data needs to be sent for extended durations.

I wonder when unacknowledged notifications are used, does the stack still send these empty packets to detect when the connection drops?

Typically, if I move the meter far enough away from the PC for the connection to fail,  the meter will begin to advertise.  It will also send out the low battery status.   I assume the meter knows the connection was dropped because of these empty packets being handled by the stack.   On the PC side, my software doesn't send any data to the meter once collection has started but that does not mean that something is not being done at the lower stack or hardware layers to detect a link failure.   

Basically what I see with the PC when it hangs,  the meter stops sending notifications but also fails to advertise.  What ever state they get into, the only way I can seem to clear it is by toggling the BLE off and on.  I suspect this is what is happening when I am using the cell phones and they hang (item #2).  One other potential clue besides the low battery status being sent, I don't think I have ever seen the meter get into this state in less than 5 hours.   Typically it happens after 10 hours or more of logging.  It could be random.  I have seen the cell phones drop connection within minutes of starting to log.  Again, maybe random.

I tried to use the Adafruit sniffer but was unable to get it to work with the large MTU sizes required by the Brymen meter.   If you are aware of how to get this to work, I would appreciate hearing from you.   

Quote above taken from:
https://punchthrough.com/manage-ble-connection/


1)Application's sample rate slows down while logging for extended periods
2)Phone drops connection at random (not battery, low signal or outside RF interference)
3)Unable to reconnect after a connection was made (requires restarting the application)
4)Recorded data is 10x higher than actual and outside of meters range *1
5)If phone powers off due to low battery, data is lost *2
6)Application hangs when trying to save data

*1 Fixed as of 7/11/25
*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM

[joeqsmith]

The following is from Google AI.  I assume this is done by the stack.


BLE using empty packets as a link detection
Using empty packets for link detection in Bluetooth Low Energy (BLE)
In a BLE connection, devices periodically exchange data. When there's no application data to send, devices transmit "empty packets" to ensure the connection remains active. These empty packets serve as a handshake, and if either device fails to receive a packet from the other within a defined "Supervision Timeout", the connection is deemed lost.
Mechanism of empty packets for link detection

    Periodic Transmission: In a BLE connection event, the master and slave devices are required to transmit a packet on each hopped channel. If no data is available to send, these packets become "empty data packets".
    Connection Events: A BLE connection is maintained through periodic connection events. Each event starts with the master sending a packet, and the slave responding.
    Keep-Alive Function: If there's no application data to be sent, the devices exchange mandatory empty packets to keep the connection alive.
    Supervision Timeout: Both the master and slave maintain a "Supervision Timer", which resets upon receiving a link-layer packet. If this timer reaches the configured "Supervision Timeout" (which can range from 100 milliseconds to 32 seconds), the device considers the connection lost and exits the connection state.

Why empty packets?

    Power Efficiency: BLE is designed for low power consumption. Transmitting minimal-sized empty packets (a 16-bit header and a 24-bit CRC) consumes less energy than larger data packets. This allows devices to quickly perform necessary tasks and then disconnect or enter low-power modes, optimizing battery life.
    Maintaining Connection: Even without active data exchange, the periodic transmission of empty packets ensures the devices remain synchronized and aware of each other's presence, preventing the connection from timing out due to inactivity.

In essence, empty packets in BLE act as a heartbeat, ensuring the integrity of the connection without incurring significant power overhead, a crucial aspect for BLE's low-energy design.
AI responses may include mistakes. Learn more

[EEVblog]

*2 I am not sure why they don't ask for the file name first, then stream it to NVRAM rather than keeping the data in RAM

That seems like an obvious change to make. Append CSV file every 100 samples or something.

[joeqsmith]

Back when I was working with the UNI-T UT181A and 121GW BLE meters, I was using Adafruit's sniffer with NORDIC radio.    It worked fine for that but with the new Brymen meter, it seems to have a problem with the large MTU size.   A have used both BLE 4.0 and 5.0 to communicate with the Brymen.   

I purchased Adafruit's latest sniffer and installed all the latest tools (wireshark, python ....).   The first thing I ran into was NORDIC phython script fails with syntax problems.  Many people have asked about this problem and others have posted how to address it.  Doesn't give me a lot of comfort.   I patched the script and everything seems to run as normal.  Wireshark displays the Advertise packets but as soon as I connect to the meter, it shows no other data.  I have all of the decoders active and no filters. 

When I revert back to the old Wireshark and NORDIC tools, Wireshark captures packets after the connection.  They are all just short.   

Having a sniffer would have been very helpful with this project but the low cost ones may not be up to the task.