We’ve got the power! (for your Netduino Go! projects)

We just received our new Power Supply Module from the assembly house ūüôā

It is the easiest way to power your Netduino Go! projects away from a computer once you’re done building it. The module will fit nicely on the top-left corner of our¬†Large Plate¬†or of our¬†Stackable Plate. This module is equipped with a standard center-positive 2.0mm barrel jack and will take any power supply, such as a wall-wart, a 9 volt battery or a cigarette-lighter adapter, between 7 and 20 volts and will output a nicely regulated 5 volts at up to 800 mA. Just connect the micro USB cable that you’re using today with your Netduino Go! to the power supply module and you’re good to go. The module also features a large switch to let you turn your project ON / OFF smoothly and easily.

Power Specifications

It’s tiny but packs a nice punch:

  • Voltage Input: 7v (min) to 20v (max)
  • Voltage Output: 5v regulated
  • Current Output: 800 mA (max)
  • 1.0v Dropout
  • Barrel Jack: 2.0mm diameter with the positive voltage at the center


  • The hole-to-hole dimensions of the module are 30mm x 25mm
  • The total size of the board is 40mm x 35mm
Hacking the Netduino Go! for power-hungry projects

We will follow up soon with a post showing how to take advantage of the 800 mA provided by the [nwazet Power Supply Module going beyond the 500mA imposed by the USB power circuit on the Netduino Go!



From prototype to product: buy your very own PIX-6T4 console kit!

PIX-6T4 Kit

PIX-6T4 Kit

It’s been a while since I’ve last posted here… We have been busy over the past few weeks getting our new little startup company off the ground and setting up a marketplace for the PIX-6T4, our very first product ūüôā

The PIX-6T4 is a complete, yet simple, game console designed to teach budding Hackers and Makers about digital electronics and programming in a fun way. Head over to the PIX-6T4 site to check out the schematics, the source code, the docs, and of course, the step-by-step video tutorial on assembling the kit:

The PIX-6T4 is an entirely Open Source and Open Hardware kit, so you’re free to hack it to your heart’s content or use it as a base for your projects. Be sure to show us what you build with it and we’ll feature your creations and contributions.

Have fun!



Building your own Netduino-powered Game Console – Part 1

So, you’ve decided to build your own PIX-6T4 game console and you’re excited about learning C#?

Awesome! Buckle up, you’re in for a wild ride ūüôā

The first step of your journey starts with gathering a few parts, which you can find listed in this spreadsheet along with their current retail price¬†and links to the suppliers. In a nutshell, you’ll need about $95 to get all the required parts.

In an effort to keep the number of suppliers down to a minimum for your convenience, most of the parts for the PIX-6T4 prototype come from Sparkfun Electronics.

However, there are many alternative suppliers out there and with some research in Octopart, you will be able to reduce the cost of building this prototype.

Next time, we’ll cover the first step of the build, laying out the IC sockets, the analog joysticks, and some headers on the prototyping board, just like this:






Driving an adafruit VC0706 TTL Serial JPEG Camera with a Netduino

HAL 9000

¬†Earlier this month,¬†AdaFruit released a nice little TTL camera, perfect for security and remote monitoring applications. The camera supports three resolutions (640×480, 320×240 and 160×120), has a built-in motion detection circuit and can output an NTSC signal, all in a fairly compact form factor. The communication with the camera is done over a TTL UART @ up to 115200 bauds. In many respects, this device is very similar to the LinkSprite camera, which has been out there for some time now.

As I’m working on a security-related project involving the Netduino, it was the perfect opportunity to put this camera to the test, starting with writing a C# driver. While interfacing with the camera over the TTL UART of the Netduino is straight forward, the datasheet¬†describing the protocol and commands required to control the camera functions is painfully sketchy and sometime inaccurate. In some instances, some camera functions such as OSD (text overlay) are not supported in the firmware even though the datasheet documents them or only behave properly if called in a particular sequence, which of course, is not documented…

Connecting the camera to the Netduino

Limor’s tutorial on how to interface the camera with the Arduino outlines the required steps rather well, so I won’t re-iterate them here. The only difference worth mentioning is that the voltage divider configuration shown in the adafruit tutorial is not necessary on the Netduino, since its GPIO pins are 5 volt tolerant.¬†So, you can simply connect the TX pin of the camera to PIN 0 (RX) on the Netduino and the RX pin of the camera to PIN 1 (TX) on the Netduino. To make things a bit easier while testing the camera with a breadboard, I built a connector using a standard 0.1″ pitch¬†right-angle header and a small section of prototyping board: unfortunately, the breakout board of the camera uses a different pitch. In addition, you’ll want to connect an SD card reader to your Netduino so that you can store snapshots. Please refer to my earlier post on how to connect an SD card reader to the Netduino if you aren’t familiar with the procedure. If you’re using a Netduino Plus, don’t worry about that part ūüôā

Using the Netduino driver

The Netduino driver currently implements 4 major functions.

Initializing communication and the camera’s resolution

  • Initialize(string port, PortSpeed baudRate, ImageSize imageSize): This call must be the first call in the application. It takes care of initializing the UART and the resolution of the camera at the same time. The reason for keeping these two functions together is that changing resolution requires a reset of the camera, which also resets the camera’s baud rate to the factory default of 38400 bauds. In addition, if the baud rate is set to something other than the default and the program is interrupted while debugging, the next time the program runs, it will have to remember what the last baud rate was (unless the camera is hardware-reset). To avoid all this trouble, the initialization function automatically figures out the proper baud rate needed to communicate with the camera before applying new settings.

Controlling TV output

  • TvOutput(bool enable): Passing ‘true’ will tell the camera to output a composite video signal showing whatever the camera is looking at. Passing ‘false’ turns it off.

Taking pictures

  • TakePicture(string path): This function will tell the camera to take and store a snapshot, in JPEG format, to the location specified by the path argument. You need to have an SD card reader connected to the Netduino for this to work. You can control the quality of the image using the¬†SetCompression(byte compression) function where the compression is a value between 0 and 100, with the default being 53.

Detecting motion

  • StartAutoMotionDetection(int imageSequenceNumber, string storagePath, MotionDetectedHandler motionDetectionHandler): This function will activate the motion detection circuit of the camera and will return immediately. Whenever motion is detected by the camera, the driver will callback the application through the motionDetectionHandler delegate. If the handler returns ‘true’, a snapshot will be automatically taken and stored to the location indicated by the¬†storagePath parameter. The filename is sequentially incremented, starting with the number provided by the imageSequenceNumber¬†argument. The motion detection can be stopped using a call to¬†StopAutoMotionDetection().¬†Click on the image below to see a sample on how this can be used.

Testing the camera

To put the camera to the test, I wrote a sample taking a set of 100 pictures using each of the resolutions supported by the camera. The sample also tests motion detection and the camera’s composite output. During the test, the camera was set outside on a tripod, pointed at a neighbor’s house about 200 feet away around 8PM on August 11th. The goal of the test was to gauge the overall video quality of the camera in lower light conditions as well as evaluating the error-rate when taking snapshots.

The results

The composite video quality, shown here on a small CRT TV, is generally quite good and stable.

NTSC output

The snapshots, on the other hand, often show compression artifacts like this:


Out of 100 pictures taken at the higher resolution, only one did not have any artifacts. Please note that I did not tweak the color saturation of the camera before using it: colors can be greatly improved with some tuning with the tool coming with the camera. Limor covers this in her tutorial as well but I’ll post updated snapshots¬†with tuned color saturation when I get the chance.

No artifact

In the large and medium resolutions, 1 picture out of 100 is generally corrupt and cannot be viewed. There could be several root causes for these artifacts and data corruptions:

  1. The connection I’m using between the camera and the Netduino is not shielded or twisted to minimize radio and electromagnetic interference. I haven’t had the chance to validate this yet.
  2. The serial buffer size vs. the baud rate is critical in minimizing errors: I was able to read a maximum of 120 bytes at a time @ 115200 baud without losing data with the current connection to the camera. Larger buffers only seem to increase the error rate to unacceptable levels which makes reading large images a slow process. Again, a shielded and twisted cable would likely help using larger buffers.


The VC0706 camera, with proper tuning, is a nice addition to any project where remote monitoring, motion detection and security are needed and it will pretty much work ‘out of the box’. It would be great to see future versions of this camera offering access to the SPI and High Speed UART interfaces: while it is possible to force the camera to use ‘out of spec’ UART speeds above 115200 bauds, it is unlikely to be very reliable.
As always, you can find the camera driver and the test code as part of the Netduino Helpers library.

Build a Netduino-powered Game Console

Over the past few months, my friend Bertrand and I have been working on a game console, the PIX-6T4, which is powered by a Netduino mini.

The console is designed as platform for learning digital electronics and C#: we’re in the process of writing a book covering all aspects of building the console, how its components work and how to write games for it with our¬†framework.

Here’s a video of the prototype of the console below:

and here, as we presented it during the Ask An Engineer Show-And-Tell run by AdaFruit on Google+ last weekend: http://vimeo.com/26943990

As always, it’s entirely open source / open hardware and we hope that you’ll have as much fun building your own and making games as we did, which¬†we will cover in a series of upcoming posts, often referring to past articles¬†on this blog.


Make Blog: http://blog.makezine.com/archive/2011/07/build-a-netduino-powered-game-console.html

MSDN Blog: http://blogs.msdn.com/b/netmfteam/archive/2011/08/10/netmf-student-and-hobbyist-projects.aspx

Driving an AdaFruit ST7735 TFT display with a netduino

Color Flow

AdaFruit recently released a sweet little TFT display that I was dying to hook up to a netduino: the display features a resolution of 128*160 pixels, is capable of showing 18-bit colors and has a microSD card reader on the back of the breakout board. As usual, Limor wrote a nicely detailed Arduino tutorial showing how to connect the display and how to write sketches to drive it.

The Arduino driver relies on the ability of the Atmega168/368 to toggle digital lines extremely fast, which does not work well on the netduino due to the latency introduced by the .Net Micro Framework: even when configured to use hardware SPI, the Arduino driver constantly toggles a data/command output line, rspin below, which would be unbearably slow on the netduino if the same method were applied.

You can see an example of this in the drawPixel function:

void ST7735::drawPixel(uint8_t x, uint8_t y,uint16_t color) {
  if ((x >= width) || (y >= height)) return;
  // setup for data
  *portOutputRegister(rsport) |= rspin;
  *portOutputRegister(csport) &= ~ cspin;
  spiwrite(color >> 8);
  *portOutputRegister(csport) |= cspin;

Driving the ST7735 on the netduino

The ¬†netduino has one advantage over the Arduino: it has plenty of RAM. So, instead of toggling I/O lines slowly all the time and using next to zero RAM, the netduino driver allocates a 40K buffer corresponding to the resolution of the display in 12-bit depth colors (16 bits per pixel) and leaves the ST7735 in ‘data’ mode upon initialization.

Drawing always happens on the internal buffer first. Then, whenever the actual display needs refreshing, the display I/O operations are performed using hardware SPI, blasting the entire 40K buffer. It may sound crazy but using this method on the netduino is faster than refreshing a single pixel while toggling an I/O line!

Take a look at the following netduino code to see how this works, compared to the Arduino driver drawPixel funtion above:

private void Initialize() {

Write((byte)LcdCommand.NORON);  // normal display on

SetAddressWindow(0, 0, Width - 1, Height - 1);


private void SetPixel(int x, int y, ushort color) {

if ((x < 0) || (x >= Width) || (y < 0) || (y >= Height)) return;
var index = ((y * Width) + x) * sizeof(ushort);
SpiBuffer[index] = (byte) (color >> 8);
SpiBuffer[++index] = (byte)(color);
public void Refresh() {

The caveat is that allocating a 40K buffer on the netduino does not leave room for much object allocation afterwards. In fact, memory is so tight that OutOfMemory exceptions will be common if not careful and planning your application accordingly.

Before going any further, let’s look at the display in action on the netduino. Please¬†forgive the quality of the video as the camera on my phone doesn’t do justice to the display.

Pretty zippy, huh?

Some hacking required…

As I was trying to get the ST7735 display to work with the netduino, I discovered that the display would stop communicating when configuring SPI to run @ 10 MHz or above.

This is a huge issue for a couple reasons: the speed of the SPI bus determines the display frame rate on the netduino and secondly, mounting a microSD card on the netduino configures SPI to run @ 10 MHz minimum. No matter what. This meant that I could either use the display or the microSD card but never together, preventing scenarios such as loading pictures from the microSD card for display for instance.

Based on previous experience, I began suspecting that the CD4050B logic level-shifter on the ST7735 breakout board was the root cause of the issue and decided to take it out of the equation altogether by shorting out its pins so that it would no longer convert signals. Since the netduino works at a 3.3v logic level, there was no risk of damaging the display driver.

CD4050B - Before hack
CD4050B – Before hack
CD4050B - Before hack
CD4050B – After hack

Sure enough, eliminating the logic-level shifter allowed me to initialize SPI @ 40MHz on the netduino as well as using the the microSD card reader without any issues.

Connecting the AdaFruit ST7735 display to the netduino

  • netduino GND -> ST7735 GND
  • netduino Vcc (3.3v or 5.0v) -> ST7735 Vcc
  • netduino D8 (or other Dx pin) ->¬†ST7735 RESET
  • netduino D7 (or other Dx pin) ->¬†ST7735 D/C
  • netduino D10 -> ST7735 CARD_CS
  • netduino D9 (or other Dx pin) ->ST7735 TFT_CS
  • netduino D11 ->¬†ST7735 MOSI
  • netduino D13 ->¬†ST7735 SCK
  • netduino D12 -> ST7735 MISO

Note that the¬†ST7735 LITE pin can be connected to netduino Vcc (3.3v or 5.0v) or any of the netduino’s PWM pins if you’d like to control the intensity of the display’s back light.

As always, you can find the code as part of the netduino.helpers library.


The AdaFruit ST7735 TFT is a fast, bright and convenient all-in-one display and microSD reader:

Using it on the netduino is sub-optimal for the time being due to the memory requirements involved in making the display work at a decent frame rate but, if used carefully, it is possible to achieve very cool results with it right now. Keep in mind that the memory requirement will eventually go away once the netduino starts supporting native ARM code with .Net Micro Framework 4.2, letting applications toggle I/O lines super fast.

Finally, my only wish is for AdaFruit Industries to consider producing versions of their products without built-in logic level-shifters as they can negatively impact some micro controllers such as the netduino.

Happy hacking!

Color Flow image courtesy of Bartelme Design


Update on 08/23/2011: here’s the same hack applied to the stand-alone version on the adafruit microSD card reader, this time with a 10K resistor between Vcc and Gnd to ensure that the electrical behavior of the chip remains stable.