Checking date to define an action

mushroom

New Member
Hi. I have a project that's become urgent. I'm using two Picaxe 20x2's, talking to each other via a 'nrf24l01' radio link, in a master/slave setup. Two LEDs on each micro flash at about a 1 Hz rate, controlled by the master micro. All the above works fine. Now the problem. Using an on board DS1307 RTC I wish to be able to turn the above flashing LEDs on for one hour, twice a weekday, getting it's on/off time from a 12 month list of on/off times for each day. There is one 24LC256 memory chip on board. Any thoughts anyone? Have searched forums for similar jobs. Found none that refer to checking the date to define an action. Think I'm out of my depth.

PLEASE READ MY POST UPDATE AND NEW QUESTIONS, BOTTOM OF PAGE.
 
Last edited:

Janne

Senior Member
I think the easiest way would be to build an array containing 365 values, the hours during which the leds are on. This array (or just a consecutive list of variables starting from memory slot 1..) you would then upload to the external or internal eeprom of the picaxe(not sure if any of the picaxes has enough EEPROM for this). The values could be also fit on the program memory (flash), using lookup tables. For leap year use an extra variable or something similar to store the values.

While running you would read out the date from the RTC(remember to take leap year into account), and get the on-times for leds from your data.
 

mushroom

New Member
Janne. Thanks for your suggestions. Will research these ideas today. I do have a 24LC256 EEPROM on board to use. I have assumed that I can use hspi and hi2c within the same program on the 20x2. I have not done this before and will try today. Have had no trouble using hspi with hi2c's pullup resistors installed.
 

srnet

Senior Member
I have assumed that I can use hspi and hi2c within the same program on the 20x2. I have not done this before and will try today
If the SPI interface is in use, then the I2C devices on the same pins can get very confused.

Unless you can disable the I2C devices in some way whilst the SPI devices are in use, its guesswork as to what is going to happmn.
 

Buzby

Senior Member
Both the DS1307 and the 24LC256 are I2C devices, so no problem there.

Where does your hspi come in to the picture ?
 

mushroom

New Member
Thanks. Usefull comments. The hspi is used for the 'nrf24l01' radio transceiver. It's been a long struggle to learn to drive this transceiver. I'd like to keep it, if possible. Tranceivers would be inactive at the time the I2C devices are accessed. I don't mind confused I2C devices, as long as their confusion doesn't change RTC time or stored memory, and that they can be accessed when hspi is made inactive. Does that sound feasable? I2C devices will only exist on the master board.
 

Pongo

Senior Member
Be aware that without some kind of external correction the DS1307 is not a super accurate clock so it may or may not meet your timing requirements over a long period like a year. Google will find you plenty of examples of actual user experience.
 

mushroom

New Member
Thanks all for your comments. Very usefull info. I could have waisted a lot of time. Now I have a more informed plan to investigate.
Srnet. Your link to your previous tests was so informative. Great work. I'm in Aust, and when I tried to respond 12 hours ago after arriving home after work I found I couldn't log on. (password at work). Appologies.
 

mushroom

New Member
This project is ongoing. Field work has delayed progress, however I'm back. Appreciated advice
has been taken on board and a new approach developed. Aims as outlined in post one.
Have several of two different boards to work with. One with a 20X2, the other with a 40X2. Each
have successful nrf24l01 tranciever impletation, and the 20x2 has a SparkFun DeadOn DS3234 SPI RTC,
fitted yesterday. System will be run from and switching 12 VDC via Mosphet boards I've already created. (up to 8 Mosphets per board).
Current thoughts are to use a SparkFun OpenLog board for SD card READING of a file of twelve months of on and off times. (3 x one hour long 'on' periods per weekday with exceptions, ie public holidays). Vague comments have implied OpenLog can be used in this way and not just logging. Please, any thoughts on this and experience with openLog? Suggestions? Also have searched for guidence on set up and use of the RTC. Seems few have used this module on Picaxe. My programing skills are challenged, so would hope to adapt others success. A secondary project exists if success is achieved, using same board components and minimal program change, so it maybe two projects for the mental contortions of one. ALL THOUGHTS AND ADVICE
WOULD BE APPRECIATED, AND KNOWLEDGE GAINED WILL BE FED BACK TO THE FORUM. Have added personal detail on my profile to inform those that my wish to know my background and spot on the planet.
 

rossko57

Senior Member
Thinks ; is this mystery hourly action linked to clock times, or to sunrise/sunset (which can be kept track of without RTC)? Does it need to account for daylight saving time?
 

mushroom

New Member
Rossko. Thanks for reading the post. 'On' times are linked to date, day of the week, and time. Approx 8am 'ON' for one hour, then 12 noon 'ON' for an hour, and lastly about 3pm 'On' for an hour. Daylight saving time is relevent, however I hope to chart needed on/off times on an SD card loaded from a computer. I could cheat and incorperate daylight saving times by fudgeing this chart. Not the best option. I expect to be working out in the field and out of contact for several hours soon, but my next task is trying out the RTC programming using limited found attempts by others, and the chips data sheet. Also I need to define if my idea of using 'openLog' is feasable. Haven't bought this module yet but may for it's logging simplicity for unrelated use. I have noted your term "mystery", and will outline the projects full purpose in detail as soon as I can. Probably tonight after I get my mini people to bed.
 
Top