Hackaday Prize Entry: Python Powered Scientific Instrumentation

A common theme in The Hackaday Prize and Hackaday.io in general is tools to make more tools. There are a lot of people out there trying to make the next Bus Pirate, and simply measuring things is the first step towards automating a house or creating the next great blinkey invention.

In what is probably the most capable measurement system in the running for this year’s Hackaday Prize, [jithin] is working on a Python Powered Scientific Instrumentation Tool. It’s a microcontroller-powered box containing just about every imaginable benchtop electronics tool, from constant current supplies, LCR meters, waveform generators, frequency counters, and a logic analyzer.

This project is stuffed to the gills with just about every electronic tool imaginable; there are programmable gain amplifiers, voltage references, DACs and constant current sources, opamps and comparators, all connected to a bunch of banana jacks. All of these components are tied up in a nifty Python framework, allowing a bunch of measurements to be taken by a single box.

If that’s not enough, [jithin] is also working on wireless extension nodes for this box to get data from multiple acquisition points where wires would be unfeasible. This feature uses a NRF24L01+ radio module; it’s more than enough bandwidth for a lot of sensors, and there’s enough space all the wireless sensors you would ever need.


The 2015 Hackaday Prize is sponsored by:

28 thoughts on “Hackaday Prize Entry: Python Powered Scientific Instrumentation

  1. :D Thanks for the great review!
    I look forward to community feedback that’ll hopefully give me specific direction as far as tweaks and add-on modules go.

    A slight clarification is in order. The NRF radio sure has a high bandwidth, and the firmware can keep up with the data stream, but the slowest step is getting the data from the hardware, and onto the PC. OS delays associated with getting each packet into Python will affect that rate. The NRF can transmit a packet with a maximum of 32bytes at a time, and from what I’ve measured, the accelerometer App(Without graphics overhead) has a ping time of approximately 2mS for a 32 Byte packet, as well as a 4 byte packet. So that’s the time frame one is looking at. I’ll try to implement a firmware feature that’ll collect up to 10k samples in a buffer in one shot at 2MbPS, following which it can be dumped into the PC.
    The nodes have built in ADCs, so the simplest, yet useful application I can think of is to make a dozen wireless pulse meters that’ll relay information to a common screen.

    @philosiraptor117: Separate tools will cost you a significant bundle, and you’ll also have to interface all of them separately if you wish to control an elaborate experimental setup. I’ve worked in a few research labs ,and have spent quite some time trying to interface instruments onto a common PC outside of a proprietary environment like LabVIEW, and am quite happy with how much easier it is to use linux-gpib , or python-usbtmc, or simple TCP sockets, and roll your own Python code.
    It may not be a research grade product, but it sure makes things a lot easier, thereby opening up possibilities for students who might not be familiar with microcontrollers, or analog electronics, but have a grip on physics and a know a spot of coding. Given that Python is increasingly being taught at the high school level, a lab tool based around it sounds about right.

      1. Hi, I’ve been meaning to try PyPy for a long time now.
        Didn’t see any change in single character ping times which leads me to believe I haven’t understood how to use it.

        I unzipped the latest PyPy build to /opt, and made a symlink in /usr/local/bin/
        installed pip
        installed pyserial > sudo -H pypy -m pip install pyserial
        $pypy
        >>>> import serial
        >>>> serial.__file__
        ‘/opt/pypy-2.6.0-linux64/site-packages/serial/__init__.pyc’

        installed numpy as well, but couldn’t get PyQt4, sip to run, so I wrote an echo program instead

        import serial,time
        fd = serial.Serial(‘/dev/ttyACM0’,1000000, stopbits=1, timeout = 0.02) # 1Mbaud
        print fd.read(100)
        s=time.time()
        while 1:
        t=time.time()
        print t-s
        s=t
        for a in range(255):
        fd.write(chr(a))
        fd.read()

        At the receiving end is an MCP2200 with TX shorted to RX
        with Python 2.7, ping times were ~300mS/255 per character
        With PyPy2.6 it was still roughly the same.

        could you point me in the right direction?

        1. I’ll repost the echo program since the tab spaces disappeared in the last post.

          import serial,time
          fd = serial.Serial(‘/dev/ttyACM0′,1000000, stopbits=1, timeout = 0.02) # 1Mbaud
          print fd.read(100)
          s=time.time()
          while 1:
          t=time.time()
          print t-s
          s=t
          for a in range(255):
          fd.write(chr(a))
          fd.read(1)

  2. :D Thanks for the great review!
    I look forward to community feedback that’ll hopefully give me specific direction as far as tweaks and add-on modules go.

    A slight clarification is in order. The NRF24L01+ radio sure has good bandwidth, and the firmware can keep up with the data stream, but the slowest step is getting the data from the hardware, and onto the PC. OS delays associated with getting each packet into Python will affect that rate. The NRF can transmit a packet with a maximum of 32bytes at a time, and from what I’ve measured, the accelerometer App(Without graphics overhead) has a ping time of approximately 2mS for a 32 Byte packet, as well as a 4 byte packet. So that’s the time frame one is looking at. I’ll try to implement a firmware feature that’ll collect up to 10k samples in a buffer in one shot at 2MbPS, following which it can be dumped into the PC.
    The nodes have built in ADCs, so the simplest, yet useful application I can think of is to make a dozen wireless pulse meters that’ll relay information to a common screen.

    @philosiraptor117: Separate tools will cost you a significant bundle, and you’ll also have to interface all of them separately if you wish to control an elaborate experimental setup. I’ve worked in a few research labs ,and have spent quite some time trying to interface instruments onto a common PC outside of a proprietary environment like LabVIEW, and am quite happy with how much easier it is to use linux-gpib , or python-usbtmc, or simple TCP sockets, and roll your own Python code.
    It may not be a research grade product, but it sure makes things a lot easier, thereby opening up possibilities for students who might not be familiar with microcontrollers, or analog electronics, but have a grip on physics and a know a spot of coding. Given that Python is increasingly being taught at the high school level, a lab tool based around it sounds about right.

  3. Interesting, but why PC based? When I’ve been in labs some twenty years ago they were ubiquitous, but are they still? Will they be in a few years? Why not cram a Raspberry Pi or something similar in there, which allows for some mobility, lower system cost, lower power consumption for long running experiments, galvanic separation (if battery powered — it’s my understanding that Ethernet still uses transformers) and potentially higher data transfer rate to the host (the RPi).

    1. Since it is written in Python and uses scipy and Qt, I assume it could be ported to the Raspy or at least the Raspi2.
      [jithin], do you have a Github repository for your project?

      1. It’s not strictly PC based. As long as the USB drivers can handle an ACM device, it can be interfaced. For example, I had worked on an Android port for another such device called ExpEYES whose design details are in the open domain. It also uses the usb-serial from Microchip, and can be accessed via UsbEndpoints on Android.
        The Raspberry Pi will certainly feature in the grand scheme of things. The PCB has connectors intended to connect it to the RPi.
        The Raspberry Pi is also making it to a lot of schools assisted by non-profits, and bundling it with a few basic lab tools will achieve more than just computer literacy.

        I’ve explored an SPI master-slave architecture as well as the mini UART on RPi2. While SPI works fine and fast, i’ll have to make several changes to the firmware which will probably involve software buffers .
        UART is easy to use since the device can reply with data whenever it’s ready. However, I’ve run into issues with receiving large packets via the mini-UART. So the USB pins have also been broken out into a port so that they may be soldered directly onto the RPi2 if need be.
        One major drawback is the lack of hardware acceleration for 3D plots. Something about OpenGl support for PyQT4.

        I haven’t uploaded the libraries to GitHub since they’re still very unorganised, but the source code and partial documentation generated using Sphinx is available at http://pythonhosted.org/LabtoolSuite/interface.html . You’ll also find the library on PyPi, but that’s mostly for collaborating with my dad who finds time to test / review and also helps out with the project in a big way.

        1. Major props to you and your dad. I just lost my dad and already miss our projects we would work on together.

          I think the Broadcom gpu is now open source supported in OpenGl. PyQt4 is maybe just lagging.

          I look forward to seeing the project on Github. This could benefit many kids as well as the curious adults among us.

          1. Thank you for your support. My condolences.

            From what I’ve read, PyQt4 is indeed lagging. Maybe they’ll catch up soon. I had tried the same with the MarsBoard, and it managed slightly better with volume plots. Still not quite usable though.

  4. Take my money! Looks like a great space saver on the bench. I always love these Swiss-army-knife style tools, while they may not have the absolute precision of other tools, they work wonders if you need automated testing, or just to get some quick data.

      1. I’ve noticed gnu octave supports serial ports. Since there’s nothing fancy/proprietary about the communication protocol I’m using, one could easily adapt bits of the python library depending on the features required. I doubt I’ll write one myself though

    1. Thank you :D
      It’s calibrated against standard DMMs, and calibration functions(3rd degree polynomials generated from the calibration data) should make it fairly accurate. The voltage reference(REF196) is meant to address the issue of temperature dependent drifts that the usual voltage regulators suffer immensely from.
      I’ll properly characterize analog accuracy and add a log soon.

      1. * 2nd degree. x^2+x+c . higher orders isn’t an issue, but in the end I’ll have to store all the values in the flashmem, and I doubt that the ADC/opamps are that non-linear. The second degree itself addresses any curvature the slope may have.

    1. If you’re looking at low volume production, it should be less than about $120 including labor costs. Although, given the high number of SMD parts, it’s not a particularly good idea.
      High volume should bring it down to about $80 since parts can be purchased at bulk prices, and pick and place assembly will bring down costs too.
      I’ve mentioned the costlier components in the project details page.

      I’m expecting a PCB for a stripped down version to be shipped soon. Since the project in its present form may be overkill/out of budget for certain consumers, the mini version has a reduced feature set. Bipolar inputs have been reduced to 2, but 8 high impedance multiplexed unipolar inputs are still there. The board will be smaller, and have fewer banana jacks . It’s mostly a cost cutting exercise, and expensive ICs like AD9833 , REF196 have either been reduced in number, or made optional. As far as add-ons go, nothing changes since the main controller is still the PIC24E . The ESP-12 will also stay as an option.

  5. For quite a long time I have wanted to build such a thing, even with the radio modules. I never did, because of that multitude of boxes that still does the job. Also I got an analog discovery which proved much more useful than anticipated.

    I think it is a great idea to build this thing. However, for research purposes people would often prefer tools with as broad usage and high performance as possible, lowest price might not be the most important thing. (Don’t forget researchers are expensive too). So, I would look at the possibility of having 2 versions, preferably build in the same way on the same PCB: a low cost version and a high performance version.
    For example the MCP4728 is a very low cost 12bit DAC, but i would try to find something compatible with 16bits resolution as well.

    1. This is mostly intended as a teaching tool . Will likely help with the transition to research grade equipment.

      I’ve got the AD7718(24-bit ADC), ADS1248, and AD5680(18-bit DAC) as add-on boards, but haven’t gotten them to work yet. About to try out a lock-in amplifier design with the addition of an analog multiplier and low pass filter.
      I intend to power the ADCs from a battery and have an opto-isolated version. My aim was to have a flexible base board which can handle expensive, precise ICs plugged into the expansion slots as requied. The noise floor on the base board may not be low enough for that high precision due to all the switching components.

  6. [jithin] This kicks mucho ass. Very nice! I’m happy to see PyPy alive, kicking and maturing. Stackless Python is also really solid project. PyPy is a great project I’m really happy to see you integrating it.

    @Others – This was posted back in 2011 but even at that time it seemed impressive.
    http://morepypy.blogspot.com/2011/07/realtime-image-processing-in-python.html

    I hope more folks leverage interest in it. (Although I see a pattern that some of the most ingenious coders are geared toward Erlang/Haskell/Scheme/Guile/SmallTalk and now I guess the popular efforts are toward Rust or Node.js)

    Sadly, PyMite(Python-On-A-Chip) / MonKEE, pyMCU, micropython are overlooked and neglected.
    pycorn(R.I.P.) didn’t get the traction.

    1. Thank you.
      I haven’t managed to integrate PyPy yet. Would be nice if someone could demonstrate a simple echo program that shows significant improvements in speed. I’ll take it from there.

      I was at Scipy.in 2014, where [Romain Guillebert] of PyPy was one of the keynote speakers. The audience was stunned when he demoed the realtime image processing example with and without PyPy. \m/

Leave a Reply to derpderpCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.