Latest Entries »

Analog RAM and CPU Meters: Update

So I finally found time to fiddle with the CPU and RAM meters again today. Between Uni assignments and The Witcher 2, I haven’t really had much time for hacking, but after finishing The Witcher 2, I had to do something to procrastinate.

So I sat down and wrote a little Python script to grab the current CPU load and RAM usage. To do this, a module needed to be imported into the script. WMI. Windows management instrumentation. Other given modules are also needed. For example, serial and time. So we can actually TALK to the Arduino. You know, I hear that’s handy for what I’m doing…


As you can see, I’m sending the data as a string of characters, with a begin and end byte.

So, I’ve got the data, and I’m pushing it to the Arduino, now all I need to do is get the Arduino to do something with it! Remember those bytes I put in between the data bytes? Yep. Let’s use those to tell the micro controller what data packet is going to which display.
Basically, on Serial.available > 0, we check the byte, if it’s the byte that precedes the CPU byte, we set a flag as 1, if it’s the byte that precedes the RAM byte, we set the flag as 0, if it’s the byte at the end of the stream, do nothing, we don’t need that data. Ultimately I could remove it, but I like having the option for letting the micro controller know that the transmission is finished, but I digress. With any other byte, we check the flag and output the value to the corresponding meter. Simple.

Arduino Source

I originally tried to be all fancy like and send it in 2 data packets with the Most significant nibble of each byte in the first packet, then the least significant byte as the second packet. Basically multiplexing the data. For no real reason but to try and implement something I had learnt in my communications theory class. Well, as you can see, that fell through. The Python script managed to encode and send the data, but for the life of me I couldn’t get the Arduino to decode the data. I’ll probably keep fiddling, but for now, it’s working.


The left meter is RAM and the right is CPU. You can also see where I’m working on the SD card interface.
The CPU output is quite jumpy because the CPU load is changing all the time, I’m working on some action smoothing methods that I can implement on the Arduino, just something else I need to work on.

The final product plan is a mounted set of monitors with LED backlighting and a custom back planes. As you can see, I’m not really measuring mA, so I was planning on scanning in the current back planes and photoshooping some new ones that suit my project, just to give it that finished look.

Yeah I know, I’m avoiding the SD interface. I’m a little daunted by it honestly. But to be fair, I’m avoiding a lot of things, aka, uni work. So on that note, I leave you. Enjoy this quick update!


Next project time!

This one is rather simple and easy, just to introduce me to the arduino and its capabilites. A couple of analog panel meters to show realtime cpu and ram usage, then have the data logged onto an SD card.

I’ve got the panel meters and have tested them. How they are gonna work is a simple PWM signal with the duty cycle adjusted to current load sent from the computer via serial port. The panel meters I have chosen are 0->1mA. So some calibration circuitry is needed so i can adjust the voltage and get a linear approximation of the data from the cpu. Now, this is rather simple.
What we want is 1mA of current being drawn when the PWM is driven to 100% duty cycle, and 0 mA when the PWM duty cycle is 0%. So, back to basics. Remember V=IR? I surely do. Bit of gypsy magic and we get R = V/I. Lets just assume the panel meter has no resistance, when it actually does, and calculate a “Perfect” resistance needed to get out 1mA.

R = 5v/1*10^-3
= 5kohms.

Tweasy. All we have to do is add a 5kOhm resistor in series between the PWM pin of the arduino and the panel meter. If you want to check that the response is linear as the voltage varies, compute I = V/R for several points and plot. You will notice it is a linear relationship*. Just what we want.

Plug it into the arduino, and you will find that it works! Fancy! Maths is again useful! <- Much to my dismay…

Nexzt, I’m gonna be working on the data logging to SD card. Now this would be MUCH more useful if I could find a particular library called uFat2 made by SirMorris. But alas, his code host no longer has it and I cannot find links to it anywhere else, So if any readers out there have it or can find it, let me know! Please!

Peace out.

*Technically, Ohms law is not a linear realtionship, as temperature varies, the line becomes less and less linear. For most applications though, we can ignore that…

Bluetooth Media Remote

It is finally finished. My Bluetooth Media Remote!

With each module* working as it should, I set out to build it onto my breadboard. Just to make sure that it works together.

*See previous posts for each module and how they work.

The final Micro-controller I decided to use on the final product was a ATMEGA8. In the first post I used an ATMEGA8515. For several reasons I decided not to use this one in the final product. Firstly, it’s a 40 pin package. I do not need that many I/O lines. It draws more power. And finally, I need that one for my studies at uni. So an ATMEGA8 was used.

Here, I noticed a slight problem…
The buttons double press sometimes. Thus sending the data twice. I think this is a limitation of the tactile switches I am using. I’m not quite sure. Later on I might write some code to only allow the data to transmit after a certain amount of time has passed using a timer interrupt on the ATMEGA8. This is for future work though.

From here, I built it on a set of prototype boards. Modular of course. In hind sight this wasn’t a very good idea, because I still hadn’t decided what I was going to enclose it in, but I was excited to build it. And build it I did.

Ahh. Its working on the prototype boards..

Now, the problem that faces every hacker, what to build it in? It’s gotta be classy, something on hand, and easy to put together.

Thanks to a brilliant idea from my mate, Damo, I thought “Why not in one of my broken Xbox controllers?”

After pulling it apart and trying to jiggle the circuits into it, I decided it just wasn’t feasible.

Back to square one.

Then, like a ray of sunshine, I remember I had a broken N64 controller as well. Thus the decision was made. It’s classy, it’s on hand. Easy of assembly went out the window when I realised how awesome it would be to use nostalgia to control my music.

After rebuilding the circuits onto new prototype boards (about the 5th time I had built the same circuit), I attacked the controller with a jigsaw blade and the file on my pocket knife. Not the best tools, but what I had on hand.
And so the N64 Media Remote was born…

And a video just to prove it works…

For those interested. The source code for the remote. The polling of the buttons is not quite neat, but it works.

I might implement an external interrupt to activate the polling, but at the moment, it’s not needed. Even the interrupt polling double transmits.

And thus the project is complete. Any questions, don’t hesitate to ask!

Later on I might get a full circuit diagram. If someone requests it I’ll make it a priority, but until then it’s on the back burner. Uni work has suffered enough…

Onto my next project! A set of analogue panel meters to monitor my CPU and RAM usage with data logged to an SD card. Stay tuned!

EDIT: Debounced the buttons. Thanks for the idea Matthew Wiebe and BohemianHacks! Here’s the updated source code

If you are a faithful reader, you might remember way back to my first post, my server. Now. That server was based on VB 6.0 and, honestly, a really really bad piece of code. So. I decided to completely re-write it in Python script.
Handy little thing python. Cross platform, easy flow control. The moment I got that server working, I knew that this was the way to do it.
To gain serial port control and the ability to import Media Monkey I had to install a couple of other libraries. Pyserial and pywin32.

Source code.

It basically waits for a connection on a specific port. Once it has gotten it, it will poll the serial port for new data and check if the current playing song has changed. When it receives data, it will act correspondingly.
As you can see I have set an escape case, the character “e”. This allows the server to close the connection and wait for a new connection. This allows us to shut down the remote without having the server still listening on the port. If the remote is turned off and then on again without sending the escape character, the remote will not reconnect to the server because the serial port is already open.

All in all, a handy little script that can be modified for any serial comms and Windows interaction.

Next, the final product! Excited? I am.

Well. Here is quite an important part, yes? What’s the point of having a remote that is powered by a wall socket? Not much, really. And, unless you haven’t noticed, there are no 5V batteries available, not on the cheap at any rate. Which really is quite annoying. So. Let’s use a voltage regulator. The following circuit is a 9V to 5V regulator using a 7805 regulator transistor.

This gives us a nice, regulated, smooth output. Very handy. And a pretty LED to boot!

This power supply can be used for any application needing 5V, so as a result, I will be using this circuit pretty much all the time, apart from prototyping on my dev boards.

Next up, the server code I re wrote in Python.

This module is rather simple. Just a simple method of connecting a bank of buttons to an AVR and checking the results using polling. You have already seen the code for polling, that was in module #1.

The theory is rather simple. We drive the input lines at 5V when off and send it to zero when on. This is known as ACTIVE LOW, because the line will be active, when the voltage is low.

The diagram is as follows.

Simple no?

When the button is not pressed, the 5V is fed into the AVR. But when the button is pressed, we are driving the line down to ground. Hence sending the AVR line to 0V.

Next module. The power supply.

On to the next module. I had been thinking for a few weeks, what kind of wireless will I use for my remote. Some options include:

  • Xbee modules with a base station connected to computer.
  • One way transmitter connected to base station and a one way receiver connected to remote.
  • Direct Bluetooth connection.

Now, each has its pros and cons.

The Xbee modules are frikken expensive. Add onto that the price of building a base station with another Micro-controller and USART->serial converters. On the up side, I would have AMAZING range for my remote.

The one way transmitters and receivers are cheap. Really cheap. Again though, I would have to build a base station with a USART->serial converters. Also, I cannot guarantee the range or effectiveness of the cheap wireless modules.

The Bluetooth modules can be found cheaply, easy to use and have no need for a base station. The range though, can be rather small, depending on the module chosen.

Taking all this into account, I chose the Bluetooth solution. I found a nice cheap Bluetooth device on eBay, based on the CSR (Cambridge Silicon Radio) chip. It all came on a breakout board for me too! Nice and easy to incorporate into the micro-controller using a USART connection. This also means I don’t need to modify any of my code from Module #1! How good’s that?

It works!
Now pair it with the computer and create a virtual COM port! For those who get the same device, take note that the PIN for these devices is 1234.

If you noticed, it’s name is “WIDE_HK”. What a boring name. This is the name of the people who made the breakout board. Now, I want  to change this. So we need to do some AT commands. TO do this, we need to connect the Bluetooth to the computer via the serial port. Take note, this is NOT via the Bluetooth wireless protocol, but through a USART->Serial converter and into the data lines on the Bluetooth chip. We also need to drive a line on the board high. This line is Pin 11, some soldering to tack a new line on at that point of the chip is required. Drive that to 5V, power it up and connect to it using putty with a baud rate of 38400. Here, we type in the AT commands. For a full list of AT commands, check the data sheet, but to change the name use this one.


This should return “OK”. And you are set!

Turn off the Bluetooth module, disconnect the line on pin 11. There we go! All ready to use!

Thanks to Hack a Day, specifically this post, I discovered a good way to extend the range of my Bluetooth device! Tack an old router antenna onto the aerial onto it! It’s the same frequency, 2.4GHz, so it is the right length for a proper antenna. Using this I get range of maybe 10m through walls. Without it I was lucky to get 2-3m. Thus the disadvantages of buying cheap modules and a cheap Bluetooth dongle for my computer.

Next module is the button switch bank.

Wireless Remote Module #2: LCD Display

Ahh, it’s been too long since I’ve updated this. As you can guess from the title, module #2 for my wireless media remote is complete. Well, module #3 is ready too, but I’ll put that in another post later on. (Don’t tell anyone, but so is module #4. I’m actually up to building it on prototype boards as opposed to my bread board)

A few weeks ago, I went down to Jaycar and picked up a few things. One of them being a 16×2 LCD character display. Key code QP-5512.
As it turns out, this particular LCD character display from Jaycar, has no datasheet. Which is quite in convenient for anyone, especially someone just learning about micro-controllers. After many hours of research, I found this: Oz electronic forums where several board members figured out its wiring and instruction sets. For the PICAXE.
Now this is wonderful…Except its code is in PICAXE Assembly syntax.

First things first, let’s wire up the circuit. I opted for 460 ohm current limiting resistors because that’s just what I had with me.

D0 -> D3 are the data lines. Because i opted to use the LCD in 4 bit mode, we only need 4 of the data lines for data transmission. EN is the enable line and RS is register select. The 10k trim pot on line 3 is contrast adjustment.

Onto the code. Once again, I would like to point out that this isn’t exactly all my code. The structure and implementation of it in C is, but the enabling and writing to the LCD logic is thanks to SABorn at ozeleforum (See above link).


Compile it, upload it and run it. Works a charm eh?

Note it is displaying the current playing song from my PC. See the serial connection? I’m tying them slowly together… More on this in later posts though.

I have actually found that on the enable pulses, you can decrease the delay to 35 us. This may cause some slight unstable reactions, but I have never had a problem with it. Just don’t go any faster.

Now, I liked this so much, I decided to put my screen on a prototype board.

So that’s pretty much it for now. Chew on that while I get bothered to write up more on the next few modules.

Here is the instruction set for the LCD screen:
DisplayOff = 8
DisplayOn = 12
Home = 2
Clear = 1
Start of line 1 = 128
End of line 1 = 145
Start of line 2 = 192
End of line 2 = 209
Master reset = 0
Scroll screen left to right = 5
Scroll screen right ot left = 7
Screen off = 4
Display top line only = 32
Display both lines = 44
Cursor on = 14
Cursor off = 12
Cursor Blink = 15

Thanks to SABorn @ Oz Electronic Forum.

Why I Think Earth Hour Is Bullshit

Ok, well, that’s a half truth. It is a fantastic tool for raising awareness of our power consumption, the act of turning our electrical devices off for an hour and then back on again is, well, stupid. In most cases, it takes less power to keep an electrical device on for an hour than to turn it off and on.

Let’s look at the theory a little bit. Apologies, this will get real technical, real fast.

We have 2 energy storage components in our electrical circuits. No, I’m not talking about batteries, I’m talking about capacitors and inductors.

Capacitors, through use of parallel, electrically charged plates, store “Voltage” (The mere concept of “storing” voltage is silly, but to keep things a little simple, let’s assume we can).
Your thinking, “Ok Phill, that’s cool, how does that mean it’s bad?”
I’m glad you asked faithful reader.
Think, at initial conditions, t = 0, before we turn on the circuit, it contains NO charge. It’s just chillin’ there. We throw the switch, suddenly the capacitor starts to charge. The voltage across it increases at an exponential rate. At V = E(1 – e^(-t /τ)), where E is the source voltage, t is time and τ is the time constant of the given circuit (τ = RC). The capacitor will reach full charge after 5 time constants, so depending on how complex the circuit is, it will take longer to charge.

Ok, now to the other side of the coin, capacitors also draw current! Yes! But ONLY when they are charging. Now this is at a rate of I = (E/R)e^(-t/τ) , where R is the circuit resistance and again t is time and τ is the time constant.

Right. Now, Power. What everyone is going on about with “Earth Hour”. Power of a circuit is defined as P = VI. Voltage times Current. So, looking back at our capacitors, we have a device that will draw a large amount of current starting out, then drops down, and the voltage starts out small and moves up. You think “That’s ok, they will cancel each other out”. Nope.
Voltage of the ENTIRE circuit. You will have other components drawing current and requiring voltage. So the voltage of the circuit, with a suddenly applied voltage source, will still be larger than the voltage of the capacitor. Therefore, at t = 0+ (Just after we turn on the circuit), we have a large current draw with the same voltage, resulting in a large power draw, via the relation of P = VI.

Inductors are essentially the same, except they “store” current. So the current flow through them drops exponentially and the voltage rises exponentially. So the same problem applies with the P = VI.

Now that’s out of the way, how does this effect anything?
Well. The basic structure of an AC-DC power supply is a Bridge rectifier (1.4V drop at all times), Transformer (A really big inductor, yeah, it has inductance) and a set of Capacitors. You turn on, say, your phone charger. To you, it works instantly, to the device, it has a “start up time”. The capacitors in the circuit need to reach their charged state, the transformer needs to warm up. All this takes more power than required to maintain its state of equilibrium.
This power supply structure is in almost EVERY device you plug into the wall. AC is easier to transport, but DC is much more useful in everyday applications.

Well. That’s power supplies out of the way, let’s look at lights.
Those “Power saving” fluorescent globes you buy? Yeah, the ones that take age to start up…
They require an extremely large voltage to turn on. They’ve got little “Starters” in them that convert large current flow into a large voltage spark to turn them on. Now, P = VI. Large current OR voltage flow means…Large power draw. Once they have reached their state of equilibrium (after 3 mins i might add) then they settle down. They still draw a very distorted current, which, trust me, is bad. You aren’t paying for the distorted part, but the power companies still need to generate it and pay for that. But we’ll get back to the power companies later.

“But Phill, I don’t like them, so I have plain old Incandescent globes”. Well done, I salute you. I hate the power savers. That’s more personal opinion though. You’re still not off the hook. The Incandescent globes are made by making tiny coils of tungsten, and hence, making a small inductor. Again, P = VI, la di da. Drawing large power at start up. There is also another thing to keep in mind. As temperature increases, so does resistance. Now those globes get mighty hot don’t they? Well what about when they have been turned off for a while? They are cold. Therefore, resistance is lower, therefore, a higher current draw (Based on fundamental law of electronics, Ohms Law, V = IR. Or as we are using it here, I = V/R ). The element heats up, resistance gets higher, less power draw.

Well. That’s the maths behind the circuitry done, let’s look at the economic side, yeah?

Power distribution is done by 3 different companies, or branches. There is the company that generates the power, the company that distributes the power, and the company that provides it to you.

The providers buy the rights off the distributers, who buy their power from the generators. Now, this happens on the hour, every hour. The distributers have to guess what the next hours power draw is going to be, and buy that much power off the generators, who will take power generation plants up and down to meet the demands of the suppliers.
So, if we have a massive dip of power draw, the generators will lose money, the distributers will lose money, and the suppliers will lose money. NOT just from you not using power, but because

  • To shut down the generators, for even an hour cost a fortune. But they can’t leave them running because no one is buying the power.
  • To turn the generators back on, there is again, inductors and capacitors, in the systems. Now, generators are HUGE inductors. How much current do you think it takes to get it up and running again?
  • Power factor correction.

“Power factor correction? What’s that?” That my friends, is the bane of power generators and distributors around the world. When you plug something that has an inductor or capacitor in it into your wall socket, it will draw both real current, and an Imaginary (Complex) component. You, as a consumer, only pay for the real power you draw, but the distribution company has to buy real AND imaginary current from the generators. To combat this, for every capacitor and inductor you plug in, they plug the opposite in. This evens it out to mostly real power draw. That is power factor correction. Now imagine turning everything off suddenly. Suddenly the distribution and generation companies are drawing FAR too much imaginary power. Power that still needed to be generated. Power that you are trying to save by turning everything off. So they correct this buy unplugging all their capacitor banks so it’s just back to real power.
Then you turn everything back on. Suddenly they are drawing the large imaginary power again. Again, they still have to generate that power. So they have to plug all their capacitor banks back in. Massive energy  and money loss for the major companies. Who do you think they will pass these “Savings” on to?

Well, I’ve defiantly rambled on for FAR too long. Suffice to say, during Earth Hour, I’m not turning ANYTHING off. I won’t be turning anything on either. Got to maintain the Equilibrium.

Nothing amazing here really. This kinda stuff you can do from numerous walk throughs on the interwebs.

The AtMega8515L was the chip used connected to a STK dev board. If you want to use just the chip on your own bread board, you will need a MAX232 chip to convert the TTL logic levels to the +30V required for serial data transmission. Thankfully the STK does this for me while I wait for my MAX232 chips to arrive.

PORTD pins 0 and 1 are the USART data transmission lines that need to be connected to the MAX and then through to the Serial connector.
Next I used PORTA for input into my micro controller. Utilising the onboard switches from the STK. It should be noted that the switches are active-low. Refer to the STK500 user manual for the wiring diagram to set it up switches on a separate breadboard.

Once all this is wired up, it’s time for some maths! 😀

Here, we need to calculate the UBRRL register that corresponds to our “Baud” rate of our serial communications. This is basically the bits per second that the data will be transmitted.


Lets  pick an arbitrary baud rate. Say, 9600 b/s. Good number, commonly used in serial communications. Makes things easier to do when it’s the standard.
Right, using a formula in the AtMega8515L user manual we get:

UBRRL = (f_osc)/(16*baud) – 1

See? It’s simple really. f_osc is the frequency that our chip is running. So in my case, 3.6864 MHz.
We throw all this in together and what do we get? 23!

Oh, if your lazy, there is a table of common baud rates, clock freqs and UBRRL values on page 160… But knowing that formula makes you seem that much smarter…

Right, We’ve done the maths, done the hardware, let’s do the code!
First, let’s get the AtMega8515L sending data.

Fire up AVR Studio and make a AVRGCC project. In this case I decided to steer clear from assembly just because I can do conditional things easier in C.

ok, source code!


The USART initialisation and transmit functions are supplied from the AtMega8515L user manual, I take no credit for either of these two functions.
As you can see I’m setting the USART active with the baud setting of “23” (remember calculating that?) and initialising it. Then in an infinite loop (Sorry, no interrupts yet) I grab input from PORTA and compare it to masks set up. Then transmits an ASCII code to the Serial interface. The “trans” if/else statement is to ensure the data is only sent once, at the initial key stroke. Just makes receiving the data a bit easier.

Ok. Flash the program into your board! Hook it up to your PC using a serial cable, or in my case a serial to USB adapter, and turn it on!

Remember, its not going to do anything yet! Nothing on the computer is waiting for input.
At this point, download and install “hyperterminal“. Just use the free 30 day trial for now, if you use it more and more, why not grab it for real, yo? Or if you want the free open source option (My choice) use “Putty“.

Ok, install, open, create a connection to your comport. Mine was comm3, but yours may be different. The set up is 9600 baud, no parity bit, 8 bytes of data and stop bit is 2. Hit connect.

Now, this is the fun bit, press a button and see if the corresponding ASCII code turns up on the screen. If so, Well done! If not, Get your troubleshooting hat on and go for it. 🙂 I’m not gonna do everything for ya.

Right, The micro controller is talking to the PC, Now, lets make the PC do something with the commands!

For this, I chose to use Visual Basic 6.0. Out dated, yes, but a simple language that easily allows comport data retrieval. Also, I’m using it to control my music. Now I use a slightly obscure media player called MediaMonkey. I highly recommend it, but that’s a different conversation entirely. MediaMonkey has an importable object that allows VB programs to control it and get data from it, handy actually.

Ok, Create a new .EXE. Import the MSCOMM object, add to the form a MSCOMM object and a timer. Set timer interval to, say, 100. Enter in the code given below.


As you can see, I’m using a timer to ask the MSCOMM object if something is new. I tried it on the data receive event, but for some reason all I got was garbage. I’m gonna look into that a lot more in the coming days…

Right, Simple eh?

Works? Music changes? (For Media Monkey Users it should). Add your own commands! Play around.

Next on the cards is a wireless media remote that displays the current playing song via a 2×16 LCD display. This one’s gonna take me a while…
I’ll keep you posted!

Have Fun.

UPDATE: Fixed up some code, added more comments to code.