EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: EEVblog on April 20, 2024, 05:57:15 am
-
I had an idea for a project that requires a low power processor+bluetooth solution running Sigrok.
Does anyone know of any existing project or solution that already has this working?
I found an RPi implementation but that's why too high power.
Thanks.
-
I did a Google - I imagine the same Google that you did - and didn't find anything.
I have a small amount of experience with the Sigrok source code (and writing decoders for it).
[edit]: Just to confirm, you want to run sigrok on the actual low-power device, right? The alternative is for sigrok to run on a PC and have sigrok speak to the device over bluetooth.
Would an ESP32/RP2040 be low enough power? Which part of sigrok do you want to use exactly? Or do you want the whole full-blown sigrok?
-
What does "low power" mean in this context?
Sigrok is PC (Windoze / Linux / etc) software, and those have a few order of magnitude difference in the "low power" expectations compared to microcontrollers.
Part of the Sigrok project is fx2lafw It is Logic Analyzer sampling frontend for the Cypress FX2 series microcontrollers, but the only thing it does is stream data from the sampling frontend to the PC over USB.
If you need real low power, then in theory you can use a microcontroller and port a part of the command line functions of Sigrok to it, but that would require some significant software porting.
----------------------
Also, Sigrok seems to be in a quite sad state lately. Latest news on the website is from 2021-03-01, but the website apparently got an update on 2023-04-09, which is still over a year ago.
-
https://www.sigrok.org/blog/bluetooth-and-ble-support-libsigrok (https://www.sigrok.org/blog/bluetooth-and-ble-support-libsigrok) ?
-
What does "low power" mean in this context?
Sigrok is PC (Windoze / Linux / etc) software, and those have a few order of magnitude difference in the "low power" expectations compared to microcontrollers.
A few hundred hours from a couple of AA's would be nice.
I just need it for it's comprehensive multimeter support, nothing else.
-
Problem is that Sigrok is a library for a hosted environment (Linux/Windows...) and so porting it for a MCU type of target is probably a lost cause, although I haven't looked closely at its source code.
I haven't found a such port anywhere, and I somehow doubt you're willing to invest time doing this yourself. (Maybe it exists though.)
It would run on a small SBC with Linux. But that wouldn't meet your "low power" requirement.
You may consider the small boards with a RISC-V CPU running Linux, like the Milk-V or something like this, which would draw a lot less than a RPi or RPi zero, but it may still be difficult to meet your low power requirements with it. But that's what I would look at if you really want to use SigRok.
-
Sigrok runs on Linux, so you'll need a SBC to run the OS where you install Sigrok. I doubt there is any SBC that can run hundreds of hours from a pair of AAs. The state of the art in low-power single board computer these days is the mobile phone. Mobile phones have bigger batteries, yet they still don't run for that many hours.
So, either you port Sigrok to a bare-metal microcontroller (which might be too complicated in terms of software), or use any casual SBC board, but with an external power source, such that the end user can power the device either from a PC USB port, or from a USB phone charger, or from a beefy USB Li-Ion power bank.
You might also add an internal socket for a 18650 Li-Ion battery (accessible from outside), so the end user can insert the battery without dismantling the unit, and you won't have to deal with Li-Ion shipping regulations.
-
Problem is that Sigrok is a library for a hosted environment (Linux/Windows...) and so porting it for a MCU type of target is probably a lost cause, although I haven't looked closely at its source code.
I haven't found a such port anywhere, and I somehow doubt you're willing to invest time doing this yourself. (Maybe it exists though.)
Correct. I was hoping someone had done some sort of minimalist port somehwere.
You may consider the small boards with a RISC-V CPU running Linux, like the Milk-V or something like this, which would draw a lot less than a RPi or RPi zero, but it may still be difficult to meet your low power requirements with it. But that's what I would look at if you really want to use SigRok.
I might have to abandon Sigrok. I just thought it would be nice because it already has support for many different meters.
-
I've looked through the sources some years ago, but with a different goal in mind. I remember there was a sigrok related video from one of the developers of pulseview (PulseView is the typical GUI for sigrok, sigrok is just the comand line tool + instruments drivers). The video still exists, at minute 1:40 he states he was a PulseView developer: https://youtu.be/dobU-b0_L1I?t=103
Try to contact the guy from the video, and ask him for an informed opinion, maybe it's doable to port sigrok on a low power MCU.
-
I might have to abandon Sigrok. I just thought it would be nice because it already has support for many different meters.
It does have support for many different meters - the challenge is that it provides support for these meters through external libraries - and many of these external libraries require an operating system because they are abstractions on top of OS abstractions.
Making sigrok run without an operating system would require porting these external libraries to run on microcontrollers. It doesn't look like anyone has done this.
The wiki Build page (https://sigrok.org/wiki/Building#libsigrok) shows the dependancies that are required for libsigrok (sigrok is a command-line wrapper around libsigrok):
- bluez for Bluetooth comms (bluez only supports linux Linux, not even Windows or macOS, let alone microcontrollers)
- libserialport for serial port comms
- librevisa for VISA comms
- libusb for USB comms
- libftdi for the FTDI protocol (this might be easy to port to a microcontroller)
- etc.
In theory if its only BLE microcontrollers you want to support you might be able to compile a version of sigrok with only support for bluetooth meters, if you write a spartan BLE library for your microcontroller that has a similar API to bluez.
The effort increases as you want to support more multimeters. I don't hold high hopes that (m)any of these libraries have been ported to microcontrollers, but I would be more than happy to be proven wrong.
-
Forgot to say, there are some single-chip running Linux, first search result for single chip Linux: https://hackaday.com/2018/02/24/microchip-introduces-tiny-cheap-linux-modules/ There should be more of them out there, I remember some DIY/blogs with single-chip Linux devboards, too, but I don't know their specs or price. I guess, a Raspberry Pi Zero W (with Wi-Fi for no wires to PC), or a Raspberry Pi DM might be cheaper, but I don't know their power specs either.
-
Now I'm trying to imagine what Dave's idea is... A remote wireless, battery-powered secondary display for meters that connects over Bluetooth?
-
Porting all of sigrok is almost certainly a fool's errand but the good thing is that it is fairly modular. E.g. starting with just the basic serial-dmm driver might be a reasonable plan. You may be able to largely re-use the individual protocol implementations (https://github.com/sigrokproject/libsigrok/tree/master/src/dmm) and the model definitions (in https://github.com/sigrokproject/libsigrok/blob/master/src/hardware/serial-dmm/api.c) and build your own functionality around that. And by you I mean the person you would likely have to hire to do it for you.
In any case you would still need to test all the DMMs you want to support yourself. There is no guarantee they will work properly afterwards (or that they ever did). And I speak from experience when I tell you that trying to debug compatibility issues without access to the actual hardware is a whole world of pain.
Another thing to keep in mind is that sigrok is licensed under GPL3. That means that not only would you have to open source your firmware, you likely won't be able to use vendor wireless stacks with binary blobs or incompatible licenses either.
-
Now I'm trying to imagine what Dave's idea is... A remote wireless, battery-powered secondary display for meters that connects over Bluetooth?
Also a wireless DMM logger would be nice to have, then, maybe a SCPI bridge between the PC and the logger, too, so any DMM would appear as a SCPI instrument, and from there it can be directly used in LabVIEW, Octave, etc.
-
You may consider the small boards with a RISC-V CPU running Linux, like the Milk-V or something like this, which would draw a lot less than a RPi or RPi zero, but it may still be difficult to meet your low power requirements with it. But that's what I would look at if you really want to use SigRok.
I might have to abandon Sigrok. I just thought it would be nice because it already has support for many different meters.
I would still have a look at those Milk-V boards and see how much current they draw under minimal utilization (which Sigrok would be if you just need to get data from multimeters).
And if it doesn't meet your requirements, you may still have material to make a video about these small RISC-V boards running Linux. They are very cheap too.
Just my 2 cents.
-
If this is for the 121GW. As I understand it, it's got uSD onboard and can already run custom / alternative firmware. What about writing a frontend for setup and configuration and then have the DMM itself do the logging? This way Buetooth can be turned off most of the time and that probably has a positive effect on battery life.
There is also a project on this forum for "a program that can log data from many DMM's".
-
How about port the drivers to ESP32?
-
Sigrok also supports android so that puts you into the mobile phone processor regime.
“A couple hundred hours of 2xAA” is around 9Wh capacity divided by 300ish which is 30mW average. That puts you into deep sleep microcontroller territory, and about the only thing that will do that sort of power budget with bluetooth is a Nordic nRF chip. Sigrok’s “swiss army knife” nature sounds like it might be computationally expensive (in the context of “spending most of your time sleeping”, it sounds like a poor fit, windows/linux support implies “always awake”)