Propellor clock - too ambitious? (latched outputs)

Discussion in 'The Projects Forum' started by coldpenguin, Jun 8, 2010.

  1. coldpenguin

    Thread Starter Active Member

    Apr 18, 2010
    165
    9
    I couldn't see any posts about a propellor clock, I was suprised.
    I am trying to work out whether my idea here is too amitious to ever work.
    I am considering using a PIC18F4* processor as a controller for a propellor clock, running with a 48MHz oscillator.

    The clock would be two arms (dipole), with 8 RGB LEDs on each arm, slightly offset, so after a half revolution, the other 8 LEDs would fit between the first half (i.e. interlaced)

    So:
    Arm A: Pivot O Arm B:
    A0 - A1 - A2 - A3 - A4 - A5 - A6 - A7 - O B7 - B6 - B5 - B4 - B3 - B2 - B1 - B0 -

    Which would become:
    A0 B0 A1 B1 A2 B2 A3 B3 A4 B4 A5 B5 A6 B6 A7 B7 O (mirror)

    This I think would help with the placement.
    The LEDs I am looking at are common Cathode RGB, so I would have to bring each Anode high in order to make a light.
    I was thinking that I could use an 74HC374N for this. Not used one before, but as I understand it, you can apply a ground or voltage to the 'data' pins, set the Output Enable to ground, and strobe the clock signal, and it should latch (flip-flop) the outputs and keep them stable.

    So my thought is, I attach 3 of these to port B, and 3 to port D of the 18f4* PIC (ports B and D are full 8 bit ports, but, don't do anything that 'special' [I am considering a wireless uart attached to C6/C7, if everything works out well] and ports A and E are only 5 / 3 bits).
    I attach the output enable to each of these 74HC chips to ground, and then the following would happen:

    while(1){
    determine_position(); // based upon how many cycles have passed since last position counter.

    portB=<bitmask-R>;
    portD=<bitmask-R>;
    strobe_clock_R(); //port E0 up, then down, should lock in portB and portD into the relevant 74HCs
    portB=<bitmask-B>;
    portD=<bitmask-B>;
    strobe_clock_B(); //port E1 up, then down, should lock in port B and D into the relevant 74HCs, the others should ignore this?
    portB=<bitmask-G>;
    portD=<bitmask-G>;
    strobe_clock_G(); //port E2 up, then down, should lock in port B and D

    Is this going to work? Am I being too ambitious would the system move on too much before it manages to lock in all 3 colours?
    Have I completely misunderstood how these flip-flops should work?

    I have attached a schematic, ish, I stopped drawing because it was getting too busy, I think there is enough to get the idea though.
     
  2. Darren Holdstock

    Active Member

    Feb 10, 2009
    262
    11
    Go for it. Some years ago some Dutch colleagues at Philips built a fellow colleague one of these as a present, and it was rather neat. I see nothing wrong with your basic concept coldpenguin, but I haven't checked the detail of your design either, that's your job. If you get it wrong, you'll learn a lot from the troubleshooting to put it right.

    Unless your compiler is horribly inefficient I wouldn't expect issues with the firmware being too slow. Persistence of vision means you can get away with quite slow propeller speeds; besides, you don't want the thing to actually take off.

    Another variant of this concept is the pendulum clock, which trades off simpler LED connections (no need for slip rings) against a LED velocity that is sinusoidal rather than constant.
     
  3. SgtWookie

    Expert

    Jul 17, 2007
    22,182
    1,728
    I think rather than use so many 374's, I'd multiplex the common LED cathodes using a couple of pins from your as-yet-unused ports. Just use a transistor like a PN/2N2222 with a 270 Ohm resistor from base to the I/O pin. That'll give you 15.5mA base current, good enough to sink 160mA or a bit more.

    That'll let you multiplex your anode output pins, too. It'll save you a lot of wiring and space.
     
  4. R!f@@

    AAC Fanatic!

    Apr 2, 2009
    8,754
    760
    Just wondering Sgt, do you know propeller uC by any chance
     
  5. SgtWookie

    Expert

    Jul 17, 2007
    22,182
    1,728
    I know of Parallax Inc's Propeller uC's. I think they use Java for a programming language. However, I only glanced through the specs a few years ago, so don't remember any more particulars on them.
     
  6. SgtWookie

    Expert

    Jul 17, 2007
    22,182
    1,728
    Back to coldpenguin's idea,
    Have a look at the attached schematic to see what I was talking about.

    I've used 9-pin SIP (single inline pin) resistor networks on the common cathodes instead of individual resistors. This means you could only display one color at a time, which might be OK for your purposes. If you wanted to have more than one color at a time on, you'd need to go back to using resistors on the individual anodes; but even then you will likely run into total package current source limitation problems.

    My assignment of the ports was admittedly rather arbitrary. You're going to need a method to synchronize the PIC timing with the rotation of the "propeller". One way you might do that is to use a stepper motor.
     
  7. coldpenguin

    Thread Starter Active Member

    Apr 18, 2010
    165
    9
    Thanks for the schematic Sgt. Wookie
    I was thinking that should it go well, that I could use multiple colours at the same time, and if it went really well, that I could even try PWM.
    This last part is what puts me off your design. But, there could be a reason why this is used in almost all schematics that I have seen (and I haven't seen latches used in any).
    Also, I am not sure that your design reduces the current through the microcontroller does it?

    However, I really do like the idea of the resistor arrays, and it would certainly cut down the number of components I need. Yours requires ~40 wires/tracks. Mine requires ~108 by my counting :(
    It is soooo much simpler.

    Implementing though...
    As far as I see it, to implement with your design, each 'cycle' would have to be:

    enter:
    set D0 off
    set D1 off //All LEDs are off for duration of cycle setup
    set A<N>
    set B<N>
    set C<N>
    set D0 on //only 50% of LEDs are on
    /half-tick
    set D0 off
    set D1 off //not required // however, all LEDs are off
    set A<N>
    set B<N>
    set C<N>
    set D1 on // only 50% of LEDs are on
    /half tick
    set D1 off
    :loop

    So best off, this is 50% duty? Or have I got this wrong. Without turning D0/D1 off there is going to be ghosting/doubling of the image. So, if I wanted a dot matrix style of display, yours would be suitable. So long as I have an odd number of dots (every half tick would be a dot, each half-cycle/circle would need to align at the edges.

    My understanding, was to some extent a flip-flop/latch was effectively also 8 transistor outputs? So the total current going through the microcontroller should be reduced by using these (correctly), so long as the flip-flop chip can handle powering 8 LEDs. My thoughts were that by using the latches, instead of the usual 'dots' you would get from standard multiplexing, that the granularity could be much finer. Possibly to the extent that a 50% cycle could be so fine that it would barely be see-able?
     
  8. SgtWookie

    Expert

    Jul 17, 2007
    22,182
    1,728
    Not with the design I posted.

    The thing is, how big do you want this propeller to be? If you keep the circuit relatively small and uncomplicated, you can support the whole thing by the motor's shaft, and the motor and board with LEDs all spin together; you only require two slip rings. The more stuff the board has on it, the more complex your balancing of the prop will be.

    The values for the resistor network I gave were just very rough. You'd really want to limit the current through any LED to around 10mA for long life; super-bright LEDs will appear pretty bright anyway. The red will have a lower Vf than the green or the blue, so the red will always appear brightest.

    It does by virtue of the resistor network. However, if you have more than one LED on, red would get more current than green or blue, and green would get more current than blue. I suppose you could work out some fancy PWM scheme, but you won't have a lot of time unless the prop is rotating pretty slowly.

    That's the idea. K.I.S.S. rules. ;)

    Implementing though...
    As far as I see it, to implement with your design, each 'cycle' would have to be:

    enter:
    set D0 off
    set D1 off //All LEDs are off for duration of cycle setup
    set A<N>
    set B<N>
    set C<N>
    set D0 on //only 50% of LEDs are on
    /half-tick
    set D0 off
    set D1 off //not required // however, all LEDs are off
    set A<N>
    set B<N>
    set C<N>
    set D1 on // only 50% of LEDs are on
    /half tick
    set D1 off
    :loop

    So best off, this is 50% duty? Or have I got this wrong. Without turning D0/D1 off there is going to be ghosting/doubling of the image. So, if I wanted a dot matrix style of display, yours would be suitable. So long as I have an odd number of dots (every half tick would be a dot, each half-cycle/circle would need to align at the edges.

    My understanding, was to some extent a flip-flop/latch was effectively also 8 transistor outputs? So the total current going through the microcontroller should be reduced by using these (correctly), so long as the flip-flop chip can handle powering 8 LEDs. My thoughts were that by using the latches, instead of the usual 'dots' you would get from standard multiplexing, that the granularity could be much finer. Possibly to the extent that a 50% cycle could be so fine that it would barely be see-able?[/QUOTE]
    I suppose you could use latches if you wanted to. It'll certainly complicate the design. Note that there are some latches out there which can sink up to 100mA continuously, 250mA pulsed - like the STPIC6D595. Unfortunately, it can't SOURCE current, only sink it. You'd need to use source arrays with the RGB LED's you've chosen.

    Better to start out with the right registers and the right LEDs.
     
  9. coldpenguin

    Thread Starter Active Member

    Apr 18, 2010
    165
    9
    This was one other thing that I didn't really understand the logic behind the other implementations I had seen.

    They only have one arm.

    I would have thought, that having two arms, in the manner I am considering, would be so much easier to balance? It would be much easier to balance the arm both statically and dynamically.

    The power input, I am stuck so far between two ideas.

    If I go split ring, then the shaft will have to be small, and balancing on this pivot would be difficult.

    If I go for an alternative, I could use a larger shaft. I am not sure yet on the feasibility yet of this though. I have seen one design, which used two motors. The first turned the shaft, the second, was used as a generator. I don't know how much power this would generate though. Supposedly it was enough for this one design. I don't know how to measure the available current though, apart from giving it a go.


    Edit:
    Please don't interpret what I am saying here as arguing, I am just trying to understand where this 'common' design has come from. I have looked at these things for the last 5-6 years or so on and off, and am only just getting around to getting it done. However, in all of the designs I have seen, I haven't seen one which has been made symmetrical. I just don't understand why.
    Sure it isn't juts that everyone has looked at Bob Blick's clock and just copied blindly?
     
    Last edited: Jun 11, 2010
  10. SgtWookie

    Expert

    Jul 17, 2007
    22,182
    1,728
    Hmm. I haven't seen many, and the images aren't fresh in my mind.

    Ever tried balancing something statically AND dynamically?

    It's not as easy as you might assume.

    The static part is pretty easy. The dynamic part can drive you bonkers.

    Why do you think that?

    Have you ever looked at a dismantled automotive alternator? Their slip rings might be 1" to 2" in diameter.

    You'll lose a good bit of efficiency that way.

    Hey, I'm not saying that you can't do it. :) The challenge is to do some really cool things using as few parts as possible.

    Adding complexity for complexity's sake really jacks up the cost, difficulty, build time, and causes MTBF (mean time between failures) to plummet. But, Rube Goldberg projects can be fun. (If you don't know who Rube Goldberg was, please Google his name for lots of hits, and lots of fun viewing.)
     
Loading...