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

0 Members and 1 Guest are viewing this topic.

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
121GW bluetooth protocol
« on: January 12, 2018, 09:28:34 am »
I prefer to create separate thread, as (hopefully) here we can discuss bluetooth protocol of 121GW.
It looks like quite trivial to integrate to various software.

As far as i see specification is not published, and honestly github C# sources are not clear(no comments whatsoever, but i am usual OSS/Linux fanboy,
and C# is something i just dont like)

So till now what i reached, i am subscribing over BLE, to indication, over handle 0x9
This is what i get:

n@n:~$ gatttool -b 88:6B:0F:41:0A:8F --char-write-req -a 0x0009 -n 0300 --listen
Characteristic value was written successfully
Indication   handle = 0x0008 value: f2 31 37 30 38 30 30 30 30 30 30 32 30 30 30 32 45 34 30 36
Indication   handle = 0x0008 value: 31 32 30 30 30 30 30 30 30 30 31 36 34 30 30 30 30 36 31 32
Indication   handle = 0x0008 value: 30 30 30 30 30 30 30 30 30 30 30 30 42 32 0d 0a f2 31 37 30
Indication   handle = 0x0008 value: 38 30 30 30 0a f2 31 37 30 38 30 30 30 30 30 30 32 30 30 30
Indication   handle = 0x0008 value: 32 31 43 30 0a f2 31 37 30 38 30 30 30 30 30 30 32 30 30 30
Indication   handle = 0x0008 value: 32 31 43 30 0a f2 31 37 30 38 30 30 30 30 30 30 32 30 30 30
Indication   handle = 0x0008 value: 32 31 43 30 36 31 32 30 30 30 30 30 30 30 30 31 36 34 30 30

As i suspect, BLE indication is limited to 20 bytes, and probably real data needs more, so it come over several BLE indication packets.

Or as ASCII something like that (over simple python script):
A notification was received: ?1708000000000000064
A notification was received: 0100B30B000240000000
A notification was received: 0000000000009F
?170
A notification was received: 8000
?17080000000000
A notification was received: 0006
?17080000000000
A notification was received: 000640100B30B0002400
A notification was received: 0000
?17080000000000
A notification was received: 000640100B30B0002400

Probably 0xF2 signaling start of data? (very likely according C# code)

So string to decode is "17080000000000000640100B30B0002400000000000000000009F"
I will try first:
17,08,00000,0,00,

Then according to source, first 2 bytes should be year:
public int Year => DecimalNibbleToValue(0, 2) + 2000;
I have 2018 set correctly, but it seems showing 2017?
Next is month 2 - 08? august?
Serial 00000 - well, no idea why zeroes, maybe not implemented yet.
00 Voltage Low Z - which is correct

I switched to voltage:
17,08,00000,02,0001B8061200000000164000061
And 02 is correct, "Voltage AC (V)", thats what i see on screen.

So what you think should be done next? Maybe, i can do some easy to hack python script based on bluepy library.
This will open bunch of opportunities to hook multimeter to raspberry, use it for triggering some specific events (like voltage threshold reached, and something should be done)

Suggestions?
 
The following users thanked this post: Iagash

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #1 on: January 12, 2018, 11:07:52 am »
With simple python script to accumulate data from notifications from 0xf2 to 0xf2, with fairly trivial script, here is what i got:
It looks like crc errors?
I dont exclude it is some python issues (usually i use C/c++/Go, but programming BLE with them is pain and not very cross-platform)

Accumulated data(55): array('c', '17080000001000001640100BD00000E4000000000000000000096\r\n')
Accumulated data(43): array('c', '17080000001000001640100BD00000E40000000000\n')
Accumulated data(55): array('c', '17080000001000001640100BD00000E4000000000000000000096\r\n')
Accumulated data(43): array('c', '17080000001000001640100BD00000E40000000000\n')
Accumulated data(55): array('c', '1708000\x81001000001640100BD00000E4000000000000000000096\r\n') <-- this one for example 0x81 appeared in serial number
Accumulated data(43): array('c', '17080000001000001640100B"00000E40000000000\n')
Accumulated data(55): array('c', '1708000000100000064&100BD00000E4000000000000000000097\r\n')
Accumulated data(43): array('c', '17080000001000000640100BD00000E40000000000\n')
Accumulated data(55): array('c', '17080000001000000640100BD00000E4000000000000000000097\r\n')
Accumulated data(43): array('c', '17080000001000000640100BD00000E40000000000\n')
Accumulated data(55): array('c', '17080000001000001640100BE00000E4000000000000000000095\r\n')
Accumulated data(43): array('c', '17080000001000001640100BE00000E40000000000\n')
 

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: 121GW bluetooth protocol
« Reply #2 on: January 12, 2018, 11:35:11 am »
Hi,

With simple python script to accumulate data from notifications from 0xf2 to 0xf2, with fairly trivial script, here is what i got:
It looks like crc errors?
I dont exclude it is some python issues (usually i use C/c++/Go, but programming BLE with them is pain and not very cross-platform)

wow this is cool. I tried your gattool command and can also receive data from my 121gw.

I just tried with my laptop but will look through my hardware box if I can find a BLE capable usb bluetooth receiver for my desktop machine.

Could you add your python script to your post?
« Last Edit: January 12, 2018, 11:37:06 am by Iagash »
 

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #3 on: January 12, 2018, 11:38:36 am »
It is still VEEERY early debug, i am just searching for a way to retrieve data reliably and then will start parsing it
Code: [Select]
#!/usr/bin/python
from bluepy import btle
from bluepy.btle import UUID, Peripheral,DefaultDelegate
import binascii
import array
from struct import *

def parse_data(x):
    xlen = len(x)
    for offset in range(0,xlen):
        if (ord(x[offset:offset+1]) == 0xF2):
            # Process accumulated data
            print ("Accumulated data(%d): %s" % (len(parse_data.accumulated_data), str(parse_data.accumulated_data)))
            parse_data.accumulated_data = array.array('c')
        else:
            parse_data.accumulated_data.append(x[offset:offset+1])

class MyDelegate(btle.DefaultDelegate):
    def __init__(self):
        btle.DefaultDelegate.__init__(self)

    def handleNotification(self, cHandle, data):
         parse_data(data)


parse_data.accumulated_data = array.array('c')
# Put your multimeter mac here
p = btle.Peripheral("88:6B:XX:XX:XX:XX", btle.ADDR_TYPE_PUBLIC)
p.setDelegate( MyDelegate() )

print('Ready!')
p.writeCharacteristic(0x9, "\x03\x00")

while True:
    if p.waitForNotifications(1.0):
        continue

    print("Waiting...")

 
The following users thanked this post: Iagash

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: 121GW bluetooth protocol
« Reply #4 on: January 12, 2018, 02:50:35 pm »
Thanks a lot, I found an usb-adapter that seems to support BLE and I got your script running after compiling and installing bluepy. 

I also get these strange escapes:

Accumulated data(39): array('c', '17080000004\x0300000061200000100164000061\n')
 

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #5 on: January 12, 2018, 03:55:02 pm »
Probably we need to wait official comments and documentation for protocol(ot at least ideas, why data is sometimes corrupted), then i can continue development.
 

Offline hwti

  • Contributor
  • Posts: 19
  • Country: fr
Re: 121GW bluetooth protocol
« Reply #6 on: January 12, 2018, 04:22:46 pm »
Using text doesn't seem very efficient !
But even on BLE, 5 measurements (ie 100 bytes ?) by second should be doable, but it depends on the connection interval.
 

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #7 on: January 12, 2018, 04:29:08 pm »
On my experience with BLE (but with NRF51), it can do much more.
But in that case i developed a bit custom protocol, while in 121GW is bluegiga module, probably used in "serial cable extender" mode, i'm not very familiar with this module, and not even sure it is possible to upload custom firmware there.
 

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: 121GW bluetooth protocol
« Reply #8 on: January 12, 2018, 05:17:12 pm »
I played around with the gatttool a bit using:
Code: [Select]
gatttool -b 88:6B:0F:XX:XX:XX --char-write-req -a 0x0009 -n 0300 --listen | ./121gw.pl
The perl script triggers on the 0xf2 like Dave2's app does. However the app calls the PacketProcessor with a length of 52.

Code: [Select]
private PacketProcessor MyProcessor = new PacketProcessor(0xF2, 52);
I don't understand where the 52 is from. From gatttool I get most of the time 78 hex chars or 39 bytes until the next 0xf2 follows..

The perl script is that one (sorry, I only know perl, yes I'm that old):
Code: [Select]
#!/usr/bin/perl

$start = 0;

while(<>) {
        if ( /^Indication   handle = 0x0008 value: (.*)/ ) {
                @in = split(' ',$1);
                foreach $b (@in) {
                        if ( $b eq "f2" ) {
                                print "\n";
                                $start = 1;
                        } else {
                                if ( $start == 1 ) {
                                        print "$b";
                                }
                        }
                }
        }
}
print "\n";

The output looks like this:

Quote
31373038303030303030313031343041451b34303130304537303130383038343030303030300a
3137303830303030303031300c343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453607303834303030303030303030303030303030300a
31373038303030303030313031343041450d74373031303830383430303030303030303030300a
3137303830303030303031303134304145360a
31370638303030303030313031343041453634303130304537303130383038343030303030300a <-- here is a "06" at pos 5,6 where I expected "30"
31373038303030303030313031343041453634303130304537303106383038343030303030300a
31373038303030303030313031343041453634303130534537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
3137303830303030303031303134304145360c304537303130383038343030303030303030300a
3137303830303030303031303134304145360630303030303030303030303032440d0a
313730383030303030303130313430414536343031300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634300330304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453681303030303030303030303030303030303030300a
313730383030303030303130313430414536303032440d0a
3137303830303030303031303134304145363430313030453730313038303834300a
31373038303030303030313031343041453634303130304537303130383038343030303030300a
31373038303030303030313031343041453634303130304537303130383038341830303030300a

So there seem to be incomplete records. You  can also find flipped bits in the "complete" records.
It looks like the BLE transmission is either inherently unreliable (I don't know anything about BLE) or the meter is sending garbage and incomplete records.

In Post https://www.eevblog.com/forum/testgear/eevblog-121gw-multimeter-issues/msg1397729/#msg1397729 I also quoted bluetooth logged VA values, which where way of.

Did you find anything in the app that looks like a CRC or something else that makes sure the data is correct? I didn't find anything.

If there is no data integrity check and the BLE protocol doesn't make sure the data arrives correct, then this bluetooth feature is completely useless.
« Last Edit: January 12, 2018, 06:09:26 pm by Iagash »
 

Offline hwti

  • Contributor
  • Posts: 19
  • Country: fr
Re: 121GW bluetooth protocol
« Reply #9 on: January 12, 2018, 05:57:13 pm »
There should be a CRC on the lower layers.
BLE indications are also acknowledged, so nothing should be lost.

If the meter is more than 1.5m away from my laptop, the gattool command sometimes fails, and even when it works the connection drops after a few seconds.
Perhaps the transmission power is very low (but it could be my laptop's fault too).
« Last Edit: January 12, 2018, 05:59:19 pm by hwti »
 

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: 121GW bluetooth protocol
« Reply #10 on: January 12, 2018, 06:14:23 pm »
Yes, I did some reading on BLE and the GATT profile. The lower layers should take care about transmission errors.

This makes the variable length and "unexpected" bytes in the "records" even more suspicious. Unfortunately the 121gw is my only BLE device, so I can't test if I get correct data from other devices.

I'd also be interested in the reasoning of sending the data basically ASCII coded when transmission speed is already low.
 

Offline riyadh144

  • Supporter
  • ****
  • Posts: 74
Re: 121GW bluetooth protocol
« Reply #11 on: January 12, 2018, 06:29:43 pm »
That is pretty great work, I will start testing and playing with it once I get my meter.
 

Offline beanflying

  • Super Contributor
  • ***
  • Posts: 3977
  • Country: au
  • Toys so very many Toys.
Re: 121GW bluetooth protocol
« Reply #12 on: January 14, 2018, 05:58:48 am »
Using one of these ANT+ dongles I use on my indoor Trainer (yes I am a Lycra wearer too ;D ) https://www.ebay.com.au/itm/USB-ANT-Stick-for-Garmin-Forerunner-310XT-405-405CX-410-610-910-/232297420959?hash=item361601589f

Added it on the shack PC and it hooked up to the 121GW without a problem.

One of the first things to do if possible now is to get access to the internal SD card so log files can be read, deleted etc!

Log from the install
"Driver Management concluded the process to install driver bthleenum.inf_x86_3bbedb3abba072b6\bthleenum.inf for Device Instance ID BTHLE\DEV_886B0F731C99\6&3338274&0&886B0F731C99 with the following status: 0x0."
Coffee, Food, R/C and electronics nerd in no particular order :)
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30113
  • Country: au
    • EEVblog
Re: 121GW bluetooth protocol
« Reply #13 on: January 14, 2018, 08:26:10 am »
Probably we need to wait official comments and documentation for protocol(ot at least ideas, why data is sometimes corrupted), then i can continue development.

We saw data corruption too, David dealt with it in software somehow, he may be able to clarify.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30113
  • Country: au
    • EEVblog
Re: 121GW bluetooth protocol
« Reply #14 on: January 14, 2018, 08:26:55 am »
One of the first things to do if possible now is to get access to the internal SD card so log files can be read, deleted etc!

It's not. The firmware has no support to do this that I know of.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30113
  • Country: au
    • EEVblog
Re: 121GW bluetooth protocol
« Reply #15 on: January 14, 2018, 08:28:54 am »
On my experience with BLE (but with NRF51), it can do much more.
But in that case i developed a bit custom protocol, while in 121GW is bluegiga module, probably used in "serial cable extender" mode, i'm not very familiar with this module, and not even sure it is possible to upload custom firmware there.

The Bluegiga 112 module uses the standard Cable Replacement mode. There is an internal header to reprogram this is you really want to.
 

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #16 on: January 14, 2018, 08:50:44 am »
The Bluegiga 112 module uses the standard Cable Replacement mode. There is an internal header to reprogram this is you really want to.
Probably if i will do anything, only if it is useful for rest of community. For myself - existing functionality is more than enough, just data corruption a bit irritating.
Yes, it is solvable (by checking length of data, printability of characters in the middle of data chunk, etc), but such trivial issue should be fixed in firmware, if possible.
I'm realistic about this subject as well, sometimes it is not possible, i have experience working with proprietary OEM blobs where vendor just don't care to fix such issues, and only way left - ugly workarounds.

And about retrieving data from sdcard, it is for sure on stm32 and i believe it is definitely possible (unless bluegiga hooked on TX only), but again - this depends if someone might get luck with reverse engineering it(no idea how welcome it is), or get into some NDA and make alternative firmware.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30113
  • Country: au
    • EEVblog
Re: 121GW bluetooth protocol
« Reply #17 on: January 14, 2018, 08:56:01 am »
And about retrieving data from sdcard, it is for sure on stm32 and i believe it is definitely possible (unless bluegiga hooked on TX only), but again - this depends if someone might get luck with reverse engineering it(no idea how welcome it is), or get into some NDA and make alternative firmware.

It was discussed early on and UEi said it was not easy to add, so we decided to leave it out, I would be stunned if it's been included.
 

Offline nuclearcat

  • Supporter
  • ****
  • Posts: 82
  • Country: lb
Re: 121GW bluetooth protocol
« Reply #18 on: January 14, 2018, 09:02:24 am »
It was discussed early on and UEi said it was not easy to add, so we decided to leave it out, I would be stunned if it's been included.
The only respectful reason, i believe, if they are out of resources on stm32 :)
Any chance data corruption will be solved in upcoming firmware releases?
If not, i finish python examples with workarounds for this corruption.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30113
  • Country: au
    • EEVblog
Re: 121GW bluetooth protocol
« Reply #19 on: January 14, 2018, 09:22:26 am »
Any chance data corruption will be solved in upcoming firmware releases?

Report it on the Issues thread and it'll go on the list.
 

Offline Kean

  • Supporter
  • ****
  • Posts: 922
  • Country: au
  • Embedded systems & IT consultant
    • Kean Electronics
Re: 121GW bluetooth protocol
« Reply #20 on: January 14, 2018, 06:02:03 pm »
I wonder if the data corruption mentioned above is a slight mismatch in baud rate between STM32 and Bluegiga module.  I'm guessing they're both using crystal oscillators.
Alternatively, is there any circuitry between the STM32 serial transmit and the Bluegiga receive - e.g. level converter?
 

Offline savageautomate

  • Supporter
  • ****
  • Posts: 41
  • Country: us
  • Technology Entrepreneur, Consultant, Enthusiast
    • Savage Home Automation (Blog)
Re: 121GW bluetooth protocol
« Reply #21 on: January 15, 2018, 07:43:38 pm »
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.

I also have a rough prototype working on an ESP32 board (http://amzn.to/2mydmoq) that can capture the BLE packets and forward them to the USB connected serial port.  The BLE implementation is still pretty wonky and the platform is a bit unstable.  I'm really looking to implement this logic on an Adafruit nRF52 board (http://amzn.to/2FECcvP) as its much more stable but I'm waiting for a bug to be addressed (https://github.com/adafruit/Adafruit_nRF52_Arduino/issues/113) before I can move forward with it.

 Thanks, Robert
 

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: 121GW bluetooth protocol
« Reply #22 on: January 15, 2018, 08:45:15 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.

« Last Edit: January 15, 2018, 08:48:12 pm by Iagash »
 

Offline amspire

  • Super Contributor
  • ***
  • Posts: 3784
  • Country: au
Re: 121GW bluetooth protocol
« Reply #23 on: January 15, 2018, 10:23:00 pm »

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.
Thank you. I have been wondering what that number is for.
 
The following users thanked this post: nuclearcat

Offline Iagash

  • Regular Contributor
  • *
  • Posts: 69
  • Country: de
Re: 121GW bluetooth protocol
« Reply #24 on: January 16, 2018, 08:43:09 am »
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..
 

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.
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 5911
  • 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