Storing hours and minutes into single byte?

[CuriousOne]

Hello.

I'm developing a system which has to store user defined time variables, minutes and seconds. To save on eeprom, maybe it is possible to split byte into two "half bytes" and store hours and minutes in them?

[Demon]

4 bits can store 16.

So the hours can fit easily in the leftmost nibble of a byte (if you don't use 24 format), but there are 60 minutes in an hour.

Good luck jamming that in the rightmost nibble.

Robert

[CuriousOne]

Yes but

24+60=84
84 needs only 7 bits (2^8=128)

so why not? just how :)

[HenrikOlsson]

Because 11:14 would be the exact same thing as 14:11 - how do you differentiate them?

/Henrik.

[Amoque]

If you could live with 5 minute resolution then, I think, it is doable - easily. In the same way that 12 hours fits into the upper nibble, 5 minute increments fit in the lower.

It may also be possible to use the memory location as a partial bit - if location is even then AM, odd is PM or some such. I have not the will or the expertise to work out such a solution, but if program space is not the issue... Using the example above, it may be that you can differentiate 11:14 from 14:11 by its location? Or, perhaps you need only store the hour once every 10, 15, or 60 bytes, then use the bytes in between for only am/pm and minutes.

[Charlie]

There are 1440 minutes in a day that need to be uniquely identified somehow.
Since you require 1440 "symbols" you will need at least 11 bits.
If you want to use different memory locations, you would need 6 (8 bit) locations.
Reducing the accuracy? Sampling every 5 minutes won't cut it - you will need to go to 6 minute samples to fit in a byte.
Coding time in the smallest possible binary space is a problem that has been around for at least 70 years now - likely nobody has thought about it before :biggrin:

[towlerg]

How about 60x24=1440 8 bits is 256 save time as 6 min chuncks 1440/6=240

for example

01:08 = 1x60/6 + 8/6 = 11 (time somewhere between 01:06 and 01:11)

23:59 = 23x60/6 + 59/6 = 239 (time somewhere between 23:55 and 24:00)


Clunky but it works provided you don't need better resolution.

George

[Demon]

You could use a word for HHMM, but nothing is stopping you from sharing some of the unused bits for other data.

Robert

[CuriousOne]

Differentiation between 11:14 and 14:11 will be quite easy, because when time from RTC reaches that time, a variable is toggled, which can be later used to determine exactly what time should be read now.

[SUNFLOWER]

If you can live with 2 second resolution then there are 43200 2-seconds per day -- one word.

[Amoque]

There are 1440 minutes in a day that need to be uniquely identified somehow.
Since you require 1440 "symbols" you will need at least 11 bits.
If you want to use different memory locations, you would need 6 (8 bit) locations.
Reducing the accuracy? Sampling every 5 minutes won't cut it - you will need to go to 6 minute samples to fit in a byte.
Coding time in the smallest possible binary space is a problem that has been around for at least 70 years now - likely nobody has thought about it before :biggrin:

One wonders how you know that all 1440 "symbols" need be uniquely identified. The Op didn't say so. In fact, if all 1440 symbols were needed, then he would likely make a 1 minute interrupt and save all the speculation. Nor do I full understand why 6 minute samples are needed? There are 12 five minute segments in an hour; if it possible to represent the 12 hour positions in 4 bits, why can not the 12 five minute positions be represented similarly (in four bits)? Lastly, I would respectfully suggest that the OP already has a clock, he is looking to record some finite number of unique data points, not serial time at all.

Here is an example of my thinking: Suppose the OP would be satisfied to record 5 points per hour in 128 bytes. He might record any 10 minute readings (5 AM, 5 PM or any combination) between memory positions 00 and 10. All of these bytes are presumed to be in the hour between 12:00 (zero hour) and 1:00; similarly, between address 11 and 20 are the data points corresponding to the hour between 1:00 and 2:00 - and so forth. In this way he might record 120 unique time stamps in 120 bytes -and include an AM/PM flag in one of the remaining two bits. Adequate? I don't know... Only one thought that might spur others.

[Amoque]

Ha! You see? It has spurred another thought: By dividing the elapsed time since midnight by 85 (seconds) it is possible to use each bit as a flag - with limited resolution, but... well, perhaps adequate.

[CuriousOne]

User inputs time in hours and minutes, so second precision is not required, minute-level precision will be enough.

[HenrikOlsson]

Hi,

Differentiation between 11:14 and 14:11 will be quite easy, because when time from RTC reaches that time, a variable is toggled, which can be later used to determine exactly what time should be read now.
I'll admit, I don't really get that or exactly what you're doing but I thought the issue was lack of variable space.... If you're going to use flags to keep track of what's what then you might as well use those flag bits as part of the "time variable" to increase its resolution.

Anyway, if the resolution can be reduced then of course you can fit in any number of bits, just a matter of how much you need to reduce the resolution.

/Henrik.

[CuriousOne]

I'm doing a light controller timer. It has 16 channels, user can set up individual channel ON and OFF times, by inputting time in hours and minutes.

[towlerg]

@Amoque
Nor do I full understand why 6 minute samples are needed? There are 12 five minute segments in an hour; if it possible to represent the 12 hour positions in 4 bits, why can not the 12 five minute positions be represented similarly (in four bits)?

There are 24 hours in a day and 4 bits will only "do" 0-15.

George

[Dave]

I have to ask, Why are the byte constraints so important? Why not words? Are you that straped for eeprom space?