POLL: EEVBlog DMM App Sigrok Support

[EEVblog]

So David is writing the new (open source) 121GW app to obviously support the upcoming 121GW multimeter. It's designed to be cross platform (Android, Windows, iOS, Linux, Mac) and support dual multimeters (more on Windows) and graphing.
But I realised that the Sigrok library support is awesome:
https://www.sigrok.org/wiki/Supported_hardware

And I was thinking that maybe it makes sense to pivot the app to use the Sigrok library as well as (or instead of). This would enable the app to become more universal and support many meters and scopes on the market.

The question is should we put the time and effort into doing this?
And as a result the app (whilst being open source) may not be free on the various platform, but 121GW purchasers will get a voucher code for it.

We have not looked into the work required to do this, and we are presuming it will not be trivial. So please don't just answer Yes because it sounds cool, only answer yes if you think it will be really beneficial.

Thanks.

Here is a current Windows phone screen shot: (the graph scales on other devices and orientations)

[BravoV]

Voted Yes, as Sigrok imo will contribute for your DMM's popularity as well, although not sure how much the impact on your sales, but more popularity is good right ?

Suggesting you send a sample to Sigrok's developer too.

[alm]

Some thoughts:
- Might consider discussing this with the sigrok developers. There appears to be overlap with sigrok-meter, but that does not seem to be actively developed (last substantial commit was in 2015). Having a feature-complete GUI for the DMMs supported by Sigrok would certainly be welcome. Currently GUI support seems to be mostly limited to Pulseview (logic analyzers and scopes).
- Not sure how easy it would be to port libsigrok to iOS and Android. I imagine interfacing with USB-TMC devices would be impossible on iOS and possibly tricky on Android. Same for RS-232 and GPIB. So the list of actually supported meters might be quite short (Bluetooth, LAN/WiFi?). Not using libsigrok on iOS might also save you from some GPL / iTunes headaches (unless those have been solved in the past couple of years).

[joeqsmith]

Personally, I don't think I would ever use it so I voted no.  I am pretty much set on using LabVIEW.   

With your meter sending data at the maximum rate, how long will it run with a fresh set of batteries?

Will the meter will be able to offload the cards data using BT?

I had posted about the data logging to the card having a problem so I could not run any long term tests with the meter.   I assume this will be resolved but when it does work, is the plan to allow the meter to fully use the cards memory for a single log file? 

If say the PC looses connection with the 121GW during a test, will the communications protocol handle this and use the card as a  large buffer? 

[sibeen]

Voted yes. It would be nice to have a logging function that I can send straight to my phone or PC.

[rs20]

Voted yes because standardization rules. It doesn't really matter how awesome David's software is (and I am sure that it will be absolutely awesome), it is impossible that it will cover all possible usecases or scenarios. If the multimeter is sigrok-compatible, well then any software I write for the EEVBlog meter will be instantly compatible with any number of Agilent, Bryment, Gossen Metrawatt, etc multimeters as well, and any software that anyone else writes for sigrok will be instantly compatible with the EEVBlog meter. So, unless I'm missing something, that's an absolute no-brainer 100% "yes".

[EEVblog]

Some thoughts:
- Might consider discussing this with the sigrok developers. There appears to be overlap with sigrok-meter, but that does not seem to be actively developed (last substantial commit was in 2015). Having a feature-complete GUI for the DMMs supported by Sigrok would certainly be welcome. Currently GUI support seems to be mostly limited to Pulseview (logic analyzers and scopes).

Ah, didn't see that program. Their website isn't exactly the best at promoting stuff.
I don't want to duplicate effort.

[EEVblog]

With your meter sending data at the maximum rate, how long will it run with a fresh set of batteries?

Don't know yet, haven't tested it as there is currently a bug in the logging.

UPDATE: I just tested the current with SD card logging and didn't really see any increase in the average current consumption. i.e. approx 5.5mA
Logging to Bluetooth the average current jumped to 11mA or so.
4 x AA batteries, so you can do the math.

Will the meter will be able to offload the cards data using BT?

No. Technically possible, but there is no plan for doing that.

I had posted about the data logging to the card having a problem so I could not run any long term tests with the meter.   I assume this will be resolved but when it does work, is the plan to allow the meter to fully use the cards memory for a single log file? 

That's the plan. Although the battery would run out before the card does.

If say the PC looses connection with the 121GW during a test, will the communications protocol handle this and use the card as a  large buffer?

Not at present.

[EEVblog]

Voted yes because standardization rules. It doesn't really matter how awesome David's software is (and I am sure that it will be absolutely awesome), it is impossible that it will cover all possible usecases or scenarios. If the multimeter is sigrok-compatible, well then any software I write for the EEVBlog meter will be instantly compatible with any number of Agilent, Bryment, Gossen Metrawatt, etc multimeters as well, and any software that anyone else writes for sigrok will be instantly compatible with the EEVBlog meter. So, unless I'm missing something, that's an absolute no-brainer 100% "yes".

Either way we will make sure the 121GW is supported in the Sigrok library.
Whether or not we send one to them or do it ourselves I don't know.
It's basically a separate issue (and the point of this poll) whether or not to pivot the software to support other meters via the Sigrok library.
It's not a no-brainer  because it will no doubt take a lot of extra time and effort to support the Sigrok library.
It's already been a massive amount of work making the current cross-platform app

[rs20]

Oh sorry, my bad, I misunderstood the poll then. In that case, I'd change my vote (if I could! ) to "Depends (on difficulty for you guys)".

[2N3055]

I voted no, because I think the first step is to provide an easy to use API that can be called from C or C++ or whatever language, and then think about further abstraction.
I believe that if your API is good enough, there will people writing Sigrok stub library for you for free.
A virtual DMM is not anything new, but a fully programmable, low cost, high resolution DAQ can be potentially very attracting.

This.  Agree 100%.

[biot]

As one of the sigrok folks, I am obviously in favor of this.

If you want your software to see the widest possible use, libsigrok support is clearly the way to go. A massive number of multimeters is supported, and they are often trivial to add as many of them use generic, already-supported DMM chips.
However using libsigrok also automatically makes your software useful for things like LCR meters, sound level meters, and tons of other gear you couldn't hope to write support for as a lone developer. Hell of an opportunity to miss.

A good, full-featured meter app is indeed what we're missing in the sigrok family, and this would be very welcome. So you'll have no problem getting support from various sigrok folks on this. Also, libsigrok is quite easy to use. I bet it has a few features you'll need but haven't thought of :-)

Quickest way to get help is IRC (#sigrok on irc.freenode.net), but the mailing list is fine too.

[biot]

I voted no, because I think the first step is to provide an easy to use API that can be called from C or C++ or whatever language, and then think about further abstraction.

Why spend the time designing and implementing an API? That is exactly what libsigrok is. It's a native C API (with C++ and Python bindings), which allows for scanning, connecting and communicating with hardware, with lots of support for all the other stuff you'll need -- ways to enumerate hardware features, specify analog values with precision indication, output to lots of file formats, and so on.

That's all been done, and works fine -- why duplicate the effort with a narrower focus on one device?

[abraxa]

Hi Dave, I'm another one of the sigrok devs. It's great to see you consider using our project!

And as a result the app (whilst being open source) may not be free on the various platform, but 121GW purchasers will get a voucher code for it.

I'm not totally familiar with all the details of the GPL but there are two questions popping up in my head:
1) Is it legal to charge money for apps that make use of GPL components?
2) The iTunes TOS and the GPL are inherently incompatible: http://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement (alm mentioned this, too). This could mean that the iOS app would have to be built without libsigrok in order to be "clean".

We have not looked into the work required to do this, and we are presuming it will not be trivial. So please don't just answer Yes because it sounds cool, only answer yes if you think it will be really beneficial.

From my point of view it would be beneficial for sure because it greatly increases your potential user base if you support more multimeters. Depending on the architecture of the app, using the libsigrok API may be trivial or non-trivial, it all depends.
I'm not voting, btw.

There appears to be overlap with sigrok-meter, but that does not seem to be actively developed (last substantial commit was in 2015). Having a feature-complete GUI for the DMMs supported by Sigrok would certainly be welcome.

While sigrok-meter isn't full-featured like biot already wrote, it is quite useful as it is. Of course it would be nice to see new features added but unfortunately, we don't have enough developers to make it happen.

Either way we will make sure the 121GW is supported in the Sigrok library.

I like the sound of that!

I think the first step is to provide an easy to use API that can be called from C or C++ or whatever language, and then think about further abstraction. I believe that if your API is good enough, there will people writing Sigrok stub library for you for free.

The only reason I can see for doing this is the iTunes<->GPL issue. However, that would require both apps to run at the same time and sounds difficult to pull off in a cross-platform manner. With that, I don't see this happening. For all other platforms, building on top of libsigrok is a non-issue.

[biot]

Because not everyone wants to code properly. Sometimes it's a killer feature to allow users to abuse the library and expect things to still work. For instance, Digilent Waveform SDK is super simple to use -- you just need to import the library and a few lines of code can get you data from device. The library contains a few sensible default settings so that most settings can be left untouched and still get sensible output. Also, a single device model makes the discovering and connecting process virtually zero effort.

I looked at libsigrok's test programs on Github, and it seems like there are quite some init code just to "properly" search and connect devices, then config device, before being able to pull data from device.

That is a good point, but do note that you can hardcode things in libsigrok just as you can without it. You don't have to let libsigrok scan for you: you can just tell it to use the 121gw driver, and pass it the serial port and speed etc parameters.

[EEVblog]

That is a good point, but do note that you can hardcode things in libsigrok just as you can without it. You don't have to let libsigrok scan for you: you can just tell it to use the 121gw driver, and pass it the serial port and speed etc parameters.

So a serial port is libsigrok expects to see new meters? (we haven't looked at the details)
Our original plan to simply implement a Bluetooth serial port, but (in hindsight perhaps unfortunately) we chose a BLE module (BLE112) instead of a Bluetooth module, and trying to implement serial port on BLE have proven incredibly frustrating, so much so that we gave up and are now just using a custom binary packet.
So it seems we'll have to write a driver that converts that data into the required serial data?

[biot]

So a serial port is libsigrok expects to see new meters? (we haven't looked at the details)
Our original plan to simply implement a Bluetooth serial port, but (in hindsight perhaps unfortunately) we chose a BLE module (BLE112) instead of a Bluetooth module, and trying to implement serial port on BLE have proven incredibly frustrating, so much so that we gave up and are now just using a custom binary packet.
So it seems we'll have to write a driver that converts that data into the required serial data?

If you're using your own BLE packet, that means you'll need to speak BLE on the client, and decode that packet. Doing this cross-platform is going to be a major undertaking, I think. That's the reason people keep doing serial port emulation over USB, bluetooth etc -- every platform already has serial port support, no custom drivers needed. Have you looked at how you're going to do this cross-platform? Which platforms do you want to support?

As for sigrok, there is currently no bluetooth/BLE transport backend, though that can be added. I'd expect it to be a while before such a backend is entirely cross-platform, however.

[EEVblog]

If you're using your own BLE packet, that means you'll need to speak BLE on the client, and decode that packet. Doing this cross-platform is going to be a major undertaking, I think. That's the reason people keep doing serial port emulation over USB, bluetooth etc -- every platform already has serial port support, no custom drivers needed.

BLE drivers on various platforms do not have any inherent support for a serial port interface, unlike full Bluetooth.  Bluetooth Low Energy is a very different beast to regular Bluetooth from this aspect. Too much detail to go into the explain why.

Have you looked at how you're going to do this cross-platform? Which platforms do you want to support?

David current app written in Visual Studio is going to be truly cross-platform. Currently working on WIndows, Windows phone, and Android. He assures me iOS will just simply work, as should Mac, and Linux will be a little bit trickier but solvable.

As for sigrok, there is currently no bluetooth/BLE transport backend, though that can be added. I'd expect it to be a while before such a backend is entirely cross-platform, however.

We can just take our BLE interface code and port that to a serial port no problems. But to be clear again, BLE modules do not have support for serial interfaces. i.e. it's not really possible for the BLE module in the meter to do serial over BLE.

[alm]

Ah, didn't see that program. Their website isn't exactly the best at promoting stuff.
I don't want to duplicate effort.

Like I said, development seems to have stalled, so I would not be too worried about that. Obviously biot and abraxa would be better judges of that. And I am pretty sure the current Pulseview for logic analyzers was a duplicate effort of the several previous attempts at a sigrok GUI.

While sigrok-meter isn't full-featured like biot already wrote, it is quite useful as it is. Of course it would be nice to see new features added but unfortunately, we don't have enough developers to make it happen.

I was going by the wiki page which has a bright red banner stating:

NOTE: sigrok-meter is work in progress and is not yet suitable for everyday use!

Just left out the "Danger, Will Robinson" and "here be dragons". Based on the git commits, I am not holding my breath until it is suitable for everyday use . Obviously supporting all available hardware with both low level drivers and a front-end is a huge task, so it is not surprising that you guys are low on manpower. That is why a third-party front-end that interfaces with libsigrok could be beneficial.

1) Is it legal to charge money for apps that make use of GPL components?

Yes. As long as you offer the full source (including all Makefiles etc) to build said binaries, and allow your customers to distribute it under the GPL. I could see this working for non-iTunes application stores like the Google Play store. It would then just be a convenience thing so people would not have to sideload it. Not sure if there are any issues in the Windows stores and Mac stores, like there is with the iOS app store.

[Rbastler]

I voted no. Because I don't think the effort needed to be put into programming is worth it in the end. I see it as a niche application for field use on a phone are tablet.
I will use at home LabView or MathLab to get data from my instruments and I would use it too in the field on a windows tablet or laptop. So I only see a place for such a app/programm on a very small amount of devices.

[WaveyDipole]

Well not everyone can afford LabView or Matlab so an open source solution would be welcome. So far it is the only way I have been able to get my meter working under Linux so I am grateful for the project. Still, I voted depends because for me it depends on certain aspects of sigrok support being in place. For example, although there are releases as recent as June 2017 on the official sigrok website, the packaged versions available via mainstream OS distributions such as Ubuntu and MINT are dated from 2014 and did not work with my meter. Still, I persevered and spent some 3 hours compiling the latest version which eventually succeeded and did work. However, I suspect it would help with uptake and user confidence if repository packages were reasonably up-to-date in the first place.

Also noting the eariler comment:

Quickest way to get help is IRC (#sigrok on irc.freenode.net), but the mailing list is fine too.

Unfortunately the IIRC channel is very quiet and I have so far received no response (other than a request from uwe_ for further detail) despite having sat on the channel for a couple of hours again this morning. It has been two days since I posted on sigrok-devel but also have so far received no reposnse. I will continue to excercise patience for a while longer, but this does seem to suggest that the project is not very well supported?

UPDATE 21/08/2017: my persistence eventually paid off and I have received some excellent support from the sigrok-project via IIRC an now have all of the up-to-date versions of the software compiled, for which I am very grateful.

UPDATE 22/08/2017: in case it helps anyone, I have posted my notes on compiling the various sigrok modules here:
https://www.eevblog.com/forum/testgear/getting-brymen-bm869s-working-with-sigrok/msg1285618/#msg1285618

[MatthewEveritt]

Getting sigrok to support the meter is pretty much a must have, but that's not what we're talking about here.

I love the idea of a proper sigrok meter GUI, cross-platform would be great, but I have to say I don't really think the 121GW app is the place to do it. It might be an interesting starting point, but trying to support all the different meters (with different features and items to display and options to send and so on) that sigrok caters for sounds like trying to run before you can walk. It sounds like a lot of work to get a polished user interface without over-complicating matters.

My suggestion would be to write a dedicated app for the 121GW with some thought going into creating a layer of abstraction between the meter interface and the GUI, more as good practice than anything else.
Maybe look into using libsigrok, or possibly just use it as a template (API) for writing your own code, but don't try and support other devices. That way you've hopefully got a good starting point if you do decide to work on a universal app later, but a better chance of having a stable, polished app ready to release when the meter goes on sale.


Bottom line, a proper libsigrok app would be brilliant, but the companion app for a soon to be released meter is probably not the right place to try it.