MCP Update

Posted 2012.03.18 14.35 in Computers/Internet/Technology

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.

4 Comments

  1. ygreq says:

    Hi Stephanie,

    Great project! I am trying to build something similar. I want to monitor and automate my house using arduino. Now I am stuck at monitoring using cosm and more precisely at using arrays, strings. Your project might help alot
    I wanted to ask you if there is a specific order of the sketches that make up your MCP.

    By the way, I might be wrong but I think you left some private twitter account data in your Constants.ino sketch.

    1. Stephanie says:

      Hello ygreq, thanks for writing!

      There is a ‘sort of’ specific order to the sketches – Arduino compiles the collective sketches in alphabetical order, by just concatinating all the INO files one after the other.

      So the ‘constants’ file for example, could not be named ‘globals’ because that would mean it would come behind ‘displays’ and ‘functions’. So then the compile would fail because none of the variables had been assigned or initialized before being used.

      The other thing (which I think they fixed in 1.0.1) was that it didn’t seem to automatically create function prototypes correctly, so if sketch ABC.ino called a function in sketch XYZ.ino the compiler would fail because abc was compiled before xyz was encountered. So I put some, but not all, of my function prototypes into the constants file to keep them at the front.

      I say I think that was fixed as the ISEB-6 sketch did not have that problem, and it was created in the 1.0.1 version of the IDE.

      Good luck & have fun!

      And – thank you for pointing out the twitter info I had left in there. I’ve removed it now. :)

  2. ygreq says:

    I still don’t get something. Were the sketches separated automatically by the arduino IDE or did you do this manually? And to put them back together, I just copy-paste them manually in alphabetical order or is there a function in the IDE to do that?

    Related to the twitter info, I would recommend you changing that info in your twitter account, not just remove it from the sketch. Some people already have that info.

    Thank you for taking your time.

    1. Stephanie says:

      I separated them manually, to make it easier for me to read and work with. It had got to the point with over 2000 lines in one file, trying to add something or work on something became a bit annoying; this way I have smaller files to look at, organized by their general type. Eg. if I want to fix or tweak something in the serial report output, that’s in the reports file.

      If you want to reassemble them all into a single file it doesn’t really matter what order they are in, other than putting the constants / globals at the top.

      It probably comes down to personal preference, but I’ve seen some people who put setup and loop at the top then all their functions below that; I do it the other way, setup and loop at the bottom and all my functions at the top.

      Either way, if everything is in one single sketch then the build process works without any hang-ups re. generating the function prototypes et cetera.

      Thanks for the reminder re. the twitter key, I’ll update that.

Leave a Comment