next topic »

[Reply #15 on:]

Thanks for the info. The DS1302 doesn't have the SQW output that the DS1307 has, otherwise it might have done. I was planning to feed the 1Hz output from SQW to timer/counter2 in order to wake the Arduino from sleep mode every 20 or 30 seconds.

Any other DIP options?

[Reply #16 on:]

but SOIC package only it seems. I have a project where I really want to avoid using SM devices as other people will be building them.

Not that I know of. For what its worth I finally caved because more and more parts are SMD only. I use these to prototype

http://www.futurlec.com/SMD_Adapters.shtml

and find that the drag method of soldering SM parts works well once you get the hang of it, even on finer pitch parts like the SSOP FT232RL.

The other thing you can do is buy a presoldered DS3231 like the Chronodot,

http://macetech.com/store/index.php?main_page=product_info&products_id=8

Good luck!

[Reply #17 on:]

The DS3231 is easier to solder than you think...most of the pins are connected to ground. So much good stuff comes in SOIC and smaller, that I think any serious electronics experimenter should have some SMT breakouts and be able to do drag soldering. I actually prefer SMT to through-hole for hand assembly.

[Reply #18 on:]

"I was planning to feed the 1Hz output from SQW to timer/counter2 in order to wake the Arduino from sleep mode every 20 or 30 seconds."

Won't that wake it every second? Or will you increment a counter every time, and when high enough, then do something?

[Reply #19 on:]

"I was planning to feed the 1Hz output from SQW to timer/counter2 in order to wake the Arduino from sleep mode every 20 or 30 seconds."

Won't that wake it every second? Or will you increment a counter every time, and when high enough, then do something?

The latter, it should wake it up whenever the counter reaches a pre-determined value (not overflow). I've not actually tested it waking from sleep but I have successfully tested it generating interrupts. I recently added some examples of how to do this on my Calunium board to the Calunium github repository: https://github.com/stevemarple/Calunium/tree/master/software/examples
The examples can probably be made to work on your Bobuino board with just a change on pin number.

Idea: if the Arduino environment had a mapping (in pins_arduino.h) from pin function to pin number then the same sketch would work unchanged on your Bobuino, my Calunium and maniacbug's Mighty-1284P. Something like

Code:

#define PIN_TC2 15

[Reply #20 on:]

The DS3231 is easier to solder than you think...most of the pins are connected to ground. So much good stuff comes in SOIC and smaller, that I think any serious electronics experimenter should have some SMT breakouts and be able to do drag soldering. I actually prefer SMT to through-hole for hand assembly.

I agree with you about being able to do SM soldering, and it isn't a worry for me - the last PCB I designed and built was almost entirely SM; SD card, 3 SOIC and various 1206 resistors and capacitors too. However, a vast proportion of the target audience for this project is likely to have very little soldering experience. To paraphrase Stephen Hawking's editor, "for every SM device the potential audience is halved".

[Reply #21 on:]

That's why I pre-assemble pretty much everything I sell. 

[Reply #22 on:]

I just used the mcp79410 and it has a calibration register to adjust up to +/- 125 ppm, maybe the ds has a similiar thing?

[Reply #23 on:]

I don't think it has that capability built in, but it does have a small amount of NV RAM and I reckon I can store the last calibration time there across power downs, then each time it wakes apply the required correction based on previously measured drift/day, current time and time since calibration.

Required correction would need to be recalculated regularly while the clock is awake, say every 5 mins. Sure its based on an assumption of linear drift over time which is clearly imperfect, but I reckon this method could produce a significant improvement nevertheless.

[Reply #24 on:]

If anyone is interested in substantially improving the accuracy of the time from their DS1307 RTC I've come up with some coding that improves accuracy from (typically) 5 - 10 seconds lost per day to maybe a couple of seconds a week or better. The basic idea is:

1) monitor your RTC for a few days against a trustworthy clock such as here: http://time.is/Adelaide.

2) work out how many milliseconds you loose (or gain) per hour. This is 'drift_ms_hour' in my sketch which stores this in NVRAM on the RTC itself (it has 56 bytes of NVRAM)

3) manually set/sync the time on the RTC to be as close as you can get it to UTC (say < 1 sec off) and write down exactly this time, to the second and it's equivalent time_t value (seconds since 1 Jan 1970 or whatever it is). This is called timeWhenSet and is also stored in NVRAM.

4) Every time the sketch starts it reads timeWhenSet and drift_ms_hour from NVRAM, prints them, reads the (uncorrected) time from the RTC, and calculates how many seconds to add/subtract based on the drift_ms_hour characteric for this particular RTC. This corrected time is calculated every second from then on.

The sketch is attached as a ZIP (too large to paste in) most of which is plagiarised from others who really know how to code (like kurt's excellent scooterputer) but I'll claim the glory for the drift reduction functionality  

(Apologies for all the PROGMEM gymnastics in this sketch, it's stripped down from another sketch where I was having problems with SRAM overflowing and need to move all the strings into flash memory, and basically I'm too lazy to convert the strings back)

Sure I could solve this by buying an upmarket RTC llike the DS3231, but this technique does same job, is free , and was fun to get working