I'm not familiar with the limitations of BLE
Think "1980s modems". Single-digit kBits/sec.
(and will joe make a machine to test that..)Joe is busy developing a machine to test the VA function of the meter with 121 GW
I'm not familiar with the limitations of BLE
Think "1980s modems". Single-digit kBits/sec.Are you exaggerating or actually quoting some design specification? SiLabs states tested transfer rates up to 8 kBytes/s using the minimum connection interval and maximum packet size.
That should allow smaller logs to be transferred within a few seconds, certainly a useful feature to have.
I'm not familiar with the limitations of BLE
Think "1980s modems". Single-digit kBits/sec.Are you exaggerating or actually quoting some design specification? SiLabs states tested transfer rates up to 8 kBytes/s using the minimum connection interval and maximum packet size.
Ooops! Brain fart, I meant kBytes.
But yeah, not fast, nowhere near ordinary Bluetooth.That should allow smaller logs to be transferred within a few seconds, certainly a useful feature to have.Maybe a future firmware feature?
I have the source code and can compile if needed (have not tried it).
QuoteDave/David - what is the transfer rate for log data over Bluetooth ?About once a second as you see in the video.
You may well not be doing it all the time, but on the occasions you do need it, it's quite likely you will be doing multiple logging sessions, looking at results, doing another session etc., so having to swap the card could be a bit of a pain. Apart from safety, is there any ergonomic downside to running ith the cover off ? Are the screws self-tap or in inserts ?
I'm not familiar with the limitations of BLE - maybe instead of downloading the whole, log, some way of browsing it over BLE might be useful as you are often looking for particular events or at a particular time.
I've asked that a few times in various threads and I saw other's asking similar questions during the live feed. For what ever the reason, they have gone unanswered. Personally, I am not sure why it was brought up in the first place if discussing it was off limits. With as many meters being released, I'm sure there will be countless reviews of it. If there are problems with the hardware, I'm sure you will start hearing about them over the next several months.
I am a little confused by this, if it's got a "Hackable ST ARM Cortex M3 processor" but no firmware source code, is it really any different from most other equipment out there?
It's not great if we literately have to hack it to make changes. (decompile, figure out the mess, inject new instructions, etc...)
I see this as a great meter that is customisable for more niche applications, particularly with the SD and Bluetooth it has a range of possibilities that aren't possible with most other things.
But if those functions aren't tweakable without lots of mucking around then it gets very difficult.
The community could write replacement firmware of course however that would be a lot of duplicated work and I'd be concerned about safeguards not being in place, potentially causing damage to the meter with the wrong combination of registers and also the calibration data not being usable.
About the decompiling, that would only be possible if the manufacturer did not enable write protection.
FWIW, my prediction is Dave sells 1842 DMMs in the Kickstarter campaign.He already sold 1268 in 22 hours. IMO it will be at least 5k.
Nope, not a chance. I'll be surprised if it even gets to 2k.
I have blown my wad on marketing, unless I want to keep hammering it, but that will only pick up the stragglers.
How accessible is it ? I thought it was behind the screwed-down fuse cover.
It is.
It takes less than 20 seconds to remove the holster, undo two screws (metal threaded insert), remove the battery cover and take out the SD card.
Yes, I timed it.
Hardly a chore for anyone who wants to do occasional data logging. And as I said, faster than dicking around with Bluetooth BLE and a ridiculously slow data rate.
If you are doing data logging all the time, I'd recommend buying a proper data logger with the convenient interface of your choice.You may well not be doing it all the time, but on the occasions you do need it, it's quite likely you will be doing multiple logging sessions, looking at results, doing another session etc., so having to swap the card could be a bit of a pain. Apart from safety, is there any ergonomic downside to running ith the cover off ? Are the screws self-tap or in inserts ?
I'm not familiar with the limitations of BLE - maybe instead of downloading the whole, log, some way of browsing it over BLE might be useful as you are often looking for particular events or at a particular time.
Dave
On the Amp Hour you mention you wanted to make a last minute hardware change (albeit fairly minor), but was faced with the fact that 2000 boards had already been printed, and a cost that could not be absorbed. For this reason you were going to hold back, and maybe amend the board in a subsequent board spin. Are you planning to do this between the first Dec batch, and the April batch, using the delay as a chance to make the change? On the same note, what happens if/when there is a hardware change, and there are potentially different board revisions, with regards to firmware updates. Will updates need to be board revision specific?
I've asked that a few times in various threads and I saw other's asking similar questions during the live feed. For what ever the reason, they have gone unanswered. Personally, I am not sure why it was brought up in the first place if discussing it was off limits.
You may well not be doing it all the time, but on the occasions you do need it, it's quite likely you will be doing multiple logging sessions, looking at results, doing another session etc., so having to swap the card could be a bit of a pain. Apart from safety, is there any ergonomic downside to running ith the cover off ? Are the screws self-tap or in inserts ?
I'm not familiar with the limitations of BLE - maybe instead of downloading the whole, log, some way of browsing it over BLE might be useful as you are often looking for particular events or at a particular time.
He said metal-threaded inserts. If they are not captive, probably worth putting some small o-rings or similar on them so they don't get lost.
Downloading logs over BLE is certainly possible, just going to be a lot of effort firmware wise. I have a months worth of data logged here thats 16MB. So a day would be much less than 500kB. At 5-10kB/s transfer rate (possible with android but not IOS), it would take ~1min to transfer.
If you are doing multiple sessions, probably worth purchasing another tool (or trying the wifi SD posted, that was a good idea). But certainly there is a small market opportunity here for dave or the manufacturer to replace the BLE module with an ESP32 (was discussed before), and maybe a dot matrix display, cost could double.
I have the source code and can compile if needed (have not tried it).
I am a little confused by this, if it's got a "Hackable ST ARM Cortex M3 processor" but no firmware source code, is it really any different from most other equipment out there?
It's not great if we literately have to hack it to make changes. (decompile, figure out the mess, inject new instructions, etc...)
The community could write replacement firmware of course however that would be a lot of duplicated work and I'd be concerned about safeguards not being in place, potentially causing damage to the meter with the wrong combination of registers and also the calibration data not being usable.
This appears to be a pretty common data sampling rate for many handheld meters that I have worked with recently (via BLE, serial, USB) that are not specialized data logging meters. In fact many meters don't provide any configurable rate, they just broadcast the current reading about once per second when connected.
I have the source code and can compile if needed (have not tried it).
I am a little confused by this, if it's got a "Hackable ST ARM Cortex M3 processor" but no firmware source code, is it really any different from most other equipment out there?
It's not great if we literately have to hack it to make changes. (decompile, figure out the mess, inject new instructions, etc...)
Well, I guess you aren't wrong. What was meant by that term is that there is a header inside to do this, and the schematic is open.QuoteThe community could write replacement firmware of course however that would be a lot of duplicated work and I'd be concerned about safeguards not being in place, potentially causing damage to the meter with the wrong combination of registers and also the calibration data not being usable.
I'll talk to them and see what we can release.
I don’t think it matter if you don’t have an andriod phone that supports BLE at all.
Andriod was late to release BLE stacks, so you have to have andriod 4.3 or higher from what I was reading.
And the chipset that supports it also, I think this is 4.0.
Unlike iOS Apple devices that have supported Bluetooth BLE for a much longer time.
So I own 4 andriod devices, 2 phones, 2 tablets. And a common problem with andriod is the cellular or phone manufacturer is responsible for the andriod updates. Well 3 of these 4 I own are Samsung, and I just checked them all despite 2 of them having the proper Bluetooth hardware Samsung never released the version of andriod for BLE to work correctly. They are all running 4.2.? or lower and won’t support the BLE blutooth stack.
A lot of people with older andriod phones might be surprised when they can’t conect to the phone they own or update andriod (without needing to root it) to work with the hardware that supports it built into the phone they already own. They will probably blame the meter, so be ready for this.
As far as open source goes, I am happy that the firmware can be upgraded, I am happy trusting Dave and UEI to get the meter running solidly, and I think it is great the Bluetooth App is fully open source.
If I am thinking about how to conveniently get extra functionality or flexibility from the meter, I probably can do more with an Android App then by modifying the multimeter code.
For example, if I had a calibrated 10V standard reference and 10 experimental references I am testing, I could use an Android App to switch the meter between the 10 tested references, measure the voltage difference between the standard voltage and the current device-under-test to 1uV. If I had to have more than 1 reading/sec, I could later correlate the Bluetooth captured data and the microSD logged data using time stamps. Hopefully logging and Bluetooth can run at the same time.
Is there going to be a document defining the available Bluetooth commands? For example, can we get the DC component, the AC component, multimeter temperature and multimeter time for a reading concurrently?
If the Bluetooth is once per second and the meter is faster - say 10 times per second - is the Bluetooth output the average of those 10 readings?
Really great job!
Richard.
I can think of two main reasons for not releasing.
1: commercial/IP reasons.
2: compliance issues with FCC part 15 & RED.
If it is the second, and your supplier has no problems with it, then somebody could always 'accidentally misplace' files on a server ;-). This way from a compliance point of view the manufacturer can still maintain that the product does not officiallly support 'alternative' firmwares.
...
Is there going to be a document defining the available Bluetooth commands? For example, can we get the DC component, the AC component, multimeter temperature and multimeter time for a reading concurrently?
...As mentioned in the Kickstarter, the Bluetooth protocol is fully documented, not sure if it's published on Dave2's GitLab yet.
Regarding the update rate, they should ideally add configurable transmission intervals. Not sure what UEi would have against doing that.
In fact, it would be quite nice to have the ability to configure all multimeter options using a text file on the SD card.
I guess you need the free version of Xamarin as well. https://www.xamarin.com
I can think of two main reasons for not releasing.
1: commercial/IP reasons.
2: compliance issues with FCC part 15 & RED.Another possible :
3: not wanting to reveal poorly written codeQuoteIf it is the second, and your supplier has no problems with it, then somebody could always 'accidentally misplace' files on a server ;-). This way from a compliance point of view the manufacturer can still maintain that the product does not officiallly support 'alternative' firmwares.Seems unlikely that firmware on a product like this could affect EMC performance, and radio stuff is all in the BLE module so that shouldn't be an issue.
Are there any parts of the IEC test equipment standards that can be affected by software (e.g. showing wrong results/ failing to show overvoltage conditions)?
I think it was discussed a while ago but before FW was finished - it would be useful if the bootloader gave some clear indication that "non-stock" firmware was loaded. Did this get implemented?
Even if not released officially I'd be surprised if it didn't get reversed by someone anyway...
Since I never order from outside of europe usually, I do have to expect VAT and customs charges, right? Some 20% on top of the 290AUD in Germany I guess?
To import electronics from outside the EU you need to pay customs duty and value-added tax on values above 150€. (VAT always applies for values above ca. 23€)
I do not know the exact percentage for this kind of measurement devices but my guess is something like 3.7%.
Number crunching:
121GW incl. shipping ca. 188€*
+ import duties 6.96€
= 194.96€
+ VAT 37.04€
Total 232€
*plus additional handling fee for credit card usage, this is not tax relevant however
Edit: That totals to around AU$ 367 incl. taxes and 2% handling fees