Should The EEVblog Meter Be Open Source?

[apelly]

The Chinese will copy it badly.

Only if it actually adds value over most of the meters on the market.

Fair point.

Depends, do you want to deal with the whiny osh crowd complaining about file formats, software libraries and such?

The OSH crowd may be pedants, but you've clearly missed the self-entitlement of the other crowd if you think there's smooth sailing ahead.

I don't open source any of my work.

I don't open source much of my work either.

I open source all of my play however. You think you're so clever someone gives a shit about your software and they'll steal it? Give me a break.

It's like leading out my equipment, it's cost the user nothing so they don't take care of it.

It's nothing like that. It couldn't be further from that. What are you thinking?

If it's free the work that went into it is perceived as of no value.

Most of the time that perception is right. Occasionally someone might help with a bug report, feedback, a patch. These things do have value to you and don't impart any obligation. That's kind of amazing isn't it? That, right there, is a free lunch.

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.

My time's worth something too. I wouldn't waste it dicking around with a fence sitter.

[mikeselectricstuff]

It would be nice, and allow some user customisation, but not a huge deal. There is the issue of warranty. certifications etc. ( do safety certs cover things like showing an erroneous low reading?).

This could easily be addressed as follows :
Manufacturer updates can be done without opening the cover, using signed code.
If you want to load your own code, you have to open the case (e.g. to solder-blob a link on the PCB), breaking a warranty seal.
Or at least have some sort of irreversable software function to enable loading other code.

Thinking about it, maybe a secure bootloader is the answer here  - the bootloader is not open sourced, and protected ( most MCUs have mechanisms for this). It will only load signed code, unless you do some special action, which then allows it to load unsigned code.

It would also be possible to reload a manufacturer update to return it to a 'factory' state

The bootloader would show some clear indication at power-up to flag that it is running non-factory code.

If the company believes that not open sourcing will protect against copying, they should also believe that the combination of a secure loader and OS application software will achieve the same thing.
 
If nothing else the "Open Source" label with undoubtedly get you some free publicity (though you will also get the more religious factions whinging that it's not "OS enough", but there's no pleasing some people!).

the NDA thing is stupid - nobody will be interested, except maybe someone who will do it and then allow it to "escape"


 

[timgiles]

Prehaps I should change my vote!

In relation to whether I would purchase the meter, the Open Source nature of it makes little difference, so I voted as such.

Would it be preferred - yes. Why? Well, if it is going to be an EEVBlog meter, then surely it should be built on the foundations of the EEVBlog. Namely, dont turn it on, take it apart. So the more available and open the product, the more fully meter reflects its heritage. While this starts with the schematic, opening the firmware helps enormously. It might also mean that fixes can be suggested by the community, improvements etc...

[EEVblog]

If the company believes that not open sourcing will protect against copying, they should also believe that the combination of a secure loader and OS application software will achieve the same thing.

If nothing else the "Open Source" label with undoubtedly get you some free publicity

Quite a lot I suspect, it's main benefit.

(though you will also get the more religious factions whinging that it's not "OS enough", but there's no pleasing some people!).

Death, taxes, and people whinging about open source details.

[EEVblog]

Prehaps I should change my vote!
In relation to whether I would purchase the meter, the Open Source nature of it makes little difference, so I voted as such.

Yes, I think I worded the poll wrong. The answer will be obviously fairly biased.
Maybe I'll start another one - "Would an Open Source EEVblog meter be of benefit to you (or make you want to buy it)"
I might edit this one and reset the stats?

Would it be preferred - yes. Why? Well, if it is going to be an EEVBlog meter, then surely it should be built on the foundations of the EEVBlog. Namely, dont turn it on, take it apart. So the more available and open the product, the more fully meter reflects its heritage. While this starts with the schematic, opening the firmware helps enormously. It might also mean that fixes can be suggested by the community, improvements etc...

It's possible to just release the schematic and then maybe provide some libraries like custom LCD driver, chipset driver  etc.

[stmdude]

Yup, I'd be interested, but I don't think I would care about the "Open Source" part of it.

If I wanted to mess around with the meter, the first thing I would want is accessable ISP pins, to recover from my own issues. Also, a way to restore the original firmware.
After that, I'd want to be able to find the datasheets for things like LCDs and other special chips in use (ADCs, etc).

Lastly, some rudimentary schematic (doesn't need to be complete) that shows me what's hooked up to which pins on the MCU.

Once I have all that (I could even figure out the schematics on my own), there's nothing stopping me...

Then again, I've got some experience with bringing up stuff, so I might not be the average target audience.
However, only _one_ person outside of the OEM needs to do this, and share with the others.

This could be an easier sell to the OEM than giving away their code.

[EEVblog]

Yup, I'd be interested, but I don't think I would care about the "Open Source" part of it.
If I wanted to mess around with the meter, the first thing I would want is accessable ISP pins, to recover from my own issues. Also, a way to restore the original firmware.
After that, I'd want to be able to find the datasheets for things like LCDs and other special chips in use (ADCs, etc).

Standard Microchip ICSP header is there.

Then again, I've got some experience with bringing up stuff, so I might not be the average target audience.
However, only _one_ person outside of the OEM needs to do this, and share with the others.

Yes. I suspect someone would do it anyway once they see the ISCP header.

This could be an easier sell to the OEM than giving away their code.

I would be a much easier sell.
I'm kind of liking the idea of schematic + drivers + an info page with datasheets etc.

[obiwanjacobi]

Add a prototyping area on the pcb 

[technix]

You can open source the hardware with nice doumentation but keep the software closed source. Opening the hardware or not does not impede cloners but as you have pointed out opening the hardware will allow easier enforcement of some license terms on them. Software, especially libraries can fall under proprietary license terms and hence unsuitable for releasing. So just release the hardware and documentation for the software can be enough. The community can cook up their own software based on exclusively open source tools and libraries. Just don't implement any form of DRM that prevents the community to load an alternative firmware onto it.

Or you can release some code without triggering NDA, by releasing the NDA-covered parts through binary blobs (that is, proprietary-licensed libraries that have an open and well documented interface, as well as allowing free usage of the libraries.) Linux kernel currently does this, while the bulk of the kernel is free and open source some drivers comes with blobs.

About UL, you can have a clear warning on the documentation that the certifications only applies to meters when using with official firmware: custom firmware = use at your own risk.

[nctnico]

I voted yes. If the microcontroller is easy to program with freely available tools it could open up the possibility to add new features or fix things which aren't so well implemented. It all comes down to how much room there is left in the microcontroller, how well the initial firmware is written and how well documented & flexible the hardware really is. I'd expect that the open source firmware will end up being a complete rewrite of the original firmware quickly.

[mikeselectricstuff]

I would be a much easier sell.
I'm kind of liking the idea of schematic + drivers + an info page with datasheets etc.

The problem with that is it greatly reduces the usefulness of open-sourcing it - I think the most likley thing people will want to do is make minor tweaks and mods , not rewriting the whole thing from scratch.

[joeqsmith]

Schematic - YES
Document any interface it has for logging - YES
If logging, provide source for communications - YES
Document alignment procedure - YES
Well written manual - YES

Parts placement / Layout - Maybe
Mechanical parts 3D files - No interest
Source code for the meter itself - Can't see a need as long as the code supplied is solid

I guess that's a depends.

[EEVblog]

I would be a much easier sell.
I'm kind of liking the idea of schematic + drivers + an info page with datasheets etc.

The problem with that is it greatly reduces the usefulness of open-sourcing it - I think the most likley thing people will want to do is make minor tweaks and mods , not rewriting the whole thing from scratch.

Well it's not really open sourcing it. It's closed source, but some helpful technical details are provided so that people can do their own thing if they really want.

[madires]

I would be a much easier sell.
I'm kind of liking the idea of schematic + drivers + an info page with datasheets etc.

The problem with that is it greatly reduces the usefulness of open-sourcing it - I think the most likley thing people will want to do is make minor tweaks and mods , not rewriting the whole thing from scratch.

Yup, the reason for buying an open source DMM is to be able to add some odd features I need or which would simplify my measuring tasks, like automation (especially with a Bluetooth interface available). Automation is a feature which you get only with expensive bench multimeters. I think an open source DMM could be a niche product for this kind of application, mainly for the hobbyist and the maker crowd.

[Fungus]

Yup, the reason for buying an open source DMM is to be able to add some odd features I need or which would simplify my measuring tasks, like automation (especially with a Bluetooth interface available). Automation is a feature which you get only with expensive bench multimeters. I think an open source DMM could be a niche product for this kind of application, mainly for the hobbyist and the maker crowd.

I don't see why this would/should solve that problem. There's dozens of programmable open-source Bluetooth/USB/RS232 data acquisition boards out there (Arduino based or otherwise).

[AF6LJ]

I always say Yes to open source, because in the end it works to the user's advantage.
Does it justify the extra work the manufacturer has to do? I don't know.

Depending on who the meter is marketed to would determine the value of making it open source. If you could get SparkFun to carry it and market as an open source meter you  might pick up some sales there. Maybe get it in the Hack A Day store also.

[madires]

I don't see why this would/should solve that problem. There's dozens of programmable open-source Bluetooth/USB/RS232 data acquisition boards out there (Arduino based or otherwise).

What about ranges, input protection or isolation (USB/RS232)?

[bktemp]

I don't see why this would/should solve that problem. There's dozens of programmable open-source Bluetooth/USB/RS232 data acquisition boards out there (Arduino based or otherwise).

What about ranges, input protection or isolation (USB/RS232)?

How do you get a BT module or USB/RS232 into a handheld multimeter without breaking the isolation? I doubt it will be possible to add such features unless Dave integrates it into the hardware.

[EEVblog]

How do you get a BT module or USB/RS232 into a handheld multimeter without breaking the isolation?

Bluetooth is wireless, so pretty good isolation 

[BradC]

Source would be nice, but I'd just buy it if it came with a Schematic. My 20 odd year protek 506 came with a full schematic that has been used A number of times over the last 20 years. The meter is getting long in the tooth now. If I could get a replacement that came with a set of documents ( and source would be gravy ), I'd buy 2.
Having said that, I use the thermocouple and 20A shunt a lot, so it'd need those too

[bktemp]

How do you get a BT module or USB/RS232 into a handheld multimeter without breaking the isolation?

Bluetooth is wireless, so pretty good isolation 

But you still need a BT module inside the multimeter.
My point is: You have to add a lot of additional hardware or at least unpopulated places on the pcb to allow for all the expansions. Otherwise it is impossible to add BT, IR or any other communication to a handheld multimeter. And that makes the DMM probably more expensive and larger.
If you want to design an open source multimeter, why not make it benchtop? A benchtop multimeter can be much larger and nobody cares. Here you can add a lot of spare connectors for expansions. And because most benchtop multimeters internally use an isolation between the frontend and the digital section, it is safe to make modifications to the digital part without touching the sensitive analogue section.

[ChunkyPastaSauce]

Open sourced firmware and easily accessible programming/debug interface would be awwweeessssoomeee and fun

[jolshefsky]

My first thought was "don't care". But then reading the responses, I decided to say "yes".

Basically, I don't want another multimeter. But if I had one that I was able to tweak, then I might be inclined. I could see reason to do things like make a rolling-average function, or tweak the autorange trips/limit autoranges. Or maybe add a transistor checker!

"Open source" conjures the same anxiety as people who talk of the utopia of anarchy: I say, "ok, so how would that work ... you know, REALLY?" The goal of open source (as I mistakenly see it) is to have this non-discriminatory mix of people providing input and making improvements. Yet without a benevolent dictator/dictators, it runs afoul of lousy code and runaway design (if you can even call it "design"). Then there's the issue of version control which is fairly mature for computer code. But for any kind of CAD (mechanical, schematics, layout, etc.) it might be available in big commercial packages like Altium, although my "system" of KiCAD and CVS just ain't gonna cut it with multiple users.

Nonetheless, just having access to the code and schematics would be enough to make it useful to the hobbyist or to someone with a specialized need. Whether that person bothers to release that code (also open source) isn't really relevant (or, IMHO, likely.)

[EEVblog]

But you still need a BT module inside the multimeter.

Good thing it already has one 

[zapta]

Dave, if you open source the firmware, you want to have a clear indication that the device doesn't run the official firmware. Similar to the unlocked sign that an unlocked Android shows on boot. This will help you with support and warranty and will help users to adjust their trust in the readings. Kind of "we are not responsible anymore to displayed values".

Also, think about the safety and certification issue. Can a firmware change can make the device less safe in any way or cause it to no pass safety certification? For example, if the modified firmware has arithmetic overflow and 220V is displayed as 1mv.

The event of crossing from stock and supported configuration to an aftermarket hacking mode should be clear with well understood implications.

Anyway, being open source will be a great selling point if your market are hackers/makers. It will give you great exposure and good will as somebody that is part of the community.