Ds1302

hmlittle59

Hello To All,

I'm working with the BS2 and the DS1302 RTC. I'm getting confused on the format in which the Day Of The Week(DOTW) is returned. Zero (0) thru Six (6) or One (1) thru (7), for (Monday, Tuesday....etc.). I THOUGHT that I had this figured out, but I was wrong. Does anyone know for sure? Will the chip work both ways, but one way is the default?

Thanks for any help

Howard

Sapphire

It's 1 to 7. You can make any day 1, but all the rest must be sequential. Zero is uninitialized, but will become 1 at midnight. After midnight on day 7, it resets to back to 1.

Moskog

Due to the datasheet the day of week range from 1 to 7.

The day-of-week register increments at midnight. Values that correspond to the day of week are user-defined but
must be sequential (i.e., if 1 equals Sunday, then 2 equals Monday, and so on.). Illogical time and date entries
result in undefined operation.

http://www.biltek.tubitak.gov.tr/gelisim/elektronik/dosyalar/46/DS1302.pdf

Tracy Allen

I prefer to pull the day of week from the date itself. Here's a subroutine that's good for things like figuring out which day is the second Tuesday of the month.

[/COLOR][COLOR=#0000ff][FONT=courier new][/FONT][SIZE=2][/SIZE][SIZE=1][FONT=courier new]julian: 
' calculates JD, the day of year from 1 to 365 (or 366 in leap year)
' and JDN, ordinal date starting with 1 on Jan 1st, 1900
' and DOW, day of the week, Sunday = 0 thru Saturday = 6
' enter with MM=month, DD=day and YY=year in flat binary, not BCD (use bcd2binary to convert)
' good from Jan 1 2001 to Dec 31, 2099. 
    JD=MM-1*30+(MM/9+MM/2)-(MM max 3/3*(YY//4 max 1 +1))+ DD
    JDN=JD+(YY-1*365)+(YY-1/4)  
    DOW = JDN//7
   return

bcd2binary:
' convert BCD time day month year from RTC chip to flat binary.
  DD = DD.nib1 * 10 + DD.nib0   ' BCD to binary conversion of day
  MM = MM.nib1 * 10 + MM.nib0   ' BCD to binary conversion of month
  YY = YY.nib1 * 10 + YY.nib0   ' BCD to binary conversion of year [/FONT][/SIZE][/COLOR][COLOR=#0000ff][SIZE=1][FONT=courier new][/FONT][/SIZE][/COLOR]

hmlittle59

Hello All,

Thanks for the replies. Tracy, yes, I did use your routine in my BS2e version that sets the (DOW) once the Date's have been entered. But my "Day Light Savings Time"(DLST) routine has been giving me fits. If the routine is turned on then on that day (Sunday 2:00am) the time goes either up or back. Once all the Bugs and over-sites were worked out, it worked 100 out of 100 times when everything is set on that day (Sunday 1:45am or so). Again, using your routine to calculate the (DOW). It just would not fail if set on THAT day and left to run. But the problems appears to be when rolling from "SATURDAY" day 6 to "SUNDAY" day 7. So I will go back and check with the Debug window (AGAIN) what value is being returned from your routine above, the DS1302 on Sunday, and what I am looking for. Somewhere along the way I may have switched the Day to look for Zero(0) instead of One (1). This routine is a critical part of my program if the Day Light Savings Routine is turned on. So it has to be exact. If the "Event" happened and (DLST) was to happen during that time period, then other variables must be adjusted accordingly.

1) I'm using your routine to set the DOW (Sun,Mon,etc)...works great
2) I wrote a Day Light Savings Time routine. works every time .....When set and tested on that day(Sunday).
3) It appears that I'm looking for the wrong DOW value...Zero (0) instead of One (1).......I hope thats all it is.
4) Will set up a 3 or 4 day simulation (IF day = 4 then Hour = $23 :Minutes = $58....IF day = 5 THEN Hour = $23 : Minutes = $58...etc), to try and make the DS1302 act like its going thru the motions of a full day and then see if the new routine catches it(Day 1, 2:00 am)

Thanks for the feed back
Howard

Tracy Allen

My DOW algorithm does return Sunday=0 thru Saturday=6, in contrast to the 1 to 7 for the DS1302. The RTC I use with the Propeller is the ISL12020M, which uses 0 to 6, but it also has automatic daylight savings time correction, which is kind of hard to set up (I haven't bothered with it!).

In the USA we (most states) spring forward on the second Sunday of March, and fall back on the first Sunday of November. My strategy in setting the clock is to feed the algorithm March 1st and November 1st and determine the DOW of those days from 0 to 6 for the current year. Also retain the ordinal day of the year, for example, in non-leap years, March 1st is JD=60. So, the second Sunday of March in non-leap years will fall on JD = (7 - DOW) // 7 + 7 + 60. For example, in 2014, March 1st was a Saturday, so the second Sunday was JD = (7 - 6) // 7 + 7 = 1 + 7 = 68th day of the year. Similarly for the fall back on the first Sunday in November. The time reset has to occur on those particular ordinal days, and it has to set an auxiliary flag to indicate standard/summer, so that it won't get in a loop at the transition.

hmlittle59

Hello Tracy,
I'll study your code some to understand it. I did go back to your original (DOW) code and did a (Day = Day + 1) to get in sync with the DS1302 format. I just don't understand how I missed any errors during my constant and repeated testing. The only time the error happened was during normal operation and the rolling from Saturday to Sunday. At that time, I only set the time (ON) that day before the 2:00 am DLST period. This time I started from Saturday 11:58pm an once it rolled over there was IF/THEN to bump the time by 1hr and 58mn and it worked just fine. I'm gonna set it up for a 8 day run from Oct and make sure it passes. Just make sure it falls thru the routine. I'll post a copy of the routine after this final test. It's not just a couple of lines like yours. I also use a duplicate copy of the code for March.

Thanks for helping me in clearing up this BUG.