Hi! That's started with a pb's form factor for the battery The ChronoDot ordered (v2.0) needed an little small battery than the (v2.1)'s version, as in SARPi's mini-project page! Got an idea: (as i've a tons of CR2032 cells here ), just ordered a socket for a battery cell and i'm happy with that choice!

Happy New Year guys!

ps: you don't need to put an hwclock -s in rc.local, all is done in rc.S.

Attached Thumbnails

     

Happy New Year.

I changed the CR1632 battery in my ChronoDot v2.1 about 11 months ago, which had lasted approx. 8 years from new. I consider this to be very good battery lifespan.

From looking at your images, what you've got is a "ChronoDor" which is a Chinese clone of the ChronoDot. Although I've never used the ChronoDor, it looks very similar to the ChronoDot and features a DS3231SN controller. I believe the ChronoDor uses a CR1220 battery and ChronoDot uses a CR1632 battery, which leads me to assume that the battery life on the ChronoDor may be somewhat similar to that on the ChronoPi. I doubt for most users the quality and accuracy of the ChronoDor will be of any concern. The important thing is that it's a RTC and does the job.

A good idea for a battery holder is a CR2032 breakout board which is also available with an on/off switch.

In '/etc/rc.d/rc.S' the hwclock if-then-else statements use 'hwclock --directisa' which is intended for ISA compatible machines such as x86, x86_64, and Alpha. For other machines it has no effect - see: 'man hwclock'. Users on the ARM platform may well find that they need to implement their own means and methods depending on their test-case parameters and hardware. Especially if (for example) a low quality or inaccurate RTC is being used that gains or loses several seconds per hour/day and the system has long uptimes and/or is not being (re)booted frequently. It's basically all down to each individual's requirements. Of course, '/etc/rc.d/rc.S' and '/etc/rc.d/rc.local' is only run at startup. The wonderful thing about Slackware is that it affords users the ability to do with it what they please and is ultimately configurable, and infinite in scope and possibilities.

Thanks for replying Exaga I'm surprised, didn't know about the existence of a chinese version.. And had a pb with a soldering point! Will check accuracy in time. Talking about hwclock, for you i should use hwclock -s in my rc.local? I forgot to say that i'm using the "dto" version's project. Good night

I very much doubt that the accuracy of the ChronoDor will be notably different from the ChronoDot, unless it's a bad one. I have quite a few RTCs using a cloned DS3231 controller and they've kept good time when I've tested them.

It's up to you what you do with rc.local or any other file(s), if anything. It's always prudent to do some testing and verify that the RTC is working as expected on (re)boot and then no further 'hwclock -s' commands are necessary. The ChronoDot RTC guide you mentioned to is 9 years old, was written for Slackware ARM 13.37/14.0, and still refers to a "disabling device-tree method", which I think is no longer used these days. So, the information in the guide is in need of a general overhaul.

Basically, with the ChronoDot (or any other DS3231 based I2C RTC) all that's required is to make sure it's wired up correctly and add or uncomment 'dtoverlay=i2c-rtc,ds3231' in the /boot/config.txt file, then reboot the system. Obviously users will need to consider their own setups and configurations in order to suit their requirements.

Ok Doc Exaga
hs: as you seen in my pics, i got the RBPi mouse but this one is not moving the cursor as expected under X.Org..
The move is not very reactive! I don't have this "pb" with a basic usb mouse (w/ my x86/x86_64 configs). Is the RBPi mouse a special device? Hope you understand

The Raspberry Pi mouse is nothing out of the ordinary or requires special drivers, as far as I am aware. Then again, I am not a desktop user on Slackware ARM, but on the few occasions when I have used Xfce a generic USB mouse has always worked as expected.

It could be that you just need to raise the mouse sensitivity or acceleration. You can do this from the system settings in KDE and in Xfce. The last step would be to create /edit the xserver configuration and tell the driver to increase those properties.

Ok mralk3