Author Topic: 121GW bluetooth protocol  (Read 7072 times)

0 Members and 1 Guest are viewing this topic.

Offline savageautomate

  • Supporter
  • ****
  • Posts: 41
  • Country: us
  • Technology Entrepreneur, Consultant, Enthusiast
    • Savage Home Automation (Blog)
Re: 121GW bluetooth protocol
« Reply #25 on: January 18, 2018, 10:47:24 pm »
Hi,

I have written a sample NodeJS (Javascript) program that can parse and decode the 121GW data protocol if anyone is interested.
I gathered most of the info needed from David's C# sources.

that's were I also gathered my information for the script.

But did you find a way to get correct readings in VA mode?
 
In VA mode I get every now an then a correct reading but most of the readings are way off, but not invalid in the packet data..

No .. I'm seeing the same thing you are .. wildly erratic values for VA readings.   
I'll have to look again, but I think also some incorrect values for secondary measurements too while on a VA mode.

 
The following users thanked this post: Iagash

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #26 on: January 28, 2018, 10:07:30 pm »
Here is the further developed version of my simple perl-script. It now parses the output of gatttool and displays it in readable form.

You should rename the file from 121gw.txt to 121gw.pl.

Then you can run it via:
gatttool -b 88:6B:0F:73:XX:XX --char-write-req -a 0x0009 -n 0300 --listen | ./121gw.pl

It reads the output of gatttool and parses the packet the multimeter sends.
It detects a lot of error but not all of them, so it's something to play with but until the bluetooth transmission is fixed in the firmware I would not rely on the data.

If the meter is in VA mode most of the data is wrong. This can't be fixed in the script and is also the case in the Android app.

The output looks like this:
Quote
1516048737.255 2017-08 00042   Voltage DC (V)  4.4652 V      _TempC    24.0
1516048737.795 2017-08 00042   Voltage DC (V)  4.4648 V      _TempC    24.0
1516048738.065 2017-08 00042   Voltage DC (V)  4.4648 V      _TempC    24.0
1516048739.010 2017-08 00042   Voltage DC (V)  4.4643 V      _TempC    24.0
1516048739.280 2017-08 00042   Voltage DC (V)  4.4643 V      _TempC    24.0
1516048739.550 2017-08 00042   Voltage DC (V)  4.4640 V      _TempC    24.0
1516048739.820 2017-08 00042   Voltage DC (V)  4.4640 V      _TempC    24.0
1516048740.157 2017-08 00042   Voltage DC (V)  4.4639 V      _TempC    24.0

At the beginning is a unix timestamp when the record was received.
The year and month is always the same since the meter doesn't seem to send the current one.
The third column is the "serial number" of the meter. You can set this value on the meter by cycling through the setup until you reach the display with 00000. If you long press SETUP you can change the digits to some other number. This number is send by the meter in every bluetooth frame.

Here is some PoC i created (unfortunately no sources yet, as its too ugly and mostly just PoC, it is linux specific, C++), idea that might be handy for EE:
Measuring resistance in auto range mode, it is a bit slow to get to correct range.
https://www.youtube.com/watch?v=7mnrvE271fA&feature=youtu.be
I used cheapo chinese microscope ($70) and, sure, 121GW
Not sure if worth to continue this app.
 

Offline benst

  • Regular Contributor
  • *
  • Posts: 56
  • Country: nl
Re: 121GW bluetooth protocol
« Reply #27 on: January 29, 2018, 11:32:01 pm »
Here is some PoC i created (unfortunately no sources yet, as its too ugly and mostly just PoC, it is linux specific, C++), idea that might be handy for EE:
Measuring resistance in auto range mode, it is a bit slow to get to correct range.
https://www.youtube.com/watch?v=7mnrvE271fA&feature=youtu.be
I used cheapo chinese microscope ($70) and, sure, 121GW

That's a great idea!

Ben
I hack for work and pleasure.
 

Offline prof

  • Contributor
  • Posts: 33
  • Country: de
Re: 121GW bluetooth protocol
« Reply #28 on: February 01, 2018, 11:41:48 pm »
I tried analysing the protocol with the "Bluetooth Explorer.app" on the Mac a while back but didn't have a lot of success because the format is rather weird (as you've figured out) and the values are extremely erratic. Glad you figure out at least that much!
 

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #29 on: February 01, 2018, 11:45:13 pm »
I'm waiting firmware with a bit more reliable data(or statement that it is going to stay like this and best way to validate data), or if there is some successful efforts to make custom stm32 firmware.
Unfortunately i dont have much time to spend on reverse engineering or making workarounds that wont be needed in future.
Then i might continue on video app with OSD.
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #30 on: September 21, 2018, 11:19:58 pm »
Looking through your script, it does not appear to come close to what the V2 document shows. 

I attempted to install the latest Windows software onto my desktop, which required the later version of 10.  Fun.  I setup the Microsoft BLE explorer and then sniffed the meter.  The data appears to be all binary now. 

I then put together a simple Labview program to sniff the meter in more detail.  What I see is similar to what you have posted.  The packet size appears to be 37 bytes long, starting with 0xF2.   All of the data appears to be binary. 

Where you show f2 31 37 30 38,   I am getting 0xF2, 0x80, 0x17 for the first three bytes.  This appears to be the same with the MS tool.

I am curious if you have made any further progress with your scripting? 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #31 on: September 22, 2018, 12:40:48 am »
I just wanted to try a simple check before I start looking at the source code up on Git.

Here is a basic raw packet.  It was fairly simple to find the primary and secondary display and what I assume are the sign bits.  These at least match with what shows on the 121GWs LCD. 

Having an actual document would save me some time.  Then again, it looks like from this that the format is going to change again.  This is nothing like the V2 document, which was nothing like the script.   It may be a bit premature to start working on it.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #32 on: September 22, 2018, 05:50:49 pm »
I had asked about which software versions matching the released Windows code.  Sadly no response.  I downloaded the most recent but ended up just decoding the basics by hand. 

Where I have placed a constant next to a position, I suspect these are hard coded as I never see them change.  Notice the pattern at the start is similar to the end.  Looks like a lot of waste to me.

I suspect the one marked checksum is actually a checksum.

The one without a comment, I have not spent the time to sort out.  It's good enough to now to include in the main program that I have been using to evaluate the meter. 

I am surprised they dump what appears to be so many constants.  The bargraph would really do me no good as slow as BT updates.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #33 on: September 22, 2018, 07:25:37 pm »
I've combined the Bluetooth communications with the other processing software I wrote for the 121.  Nothing fancy yet. 

Shown with a 10V peak sine wave, the 121 set to VDC.   A few things to note, when the range changes, the meter appears to send back values of 0.  When I force the range to avoid it changing, the data appears good.  I changed it to a sawtooth and looks like it doesn't miss data.  It's a short test but looks promising.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #34 on: September 23, 2018, 01:25:59 am »
Running the software from the store, it appears to also see the zero's at +/-5 volts when the meter selects a different range. 

Looking at the code that is checked in, it appears that they are moving ahead with the different packet structure. 

There appears to be a big gap in time as far as what was released.  I was not able to find a version that matches with the latest firmware.  A bit of trial and error to overcome the lack of documentation and I believe I am very close with having it all work now.

 







How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #35 on: September 23, 2018, 01:33:28 am »
The next step is to make sure the communications is stable, or at least as stable as what was released for Windows 10.   I let their software collect for while using a sawtooth.  It may miss some points in time but the data itself looks good. 

Currently I am running an extended test using my software.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #36 on: September 23, 2018, 05:04:40 am »
The checksum will be required.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #37 on: September 23, 2018, 05:19:05 am »
The steps I used to process the data are:

1) Store all the received data into a buffer.

2) Search for a single frame.  Basically I look for two start bytes and make sure that there are 36 bytes between them.  Obviously, the meter could output a start byte as part of the normal data.

3) Once I have synchronized to a packet, I calculate the checksum.  Calculating the checksum was sadly a bit of trial and error on my part.  Perform and XOR on the entire 37 bytes, after replacing the location of the sent checksum with a 2. 

That's about it.  Once you have the packet, just decode it.   After adding the checksum, I let it collect for about an hour and saw no glitches.   :-+   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #38 on: September 23, 2018, 01:06:08 pm »
I let it run overnight.  Roughly 7 hours so far without a problem.  The red trace is the secondary display (temperature).  Metrics shown are for the primary display.   I plan to let it run for the day before calling this part done.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #39 on: September 23, 2018, 07:58:06 pm »
Added Dave's logo to make it official.    Also added a readout for the secondary display.  It's been running a bit over 3.5 hours on top of the 7 from last night. 

This plot is looking at the time between receiving a good packet in ms.  Normally it's a half second.  Once in a while, it looks like the communications have some problems and it can take up to four transmissions to get a good packet.   This seems very high to me.  Maybe there is another problem causing so many errors.

From the protocol document:

Quote
We have found from various tests that we can reliably receive 31 bytes on most systems. The previous packet was 54 bytes, we lost half of most packets on some systems. This is not app related, several other users who have developed their own BLE implementations have confirmed this.
Therefore, we propose to make a shorter packet, to improve reception reliability on most systems.
The packet below is 19 bytes, which is substantially shorter than the previous format. The actual data format is identical, except for the way serial number is formatted.
Each digit 0 – 9 of the serial number is stored separately.

Again, I am receiving 37 bytes with version 1.26 firmware.  So it seems something different from what is mentioned here.   I am not keeping stats on the number of errors but it's no where near the 50%. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #40 on: September 24, 2018, 02:17:46 am »
I added a counter for the packet errors.  After 3700 packets, it's sitting around a 1% failure rate.  The blue trace is the error count.  It appears fairly linear as I would expect.  Still, it seems a bit odd that there are any errors at this layer.   

It's very usable as is.  A big step up from using the card to store on.  I doubt I will do any more with it until after they change the protocol.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #41 on: September 24, 2018, 05:21:30 pm »
I am trying to understand why there are ANY checksum faults.   The lower layer has error detection and retry built-in.   Has anyone looked into the causes of the errors?   

It transmits very slow, 500ms.  There is hardly any data being sent.  There would have been a lot of time for the hardware to resend.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #42 on: September 25, 2018, 12:39:12 am »
Because the packet protocols specifically state  "lost half of most packets",  I added a lost packet metric.   

If there is a CRC fault, my software waits for the next packet which will cause a slow packet error.   Slow packets are ones that take longer than 800ms from the last packet.   I take the number of show packets and subtract off the ones caused by the CRC faults.   This is what I think is the actual number of lost packets. 

In this case, we can see of the there are 13 CRC faults and 8 possible missing or dropped packets out of the 2700 that were sent.   It's not perfect but still comes no were near the half that was mentioned. 

I assume the error correction is done at the stack layer.  I wonder if the meter's stack just does not handle the resend and if there is a failure, it gets ignored and the bad packet is sent through.    Seems odd. 

I have seen the meter stall when writing to the SD card and wonder if this is possibly the problem causing delayed or missing Bluetooth packets.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #43 on: September 25, 2018, 03:20:28 am »
Up to this point, all of the testing I have done with the radio were with a distance of a couple of feet.  Moving the 121GW about 2 meters away and I see the CRC errors dramatically increase.   More interesting is that the packet loss seems to double the CRC errors.   

Moving the 121GW about 3 meters and it disconnected.   So I doubled the range, or about 6 meters and can no longer detect the meter.  I tried a different brand radio and the same thing.  The PC can't detect the 121GW.     

I have a Gossen meter that uses BT and I set it next to the 121GW.  Same radio.  No problem detecting it. 

I also got scammed by UNI-T  and bought one of their UT-D07A BLE adaptors.  Sadly they never supported Windows as claimed and I have been too lazy to do anything with it.   I place it next to the Gossen and 121GW. 

I also have a CEM meter with an 900MHz ISM RF link that uses FSK.  Sure, it won't talk to a cell phone, like I care, but I have used it in tests with at least this distance.   


I'm surprised that the radio in the 121GW performs this poorly.   It's possible it's because it's a prototype.  Perhaps the kickstart meters were improved.    I wonder now if this is what is causing these 50% data loss numbers that were reported. 
« Last Edit: September 25, 2018, 10:56:54 am by joeqsmith »
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Online joeqsmith

  • Super Contributor
  • ***
  • Posts: 5927
  • Country: us
Re: 121GW bluetooth protocol
« Reply #44 on: September 25, 2018, 10:20:09 pm »
Meter has been running most of the day.  Notice the strange increase in lost packets.  Nothing was changed.  I wonder if the batteries are starting to run down.  The low battery indicator is not yet active. 

CRC failures continue to be linear. 

I was reading on the BLE112's range.  Seems odd that the meter appears to have problems with such a short distance. 


Quote
Robustness. BLE uses single 24-bit cyclic redundancy check (CRC) on each packet, allowing the header and data fields to detect odd number bit errors as well as 2- and 4-bit errors. The 24-bit CRC, versus 16- or 32-bit CRC, is optimized for BLE’s data payload.

https://www.digikey.com/en/articles/techzone/2014/aug/moving-forward-with-bluetooth-low-energy
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline kgmuzungu

  • Newbie
  • Posts: 4
  • Country: at
Re: 121GW bluetooth protocol
« Reply #45 on: December 08, 2019, 06:53:45 pm »
Hi,

did someone get it running? I mean to directly read from the bluetooth (COM) port and log to a file? If you have some code, also if buggy, can you post or link it?

thanks
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf