Julian date ??

H

Hansen

Member
Julian date is 7 char long

exm 2453623 i can't have that in a word this come from eeprom as ascii char in 7 diff byte

2453623 JD is CE 2005 September 09

7 char off JD read from 24c08 byte 3f hex to 45 hex
as the same time it have a another date 0605 also in ascii code

0605 is month 6 year 5

this 4 char read from the same 24c08 location 80 hex to 83


What i want is the change the month and year the the PICAXE need to calculate new JD number

this 4 + 7 digit shut be change back to ascii and stored the new JD and MMYY the same location




follow code line is to read data extranal eeprom an store it in the internal

I want to change MMYY that shut be stored back to externat to be 0911 ( 9 month 11 year )
now it shut make a new JD from MMYY + some day, as in the top (2453623 JD is CE 2005 September 09 = relation to 0605 (MMYY)


Code: 
i2cslave %10100000, i2cfast, i2cbyte

main:

'Read  7 byte from eeprom and store it in interne eeprom add 0 to 6
	for b12 = #3F to #45
	     readi2c b12, ( b11)
           b10 = b12 - #3E
           write b10, b11
      next b12
'Read  4 byte from eeprom and store it in interne eeprom add #10 to #13
	for b12 = #80 to #83
	     readi2c b12, ( b11)
           b10 = b12 - #70 
           write b10, b11
      next b12
end
 
premelec

premelec

Senior Member
I don't know if you looked back [search!] in this forum's posts - there was a pretty long bit on Julian Dates a few years ago that might be of help...
 
B

bluejets

Senior Member
According to this site.....Quote ...

"Many applications (especially mainframe systems) store dates in the Julian format, which is a 5 digit number, consisting of a 2 digit year and a 3 digit day-of-year number. For example, 24-August-1999 is stored as 99236, since 24-August is the 236th day of the year."

http://www.cpearson.com/excel/jdates.htm
 
premelec

premelec

Senior Member
I thought the 'real' Julian date as used by astronomers and such was a long number indicating the number seconds since AD 0 or some such :) perhaps there are many variations - I thought the idea was to make a date into a number which would easily lend itself to calculations without special calendar interpretations - I guess I'll have to re-view my view :)
 
W

westaust55

Moderator
premelec said:
I thought the 'real' Julian date as used by astronomers and such was a long number indicating the number seconds since AD 0 or some such :) perhaps there are many variations - I thought the idea was to make a date into a number which would easily lend itself to calculations without special calendar interpretations - I guess I'll have to re-view my view :)
Click to expand...
True there are 4, 5 and 6 byte implementations some of which go go down to seconds and fractions thereof.

I did some work (a bit clunky/bulky) when I was experimenting with 1-Wire networks and an associated Julian type 1-Wire RTC chip (DS2417).
See post 39 here: http://www.picaxeforum.co.uk/showthread.php?15306-One-Wire-Devices-Networks/page4
and post 74 here: http://www.picaxeforum.co.uk/showthread.php?15306-One-Wire-Devices-Networks/page8
 
H

Hansen

Member
srnet said:
I hope I am not the only person that is having difficulty understanding that post.
Click to expand...
maybe I have not explained problem well enough

The MMYY info in the EEPROM is battery pack born date
The JD info is the shipping date and it used to limit the time how long it can be used

If the battery pack JD is more that 1 year old is not possible to install it in the system and if system have 1 that more than 3 year it want an new pack

inside the packet 10 * 1.2 Nihm cell and the little small 24c08

I want to recycle the battery pack



thx for all the other port replay, after reading I see I only need to look at the 4 last digit of the JD because 1 year add = 365, and it will take a lot off year's before I need to 5 digit :)
 
W

westaust55

Moderator
Okay, I see what you are endeavouring to do.

This does then raise the question, is this a one off task or something that will be repeated regularly ?

If it is a one-off task it might be easier to use the PICAXE to read the EEPROM and display the dates, manual convert and just have the PICAXE write the new dates in ASCII format back to the EEPROM chip.
If more frequent, then it is warranted to develop a routine to update in a more automated manner – maybe with a DS1307 RTC to extract the present MMYY date as a reference for the new data to be programmed.
 
H

Hansen

Member
westaust55 said:
Okay, I see what you are endeavouring to do.

This does then raise the question, is this a one off task or something that will be repeated regularly ?

If it is a one-off task it might be easier to use the PICAXE to read the EEPROM and display the dates, manual convert and just have the PICAXE write the new dates in ASCII format back to the EEPROM chip.
If more frequent, then it is warranted to develop a routine to update in a more automated manner – maybe with a DS1307 RTC to extract the present MMYY date as a reference for the new data to be programmed.
Click to expand...
This is a repeated regularly

JD is 3 month newer than than the MMYY

If MMYY is 0911 then JD shut be 12 month 11 year and still JD shut also be 2-3 month old

2 main function

1: read out all info from the 24C08 8 byte at the time hex and ascii ( that already work today)

2: reprogram chip with new JD 2-3 month old and MMYY that 5-6 month old

to control MMYY i had think about program wheels 1-15 one for year and one for month
1 switch to switch betwin the 2 program section
 
hippy

hippy

Ex-Staff (retired)
It certainly should be possible to read out the 'build date' and 'shipping date', adjust those and write one, the other or both back to the Eeprom ( assuming Write Protect signal to Eeprom is not active ). The only issue is in knowing what the format of the two numbers are and how they are encoded and the 'build date' seems to be just two bytes.

I'm however not sure what help is being asked for.
 
W

westaust55

Moderator
I am also confused.

If a battery is being rebuilt then is it not already likely more than a year old?

As previously stated : The system in which it is fitted require the battery must be less than 1 year since manufacture when fitten and must be relaced by 3 years form manufacture.

So why:
reprogram chip with new JD 2-3 month old and MMYY that 5-6 month old
Click to expand...
why not after a rebuild set the build date to the current month/year? and also MMYY of Julian Date accordingly as well.
 
H

Hansen

Member
westaust55 said:
I am also confused.

If a battery is being rebuilt then is it not already likely more than a year old?

As previously stated : The system in which it is fitted require the battery must be less than 1 year since manufacture when fitten and must be relaced by 3 years form manufacture.

So why:


why not after a rebuild set the build date to the current month/year? and also MMYY of Julian Date accordingly as well.
Click to expand...

Exampel

battery box that endoff life

Box info

MM/YY = 0207
JD = 2455562 = 2007 may 6

then you change the battery cell in the box

change MMYY 4-5 month old off current date
and change JD to 1-2 month off current date

this make the battery box look like as new battery box ( just you recycling the box)

Rule on in this case is JD always in 90 more than MMYY date

battery box life time is 4 year's from JD
 
You must log in or register to reply here.
Top