Electronics > Projects, Designs, and Technical Stuff

30 day Erratic timer

(1/3) > >>

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) |O
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! ;D

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

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 ;D

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

Navigation

[0] Message Index

[#] Next page