30 day Erratic timer

[Bigkim]

Me
I need a circuit that times for 30 days, ERRATICALLY.
For a Science project I need a Timer that will trigger for 5 seconds at a random ] time/day, 1 time during a 30 day cycle.
The circuit then resets and then triggers at a different erratic time/day over the next 30 day cycle, for 5 seconds,
Then on and on.
It should be triggering a Piezo Beeper, and an LED for the 5 seconds (approximately, not high accuracy needed either)
Please note, the day and time does not need to be accurate at all....hell, it can be plus or minus a few days. As long as its relatively erratic, its all good.

Thanks in advance for any help!

An example would be that it would trigger May 1st, 1pm, June 20th, 7am, July 15,5am...etc etc

I do have a circuit that Im trying to attach that triggers after a 30 day push of a button, if that helps...just have to find it again.
 I really would prefer a full circuit rather than using a Microcontroller, as Im 63, hell I pre-date I.C.s.
I have purchased a programming kit fro Amazon, just no time to start it.
Thanks for any help, in advance

[Kim Christensen]

Well, you could use the old CMOS 4060 timer + additional counters (if needed) for the long period... To randomize that time period you could add a LDR/CDS to the oscillator RC network (For pseudo randomness) but not have it dominate much.
For the short 5 second buzzer/LED, a 555 would be fine.

[dobsonr741]

Another way of randomizing 4060s:

1. Use one chain of 4060 (one 4060 might not enough) to be on the approximate 30 day rhythm. Use an RC oscillator for the 4060, do not stabilize the power supply.

2. Use a second chain that free runs on a frequency that allows you the desired "spread", maybe a few hours for a full overflow of the 4060.

3. Your final event tiggers when the 30 day chain triggered and then the "spread" chain reached zero (easy to detect).

[sparkydog]

Hmm.

I know you said you don't want to use an MCU, but...

The way you described the problem, triggering "the event" at 01-31 23:59:50, again at 02-01 00:00:10, and again at 03-31 23:59:50, is within specification. I haven't the foggiest idea how you're going to achieve that sort of thing using only analog circuitry. "Choose a random number X between 0 and 30d, then sleep for X, then sleep for 30d - X" is a trivial software task, especially if you have a good host platform. Doing it in hardware-only...?

You really aren't asking an electronics question, you're asking a programming question. That means at least an MCU, although in this instance I would seriously consider an SBC. An SBC is going to give you a solid host platform that will make implementing the software trivial. It will also give you easy access to non-volatile storage, which means resilience in case of faults. It's also a friendlier environment than an MCU, and you'll have a neat toy that can be used for any manner of tasks once your project is over.

What I would do (to implement this with a SBC) is:

• Using a high quality entropy source, seed an RNG with an initial state. Save this to non-volatile storage.
• On first boot, run a script that uses the saved seed to generate a time for the next event. Write a crontab entry to run the script again at that time, calling it with an argument that tells it to fire the event.
• When the script runs in 'fire the event' mode, turn on one or more GPIO pins, sleep 5 seconds, then turn them off.
• The same script should then reload the RNG state (or reseed it, if you have access to a suitable source of entropy), generate the next time, and rewrite the crontab.

You may need to run the script manually (i.e. you'll need to log into the SBC however you do that) the first time. Alternatively, you can set it up to run on boot, check if an event is scheduled, and schedule one if needed.

Properly using a cron job means nothing will break if the SBC restarts, and you don't need to rely on your process running the whole time. If set up properly, even a restart when the event was supposed to fire will result in only a modest delay, which should be okay because the timing is supposed to be random, anyway.

Cron probably won't provide you with extremely fine resolution. If you need that, generate a small (less than a minute) delay along with the crontab time that you pass into the script. Sleep for this long before firing the event.

Note that you'll also need to save the start timestamp of the current or upcoming time period to use as the basis for generating the next interval.

I should probably note that, if you aren't too worried about power consumption, you could also use any old PC you happen to have lying around, in combination with a network-enabled MCU. There are all sorts of ways a full-fledged PC can make a light blink and/or make sound.

[CountChocula]

As others have pointed out, this is trivial to implement using a microcontroller; I think that it can be done with discrete logic as well, though I think you'll end up with a giant circuit

For some fun, I fired up the old Falstad and wired up a much scaled down version that should more or less do what you want (assuming I understood your requirements correctly). You should be able to make this work for your specific use case by adding more logic gates and changing the passive components around the system clock so that they fire at the appropriate rate.

The circuit implements the following algorithm:

• Set the timeout. This is done by using a separate oscillator that runs at many times the frequency of the main clock. It's not truly random, but probably random enough for your needs. The system is in this mode when the buzzer has started, uh, buzzing. This pulls the data line of the shift register in the timeout circuit high and causes its outputs to go high one by one with each cycle of the main clock. When this happens, the D flip-flop attached to each of the outputs loads up whatever value the timeout clock is set to at that time, creating a pseudo-random sequence of bits.
• Reset the time counter. When the first bit of the shift register goes high, the time counter is reset to zero. When the last bit of the shift register goes back down to a low value, the time counter reset line is released, allowing the count to start again.
• Compare the time counter with the timeout set value. When the counter state corresponds to the values set in the timeout flip-flop, the comparator's output goes low, triggering the buzzer circuit. Otherwise, the time counter increments by one with each clock pulse.
• Buzz! When the buzzer circuit is triggered, a bit of blue logic ensures that the time counter is held in reset, and the timeout set sequence begins again, effectively resetting to the initial state.

There are probably some corner cases that need to be accounted for—for example, the reset sequence shouldn't really begin until after the buzzer has stopped, but those could be fixed with a bit more logic. Obviously, I have no idea if this would work in practice… it's just a simulation.

Enjoy!


—CC

[hanakp]

If it's for a science project, do you really need to build it from scratch? Because you could use existing arbitrary waveform generators. Even cheap (~250 USD) ones like Siglent SDG800 can generate frequencies from 1 uHz, or 11 days period. And of course there are even cheaper generator modules on Aliexpress and the like. They can usually generate noise, which could be used to create the random delay. You could debug it very easily too, you'd quickly fine-tune it on a higher frequency and then just switch it lower.

[Ian.M]

I really would prefer a full circuit rather than using a Microcontroller, as Im 63, hell I pre-date I.C.s.
I have purchased a programming kit fro Amazon, just no time to start it.

Don't let the side tasks of another project  become a fully fledged and greater project in their own right! That way lies madness and failure to complete most of your original projects. 

I need a circuit that times for 30 days, ERRATICALLY.
For a Science project I need a Timer that will trigger for 5 seconds at a random ] time/day, 1 time during a 30 day cycle.
The circuit then resets and then triggers at a different erratic time/day over the next 30 day cycle, for 5 seconds,
Then on and on.
It should be triggering a Piezo Beeper, and an LED for the 5 seconds (approximately, not high accuracy needed either)
Please note, the day and time does not need to be accurate at all....hell, it can be plus or minus a few days. As long as its relatively erratic, its all good.

As Sparkydog has commented, the lowest effort solution is a SBC (presumably running Linux) as it makes it trivial to write and test a script to implement the desired long period pulse pattern on a GPIO pin.   However, the stated low accuracy requirements also bring it well within the capabilities of an 8 bit MCU, possibly with a RTC module if greater accuracy of the repetition time of day within each 30 day period is required than can be achieved with the typical 1% to 2% MCU internal oscillator, or few hundred PPM of an unadjusted, uncompensated crystal oscillator. 

IMHO its worth the extra effort to program your favourite low pin count MCU to do the job, with extremely simple looping code to count seconds in a day, and at some particular count, start the required five second output pulse, randomising the start time (seconds count) every 30 days.   

If you don't *have* a favourite MCU, digging in to learning to program your MCU module from Amazon will almost certainly take less time than building and testing the boards full of logic chips that the proponents of hardware solutions have proposed.

If your 'programming kit' has some type of Arduino, it can almost certainly be used as an ISP programmer for any ATtiny chip for which an Arduino core exists, or you could simply get an Arduino Nano clone for a few bucks to wire into your science project, to avoid tying up the more expensive Arduino that came with your kit.

If you get stuck with developing code to implement your timer, post what you have tried so far here (in code tags for easy reading + attached as a zip file containing all *your* source so others can build the same code), and we'll help you debug it, and even restructure it if your algorithm or implementation is poorly chosen.

[Swake]

Any self respecting PLC can do this. Siemens Logo for example. Enough cheap Chinese clones.
Or an arduino of course. Randomize between let's say between 0.8 and 1.2: random(0.8,1.2). Multiply this with 2.592.000.000 (=the number of milliseconds in 30 days) and then delay().

Any 'analog' schematic will take you 10 times the amount of work. Even counting the learning curve

[mycroft]

For a Science project I need a Timer that will trigger for 5 seconds at a random ] time/day, 1 time during a 30 day cycle.

An example would be that it would trigger May 1st, 1pm, June 20th, 7am, July 15,5am...etc etc

There are more than 30 days between May 1st and June 20th. Is this a problem? Which granularity is required? 1 second? 1 minute? 1 hour?

Mycroft

[sparkydog]

Still a fan of an SBC . Besides fault tolerance, as I previously explained, one of the benefits of having what is essentially a full-fledged modern computer is that you can use a RNG of known high quality like Mersenne Twister that you can seed with 48 bits of entropy or more (Arduino is limited to 32 bits).

If you're running this project for months on end, the chances of a power outage occurring are high. An SBC will reboot and recover its state. An MCU won't be able to do that. If you go with an MCU, a UPS may be a requirement. If you have to buy one, the MCU approach is going to be more expensive than an SBC.

On the other hand, if you ignore reliability, you can write a darned simple MCU program. We've given hints how to go about that, but for grins, I went ahead and implemented it using Wokwi:

diagram.json

Code: [Select]

{
  "version": 1,
  "author": "sparkydog",
  "editor": "wokwi",
  "parts": [ { "type": "wokwi-arduino-nano", "id": "nano", "top": 0, "left": 0, "attrs": {} } ],
  "connections": [],
  "dependencies": {}
}

random-event.ino

Code: [Select]

// How often should an event happen (in seconds)?
const long interval_secs = 30; // 30 * 60 * 60 * 24

// How long should an event last (in seconds / milliseconds)?
const long event_secs = 5;
const long event_millis = 1000 * event_secs;

// How long (max) should each delay() be (in seconds / milliseconds)?
const long delay_secs = 10;
const long delay_millis = 1000 * delay_secs;

// Initial random seed
const unsigned long seed = 0x66554c8e;

#define LED_PIN 13

void setup() {
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, LOW);

  randomSeed(seed);
}

void sleep_for(long t_s, long t_ms) {
  while (t_s > delay_secs) {
    t_s -= delay_secs;
    delay(delay_millis);
  }
  delay((1000 * t_s) + t_ms);
}

void loop() {
  long when = random(interval_secs - event_secs - 1);
  long when_fine = random(1000);

  sleep_for(when, when_fine);

  digitalWrite(LED_PIN, HIGH);
  delay(event_millis);
  digitalWrite(LED_PIN, LOW);

  sleep_for(interval_secs - event_secs - when - 1, 1000 - when_fine);
}

This just turns on the on-board LED (which was convenient for simulation), but can be trivially tweaked to twiddle any set of GPIO pins. For testing, the interval in which an event can occur is specified as 30 seconds rather than 30 days, but all the parameters are controlled by constants and are easily tunable. Because 30 days is more milliseconds than fit in a 32-bit number, I pick two random numbers to determine when to fire the event, one that has only seconds granularity, and another to select a specific millisecond. If you don't need sub-second level of randomization, you could simplify things a bit by dropping that code. Due to the same 32-bit limitation, I implement a simple counting loop to delay for the requested interval. For testing, I limit each delay() to 10s, but for your final application, it might make sense to increase delay_secs, but it has to be less than ~24 days. (Personally, I would keep it to 1 week or less, but... 🤷) Also note that, assuming the board's oscillator is perfect (it isn't), this is going to systemically drift towards an interval slightly longer than 30 days because no effort is made to compensate for how long it takes to execute any of the code. However, since you indicated that exact accuracy isn't needed, this is probably a non-issue.

You should probably look into how to generate an initial random seed using available hardware. You might also want to "salt" whatever you get with some bits of known quality entropy. On the other hand, if you're only ever going to run this once (or don't mind updating the seed manually every time), you can use a predetermined seed; just be aware that doing so means you'll get the exact same sequence every time you restart the MCU. (The one shown was generated with dd if=/dev/random bs=4 count=1 | od -tx.)

p.s. Please test this yourself before using! It seems to work, but I only spent about a minute on testing.

p.p.s. I don't know what environment Swake is using; Arduino's random(), at least the C version, doesn't take floating point numbers...

[dobsonr741]

An SBC is an overkill just to have /dev/random

Low cost chips can have perfect TRNG, like this assembled breakout under $5:
https://www.adafruit.com/product/4351

[sparkydog]

An SBC is an overkill just to have /dev/random. Low cost chips can have perfect TRNG.

...so your $5 MCU board now requires another $5 board, plus assembly? (Plus learning how to interface with that chip?) When you can get an SBC for $20 or possibly less? Sure, you could do that, but I don't think the trade-off is as attractive as you think.

Anyway, the real trade-off isn't about quality of the PRNG; if you care about that (and it seems the OP doesn't), you're more likely to also care about accuracy, which means adding a better time source, i.e. another additional external component... or an SBC using NTP. The main reason I'd prefer an SBC is because it's a lot cheaper than a UPS, which (in some form) I would consider mandatory with the MCU... because a reboot of the MCU is going to completely wreck the scheduling.

With an SBC, you already have a non-volatile RTC (even if you don't use NTP), non-volatile storage you can use to remember the schedule across reboots, and... while you could write your own logic to fire the event at a scheduled time, make it robust against missing the scheduled time due to an inconvenient reboot, debug it... you could also just use cron, which is extremely well tested and already does all those things. All this for about the same material cost, zero assembly cost, and way less development time. And power failures won't wreck the experiment.

Really, it comes down to "is it a problem when the schedule gets wrecked due to some transient power event?". If it isn't, the MCU-based program I previously posted should be fine. If it is, you might as well just grab a cheap SBC and save yourself the time and effort of building yourself all the features that the SBC provides as standard.

[Ian.M]

OTOH, battery backup for the MCU version can be as simple as a CR2032 connected to the Vbatt pin of the RTC chip + code to keep the current settings in RTC SRAM, or if no RTC, a few Alkaline cells feeding the MCU's Vcc pin via a diode with a little less than the regulator's output voltage.  It may also need a resistor divider to monitor incoming power so it can enter a low power state if the power failure is long duration.

Also some SBCs are vulnerable to filesystem corruption on unexpected loss of power in their default 'fresh out the box' configuration, so you either need the knowledge and skills to avoid that, which has its own problems if you also require persistence, or need to provide a battery backup solution for the SBC, which is much more challenging than for a small MCU, due to the much higher average operating current it will draw.

Throwing a SBC at this problem, for any other reason than there's already one handling other functions that can handle the minimal additional workload, is like buying a ten tonne hydraulic press, just to crack a handful of walnuts!

[dobsonr741]

The biggest concern I have is that @Bigkim did not yet tell what the device is for - either to run the firedrill schedule in a nuclear power plant, or to operate the bird feeder in a living room.

Much depends on it. MCU vs SBC: the MCU+TRNG chip BOM is <$2 in single qty.
(DigiKey  150-ATECC608B-SSHDA-TCT-ND and ATTINY402-SSNRTR-ND)