NEW Brymen Bluetooth BM787BT Multimeter

[joeqsmith]

 

This is why I asked you to provided EXACTLY what you wanted from the start not several posts into the discussion.   If you can use the format and data I have provided in the attached example, I will collect more data for you.

[bdunham7]

I logged data for an hour and half using a 1k resistor and only got 2 data dropouts with the phone half way across the lab sitting on top of my computer.

Why does it go to 10.000 when the "dropout" happens?

[EEVblog]

I logged data for an hour and half using a 1k resistor and only got 2 data dropouts with the phone half way across the lab sitting on top of my computer.

Why does it go to 10.000 when the "dropout" happens?

I have no idea, I didn't expect that. Could be a quirk in the app when it gets a dropped packet?
Both samples are 9.9996k actually. Well outside the 60,000 count range of the ADC. I don't think it can autorange for one sample and then autorange back the next sample, so it has to be a quick in the app/received bluetooth data

[EEVblog]

2nd test for 1 hour, phone less than 10cm away from the meter. I received and made a call around the 55min mark.
Not a single digit change, all values are 1.0000k
The last sample drop is just an empty cell

[EEVblog]

Another test , this time across the lab as far as I could go, about 9 meters.
4 "dropouts" of again 9.9996k
And again, within one count on every other 1k sample.
So seems to be distance related dropout of some description, as you'd expect, but they need to handle the data better by logging NULL or something instead of a false reading.

[floobydust]

I'm thinking there are three firmware loads in this multimeter?
The DMM MCU, the Bluetooth module base (libraries), the Bluetooth module app. The module base F/W I think is old and hopefully stable but it might have fallen in the cracks with Infineon's acquisition of Cypress. Developers get sacked and an ecosystem just sits there orphaned.

edit: as far as black box testing goes, I suggest trying some things such as a different function or sample rate or noisy BT environment etc. to flush out what is happening.

[EEVblog]

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

[joeqsmith]

Just heard I'm getting my first batch early June.

Have you heard if they are going to push this date out?   If the 10X problem is with the radio's firmware, I wonder how distributors will handle the upgrades.  I have to believe they will have these basic problems solved ahead of time. 

[EEVblog]

Just heard I'm getting my first batch early June.

Have you heard if they are going to push this date out?   If the 10X problem is with the radio's firmware, I wonder how distributors will handle the upgrades.  I have to believe they will have these basic problems solved ahead of time.

I haven't heard yet.
It's common for Brymen to delay a release though, so it wouldn't surprise me.

[joeqsmith]

I haven't heard yet.
It's common for Brymen to delay a release though, so it wouldn't surprise me.

Looks like their radio had the programming connector attached.  I ordered the programmer for it and have asked it Brymen will provide details and programming files for it.  There may be a way around having to use the phone to upgrade the radio. 

[EEVblog]

I haven't heard yet.
It's common for Brymen to delay a release though, so it wouldn't surprise me.

Looks like their radio had the programming connector attached.  I ordered the programmer for it and have asked it Brymen will provide details and programming files for it.  There may be a way around having to use the phone to upgrade the radio.

I'm sure there is. But that's not a solution for users. Just like upgrading the meter firmware is possible but not an option for users.

[joeqsmith]

Looks like their radio had the programming connector attached.  I ordered the programmer for it and have asked it Brymen will provide details and programming files for it.  There may be a way around having to use the phone to upgrade the radio.

I'm sure there is. But that's not a solution for users. Just like upgrading the meter firmware is possible but not an option for users.

Sorry, you lost me.  The goal is to replicate the 10X glitch you are seeing, and understand why my phone will not connect with the meter.  While they are working on these problems, I am attempting to get a parallel path going. 

[joeqsmith]

The more I read about the radio they chose, the more I would lean towards including details about programming it in their manual.  They are using a bootloader with fallback.  Chances of bricking it should be slim. 

[EEVblog]

Sorry, you lost me.  The goal is to replicate the 10X glitch you are seeing, and understand why my phone will not connect with the meter.  While they are working on these problems, I am attempting to get a parallel path going.

oh, ok, my mistake.

[joeqsmith]

No problem.   I started a new thread on the eval boards for their radio.   

https://www.eevblog.com/forum/projects/cypress-psoc-creator-miniprog3-ez-ble

I have been doing a lot of reading about how the programming works and started to write my own.  I've made some progress but so far, that has been a bust. 

They are setting me up with a Beta for the iPhone which I hope to have working next week.  With any luck, this will allow me to update the radio's firmware.   They should also have that BLU phone like mine to start testing with.   Lots of irons in the fire..

[joeqsmith]

I was able to get the iPhone application setup.   It connects to the meter as fast as my custom Windows application.    When attempting to update the meter's radio, I get the same "Not Network".   I tried to then manually select the firmware file.  They never prompt for a filename, and I once again see some Chinese text displayed.  Apparently they have tested several versions of the iPhone and my wife's happens to be problematic list.  For now, we just have to wait.   

The meter, and even the radio as far as I can tell, have been working perfect since arriving. 

[EEVblog]

Brymen response on the data dropout issue:

Our R&Ds told the phenomenon which you found below to our APP designed subcontractor and were advised that the APP version 1.0.59 does not check CRC checksum for BLE Device Reading Packet. Our R&Ds thought it might be the reason why APP did not filter out those four wrong readings. Our APP designed subcontractor has modified the APP to check CRC checksum for every BLE Device Reading Packet. Please kindly download the update APP version 1.0.60 to install

[joeqsmith]

They mentioned that earlier.  Because I have been unable to reproduce the 10X problem you saw, I would have no way to test anything they came up with.   

A few thoughts about it.  They use a large enough MTU that the entire payload fits into one packet.  Bluetooth has built in error handling, so I couldn't see how this was going to be a problem.  Let's say it is the cause.  The first step to talk to the meter is send the password command.  When I first attempted to talk with the meter, they had not yet provided details about the CRC.  Guessing at the format proved a waste of time as the meter uses that CRC.  In other words, the group responsible for the software would have had the CRC coded and working for anything else to work.  So why they wouldn't check the CRC, length, header and footer as a minimum seems a bit odd? 

My question, which YOU are the ONLY one who can answer (as Brymen has also been unable to replicate), does this new version correct the 10X problem? 

[floobydust]

They still don't say what it does with a bad CRC, now that it notices this.

[joeqsmith]

With my app, I keep a metric but bundle CRC with all the others.  If I ever did detect a fault,  I still process the data.   I would expect my software to be every bit as bad as theirs in that regard.  With all of my testing, I don't believe it has ever detected a fault which makes sense.   

https://www.bluetooth.com/wp-content/uploads/2019/03/Bluetooth_5-FINAL.pdf

Dave needs to test it and report back.     

[floobydust]

I find it weird the exponent gets consistently corrupted to x10 for Dave, despite any random bunch of bits that could have gotten scrambled in the packet. That points to it being a side-effect bug, where a variable next door is wrongly being overwritten or maybe it's that [24] or [27] digit thing getting trashed.

[joeqsmith]

I find it somewhat weird that I was not able to replicate the problem, using the same DMM firmware and Android application.  It makes no sense that the radio's firmware would be the cause but it is certainly a difference.  As is the phone make/model.  When Brymen told me that they were also unable to replicate it, that's the real head scratch er.  Still, I doubt they have Dave's exact same phone.   

I was hoping Dave knew Wireshark and could just sniff the packets.  At least it would have answered if the problem with with the meter or the phone.  Engineering 101, cut the problem in half.   

My plan is to stay with the old application until I am able to update the radio.  I will then try once again to replicate the problem. 

[EEVblog]

I was hoping Dave knew Wireshark and could just sniff the packets.  At least it would have answered if the problem with with the meter or the phone.  Engineering 101, cut the problem in half.   

How does WireShark, which is network sniffing program for Windows, help debug a 1-in-1000 data corruption issue on an Android phone?

[joeqsmith]

How does WireShark, which is network sniffing program for Windows, help debug a 1-in-1000 data corruption issue on an Android phone?

BlueTooth is a network.  Wireshark will collect the data, filter, save, etc.   You can target the meter, ignoring all other traffic.   Brymen already provided you with the protocol.  So it's just a mater of looking through the data to see if the meter is sending the bad data.  If not, we know it is something with the phone or Android application.    You know what you are looking for and can use their spec to determine the packet that would create that fault.  From there, just do a search. 

It's most likely caused by the meter or the phone, not both.  You should be able to answer that pretty easy.

https://www.wireshark.org/docs/wsug_html_chunked/ChWorkFindPacketSection.html

Of course, if you repeat your tests using the new application and it does not fail, then maybe repeat running to original version again,  and you find it does correct it, we have our answer.

[EEVblog]

Running the new 1.6 firmware for 1.5hours I didn't get a single dropout. Phone across the other side of the lab as before.