close-circle
Close
0%
0%

A HSDK for ultrasound imaging

Using a Raspberry-based hardware and software development kit to understand ultrasound imaging

Similar projects worth following
close
This tool is based on the previous work done (like murgen, but was not simple enough), to get a ultrasound imaging dev kit. In short, this is a modularized version of Murgen, all equipped for imaging, based on two ad-hoc ultrasound boards, a Raspberry, a custom ADC, and a motherboard.

This HSDK has for objective to:

- consolidate existing hardware research;
- simplify and lower the cost of the kit;
- permits benchmarking of ultrasound systems;
- introduce a simple API to control hardware;
- have a server which provides both raw ultrasound and data standard DICOM files;
- have a kit that can be used for pedagogical and academic purposes - not to mention people who want to understand ultrasound!

This dev kit can be used in other projects such as dopplers, non-destructive testing, using piezos as sensors, ...

More info on the basis of this work: http

Lots of water under the bridge. Since the last post! This project was born a year ago when I wanted to split a bigger board into smaller modules. I went on exploring different options, combination of modules, hardware, probes, motors, and DAQ (from STM32s to Beaglebone PRUDAQ, passing through onboard smaller ADCs), which yielded lots of interesting results. I really enjoyed exploring all of this, and really learnt a lot. Who know I'd do this when 18 months ago I didn't know anything about electronics hardware (or at least had forgotten all from the golden age of my studies?).

Anyhow, the goal here is simple. I need a stand-alone "exploring tool" to explore ultrasound systems. I have built several versions with Murgen, and have made the proof that it's possible to have a small ultrasound machine in your garage. However, I found more pleasure in building the tools and in the process of digging into the different components.. and that's what I want to explore in this project.

Hardware is basically already built: previous lessons from Murgen bring the analog front end, a hack I have can be used to emulate a probe: what remains is to remove overkills on the circuits, and SIMPLIFY everything, making it more robust and more user friendly.

The second step will be to have a good driver for the Raspberry Pi (which I believe is enough for my needs), to control the hardware, and develop a good enough server API.

Once this is done, I'll be happy to test it with probes like the ATL probes I've been debugging, with doppler probes projects here and also to explore this chinese probe of mine.

So, on with this project, and see if cross-pollination works =)

  • Making a cheaper pulser

    kelu12408/30/2017 at 19:44 0 comments

    Part of this project is a pulser module - its aim being to generate the high voltage necessary to generate the inital accoustic wave for ultrasound imaging, with severe constraints in terms of voltage, impendance, and duration. 100V for 150ns are not unheard of.

    The previous module, tobo, was great at its job, up to two point. First was its price, with a 50$ RECOM component to generate the high voltage, and then the possibly more fragile components such as the HV7360. 

    To solve this, the HV7360 has been replaced, and I'm changing this unipolar pulser to a bipolar pulser, for both precise timing of pulses at 0, +-25V, +-50, +-75V -- voltages being set with jumper. The layout still remains the same, and yields:

    It's been sent to Shenzen, let's see how it goes =)

  • Ultrasound with the Pi W 24Msps ADC

    kelu12407/16/2017 at 22:22 0 comments

    and getting access to ultrasound raw signals, yields the way to more fun with ultrasounds! The ATL3 probe used provided access to interesting insights and signals, ultimately to rebuild an ultrasound image of our beloved phantom

    ( as usual the jupyter notebook is available):

    Not too bad! We have 1k lines, 2500points on each ADC, times 2 ADCs. That's around 5M points, at a resulting 24Msps. I got three images:

    Which, combined, provide a good example of an ultrasound image:

    yeahh!!


  • Getting to signal processing

    kelu12407/02/2017 at 09:15 0 comments

    Got interesting images using both the analog envelope and the digital detection of the envelope processes. Digital envelope detection detailed at https://github.com/kelu124/echomods/blob/master/elmo/data/arduinoffset/20170612-ArduinoFFTed.ipynb yields the following

    and on the analog envelope side (see jupyter notebook too):



  • Putting it all together

    kelu12406/11/2017 at 22:28 0 comments

    exI have tried with the latest 20Msps ADC pHAT I've assembled for the device. I've butchered soldering the 2nd ADC, and had no spare, so I skipped one of those. The issue in this is that I got 2 output pins of the ADC soldered together, so it outputs rubbish...

    Long story short.. here's my setup:


    and the output..


    All of this is managed through the Raspberry, so I'm quite excited, and eager to develop the API to expose proper data from the RPi through wireless interactions!

  • Raspberry Pi setup

    kelu12405/29/2017 at 19:54 0 comments

    Here's a tentative setup for the SDK. It's based on a motherboard exposing all interesting signals, a Pi (W in this case), an ADC shield (detailed here) which goes up to 10/11Msps, and the pulser as well as analog processing modules.

    Things to do now:

    • Exposing the Pi IP on the OLED on standy
    • Documentation as a webserver by the Pi
    • Web storage also through a webserver (in addition to the Pi SSH)
    • Getting a nicer ADC pHAT ... 20Msps on its way
    • Making the kernel module better (control of the pulse duration for ex - and getting additional infos if possible)
    • Doing a python server - acting to serve the signal through a dedicated API
    • Explore if additional pins can really be exposed through the pads.. and used.


    Beware, I had to use a 750mA 5V power supply for the USB power. It does use a tad of power as is!

  • Simplifying the ultrasound imaging debugger

    kelu12405/11/2017 at 20:05 0 comments

    Lots of water under the bridge. Since the last post! This project was born a year ago when I wanted to split a bigger board into smaller modules. I went on exploring different options, combination of modules, hardware, probes, motors, and DAQ (from STM32s to Beaglebone PRUDAQ, passing through onboard smaller ADCs), which yielded lots of interesting results. I really enjoyed exploring all of this, and really learnt a lot. Who know I'd do this when 18 months ago I didn't know anything about electronics hardware (or at least had forgotten all from the golden age of my studies?).

    Anyhow, the goal here is simple. I need a "exploring tool" to explore ultrasound systems. I have built several versions with Murgen, and have made the proof that it's possible to have a small ultrasound machine in your garage. However, I found more pleasure in building the tools and in the process of digging into the different components.. and that's what I want to explore in this project.

    Hardware is basically already built: previous lessons from Murgen bring the analog front end, a hack I have can be used to emulate a probe: what remains is to remove overkills on the circuits, and SIMPLIFY everything, making it more robust and more user friendly.

    The second step will be to have a good driver for the Raspberry Pi (which I believe is enough for my needs), to control the hardware, and develop a good enough server API.

    Once this is done, I'll be happy to test it with probes like the ATL probes I've been debugging, with doppler probes projects here and also to explore this chinese probe of mine.

    So, on with this project, and see if cross-pollination works =)

  • A first module: the analog front end

    kelu12407/10/2016 at 11:38 0 comments

    bGoblin is born! We received the module from the fab today. This small module is composed of:

    • A time-gain-control (or a VGA) to compensate for the ultrasound attenuation
    • An enveloppe detector, to actually get the echoes
    • An amp to better stretch the signal before it goes to the...
    • 3Msps ADC

    How does it work?

    Which, in functional blocks, gives:

    It works! Let's try it with a 3MHz burst:


    Or, if we buff up the signal: with the gain control, to make it better "readable" with the ADC:



  • Releasing two modules: HV Pulser and TGC+ADC

    kelu12405/07/2016 at 18:03 0 comments

    After Murgen, which was a all-in-one analog acquiring and processing analog board for ultrasound imaging, we're glad to pursue the adventure of the black company, with the release of Tobo (the HV Pulser) as well as Goblin (TGC+ADC).

    Tobo, the HV Pulser, connecting In and Out of the transducer. It includes the MD100 protection.Goblin: it takes the signal coming back from Tobo, and processes it for it to reach the ADC, which is a 2Msps SPI.

    These two boards, plus a 3.3/5V alim, a piezo and a controler (such as an arduino) are enough to do some basic imaging ! More on the Github repo here.

  • Automating the documentation process

    kelu12404/29/2016 at 15:11 0 comments

    Building an OSH project takes time.. especially on documentation. What about we build it like any other program? Let's throw in the Readme.md as source files, let's compile them with python, pipe it to GraphViz... and bam ! Graphs and magic documentation happen !

    Readme of the project here : https://github.com/kelu124/echomods/blob/master/Readme.md

  • What are the echomods

    kelu12404/26/2016 at 21:54 0 comments

    The principles of the echOmods is to enable a full chain of ultrasound image processing and hardware control. Four basic modules are considered. Each of this module will be landing on a motherboard, more or less a stripboard.

    Key interfaces, signals and alims will be available on each of the 19 tracks on the motherboard, and will enable communication between modules. However, some tracks can be unused by the modules.

    In this dense version, there are 4 modules electronic modules, the Transducer and the Motor modules are not depicted.

    These modules can have a form factor close to the arduino trinket pro, with a row of 19 pins on the side. Each module will have a function, as described below. At the heart of this project, there will be 4 modules, plus the motherboard. 2 of these modules will be SMD, 2 as modules based on stripboards. Two additional modules will enable replacing the transducer module and getting advanced signal acquisition/streaming, respectively

View all 10 project logs

Enjoy this project?

Share

Discussions

Jean Pierre Le Rouzic wrote 05/13/2017 at 05:52 point

You are right that the speed of sound in the body is around 1,500 m/sec and one millimeter wavelength is not possible at 45 kHz.
However it seems to me that even at 1,500 m/sec, at 45 kHz the wave length is still as low as 3.33 cm.

  Are you sure? yes | no

Jean Pierre Le Rouzic wrote 05/12/2017 at 16:10 point

You did a tremendous job!
What about doing something without any pulse at all? Pulse hardware is costly, as you told there is a need for a fast and costly AFE. What you really want is just to send and measure some discontinuity at some time.
* For example if you send a tone at a constant frequency, then change it to another frequency and measuring the delay in the receiver, you will still be able to do A-mode ultrasound, this time with cheap hardware, no need for an ADC.
* In addition you can do Doppler analysis on it.
* With only three piezo you can have a solid state B-mode by adjusting the phase of the three piezo and making interferences, which is impossible with pulses.
* Another thought: Why not dropping the requirement for high frequency signals
entirely? At 48Khz, the wavelength inside the body is less than one millimeter large. I
doubt much medical ultrasound can do better, except with a perfect
homogeneous phantom.
* In this later case why not using super resolution techniques with multiple low cost emitters/receiver?

  Are you sure? yes | no

kelu124 wrote 05/12/2017 at 21:08 point

too many ideas! And great ones to not make things easier ;)

I also would like to test cmuts with a multiplexer in front of it. With 8 elements, a good multiplexer, and an arduino for the pulse .. one can do synthetic aperture too - alleviating the need for mechanical stuff.

True for frequency sweeping!

  Are you sure? yes | no

kelu124 wrote 05/12/2017 at 21:11 point

a point though: speed of sound in body is ca 1500m/so, at 45kHz you'd have a 3.10-2m resolution. Not that good :/

  Are you sure? yes | no

kelu124 wrote 05/12/2017 at 21:13 point

Looking forward to testing this debugger tool on this famous doppler probe :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates