Astronomy look-a-likes

Whilst watching the rugby on at the weekend, I was struck by the similarity between the Sussex University Physics and Astronomy department head of school and the ever-smiling English head rugby coach. Are they perhaps related?

PC-SL.png

Advertisements

Word clock; demo video

The following things are not yet done for the Word Clock: 

  1. Case
  2. Real time clock
  3. Human interface

However, I have been able to write the display routines, and a basic loop around the the display. The idea is that the display routine display_time(char hh,char mm) takes two variables, the hour (in hh) and minutes (in mm), and figures out which LEDs to light, and sets an array of globals.  A second routine show_time() pushes the globals out to the shift registers in the right order. show_time() has to be called often, as we are multiplexing the LEDs, but display_time() only needs to be called when the time changes.

As the RTC isn’t yet implemented, looping through the times can then be set to run fast, so that you don’t have to wait 24 hours to test the display logic. 

The video is here: http://youtu.be/iacYOHE3SZk

No audio, because we were watching BSG whilst testing, so I stripped that out.

RTC thoughts

I’ve wired in a DS1305 RTC chip, which has multiple functions. It can operate as a stable 1 second pulse (I’ve wired to a pin on the PIC that allows interrupt on change), it can raise alarms, and it can also, over a serial link, give you a binary string representing the time (including a date if required!). I haven’t decided whether just to use it as a reliable 1 second pulse, and do all the time counting in the PIC code, or to off load all time counting to the DS1305, and just ask it every minute (or so) what the time is, and feed that to the display_time(hh,mm) routine. Current program storage use is only 60% at the moment, so should have room for either. I’ll probably try having the DS do the time keeping and see if it all fits in the code space.

Matrix LED testing

In the drive to be able to control more and more LEDs, there is the matrix format. Here’s a circuit diag from Kingbright that produce bulk devices. The circuit diagram is:

matrix_diag

Here’s a picture of the device

led_matrix

35 LEDs in an 7 by 5 package, and so only 13 pins. And so can be driven (in theory) by 2 shift registers.

For example, if C1 is 5V, and pin 9 is 0V, then current flows through the top left LED and that LED is lit. In fact, if all of the R1 to R7 are 0V, all 7 LEDs are lit. So as long as the R? are high (i.e. 5V) and C? are low (i.e. 0V) everything is off.

So we can control this by driving a particular column high, and then Rx low for the LEDs we want to be lit. Current will then flow and the LEDs lit. And this can then be done for each column in turn. We can take advantage of the fact that human eyes are, in terms of temporal response, rubbish and just light the LEDs as quickly as we can, it’ll look like a static picture.

HC magic

The 74hc595 shift registers have a bit of magic in them. The outputs can be driven high, and we are used to the idea that a driven high output can supply current, i.e. be a current source. Upto 20mA, which as LEDs are fully lit with 5 to 15mA (dependent on colour), is nice. In addition, an output driven low can sink current. No connection to ground required. So an LED can be placed between two outputs; if one end is driven high, and the other low, it’ll light. Any of the other three cases, the LED would not be lit.

History

A couple of years ago, I built a circuit to test this, using a Kingbright matrix, 2 74595s and a PIC. Due to a shortage of DIP scokets, an excess of enthusiasm, and a lack of planning (read: not drawing a circuti diagram before putting together) some mistakes were made. I traced through what was made, and identified the mistakes.

matrix_errors

Major thing to do here was to identify the mistakes. I then fixed up the board, and then it looked like

matrix_fixed

Code

The code is then simple. With the circuit above, the idea is to drive each column high in turn, and set the rows to low for the LEDs that are wanted to be lit, and high the others. I used the same send_byte_to_595 and display_595() routines that I used for the Spoke Pov project, making sure to send the row first, and then the column. i.e.

void display_5x7_matrix(char v1, char v2, char v3, char v4, char v5) {

    send_byte_to_595(v1);
    send_byte_to_595(0x08);
    display_595();

    send_byte_to_595(v2);
    send_byte_to_595(0x10);
    display_595();

    send_byte_to_595(v3);
    send_byte_to_595(0x20);
    display_595();

    send_byte_to_595(v4);
    send_byte_to_595(0x40);
    display_595();

    send_byte_to_595(v5);
    send_byte_to_595(0x80);
    display_595();
}

The main() is just then a repeated set of calls with the right values

 
{
    v1 = 0b00010000;
    v2 = 0b00100100;
    v3 = 0b01000000;
    v4 = 0b00100100;
    v5 = 0b00010000;

    while ( 1==1 ) {
        display_5x7_matrix(~v1, ~v2, ~v3, ~v4, ~v5);
    }
}

Simples.

The pattern is designed by my daughter as a smily face. And it works!

Demo image, along with design requirements from daughter.

Demo image, along with design requirements from daughter.

Interestingly, the different colours are not as obvious to human eyes as to the camera…

Code for this is on github as [to be filled in]

This was all a test. The idea is to push to a larger, homemade, matrix of LEDs for another project. But this circuit allows a little experimention with the “output enable” control pin to change brightnesses (the subject of a forthcoming post) and a general proof of concept of driving a matrix without having to wire up 35 LEDs…

 

 

Bike Spoke Images; final breadboard?

With the interrupts at least demonstrated (https://astrospanner.wordpress.com/2014/02/02/bike-spoke-images-timer-interrupt-woes/), hall effect switching demonstrated (https://astrospanner.wordpress.com/2014/01/24/magnetic-switching-pov/) and LED control demonstrated (https://astrospanner.wordpress.com/2014/01/27/bike-spoke-images-pic-leds/), two things are true:

  1. all the hardware has been demonstrated to work
  2. conceptually, the “hard” bits of the software have been demonstrated to work.

So there are two more steps; a final software build and a final hardware build.

Feel free to listen to this (http://www.youtube.com/watch?v=9jK-NcRmVcw) whilst reading this post.

Final Software Build

The software is structured into three sections: a timer interrupt routine, a hall effect interrupt routine and a main() routine. It’s generally a good idea for interrupt routines to be quick to execute, so that further interrupts are not missed. As such, the display driving has been moved to the main() routine. The three routines communicate via a set of global variables. The global variables are:

Global variable Timer Switch Main
Counter increment read, reset
Change Display Flag Set Set Read & Reset
DisplayCounter Read, Write
DisplayCounterSet Read Set
ToDisplay Increment Reset Read

Flowcharts for the three sections are

main()

main

hall effect switch

switch

timer

timer

And in words, the idea is whenever the magnet passes the Hall Effect switch, the following things happen:

  1. the number of timer ticks since that last happened, divided by the number of radial lines to display is stored (in “DisplayCounterSet”)
  2. DisplayCounter is reset (to DsiplayCounterSet)
  3. The radial line to display is reset to zero
  4. The zero radial line is displayed

The timer is counting down DisplayCounter, and when it reaches zero, the DisplayCounter is reset to DisplayCounterSet and a new line gets displayed.

Because the wheel rotation speed is changing (reasonably) slowly, this scheme uses the last rotation speed to guess where to display each radial line. If we didn’t do this, he orientation of the displayed image would drift, unless the wheel was going at the exactly correct speed (which would also be dependent on battery voltage and temperature).

Final Breadboard

With the code working, this can be implemented on a breadboard. It’s the same breadboard as used before, just with the addition of the magnetic switch onto pin 4 of the PIC. (Pin 4 is the input only pin of the PIC12f675 so it makes sense to use it as the only input.) For aliveness testing I also added an LED driven by pin 3 and an additional line into the Hall Effect routine to toggle the GPIO so I could check that a) the PIC was doing something and b) all magnet passes were identified.

And it works!

Video here: http://www.youtube.com/watch?v=nfqQzUZzInU

You can see in the video that there is a fast pattern for the first 3 seconds, and then I pass a magnet near the Hall Effect sensor (which is on the bottom right of the board). The pattern then repeats after the next pass at 7 seconds. The pattern certainly repeats.

The pattern is hardcoded to 64 lines. It intends to say “CYCLING ROCKS”. The font is hand designed to fit into the 64 lines to be 8×4 sets, to look like this:

Excel produced image

Excel produced of message

The circuit board (as seen in the video) was actually built a couple of years ago for a 16 pin PIC. Fortunately, the power connections for different PICs are presumably deliberately pin 1 and the last numbered pin, so a 8 pin PIC can be put into the same socket. After wrapping with some duct tape, I then mounted on the front of wheel of my daughter’s bike. (Smallest bike to get into the kitchen work area).

Breadboard on the bike

Breadboard on the bike

The magnet was duct-taped to the fork, and with the lights off, can be tested properly, as can be seen below:

running

This was stable for different rotation speeds. So apart from senses of letters, this can probably be declared a success!

Next steps are to try this on a bike that we can actually cycle along to see what it looks like to a random passersby before going for a full up 24 LED version. (Still slightly worried about fitting all the data into the PIC…)

Bike Spoke Images: Code release

As intended, I’ve setup a github account and repository. The clone url is: https://github.com/astrospanner/pov_project.git

All the code used for the demos so far is on there. Because it was setup after I wrote and debugged most of the code, there’s little history that you would normally associate with a proper version control system.

From now, this is now the public facing repository for all project work that this blog will document.

It’s worth pointing out that I’m using TortiseGit (https://code.google.com/p/tortoisegit/) as a Windows 7 shell extension to help with the commits and pushing. The Dancing Monkeys blog had an excellent easy to follow instruction blog post that I followed to get everything setup. Linky: http://dancingmonkeysaccelerated.blogspot.co.uk/2012/03/git-for-windows-with-tortoisegit-and.html

Enjoy the code! If you think it can be improved; comment, or send me a patch!

Licensing…

I’m going to release the code for the Bike Spoke images. But which license should I use? http://choosealicense.com/ gives a handy guide, and I quickly decided on the MIT License. (http://choosealicense.com/licenses/mit/)

Why? That’s a question with two levels.

Firstly, I want to distribute the code so that others can learn from it, use it, and tweak it to add things to adapt it to their use cases. (For example, running with less LEDs, or changing the image, or, even, providing a memory card containing the image on the fly…) An open source license allows this.

Secondly, I want some attribution (or as some might say, blame) for my code. But if it blows up your toaster or makes your cat sick on the rug (it won’t), I don’t want to be liable. If someone invents a wizzy method for something that builds on my code, and manages to license/sell it, great for them. This means further use of my code, which goes back to the original reason for building stuff; to make something that might outlast you.

The MIT license fits with these goals, and is not an enormous long legalistic document that no-one will read (c.f. GPL v2 or v3). So my default license will be the MIT license. And I see this work plastered all over a youtube video as a how-to (with attribution) I will be happy.