Re: Keypad for Gated Entry

and it is legal to log all this?

Yeah, I’m not sure where all the legal stuff was going. This should be a very doable project with Arduino. As far as the logging, how much data are you wanting to retain? If it’s more than the a little and for convenience it would probably be best to store the data on a SD card.

I’d recommend getting each portion working on it’s own and then combining into the final project.

Thank you Digger450. Would I be correct in my calculation? If I use the DS1307 as my real clock and source for the time stamp, and if the AccessCode+TimeStamp were stored in 8 bytes and the( access codes maximum of 6 characters ) then I’m looking at 8 bytes per entry. I have the atmega328 on the Arduino which has 1K EEPROM. With this calculation I could store more than 120 entries which is good enough between resets every 3-4 weeks. Can I store the AccessCode+TimeStamp in 8 bytes? Thanks for the reply.

Can I store the AccessCode+TimeStamp in 8 bytes?

Probably, but not using the way you describe if you access code is 6 characters long:

You will need 4 bytes to store the time. The most efficient way is to store the number of seconds since a fixed data. There is arduino code to convert from date and time elements into this 4 byte value in the DateTime Library called makeTime that will do this. (You don’t need any of the other functions because you are using a real time clock, the following line will return a long (a 4 byte number) that contains the time
long time = DateTime.makeTime(sec, min, hour, day, month, year);

The method of encoding time as seconds since a date is a standard (sometimes called unix or posix time ) and most programming languages have a function that understands these values.

You can reduce the number of bytes to store the access code from 6 to 4 if the code is numeric. A search for atoi in this forum will turn up discussion where converting from character representation of a number to an int is discussed. Because your numbers are 6 digits you need to use the long integer version, named atol

If you want to go to some extra trouble, you can squeeze your access log entries even further.

Presumably, you have a list of access codes in EEPROM, to check against the code they enter. When you log it, you don’t need to save the whole access code. Just save the index of the code from the list.

For example, if the list of valid codes is:

  1. 123456
  2. 987654
  3. 743979

and they enter ‘987654’, you would log ‘2’, meaning the second entry in your list. (Of course, in ‘C’, array indices start with 0, but you get my meaning).

Unless you have more than 256 access codes, logging the access code this way will take up only one byte.

As to the time, if you don’t need one-second accuracy, you can just log minutes. As mem said, use an offset since a particular date. For example, calculate the number of minutes since Jan 1, 2009 and store that number. If you do this, three bytes can store over thirty years of date stamps.

There are a few disadvantages to this time and date stamp method. You’ll have to write your own routines to do the calculations, and you’ll also have to write the routines to convert the ‘elapsed minutes’ numbers back to regular dates and times.

But, if you want to cram the maximum number of log entries into the smallest amount of space, that’s one method.\


Mfm9’s suggestion for logging the index is a very good way to minimize memory usage. But if you need to log all invalid entries for security reasons then you need all the digits (and probably lots of RAM to hold them).

There are lots of tricks you can do to reduce the number of bytes to hold time, for example if a minute is sufficient precision then you could use two bytes to hold the number of minutes since the last logged reading (you would store the full four digit date and time of the first reading only). But it would be prudent to keep things simple to start off with.

the letters represent access code
Are you saying the access code will be alphanumeric?

Will there be one access code or many? Will it be changed, if so how?

Once you have the basic outline for the functionality decided it will be easier to figure out implement the data storeage.

If we take the following code for example:
How can i change serial.println(key) to sore the key entered? I dont think i coud use serial.write(key) can i? If so how would i know where it writes to? In an array or EEPROM? If i store in EEPROM then i am using the analogeRead(0). This cant be can it? Its an analog pin (0) the keys are from digital pins. Or am i just completely lost…? Thanks.

#include <Keypad.h>

byte rows = 4; //four rows
byte cols = 5; //four columns
byte rowPins = {0, 1, 2, 3}; //connect to the row pinouts of the keypad
byte colPins = {5, 6, 7, 8, 9}; //connect to the column pinouts of the keypad

Keypad keypad = Keypad(rowPins,colPins,rows,cols);

void setup(){

void loop(){
char key = keypad.getKey();

if (key != NO_KEY){

If i store in EEPROM then i am using the analogeRead(0). This cant be can it?
Yes, it can’t be :wink:
Have a look at the EEPROM example sketches to see how to read and write EEPROM. But I suggest you do the EEPROM part last. Get the core functionality working first. I suggest you write a function in your sketch (call it something like logEntry) where you pass the keycode (or index) and it displays the information on the Serial monitor. When you have the data capture working correctly you can add the EEPROM interface.

It would help us to help you if you said a little more about what the sketch needs to do. There was a question asked in the previous post regarding data entry that I would be interested in reading the answer.

<<Are you saying the access code will be alphanumeric?

The keypad that I’m using has 4 rows and 4 columns. Column 4 has A @
R(row)1, B @ R2, C @ R3, and D @ R4. I figured since the pad has letters why not use it?

<<Will there be one access code or many? Will it be changed, if so how?

I was thinking to use the first digit and the # as the access keys. That will make things easier. I would not have to create access codes. The access codes will just be assigned (verbally) as a combination of 5 digits (ex. 1001A, 1001B?) that begin with 1 and (letter indicating the apartment unit# A-E) the # will function as Enter/Open and/or store key. The program will accept any access code that is 5 characters and begins with 1.

<<When you have the data capture working correctly you can add the EEPROM interface.
I’m trying to understand some code now:
#include <Keypad.h>

const byte ROWS = 4; // Four rows
const byte COLS = 4; // Four columns
// Define the Keymap
char keys[ROWS][COLS] = {
{‘1’,‘2’,‘3’ ‘A’},
{‘4’,‘5’,‘6’ ‘B’},
{‘7’,‘8’,‘9’ ‘C’},
{’#’,‘0’,’*’ ‘D’}

byte rowPins[ROWS] = { 8, 7, 6, 5}; // Connect keypad ROW0, ROW1, ROW2 and ROW3 to these Arduino pins.
byte colPins[COLS] = { 12, 11, 10, 9 }; // Connect keypad COL0, COL1, COL2 and COL3 to these Arduino pins.

Keypad kpd = Keypad( rowPins, colPins, ROWS, COLS ); // Create the Keypad

#define ledpin 13

void setup()
digitalWrite(ledpin, HIGH);

void loop()

char key = kpd.getKey();

if (key != NO_KEY){

I’m trying to understand what I could use instead of the serial.println (key) to log a key. If EEPROM is written to with analogRead(0) do i have to use shitOut or what…? I dont understand :-?

If you really want to do the EEPROM part first then start by looking at the EEPROM example sketches as suggested previously. But I don’t recommend you start your project with this for a couple of reasons:
You have not decided how you will store the data – the hexadecimal characters you intend to use can be packed so that two fit into a single byte. It is also not clear if you need to store the entered number or just the index. Your post implies that the access codes for each apartment are hard coded into the program, but what happens if someone moves their access code needs to be revoked?

The other reason not to do the EEPROM part first is the EEPROM memory (unlike RAM) has a finite number of write cycles. The number is large enough so that well behaved code will not be a problem, but if you have a programming error and a loop gets out of control you can accidently exceed this.

Thank you. Keep in mind I am learning in this process, it is the most important part of the whole project. This is my first programming project with the Arduino Duemilanove ( ) I don’t think its much about the necessity of building the thing. Its more like a personal advanced project, and I like to learn as I go along. I kind of see this as my hands on learning environment, and if I may do so respectfully. I may understand things a bit differently and my questions may not be too revealing because I like to do some of the work myself. I am writing to get direction and feed back and try to use my combined understanding when building.

You have not decided how you will store the data.
Actually I have. I just thought I first learn how to write and read and then I’ll concentrate on the what to write part. In my mind I think I’m approaching it from a fundamental perspective. At this point I am merely trying to manipulate code in an effort to understand and learn.

but if you have a programming error and a loop gets out of control you can accidently exceed this.

Thank you for this!!! I totally forgot about reading that. I may have ran the write code maybe a few times.

<<<<<<With regard to writing to EEPROM however, what does the following code say ?
#include <EEPROM.h>

void setup()
for (int i = 0; i < 512; i++)
EEPROM.write(i, i);

void loop()

<<<<<<<What makes it different then this one? And finally, which one could be used in the above keypad code and how ?

#include <EEPROM.h>

int addr = 0;
void setup()
void loop()
int val = analogRead(0) / 4;
EEPROM.write(addr, val);

addr = addr + 1;
if (addr == 512)
addr = 0;

I am not sure if the original posts have been removed but the question:-

and it is legal to log all this?

Very much depends on the country you are in. In Scandinavia it is illegal to log legitimate information. That is if some one is entitled to enter and they enter with the correct code you can’t log it. In other countries like the U.K. you can do things like this. You would have to ask an expert in the country you are in for a proper answer.

Polite request.
Can you post code between the square brackets that come up when you click the hash icon in the reply box.


The EEPROM is like an array of bytes. In this case the array is 512 bytes long. Of course the advantage of EEPROM is that the bytes you write to EEPROM are preserved even after the power has been turned off.

Just as each element of an array has a subscript, each byte of EEPROM has an address. The first byte’s address is 0, the second byte address is 1, etc., up to the last byte, which has an address of 511.

Unlike an array, however, you need to use a function to read or write a byte from/to EEPROM. To write a byte to EEPROM, use:


Where ‘addr’ is the address (0 - 511), and ‘b’ is the byte you want to write.

To read a byte from EEPROM, you would say:

b =;

So, the first example you gave writes the EEPROM with a 0 at address 0, a 1 at address 1, etc.

The second example uses analogRead to read the voltage at a pin, writes the value to EEPROM, waits 100 milliseconds, then does it again. It also adds one to the address each time, so each successive value goes to the next position in the EEPROM. There’s an interesting twist in this code: when it reaches the end of the EEPROM, it goes back to the beginning, and starts overwriting the previous 512 values. This means that the EEPROM will contain the most recent 512 voltages read with analogRead().

So you see, the analogRead() has absolutely nothing to do with reading and writing the EEPROM. In the example, analogRead is used just as a source for data to write to EEPROM. The data could just have easily come from a keypad instead of analogRead().

I hope this helps.


Vraiment bien!

Merci, c’est justement ce que je cherchais

Merci beaucoup

merci de votre part

c’est une bonne idée

il semble intéressant

[u]comparatif simulation assurance vie multisupport[/u] - simulation assurance vie ! Les sites de simulation assurance vie[u]comparatif simulation assurance vie multisupport[/u]

Mais, il ne marche pas.

Roselady123 Je vous en prie. C’est un acces- mecanisme qui est tres facile. Oui, ca ne marche pas maintenant. Mais si ca marchais, alors nous n’aurions pas le projet. PardonmyFrench…I’m a littele better at English. Parlez-vous?

Key word LED pin 13 open/close or on/off*.
AWOL the other hand!!! Can’t you lend the other hand??? Whats wrong with the code??? :frowning: >:( :-? :-? :-?

Without any evidence, it’s difficult to see what’s wrong, but you’re reading the keypad twice each time.
If this flushes key presses, you’ll only log every other press.