I have been looking at the packet protocol document but as it seems to be missing a fair bit of information (It may be me not be reading it correctly) I decided to start making my own but as I don't have a blue tooth adapter on the PC I have been probing the UART interface to the BLE112 inside the meter with my logic analyser and have noticed a couple of quirks.
1. The Year value of the packet never changes no matter what is set on the meter.
2. The Month value of the packet never changes no matter what is set on the meter.
3. While decoding the Main LCD Range packet (7) I noticed that on AC and DC micro Watts the 2500.0uVA range appears to be repeated - this shows on both the meter display and the UART packet.
I am using V1.51 on my meter.
Jem
I think that when the upload of an EEVBlog.bin file is complete, it should be deleted. This would free up that space for meter logging functions. I can't think of a reason why to keep it there once the upload is done. A user would not have to go back into the meter to delete the file, assuming they are OCD about that. Then - as I prior recommended, the battery door can be screwed down before an upload is started.
What ever is causing the communications to slow down appears to be the 121GW's main firmware.
...
...
As a side note, I had changed the meter to Eneloop NiMH and had never charged it. The battery indicator never came on. Even after all of this testing. Finally it gave up last night. ...
It appears by the time version 10.0 rolled out, they had converted to a 19 byte, binary format. It's very similar to what we have today. They were still running at 250ms. It looks like the firmware, even with only 30% of the amount of data that had been sent, it was already starting to lag.
Firmware Version - Format, #Bytes in packet, Packet Rate, Timing Stable or does it lag
1.00 - ASCII, 56 Bytes, 250ms, Stable
1.05 - ASCII, 56 Bytes, 250ms, Stable
1.07 - ASCII, 56 Bytes, 250ms, Stable
1.10 - Binary, 19 Bytes, 250ms, Lags
Corrected version numbers
It appears by the time version 10.0 rolled out, they had converted to a 19 byte, binary format. It's very similar to what we have today. They were still running at 250ms. It looks like the firmware, even with only 30% of the amount of data that had been sent, it was already starting to lag.
Firmware Version - Format, #Bytes in packet, Packet Rate, Timing Stable or does it lag
1.00 - ASCII, 56 Bytes, 250ms, Stable
1.05 - ASCII, 56 Bytes, 250ms, Stable
1.07 - ASCII, 56 Bytes, 250ms, Stable
1.10 - Binary, 19 Bytes, 250ms, Lags
Corrected version numbers
Do you have some details about the test you performed, I'm writing a bug report but not really sure specifically what you've done. By lag do you mean the time between logging and the actual signal or the the sample rate is slower than expected slightly?
Forget the RF link for now. Just monitor the serial lines from the meter's MCU. You will find that the rate that the packets are sent will vary depending on the input signal. Depending on the version of firmware you install, the time between packets will be 500ms or 250ms. I have shown where this time can be seconds. This does not appear to be a problem with the older firmware. It appears the problem showed up in version 1.10 when the packet sized was reduced and the binary format was introduced.
I suspect the packet rate was slowed down even further after 1.10 in an attempt to resolve the lag between packets. However, in 1.00, they were sending almost 3X more data at the 250ms rate and not lagging.
I would think they could write the newer binary formatted, smaller packet like 1.51 uses at the same rate they write to the SD card and not lag.
Yes, I confirm these values of 0.022µA and 0.32mA @ FW 1.51.
With FW 1.26, it's 0.046µA and 0.06mA, though.
Maybe there's a systematic bug inside these modes.
Change was 'Amp range sensitivity improved'.. probably that causes this offset.
Frank
[Adder]: It makes no difference, whether probes are inserted, or not.
I'll look into this for you, I think we will be able to work it out.
Just so I don't have to redo your test (will be faster), do you have examples of the sampled UART data that show this (a screen shot or photo of the logic analyzer)? Something that shows the jitter between samples.
If you don't see this before 4pm I'll do the test myself but I figured I'd ask.
There are several posted on this thread. If you look at this picture for example, there are two different programs shown. The one in the upper left is using a FTDI TTL to USB adapter to sniff the serial line from the MCU. In this case, I am counting the number of times the the time between packets is longer than 800ms. The main program is looking at the data across the RF link. The yellow trace is also the number of times the packet spacing has exceeded 800ms. Note how the two track. Als note that the blue trace, showing the CRC failure rate is not effected.
It you would rather see the actual time, TEST2E is showing just that using different modes and signals applied. Again, in the 5V range with nothing attached to the meter, so the readout is basically all zeros, the packet spacing is very repeatable.
You could use a LA but I was wanting to capture more metrics. Actually, you could add some checks to your Windows application and check it on the RF receiver side like I was originally doing. Should be easy enough to replicate.
****
On TEST2E, the vertical axis is time in ms.
Very nice. Thanks for taking the time to dig into it.
I am playing around with a UNI-T meter using BLE as well. There is still a lot of work to do on it but there are some things that UNI-T does that UEI could leverage. One major difference is how the display data is sent. The 121GW has the data, sign bit, scaling... The UNI-T sends the data as a float. IMO this is much easier on the PC side of things.
They also embed a checksum and like the 121GW, it seems to be required but the error rate is much lower for what ever reason. They can update at 10Hz rather than 2Hz and are sending 55 Bytes. If anything, I would expect the CRC error rate to be higher on the UNI-T.
https://www.eevblog.com/forum/projects/uni-t-ut-d07a-bluetooth/
I was a little confused about what I was seeing when I was attempting to write a Labview app for the 121. Looking deeper into the BLE interface, if you fire up Wireshark you will find that the 121 sends a single packet for the start byte. It's a bit odd as the entire data structure could fit into a single packet but the 121 will send two. I suspect this may have been a carry over from the earlier structure.
It's too bad that the BLE112's serial interface was not routed to the MCU so you could field upgrade it with the firmware. It looks like you are stuck with what you have unless there is a newer release of the meter at some point.
I am back to 1.26 with the BLE112 image that was uploaded.
Did you try to see if you could still replicate the lag with the beta firmware like I showed?