Data Acquisition Module

Check this out The Ultimate Raspberry Pi & Maker Store– The Pi Hut

This reminds of arduino where the “shield” does more than the actual mainboard does. Not an ideal approach since you are now losing NETMF built in capabilities, like file system and graphics. I do not think System.IO will work with this SD card. Same way as how NETMF Graphics (and glide) will not work on this Raspberry Pi Store | The Pi Hut

Still, it is a good idea, a Data Acquisition Module. What I like to see is that same module but with dasylink so you can chain multiple of them on one socket. I see @ GMod(Errol) is coming up with modules on the fly lately so he maybe our hero to finish this in a weekend :slight_smile:

What would be very important addition to such module is isolation. I have been looking at RS485 Data Acquisition options and they are all very expensive, $500 expensive! So this maybe the way to go.

Hi Gus,

Check this out The Ultimate Raspberry Pi & Maker Store– The Pi Hut

I do not think System.IO will work with this SD card.[/quote]

That’s a nice looking module. I ordered one…and am looking forward to playing with it soon.

I don’t represent Nwazet but to answer your question in part: I believe that this module went into production by Nwazet before GoBus 1.5 was announced. With an in-field update to GoBus 1.5 firmware, you could certainly use the built-in System.IO classes with the DAQ’s SD card. That’s how the SD Card GoBus module (using the same STM32F0 micros) works.

In the meantime, I believe that Nwazet provides classes to use the features today (much like how Gadgeteer has its own replacement classes for many built-in NETMF classes).

The primary goal of GoBus is to add external I/O onto a mainboard seamlessly…so I’m pretty excited to see products like the Nwazet DAQ come to market.


nice module, i agree with using daisylink, in fact i think daisylink could be used a hell of a lot more, especially sringing together more and more of the same type of module to increase its capabilities like analogue i/o for example need 8 add a module need 16 add another module.

personally though and i think its mainly because of my lack of knwledge in the area but the learning curve for creating daisylik modules seems steep to me. but hopefully i`ll find time to learn in the future as i think daisylink has huge potential taht is cureently not being used.

GHI did it all for you. You really need to know nothing about dasylink to create daylink modules (assuming you know how ot make modules) Home - GHI Electronics

Go! bus is like a very fast, much more feature-rich, non-chainable (I don’t think…?) DaisyLink. Someone ought to create a Go! bus module for Gadgeteer. The driver for it would be implemented like the IO60P16 module, I would imagine.

If you’re using Go! bus on Go! bus hardware, then the IO is virtualized. It’s like your micro has “virtual” pins that you work with just like the “physical” pins.

Actually, I think they are chainable. I think Chris explained this in a thread back when GO! was first announced.

Hi godefroi,

That’s a good idea. You could add up to 255 GoBus modules to a mainboard this way, as long as you have the appropriate pinout to support GoBus (3V3 UART, 1 interrupt-capable GPIO, DMA-based SPI, 5V power, and switched DC-DC 3V3 power) and a compliant GoBus stack.

If you’re interested in working on something like this just PM me and we can start the conversation, get you a free license to use the GoBus trademark and interoperability logo, etc.

One important note is that the GoBus stack is compiled into the mainboard firmware… GoBus is virtualized I/o, so it operates at a much lower level than the IO60P16 Gadgeteer driver.


If Go! bus is so great (sorry didn’t have a chance to check it yet), then perhaps it should be included in Gadgeteer 2.0 specification. Unite the camps earlier.

Great idea. Get Oberon core, GHI libs, Go all together for a supper product. Actually, GHI always wanted to see serous NETMF-partners co-development and this maybe the perfect place. We got this going with Oberon already and love to see it with all others. And if that happens, GHI wouldn’t mind adding more of its premium feature to the OSHW base.

1 Like

This kind of talk just gets me all excited. However, GO! & Gadgeteer are so radically different I don’t know how you merge them w/o basically scrapping Gadgeteer as we know it including most of the modules already developed. I’d certainly love to see you all put your heads together and figure it out though. GO! has some really innovative features that Gadgeteer could benefit from.

Why? Isn’t go simply SPI based modules? So just use S socket?

Or just treat it as another type of Gadgeteer socket.

GoBus ports use the same pinout as a Gadgeteer SUY socket as a gesture of support to the MSR researchers who originally created .NET Gadgeteer. It also helps ensure that users plugging a GoBus module into a Gadgeteer mainboard (or vice-versa) don’t have to worry about accidentally damaging the module or their mainboard.

To remove any confusion, GoBus is a bus protocol like USB (rather than a pin mapping system). The GoBus protocol and its SPI transport also have a few requirements for mainboards which are designed to ensure a good user experience. These include power supply, USART module re-flashing, voltage tolerance, DMA, and port identification requirements. You also have the PWM-enabled status LEDs and power FETs on every port, etc.

The plug-and-play GoBus modules themselves have very few requirements aside from the low-cost MCU and in some cases minimal power management. The GoBus-compliant mainboard does the heavy lifting, which helps keep costs down on modules.

It is certainly possible to add a set of GoBus ports to a mainboard. We’d have to work out the details to make sure that interoperability and user experience were maintained. The protocol and GoBus interoperability logo are of course both available under a royalty-free license.


I don’t think it would be that simple. Go! is based on the idea of virtualized pins which ultimately translates into an almost indefinite number of available pins to the programmer since you’re no longer limited to the actual number of pins provided by the mcu. Sure, you could probably work out a way to get Go! modules working on Gadgeteer using just an S socket but I believe the driver would have to be totally rewritten since so much of the virtualization comes from the core framework.

Also, you can already use some Gadgeteer modules directly on Go! but IMO that’s just a hack. I’m still torn about how this should really work. As a pure prototyping & one-off projects, I think Go! is superior. For prototyping that will ultimately become a commercial project, I think Gadgeteer is superior since you need to be constrained by the realities of what your end product will have available to it.

The idea of having to put a mcu on every module feels like a royal PITA since many of the things I build are one time “modules” that never see a real PCB. If I had to go through the hassle of adding SPI to every module, I don’t imagine I would be as motivated to mess around outside of pro made modules.

Hard to believe that Gadgeteer is barely a year old and Go! is half that. I can’t wait to see where we are in another two years :slight_smile:

Thank you for taking the time to dig into the GoBus protocol. It’s cool to see users getting down into the more technical details. BTW, the current GPIO limit for GoBus is 32,640 GPIOs…although it’s likely that your mainboard would run out of resources before you could open that many InterruptPorts.

Those are valuable perspectives. Additionally, I think we’ll see some developers prototype commercial products with GoBus Virtual I/O as well, since it frees the developer from the constraints of a particular MCU until they finish their application. Then they can pick the MCU which is most appropriate. They could also use GoBus royalty-free inside their product if they can’t find an MCU which completely meets their needs.

One quick note on the mainboard that you’re referring to…the mainboard specs recently removed the Gadgeteer module pin compatibility note to make sure it was understood that this is more of an “advanced hack” than a feature supported by the GoBus protocol. With FEZ Cerberus adding support for the Gadgeteer libraries, all mainboards with Gadgeteer sockets should support the Gadgeteer framework.

There may be ways to simplify this even further. You do need to add an MCU (DIP or SMD) and a few caps, but you can also use a proto-module which takes care of that if you’re not space-constrained. As for firmware, with GoBus 1.5 we’ll be providing standard firmware which enables you to select which microcontroller features you want to expose (GPIO, ADC, PWM, etc.) and then deploy over the bus to the module’s microcontroller.

It’s amazing how time flies when we’re all having so much fun with .NET MF!

.NET Gadgeteer will celebrate its second anniversary in two weeks at MakerFaire NY; I’m hoping that some of the original Gadgeteer creators can make it this year and maybe we can all celebrate NETMF together.

BTW, here’s the blogpost follow-up from Gadgeteer’s debut. Cool memories.


I can definitely see this and this is what I had in mind when I said “pure prototyping”. Let me describe to you what I always envisioned as the ultimate destination of the Gadgeteer concept. I would love it if every mainboard & module had to also include their schematic and Visual Studio or some other extension were able to take a project from the GUI designer and merge all of the different schematics together to form a single PCB design that could be shipped off for mass production with nothing more than tweaking of the layout required by the user. This is very possible to achieve with Gadgeteer. I’m having difficulty imagining how this could work in Go! in a practical way.

My concerns with this are primarily the added cost and time to develop the drivers. I can definitely see how a standard firmware could be used to make driver development no more difficult than Gadgeteer driver development. That’s good news.

[quote].NET Gadgeteer will celebrate its second anniversary in two weeks at MakerFaire NY; I’m hoping that some of the original Gadgeteer creators can make it this year and maybe we can all celebrate NETMF together.

BTW, here’s the blogpost follow-up from Gadgeteer’s debut. Cool memories.[/quote]

I remember that video. Thanks for the memory. :slight_smile: When I said one year old, I meant one year of being publicly available as the Spider. Can a product really be considered a product if it’s still in v1.0 R&D?

Hi ianlee74,

That’s a cool idea. The designer could also probably include an auto-router and the ability to shift around pins (and change the pin declarations in Visual Studio) to help minimize the number of layers required and help meet EMI requirements. And for GoBus, the designer could select from a database of chips and pick the lowest-cost option for your application.

Definitely some possibilities here; I like your line of thinking.

I understand now. Since MSR built and shipped Gadgeteer mainboards out to a limited audience back in 2010, and having been involved with Gadgeteer even longer than that…I tend to count from the date that the platform was picked up by users rather than when 3rd-parties started making boards. Either way, one year or two…it’s great to see more and more projects based on NETMF.


Prototyping is probably actually easier with Go!, just because from the user-software-side, there is no Go!, there’s just I/O. If all your Go! virtualized peripherals add up to x UART and y PWM and z GPIO, and you can find an MCU with that many UART and PWM and GPIO, then you’re already done. If not, then you can continue to use Go! and additional MCUs to implement your project.

The big danger for NETMF here in the short term is the forthcoming breed of easy-to-program native ARM platforms (such as Paul Stoffregen’s project, Galago, and the Arduino Due) which will be simple (Arduino has proven successfully that they can make it easy to program microcontrollers in C/C++) and highly powerful. It’s scary to think just how much faster even the Teensy 3’s 48 MHz processor will be running native code than NETMF running even on something like Hydra at 240 MHz. There will be no contest. Already at 16 MHz on an 8-bit AVR, there are things that are possible that NETMF will never be able to do without things like RLP.

To put too fine a point on it, the Go! vs Gadgeteer discussion may be moot here in the near future.

I agree 100% with the above, I think .NETMF should embrace RLP or something similar as a core feature. I realize that this would negate the code portability, but I am sure for production systems there are scenarios where this is acceptable and .NETMF provides a convenient productive environment for 99% of the system while that 1% that is performance critical can be delivered natively with relative ease.

Another option is to revisit the JIT and AOT compilers that were explored early on. The “standard” NETMF operating environment has changed from those early days, we’re not exactly targeting wristwatches anymore.