The future of Gadgeteer

We are planning that next year will need to be 10-20 devices

If I’m going to do a carrier board is sure to turn to @ Dave McLaughlin. Thanks.

Today, my order arrived - got me a big smile on my face, because the German customs cleared it unexpectedly fast - BUT: they managed to CUT the cable of the pulse oximeter… AHRG :wall:

2 Likes

Thats why they cleared it so fast. To get it out of sight :whistle:

1 Like

Sad to see it go. As an original hardware engineer who moved into the OS world Gadgeteer allowed me to re-awaken the love of gadgets with low startup investment in my busy schedule. The fact that I was writing an operating system and device driver model at work in C# was all the better…

But it never caught on like Arduino, and now RaspberryPi and others. Having implemented many Gadgeteer projects and re-implemented in Arduino/RaspberryPi, etc. I will say the Gadgeteer is the fasted to up and running. Even as an expert with scopes and logical analyzers I spend many more hours on hardware, code, and drivers for Arduino style projects than plug and play Gadgeteer, as long as you don’t go outside the boundaries.

But since it did not take off, the cost of a “deployment” system was prohibitive. Which is why the Arduino style was in the picture, leading to double coding in C# for Gadgeteer for quick “Startup Weekend” stuff (actually won one), and C/C++ for production units.

The other big gap I ran into is writing code for the display. In todays world a good, portable GUI library is a given, especially for a non-GUI person like myself. Even more so starting from HTML/Javascript which is taking over the web is closer to the model I have in mind. So I know find that a RaspberryPi with its 7" display as just right and can use HTML5/Javascript, AngularJS/Node.JS for my UI.

My next step is to use native Android UI’s, as my prediction that Android phone chassis will find its way into the IoT space is coming true, such as the $9.00 C.H.I.P. computer. With Linux Arm7 on board, I can use full NodeJS/Javascript and Python, etc. I have noticed even Java being pushed out of embedded, not just C#.

As others have said, I have over $1k invested, but I learned a lot and did some great projects.

2 Likes

I have been thinking, I like the small connectors and cables aspects of Gadgeteer. Is the cost to prohibitive to continue to make sensors this way?

I can see creating some small adapter shields for RaspberryPi, C.H.I.P., BeagleBone and others that acts as the main board to connect up sensors.

I can also see a market for small adapter boards that take standard Arduino style modules and make then signal compatible with a Gadgeteer setup.

Now that the hardware lives on, what about the software? My solution is a Node.JS based framework that uses similar concepts to Gadgeteer designer. JSON files can configure a tool to build a project prototype, much as the Gadgeteer VisualStudio add-in did. Since everything is driven from a standard JSON file, we have simple tooling for editing and generation of project descriptions.

Now a visual designer, maybe based on “Fritzing” or other similar work would allow visual drag and drop of hardware modules, with output being the JSON file that is input to the application template generator.

Javascript based “drivers” around a common pattern would interface the sensors and actuators.

Maybe I am just trying to keep the whole concept alive on modern languages and trends. I don’t see anything else similar…

1 Like

@ zr1fiend - we welcome anyone moving gadgeteer forward, as a whole or just the connectors.

@ Gus - The availability of modules will be important. I can Eagle design a set of shields for RaspberryPi3, C.H.I.P. and even Arduino. But I can’t manufacture, so a manufacturer would have to build modules and main board adapters.

The software side can be open source. Linux and NodeJS, Open source C# on Linux/WinIoT, even Python/Micropython of that community wants to be involved.

Maybe we should private email my background.

Accept reality with pain

At least one suggestion to replace Display TE35, T43 Module with GXP Gadgeteer Bridge in the CobraIII in which I make my design. Which is still in production, this should give at least one solution with another provider and a connection scheme.

Otherwise start a new development and stop using Cobra and G120 that is my doubt.

My greetings and sorry for the translation errors on GOOGLE my language is Spanish.

Hi…i am a new user here. As per my knowledge FPC connectors in locations that may or may not sit well with final display mounting relative to mainboard, doesn’t seem easier to me. In fact, looking at my Cobra 1 with 4.3 case, I do much prefer the T43 connected to the Raptor sitting next to it. I can’t solder that FPC. I can solder the .05 headers no worries. If I’m making a “custom” board, at least the standard that the RGB sockets gave made it easily transportable to another manufacturer’s mainboard if you wanted.