EEVBlog 121GW Discussion thread

[joeqsmith]

There is a fair bit of overhead sending that one byte packet.   

There were other motivating factors also which included differences in implementation for BLE on different platforms. Some platforms have a longer buffer than others and it needed to come in one packet.
The number of platforms this device supports was also a factor in the reduction of the packet size.

Right but it sends two messages, not one.   One with a 1-Byte payload and the other with an 18-Byte payload.    If they had considered programming the BLE112 from the MCU, they could correct it. 

The little interface I put together for the 121 would not care how they slice up a packet.  It just stitches the messages together and parses them once it has enough data.   So if the ever did decide to change the code for the BLE112 in production to go to  a single message format, it has no effect.  I do wonder if this is where the higher checksum failure rates are coming from.   

[FrankBuss]

I guess there are other problems. With the Blue Gecko chip I had no problems sending data from 7 m distance, through a wall, and no packets were lost. The packet rate just dropped, maybe because of resending. But this was all automatic in the Bluetooth layer. In my application layer it looked perfect. And the product page of the BLE112 says "Typical Range: 150 Meters" (middle of the page, search for "meters"). Of course, problably they measure this in a desert, far away from all other RF sources, and at night, with new moon but it should be still no problem in a normal setting for a dozen meters.

But the BLE112 is a very low power CPU, with only 8 kB RAM and a 8 bit CPU. The BGM11S I was using has a 32 bit ARM core, with 32 kB RAM. Maybe it doesn't buffer much and the protocol of the main CPU doesn't pay attention if sending data to it is allowed, like when it tries to resend data, or a RTS/CTS problem, if they are using a serial connection.

Or maybe it is a wrong GATT specification. For example if you really need 2 packets, you could specify a characteristic as "reliable write". But this is only available for message sending from the PC/phone to the meter. But for the other way for me a simple "Notify" characteristics worked. Looks like they are reliable, too, which would explain the packet rate drop in my tests, but no loss of packets. So there shouldn't be a problem with the bluetooth transfer itself.

[FrankBuss]

Found another page (note that "server" is the meter and "client" is the smartphone/PC, that's the silly BLE speak) :

https://community.nxp.com/docs/DOC-328525

This says the opposite of the TI page: A "notification" is not reliable, but an "indication" is reliable. So maybe changing the characteristics property from a notification to an indication would help (or vice versa)? Could someone post the GATT definition? If they are using the Simplicity Studio IDE, they will have a nice .isc file in XML format, but you could extract this from the device itself with "gatttool" and some work as well.

[GeoffreyF]

Some 121GW come with Bryman probes and some with UEI Test Probes (silver not gold plated).  I got the UEI probes and they are just fine.

These UEI Test alligator clips (AAC3) screw to the UEI Test probes very well.  The Rubber sleeve fits over the probe and can slide down further to more fully expose the metal of the Alligator clip. The clip  is really strong and well made.

https://www.amazon.com/gp/product/B007HQZB18

Actually the resistance through the probes, with the clips is a little less than holding the probe tips firmly together.  Also, when the clips are used to connect to the temperature probe, instead of plugging it in, there is no difference in the reading.   This indicates to me that there is no measurable loss compared to direct probe contact.

The clips are a bit large and so less suited to some applications than "grabber" type.

[GeoffreyF]

This video explains power up options for the Fluke 87v.  It seems to me somethings like this would be easily implemented in the 121GW. 

[FrankBuss]

Useful options. But might be better if it is in some config menu. Otherwise it gets tricky, if you want multiple power-on functions.

[CDaniel]

Auto power off is inteligent in some meters , not just a timer . It resets itself if the reading is changing as you would measure something .
Anyway many other meters have at least some beeping sounds to warn you before the time is up .

[Seppy]

Sigrock support for the 121GW was added:

https://sigrok.org/blog/libsigrok-051-released
https://sigrok.org/wiki/EEVBlog_121GW

This was done by a user of the 121GW, pretty neat.

[1anX]

Seppy, any word on why firmware V1.51 has been removed from the 121GW firmware list for download?
Is there a problem with the version or is it just missing after a website update? Need to know if the missing version has caused a problem and what the effect on the meter might be.

[Seppy]

We don't think so, but there was an issue with one person. I thought it prudent to pause the update, looks like its safe I'll release it again when we are sure.
Their post on the forum is:
https://www.eevblog.com/forum/testgear/121gw-calibration-killed-after-firmware-update!/

They did not have a backup of their calibration prior to updating and seem to have bricked their cal, this has been investigated and at this point it it seems that their unit might have a physical defect or the cal was accidentally overridden by the user.

[GeoffreyF]

Seppy, I did not know of the need for backing up Calibration and installed 1.51.   I don't know if my Cal is bricked. How do I check?  What instructions did I miss about backing it up?

From your post, it sounds though like this one incident cannot be duplicated in house?

[sirtet]

Android app:
I miss a feature to read/Export logs.
The gw 121 product page links to a UEi app, but the link is dead...
What is/was this app?
I did find a app named "UEi apps" , and in it, a  app "525DMM" is listed.
This latter app has a logs function and does connect to the 121 (shows error if bt is off on 121), but shows no measurements...
What is the Story here?

Gesendet von meinem H8324 mit Tapatalk

[sirtet]

Temp sensor:
The 121 is rated up to 1350Deg. C. Or so. The sensor's insulation is obviously not, the Photo shows the effect of 1040deg. IT still seems to work, but I wonder What temp. Limit the fabric has, and What it is for anyways. The wires must be insulated different, but how.
And, What are the sensor's specs, in case i want to replace it?

Gesendet von meinem H8324 mit Tapatalk

[metta]

Hi Everyone,

I'm getting a little concerned with my order that I made back in September. I'm posting here as a last resort because the person I was in touch with, Suse, has not responded to any of my follow-up emails concerning the tracking of my order or a resolution. My 121GW was destined for Vancouver, Canada but the last tracking update was on September 16th when it passed through Germany: https://ecommerceportal.dhl.com/track/?ref=AUBCN001823543.

If you check the tracking yourself you'll see that it ghosted on me. Hopefully a little exposure in this thread will get some action or response.

Thanks for reading.

[GeoffreyF]

From the link that you  provided, your issue is with DHL, not with Suse or Jonestronics.   I am dumbfounded that you didn't contact the carrier back in September.

[metta]

From the link that you  provided, your issue is with DHL, not with Suse or Jonestronics.   I am dumbfounded that you didn't contact the carrier back in September.

I followed up on this order on October 21st when I was told by Suse to email back in November if I hadn't received by then. I'm not the one arranging shipment so I don't think it's unreasonable to expect the folks over at Jonestronic to follow-up on their end. In my experience, when you purchase something online and it doesn't come through, usually the vendor is the one that has to follow up with the shipping company. Is this not your experience as well?

Edit: Just got off the phone with DHL, and just as I suspected, they tell me this is something that needs to be resolved from the merchant's side. I don't think your snark is warranted.

[GeoffreyF]

If it were me, I would work it with the delivery company.   I think your strategy is really more the cause of your problem than anything.  As your link demonstrates, Jonestronics provided the shipment to DHL.   DHL then lost it.

If you had worked this with your local DHL office, the problem would be solved. At the least they could admit that they didn't have the package anymore. Then their insurance would compensate you.

Now through your stuborness, the trail has grown cold.  Did you even complain to DHL?  I don't fault with Jonestronic's here.  I find it with DHL and your failing to complain they didn't deliver.  Nothing you have written is even remotely  relevant to anything I care about.  You have no issue with the 121 GW because, obviously, you never got one.  So please don't clutter up this thread.   

[jack-daniels]

I'm not the one arranging shipment so I don't think it's unreasonable to expect the folks over at Jonestronic to follow-up on their end. In my experience, when you purchase something online and it doesn't come through, usually the vendor is the one that has to follow up with the shipping company. Is this not your experience as well?

Definitely down to the seller to sort out.

[metta]

I'm not the one arranging shipment so I don't think it's unreasonable to expect the folks over at Jonestronic to follow-up on their end. In my experience, when you purchase something online and it doesn't come through, usually the vendor is the one that has to follow up with the shipping company. Is this not your experience as well?

Definitely down to the seller to sort out.

  I'm happy to take it offline, but I have to try other means if I'm not getting any communication. I understand things get busy.

[Simon]

It is the person that made the contract with the shipper that has to deal with it. DHL are not renowned in a good way all over the world. I tend to use different carriers depending on destination country.

[Brumby]

It is the person that made the contract with the shipper that has to deal with it.

This.

The merchant enters into a contract with the purchaser to supply the goods purchased.  The merchant then enters into a contract with the carrier to deliver it.

As I understand it, any assistance the carrier may provide to the purchaser is a courtesy.  Their obligation to deliver is with the merchant - and it is the merchant's obligation to the purchaser that delivery is made.

[metta]

Thanks for the confirmation everyone! I’ve opened up a PayPal case as a last resort - hopefully it’s a little more visible.

[Terry01]

I just ordered 1 today! Yikes!! 

[Simon]

I just ordered 1 today! Yikes!! 

Currently out of stock. I will have them in the UK as well when things get moving.

[Terry01]

I got mine delivered today. Ordered from Welectron and shipped the whole way by DHL. Pretty poor packing to be honest. The meter is fine and no bashes on the box so I take it it was handled well by the carriers, if it had taken a bump "en route" I doubt very much it would have survived. The fact it arrived unscathed was more down to luck than it being well packed.

Hey Ho!