Matt Isenhower

I used a simple "charger doctor" from Adafruit

Oh, interesting! I hadn't seen this product before. I see they also have this, which would allow you to connect it to a (probably more precise) multimeter: https://www.adafruit.com/products/1456
 

I run my Pi 2 headless and I find it's using about 280mA - 320mA under a reasonably normal load.

It's possible that the adapter I was using was a bit dodgy, too -- I really should take some actual measurements to confirm.

Interesting idle power numbers!

The Raspberry Pi 2 will need much more power than that during actual use I even had some trouble powering mine with a 1A USB adapter.

Also, I don't have actual numbers for this, but power usage on the N3W does shoot up a bit during Wi-Fi operations (as you'd expect). Still way less than a Pi, though.

How are you measuring this, did you just cut a USB cable?

+1

Microsoft have posted a ton of great tutorials for their Windows IoT Core platform on hackster.io. Netduino would be a great addition

Matt

Hi volleynerd,

You are correct that the Netduino Go is a bit older (originally released in 2012) and the Netduino 3 is the most recent Netduino (released only a few weeks ago). I covered a bit of the Netduino Go's history in my blog post/review here.

Chris will probably be able to tell you more about the Netduino Go's future, but my understanding is that it's only temporarily missing from the main product lineup page. It's still receiving firmware updates, support, etc. at this point.

If you're only using Go modules, need more than 3 GoBus ports, and don't need Wi-Fi or Ethernet, the Go mainboard is still a good choice. Otherwise, I'd choose the Netduino 3

Matt

It looks like there have been a few nice additions to the GO! Which mean a few software modifications are required.

Great overview of the differences in the new GoModule base class. Just to add a little background, the SPI changes became necessary because (as of NETMF v4.3?) it was no longer possible to have multiple SPI objects open on the same SPI bus. In my experimental library I just create/dispose of an SPI object for each message, but I think in Chris' library he routes everything through a central, shared instance.

This change and the IRQ/GPIO line changes also help prepare for changes that could come with GoBus 1.5 (for things such as routing messages to GoBus hubs, etc.).

Making the module GUID an abstract property is mostly cosmetic but it does help simplify/standardize the module discovery and instantiation processes. It also makes sense since the ID is literally a property of the module

Matt