EEVBlog 121GW Discussion thread

[Iagash]

No need to implement CRC, because BLE has this already integrated on the lower levels and automatically resends packets, if they are wrong, so no need to implement it on the data layer. Usually you can be sure that the transmitted data is right, so it must be another problem.

Yes I know. I checked the BLE spec.

The problem is with the firmware communicating with the BLE-module and the guesswork seems to be in the App since last August. So they seem to know since some time.

[FrankBuss]

No need to implement CRC, because BLE has this already integrated on the lower levels and automatically resends packets, if they are wrong, so no need to implement it on the data layer. Usually you can be sure that the transmitted data is right, so it must be another problem.

Yes I know. I checked the BLE spec.

The problem is with the firmware communicating with the BLE-module and the guesswork seems to be in the App since last August. So they seem to know since some time.

Ok, but why did you write that the protocol is broken without some sort of data integrity like CRC? Even industry standard protocols like SCPI (which would be nice to have in the multimeter) don't have integrated checksums, but it is implemented in the lower levels as TCP/IP (don't know if GPIB has a checksum).

[Iagash]

Ok, but why did you write that the protocol is broken without some sort of data integrity like CRC? Even industry standard protocols like SCPI (which would be nice to have in the multimeter) don't have integrated checksums, but it is implemented in the lower levels as TCP/IP (don't know if GPIB has a checksum).

Since the serial communication between the BLE module and the CPU is not protected and obviously unreliable.
I guess it's hard to impossible to add protection to the BLE-module, so just make it end-to-end.

It's cheap and easy and you're set.

[FrankBuss]

Since the serial communication between the BLE module and the CPU is not protected and obviously unreliable.
I guess it's hard to impossible to add protection to the BLE-module, so just make it end-to-end.

It's cheap and easy and you're set.

This would be a bad patch, and if it is a problem in the firmware before the checksum is calculated, it wouldn't even help. But Dave wrote that one data corruption UART issue was fixed. Would be better to find all issues instead of trying to program workarounds. A few cm PCB trace UART with the typical baud rate that these chips uses, can't have transfer errors. But there can be interesting problems, if you don't set the interrupt priorities right, if you receive data over UART, or if you don't implement flow control right, if the BLE module needs this, like RTS/CTS or XON/XOFF.

[1anX]

A one sentence summary would be that the 121GW meter was a good idea poorly implemented!

I understand where you are coming from, but I would call that a bit harsh.  I would call that a "consumer" comment, not an "engineer" one.

I would call my comment accurate!

The concept for this meter has a lot of merit and those of us that have placed our order understand what the specification will provide us with as users. Then to have the "production meter" released to backers with an out of spec switch that suffers from intermittent contact is pretty much unacceptable in 2018. Even the cheapest of multimeters have reliable switches and the 121GW is not a cheap meter.

The implementation of the meter with a chipset that both Daves and UEi combined dont understand fully was risky. It was risky for the users as its their money that could have been spent on a comparable reliable meter with a fully functioning switch and mature firmware.

Finally as you, (Brumby) like car and car manufacturing metaphors, here is one to consider. Thank god UEi and the 2 Daves dont use the "lets get everyone involved to test it in the real world" concept for developing and fixing the bugs in self driving cars for our public roads 

Having said all of the above and meaning it, I would also like to add that I am confident that eventually the meter will evolve into and match its concept. It was and is simply a "poor implementation", lets face it, the current meter is nothing more than a prototype.
 

[Iagash]

This would be a bad patch, and if it is a problem in the firmware before the checksum is calculated, it wouldn't even help.

But Dave wrote that one data corruption UART issue was fixed. Would be better to find all issues instead of trying to program workarounds.

Well, yes, you're right.

But considering the bug is there and known since last August, how do you calculate the chances that they'll find it, fix it and get it right?

The CRC is one or two man hours at UEI and one for Seppy in the app, that's worth less than two meters and you don't need to guess the data.

[glarsson]

I would prefer that the bug is fixed (and get all data points) rather than just made the corruption detectable with the help of CRC (and lose data points).

[EEVblog]

No need to implement CRC, because BLE has this already integrated on the lower levels and automatically resends packets, if they are wrong, so no need to implement it on the data layer. Usually you can be sure that the transmitted data is right, so it must be another problem.

Yes I know. I checked the BLE spec.

The problem is with the firmware communicating with the BLE-module and the guesswork seems to be in the App since last August. So they seem to know since some time.

The firmware and packet DOES have a XOR based checksum at the end.
Our software does multiple things to check for bad packets, but if a packet is not received in full for whatever bluetoothy reason, it might be hard to recover from that unless you do lots of stuff. David's app for example using a voting system among other things to handle non-fully received packets.
We are looking into this improving the packet protocol.

[nidlaX]

No need to implement CRC, because BLE has this already integrated on the lower levels and automatically resends packets, if they are wrong, so no need to implement it on the data layer. Usually you can be sure that the transmitted data is right, so it must be another problem.

Yes I know. I checked the BLE spec.

The problem is with the firmware communicating with the BLE-module and the guesswork seems to be in the App since last August. So they seem to know since some time.

The firmware and packet DOES have a XOR based checksum at the end.
Our software does multiple things to check for bad packets, but if a packet is not received in full for whatever bluetoothy reason, it might be hard to recover from that unless you do lots of stuff. David's app for example using a voting system among other things to handle non-fully received packets.
We are looking into this improving the packet protocol.

It would be useful if the user could receive some feedback regarding incomplete / lost packets in the app.

[Iagash]

The firmware and packet DOES have a XOR based checksum at the end.

Thanks!

But I guess you won't tell me how it is calculated or why it doesn't seem to be used in your app. At least I can't find it.

What I find concerning data validation is this:

Code: [Select]

static bool is_valid(string input) {
       if (input.Length != 52)
                 return false;
       foreach (var c in input)             {
              if (!(Char.IsDigit(c) || Char.IsLetter(c)))
                     return false;
      }
      return true;
}


David's app for example using a voting system among other things to handle non-fully received packets.

Yeah, the data sometimes looks like the result of some democratic process. 

We are looking into this improving the packet protocol.

Thanks, I'm very much looking forward to this.

[EEVblog]

But I guess you won't tell me how it is calculated or why it doesn't seem to be used in your app. At least I can't find it.

Not yet, because there is a chance it might change soon.
As for use in the app, only David can answer that.
The github code is not up to date either.

[EEVblog]

The implementation of the meter with a chipset that both Daves and UEi combined dont understand fully was risky. It was risky for the users as its their money that could have been spent on a comparable reliable meter with a fully functioning switch and mature firmware.

Even the big names like Keysight, Fluke, Gossen, Extech etc have all released meters that are less than perfect and have had a range of issues from hardware to software, lost calibration data in updates, bricking, to safety. If you've been watching my videos for a long time you'd know that. One of them almost killed or injured me due to a design flaw. These were all "reliable" released meters from huge reputable names.
I was just talking to one of them the other day commenting on the issues we've unfortunately been having, and they laughed and said they have had much more embarrassing problems in released products. Shit happens.

[Elasia]

The implementation of the meter with a chipset that both Daves and UEi combined dont understand fully was risky. It was risky for the users as its their money that could have been spent on a comparable reliable meter with a fully functioning switch and mature firmware.

Even the big names like Keysight, Fluke, Gossen, Extech etc have all released meters that are less than perfect and have had a range of issues from hardware to software, lost calibration data in updates, bricking, to safety. If you've been watching my videos for a long time you'd know that. One of them almost killed or injured me due to a design flaw. These were all "reliable" released meters from huge reputable names.
I was just talking to one of them the other day commenting on the issues we've unfortunately been having, and they laughed and said they have had much more embarrassing problems in released products. Shit happens.

The first microcontroller bootloader I made eons ago had a nasty flaw of bricking the chip due to brown outs causing code execution jumping into the bootloader code to erase the device!  Oppps

Wasnt that hard to fix with the addition of a reset chip and also by keying the erase code to needing unlock values not stored in the device itself but still... talk about egg on face!

[1anX]

The implementation of the meter with a chipset that both Daves and UEi combined dont understand fully was risky. It was risky for the users as its their money that could have been spent on a comparable reliable meter with a fully functioning switch and mature firmware.

Even the big names like Keysight, Fluke, Gossen, Extech etc have all released meters that are less than perfect and have had a range of issues from hardware to software, lost calibration data in updates, bricking, to safety. If you've been watching my videos for a long time you'd know that. One of them almost killed or injured me due to a design flaw. These were all "reliable" released meters from huge reputable names.
I was just talking to one of them the other day commenting on the issues we've unfortunately been having, and they laughed and said they have had much more embarrassing problems in released products. Shit happens.

Well after criticizing the 121 GW for faulty switches and patches that were apparently poorly tested and then released as "production quality" I had an interesting purchase yesterday.

I purchased 3 Garmin 55 Dash Cams ($240ea) from Harvey Norman. Got home attached my power supply to the cam's charger and went thru setup and testing them. Cut a long story short, only 2 out of the 3 worked correctly. Two of these brand new units would not hold their setup data and would not write it to memory. This meant that every time the cam would power up, 20 or so button presses would be needed to get it to operate.

They will all be returned to HN today for a refund!

Garmin released a device that obviously was untested before being shipped out to sell and looking on a garmin forum it seems that the setup data failure is pretty widespread across the world. The Garmin 55 is an evolved product not a new design, so as you say Dave, shit happens and point taken!

Update!
The guy at HN this morning arranging the refund told me that he is on his 3rd iPhone X, as the previous 2 had charging and battery problems, he now wants it replaced with the iPhone Plus!

[imidis]

I don't have a 121GW or own one. However, many large corporations put out bug ridden and poorly built items. I think the big difference between them and Dave, is Dave cares. Instead of brushing things under the rug, ignoring or hiding them, avoiding any responsibility like so many companies do.

[Elasia]

I don't have a 121GW or own one. However, many large corporations put out bug ridden and poorly built items. I think the big difference between them and Dave, is Dave cares. Instead of brushing things under the rug, ignoring or hiding them, avoiding any responsibility like so many companies do.

Not just large... you got a ton of hacks out there too due to companies just flat out either not understanding risk control around software or even ones that do and just dont give 2 cents... the medical device land is just littered with them and is absurd.  A lot of sectors could learn a thing or two from the avionics industry... probably the best group to have their shit together

I've mostly used agilent portable dmms but i think my next one will be a 121GW if there is a 2nd gen.. i do like the idea of it but late to the party this round

[lukasz.kostka]

Hi.

Is there any chance for new batch of 121GW ? I see that it is out of stock.

[Brumby]

Dave still has a couple of thousand 121GW to deliver from his extremely successful Kickstarter campaign.  That needs to be fulfilled before any consideration can be given to him getting them "in stock" in his EEVblog store.

There was a delay from parts shortages earlier this year - and I don't know if they have been resolved or where that manufacturing is up to.  We do know the mechanical issue with the range switch has been sorted out, but considering the other problems at the moment, it is possible there may be some reservation about forging ahead with a mass run, just in case there needs to be a hardware revision.   << PLEASE NOTE, I am only guessing here. >>   If it is found these problems can be completely eliminated with firmware updates, then I would expect production to get up to speed at the earliest opportunity ... but Dave is the best person to give clear answers here.

[lukasz.kostka]

Thx.

Do you know if there is any channel / information source that I can subscribe to see when multimeters will be available ?

[Brumby]

I believe Dave does Twitter - @eevblog .  I'd be pretty confident he would tweet about that.

(Sorry, I don't do Twitter.)


You could also check in here for updates, as you have.

[Worsdier]

Hi.

Is there any chance for new batch of 121GW ? I see that it is out of stock.

I’m afraid you still have a long time to wait for stock. I backed one of the first 400 meters and it’s been 4 months overdue.

[EEVblog]

Thx.

Do you know if there is any channel / information source that I can subscribe to see when multimeters will be available ?

Sign up for the newsletter
http://www.eevblog.com/newsletter/

Many people still ask, and I don't know why people seaming don't quite understand that I have to deliver the Kickstarter units first before I sell to the general public.

[Seppy]

At this point we are basically using the current user base as a testing platform to find and confirm bug fixes. There is nothing better than giving it to a few hundred people and getting feedback.

This is fine, but please "fix" things and don't "cover up".

The bluetooth transmission is broken by design and by implementation.

• There is no data integrity, aka. CRC or something on records (design error)
• The ASCII decimal/hex coding wastes more then 2/3 of the already scarce bluetooth bandwidth (design error)
• You have to check every single byte received for plausibility (and you'll fail in a lot of cases) (implementation error)
• If you look at the errors in the data it's clear that some buffer in the firmware get's overwritten (implementation error)

Would current owner prefer we not make interim firmware releases available for testing?

I'm fine with testing, no problem.

But the 1.07 -> 1.09 is not a fix, it's just trying to cover up above mentioned errors a bit better.

Start with fixing the missing CRC. Then errors can be detected reliably and automatically and one can trust the data received is what the firmware wanted to send.

As stated before there was actually a checksum. What was happening was the OS was dropping half the packet on some systems, we compacted the packet so that it fits into 19 bytes.

This means that the XOR checksum now reliably makes it into the transmission. There is an update to the multimeter App and firmware that improves the situation greatly but further testing is needed. If anybody needs help developing a script to read the packet feel free to contact me.

The BLE packet format is now in a document on the 121GW product page.

If you install version 1.10 of the firmware you will also need to update the app.
You can do that on the Google Play / Window Store, (at least when they approve the update).

Links for the mentioned documents and firmware can be found at:
https://www.eevblog.com/product/121gw/

[Fungus]

Thx.

Do you know if there is any channel / information source that I can subscribe to see when multimeters will be available ?

Go here and search for "121G":

https://www.oreillyauto.com/

[Iagash]

If you install version 1.10 of the firmware you will also need to update the app.
You can do that on the Google Play / Window Store, (at least when they approve the update).

Thanks, first check findings:

The values displayed in VA mode by the app are still wrong:
meter displays (correctly, verified with other meter): 1966.2mVA DC, 4.3672V, 450.29 mA
app displays: 1966.2mVA DC, 2.1863V, 204.52 A

If I change the input to the meter for negative current, the meter displays the negative current correctly, but the app still displays the same wrong positive current.

So the the values are off around factor 2x, current displays A instead of mA.

This is DC mode, firmware 1.10, app version 5

The update rate is much higher now, thanks!

I'll check the documents and update my script and let you know what I find there.