NEW Brymen Bluetooth BM787BT Multimeter

[joeqsmith]

Looks like this one may work.   Towards the end of their write up, they are sniffing some packets that are much larger than the Brymen meter uses.   

https://dojofive.com/blog/using-the-nordic-nrf-sniffer-for-ble/

[joeqsmith]

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.   

It looks like one problem was I had installed the latest Python 3.13.5 and the NORDIC scripts was written for 3.11.x.   Installing Python 3.11.9 did allow me to use the script as-is.   I also upgraded to wireshark 4.4.8 and WinPcap 4.4.3.   Running WS, as before, I see the Brymen advertising but as soon as I connect to the meter using the PC, no further packets are captured.   

I tried connecting with a cell phone and WS continues to capture packets.  It appears that with NORDIC's latter sniffer, there is some sort of conflict when using the same PC to sniff traffic and interface with the meter.    Their original software did not work like this. Rather than having to install Python, the provided an EXE ("ble-sniffer_win"). Maybe it did not use the MS stack and that is why the two programs don't interfere with one another. 

With the changes, I still see the same problem where it doesn't seem to handle the large MTU sizes.   I had been using a Targus BU4086 which they claim is BLE 4.0.  Most of the on-line documents claim 4.0 did not support the larger MTU size needed.   It would require 4.2.  I see no difference using a 5.0 and that 4.0 radio with my software.   That Adafruit was also 4.0.    Not knowing anything about BLE, maybe it was the wild west.     

I have ordered the NORDIC nRF52840.  Part of the reason for wanting to sniff the traffic is to try and understand how Brymen's OTA programmer works.   This information  was not included in their interface document. 

[Kean]

Yes, BLE 4.0 had a limited MTU but was not "enforced" so some implementations did allow longer.  BLE 4.2 added the data length negotiation to increase MTU.

I'm no BLE expert, but I have done some implementation work and researched it a bit.  Was using mesh, but have now moved to another mesh protocol.

And yes, sometimes installing the latest release of Python will bite you.  Been there before - a few times!

[joeqsmith]

That sure seems like the case  (not enforced).   I did go through all of that documentation and followed all of the instructions to setup the new software.  I did not run into any problems and it seems to all work as expected.  I just need the hardware now. 

I really don't understand why there is a interference problem when running the other setup.  It makes me want to try some other tests using speakers, other meters and such.  It's hard to believe that especially having two different dongles, that the OS would have any problems.   

Talking with Brymen about reverse engineering the OTA programming, they have provided me with some clues.   It doesn't sound like they would be apposed to adding these details to their document but as it stands, that work was all contracted out.  If you download their application, you can now see who the developers are.  Basically any communications I have with the developers is through Brymen.  I think it would be easier to just sniff the traffic to answer some of the questions I have.   

I released that first video on Mar 25, 2025, so today marks 4 months.   Hopefully they are able to address my other concerns in short order.   

***
There are several videos showing the NORDIC nRF52840 being used as a sniffer.   This one demonstrates larger packet sizes.   Confidence is going up...
https://youtu.be/HeG3ARRm05I?t=776

[joeqsmith]

Brymen said they will remove the units from the CSV value column 

Looking at their latest, it seems there are a few where it is not consistent.  I have passed these onto Brymen.   Should be a minor change. 

[EEVblog]

Looking at their latest, it seems there are a few where it is not consistent.  I have passed these onto Brymen.   Should be a minor change.

Wow, that's odd, I wonder how that happens?

[joeqsmith]

Looking at their latest, it seems there are a few where it is not consistent.  I have passed these onto Brymen.   Should be a minor change.

Wow, that's odd, I wonder how that happens?

My guess is they are focused on the bigger problems right now and may not have a way to automatically run regression tests.  It would be easy to check but you may have noticed that when you change the meter's settings while logging data, the application stops collecting and asks if you want to save the data.  So you have to create a file for each mode and run through the ranges.   

If you are asking about how their code is structured that you could change the formatting for some but not all, that's a good question. 

With the older WireShark/Adafruit sniffer at least being able to capture the empty packets,  I thought I would try and see what is going on when the PC is unable to recover after the meter disconnects.   Part of the problem with the old NORDIC ble-sniffer software, it can't locate the meter after it has started logging.  You can start their software, select the meter then start the logging and then stop Wireshark.  Then you can start it back up some time later.   The problem is, the NORDIC software is not robust enough to allow me to capture after a day or so.   The Brymen meter is turning out to be more reliable.  The new NORDIC radio should arrive in a few days.

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
7)Cell phone data file format (units after value) is inconsistent in different functions/ranges

*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 the mean of the 1k test resistance.  Plot showing the drift over a 2 hour period.  The modified/poor man aligned BM786 (BT) drifts about 0.03 ohms.   That's just sitting on the desk (ceiling fan causing all sort of air currents).  Time to pull out the meat packing box and see if we can tighten it up a bit.   

https://www.eevblog.com/forum/testgear/hear-kitty-kitty-kitty-nope-not-that-kind-of-cat/msg1371562/#msg1371562

[joeqsmith]

Looking at the mean 2 hours after the chamber was allowed to stabilize at 21C.  About 0.002 ohms of drift.   

[joeqsmith]

The NORDIC radio arrived.   Easy enough to program in the firmware and set it up with WireShark.  Sniffing traffic at work, I am seeing packets in excess of 200 Bytes, so looks like the MTU problem is solved. 

***
Shown BM786 sending a reading to the cellphone.      For $10 USD, I think we have a winner.

[geralds]

If of interest (and not sure whether this has been posted before), I just noticed that the BM788BT is now shown on Brymen's website:

http://www.brymen.com/PD02BM780_788BT.html

[joeqsmith]

Brymen's latest is version 1.0.66.  The last version I tested was 1.0.64.   They do not have a change log, and I have not heard anything from Brymen as far as what was changed or why.   I can't see any reason to run these long tests on each release they have without knowing that they have at least attempted to address some of the more major problems.

I have spent a few days trying to understand more about the undocumented commands.   I used that NORDIC sniffer and Wireshark to record from the time the meter was turned on, to the phone connecting, logging data, then programming the FLASH and back to logging.   The sniffer worked very well for this and they made it fairly simple to setup filters in Wireshark to sift through the 10s of thousands of packets.   I now have the checksum for the OTA commands working and have some idea how the the programmer works.   

There are two problems that I ran into.  The first is with Windows.  Brymen uses a connection interval of 100ms and a supervision timeout of 6000ms (from their document).  BLE 101,  if there is no data to be transferred, empty packet are sent.  If there is no data received for 5 seconds, the meter will close the connection and start to advertise.   

The problem is with windows/labview, if I close the connection, the OS keeps the port open by continuing to send empty packets.   The only way to close the connection is to exit the application, or it's possible to use pnputil.   The problem with that is Microsoft did not see fit to allow the full command set for all versions of Windows 10.   

PNPUTIL [/add-driver <...> | /delete-driver <...> |
         /export-driver <...> | /enum-drivers |
         /enum-devices [<...>] | /enum-interfaces [<...>] | /?]


Why do I care?  One of the modes where the DMM hangs is that it stops sending notifications.  It's really a bug with the meter, but Windows could recover if I could reset the driver or get it to stop sending empty packets keeping the connection open.  Using Device Manager to reset the driver does indeed recover the communications without resetting the DMM's BLE or Labview. 

I have started to experiment with some of the undocumented commands.  The DMM can get into a state where I flat out can't recover the meter without power cycling the radio (turning BLE off and on).  While it is in this mode, it will advertise and I can connect, but the meter will not respond to any of the high level commands.   This is after dropping to the boot loader and trying to exit back to the application.   In this mode, even with no data being sent to it, it will not recover after the 6second timeout.     Their cell phone application behaves the same, locating the meter but unable to connect to it. 


***
Removed all programming notes as to not waste anyone's time chasing bad info

[joeqsmith]

Brymen's latest is version 1.0.66.  The last version I tested was 1.0.64.   They do not have a change log, and I have not heard anything from Brymen as far as what was changed or why.   I can't see any reason to run these long tests on each release they have without knowing that they have at least attempted to address some of the more major problems.

I tried the latest software on two different cell phones with both meters.   The UNNECTO stopped logging after 12-20 hours and was prompting to save the data.  I selected save and got the spinning icon.  I left the phone in this state for about 20 hours and it never changed.  It required the application be closed.  All data was lost.   

I manually stopped the Motorola Trac phone after about 30 hours of logging to avoid any problems.   I selected save the data and get the same spinning icon for a few minutes then it prompted for a file name (all normal).   I selected the default file and again get the spinning icon.  It has been in this state for about an hour.   Again, all data was lost. 

Both of these failures, while a little different fall under #6 below.  What ever the developers changed, it did not appear to address this major problem.


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
7)Cell phone data file format (units after value) is inconsistent in different functions/ranges

*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]

A few small updates.  It turns out that the Windows "pnputil" was updated on the Pro version on Win 10.  I have since upgraded my PC and have added support for to my software to call this command to reset the BLE driver.  It works like a charm.

I also discovered that the reason the NORDIC sniffer / Wireshark would not log any date when using the same PC to talk with the meter, it seems Wireshark's device must be set to the Brymen first.  Doing so, I was able to record large sessions with the PC as well as the cell phones.   

I finished up adding the OTA firmware programming to my software.  It just doesn't work.      Comparing Wireshark between the cell phone and PC,  it all looks right, but I am obviously missing something. 

[joeqsmith]

I captured a few more data sets with WireShark using the cell phone and the PC.  I have compared the packets and everything matches, at least when looking at the application and boot loader commands and their responses.   I thought time between packets may have been used as another layer of protection, that or the number of notifications between commands, but coding in similar check yielded nothing.  Basically, what happens is all BLE packets appear correct up to the point where I drop to the boot loader and attempt to program the very first locations of memory.  Then the meter appears to return an error code. 

The email address provided in the software download area is not actually for the people developing the software but for Brymen.  I have asked Brymen if they would consider putting me in direct contact with the developers to work through these last few problems and help clear up some of the undocumented commands.   

Even if we are able to sort out the programming, if you run their software and try to update the FLASH, it will prompt you for a local or auto download file.  So far, I have not seen the download from the internet work.  Brymen has had to supply the updates to me directly.   In the future I suspect everything will be over the internet, which will mean sorting out where those files are stored and how to retrieve them.   

Because of #2, Phone drops connection at random, and I have seen with the PC where the meter gets into a state where it no longer sends notifications,  I suspect there will continue to be updates to the firmware, at least in the short term.   

[joeqsmith]

I have removed all of my programming notes as to not waste anyone's time chasing bad info.  This morning, I was able to successfully program the meter using my software for the very first time.  At this point, I would have settled for bricking the meter. 

Shown using Motorola cell to verify the version after reprogramming from 1.0.1.  Of course, I still do not know what the undocumented commands do.  With Brymen's approval, I would like to include these details in the open source documentation. 

Also shown is the BM786 prototype with added BLE radio.  The O-ring is holding the meter together (no screws) to gain access to the programming connector.  The hot glued battery pack is also shown.

If you need to work with BLE, that $10 NORDIC nRF52840 radio was well worth it. 

[joeqsmith]

I received the following response from Brymen: 

Glad to hear that your software was able to re-flash meter's BLE successfully. If you would like to open the source and to update our document to include this information, please kindly go ahead. We thought it would be able to benefit some users and we really appreciate that.

This is very good news for those interested in writing their own custom applications.  There are a few details I am trying to resolve with Brymen, including how the firmware will be distributed and descriptions for the extended commands used during programming.

[joeqsmith]

From Brymen's testing, the cell phone application's automatic firmware update works.  They asked how my cell phones behave so I made a video showing all three phones attempting to program a meter.  I also demonstrate my custom software programming the meter's BLE to the latest revision.  It's a lot faster.  Seconds vs minutes.   
 

[EEVblog]

Remote update doesn't work on mine.
Auto download shows network error like yours, and the manual select file displa ythe same as yours and appears to download a chinese character file like your but the file does not show up to select it.
Same version 1.0.66

[joeqsmith]

Remote update doesn't work on mine.
Auto download shows network error like yours, and the manual select file displa ythe same as yours and appears to download a chinese character file like your but the file does not show up to select it.
Same version 1.0.66

Good to know.  I have passed this onto them.  They are working on it.   

Brymen would need to provide you with the programming file.  Copy is to the phone's download area.   I tether my test phones to the PC and copy them over.   

!!!!WARNING!!!!!
YOU COULD POTENTIALLY BRICK THE METER!!!!  Early on in my testing, Brymen provided a version that required the hardware programmer.  Later, I  tried to use the phone application to upgrade from a very old version to a much more recent and it bricked the meter's radio.  The company doing this work may have changed something in the firmware/application that made these not compatible.  With your meter having very old firmware, I suspect you may have a problem if you attempt to load the latest release (1.0.3).  I assume now that the meter is for sale to the public, the design is stable and there is no concern. 

Maybe consider testing with the released meter once they arrive. 

[joeqsmith]

I sent Brymen my first draft of my notes on how to program the FLASH over-the-air. 

I saw where they have a new protocol interface document available on their website.   Hopefully in the future, it will include my notes.

[joeqsmith]

Brymen has reviewed my OTA document and will append it to their document in the future.  Hopefully it provides enough details that someone could write their own custom application from scratch. 

[joeqsmith]

Dave,  I understand they are going to release a new application soon that will address the remaining problems. It would be good if you test it as well.  Were you able to update your meter's firmware? 

[EEVblog]

Dave,  I understand they are going to release a new application soon that will address the remaining problems. It would be good if you test it as well.  Were you able to update your meter's firmware?

Just got the email about the new app, haven't tried yet, probably can't do it this weekend.
Wasn't able to get the BT module firmware update working.

[joeqsmith]

Unofficial BM78x BLE OTA programming procedure

1) Download and install latest 1.0.66 application using the link they provide from their main page
2) Copy BM78xBT_1_0_3.cyacd into the cell phone's download directory (file supplied by mfg)
3) Turn on meter and enable the BLE
4) Start application
5) If you wait long enough, the app should start scanning for advertisements from the meter, and locate it
5a) You may need to press the + key or toggle the BLE on/off
6) Once app detects the meter, just press on the meter that it is showing RSSI
7) Enter the password for the meter (0000)
App will link with meter and should list the meter with MAC and check mark next to it
9) Select the About key
10) Select Version Information
11) Select BM78xBT (down arrow)
12) App will prompt BLE firmware OTA?  Select Update
13) Select File
14) Wait for screen change, Chinese characters, spinning icon.  Eventually app will prompt Update OTA Select File (You do not need to select the Reconnect key)
15) At this point, you have never used the app so no files will be listed.  Press the paperclip key
16) App will prompt with Downloads.  Select the cyacd you copied into that directory
17) App will include selected file in the list.  Go ahead and select it by selecting circle to left of file name. Should turn red.
18) Select Update
19) App will prompt with Preparing to start the update ......
20) Now comes the VERY long wait.  Very long.  Maybe you think the app is hung... Keep waiting. 
20a)  I have seen the application hang here as well as other times.  You know the drill, toggle BLE, restart app...   
21) Eventually the app will start the update and show the % completer.  Wait another 5-6 minutes, it should finish at 100%   
22) App will prompt The OTA firmware update via BLE has been successfully completed.  Please restart the device. 
22) Select OK
23) App will close (still running in background). 
24) Toggle the BLE off and on
25) Bring app back to foreground and allow it to reconnect to meter
26) Select the About, version, .... to verify that the meter reports the new BLE version

What happened when you tried the update?   Did you miss the paper clip?  I did.