The project is about providing an ‘Arduino of ultrasound’ to researchers, academics and makers, simply because nothing existed in the market. I was a research engineer at Philips in medical imaging around 15 years ago. It was a great opportunity to work on low cost medical imaging devices, where we got to a proof of concept working with an OLPC (One Laptop per Child initiative). A few years passed, and in 2014 I met with Mehdi Benchoufi and we had an initial discussions for what became echOpen afterwards.

Mehdi, Pierre, Olivier and I, started a project, which became the echOpen association. We wanted to post the technical project of having open source with ultrasound. I spent less time with the association in 2016 or 2017 because I wanted to focus on something that would be used by makers, hackers and layman while echOpen took a different approach, going into making a medical device. At this time, I started to experiment more on the hardware components. This was initially a functional block approach, where each block captures a function, allowing one to swap modules and try different approaches.

That worked relatively well, and confirmed the interest from a couple of individuals, the core of the community. Along with this initial pitch, the design got more mature and more integrated, leading to the first product. The un0rick board is interesting as an approach. I am not an electrical engineer, and knew very little about electronics design.The open source approach allowed me to get in contact with the right people to help with the toughest electronic parts, and we got to a design that is far from perfect but still in use today.

The more I knew about the project, the more I was able to concentrate on my skills and vice versa. I improved my skill and by this the complexity of the project.

This went well until the pandemic in 2020 and the supply shortage. the project could not move forward, as I could not try new designs or build new boards. Therefore I stopped developing the product. Then, we started a smaller version of the board - smaller, and also cheaper, and it has a bit more performance. Today, we work mostly on new parts like the raspberry pico chips, opening exciting doors.

What was done for Ultrasound can theorically be replicated in the MRI space. If we look purely at the technology, we are talking about signals in the megahertz range. What we’re discussing right now is to what extent we could build a common tool, a basic Arduino, that could be used for both technologies, ultrasound or MRI.

The core benefit is to provide an arduino of ultrasound. And for me, to have a blast and learn while contributing to the commons.

The side benefit is to generate something you don’t keep under lock and key. I see the value in the commons, and egoistically I also benefit to know that what I made benefits others. Apart from this, the greatest benefit is that I like to believe my users are getting access to technology that they wouldn’t have access to normally. Users are academics who want to have a system to test ideas. I have also seen startups using that to develop proof of concepts, teachers to have a demo tool for their courses, institutional organization collaborating to build customized solution.

It is mostly funded by me as an individual. The community helps keeping the cost down when doing a batch. As an individual maker, I have no structure in terms of business, this is a side project, and it has no official structure.

Funding is a good question. I cannot get funding or institutional support, because one needs to be affiliated to an institution to register on any research publication institute, so it’s impossible for me to get that kind of support.

Similalry, I have tried publishing articles about the open hardware, methodologies and sources I’m using, but I’m not affiliated with any lab, which makes classical publicationdifficult Hopefully, this is something recognized by the open source imaging community, and I am sure there will be initiatives to tackle this challenge.

That’s a good question. I spent maybe between 5 and 10k out of my pocket over the past few years, in getting batches out, but I’m not necessarily keeping track of the ad-hoc, smaller parts bought for tests and experiments. Part of the larger batches do help keeping the cost of prototypes acceptable.

I guess an open source starts with documentating an idea. I just started with documenting what I was doing for my own purpose. When you progress on a side project, on some evenings, weekends, from time to time: you usually come back to the table with no memory of the details of what you were doing. It is definitely helpful to keep a lab log, for you first, but also to ‘build in public’.

The documentation brought the interests of some people and publications. I’ve done a couple of publications since, on, for example, the Journal of Open Hardware. That helped raise the profile of the project.

People usually come to the documentation, then to me by email and/or to the community open Slack channel (to allow people to talk to me and to a wider community). Some physical interactions occurred when a few current members came through Paris or London and we met to chat in meetings, like what we did in Grenoble in 2022.

I don’t want to be a bottleneck in the community communication. If I were to be hit by a bus tomorrow, I still want the community to organize itself. There are also opportunities to meet with the wider open communities, especially with echOpen, and the wider open imaging community.

The community is pretty much organic. Today, on the Slack are around 240 participants, the community is bigger if you consider people who have an interest for school or an academic project who would be active for 6 months and then leace. The activist circle would be five people, the authors of the paper we published.

One could say there are no real issue because this is a side project. Nobody’s life depend on it. If someone is rude, they get ignored. If there are no resources, development is put on hold. The major bottleneck is time. As a side project, it progresses when people want to, and have the time to.

There is a minor bottleneck which has been the components shortage over the last years and it froze the project’s development. No new boards could be shared.

Another challenge usually is that building hardware takes time. But in this case, it is a benefit. As a side project, if you have to wait two months for a board and you can’t do anything, well, just freeze for two months, just doing some community management. And because it’s a side project, there is no added stress.

It’s pretty much organic and defined in the long term, so a slow pace fits our objectives.

It’s pretty much organic and defined in the long term, so a slow pace fits our objectives.

It’s pretty much organic and defined in the long term, so a slow pace fits our objectives.

As this is an informal community, there is virtually no governance nor governance processes. From a technical perspective, people making the decisions are people doing. They make decisions based on their requirements.

I sometimes collaborate with organisations. These organisations share their requirements, and we discuss past learning and opportunities to improve. They lead on the decision of the joint project, which, when possible, can be brought back to the community, if they develop new things that come back to the project. The agreement is that I advise them on the points they do not know, and in exchange, they put technical and professional skills into this joint effort. A good example is the latest iteration of lit3rick board. It has been co-designed by professionals from a Canadian institution. They have come in with specific needs, but also excellent electrical engineers, and together we optimized the previous iteration.

Coming back to the decisions, the project does not have a specific roadmap. It’s just what is interesting to pursue at the moment. The perfect example is what we’d like to do with open MRI initiative: there is definitely a good intellectual challenge there, and we will learn from both modalities and this will allow us to build something new, hopefully better.

The first was the Murgen board, which was a BeagleBoard add-on, similar to the ‘hats’ on the Raspberry. We came back to a module-based concept where the different functional blocks of the hardware split into individual physical elements, named as ‘echomods’ project. The next iteration was to integrated lessons from the modules into the ‘un0rick’, an integrated, slightly overspecced design, and its ‘lit3rick’ counterpart, which are smaller, approximately the size of a Pi Zero. Today, i’m still working on the smaller raspberry pico chips.

The device is electronics at heart. I do not have the space or resources to do more like building the board physical transducers (or sensors) or the mechanical aspects.

The device has its own gateware. FPGAs (field-programmable gate array) have been historically under proprietary tools. Fantastic work was done by Claire Wolf and team on developing an open source tool chain for a specific family of FPGA. This work was fundamental for the integration of the modules design in a single board, to allow users do things but also make it user-friendly. This in turn helps the end user, not me, to get the gateware they need. A very good example of that is my work with a non destructive testing (NDT) team. The team did not know anything about FPGAs, but with the visual editor interface, it was easier for them to get their own gateware, by tweaking variables.

Fantastic work was done by Claire Wolf and team on developing an open source tool chain for a specific family of FPGAs, which are highly configurable integrated circuits. There are both VHDL and Verilog (hardware language for FPGA) designs, but I must say the open-source toolchain has been a game-changer.

The lit3rick is market ready. It’s to some extent due to the collaboration with professionals in the sector who also tested the device. The un0rick has been around for a while so that would make it market ready, too.

All the source files are shared and are openly accessible. Most of the electronic files are Altium or Kicad files, and we’re trying to move more towards KiCad which is more open.

Some users did their own batches through fabs and produced it on their end. I know of people who have used the designs for their own purpose and they have reused some parts completely, and did some slight adjustments to other parts before sending it for production. I also spotted forks of my designs for tangent purposes, namely tomography. It was good to see the design was reused, even if these specific people fail to mention our project in their description. When people are cooking what you’re often cooking, it’s a good sign for the recipe.

Absolutely. And the great thing is that they also come back with more questions about your initial design and that helps cross-pollinate both projects!

The initial objectives was to get something like an arduino of ultrasound that I could play with. And then I realized that the documentation was really needed to achieve that, especially if I wanted it to be in the public space.

The documentation itself became a priority, seen as a lab log. I created scripts scripts to help classify and manage the information and data (pictures, screenshots, gas) generated during experiments. The data itself of the experiments is tagged with metadata that allows to find back what were the conditions of the experiment. The same applies to pictures, using for example the EXIF tags. I have been running the scripts since 2016, and they are still used in generating the documentation. It’s been real helpful not only for me, but also for example to onboard people: I can point them to a session where I tried tomography and where we would find the gateware for the FPGA. They would find the corresponding scripts , and reuse them relatively easily. That became the primary output. The community is a byproduct of the work on the hardware. I have no objectives when it comes to the community. We can say fun is the number one expected output.

There are a couple of papers that are not exceptional, to be honest, but at least the knowledge is out. There are two papers in the Journal of Open Hardware, plus a couple notes on Zenodo. These note usually are PDF that double as zip files: you get access the source files by renaming and unzipping the PDF. The rest of materials, more day to day related, is archived on GitHub.

Project is mostly electronics so you will find the usual gerbers, BOMs, and kicad or altium files. There are no mechanical elements, so we have no CAD files. When I’m doing an experiment, I’m sharing the data of the experiment. It’s hard to keep track of what I’ve done during the experiment.

Hardware files and documentation in general lives mostly in GitHub. The core publications are online material, which would be in GitHub and Zenodo. I think we used arXiv for preprints, too.

I choose GitHub because that’s easy and universal tool. It provides the version control system. I choose Zenodo because I wanted to have an independent platform to store notes a get a DOI for further referencing.

The learning curve for GitHub is low if you’re doing software already. Zenodo is also straightforward.

I experimented with a platform called upverter, which is an online hardware editor. Some designs are still available there but not maintained, as I’m trying to keep the constraint of using open, commonly used tools.

Apart from holiday pictures, I’ve published everything I’ve done. I believe most topics are documented, even things that might be less relevant for users. When it comes to the hardware, everything is published.

That’s another good question! You can be successful if you know your objectives - and I have no objectives apart from having fun. I was successful as I have fun. I had a lot of frustration due to the component shortages during the pandemic. If the supply chaine is broken, I can’t do open source development anymore.

Meeting a dedicated community was an unexpected positive experience.

It strated with my frustration of not being able to contribute to the commons in the company I worked for. I do believe that giving back to the commons and being open are some of the ethics when you’re into technology. It’s about how we can, as individuals and organizations, safely contribute and give back to the commons.

It depends on your metrics. I’ve done a bit of publication on Hackaday at the beginning, where the project has close to 2800 followers. Our slack has around 300 users, which is my only metric for the moment. Say 2800 interested, 300 talking members, 10 to 20 doing actual development, and possibly 10 to 20 papers or theses using the hardware.

Most of them are ultrasound professionals, researchers, or start ups. Startups usually seek hardware, equipment and advisors. There are also teachers who use the devices for their courses.

If you look at the map of the purchases, there is a higher density, for example, in east Asia, with a very strong medical imagery ecosystem as well. In the USA or Europe, the orders come from mostly universities, a few startups and individuals.

Maybe to 10 to 20 people have regularly contributed and 5 to 10 have rarely contributed.

I’m not finding them, they are finding me. I’m currently not really active, but maintain a room open for discussion. People drop by and some stay, and contribute if that aligns with their needs and aspirations.

Our communication channel is open about what is happening at a given point: the community members have their own projects and talk about them, and what they’re doing. I can coordinate by saying here is X and they are doing Y.

Users in general benefit because they have access to dedicated, simple hardware. Contributers are usually curious people. They are looking to learn and try things, like me. Maybe that’s a bias in selecting and engaging with the community. Most of the active contributors have this willingness to share back. A couple of professionals wanted to have tools and are staying because they found a cool place to share and communicate. One of the categories of the contributors would be academics and researchers with an obligation to publish. With that respect, they’ve shared, for example, a master thesis or their research work.

I benefited by learning and talking to people with great ideas: people that came in are amazing. It’s also about this intellectual challenge. I am not an electrical engineer, but a research engineer and having a physics or electronics challenge is refreshing.

Yes, definitely. Hardware takes time and you need to take time. That allows you to reflect on what you do. I also like this process because it give me a different perspective on software development. Definitely would do it again.

We are discussing the same adventure in a different space right now with an opportunity in the open MRI space. Right now, talking with the community (mostly in Berlin) is opening a door to the next challenge. I’d definitely love to access to an MRI machine, better understand how it works, and work on the open-hardware magic!