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)
#!/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...")
gatttool -b 88:6B:0F:XX:XX:XX --char-write-req -a 0x0009 -n 0300 --listen | ./121gw.pl private PacketProcessor MyProcessor = new PacketProcessor(0xF2, 52);#!/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";
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
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.
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!
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.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.
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.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?
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
Thank you. I have been wondering what that number is for.
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.
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.
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..
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:Quote1516048737.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 (https://www.youtube.com/watch?v=7mnrvE271fA&feature=youtu.be)
I used cheapo chinese microscope ($70) and, sure, 121GW