NEW Brymen Bluetooth BM787BT Multimeter

[joeqsmith]

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.

And if you run the old app again, does the problem return?   

[joeqsmith]

Just in case you missed it, again you do need some hardware to use WireShark with BLE.   

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

[EEVblog]

Ran the old 1.0.58 app (it doesn't overwrite when you install the new version) and I didn't get an data drops in 1/5hrs again (26400 samples).
So something else is going on here, perhaps interference related.

[joeqsmith]

That's not good.  Did you conduct these new tests using resistance mode with the same 1k resistor you originally used? 

I have tried sweeping the resistance value when using my software and saw no problems but maybe it has something to do with what you saw.   

I wouldn't think interference from other sources would be a problem.  Similar to how we are able to send so much data over the internet with countless other traffic, Bluetooth is similar (actually why I suggested WireShark).  When I tried running these tests at work, I also get a lot of traffic but was never able to replicate the 10X.   

Brymen did contact me about reinstalling the application for the iPhone.  The short story, I now have the 0.1.20 firmware installed.  These changes did not improve my connection problems when using the Andoid phone.  The iPhone on the other hand seems to work fine.   I understand they received their BLU G64 phone.   Hopefully they are able to find the incompatibility problem.  At a minimum, I think the more phones they test, the more robust their application will be.   

[joeqsmith]

I do not know what they changed with the radios firmware but it did not appear to effect the operation.   Shown, I had take the meter with resistor substitution box for a walk, switching different values while forcing some dropouts (note updated firmware).  It wouldn't make a lot of sense that this would cause a problem.  You're a mile away from the switch point.   Still, I wouldn't rule anything out at this point.   Something obviously was causing it.

Also note that even with these dropouts, there are no CRC faults detected.  This is what I was suggesting that BLE should handle that at a lower level. 

With the iPhone now able to program the firmware, I think the next step will be to sniff that traffic during the process and see if I can answer some of the questions I have about how they have implemented the OTA programming.   I just need to steal my wife's phone which is going to be easier said than done!

[floobydust]

I'd take a sig gen and resistor and modulate the resistance seen by the DMM by a very tiny amount, at the rollover value. With a LF sine or square wave maybe.
Causing the DMM some jitter, example reading 1.0005k to 999.90 so it's at going back and forth centered at the rollover/range/exponent change, at say at 1Hz.
If Brymen firmware doesn't use proper semaphors, the read and write of the reading data structure would not be atomic.
I'm saying (as a guess) the BT thread reads shared memory holding the last reading, but while the DMM thread is updating it with a new reading- but decimal pt has moved.
Or the BT module messes up reading the long term verses short term average the DMM has and switches between. Just giving some ideas of thing to flush it out, instead of waiting for it to appear.

[joeqsmith]

I'd take a sig gen and resistor and modulate the resistance seen by the DMM by a very tiny amount, at the rollover value. With a LF sine or square wave maybe.
Causing the DMM some jitter, example reading 1.0005k to 999.90 so it's at going back and forth centered at the rollover/range/exponent change, at say at 1Hz.
If Brymen firmware doesn't use proper semaphors, the read and write of the reading data structure would not be atomic.
I'm saying (as a guess) the BT thread reads shared memory holding the last reading, but while the DMM thread is updating it with a new reading- but decimal pt has moved.
Or the BT module messes up reading the long term verses short term average the DMM has and switches between. Just giving some ideas of thing to flush it out, instead of waiting for it to appear.

I would say this is a very good idea and one I had ran with this meter but not straddling the 1k arbitrarily selected test point.  This would be very easy for me to setup such a signal (see attached triangle wave at 0.05, 0.1, 0.5 & 1Hz).  Then increasing the amplitude to get roughly the same p-p value. 

While you suggest the problem is on the meter side, I don't know that.  Hence asking about about sniffing the communications.   I could run this test using the phone but it can take upwards of an hour an a half just to connect with the meter.  However, if the problem is with the meter, I am now running the same firmware for both the radio and DMM as Dave's.   It should reproduce with my Windows application.   I'll let it run like this for a few hours but I doubt very much we will see anything. 

[joeqsmith]

One thing to mention is that is not some floating point number.  If you read their document, that decimal point will have a fixed location within the five digits the meter sends (in the case of this 1k ohm test).  What it sends would be 1.0005k to 0.9995k for example rather than 1.0005k to 999.90.  If the phone presents the later, it is because the phone is reformatting the data.   In my software, the large readout is the decoded ASCII data.  This is then changed to a float which is graphed (and other processing).   

Shown with a bit over a half hour of data collected.  Nothing particularly of interest in the data but I will allow it to run a while longer.

[joeqsmith]

Over an hour and a half of dithering the data about the 1k ohm as suggested, not a single 10X glitch.   Maybe Dave will try it for you using his meter and phone.

[floobydust]

That was fast but no fruit on your bench it seems.
I'm looking at the big packet of 152 bytes. The reading is sorta floating point in that there are 3 bytes with the Mantissa [21,22,23], and then the Characteristic (exponent) gets assembled from [24,27] I think.
The 32-byte "Device Reading Packet" portion, bytes 24 and 27. Maybe they are the ones giving trouble? So I was thinking about working them to check the edge conditions.
[24] Reading Decimal Point (depends on # digits displayed)
[27] Display Digit Number (3 or 4 or 5 or 6 digits displayed)

Does the meter on Ohms keep a constant number (5?) of digits? Or does it slide over when below 1,000.

[joeqsmith]

I did lower the amplitude to improve your odds and let it run a while longer but as you can see it had no effect.   I have collected several hours of data with this meter over the Bluetooth interface and have never seen what was described.  You would think at some point I would have run into it but again, we do not have the exact same setup although I am taking steps to minimize those differences. 

Does the meter on Ohms keep a constant number (5?) of digits? Or does it slide over when below 1,000.

 

*** 
For example:
1 ohm = 001.00
0.01 ohm = 000.01
***

I believe so.  The number of leading zeros and location of the decimal point will change is all.  For this particular case, the decimal will remain fixed.   Now in Dave's 10X case, the decimal may have shifted right but I think the actual data was outside the meters max count.   You would need to go back and read his posts.   Basically I thought what he showed made no sense at all.   I would have bet the farm it was the Andoid application but the limited amount I have used it, I was still unable to replicate the problem.   

Do a deep dive on that document.  If you have any questions about it, feel free to ask.  If you come up with some other test that you think could force this fault, let me know and I will see if I can set something up.   

***

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

[joeqsmith]

Shown is data I collected using the same meter and radio firmware revisions as Dave's test.  Same Android application revision.   The meter and phone are not the same hardware and the phone's are using a different versions of Android.   

[EEVblog]

That's not good.  Did you conduct these new tests using resistance mode with the same 1k resistor you originally used? 

Yes.
Will run it again today for longer.

[EEVblog]

Wow, 52000 samples and I got a whole bunch of dropouts on v1.0.59 today.
Only physical environment difference is I had the aircon on.
Will try again with v1.0.60

[EEVblog]

Short 20,000 sample test on 1.0.60 with aircon on done, no drops.

[joeqsmith]

Could you please post or email me the data you recorded when the glitches occur. 

Do you remember if your A/C was running during the time when you first noticed the 10x glitches? 

Beyond running that new application with the same setup, A/C on or off, for as long as possible, I'm not sure what else you could do.   I wonder if the A/C actually played into it, or was something else going on.

Brymen was able to replicate the connection problems I am having with the BLU phone.    

[joeqsmith]

Also, I am curious if you are seeing any problems with the files not being saved during longer collections?

[EEVblog]

Could you please post or email me the data you recorded when the glitches occur. 
Do you remember if your A/C was running during the time when you first noticed the 10x glitches? 

Don't recall.
I only noticed it because I happen to be running specific lab air quality measurements that need me to have the aircon or or off all day.

Beyond running that new application with the same setup, A/C on or off, for as long as possible, I'm not sure what else you could do.   I wonder if the A/C actually played into it, or was something else going on.

Needs more testing I guess.
At the moment, v.1.0.60 seems to have fixed it. But again, more testing required.

[EEVblog]

Also, I am curious if you are seeing any problems with the files not being saved during longer collections?

Biggest one so far is 3 hours. No problems apart from it taking a bit extra time to process before the save button comes up.

[joeqsmith]

I have lost files a few times when using the phone.  Today I let it run about 5 hours.  It took a very long time to prompt me for the file but eventually it looked like it had saved.  Using the PC to transfer the data to the PC, it had 0 Bytes.   The phone has plenty of storage space but it could be another incompatibility.

It's always that 9.9996.  Everything is stable before and after.   The decimal point is in the correct location but it acts like the digits were shifted left and you gained that 6 digit.   If you try this with some other value that is less consistent (0.1234 for example), do you see a similar shift? 

As a last ditched effort to remove one more variable, I am attempting to modify one of the BM786 meters to a BM787BT.  I will also trim my resistance to match yours.   Even if I am unable to replicate what you are seeing,  I hope to test their applications with more than one source. 

[EEVblog]

It's always that 9.9996.  Everything is stable before and after.   The decimal point is in the correct location but it acts like the digits were shifted left and you gained that 6 digit.   If you try this with some other value that is less consistent (0.1234 for example), do you see a similar shift? 

I'll try that after another v.1.0.60 test running now.

As a last ditched effort to remove one more variable, I am attempting to modify one of the BM786 meters to a BM787BT.  I will also trim my resistance to match yours.   Even if I am unable to replicate what you are seeing,  I hope to test their applications with more than one source.

You'll have to physically swap the processor as well to get the firmware change, not sure I see the point in that?

[EEVblog]

I have lost files a few times when using the phone.  Today I let it run about 5 hours.  It took a very long time to prompt me for the file but eventually it looked like it had saved.  Using the PC to transfer the data to the PC, it had 0 Bytes.   The phone has plenty of storage space but it could be another incompatibility.

There might be a max sample number limit where something breaks.

[EEVblog]

Just found another issue.
I was logging data and decided to take the phone and the meter in a bag to the post office and shops. This was the first time I had locked the phone during logging. I also used the RFID to pay for something.
Even after all that I could still see the program was logging as I scrolled through the open apps.
But when I got back to the lab and lunlocked thep hone switched the logging app, it was disconnect and the logged data was all gone 

[joeqsmith]

Yes, when during those first tests where I walked away from the meter carrying the phone to force the drops, I would often loose the data.  These tests were over a few minutes rather than hours.   You could try that very easily.  With mine, the phone's screen will blank out when you pushed it too far.

>>You'll have to physically swap the processor as well to get the firmware change, not sure I see the point in that?
I thought I have been clear about that.  The point is to try and reproduce what you are seeing with those 10x glitches.  Part of that is removing unknown variables.     

[EEVblog]

>>You'll have to physically swap the processor as well to get the firmware change, not sure I see the point in that?
I thought I have been clear about that.  The point is to try and reproduce what you are seeing with those 10x glitches.  Part of that is removing unknown variables.   

I don't see how the meter hardware can be the problem.
But ff it is the problem, i don't see a mechanism where there is a difference/fault in the hardware between boards.
Not impossible, but seem like the most remote possibility