You are currently browsing the make tag archives.

pushpin

Thermostat V3 Schematic

Here is a schematic for my Thermostat V3. It’s something of a ‘block diagram’ as I did for the ISEB6 layout, as it is another project that was mostly assembled from off the shelf modules.

You can download the PDF version here.

I have omitted the lux / luminosity sensor in the above schematic, because it’s not working very well and I find it’s fairly pointless. I’ll likley remove it from my thermostat next time I’m doing work on it.

For something of a BOM and assembly instructions, please download the zip file that was linked in the original Thermostat post.

Cheers!

pushpin
  • Number:
     25605
  • Date:
     2012.06.13
  • Time:
     13.35
  • Check:
     207
  • Origin:
     Hobbies

Ok, Gonna Try Learning Eagle…

I’m going to have another shot at learning this Eagle thing. I’ve tried twice before and both times it made me want to cry (why does it have to be so difficult!) but enough people are using it that it seems to be the standard when it comes to schematics and pcb layouts.

Still, what ever happened to hastily-drawn pencil sketches on the backs of napkins?

Anyways, it would really, really be nice to get my own custom PCBs made now and then, for some of these projects. And it would be equally nice to be able to have a schematic to share.

If anyone can suggest a good tutorial, please let me know! I know there’s dozens of tutorials but I don’t know which ones are any good and which ones are crap.

 If I do manage to figure this beast out, then I’ll give myself two rewards – first, I get an Eagle badge from Adafruit! And second, I’ll get a custom PCB made for my ISEB-6 Mark II which will be loads of fun to assemble.

No deadline for any of this – maybe ‘end of summer’ but maybe not.

 

pushpin

The Fun of It

So last week I did a write-up about my ISEB6, parts of which ended up making the rounds on various maker / tech blogs. I noticed a lot of people were wondering why someone would bother doing this? Why ‘waste’ so much time, money, energy, and effort making something like this?

The simplest answer is, for the fun of it.

Sure, there’s a level of enjoyment to be had from simply having the finished product, from using it. There’s the utility of it – it was designed to do a thing, and it does that thing. There’s the sense of novelty, that one might get from any new toy, be it a cellphone, computer, tv, or whatever. In this case all that is augmented or magnified by the fact that I built it myself.

When you build something yourself, you have the sense of achievement, in seeing something through from initial concept to final build. You have the knowledge and experience gained, from learning the hows and whys and whats. And you have the pride of knowing that you made something – you set a goal for yourself, and you accomplished it.

And there’s the sheer fun of solving problems and challenges. Physical computing projects like these give you the opportunity (or the challenge) to work with very limited resources. How many functions can you include, how many features can you code, when you are limited to 32kB in which to fit your entire program? And when you have only 2.5kB of RAM in which to execute that code?

Wearable projects add two more dimensions of limitations: Size and Power. How many features / peripherals can you add without making the whole thing too big / heavy / unwieldy? And how much power does everything draw? How long will it run before you need to recharge, or do you need bigger batteries?

I’ve seen a few comments that basically asked, why not just strap a smartphone to your wrist? The simplest answer there is, that’s not what I wanted. That might work for some people, of course. Find something that someone else has built that’s close enough, or good enough, buy it, settle for it.

Why settle though? I live in a world where if you want a specific product to do something the way you want it, if noone else has built exactly what you want, you build it yourself. Build it yourself and you have exactly what you want, the way you want it. And if it ever breaks, you have the know-how to fix it.

(A close runner-up is, buy something that’s mostly there, then hack it to make it perfect. Add those features, fix those functions, and get exactly what you want that way.)

Stuff does break of course. Especially when you’re building and experimenting and learning, all at the same time. Sometimes it’s part of the fun of the challenge, sometimes it’s less fun but you still roll with it. Last week the OLED screen died, I never figured out why but luckily I had a spare so I just replaced it.

Two days ago the Micro-USB port snapped off the LiPo charger. I consider that a component failure since it’s supposed to withstand plugging and unplugging. I didn’t have a spare charger board, so I’ve contacted the manufacturer to ask about a replacement, and in the meantime I did some delicate solder-surgery to enable me to keep using the broken one, for now. (That was less-fun.)

And since that write-up last week, I’ve made a dozen revisions and upgrades to the software, changed / improved some of the leather work, switched out the dull dark hardware for shiney brass, and added brass snap closures to keep it on my wrist instead of the elastic string I had started with. I still plan to redo the top leather layer to make it more attractive.

That’s part of the fun too – projects like these are never really finished. You can go on improving them, enhancing them, upgrading them, until the next big idea comes along.

pushpin

Thermostat Three

This might just be the fastest project I’ve ever done. Saturday morning I started the hardware build, by Saturday evening I had also begun the software. By Sunday afternoon I was halfway through. Sunday evening saw it 90% completed. Monday was finishing touches and adding some extras just because. Tuesday I finished it. This afternoon I installed it.

Some of the things that aren’t obvious in a still photo: The the block above the screen has two RGB LEDs behind it. These aren’t programmable, but one cycles through the colours slowly and the other does so quickly. Together they provide a sort of swirly multi-colour effect that I think is reminiscent of ST:ToS effects.

The red circle ‘red alert light’ is wired to the XBee’s RSSI so when the XBee receives a wireless command, the red light comes on for a few seconds.

The white gridded rectangle is the DHT22 sensor (temperature and humidity). I felt it would ‘blend in’ enough that it should be mounted right up front for all to see. The little black hole to the right of the DHT22 is for the light sensor.

Why is there a light sensor? Why not? Also: because I had an extra one laying around.

The screen display is mostly self-evident. Time, day, date. Heat/Cool. Run/Hold/Override. Target temp (small) and actual temp (large). Fan status (on/auto) and humidity.

The last line is EV (exposure value) and free memory. That’s 657 bytes. Not kB or MB, just bytes. It probably won’t ever change but it’s there just because there was space for it.

The following images have some more build details / information:

The sketch code, and a text file with lots of my design and build notes, can be downloaded here: Thermostat_3.zip

pushpin

MCP Update

It seems like every other day I’ve been tinkering further with my Master Control Project. Since I last blobbed about it, there have been a number of revisions and modifications.

First, I ran into all kinds of crashy problems which I traced back to the String object class. What worked perfectly under the older Arduino IDE no longer worked properly under version 1.0 – specifically it appeared that String objects were gobbling up dynamic memory until there was a stack heap collision and it would sieze up till I rebooted it. Very frustrating.

So the solution was to rip all the Strings out and use fixed char arrays. It only took about an evening to rewrite all that, and the end result was a surprising 5kB savings in the final compiled sketch size.

Along with all that, I made some changes to how tweets were sent, streamlined the content, and cut it back to one status tweet per hour. I’m still having some problems with tweeting – the Arduino Twitter library sends tweets through a 3rd-party host and sometimes that is inaccessable or non-responsive, but I’ve made the tweet function non-blocking so if a tweet does fail it won’t jam up the rest of the works – nor will it hang while waiting for a response from the 3rd-party server.

Hardware wise, I have made some more changes. I moved the Chronodot off of the back of the GLCD and mounted it on the Mega Proto board. It didn’t make sense being on the GLCD since it has nothing to do with that, and being on the Proto board means it’s more self-contained. It also let me use the temperature sensor in the Chronodot to get a feel for the temperature of the MCP’s main Arduino board. Which led to…

The Arduino was running quite hot. It was consistently around 120°F which is almost too hot to touch. This is because it’s got a lot of stuff going on, drawing a fair bit of current. It draws too much to power it from the USB port, so I had a regulated 9vdc supply going into it. That however meant the linear regulator in the Mega was turning the extra 4v into heat, adding to the problem.

So I got a descrete efficient DC-DC converter and wired that to my desk’s dc supply (13vdc for ham radio gear). I modified the Mega so it would accept a regulated 5vdc source without any further adjustments, and that has allowed the board to run cooler – down to about 100°F. (Though the DC-DC converter isn’t exactly calibrated, it’s about 300mV high. Shouldn’t be a problem though.)

Log Tape

The newest hardware upgrade was the addition of an Adafruit Thermal receipt printer. The idea here is to be able to get hard-copy logging of things, and printing out messages. Right now there’s two things that get printed regularily – first, every time it sends a status tweet, it also prints the current radiation level along with a timestamp.

And second, based on the Adafruit Internet of Things Printer, it checks with Twitter and prints out any tweets that are addressed to it or to myself. Twice per hour it accesses the twitter search api then prints out any new tweets. (It is throttled so if there’s a lot of traffic, it won’t go crazy.)

One last software “upgrade” was that the Arduino sketch was getting rather large – it was pushing 2,000 lines, and it was getting harder to find specific lines when working on it. So I broke it apart into separate files, so similar functions and routines are grouped together. Hopefully it will make it easier to read, and easier to debug problems.

If you are interested, you can download the latest project files here:
MCP_V3.zip

The next major upgrade I have in mind is to add a second GLCD – two of them stacked vertically will give me 128×128 pixels of monochrome graphics. I’ll probably retire the character LCD as it won’t be necessary at that point.

Also, maybe some controls, finally. So I can, like, control it, and stuff.

pushpin

Some Pics

pushpin

Two Screens: Still Better Than One

So with all the features and functions I’m adding to my Master Control Panel, one screen just wasn’t enough any more to display all the data it’s collecting.

I’ve used standard character LCD screens before, on my Thermostat and the randomizer, so I figured I could just add one to the MCP as a secondary display. Then I thought, why limit myself to a measly two rows of 16 characters?

The 20×4 screen sounded like a way better idea… I just didn’t realize it was going to be so physically big!

It feels bigger than the primary display. Now I’m all unsure if I like it or not. I want more display resolution, to display more data. I don’t know whether to stick with two displays, or these two displays, or try different displays…

Decisions decisions.

Meanwhile, the radiation sensor is telling me that at the current rate cosmic and gamma rays are passing through my livingroom, I can expect to develop superpowers in approximately never.