Please realease an update to your SDK ASAP!

Hi everybody,

So after several days of frustration and googling I finally managed to build a simple device using the Fez Spider Kit with NETMF 4.3 QFE1, NETMF Gadgeteer Package 2014 R5, Visual Studio 2012 and Windows 7 64 bits. The device is quite simple, it uses:

  • LCD T35
  • Camera module 1.1
  • Ethernet module J11D
  • Button 1.4

It simply streams video from the camera to the LCD, and listens to web requests to send the latest picture from the camera to a web browser. Nothing fancy, very basic functionality.

I am running a prototyping lab at my university and we bought 20 of these kits to use with my students in class. So, to implement a functionality like this, should be a breeze! It is not!

I encountered several bugs that required laborious workarounds. For starters, I had problems with DHCP:

No big deal, easy to solve. I ended up using static IPs anyway. Then I had problems with the WebServer:

That was a big deal, I had to add the Gadgeteer core source code to my project, modified and recompile it!

Then later I had a problem with the camera and ethernetj11d working together:

I found a workaround, but it requires modifying generated code. Bad idea! But I had no choice.

And finally, when I wanted to send a picture taken from the camera back to a web browser I had to use this workaround:

There it suggests that I need to implement the function ConvertToFile in my own code, the one implemented in the libraries is broken. This function takes more than 20 seconds to process a 320x240 BMP picture!!

I understand that some of these bugs are in the .Net Microframework maintained by Microsoft, but I have to say that I feel that I am now stuck with 20 Fez Spider kits. With a firmware so amazingly buggy, I can’t use them in my class or for any prototype. But I still want to, these devices are so cool and the concept they represent is so beautiful. Please don’t let me give up, fix all these bugs and release an update, I beg you.

A hopeful Gadgeteer user,


We love schools and educators. Give us a chance to help you better. Posting on the forum will solve most problems but we would not know what is urgent and what users are working on.

Do you want to call tomorrow and talk to Gary? He is our superhero here at ghi.

Thank you Gus for your kind offer. Actually I don’t have any technical problems with the Fez Spider kit at this moment. As I mentioned in my first post, I managed to solve all the problems that came along. My only concern is the amount of workarounds and tweaks necessary to implement just a relatively simple application.

Please don’t get me wrong, I’ve been working with embedded systems for a few years already and I know that bugs, workarounds, tweaks, etc. are unavoidable and you just have to deal with them. Nevertheless, some of the bugs could easily be solved right now by releasing an update to the Gadgeteer package. GHI products are great and incredibly fun to use, I just bought a few extra modules a couple of weeks ago, but their firmware needs an update. It will improve them a lot.

Kind regards,

1 Like

@ Gus - Thank you for that wonderful introduction!

@ fexadom - I will email you shortly to get some more information and to see what we can do to help you with future course work.

@ fexadom - we would like to think of our software as being superior in quality and we will do whatever is necessary to accomplish that :slight_smile: feedback is very important for this process, so thank you.

As Gary knows, I am in the same situation. I would really like to use Gadgeteer from GHI in my lessons but right now it is too difficult for my my pupils to manage all these workarounds.
I watch Gadgeteer since several years and there was a big improvement since then.
But I fear I have to wait another year…

I very nearly gave up on gadgeteer because of the problems I ran into immediately when I started… the displays not working, tunes module and motor driver module incompatible with the hubap5, raptor not speaking to visual studio and changing it’s target name randomly, documentation that was just plain wrong and unusable and misleading…

I have a handle on all these issues now…more or less…but I was initially very angry at myself, thinking I was just not understanding something that should be so simple. I thought it was me!

I am a little surprised that another sdk with the major fixes has not been released though. I wonder how many in my position actually did give up.

I too am hoping it will be soon. End of march (end of 2015 q1) seems ideal :slight_smile:

@ mtylerjr - This thread:

Discusses the rationale behind not updating the SDK as frequently as in the past.

It’s a tough problem… Update too frequently and it’s very disruptive for customers, who may find it hard to find accurate docs and forum info. Update less frequently, and it’s difficult to get bug fixes in the hands of your users, which can be especially hard on new users.

Personally, I’m a fan of more stable releases, but I’m also quite comfortable pulling in code from. GHI’s bitbucket repo if I need a fix before the next SDK release. I can sympathize with those who are less so.

Hopefully, the thread above will at least provide some background.

Documentation should all be updated as of few months ago. I am surprised you seen issues and surprised with issues you found in the software. Please provide more details so we can take care of any issues promptly. For documentation, use the feedback form on the bottom, for everything else, please use the task tracker. I am not aware of any major issues so we really need your feedback.


The main issue for me is the bug involving the display modules (N18 T43) that prevent displaying images without slowwww workarounds. These were mentioned by the original poster.

The other issues that frustrated me involved the HubAp5 - initially, it failed horribly when I tried to use the motor driver module with it. Eventually taylorza discovered that one needed to set the frequency down from the default 25khz to 5Khz to get that combination to work (thanks taylorza)

The tunes module, (likely for similar reasons) creates very distorted tones when used with the hub - the standard musical note enums are not usable. This means it -must- use the only P socket on the raptor. It would have been nice to see a warning in the docs for that.

Also, the issue trying to use the smart multicolor LED with the hub derailed me (2 or 3 minutes to set a color, because of daisylink bit banging) was very very frustrating initially. Now I know it is just not a generally usable combination and not something I was doing wrong. I still don’t see any notes in the docs warning people about this.

But the image display bug is one that is preventing me from doing some things I’d like to do. The fix for that is what I’m really waiting for.

Im still very much enjoying my gadgeteer hardware though. :slight_smile:

@ mtylerjr - we will take a note of all these but I highly recommend the task tracker do nothing gets forgotten and voting helps us in determining what should we do first. By the way, none of these issues are critical enough to release a new sdk just for it. Anyway, the next sdk is not to far away. Fewer releases make things better overall.

I guess not… except the “digital camera tutorial” that uses the serial camera and display module is the first one many people try - there are articles describing it all over the place (and the first one I tried) - just wont work.

I know software is like jello - every time you touch it you have to wait until the shaking stops - so I understand your desire to release less often - but displaying images on a display screen is one of the fundamental “must work out of the box” features, if you are selling camera modules and display screens and advertising them as working together “simply”

But again I can surely sympathize. I’m just putting in my two cents about my perceptions of the “severity” of that bug.

@ mtylerjr - which display doesn’t work? Maybe there is an issue I am not aware of. The N18? You are using it with the camera?!

Haven’t there been dozens of threads about this?
The functions that allow you to display an image on the N18 display (and T43) are broken. John explained the bug, and apologized for it and said it would be fixed in the next sdk. He made a small mistake in a function that converts image data.

Workarounds have been posted that require modifying the code, except those workarounds are very very slow compared to the intended functionality that was (I assume) implemented in native code originally.

Also, drawing on the N18 causes text and other elements to be duplicated (the screen is split weirdly) - I think some threads indicated that this was related to the same issue. I’ve seen literally probably at least 10 threads on this?

Here are some threads were people have run into this issue. I just did a quick search for threads where John or someone eventually forwarded them to the last link regarding the bug.

Also, please note that I don’t mean this as a “OMG this software is terrible” post… just that this is the bug I am patiently waiting to be fixed, while I enjoy all the other very cool aspects of the gadgeteer hardware that I have.

I think GHI is doing a good thing! I just would like the native conversion/graphics functions working in the latest SDK, without having to roll back :smiley:

@ mtylerjr - I knew about the n18 but not other displays. I will check with the team.

Ok so here is what I learned. The only display with that slow work around is N18. There is another issue with the camera driver that effect all display; however, all native displays work fine otherwise.

I know you are not complaining but we need to know exactly what is going on so we can cover most, if not all issues in the coming release. So far, all these issues mentioned are fixed already internally.

AH! cool. Okay. I ran into the N18 problems first, trying to display images from the camera, then when that had issues, testing by drawing text and having other issues- I assumed they were the same issue.

The I went to the T43, and ran into camera image issues, and stopped there, thinking it was a single issue affecting both displays. Now I see that there were 2 issues, and I can still use the T43 for non camera-image stuff. That’s helpful!