Embedded - 56: Rodents of Unusual Size

Episode Date: June 18, 2014

Matt Haines (@beardedinventor) and Tom Byrne (@tlbyrn) spoke to Elecia and Chris about Electric Imp (@electricimp). This discussion goes far beyond our first with Matt (Episode 6!). It is more software and implementation oriented than last week's Amp Hour.  In the vein of "what do I do after I've made an LED blink from a webpage?": Tom's Neopixel Weather project (instructable!) Mars Curiosity rover that mirrors what is happening on Mars (provide your own Martian) Elecia's are-you-ok widget Sparkfun tutorial, thanking Matt for his help with cleaning (ahem, re-writing) the code Electric Imp github repository, including the extensive webservices page Hackathon entry Twitch controls a HexBot via Electric Imp led to an excited discussion of Twitch Plays Pokemon  Matt's Hackaday Prize (SPACE!) entry that uses an Imp to show when the ISS is overhead MakeDeck is making Electric Imp dev kits for OEM  development.  Imp page devoted to the question under Next Steps (also, the new Squirrel documents mentioned on the show are up!) Finally, the SparkFun contest winner was announced. There were many great entries, choosing a winner was difficult. Ken M (@Deamiter) won the grand prize. Luckily, Matt and Tom brought two April board + Electric Imp sets to give away so Chris Svec (@christophersvec) and Alex Irvine (@EternalPractice) were runners up. Thank you to all who participated, your ideas were awesome and we loved to hear about them.

Welcome to Embedded, the show for people who love gadgets. This is Eliseo White. We've got a crowd on today. Christopher White will be co-hosting once again, and Matt Haynes from Electric Imp is back and brought me an engineer to talk to. So welcome, Tom Byrne. Thanks. Happy to be here. I know that some competitor podcast, The Imp Hour, sniped my electric imp plan. Or maybe you heard our own previous show, which was episode six, which was called Robot

Squirrel's Dream of Electric Imps. Consider those the beginner class. And this is going to be the advanced one. And we're going to talk really get into details here we're also going to answer some of your user questions with the are you okay project i've worked with the imp a lot i'm not an advanced user but i'm over the newbie stage finally so that's what the plan is and in case listeners haven't heard the other shows, can you give me a two-minute introduction to Electric Imp?

Sure. So Electric Imp is a platform for building hardware that connects to the internet. So we're trying to make it as easy as possible to enable people to build internet of things things. So the whole premise of it is that there's all of these sort of barriers to entry if you want to build a connected object. You need to think about security and how it's actually going to connect to the internet, how you're going to manage those connections and scale them up to thousands or millions of devices. And all of that sort of

takes away from the core of what you're building, which is the product itself. So the goal of ElectroCamp is to sort of abstract all of that away and make it so that you can focus on building the things you want to build and ignore this sort of fluff that just supports it. And to some extent, you, so that was Matt. And to some extent, you were directed towards web developers as part of your audience, not necessarily microcontroller people, not embedded systems people, but those other people who talk Java and stuff. Yeah, we attract sort of a weird, eclectic group of developers.

So one of the really neat features of ElectroCamp is that everything runs in a virtual machine. So rather than writing C or assembly for your embedded device, your imp, which is the hardware part of our platform, is actually running an operating system. And on that operating system, it has a virtual machine for a programming language called Squirrel. And you also have the same or a very similar virtual machine that runs on our servers, and they can talk back and forth. So it's sort of a really easy way to get web developers into playing with hardware since it's a much more familiar language

and sort of a lot less intimidating than you typically have with something like the Arduino or other embedded controllers. All right. I want to go back for a second, actually. Tom, will you introduce yourself? I mentioned hardware, or I mentioned engineer, but I think you're a hardware engineer? I try not to say hardware engineer. I am an engineer. I'm trained as an electrical engineer, but I did aero and mechanical for a while before that, and I spent an awful lot of time writing software of varying degrees of quality. So I try to keep it diverse and broad. But yeah, I help customers of Electric Imp get their designs ready to go to production. I help them solve their problems and

figure out ways that we could be better at doing what we do. Cool. Matt, what is your background? So right now I'm the community manager at Electric Amp. That's a fuzzy title. It is. So I do a lot of, I wear a lot of hats, I guess, but mostly it's to support our hobbyist community. So all of the people who are using our platform that aren't building things commercially, and some people who are. So I basically, I guess my role is to sort of make

sure they have the tools they need and the resources they need to work with our platform the way they want to. So prior to coming to ElectroCamp, I was a software developer and project manager. And I actually started a hacker space in my hometown in Canada. And that's sort of what eventually led me to building cool things and being interested in ElectricEmp. So have you both been there from the beginning? I was actually there a little bit earlier.

But Matt's been there for quite a long while now too. Yeah, ElectricEmp is just over three years old now. And I've been there for about a year and a half. I should say I wasn't there right at the beginning either. I joined after Electric Imp debuted. So what is the best way for someone who just received an Electric Imp to get started? I think the first thing to do is the electric GIMP version of Hello World, which is to blink an LED from the internet. And I think you've done that before, right? I have. I did that when you still had the graphical interface. Sure, Planner. I remember that.

But now you've moved on to having Squirrel for both the server-side agent and the device code. And I have gone far beyond blinking lights. Yes. The SparkFun tutorial for how to blink lights was pretty cool because it really was very... It's hard to not follow those instructions. They put a lot of work into that tutorial. We were all pretty impressed with it.

You've written some other tutorials, Tom. A little bit, yeah. Which ones? So I think earlier on, even back in the planner days, I got pretty interested in showing people how to build things with instructables because it seems like there's a pretty robust community there. So I started out building some things

like how to make a potentiometer connect to the internet so you can drive arbitrary values to control all sorts of different things. And then we did things like change light colors or move little robots or put blinds up and down with it. But since we've had agents, I started doing some more kind of end-to-end projects. We did a internet-connected battery-powered thermometer that we call TempBug. That's like a great Electric Imp 102 project. Not a lot of parts, not a lot of code, and it'll make graphs. And who doesn't love graphs? So we've done that. And actually, a natural extension to that is making an internet connected barbecue thermometer, which we did. So what are some of the others that we've put up

recently? I think we did a NeoPixel ring that shows the weather. So it'll do different, um, animations depending on the conditions of the zip code that you give it. And that one's a lot of fun. I really like that one. Are there different pixels for different days or? Oh, so this one, it's actually a little, it's a little square, um, of kind of smoked acrylic that we made at a hackathon. And there's one of those NeoPixel rings behind it, a 24 pixel ring that we got from Adafruit. And it's just hooked right up to the imp and the imp just plays animations on the entire dial given the weather conditions. So

when it's raining, any pixel might suddenly twinkle blue or purple or something like that and then fade out like raindrops. And I actually really like the lightning one because every so often it'll do a lightning strike where it'll all light up bright yellow and then fade out and go back to raining. If it's clear, it'll show the color depending on what the temperature is and the brightness will correspond with how overcast or clear it is. So it's actually really fun to just glance at it if you don't have a window right next to your desk like I don't. So that sounds like a good one to talk about.

Clearly, you have to talk to some weather interface on the web through your agent. Right. And so you HTTP out to, like, Wonderground? Sure. So this is actually where the whole power of agents comes in because we can arbitrarily define our HTTP interface in the agent. It has an API so you can build and send requests.

It has an API so you can register an HTTP event handler. So when a request comes in, you can do whatever you want with it. You can look at the path. You can parse JSON requests coming in. You can do things with query parameters. This particular example doesn't use the HTTP on request at all. It just builds a request to Weather Underground with the zip code in it, sends it, gets the response back as a block of JSON,

parses it, and then all the little things about the weather you might want to know are in nice little fields that are really easy to find. And you don't even really have to do any parsing yourself because it's right in the API. So you just HTTP.json decode, and there you are. It's a table of weather information. And is that all on the device?

It's actually all in the agent. All of that is before the device even gets started. On the server, because one of the things that's cool about Electric Imp is that it's got low batteries. Yes. And so you want to put all of your other stuff on the server if you can, and then just pop a little bit down to the device.

Okay, so server goes out, gets some information, and now it's all ready. Does it send down, like, show animation three? So here's where design decisions start to happen. You as the electric programmer can choose to send down it's raining or you can choose to send down animation number three or you can choose to send down specific requests.

I mean, in this example, what happens is it says it's raining and the device picks an animation that's made just for rain. And that's just the way that I developed it for this example, because it was, as far as I could tell, the fewest lines of code and the clearest example of how to push the data around. But how thin you make the device is kind of up to you,

and it depends on what kind of power story the device needs. So this is kind of, it's all about flexibility. So on the device, you have some fixed animations. And maybe it's like do random X, Y, or Z. But you also have, raining means blue and purple and intermittent. Right. And sunshine may mean glowy yellow or whatever. Right, exactly.

And those are on the device itself. Yep, yeah. In this case, we've taught the device, its entire lot in life is playing animations. So it has a class with a bunch of different functions in it for different animations, and when you hand it the forecast, it just picks the right one and does it.

So you could replace the agent entirely with a stock market agent and play different animations for the stock market. And how do you control the NeoPixels? So in this case, they're a bit tricky. So NeoPixels use kind of a strange one-wire, it's not Dallas,

it's a different one-wire sort of protocol. All strange. Yeah, exactly. And the imp doesn't speak it per se. We don't have a single API call that says set a NeoPixel to this color. So instead what we do is we build a frame buffer as a blob object. And a blob is just arbitrary binary data, right?

And it has a file handle just like a file would, and you can read and write to it. And you can also index specific bytes inside of it. And what we do is we build this frame buffer and then hand it to the spy peripheral because the spy can generate carefully timed waveforms. And we don't use the clock line from the SPI, and we don't use the master and slave outline, MISO, on the SPI. We just use MOSI. And so it spits out a waveform that just happens to be the right shape. And in this case, we've kind of packed that all up into a class. So you, as someone using the NeoPixels with an electric amp, you don't really have to think so much about what the waveform looks like. You just put this class in your code, and then you call the functions that are already there to set the specific values of given pixels inside the frame buffer, and then tell it to send

when you're ready. So there's no hardware interface for this one wire bus, but you have obfuscated all of the things that I might need so that as a programmer, I can just use it. Right, It's all abstracted away, but you could dig down and look at it too. I mean, the code's completely open. It's all on our GitHub and you can work through it. You could change things if you needed to. If the timings for a specific part were a little bit different, you could tweak the waveform in the class. I know we ran into that because there's two versions of the actual NeoPixel hardware. There's the 2812 and the 2812B and their designers and their infinite wisdom made their timing just slightly different. And you do have a lot on GitHub. Unfortunately, I managed to do all of my project

by searching through your, doing all the R U OK project by searching through your documentation on your web and then your forums and then Google and never came across your GitHub repository until I sent my code off to Matt and said, could you take a look? And I don't think I ever really gave you credit for that. I didn't thank you in the tutorial, so I'm just going to make this the thank you for looking at my code and fixing it. And one of the things you did was make it so that I was using your GitHub repository version of how to interact with Twitter.

Yeah, I remember when you first showed me that code, I was like, wow, I haven't seen this in a long time. We used to have a whole bunch of functions for actually doing all of the encryption and it was sort of this big mess that i remember spending way too much time working through um and it's sort of like goodness i remember that encryption and squirrel yeah so it's just like you can what you really want to do is just get rid of all of this code and replace it with this nice little uh wrapped up class that does it all and uses the built-in encryption things that we have um so that got cleaned up a bit and i think you were also using some old planner code as well which was really cool to see i hadn't i hadn't seen that in really cool to see parses out too wow that's just pathetic

it was like i think you were using uh you had made a class that extended either input port or output port, which is how HTTP used to be done. And it doesn't break anything. No, it all worked before I gave it to you. We set it up so that when the planner went away, all of those classes would continue to work in quotes. And they would basically just shim classes so that people's code wouldn't break.

It wouldn't do what they wanted it to do, but it wouldn't break. What other things should I not make an effort to write? In fact, I shouldn't even make an effort to search the web for. I should go straight to your GitHub repository. Or even straight to the API guide because a lot of stuff's been added there

that wasn't there before. Yeah, so I'm not sure how much you've poked around on our newer documentation site. So we have a complete API spec on our developer center, and it shows examples for all of them. And we're either just getting ready to release or just did basically the same thing, but for a whole bunch of squirrel. So I'm not sure how much of the squirrel documentation you sort of tried to read.

Oh, that was unpleasant. Yeah. So that was sort of one of the really frustrating parts. Even internally for us who are developing on the Squirrel language and we use it every day, I still always hate whenever I need to go to the Squirrel docs to go look something up because they're just sort of muddy and difficult to find things. We should say that the Squirrel developers are actually really pretty wonderful people, but the documentation is geared more toward implementing squirrel

than using it yes it was as though i was reading it for cs course and not reading it to use yes so squirrel for electric imp developers is kind of a different brand of documentation and and that's here somewhere uh it might be it might not be released quite yet i think it might by the time this podcast actually goes live it will will probably be out. Um, but right now it's just sort of in our, in our internal review process, I think. Okay. Well, I'll make sure that's part of the show notes. And I do see, uh, like now there's the UART class and the SPI class and the S4C class and those I did mooch off of other people who are using electric amp okay it is nice that it's part of the maker fair or maker community that shares everything they do yeah so one of the

uh i guess one of the questions we always get is um whether we're open source and i guess we might as well just talk about that now um so i mean electric amp as a a platform is not open source, but it's really great that so much of our community, it's sort of a really open platform where all of the reference designs and all of the reference code that we write for applications are all completely open. And most people within our community, like you mentioned, are sort of have the maker mindset

and want to make things and share what they've made so other people can learn and build them as well yep actually to that end i i think earlier when we were talking about things that are on github that you wouldn't want to write yourself all over again um we should just mention because you put a lot of work into the web services classes that are up there now yeah there's twilio twio's there. Twilio just got a major rewrite, and it looks a lot nicer now. Firebase is a really powerful, like a back-endless database service that we really like to use

for a lot of our demos and tests. And there's a really nice class in there for dealing with that now, too. And I think we've added stuff for Zively and Plotly. And Prowl and Kinia, which I'd never heard of. I have no idea what most of these things do. I know, I look at their web services page and I'm like, I have no idea.

So what kinds of applications do these services enable? Yeah, so I guess we can just go through some of them. So KeenIO is an analytics as a service. So it's designed so that you can push data to it and then you can use some JavaScript and some other libraries that they've written to do fairly powerful queries and make pretty graphs and dashboards.

So is that for like correlating weather underground with like earthquakes or is it just like for drawing? I can give an example. Yes, please. So I went to a hackathon at Hackbright up in San Francisco maybe a month ago, and we built a little connected water meter. The idea was to prototype a smart meter.

And we were collecting water-used data for every five-minute block of time. We'd count pulses for five minutes and then upload what we got. And so we had this very granular data, but in order to build graphs that show you know, we had this very granular data, but in order to build graphs that show you how much water you used today versus yesterday, like a weekly graph, a monthly graph, how you're doing against the national average, how you're doing against your

neighbors, these were all things we wanted to do. And we didn't want to really write code that windowed the data and bind it up appropriately. Keen does that. So you just build a query and it's actually very human readable. So you can just like the, for the, like the timescale, you can say last four days and it'll just bend the data up. You give it an interval. So daily last four days, you get four bars and it's how much water used every day for the last four days. And there's no hand waving or anything like that. It just, that's all you have have to do so that was really nice for that application and i think we haven't explored all the things it can do but i think there's probably more i i think keen io would be really cool for quirky's egg tray so uh quirky made a connected egg tray that can count how many

eggs you have in your fridge i may have made fun of this on a previous episode. Quite possibly. So I think there's the potential for Quirky to be the leading egg experts for how consumers consume their eggs. I think you could get lots of interesting data about that. That's a big market. It is, I think so. But you could get all sorts of interesting things.

You could get how long people leave their fridge doors open for, because that's a thing that you could really easily sense. You could see how long it takes people to sell or to consume 12 eggs, how often they refill their eggs. I think there's lots of data that you could sort of slice and dice in interesting ways with an application like that. Sure. You could see Christopher's breakfast every day, and then when I make cookies. Okay, so that's Keen.io. That's Keen.io. Chris also mentioned Prowl, I think was one of them. So Prowl is a really easy way to do push notifications to different devices. So that's push notifications are when you get a little pop up on your phone or on like a Mac computer or something that says, Hey, there's something that needs your attention.

Um, so prowl is this really great service for it. Um, that's sort of generic. So typically if you want to do a push notifications, you need to write a custom app. You need to register all of these weird things. And it's, it's a pretty big process to do it. So the way Prowl approaches it is you just download and install the Prowl app, which you can get for most mobile phones. I think you can install a Prowl client on Windows and macOS. And then you basically register an endpoint with your account and you say, whenever a message gets pushed here, send a push notification to all of the devices that have Prowl for this account.

So this is sort of a cool way to push important information that you want to pop up and maybe not through email or something else so we've we've looked at using this for the building that we're in right now sometimes forgets to turn the heat or air conditioning on. So it'd be cool to have like a temp bug in our office somewhere. And if the temperature ever got above, oh, what's the Fahrenheit? I'm still Canadian and use Celsius for temperatures. I think above 80 is pretty bad for indoors during the week. So if it gets too hot or too cold,

it could send a push notification to like a building manager or to somebody who could alert a building manager to say, hey, something's wonky. It should probably be looked at. And hey, look, now your readme for the GitHub Electric Imp web services has all of the list of what the services are and what they do. Thank you for that.

Yes, that's sort of one of the things that's been on our to-do list for a while. So one of the things we're really trying to do with our GitHub is make it so that it's a lot more friendly for people to find the resources they need. So we've done that for the web services. We're in the process of doing that for the hardware section. And then also make it easier to contribute to it. So one of the big things that we want to see is

a lot of the classes that are in there right now are code that we've written internally for projects we've been working on or for customers that we've worked with. And a few of them are contributed by our community. And we've certainly had a lot of bug fixes from them. But we're really excited about the prospect of having sort of our larger community contribute new code and new functionality. That's actually, the last six months have been a pretty good uptick in that.

We've even gotten developers coming in from our customers, people that are actually trying to ship production devices. Their programmers have come in on a couple of different reference design examples. So like the example code that we post with the reference design and submitted pull requests against my old code from a year ago and fixed things that had been on my to-do list. And that's just really wonderful. It's amazing that the platform is open enough and that the customers are that committed to reusing the code and making the code available for other customers to use as well. That's been a really cool way to work with people that we wouldn't have worked with before.

That is really cool. And web services are all agent side. Yep. And then you mentioned there's a hardware repository too. And looking through it, it's a lot of sensors that I recognize and some that I don't, like spy flash and a couple of accelerometers are on here. And I'm not sure what a DHT11 and 22 are. Those are actually temperature and humidity sensors. Those are very popular, I think, with Adafruit and SparkFun as

well. And those do use Dallas OneWire. And we actually talk to those just about the same way that we talk to NeoPixels. So essentially, before I add a new sensor to my system, I should look here? Yeah, take a quick spin through the GitHub and just see if there's work that's already been done to support what you're trying to work on. And if there isn't, definitely let us know. Because if it's something that's interesting enough that you'd write a class for it, that's definitely something that we should keep in our repo. So really, I could have gotten you guys to write all the code for me?

Maybe. You wanted to know more about Squirrel, didn't you? Well, yeah, it's not something that, as a software engineer, I've heard of before, so maybe that's just because I don't move in the web development circles. But how did you guys settle on that? And was that an easy decision or was that a long and torturous path? So the story behind Squirrel is kind,

it's not too long of a story, I guess. So initially, the electric amp in the very, very early prototypes was using Lua, which is Lua and Squirrel are used in a lot of really similar applications for a lot of sort of similar reasons. They have really light VMs. They're both, well, Lua especially is quite popular in the gaming community. Squirrel is used as a scripting language in a few different games, but not nearly as many as Lua. And sort of for the reasons of when you're running in a resource-constrained environment like a video game, if you're just a scripting language inside of it,

you want it to be lightweight, you want it to be speedy and do all the things that you want it to do. And that actually happens to translate fairly well to embedded applications as well. So we were working with Lua, and about a week before we actually sort of announced and made ElectroCamp public, it was decided that Lua was not going to be a good thing moving forward. I think largely because of how arrays were handled or weird memory things. There were a couple of data types that just didn't do the things that you expected them to do. I think that was one of them.

It didn't have arrays. Okay. The way that Squirrel has arrays, the way that C has arrays. And there actually have been some advancements. There's an Elua project that's worked on making an embeddable Elua. Actually, a lot of the things that have showed up in Elua we've made modifications to squirrel to suit the same purposes okay um actually i think uh one of your listeners sent in a question a while ago that was in your your list why didn't we use java right yes punky asked one wanted to know why why not java since free scale

and oracle and arm are all kind of pushing that for Internet of Things? And that got my attention, so I looked it up, and Java has five core tenets. It turns out that they really said this was the purpose of Java. They wanted it to be simple, object-oriented, and familiar. That was really largely why we chose Squirrel. It looks just like JavaScript, so it's simple, it's object-oriented, and it's familiar to a lot of people that are interested in user experience and how defining device behavior. It has to be robust and secure.

It's got to run under VM. We don't want you to be able to push Squirrel that can brick a device. That's why we picked Squirrel, is that the operating system can clean it up and fix problems. Needed to be architecture neutral and portable. Well, we've got Squirrel onto an STM32,

so that was definitely one of our goals as well. High performance and lastly, interpreted, threaded, and dynamic. High performance is a little bit of a subjective thing to say about a language. Yeah, especially in an embedded world. Yeah. But we can record and play back audio

on a little microcontroller. So I feel pretty good about that. And it is interpreted, threaded, and dynamic. So Squirrel really kind of approaches the same goals that Java approaches. And I think we chose it primarily because the VM was a little bit lighter. And we were a little bit less concerned about potential licensing issues. Oh, that's a good point.

I wouldn't have... Do you feel like you have more influence on the Squirrel development than you would on, say, Java? I mean, if you have some language feature you really, really want. Sure. Well, that's a little bit more about how the language is put together.

I should say that I don't work on the team that builds the AMP operating system and implements Squirrel. But I do know that they do have routine contact with the original Squirrel developer who put it together, I think, for a PhD thesis. And we've worked back and forth with him before. That would be harder to do with Java. Sure, yeah. Java's a little bit more of a large community And I initially found Squirrel a little odd Coming from C

But once I kind of shifted my perspective And came at it from the website From JavaScript, it all made a lot more sense It was just a matter of putting my head in the right place sure yeah one of the one of the big things that we see um especially with sort of embedded developers who are coming to our platform is it's a really uh it's sort of like a fundamentally different way of thinking about how you want to develop your hardware um you're you're coming at it from a much more sort of event driven perspective so

you're not saying what's my you know what's my super loop going to look like what am i going to do for all of these like tiny you know tiny weird quirks to make things work um it's more of a high level flow type programming language i think i agree with the high level but and and they talked about some of this on the Amp Hour. But I disagreed with the asynchronousness. I'm used to interrupts and all these things happening and being event-driven. And sure, I have a wow one loop, but all that does is pet the watchdog and call whatever operating system call I have. Everything else happens whenever it needs to happen. Why do you think that's so difficult for embedded people?

I guess embedded might be the wrong description. I guess Arduino maker might be a better description. Ah, okay, okay. I'm on board there, yes. Yes. Let's see. One of the things that I meant to cover back, you know, in the introduction,

because we haven't quite finished that section yet, was BlinkUp. And that's how you program the imp and it flashes a smartphone screen and the imp gets your SSID and password and your credentials to Electric Imp so that it attaches to the correct account. Right. Do you like BlinkUp?

Yeah, I do like BlinkUp. It's fast, it's secure, and it does everything we need it to do. I sensed it maybe... I liked it to start with, but then I tried to talk somebody through it over the phone, and that went really badly. I've definitely tried to talk a great number of people through it over the phone.

BlinkUp has grown up a lot. Early on, BlinkUp was not as sophisticated as it is today. And the wide variety of Android devices just made the experience of using BlinkUp even more variable. It depends largely on the frame rate that your device will hold and what it does when it decides not to hold it. And we've added a ton of stuff inside BlinkUp, how it works and how it's received on the device that make it a lot more reliable across a lot more devices. It also changes depending on whether you're talking about getting a developer through blinking up a dev kit versus getting an end user through blinking up an imp-based product. So how is that different? I've only used the dev kits.

Sure. I think it must be easier for the end users. Yeah, I did it with the Lockatron. It was a little, I mean, it seemed easy. Yeah, so BlinkUp is tunable. And in the cards, this isn't really something that you notice because the entire BlinkUp circuit's already defined. It's all built in.

But if you're using a module-based device like Lockatron, like a lot of other products that are out there right now, you put down your own photo transistor, um, and you put down your own, um, like a bias resistor to control the sensitivity of blink up to light. So a customer that has a device that's going to be used in your yard, that's going to be vulnerable to a lot of bright sunlight or something like that might choose to make blink up less sensitive so that it doesn't saturate when it gets all that bright sunlight near the actual receptor. Whereas something that's used in a dark room might be made, or maybe I've got that backwards now. At any rate, you can tune it

for your application. So there's less of this, well, am I holding my phone correctly? Is it in the right place? Do I need to go in a dark room? It can be set up based on how you know the device is going to be used. And my instructions for the phone finally were, okay, now hold it under the table. Yes. Which is very frequently in the instruction. Which finally worked.

Yeah. There are other ways of putting in SSID and password information. Yep. Are you talking about doing those in conjunction, especially for the products, the people who are OEMing the electric amp and putting it into their consumer products? Mm-hmm. So it's important here that BlinkUp doesn't just give you the SSID and password. BlinkUp gives you the SSID and password and claims the device as yours. Right.

That's what attaches it to my user account or to Lockatron's massive number of accounts. Yes. Yeah. Sorry, I didn't mean to cut you off. No, no, that's fine. Either as a developer or a customer, that's what makes it yours. And it's really important that it does that because that's part of the security of the device. There are different things you can do to just move the SSID and password around once the device has been claimed. Say you were moving it from one location

to another, but not from one account to another. That could be done programmatically. And we have looked at some of the ways that other devices handle configuration and SSID and password and user account. We are always kind of paying attention to what other options are available to solve the common problems of connected devices. And when we see some options that let us move different use cases from impossible to possible, we tend to go after those. But it's done based on which one is going to get the most from column A to column B. And I think BlinkUp has been a really versatile solution there because it does tend to support just about every application we've come up with. And I don't love BlinkUp up but i don't hate it and i certainly don't have a better suggestion the whole make a little wi-fi hotspot uh access point and then log into that and then set all of

your information is far more annoying than blink up sure and the usb it adds so much cost if you're doing like a usb printer to do wi-fi yeah it's just so i don't have a better suggestion i just if you don't love it yet i think what i would suggest is check out some devices that have really been tuned um because it has come a long way since we decided on the hardware design for the cards and that's still how the cards are made um if you take a look at make deck uh they're a little startup that one of our forum users actually just started out of Pennsylvania and this guy just started his own small business and he sells module-based dev kits to kind of pro-level imp developers so he has one that's pre-designed to work with a lithium polymer

battery he makes really really small breakouts too And since these are all module-based, he had the chance to put down his own photo transistor and tune the circuit. So it's a really good experience getting started with that. You get twice as many GPIOs. And it's a good piece of kit. I've used it for a lot of projects around the office, and I've been really happy with it. Neat. Make a deck.

Okay, cool. That would be the show notes. So what other really neat products have you seen built with the imp? Are we talking like commercial products or things that are, our community is just sort of hacked together? Let's go with community first. Community first. So I ended up going to a fair number of university hackathons as part of my job to go sort of support and sponsor them. And other than the midnight-ness of it, that sounds really fun.

It is. The exhausting, I really like hackathons, so I usually go and I spend most of my time actually at the hackathon and mostly just sleep a little bit at night and hang out and help people build things all day. Um, so I've seen some really cool projects come out of that, that have ranged from sort of, um, like this is, this is potentially a really good business idea all the way down to just sort of, that was really cool. Um, so one of my favorite has been um are you familiar with uh twitch plays pokemon the the internet sensation is this where a crowdsource group of people like hundreds of people play pokemon all at the same time yeah and attempt to control it randomly yes um so it somebody designed they used uh twitch which is an online streaming thing that has a chat window with it,

and they built a little application to look at the chat window, and people could type in commands like up, down, left, right, A, B, whatever other buttons there are for Pokemon. Select and start feature fairly heavily in Twitch Plays Pokemon, unfortunately. And so what twitch plays pokemon

did was uh based on like there is one mode that was anarchy where just take every single command and execute it um and another called democracy where it would take the the one that was voted for the most um and it would move the character in that direction or click that button um and that one of the hackathons that i was at, I think it was in Princeton maybe, they actually had access to a laser cutter and a bunch of other hardware. And over, I guess, 36 hours, a team from scratch built a new hex bot. They laser cut all of the pieces for it. They hooked up all of the servos.

And they controlled it with an imp over a twitch stream so they made this hex bot where you could type in commands like forward or back and it would move the the robot forward or backwards i think you could make it wave and it would waggle one of its arms so that was that was a really kind of cute project and really sort of capitalizing on things that university students were into. Did that go up on the community page? I don't think that one did, no. That one really inspired me to the large number of other applications that could be humorously executed,

such as Twitch waters Matt's front lawn, Twitch drives the NASA Curiosity rover, and so on. Oh, that's another good one probably the the coolest community project um i've ever seen is uh it's by a i think a researcher in the uk called uh john rogers and he does a bunch of interactive design type research and a couple years ago for i believe it was for nasa space apps which is a big hackathon that NASA does each year that sort of, it's at a global scale and different, you know, different cities do different things for it. And they 3D printed a replica of the Mars Curiosity rover. And they were able to get a feed from NASA so that they could get basically the movements that the Mars Curiosity rover was

doing. So they would put this guy down and they would turn it on and it would move in sync with the Mars Curiosity rover on Mars. Okay, that is really cool. I think that's my favorite project because everybody loves space. Okay, now I don't want to talk about the commercial product because it's just so cool. I do have listener questions. So we covered the one from Punky, and there was David from Australia,

but not Dave Jones from the Amp Hour. Thank you for these really short names to call you. He asked about MQTT. MQTT. Which is one of those, I always hear it with XMPP and the Internet of Things, and then that's about the time that I tune out and go take a nap or something.

That's a lot of people, I think. I know. Are you going to support an MQTT module? What is it? Oh, I'm sorry. I only have Wikipedia familiarity with MQTT. Is that the maximum amount here? Because that's kind of bad.

I think Matt has actually built something with MQTT recently. Kind of. Kind of in a workaround way and not with the AMP. It's a messaging protocol for use on top of TCP IP. Yes. So like a remote procedure call kind of thing? So it's designed to be a lightweight messaging protocol. So the idea is with a lot of Internet of Things applications,

you want to be passing messages back and forth between devices or between devices and servers, and you don't necessarily want the full HTTP stack that you might need to be to be passing messages in easy way. Um, and so electric amp kind of, uh, skirts around this question because, uh, we, we sort of do our own thing for the communication between the device and its agent. Um, so that's just sort of messages that are passed back and forth, um, in sort of our and forth in sort of our own protocol. But I could go from an agent to an MQTT gateway

and then get on to the MQTT world. You could. And you've done that before, Matt. Yeah, so there's a service called Telemetry and they're all about MQTT data. So they provide a HTTP as well as an MQTT interface for MQTT buses, I guess. And so I've been playing with an Arduino shield

that they've released called the Coyote Board, and it lets you... Oh, that's been on your Twitter stream. It has. So it's a little cellular module that hooks right up to their service. And then you can listen in to MQTT messages. So you can open up a port and listen to whatever your device is streaming out.

And you can also forward those messages to anywhere else you want with sort of rules that they've built. So you can say, if you get a message on this particular feed, then forward it to this HTTP address. Or if you get a message at this HTTP address, forward it to the MQTT feed.

Too many letters. We're just going to take all the T's out of the acronyms now. It's just too many. Although that does kind of bring up a question from Elizabeth, who was my guest a couple weeks ago. I think I was about to ask this, so yeah. The RUOK. Okay, so I have the RUOK widget,

and I'm not going to explain what it does in hopes most people already know. But you could have multiple of them. They'd sit around your house, and you could pet them or whatever. And right now, each of my electric imps has its device and they're all running the same device code and they're all running the same agent code. What if I wanted multiple devices to go to the same agent? Sure. Yeah. And there's a lot of different types of projects that do kind of want to aggregate

data, right? This is one of the areas where we've used Firebase quite often because I don't really want to spool up my own server, right? No, I don't. I really don't. It's not my idea of a good weekend, good time, right? I'm perfectly content to let Gmail handle my email server needs and so on and so forth. But Firebase is great for this because we have an agent class for it already.

So you just drop the class in and then you tell it where But Firebase is great for this because we have an agent class for it already. So you just drop the class in and then you tell it where your Firebase is and it's a big database on the back end and you can push events to it and you can actually have, if you've got some other, like you wanted to run some code against the data as a whole, you could just spool that up on a server once and just point it at the Firebase and it would do that. And you wouldn't have to worry about actually collecting the data and maintaining a database and everything like that. So you can push data to the Firebase from any agent and any other agent with the Firebase class that knows where your Firebase is and knows the key for it can receive those events. They'll actually be pushed from the Firebase down to the agent the agents the agent doesn't have to go look for them or check in or anything like that

so it's it's an interesting kind of hub so all of my creatures would go up to firebase and then one of them would be in charge and the in charge agent would get the information from Firebase and if we didn't get enough check-ins on all of the devices, then it would text me or tweet to me and say they didn't check in. They didn't pet any of the devices this morning, go over there, call them, whatever. Sure. You might not have an agent actually be doing that check to the Firebase to send you the SMS or something like that. That might be a job you choose to do in Python or something like that. And you could run it wherever you want. But an agent could also do a job like that, where any of the agents that's talking to the Firebase could take a look at the data at any time and be in charge of sending you an SMS. Yeah, I don't really want to run my own server.

You guys can do that for me. Sure. Yeah. The point is the collection of all the data from all the agents isn't hard if you have a service that can pull it all together like that. Is Firebase similar to If This Then That? In some ways, and in some ways it isn't. I would say no. So If This Then That is really all about having sort of separate predefined services and hooking them together. So you're saying, if something happens on this service,

then trigger an action on this service. Firebase's Jam is sort of all about basically building data-driven applications without the need for hosting your own backend. So Firebase does two things really, really well. So they make it really easy to collect data in a sort of semi or very structured way. So you basically just push JSON objects to Firebase and it will store them. And then the other thing that it's really good at is pushing that out to everybody who's listening. So it's really designed to be a real-time backend,

is what they describe. So you can open up a request to a specific Firebase or to a specific node within a JSON table in the Firebase, and you'll get data pushed to you whenever that changes, rather than having to go and pull it. And then along with that, they have all sorts of other cool security things and other sort of features that you can use. But those are the two sort of really interesting ones

for something like the REOK project. How expensive is Firebase? They have a pretty good free plan for developers. Sweet. Yeah, as always. We've never paid for it, I don't think. And that's not because we're electric imp. It's just because we've never had to so they're they're all gun was free for like 10 000 emails yeah yeah if i get 10 000 i'm not okay emails in a month that's just a bug so um

i think firebase is pricing uh there's a little bit based on data but it's pretty hard to exceed their their data limits because you're not really using it as a database to store gigabytes of data. So the thing that they mostly charge money for is the number of concurrent connections. So since they're designed to be this sort of real-time backend, there's a lot of applications that use them where many, many applications or many instances of an application

will be synced up to a single Firebase database. Think of an entire user base all running an app at the same time and the app looks straight at the Firebase. Yeah, so I know there's been a couple games that have been built with it, like multiplayer-type games. So once you start getting more users, that's where the value really comes in because you basically just open up a feed in each of those to say listen to the firebase

and when it changes update your client i like all of these little web services that kind of let us little moochers who just want one or two things yes they just and i it's good for them because it's a good way to to get me to understand the service. Yeah. And there's tons of people out there who have been just waiting for all this data to arrive, all this Internet of Things data. And they've got all these nice little things you can do with it. And the only thing that's been, I think, keeping developers from them is there's no way to get the data in.

And that's kind of the one thing that we're really trying to be excellent at. So another question from a user, David, again from Australia, but not EEVblog. We talked to him about how to learn Squirrel and how there's going to be a better tutorial by the time this airs. But he also wanted to know

if you are building US and non-US versions of this system, and is that a pain because of channel limitations in Wi-Fi? We do build non-US versions. There's an EU version. Actually, I think there's more places that we do have regionally approved things than don't. I don't think I can list them off for you, though. And it really isn't a pain. Our Wi-Fi chip handles all of that.

We give it a country code, and it tells it what channels it's allowed to use, and we never have to think about that ever again. The operating system just does the same thing on all of them, and the Wi-Fi takes care of the Wi-Fi. Cool. Okay, and this one is from me, which I guess I did put that in the notes. Thank you, old me, for making me sure that your code is correct before you ship it you do linch checking and i swear there were every time i touched the code i would make a typo and change a variable name and not find out until like three weeks later because that was how long it took

for my battery to get low or whatever yeah this is i guess this is one of the sort of uh curses of using interpreted languages is that you need to run your code to tell that it's broken in a lot of cases um but there are cases i mean uh i heard about the putting it in your garage door with an accelerometer uh on i guess that was the end of the amp hour. I don't know if anybody else finished the show. I did. Yeah. Oh, right.

That was Brandon's project. That was Brandon's project. Yeah, I listened to my boss's entire podcast. And you didn't listen to it. Just like he's going to listen to the entirety of mine. But he put an accelerometer and it would tweet to him, text to him if his garage door was open for more than five minutes because that meant he forgot to close it. And so the important part of that is when you've hit the five minutes. The thing that is most important is when it

fails. And that's the hardest condition to test. And so that's, that is hard. It is. How are you going to fix it for me? So there's a few, there's a few obvious answers and a few not so obvious answers, I guess.

So one of them, I guess, if we're talking about grown up engineering and, you know, writing unit tests and everything like that, that has as much to do with how you approach writing your code and the style and sort of how you go about writing your code

as it does the frameworks you use. Well, and that's a web thing versus an embedded thing for sure. There are devices that can kill you, and therefore you don't screw them up. Yes. And there are very few web pages that can do quite as much damage as, say, a car. Well, but even with web pages and web applications, you know, there's still,

there's a pretty strong test, like TDD culture with web developers. Definitely. More and more, which I think is good. You still can definitely write tests for squirrel code. You write all your functions so that they're single-purpose functions and they don't encompass tremendous amounts of functionality. Then you could just have a little bit of code at the bottom to test each function the way you want to test it

before you finish actually bringing up the device where your power on self-test includes your unit test yeah or you you do your unit tests and then you you know you comment them out when you ship it or you comment them out when you're actually running it um you know that's not the the best experience obviously allow multiple files to you, so it's still just one file for the device and one file for the agent. Put that on my wish list too. So some of the features that we're working on in the really short term that we can talk about are an API for our IDE. So this is going to be sort of a set of web endpoints that you can use to get information about your devices and upload code and read logs. So once we release this, I'm really excited to see what kind of tools our developers build around it. Yeah, because right now, if I want to look at three different

RUOK widgets, I go through each one and look at their server logs individually. Yeah, and when you want to make modifications, you need to do it through our IDE. Which is web-based. Yeah, which is, there's good things about it, and there's not good things about it. And most of the not good things come about when you're talking about grown-up engineering. Yeah, the Web IDE had a job to do,

and its job is to be quick and easy to get started as a developer. You don't have to install or build anything and it will work on anything that has a browser on it. But it definitely does fall short when it comes to adapting to developers' workflows instead of making developers adapt to it. And that's what Open Endpoints are all about. This is about building plugins for whatever your existing flow is so that you can stick with it and make it work for you.

And you mentioned device analytics having five devices on my account at one time which was the max and now i'm back down to three it was it was a little daunting to take care of them all and i think about lockatron with a lot more yeah so um there's there's a bit of a there's a bit of a difference there. Commercial developers have always had a separate interface that they get that lets them manage their firmware and get some extra analytics and push updates in a safer way that's not just command S or build and run.

Every time I save it updates even if i didn't really mean to yes um so i mean one of the with the web endpoints for the ide the thing that i'm really excited to see is for something like test driven development you could write like a plugin for emacs or for you know eclipse or your of choice, where you have a project and your project has a bunch of files. And when you click test, it uploads your base device code, and then it appends a test file, and then it runs that. And if it passes in the logs, it returns a result. And then when you click deploy, it uploads your base code

plus your application code. So I think there's a lot of potential for really powerful tools to be built around that, and I'm really excited to see what our community does with it. Yeah. We actually have prototyped this before and did have some pre-check of Squirrel syntax before even uploading the code. Squirrel being an interpreted language,

you can install it on your Mac or your PC and do a quick syntax check there have you guys seen what apple's doing with swift yeah yeah watch wwdc yeah the the playground thing was interesting to me from an interpreted language standpoint because you had i don't know if you've seen this but uh you have the id and you have code you can edit and then on the right side is basically the side effects of all the code in real time. So any contents of variables or arrays, it'll even plot the arrays as you go. It runs all the for loops as you type them,

and you can see the effects of everything as you go. So it seemed like that's the way some development testing, or at least initial development testing, might be going. It could be applicable to other interpreted languages. It's a great training environment. Yeah. Yeah, I don't know if I would ship any code after having just played with it in the playground.

Right, but it's a good debugging tool, too. Oh, it's a phenomenal debugging tool. Yeah, it would have caught all of my misspelled variable names. So I think I have one more question. Well, I have, like, three more like three more but good keep them coming uh you're a platform and so your customers are engineers although you have to be aware of the consumer market what are your thoughts pros and cons of of having in your engineers as your customers i like it uh i get engineers engineers Engineers make sense to me. Consumers don't always know.

Well, I mean, consumers can, but sometimes I have to understand their story a little bit better. But understanding the needs and wants of an engineer is definitely something that we find pretty relatable. And I think what's neatest about having engineers as customers is they often aren't engineers that are experienced in doing the same sort of things that we're doing. They might not be embedded engineers. They might be web developers. They might not be engineers at all, which we get sometimes. They might be people looking to start a new venture and they just have an idea. You do make it sound very easy. And it is pretty easy. Some things are pretty easy some

things are not and sometimes there is a learning curve and helping people through the learning curve is really interesting but uh seeing people that didn't think they could do this a year ago get a product to market is one of the more satisfying parts of the job um and having them come back and give feedback from the perspective of someone who does have experience. Like when you talk to an engineer and they say, this is good, this isn't good. That's actually really rewarding too, because there's things you can do about that. Do you have an answer too? I guess I've always sort of been in roles where I'm walking a fine line between engineers and non-engineers.

Most of the software development that I've done has always been very, very closely, like working very closely with end users. So it's always been sort of walking the line between engineering and technical people and non-technical people. And I also get the great pleasure in my position to get to deal with makers and not uh our sort of customers as much so well all those hackathons yeah it would be really interesting to go and see what people come up with yeah i can see that would be a very fun part of the job well you get people jumping across the line to makers that become uh commercial customers all of a sudden which is just wild and really really cool well that goes back to firebase offering things for free for

small customers right this is why you have hackathons because somebody may say oh yeah i didn't know yeah and that's that's what you want and on the other side of the spectrum it's really cool too like having an engineer that's more experienced than me come in and say, Hey, I've got a bug and it's somewhere in my code. And like, maybe you can help me fix it and throw you a 8,000 line squirrel. Right.

We actually have taken a calling those rodents of unusual size. That's great. Yeah. So that's, that's really cool too. Cause you find people using things in the language that we use every day that we didn't know were there because they were that experienced. And then you add that to your, your repertoire and then you can use that the next time. So

having engineers as customers makes, uh, our engineers, better engineers, which is fun. All right. Well, uh, I believe, you know, that we're having this, from the Elizabeth's show, we're having this contest, which was to name an R U OK? widget. Oh, yeah. And I'm a Hackaday Prize judge. We didn't talk about Hackaday at all. Should I stop now? We should talk about space. It's even better because it's a space prize for Internet of Things things, isn't it? Or is it more general than that? They want it to be connected.

But they also want it to be futuristic. They haven't set a whole lot of rules here. I'm so looking forward to so many cool things already and I'm trying not to snoop too much because it's dirty in the judging pool. And yet, this is cool. Can I build it?

Is it daunting being a judge? There's such high stakes going to space. I'm on such a great team. I mean, I figure Jack Cancel and David Jones and Lee Morfreed. It comes to worse, I'm just going to say, oh, that's a good idea. and David Jones and Lee Morfreed. Worst comes to worst, I'm just going to say, oh, that's a good idea. I'd love to just spend the weekend hanging out with that judging panel.

I know, me too. I don't think we're ever getting together. You should email around and remedy that. That'd be a lot of fun. It would be a lot of fun. I have been going through the judging panel and having them on my show. So Joe Grand will be on in a couple of weeks.

Oh, that's great. Yeah. Do you have any Hackaday prize things that you know about that are using electric amps? Oh, I submitted one. What did you submit?

I submitted. Don't tell, you'll have to recurse or refuse yourself. It's fine. So actually, are you kidding? Do you have more dev kits? Cause you know,

there's bribery here. Ah um i actually submitted i submitted a space project actually well kind of a space project um so i built a little rectangular box um out of uh acrylic i got it laser cut with a service called pinoco um who i think are based in oakland so you just send them design files and they'll laser cut things for you. So they made me this really nice box and I basically just put a bunch of NeoPixels in it. And it's hooked up so that whenever the International Space Station is flying overhead,

it lights up and glows. And that's all that it does. It's just, it's really pretty. And it sits on my desk at home and it glows sometimes. And I remember there's people in space. That is cool. I don't think I'll win, but I think it's pretty sometimes, and I remember there's people in space. That is cool. I don't think I'll win, but I think it's pretty cool. Tell Isaac Newton that's all it does.

Do you have all of the files online? Yeah, it's all on, I think it's on my GitHub account. And in your Hackaday entry, did you make it so that if I wanted to go out and build one i could do that right now yeah absolutely because that's going to be one of the big judging criterias so there's there's all of the design files for you to send off to pinoco and you could if i guess if you had you know your own laser cutter at home um you could probably laser cut it at home and then all of the the code and the components are really easy to come by it's like like there's an amp dev kit and a DC plug and some NeoPixels.

And you solder like six wires and that's it. Surprisingly few parts. I think the hardest thing about the entire build was just gluing the box together. And that wasn't that hard. Neat. That's going to be one of the things I am going to look for. If I wanted to build this, could I do it? Yeah.

And that's given my soldering skills a higher bar than you might think. Okay, so contest. For winning the $75 gift card for SparkFun, and then Tom and Matt did bring me two electric imps and instead of thinking up a new uh contest i'm going to give away an electric imp and the april board they came with as runner-up prizes that's okay with you guys right that's that's cool prize cool because i mean this is this is the expensive this uh april board and electric imp is the core of how I built Maxwell and the other ones. So, you know, you're getting half the hard and difficult part of the system. Although if you see me trying to stitch together an octopus, I think you might change your rating of what's the difficult part of the project. Oh, no.

Actually, I went to Target and I just bought i bought a dog toy oh and then ripped it all apart you didn't have to make it from scratch no no yeah the manatees are from scratch the manatees are from scratch yeah uh but i don't sew very well okay and he's made of hot glue and fishing line yeah and and velcro there's there's not much. Fancy. Yes. Okay, so we got a lot of good, really good entries. And people gave long descriptions of what they were going to do with it. And I'm not going to read them all, even though I kind of want to. I'm going to instead finally choose winners.

I have this piece of paper where people have marked who their favorite is. And Elizabeth, who said she would be the tiebreaker judge, said, no, I can't decide. Just flip a coin. But we didn't have to. The runner-up winners of Electric Imp, the first one is going to be Alex Irvine for his Crustacean Crusader Crab that's going to go on something that has to be opened, like the fridge or the pantry. And the that's going to go on something that has to be opened like the fridge or the pantry and the crab is going to have the claws the hinge and if it opens the crab will know and it'll be a switch that activates and it can move its arms up and down to indicate it's been activated

so um the crustacean crusader crab yay um the other runnerup is the penguin named Peck from Chris Feck. And the Peck name is short for peckish, meaning hungry, and it would also go on the refrigerator. But it can also mean peck as in kiss on the cheek. Like you'd give a loved one, which was very in theme with the contest. And, of course, on a bad day or on one of those internet creepy spy days, it might mean hen pecking or actually chicken pecking, which has worse connotations,

but that's what family's about. Chris did get a few extra points because he was the one who originally pointed out that Maxwell had the well part of him, and he suggested Rosie and Haley too. And since I used Haley on one of mine, I can't exactly. He definitely gets points for that.

And so they're both getting electric imp. I think I have your emails. If I don't and you haven't already got an email from me, contact me. And the winner came over Twitter and was actually the first one we got. And that's Oki, the plush tree, plush oak tree, of course, that makes sure you're okay. It's going to have a wooden A button on the top so you can send an actual oak A.

So thank you, Ken M., for that. Yes, puns. I should have noted there would be extra points for puns pun gods have smiled upon this one we are big pun fans at electro camp if you've ever read our blog i have you are every title is a pun just about oh and then i keep i keep i'm looking at this list i'm like oh but what about that one? And then what about, you all did a very, very good job with these names. I am so pleased. From everything Michael the Mole to Is Doug Gone Doug On, which was hilarious and very keeping in with the Mandy and the maybe not dead yet name. St. Bernard's and Seamus the Leprechaun.

I'm not going to read them all, but great job. Thank you for everybody who participated, and it was very hard to choose. Having babbled about all of that, now back to my guests. Matt, do you have any last thoughts you'd like to leave us with? I don't think so. Okay. An honest answer. I definitely do.

I have probably 30 or 40. I'd talk into a mic for the next six hours if you let me sit in front of it. But if I only have to pick one, I would say if you haven't visited the Dev Center and the resources tab recently, or even if you have recently, by the time the podcast airs, definitely go check it out. We've been putting a ton of work into it. And there's a next steps page now for when you finish

blinking an LED that takes you to how to build all the instructables that we've put up. They're all put together there. There's lots of fun stuff you can build for reasonable amounts of money and with reasonable amounts of time. And they'll all help you become a better developer. And there's lots more for Learning Squirrel and lots more for getting in touch with us. So if you haven't been there in a while,

or even if you have, go check it out again because I think it'll be worth it. Matt came on a year ago and the big thing I said to him for weeks afterwards was, this documentation is insufficient. And I am not saying that anymore. It's gotten so much better. Good job on that.

Thank you. We're still saying that. I don't think we're done yet. So we'll try to keep it going. But the track is great. Excellent. One of the really exciting things that's happened recently is that we hired a technical writer. So even if you, as Tom mentioned, even if you have been to our resources center and to all of the resources we have, that's sort of constantly being worked upon now.

So we're putting out new documents all the time about this is how you work in depth with this functionality and this is how you this is how you use this api to do x yeah um so it's definitely improving and it's definitely a really great resource for a lot of our developers yeah we hired we hired not just any tech writer either he's an avid maker of things he's very well written and he's fun to read and he hits the nail on the head um so they're they're docs that won't bore you to death they're they really spot on. Oh, and you are starting to link to other people's projects. We are. We're the community page. And I have my Are You Okay widgets on SparkFun,

but I would like to link it to you. How do I do that? Yeah, so we have a new community portal. It's community.electricamp.com, and it's a blog and project collection from people within Electric Amp as well as people within our community. And if you're interested in contributing to it, you can just send an email to community at electricamp.com right now. We don't have sort of a formal process to go through, but that's sort of one of the things we're working on. So we're hoping that

this is going to be a great place for everybody to share their projects and their builds and sort of get an idea of what other people are working on. Very cool. My guests have been Matt Haynes, and that's Bearded Inventure to many of you on Twitter, and Tom Byrne of Electric Imp. Thank you for joining us. Thanks, guys. Thank you very much.

It's been a real pleasure to be on. Thanks for having us. And thank you to Christopher for being on and for producing the show. Thank you all for listening. I have enjoyed this contest quite a lot, so we'll be doing more. But even if you didn't participate,

thank you for being there. Hit the contact link at embedded.fm or email us at show at embedded.fm if you want to say hello. The final thought for this week comes from Elon Musk. And he said, if you go back a few hundred years, just a few hundred years, what we take for granted today would seem like magic. Being able to talk to people over long distances to transmit images flying accessing vast amounts of data like an oracle i think he's right it's a pretty cool time to live