Should The EEVblog Meter Be Open Source?

[Fungus]

Standard Microchip ICSP header is there.

I was already affraid it would contain a PIC. Don't bother open sourcing it because the required tools aren't available for free.

I was a bit worried about that too, I know Dave is a PIC fan. I forgot about the expensive PIC compilers and development kits though.

Should really have used AVR these days. Oh, well.

(this thread can now devolve into a PIC vs AVR flamefest)

[stmdude]

Standard Microchip ICSP header is there.

I was already affraid it would contain a PIC. Don't bother open sourcing it because the required tools aren't available for free.

I was a bit worried about that too, I know Dave is a PIC fan. I forgot about the expensive PIC compilers and development kits though.

Should really have used AVR these days. Oh, well.

(this thread can now devolve into a PIC vs AVR flamefest)

Yea, I'm not a big fan of the whole PIC thing either. Ancient technology, that's not only small in CPU and RAM/Flash, but also very expensive for what they are.
But. It's Daves product. He calls the shots, and I'm hoping there's more behind the decision than "I know PICs, so that's what we should use".

Either way. Hopefully it's hackable with decent schematics. If so, I might even consider making a replacement board (if physically possible) that has an MCU that I like.  I'd re-use Daves/OEMs design for the analog stuff, because I truly suck at analog, and anything beyond 5V gets me nervous.

Hmm. I wonder if Dave would consider selling just the empty cases with LCD, buttons/switches or whatever is on it ?

[Fungus]

But. It's Daves product. He calls the shots, and I'm hoping there's more behind the decision than "I know PICs, so that's what we should use".

I think PICs are slightly cheaper than AVRs for equivalent features, but ... as noted: The compilers are proprietary/expensive/crappy and AVR has far more online momentum these days.

PICs were king 15 years ago (when Dave learned?) but not any more. You'll not see many youngsters using them.

[stmdude]

I think PICs are slightly cheaper than AVRs for equivalent features, but ... as noted: The compilers are proprietary/expensive/crappy and AVR has far more online momentum these days.

Yep, I think the AVRs would be even more expensive. I was thinking more along the lines of a Cortex-M based MCU.
Free tools and cheap chips with tons of peripherals built in.

Edit: I'm still very psyched about the meter though. I can't wait to see what Dave cooked up, and what would set this meter apart from others. I'll probably buy one just to take apart, unless Dave beats me to it. 

[Dielectric]

Going with "Hackable", some STL files or equivalent of the case would be cool to have so we can make custom mounts and stuff.  I could import the STL of the meter and do a "subtract" to make a nice fitting pocket then print some kind of funky stand or mount on my 3D Printer.  No need to have the original mechanical design files that include the internal bosses, etc. 

[EI6JA]

If the schematic and alignment procedure were  available, it would  be great.  Perhaps  a feature  for  a user calibration with just a single voltage reference, for example I have a reference that is 4.987 volts can I tell the meter this is my reference and work out the corrections from this.  Full open source would not intrest me but ability to repair and calibration would be a big plus in my book.

[Fungus]

Yep, I think the AVRs would be even more expensive. I was thinking more along the lines of a Cortex-M based MCU.
Free tools and cheap chips with tons of peripherals built in.

I'm thinking more along the lines of the way the Arduino Leonardo works: You can upload firmware via. a USB cable and afterwards the exact same cable transforms into an RS232 port for data logging, etc. No ICSP/JTAG/JLink programmer needed.

I'd definitely go down that route if I were using "user programmable" as a selling point.

AVR makes it very easy to do that and all the bootloader code is freely available. I believe ARM could do it, too. You'd have to weigh the $1 saved on the ARM CPU against the extra complexity of getting it all working. The $1 might not be worth it in real terms (especially if there's a $20 ADC in there or whatever).

(I assume the extra processing power and RAM of an ARM vs. AVR isn't really a factor for a multimeter).

Edit: I'm still very psyched about the meter though. I can't wait to see what Dave cooked up, and what would set this meter apart from others. I'll probably buy one just to take apart, unless Dave beats me to it.

Yes, it will be interesting to see the features and final selling price. What can a bunch of enthusiasts come up with compared to the big boys? Competing directly in "multimeter" world seems silly, it's hard to imagine they can produce Fluke quality at Uni-T prices. The manufacturing setup cost is too high for the volumes they're likely to sell.

Nope, I'm imagining more of a cross between a bench meter and a handheld meter. Something designed as a useful lab instrument rather than something to throw in a toolbox, eg. like that temperature logger from last week's mailbag (EEVBLOG#872).

Then again, Dave said it's it's a 7-segment display, not dot matrix. I'd want dot-matrix in something like that.

Time will tell... 

[Kilrah]

Although few people would actually mod the code, if someone did a really useful mod, quite a few more may use it.

Exactly, that's the point. It only takes ONE guy to come up with a good idea and implement it for it to be worth it for all the others.

People like the idea of open source hardware more than they will actually ever take advantage of it.

In the line of products I work for with our open source software there are an estimated 100k users, and we are currently 3 developers. We only gained one from the jump from 1k users to 100k.
BUT, the 100k are nevertheless happy about the open source "idea" because even if they don't participate at all, or "only" through feature suggestions and bug reports they've seen that they actually take advantage of it a lot, through what they gain in the form of new features, things that nobody else would bother implementing for them, and fixes that would take months to be taken care of if ever without it.

The lack of marketing-driven artificial crippling is the one thing that makes a huge difference too. In that field the whole open source thing has kicked the well established players quite hard and is with no doubt getting them to start doing something again instead of sitting on their laurels, which is good for everybody.

The software for a multimeter has more limited expandability, but still someone might come up with something awesome that nobody has thought about before, and just that would make it worth it.

Hardware wise I'd also be for a dot matrix display.

[Poe]

Open sourcing does really enable clones, they will happen regardless.
In fact, open sourcing under a suitable license can protect the company, because it legally forces any company to that uses the code or schematic to also open source their product and improvements.

Agree that OSHW enables clones. 

At least once a month, companies which otherwise couldn't justify a ground-up design, come to us with what suspiciously looks like someone's OSHW project (copy/paste) asking for an engineering quote to "just make some small changes and polish it off".

In regard to your second sentence.... You're only talking about software, correct?  Obviously that doesn't apply to hardware.

How would this EEVblog meter compare to the Mooshimeter or Voltset?  Those are nice because the bits you never need to change (hardware/firmware that just ships out readings) don't.    All the fun stuff you'd like to change is just app programming.

The first opensource multimeter I ran accross was this thing:  http://www.seeedstudio.com/depot/bluetooth-multimeter-p-1535.html

[mikeselectricstuff]

But. It's Daves product. He calls the shots, and I'm hoping there's more behind the decision than "I know PICs, so that's what we should use".

I think PICs are slightly cheaper than AVRs for equivalent features, but ... as noted: The compilers are proprietary/expensive/crappy and AVR has far more online momentum these days.

PICs were king 15 years ago (when Dave learned?) but not any more. You'll not see many youngsters using them.

So that would be why Microchip bought  Atmel, not the other way round then ?

[mikeselectricstuff]

Hardware wise I'd also be for a dot matrix display.

a full matrix has major downsides ( contrast, power), but a small matrix section at a sensible mux rate to show menu stuff more legibly than trying to do it on 7-segs would be a useful compromise.

[Zero999]

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.

Anything like an unlocked sign can be hacked  and I don't see how malfunction due to modification of the firmware can put Dave at risk. It should be easy to prove whether it's running the original firmware or not and if the customer modifies it, causing it to mess up, it's their problem.

Open sourcing does really enable clones, they will happen regardless.
In fact, open sourcing under a suitable license can protect the company, because it legally forces any company to that uses the code or schematic to also open source their product and improvements.

Agree that OSHW enables clones. 

At least once a month, companies which otherwise couldn't justify a ground-up design, come to us with what suspiciously looks like someone's OSHW project (copy/paste) asking for an engineering quote to "just make some small changes and polish it off".

In regard to your second sentence.... You're only talking about software, correct?  Obviously that doesn't apply to hardware.

How would this EEVblog meter compare to the Mooshimeter or Voltset?  Those are nice because the bits you never need to change (hardware/firmware that just ships out readings) don't.    All the fun stuff you'd like to change is just app programming.

The first opensource multimeter I ran accross was this thing:  http://www.seeedstudio.com/depot/bluetooth-multimeter-p-1535.html

Clones aren't a problem. Register a trademark which only the original product can have. That way the customer can distinguish between the real thing and a copy.

[Fungus]

PICs were king 15 years ago (when Dave learned?) but not any more. You'll not see many youngsters using them.

So that would be why Microchip bought  Atmel, not the other way round then ?

Yep. They saw the writing was on the wall for PIC vs. AVR and did the sensible thing while they still had some cash left. 

[nctnico]

Agree that OSHW enables clones. 

In the OSHW world there is no such thing as clones. Everybody can produce a circuit in any quantity they want.

[Poe]

FDTI's trademark prevented clones?

I can't wait for Tindie to pick up this Microchip strategy and buy Amazon.  Probably just old people keeping Amazon afloat anyways.

Anyways, just do it like the Mooshimeter.  That way, the hardware becomes so easy to clone there's no fear of loosing any IP.

Programming the phone side also becomes trivial so no fear of loosing an afternoon's worth of IP. 

It also produces the cheapest and most useful, easiest to configure solution for the people who would actually take advantage of the open-source-ness.

All arguments for a meter-mounted display can be satiated with on-board LEDs and buzzer IMHO. 
Reading within 7.642V and 7.645V = Green LED, Beep and record time.
Reading outside of that = Red LED only

nctnico - Tell Dave that.

[EEVblog]

According to my dictionary a clone is "A person or thing regarded as an exact copy of another". Surely having ready access to the design files enables that process of cloning.

Not if you don't release the PCB or case CAD files.

[EEVblog]

Hardware wise I'd also be for a dot matrix display.

a full matrix has major downsides ( contrast, power), but a small matrix section at a sensible mux rate to show menu stuff more legibly than trying to do it on 7-segs would be a useful compromise.

No point talking about the LCD, dot matrix is not going to happen, the 7 segment display is done and dusted.

[EEVblog]

Yea, I'm not a big fan of the whole PIC thing either. Ancient technology, that's not only small in CPU and RAM/Flash, but also very expensive for what they are.
But. It's Daves product. He calls the shots, and I'm hoping there's more behind the decision than "I know PICs, so that's what we should use".

The designer/manufacturer picked the PIC16, not me. At one point they wanted to change it to some obscure Chinese architecture for some reason, I said stick with the PIC.

Hmm. I wonder if Dave would consider selling just the empty cases with LCD, buttons/switches or whatever is on it ?

Nope, not worth the hassle. Who's going to want that, one or two people?

[EEVblog]

I was a bit worried about that too, I know Dave is a PIC fan. I forgot about the expensive PIC compilers and development kits though.
Should really have used AVR these days. Oh, well.

You mean the same Atmel that was just bought by PIC and is having the guts cut out of the company? That Atmel? Yeah, that would have been a smart choice...

[wilfred]

According to my dictionary a clone is "A person or thing regarded as an exact copy of another". Surely having ready access to the design files enables that process of cloning.

Not if you don't release the PCB or case CAD files.

I can't argue the finer points of what OSHW is. I just assumed it was sufficient information to replicate the product. I don't actually see a point to less than that because it wouldn't be entirely open. I thought the intent of OSHW was to enable others to create a replica.

[mikeselectricstuff]

Hmm. I wonder if Dave would consider selling just the empty cases with LCD, buttons/switches or whatever is on it ?
Nope, not worth the hassle. Who's going to want that, one or two people?

What about availability  of spare parts for repair?

[nctnico]

Agree that OSHW enables clones. 

In the OSHW world there is no such thing as clones. Everybody can produce a circuit in any quantity they want.

According to my dictionary a clone is "A person or thing regarded as an exact copy of another". Surely having ready access to the design files enables that process of cloning.

How can you make a clone if you are using the same design files? It is just like two factories making the exact same product using the same specifications and drawings.

[EEVblog]

Hmm. I wonder if Dave would consider selling just the empty cases with LCD, buttons/switches or whatever is on it ?
Nope, not worth the hassle. Who's going to want that, one or two people?

What about availability  of spare parts for repair?

AFAIK the only company in the world that offers spares for handheld multimeters is Fluke.
I ain't Fluke.
You'll have the schematic and part numbers, buy them on Digikey.
It's not really viable to keep and offer spares for everything, which is why hardly anyone does it.

[nctnico]

How can you make a clone if you are using the same design files? It is just like two factories making the exact same product using the same specifications and drawings.

Does it depend on whether it is two Toyota factories making a Corolla or two different companies making the same car but with a different badge like Ford and Mazda did at one time? It becomes a semantic debate. Will it resolve anything? I don't know the precise definition of just what OSHW is and just having watched the debates that go on from the sidelines I'm not at all sure there exists common agreement anyway.

One of the projects I'm working on uses open hardware initiated by CERN: http://www.ohwr.org/ This hardware and software evolves around picosecond timing synchronisation between various network nodes.
One of the designs is a PCIe base board for FMC Vita57 modules: http://www.ohwr.org/projects/spec/wiki If you scroll down you can see you can buy this base board from various companies who produce it.
The software is maintained by various people from various companies (including CERN).

[amspire]

Previously I did suggest an interpreter but I was thinking the processor would be more powerful then a PIC.

But I am still going to suggest the idea again modified for a 8/16 bit processor but with a second element thrown in that I think makes the idea worth a look.

As much as I like the idea of an open source multimeter, I really think a quickly flexible but totally reliable multimeter is more important. I think the manufacturers probably do a decent job reading voltages, resistances, etc and I am not sure there is much to gain rewriting this. Also the display is not great for an open source design as it will have the numbers and symbols to match the factory software. Cannot go dot-matrix display as without backlight, the contrast is lousy.

However, if there is an interpreter layer between measurement and display that can be replaced, it really does give you something, especially if a NFC reader could be added near the terminals. NFC tags for under 20c can contain 1K or more of eeprom memory - plenty for a new script for the interpreter. The reason for choosing NFC is it allows passive tags - this is important.

How would this work? You could build a RF SWR meter plugin containing some balun magic and a diode rf level detector. The moment this is plugged in, the meter could read the script on the tag in the plugin, which can blank out the "V" symbol, put the decimal point in the right place, can linearise the diode reading and can include calibration data. Once this plugin works on one meter, it will work and be calibrated on every meter. Unplug it and you have a factory standard meter again. Tags could be used for quick settings - like to set the range to 40K/60K range, and to measure relative to 10K. You could have a tag to change AC volts to dB (if the meter doesn't do it already). Change Ohms to Siemens. To connect to a second meter and combine measurements. You could even have a mode that you can get the meter to write a script to set the present operating mode - three taps of the tag and the multimeter writes a script for current settings/range to the tag.

But an interpreter is a huge job? No, if you make the right choices, the main part of a fast reliable interpreter can be a hundred lines of code. Once this exists, it almost trivial adding functions assuming similar functions already exist in the meter. I have added interpreters on systems of far lower power then a typical 8 bit PIC, and I can do details if anyone is interested. I am a slow programmer and I had my first go at an interpreter running in half a day back in about 1979 on an HP 9825A calculator/GPIB controller.

This would be the first ever meter with a NFC reader to detect the insertion measurement plugin devices that are unknown to the firmware and adapt to them. This is not something that an Open Source meter can do.

One of the key underlying principals with this approach would be opposite of Open Source - the code can never do anything that can damage the meter, and since code can be added instantly, there is no need to change the factory firmware, and so no warranty is affected. Every time the meter is switched on and there is no NFC tag, it can return to factory firmware mode. It would still be a ground-breaking meter, and in a way more useful then Open Source if a rich set of interpreter functions are added. NFC tags can go to 1M eeprom, and so tags can also be used to store and transfer data.

It is just an idea. I thought it was worth suggesting, even if it is not possible right now.