Live data from Hacker News

Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

un0rick.cc

11–20 of 36 posts

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#11
post #9
post #7

Earlier quoted context omitted.

Ultrasound processing is actually pretty niche: you have a whole bunch of channels with a very high sample rate (tens of MHz). In the case of medical ultrasound, a typical handheld ultrasound probe can have range from 50 to 150 parallel channels. Because you need fast, parallel DSP, FPGAs actually really shine for ultrasound. And because production volumes are relatively low, the NRE to jump to an ASIC generally isn'…

Today a graphic chip is also good to compute ultrasound images. I suspect that you can even do it on a CPU. I'm not sure if it is that practical to process in a FPGA if you want to compute non-potato image quality: you would need to handle tons of data by the FPGA, so either use a gigantic one (with a ridiculous price) or somehow page the data (but that's quite complex to do then...) -- this seems way more difficult…

Its not just about the compute, but also the data acquisition. You can connect directly to your ADC without extra glue logic (and in some cases use the one embedded on the FPGA). Also a GPU is a lot more expensive than a $20 FPGA.

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#12
post #9
post #7

Earlier quoted context omitted.

Ultrasound processing is actually pretty niche: you have a whole bunch of channels with a very high sample rate (tens of MHz). In the case of medical ultrasound, a typical handheld ultrasound probe can have range from 50 to 150 parallel channels. Because you need fast, parallel DSP, FPGAs actually really shine for ultrasound. And because production volumes are relatively low, the NRE to jump to an ASIC generally isn'…

Today a graphic chip is also good to compute ultrasound images. I suspect that you can even do it on a CPU. I'm not sure if it is that practical to process in a FPGA if you want to compute non-potato image quality: you would need to handle tons of data by the FPGA, so either use a gigantic one (with a ridiculous price) or somehow page the data (but that's quite complex to do then...) -- this seems way more difficult…

You don't understand. FPGAs are not used for their computing prowess, but for the ability to do highly timing sensitive parallel data acquisition. At 64 Msps you have Their most important feature is determinism. You can reason about and get an upper bound on how long something takes even while programming them.

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#13
Seems worth mentioning that incorrectly used an ultrasound can burn bones. (Specific frequencies in bony areas moved too slowly).

I didn't do enough research to understand this (but just enough to verify it). I learned it initially from my wife who's an NP. When I mentioned a previous DIY ultrasound article to her she looked skeptical and mentioned the risk of bone burns.

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#14
post #9
post #7

Earlier quoted context omitted.

Ultrasound processing is actually pretty niche: you have a whole bunch of channels with a very high sample rate (tens of MHz). In the case of medical ultrasound, a typical handheld ultrasound probe can have range from 50 to 150 parallel channels. Because you need fast, parallel DSP, FPGAs actually really shine for ultrasound. And because production volumes are relatively low, the NRE to jump to an ASIC generally isn'…

Today a graphic chip is also good to compute ultrasound images. I suspect that you can even do it on a CPU. I'm not sure if it is that practical to process in a FPGA if you want to compute non-potato image quality: you would need to handle tons of data by the FPGA, so either use a gigantic one (with a ridiculous price) or somehow page the data (but that's quite complex to do then...) -- this seems way more difficult…

Not really: people have reacted to more capacity being available by getting in more channels. You can control a 1980s 20 channel ultrasound using even an atom cpu, not a problem (though will still get close to max cpu capacity). So what did we do ? Well we made chips, I believe the best one now has 4000 channels and there's test models of 8000 channels. A quad xeon can't process that. But it gets worse.

Because information is encoded both in the direct signal and in the interference patterns between different probes you'd want to evaluate both of those (if nothing else it gets you a wider field of view, but really it gets you more than that, for instance you can get full 3d from a cross-shaped array). Unfortunately that scales with the square of the number of channels. This doesn't even work on FPGAs at the moment, so they basically limit interference processing to only 100 or so of the 1000-2000 probes they have these days.

This is a problem that keeps coming back. CPUs can do nearly everything in processing, but with one exception they suck at it.

That means that when doing these things, you can use CPUs, and people are always pushing that, if you accept to be 2-5 years behind the state of the art for advanced applications, or you accept that you have to spend 50$ per piece where others can get more processing done for 1$, or "much less but still enough" processing done for 0.1$ (FPGA, DSP, microcontrollers, ...).

Good luck in the marketplace if you go CPU.

CPUs work where your complexity is above a quite high lower bound, and they stop working once you hit a certain level of data processing. Below that lower bound, they are absurdly expensive. Above the data speed limit they just can't keep up.

Now there's niches where the strengths of CPUs outcompete other approaches. For instance, you want to create stuff to interface with ancient equipment. Lots of that is necessary, and lots of it is custom. For telecom companies, banks, factories, ... here CPUs and the fact that you can do one at a time are tough to beat. Sure FPGAs can do it better, but that's not the point here. They're much harder to design, so a one-off (or couple-dozen-off) designs use CPUs, plus they're very unlikely to hit the data rate limits.

Even there CPUs tend to have a disadvantage. Lots of environments where these things have to operate aren't exactly pristinely clean, cooled and free of static and interference. CPUs don't deal with it half as well as especially FPGAs do. You want a closed box that has to operate at 70 degrees without cooking itself with constant electrical arcing around it ? Don't go for a cpu on a large mainboard. You can't cool because any cooler will get clogged and destroyed in a matter of weeks at the most.

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#15
post #9

Earlier quoted context omitted.

Today a graphic chip is also good to compute ultrasound images. I suspect that you can even do it on a CPU. I'm not sure if it is that practical to process in a FPGA if you want to compute non-potato image quality: you would need to handle tons of data by the FPGA, so either use a gigantic one (with a ridiculous price) or somehow page the data (but that's quite complex to do then...) -- this seems way more difficult…

Not really: people have reacted to more capacity being available by getting in more channels. You can control a 1980s 20 channel ultrasound using even an atom cpu, not a problem (though will still get close to max cpu capacity). So what did we do ? Well we made chips, I believe the best one now has 4000 channels and there's test models of 8000 channels. A quad xeon can't process that. But it gets worse. Because infor…

Great information there!

Perhaps sounds like a use case for a streaming parallel ADC board into GPU memory? Maybe an FPGA can run ADCs and buffer into a FIFO and transfer over PCI in large, efficient frames?

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#16
post #13

Seems worth mentioning that incorrectly used an ultrasound can burn bones. (Specific frequencies in bony areas moved too slowly). I didn't do enough research to understand this (but just enough to verify it). I learned it initially from my wife who's an NP. When I mentioned a previous DIY ultrasound article to her she looked skeptical and mentioned the risk of bone burns.

I have never heard of this being an issue for diagnostic ultrasound. Since I’m trained in (cardiac) ultrasonography, I think this would have come up... I also did a brief lit search and didn’t identify any obvious examples.

I suspect your wife is referring to therapeutic ultrasound, which can damage bone [1]. But this is not the ultrasound people are getting of their heart, abdomen, or pelvis in general.

1 = https://www.ncbi.nlm.nih.gov/m/pubmed/11731056/

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#17
post #13

Seems worth mentioning that incorrectly used an ultrasound can burn bones. (Specific frequencies in bony areas moved too slowly). I didn't do enough research to understand this (but just enough to verify it). I learned it initially from my wife who's an NP. When I mentioned a previous DIY ultrasound article to her she looked skeptical and mentioned the risk of bone burns.

I have never heard of this being an issue for diagnostic ultrasound. Since I’m trained in (cardiac) ultrasonography, I think this would have come up... I also did a brief lit search and didn’t identify any obvious examples. I suspect your wife is referring to therapeutic ultrasound, which can damage bone [1]. But this is not the ultrasound people are getting of their heart, abdomen, or pelvis in general. 1 = https://…

Even diagnostic ultrasound has been implicated in foetal brain damage (through cavitation). And ultrasound operators are known to often suffer from damage in their dominant hand.

https://onlinelibrary.wiley.com/doi/full/10.7863/jum.2009.28...

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#18

Earlier quoted context omitted.

I have never heard of this being an issue for diagnostic ultrasound. Since I’m trained in (cardiac) ultrasonography, I think this would have come up... I also did a brief lit search and didn’t identify any obvious examples. I suspect your wife is referring to therapeutic ultrasound, which can damage bone [1]. But this is not the ultrasound people are getting of their heart, abdomen, or pelvis in general. 1 = https://…

Even diagnostic ultrasound has been implicated in foetal brain damage (through cavitation). And ultrasound operators are known to often suffer from damage in their dominant hand. https://onlinelibrary.wiley.com/doi/full/10.7863/jum.2009.28...

> ultrasound operators are known to often suffer from damage in their dominant hand.

Do you have a citation for this? I don't see anything about it in your link.

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#19
post #8
post #2

The github is a little more descriptive and answers a few more questions: https://github.com/kelu124/un0rick/ (though don't expect all your questions to be answered here either). I'm curious what the FPGA approach offers above a regular CPU/DSP approach in plain English (quod non intellegunt: technerdese attracts followers, latinnerdese less so). I've been interested in FPGA's since dabbling with them a couple years…

As in all engineering related choices, there are tradeoffs that make the decision between FPGAs and DSPs: Similarities: ->Both are specialty items, with specialty dev. environments and proprietary libraries. ->Both are designed to do fast processing of highly parallel data (DSPs are known as VLIW processors, at least in all of the architectures I'm familiar with). ->Both require knowledgeable specialists to really ge…

One thing that might tip the balance in 2018: there's a growing familiarity and body of open source knowledge now around fpga signal processing among the sdr community.

There are now a lot of well documented open source fpga-based data acquisition boards being sold today at comparatively rock-bottom prices - we just call them sdrs.

The bandwidth requirements for ultrasound would seem to fall easily within the open source state of the art.

Re: Show HN: FPGA Ultrasound Imaging on a Raspberry Pi

#20
post #12
post #9

Earlier quoted context omitted.

Today a graphic chip is also good to compute ultrasound images. I suspect that you can even do it on a CPU. I'm not sure if it is that practical to process in a FPGA if you want to compute non-potato image quality: you would need to handle tons of data by the FPGA, so either use a gigantic one (with a ridiculous price) or somehow page the data (but that's quite complex to do then...) -- this seems way more difficult…

You don't understand. FPGAs are not used for their computing prowess, but for the ability to do highly timing sensitive parallel data acquisition. At 64 Msps you have Their most important feature is determinism. You can reason about and get an upper bound on how long something takes even while programming them.

Determinism is certainly a huge part of it, but FPGAs are insanely badass at computing prowess - you can create a custom architecture to execute whatever it is you're trying to compute.
Post reply on HN