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.
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).
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.
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.
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.
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.
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.
The firmware and packet DOES have a XOR based checksum at the end.
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.
We are looking into this improving the packet protocol.
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.
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.
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 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.
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.
Hi.
Is there any chance for new batch of 121GW ? I see that it is out of stock.
Thx.
Do you know if there is any channel / information source that I can subscribe to see when multimeters will be available ?
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.
Thx.
Do you know if there is any channel / information source that I can subscribe to see when multimeters will be available ?
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).