I am beginning to write some code for a clock.

Archive FastLED Archive
1

I am beginning to write some code for a clock. I have a crystal install in the Teensy 3.1.

I have 60 LEDs - so the maths is easy - even the hour is dead easy using (hour() % 12) * (NUM_LEDS/12)

When I let my code run freestyle it runs really quick — a minute takes 40 seconds.

{
fill_solid( &(leds[0]), NUM_LEDS, CRGB::Black );
leds[second()] = CRGB::Blue;
leds[minute()] = CRGB::Green;
leds[(hour() % 12) * (NUM_LEDS/12)] = CRGB::Red;
FastLED.show();
}

I fixed this by adding a delay 250ms to the loop.

I am really curious what causes the fast running — I thought perhaps because I was running it overclocked (there’s no need - I scaled it back)

On a similar topic — any ideas why doesn’t this work:

elapsedMillis ms;
{
leds[(ms % 1000) * (NUM_LEDS/1000)] = CRGB::White;
}

I know this isn’t strictly a FastLED issue — but I know others have made clocks!

2

Have you tried out the Teensy time example noted here? https://www.pjrc.com/teensy/td_libs_Time.html#teensy3

I havent done clock stuff, but I think seeing the actual clock output in serial would be a good indicator of if your clock is off

3

Hi Ryan,

I’ve checked that out — the time is fine when working with the delay — and using the TimeTeensy example.

I sorted my milliseconds issue — int newms = (ms % 1000) * (NUM_LEDS/1000.0)

Should have realised I was multiplying by zero — doh!

James

4

It appears teensy also has a clock compensation setting: Teensy3Clock.compensate(int). I would double check your soldering and whatnot.

Is the 250ms delay causing it to read accurate times, or is that just correcting the time? I wonder if refreshing the clock too quickly causes errors. Indeed I’m in over my head here, I hope others have some insight :slight_smile:

5

It appears to be to do with the way it keeps time — if I set setSyncInterval to 1 then I get an accurate time but the second hand pauses every so often as it resynchronises itself.

If I set setSyncInterval to 10 then the thing is constantly moving the second hand backwards every ten seconds to correct itself.

6

Thanks for the idea. I was going to add a RTC to my Ardunio so I could turn my lightshows on/off automatically by time of day. I’ll play around with your code examples to see if I can get it to work for me. Of course, I will need to set the clock to some virtual time first.

7

Hi Bob,

The Teensy is very convenient as it has an RTC built in — for the cost and if it’s accurate enough for you it’s a neat solution. All you need is a coin battery holder.

The example code that comes with the Teensyduino software will set the time for you to your PC/Mac clock — super easy.

James

8

Update: I sorted this issue by doing this at the beginning of every loop:

time_t time = Teensy3Clock.get();

and then using the usual hours, minutes seconds etc

minute(time)

I also wanted to get an accurate millisecond so I am reseting an elapsedMillis every time a new second happens — this still won’t get you an accurate millisecond because it’s still using the Teensy crystal for timing which is approx 1.5x too fast on mine (overclocked 96Mhz). So I time the whole loop and then apply a compensation something like:

compMs = ((1000.0 / (ms-oldMs) + compMs) / 2;
oldMs = ms;
realMs = int(ms * compMs);

Averaging it made it a bit more consistent.

Hope that helps others.

James

9

Thanks James. Just cutting my teeth on an Ardunio. I will look at the Teensy. Can I use my existing Ardunio sketches to drive it?

10

Bob— depends if you’re using any odd libraries— most of the key ones are ported to Teensy. The Teensy is really great — it’s so much quicker and bigger and gives huge overheads for speed and memory.

It’s a no brainer to go for a Teensy over an Arduino.