Should The EEVblog Meter Be Open Source?

[blacksheeplogic]

I don't know how it goes for hardware, but for software, I open source all my personal projects and I see a huge value in that. If software is of any interest, then you will be getting free contributions and functionality extensions.

I don't open source any of my work. It's like leading out my equipment, it's cost the user nothing so they don't take care of it.  If it's free the work that went into it is perceived as of no value.

My time is worth something, if someone came to me and offered their time towards the project no problem I would give them the code.

[EEVblog]

BTW, the other thing the manufacturer suggested is perhaps an NDA or signed license agreement type thing for the source code for those who want to play with it.

[BravoV]

BTW, the other thing the manufacturer suggested is perhaps an NDA or signed license agreement type thing for the source code for those who want to play with it.

Just a thought, once the meter is "rooted"  , there should be a "permanent" sign or notice that can easily spotted like at LCD when turned on for the 1st time.

Of course this feature can not be "easily" turned off by hacking / script kiddies. Although I'm not sure if this feature is feasible and economically to be implemented. 

As long it's easy to spot if the firmware had been altered by user, this may ease at Dave/manufacturer's side on supporting, like support/warranty will be gone once rooted, and also useful for 2nd hand market where people are starting to sell/buy used ones.

[amspire]

True open source is usually very hard for companies since they are probably using libraries from all over the place with different licenses. For GPL, they would have to get permission from the authors/copyright holders of every single library.

However, if they have an open API with something like embedded Lua language, with a powerful enough API, they could achieve essentially the same thing. The API would still leave the manufacturer in low level control over what is happening, and that might make them feel more comfortable. Lua would only needs something like 200Kbytes of ROM, and is under MIT license which is excellent for commercial manufacturers.

The trick would be to set up the API to be as general as possible and to have a license for the API that encourages other companies to use it. There are probably people in this forum that would probably jump at the chance to help document the API in really great way. Especially if they get the multimeter free for their efforts.

If you look at something like the Blender 3D interface, every button and control you see has an attached python script that calls underlying API commands. All these scripts can be easily edited and changed by a user, if they wish. If the multimeter had all the switched functions and display functions as Lua scripts, then all those script could be customised by end users. So a user could take, say, a standard DC voltage range and add to it extra averaging, standard deviation calculations, logging - whatever they can thing of.

This would also make it easy to have a "reset to factory" option to save people, and to also help in warranty situations.

No need for an assembler package and no need to open their source code.

Richard

[ataradov]

Just a thought, once the meter is "rooted"  ,

I think you are getting ahead of yourself. The biggest challenge here is to find people wanting to buy one, apart from people wanting to support Dave personally.

Why would anyone need another standard meter, especially if there is a tricky procedure for rooting.

In case of Rigol and Flir there is significant value to be gained. What can you "unlock" in a meter? The biggest mod I ever seen people do is to hack back light into a cheaper model. I see no evidence of demand for much more.

If it had graphical display, then possibilities are opening a little bit.

[EEVblog]

True open source is usually very hard for companies since they are probably using libraries from all over the place with different licenses. For GPL, they would have to get permission from the authors/copyright holders of every single library.
However, if they have an open API with something like embedded Lua language, with a powerful enough API, they could achieve essentially the same thing. The API would still leave the manufacturer in low level control over what is happening, and that might make them feel more comfortable. Lua would only needs something like 200Kbytes of ROM, and is under MIT license which is excellent for commercial manufacturers.

It's a hand held multimeter. Pretty sure the code is all custom.

[EEVblog]

I think you are getting ahead of yourself. The biggest challenge here is to find people wanting to buy one, apart from people wanting to support Dave personally.

So every meter manufacturer in the world shouldn't bother bringing out new models any more?

[ataradov]

So every meter manufacturer in the world shouldn't bother bringing out new models any more?

That's not what I'm saying.

If making meters and marketing them accordingly is something you want to do, then by all means. But thinking how open or closed source can affect anything at this point is a bit premature, IMO.

I guess I'm just missing the point of the original question. Open source is better than closed source all other things being equal, but I don't think it is a huge selling point.

[amspire]

It's a hand held multimeter. Pretty sure the code is all custom.

It could be, but they wouldn't rewrite the code completely for every multimeter. If they have re-used code libraries that are in all their multimeters, then when they open source this code, they are opening some of the code used in every other multimeter. It may be they do not want that. They are showing their libraries to every other multimeter manufacturer.

A thing I have often seen is a programmer needs to do something they haven't done before, and so they go to the web to find a code snippet that does the job. They put the snippet in their closed source product and no one knows. If you then try and make that source open, you have to find all code snippets like this that were pulled from other sources, track down the authors and ask for permission.

The API approach does mean it is much more accessible to an average user. If I want the meter to average over 10 seconds and return an extra digit or two - I could just edit a python script to increase averaging, and find a way to send the extra digit(s) somewhere - perhaps the secondary numeric display. Simple and quick- Windows Notepad, an RS232 connection and 5 minutes of time.

If I have to open up an assembler, spend a day working out what the obscure assembler does at least enough to add my changes, compile, and then completely rewrite the firmware with the risk I may brick the multimeter, I wouldn't bother.

[TiN]

BTW, the other thing the manufacturer suggested is perhaps an NDA or signed license agreement type thing...

Press that "No" button you have. Most of tinkerers who would otherwise play with the meter or adopt to their custom needs may not bother going thru hassle asking manufacturer (which likely will want to ask them questions, why you need firmware, what you want to do, etc-etc). It's also prevents easy sharing of "mods" and "tweaks" which otherwise could be popping up on forum here like mushrooms. Make it open and friendly (remember Red Pitaya hassle?) or don't open at all, I'd say.

It can go big if meter have decent hardware and PC interface (infrared, BT or otherwise) with readily provided API/code examples. Should not be hard to open a dedicated forum section "EEVBlog DMMxxx - tweaks and user mods" - and have all those young players posting all their stuff and their code for your meter there. I'm sure big guys would see this and be thinking "why we did not think of this years ago?". This works for smartphones obviously, there is large community posting custom OS images for their Droids of every manufacturer, you name it .

I'm seeing this kinda users even with bench DMMs, doing their own mods for their often 1K+$ units, given zero support, no firmware, often even no schematics at all. Or the scope haxors, which I'm sure you aware of. Or take other scale - usual PC gamers, who make their custom levels, mods, addons and such for favorite old games they like. Make it fun 

Even better if someone "forgot" on assembly line to remove handy SPI/I2C header from the meter's PCB, which allows to connect custom sensors to meter!

[bitwelder]

Yes, it would be an interesting to see an 'Arduino of multimeters': it has a certain set of basic functions when it comes out of the box, but if you want to hack it and make it into a specialized instrument, you at least have the possibility to try that.
In that sense, I hope this multimeter will be designed with an 'expansion port' (carrying I2C, SPI or whatever bus fits best) and e.g. BLE connectivity (and a decent API).

[Lightages]

It would be a great selling point to have it open source. I think it could be problematic for warranty purposes but there are ways to mitigate this. Make the source available by NDA and with an agreement that the warranty might be void if the firmware is changed. Control this by serial number. The problem is that the source will get leaked. So maybe have the firmware have a flag that changes with any update so that any meter sent in for warranty would be obvious whether the firmware was changed or not. Of course this is not a perfect solution neither......

[Fungus]

Schematic: Yes, of course.

Firmware: I say it depends on whether or not the screen is dot-matrix and whether you're doing it as a way of offloading the programming instead of doing it yourself.

A dot matrix screen gives a lot of possibilities.

Letting other people write the firmware makes sense if you don't enjoy that or don't have much free time. The worst possible thing would be to waste a lot of time writing some firmware that's instantly replaced by everybody who buys the meter.

[Fungus]

It would be a great selling point to have it open source. I think it could be problematic for warranty purposes but there are ways to mitigate this. Make the source available by NDA and with an agreement that the warranty might be void if the firmware is changed. Control this by serial number. The problem is that the source will get leaked. So maybe have the firmware have a flag that changes with any update so that any meter sent in for warranty would be obvious whether the firmware was changed or not. Of course this is not a perfect solution neither......

I'm not sure how firmware could blow the circuitry of a multimeter. It won't be able to switch out the input protection or anything like that.

[bson]

It would be even cooler to open source if it were a bench instrument that can be expanded with custom acquisition boards and firmware!  For example, make multiple units potential operate in a master-slave mode to make multiple time-synchronized measurements, controlled from and stored onto a microSD card on the master.

It is not that. Handheld meter.

Oh I know, I was just dreaming!

[IanJ]

Re: Should The EEVblog Meter Be Open Source?

If in doubt then don't do it......I guess you can always change your mind later when you see how sales go.

Ian.

[Lightages]

It would be a great selling point to have it open source. I think it could be problematic for warranty purposes but there are ways to mitigate this. Make the source available by NDA and with an agreement that the warranty might be void if the firmware is changed. Control this by serial number. The problem is that the source will get leaked. So maybe have the firmware have a flag that changes with any update so that any meter sent in for warranty would be obvious whether the firmware was changed or not. Of course this is not a perfect solution neither......

I'm not sure how firmware could blow the circuitry of a multimeter. It won't be able to switch out the input protection or anything like that.

Without knowing how the multimeter works at the very least someone might be able to brick their meter.

[EEVblog]

If I have to open up an assembler, spend a day working out what the obscure assembler does at least enough to add my changes, compile, and then completely rewrite the firmware with the risk I may brick the multimeter, I wouldn't bother.

It's written in C

[EEVblog]

If in doubt then don't do it......I guess you can always change your mind later when you see how sales go.

True.

[EEVblog]

Schematic: Yes, of course.
Firmware: I say it depends on whether or not the screen is dot-matrix and whether you're doing it as a way of offloading the programming instead of doing it yourself.
A dot matrix screen gives a lot of possibilities.

Nope, dual 7 segment.

The idea is that people can tweak the meter to do what they want.

[pickle9000]

I would love to see open source firmware for a meter. Could be a real thing, dumbed down meters for custom applications. Super good idea.

[Fungus]

Without knowing how the multimeter works at the very least someone might be able to brick their meter.

If it uses a bootloader-style programming interface then it shouldn't be brickable - look at how many idiots^Wpeople upload programs to Arduinos all day long without bricking them.

[Fungus]

Schematic: Yes, of course.
Firmware: I say it depends on whether or not the screen is dot-matrix and whether you're doing it as a way of offloading the programming instead of doing it yourself.
A dot matrix screen gives a lot of possibilities.

Nope, dual 7 segment.

The idea is that people can tweak the meter to do what they want.

That kinda limits how much value people could really add over decent stock firmware.

It would be nice for people to be able to update the first firmwares, sure, but after a couple of months it would be "finished" and not much point in changing anything else. Maybe somebody would reprogram it to play a crap version of Frogger, but... 

I guess it comes down to how much effort it would take to document it and provide the programming tools.

(I know - a hack to turn the display upside down for people who live in the northern hemisphere!)

[bktemp]

I don't see any benefit in making a handheld multimeter open source:
The functionality is limited by the chipset used and the hardware in the device, therefore it is impossible to add many new features in software unless the necessary hardware is already on the pcb (like flash memory for data logging or IR transceiver for communication). Adding new hardware in a handheld multimeter is pretty much impossible because of the restricted space.

If it would be a benchtop multimeter with a large graphical display and room in its case for own extensions (like bluetooth or wifi) it would be a completely different story, but for a handheld multimeter I think open source is useless.

[han]

Open source for Ordinary DMM = NO.
But for niche app like interval data loging, custom sensor metering,.. an DMM with open source HW/SW is very promising.