Mass production from Gadgeteer prototype?

Hi guys,

I am currently evaluating using the Gadgeteer platform for a small hardware project I have. My background is in software engineering and I am very strong in C#. But I have almost no experience with electronics, which is why the platform is so appealing to me.

However, I am worried about how I would go from prototype to mass production on the Gadgeteer platform. Is there anyone that has done this that can point me at material to walk me through the process? Specifically I’m wondering how I go about producing a design that I can hand over to a fabricator. What design files do I need, what software do I use, etc?

I don’t mind lengthy reads or learning new concepts or software. It would just be nice to have a little guidance from someone who has done it before :).


hi mikdav, and welcome to the forum

I am not sure how forthcoming some of the “commercial use” folk can be here, but needless to say there are people who have done and continue to do what you’re thinking of.

Much discussion comes from the “scale” of your commercial project. If you’re going to sell 10 or perhaps even 100 devices a year, perhaps using Gadgeteer components directly is still a sensible approach. At some point your scale becomes a trigger for needing to move to a custom design (or it might be other factors - space constraints for example).

Many of the commercial use discussions that are scattered here on the forum imply that those commercial teams have electrical engineering experience doing the PCB design and layout work, so that may be a consideration for you since you don’t seem to have any.

One other good factor is that many of the products have open designs, and the task then almost becomes a “cut-and-paste” of the building blocks you’re leveraging. So here’s one of the things I would suggest you look at to see how comfortable you may be with all this. Go over to the resources section on the Raptor board, and download the eagle files for the board design. Go and get the appropriate copy of Eagle to evaluate this work, and open the schematic file. To produce a set of board files to have the PCBs made, you would need to export from these files (into “gerber” files, but that’s not relevant for you yet). You can also open some of the Gadgeteer modules equivalent schematic/design files and you can get an idea of what you would need to do to merge those components onto a single board.


Thanks, Brett. Yep, you hit the nail on the head. We have scale, cost, and space constraint issues that make us want to go to custom fabrication.

The project is for internal use to replace some of our more costly manual processes in the field. We would be consuming somewhere between 1000-10000 units a year. It needs to fit into a space about 1.5" x 1.5", and we were hoping to produce it for $50-75 unit including the compute, a CAN module, and a GSM radio. I don’t really know if that is possible at this point or with this platform.

I’d like to stay NETMF if possible since we have a lot of organizational knowledge in C# and the firmware is what we care most about. It needs to make calls to ssl-based web services in our backend and we would like to spend most of our time worrying about that software and not the hardware around it.

Probably the best way for me to proceed is to produce a working prototype based off of Gadgeteer to convince executives to fund the project. Than ask for $10-30k in funding for a hardware consultant to layout a minimal board for us based on NETMF (in addition to fabrication costs, etc).

But I’m guessing when I do that, things get a lot more complicated. Instead of the simple Gadgeteer libraries for controlling the GSM network I’m guessing I’ll need to write new libraries to control whatever specific GSM module was chosen in the custom board. Same for the CAN module, etc. Is this a bad assumption?

Thanks again, Brett. Is that going to be my most sensible approach here? Any more advice for a software guy feeling like a fish out of water?

This game an an idea while working on this book so I added a small section about production

(book is still a draft)

1 Like

@ mikdav - When using Gadgeteer, you should put your “business” logic into separate modules/classes/libraries from the Gadgeteer framework specific code. Then, when you commercialize, you only have to code for the production “framework”.

Rather than the business logic handling an Output port, is should handle a state change of the external stimuli. It would be worthwhile to spend a little time experimenting with doing the same things in pure MF and then Gadgeteer. This will give you a feeling of how both work, and help you to architecture you application to ease the transition from prototype to production.

1 Like

Thanks Gus and Mike. Good advice from both of you. Great to know that GHI provides consulting services.

Good advice! I would go further and say, if you are doing a “commercial” development consider using pure NetMF at the beginning of the prototype. Now I use Gadgeteer to experiment with the modules, but the actual prototype uses pure NetMF.

Thanks, kiwi_stu. From everything I’m reading, it appears that may be the way to go. Right now I’m not even at the prototype stage. I’m more like at proof of concept.

So I’m thinking I will have three steps:

  1. Proof of concept based on Gadgeteer in order to be quick (I think I can get this done in a day or two) and cheap (<$300 hardware). This will be used to demo and justify funding the project.
  2. Prototype based off of pure MF.
  3. Custom PCB and mass production.

I figured I would need to break 1 & 2 out due to cost. I’m used to working at a much higher level of abstraction than pure MF and so I would have to invest potentially weeks or months to get a prototype done, which I probably shouldn’t do without approved funding.

Am I overestimating the cost difference in terms of ramp up (remember I’m a software engineer) and component costs between 1 & 2? I feel like I understand Gadgeteer from the docs and it fits well within my realm of expertise. Pure MF is still too nebulous to me and therefore seems expensive in terms of time. I would love to skip a step if you have any suggestions on quick ramp of to NETMF for a non-hardware guy.


IMO, having come to Gadgeteer from a software dev background, this seems like a sensible way to approach it. Once you’ve spent some time with Gadgeteer, getting deeper on NETMF will be more approachable, where if you were trying to build your proof of concept with NETMF, it would probably be more time-consuming and frustrating.

Do keep in mind, however, that unless you’ve already validated that there are Gadgeteer modules for all of the components of your proof of concept, you may need to do some things using breakout modules and/or breadboarding. That’s not terribly difficult, but it will mean going a bit deeper under the covers of the Gadgeteer abstraction layer.

In addition to having the forums available for questions, you should make sure to take advantage of the search box at the top of the page to search both the Codeshare community section, as well as the Documents section of the GHI website. Both have a wealth of information that you will likely find helpful. And in the case of the documents search, it’s not a bad idea to click the “include obsolete documents” link, as there are sometimes useful tips there, too (and it’s the only way to find the docs for discontinued products, if you have any).

For example, if you search for “Digital” in the documents section, you’ll get a nice list of documents for dealing with Digital I/O:

Hope that helps!

remember that you can still use the gadgeteer hardware while coding in pure netMF. Thats a great way to take the hardware uncertainty out of the loop. It can be tough to debug something when you don’t know if the problem resides in the software or hardware domain. And without some minimal test kit (DVM and oscilloscope) it’s really really hard. when the hardware is known to work the software is not really much different than any other software project.

The SoM modules are GHIs commercial offering. This means that they aim to provide longer availability. The gadgeteer ‘hobiest’ boards are a bit more likely to change.

1 Like