Table of Contents
What is this hardware (and accompanying firmware and software)?
The HDL-0108-RSCPT is the “yes” answer to these questions:
- Can we design a low-cost, simple, reliable, 8-channel, modular/scalable, rapid-scanning ultrasound platform suitable for mobilized NDT scanning applications like robotics and hand scanners?
- Can the data processing required of this data match the processing that works for our prior NDT electronics?
- Can it be something we (you) can drop right in to our (your) system so we (you) can control it and run its data through our (your) data pipeline?
- Can it be easy to customize in all sorts of ways? (Yes, truly, all sorts of ways!)
- Can it be tweakable for R&D?
- Can it be easy to interface to software? Will you (we) provide the full suite of examples?
- Can it be easy to customize using only open source and/or free-as-in-no-money development software and development tools?
- Can it be easy to work with, requiring only a couple of extremely low cost interface cables, like USB-serial converters?
The answer to all of these questions, is “YES” and this is the hardware plus firmware and software examples that say so. The accompanying firmware(s) and software show how simple it is to interface and to customize. This platform can be used as a “seed” – to grow and determine additional features that would make the hardware stellar, and still low cost, in other specialty applications and expanded use cases.
There is no doubt that there is a world of bench top and mobile NDT systems out there from the big names, and they are a different category of product altogether. You may find those more suitable if you’re focusing on specific NDT services requiring them, or you need a lab quality system that can span all ranges of potential applications, with the focus being on the physics and the output data, as provided by the vendor. The cost and limitations in system automation and integration options will of course mirror those needs. Think Arduino/Beaglebone/RasPi versus MacBook Pro or a Dell Server. Or something like that. Point is, this project was never intended to create a product equivalent to what already exists for polished, bench top or field rugged, multi featured, multi application, systems for wide-ranging NDT services or laboratory physic research. Though indeed, it is capable of parts of all of these applications anyway. These systems often include embedded PCs and other such related PC peripheral items. Anyway, it’s a different category of product.
What are examples of things we can customize?
There are notes and examples scattered through out this Q&A section. Here’s a condensed list of examples in a single section:
- Pulse voltage – swap the module to achieve your range, adjustable in steps, fully software programmable.
- Narrow band frequency selection, and broadband options – program your pulse characteristics, and program their select-ability real-time or fixed; update filter components on the board if the stock range doesn’t work; implement digital filters on the capture control hardware or in software in addition. Update the firmware for the sample rate and sample lengths, as appropriate. The footprint for the highest sample rate ADC on this simple little board is about 100MHz. Just get in touch if you’d like help at any point. With customization, a working range is probably 100kHz or lower to about 25MHz. And again, we can always rev the hardware, for hire (and probably will with time anyway). No problem.
- Pulse channel sequencing and pairing – just update the firmware(s).
- Piece together (the already long) sample windows for extra long sample windows, for example to be able to track offset distances along with late-in-time phenomena – update the firmware(s) and software.
- Drop a new additional serial interface into the capture control hardware using vendor IP blocks, or roll your own, even a simple single or double line shift register for storing configuration or expanding real-time control options.
- ADC (low frequency or DC) sampling, as an auxiliary: More notes on this to come. Tested and functional however.
- More examples coming … just scratched the surface…
Is this open source?
Yes, the firmware examples and the software example will be released as open source and are currently governed by copyright and MIT license. If you want me/us to implement something that is proprietary, you should probably not ask about it without disclosing it as such, or you/we should set up a code management situation where that code is not included in the public release. Or just customize in-house, maintaining the correct license procedures.
Hey, you know those sliders in the demo App, how do we add control like that for other things, like pulse with (frequency) and pulse type selection?
Yep, just modify and customize the firmware(s)! There are a LOT of options and solutions. Ask me/us for more details about how. You can expand this platform in a lot of ways. Just start digging in. Or we can do it for hire, no problem. Yes, imagine: pulse patterns, frequencies, patterns that change in time sequentially, self-adapting and tuning feedback for parameter adjustments, all kinds of things could be done here. The world is your oyster, and in many ways, this system can be a blank slate (or partially blank slate).
What about bipolar pulsing?
Yep, there are solutions we can discuss. For simplicity, like our previous flagship hardware (and firmware, etc.) and its derivatives, the pulse section is a negative pulse design. There are options to interface with the board(s) to create bipolar pulses, or for us to simply implement another design in a revision.
Hey, I see “stuff” in that live waveform, like flicker, or etc.!
Yeah, this App makes it a snap to zoom in to a high level of detail with a large screen view while holding the same place in the waveform during a live, high resolution, high frame rate real-time streaming video-like data view.
This is a really good thing.
Maybe your in-house software already does this too for your existing hardware, maybe not. Make sure you’re thinking about comparing apples and apples. And make sure to review what the objectives are for the data and the system overall, including what characteristics matter and when.
But what’s happening is that you get to see stuff you may never have seen before in equivalent equipment. Live and real-time. And at rapid frame rates.
There’s a lot to say about this, and about potential changes, revisions, re-spec’ing, adding shielding, etc. Feel free to ask about whatever grabs your attention and we can discuss.
Hey, your App doesn’t show/have/look like such and such awesome feature the way that our in-house system does!
Right-o. Perfect topic for clarification. Your in-house software is probably awesome. And the product of a long or large development commitment and effort.
This App here was rapidly developed and designed to demonstrate how to do basic functions with the hardware. So that you can take those basic functional blocks and plug them in to your own awesome in-house software. What are the commands, responses… what’s a good way to handle the streaming data buffer, etc. It would be wasted effort to develop something that you won’t be using and instead will be developing in your own in-house software. There are so many routes for development!
This App does happen include a bunch of bonus demo features, to get up and running with the demo software framework, if anyone perhaps decided to switch over and use this framework versus your in-house framework. Or if anyone otherwise found inspiration from the App for application to your in-house UI/UX. But, yeah, it provides a known working functional block of collected examples to be able bench test the hardware and your custom software integration.
Chances are, whatever you are asking about is already on the long term wish list for this App (DacqMan), so it is nice to know what you’re interested in anyway. All good. And if you’d like to accelerate the inclusion of a feature into this software, instead of in your in-house software, contract terms are available to make that happen.
My customer wants us to build a system that does some extra stuff too, that isn’t 8-channel ultrasound scanning. Can we use your board for this too?
This board, the HDL-0108-RSCPT is designed to do a really good job at rapidly scanning 8-channels of transducers for NDT and getting you that data, streaming to your system for mobilized applications.
So, extra stuff is probably out of scope for this hardware. (Why isn’t my mountain bike a good choice for also shining my shoes? Oh, well, I guess we could probably figure out something if we had too…)
But, yeah, your customer’s question is in scope for building a custom system as an integrator, altogether, as you can assemble and integrate all sorts of other components, if you need to widen your offering for types of scan data that you provide to your customer, while your doing a scanning job.
Another way to say that is: For example, if you’re also controlling a robot, why not integrate those extra needs into the robotics system. There’s probably plenty of extra room for power and data needs, and real-estate too.
But wait …
Yeah, I know, but, we have really tight constraints for the project, is there any way you can help us meet the other needs outside of the ultrasonics with this hardware too?
Gotcha. Yeah, let’s look at this together. Assuming that your extra data acquisition needs are sampling essentially DC voltages in the 0 to 3.3 volt range, you could carefully update the firmware(s). Re-allocate a pin at the proper stage in the firmware’s control cycle, to be an ADC pin and read accordingly. Update your comms firmware and software components to transmit and format that data as needed as well, and work it into your newly customized streaming data scheme. See notes above, and note that an example exists i the MCU firmware for on-demand sample grab. Or you can create or use a small “child” board that samples and formats the data into some digital interface, I2C or SPI. You might want a “child” board anyway for analog signal conditioning and protection. Then try implementing the SPI pins on the board, instead of allocating one for ADC.
In any case, if you want to explore this, I/we can help design any part of this that you’d like. At your request, I/we can help you identify suitable pins and documentation for how to test and implement such things.