next topic »

[Reply #90 on:]

What uC are you using?

I've run that code on the 168,328 and 644 (with the Sanguino).

Try putting some Serial.print statements before each instruction in the loop to see
if you can isolate the specific instruction that is causing a problem.

In my main program I have a couple of other include statements. I am assuming
that if these were required your program wouldn't compile.

(* jcl *)

[Reply #91 on:]

Aha! A moment to get back to this.

I am using a 168.

The code gets through the setup, enters the loop, and gets as far as:
rtc.read_regs();
It never returns from that call.

It could be something simple, what pins should I be using? Is it analog pins 4 and 5?

[Reply #92 on:]

Yes it is analog pins 4 and 5.

Do you have pull-ups on those lines?

There is a schematic in the NB1A datasheet at http://www.wiblocks.com

(* jcl *)

[Reply #93 on:]

Hello,

I just started with this library, it seems to work but every time I close the serial port and open it agian the time resets (I have a 3V battery connected)

This is the sketch I use:

Code:

#include <Wprogram.h>
#include <Wire.h>
#include <DS1307.h>

int rtc[7];  

void setup()
{
  Serial.begin(9600);
  RTC.stop();
  RTC.set(DS1307_SEC,1);
  RTC.set(DS1307_MIN,23);
  RTC.set(DS1307_HR,12);
  RTC.set(DS1307_DOW,1);
  RTC.set(DS1307_DATE,1);
  RTC.set(DS1307_MTH,10);
  RTC.set(DS1307_YR,7);
  RTC.start();
}

void loop()
{
  RTC.get(rtc,true);
  
  for(int i=0; i<7; i++)
  {
    if (rtc[0] < 10 && i==0){ Serial.print("0");}
    Serial.print(rtc[i]);
    Serial.print(" ");
  }
  
  Serial.println();
  
  delay(1000);

}

[Reply #94 on:]

Hi Wouterk,

Isn't that what you do in the setup() of the sketch? Setting the time to 12:23:01.

Jeroen

[Reply #95 on:]

So every time a serial connection is established the Setup() routine is called?

That should indeed explain the kind of behaviour that i'm experiencing...hmm

[Reply #96 on:]

Okay so I removed the RTC.set statements from the Setup routine.

And set it once to the right time and date.
After 4 minutes the RTC is already more than 2 minutes behind

I'm using an 32,768 Mhz crystal, here's a picture of my setup:

[Reply #97 on:]

Your picture is very fuzzy so I can't say for sure but it seems like the wiring my not be correct. The crystal should wire to pins 1 & 2, batt + to pin 3 and batt- to pin 4 and common ground.


Lefty

[Reply #98 on:]

Maybe this will help.
Its what I did when I was playing with th DS1037.


http://scratchpad.thisandthose.org/joomla/index.php?option=com_content&view=article&id=1&Itemid=3

Gordon

[Reply #99 on:]

Yes it is analog pins 4 and 5.

Do you have pull-ups on those lines?

There is a schematic in the NB1A datasheet at http://www.wiblocks.com

(* jcl *)

Me again, had another few minutes to poke at this.

No pull up resistors on the data lines.

I think the wiring is correct however, because the sketch with no library worked great.

I tried the original DS1307 library next, it works great! Yea! I set the correct time and modified my alarm clock prototype to use the DS1337 breakout board using the DS1307 library. The only extra feature of the DS1337 that I care about really is the added precision, so I think this will work ok for now.

[Reply #100 on:]

Excuse me for the fuzzy picture. I verified the wiring with gordon's picture and it's exactly the same.

I think the arduino uses internal pull ups, because I can read the I²C data just fine. The only problem is that the time just isn't "ticking" at the right speed. The clock ran (still is running) after the weekends, and the date is correct, the time is off by approx 2,5 hours (in 3 days) so it has to be a crystal issue in my opinion..

I'll have another go with a new 32,768 kHz crystal today  

[Reply #101 on:]

These kinds of problems are why the DS3231 is so good. Even if you get the DS1307 crystal calibrated just right, when the room temperature changes by 10 degrees you'll be right back where you started. The DS3231 has a built in crystal and compensates for temperature changes.

I don't have any more ChronoDots for sale, but EMSL has them now.

[Reply #102 on:]

Temperature doesn't have that much effect.  I flew a random 32.768kHz crystal and a commercial (0C-70C) temperature rated DS1307 on a high altitude balloon, with only the self-heating from the 7805 regulator to keep the tiny package warm.  The DS1307 stopped reporting time via I2C when the temperature reached 0C, but the clock actually kept ticking and the system returned to normal behavior as it warmed back up, with no appreciable loss of time accuracy.

-j

[Reply #103 on:]

Yes, I'm pretty sure that the effect wouldn't be very noticeable over the course of an hour or two.

[Reply #104 on:]

Hi,
I run into strange problem with DS1307 as mentioned by many others.
My setup  uses SD-shield, DS18B20 sensors, LCD from Nokia3310, DS1307. All blocks worked fine separately and might going very badly in combinations. Then I foung that http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1222946089 thread, where it was suggested possible out of memory error. Then very helpful article http://itp.nyu.edu/~gpv206/2008/04/making_the_most_of_arduino_mem.html.
Suggestions from this article helped me to get all modules to work together.. except DS1307 It was last in the chain though..
Then I found function FreeRam() from fat16lib which I use for SD operations and started to play with it.
Some results are that:
- bare sketch (it just outputs FreeRam value in setup and loop) gives 836 bytes of free RAM (with ATmega168);
- + #include <Wire.h> leaves  814 bytes;
- + #include <DS1307.h> leaves 622 bytes.
So if with my current sketch which shows 170 bytes of free RAM I add include for DS1307.h it dies for sure.
Is not it too high price for one i2c device to take 200 bytes of RAM?
Especially in situation where I just want to get timestamp from it and store it on SD with other datas..