SMD Version

[balzreber]

Hello liebman

I'm currently in the final stages of finishing an SMD version of your awesome AnalogClock.
I only use JLCPCB components, so the board should be orderable from there, almost fully assembled.
The current version is a 1:1 replica of your design.
I think I could make the design even simpler, and therefore smaller. But I have some questions for you about that.
Of course, I will share my design once it is finished.

(Image is wip)

[balzreber]

I finished the board. It's now 100% JLCPCB parts, including THT. So the board can be ordered fully assembled.
I got the footprint down to 70mm x 40mm.
I'm just waiting for a missing part to arrive at JLCPCB. As soon as that happens, I will place my order.
By now I pretty much found out what I needed to know by myself.
I plan to spit off my board into a separate reopo. I know I'm technicaly allowed to do that, due to this project running on an Apache 2.0 license. But it would be nice nevertheless to get an okay from liebman?! Maybe he could even reference my repo in the readme of this project?
I will create my repo after I'm able to get my board, so I can be sure that there are no errors.
I will post updates here until then.

[liebman]

This looks really nice! The only potential issue I see is programming the AtTiny85v, have you considered how your going to manage that? (will JLCPCB program them before assembly?)

[balzreber]

Good point. My idea was to program it "in-circuit". Something like in the image below.
Or do you see any circuit limitation that would prevent this?

[liebman]

It may work for the initial programming but after the fuses are set the reset pin will be disabled (its turned into a GPIO to detect power fail)

[liebman]

You will want to insure that programming is done at 3.3v (does that work?) or you will put 5v on some of the ESP8266 IO pins (SDA/SCL). Also possible issues with the RTC seeing signals on its pins while unpowered.

[balzreber]

I see what you mean. I think I will add some dip switches to completely isolate the attiny85 just for programming. Thanks for your thoughts on this @liebman

[liebman]

maybe it would be smaller to switch to THT for the attiny and socket it? This is why I went with THT for it. Made it easier to pop out and use an HV programer to reset the fuses so it could be programmed again.

[balzreber]

That is a good idea. I didn't want to do that, so you can order the board fully assembled. And I don't think JLCPCB will socket the chip for me. Neither will they deliver it as a loose part. But since you need to order an Attiny programming board separately anyways, you may as well order the chip with that.
I will be back with a modified design.
Thank you so much for your help @liebman. As you probably noticed, I'm not an electronics engineer ;-)

[balzreber]

By the way, Is that okay with you @liebman ?

[alteredz]

Once this board design is finalized, I'd like to purchase a couple.
I'd prefer getting them with the chip already programmed.
Thanks, Pete

[liebman]

@balzreber I'm fine with that labeling.

Some assembly houses can pre-program MCUs as part of assembly, you may want to see if thats possible in this case. If so then you can put some SMD jumpers on the traces that lead to the attiny, that way if you needed to re-program it a second time you could cut these, program, and then solder bridge the cut.

Also the one thing that I found most difficult was finding clock movements that were easy to modify - and tuning the exact pulse timing and pwm level was a real challenge. I'll look later to find where I ordered these from.

[balzreber]

@alteredz I was talking to JLCPCB about that. They told me that they could theoretically do that. But they would have to look at the exact schematics to confirm (they do in-circuit programming, not pre-programing). And of course, it costs extra. And since they have to involve some engineers, the markup will be significant!
I'm currently changing the design to have a socketed Attiny. You can then buy a USB programming adapter (like the one in the image a few posts further up) and program the Attiny with that. It should be pretty much plug-and-play.
Of course, you can talk to JLCPCB yourself, I didn't ask for the exact price. And of course, you can order the same board from other manufacturers. It's just that my BOM will have JLCPCB part numbers in it. So you would need to change that.

@liebman thanks for the hint! I'm living in Switzerland. The home of clocks. So I hope I can get some good clockworks here :-)) But I would appreciate you looking up which ones you used nevertheless ;-) Thanks

[liebman]

I noticed that the blog link was broken - I've just updated it - it will provide a lot of info about the design. https://blog.taboola.com/analog-clocks-ntp/

[liebman]

This is what I had the best success with https://www.klockit.com/all-departments/quartz-clock-movements/quartexr-push-on-quartz-clock-movement-threaded.html

[balzreber]

@liebman Thanks for the additional info!

In the meantime, I modified the design to have a socketed Attiny85. Still waiting for the missing JLCPCB part.
I will keep you guys up to date on further progress.

[liebman]

You should switch C4 to a multilayer ceramic one like this

[balzreber]

Okay, will do that. You had an Alu as C4 in your assembly pics, that's why I have chosen one as well.

Those are the rest of the relevant components. I remember that I had to "upgrade" C6 to 680uF due to availability.
Do you mind having a look over those and tell me if you see any other problems?

Pretty much all standard 0805 250mW film resistors

The capacitors. Will change C4 to ceramic.

RTC

D2 Diode

Voltage Regulator. That's the one I'm waiting to arrive at JLCPCB

The Attiny is a Attiny85V-10PU like I read in your blog.

And sorry @liebman I didn't want to pull you in this this deep. But I totally don't mind if you are willing to help ;-)

[liebman]

C2 - the one you have is 6.3V - thats cutting it close (4AA batteries is ~6v) I'd choose one with a higher voltage rating to be safe - the others are ok.

[balzreber]

Will change that.
And thanks man, I really appreciate your help!

[balzreber]

Alright. I updated the design again. C4 is now ceramic and C2 is 16V.

(I know the Attiny looks like a chip here. That's only the JLCPCB 3d model. It is a socket)

Still waiting for the Voltage Regulator to arrive.

[balzreber]

I finally got the boards 🥳

ESP and Attiny are programmed. Worked like a charm.
The only thing is that the clock I connected is only jittering. But I guess, as @liebman said here #24 (comment), this is only a problem with the correct tick pulse and duty settings.
Otherwise, everything seems to work as planned so far.
I will make sure to post updates on any further progress.
As soon as I can confirm that the board is working properly and has no errors, I will create my own repository with all the production files.

[balzreber]

I did some measuring today.

This is the clock movement I'm using @10ms / 500mV:

This is the output of the board (with default parameters) @10ms / 500mV:

And with higher resolution @500us / 1V:

@liebman Is it normal that the board output is not a single pulse like the clock itself? Or is there something wrong with the board?

PS: I tried with two boards and had exactly the same results.

[balzreber]

After some playing around, I totally got it to work 🥳
In the end, I only had to crank up the tp_duty and ap_duty parameters from 45 to 100.

I used a super cheap Ikea clock for this.

[liebman]

How many battery cells does your clock use? All of mine are single cell (1.5V) and none of the clocks I had responded well to 100% duty cycle tick pulse (tp_duty) and adjust pulse (ap_duty). The symptoms as I recall were missed ticks and randomly starting to tick backwards. I also found that the settings varied between brands.

100% duty @ ~ 3v is twice the power delivered to the clock movement per pulse than via the 1.5V battery cell in my case.

[balzreber]

At the moment I'm using 5V directly from a power supply.

I don't get it. Isn't there always the same power delivered to the clock movement?
Isn't the output of the voltage regulator always the same, no matter the input (as long as it is in the allowed input range specified)?
On my oscilloscope, the pulse always looks the same, no matter if I deliver 4V or 6V.
Am I missing something here?

I only tested with the cheap Ikea clock movement at the moment. But there are other clock movements ordered and on the way. I will do more testing as soon as they arrive.

[balzreber]

I'm sorry. I know what you mean now.
You are only speaking of the duty setting which varies the output to the clock.
And you are right. The clock itself only uses one 1.5V cell.
The thing is, if I set the duty to 50 the clock handle only jitters. It starts moving at about 85.

[liebman]

have you tried varying the pulse width? It takes time for the clock movement to move to the next position and to settle.

[balzreber]

I have done that. But I was only playing around with the values.
I will do a methodical test series with multiple clock movements today. I will post the results here.

In the meantime. I finally got the rsyslog to work.
And I noticed that the clock is unable to sync with NTP.
I always get:

...
2023-09-08T07:43:27.308976+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 93.580266 I setup syncing RTC from NTP!
2023-09-08T07:43:27.325574+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 93.596183 I setRTCfromNTP using server: 0.zoddotcom.pool.ntp.org
2023-09-08T07:43:27.958741+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 94.227662 I NTP ::getOffset: NEW server: 0.zoddotcom.pool.ntp.org address: 156.106.214.48
2023-09-08T07:43:29.300346+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 95.573045 E UDPWrapper ::recv: failed wanted:48 != size:0
2023-09-08T07:43:29.322768+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 95.592012 I NTP ::makeRequest: used server: 0.zoddotcom.pool.ntp.org address: 156.106.214.48
2023-09-08T07:43:29.341810+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 95.614876 I NTP ::makeRequest: packet size: 0
2023-09-08T07:43:29.358791+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 95.631535 I NTP ::makeRequest: duration 1019ms
2023-09-08T07:43:29.372336+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 95.648377 E NTP ::makeRequest: bad packet!
2023-09-08T07:43:29.392327+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 95.664632 E NTP ::getOffset: makeRequest returns: -1
2023-09-08T07:43:29.406109+02:00 esp-acd0de.local SynchroClock: 00acd0de 1.1.12-la[0]: 95.682326 W setRTCfromNTP NTP Failed!
...

I tried multiple different NTP Servers. No luck.

EDIT: I set up my own NTP server. Now it's working. So the previous problem seemed to be a network issue.

[liebman]

I was going to ask, but can't see it from the board pictures, did you put a keep-out zone under the ESP12's antenna?

[balzreber]

I have done that, yes. The area under the antenna is where the label is.

Sorry I didn't post measurements yet. I got hung up on another project. But I will be back soon with more...

[balzreber]

So I tested a. bunch of clock movements. Everything seems to work just fine. I can set the clock with no problems. With duty cycles around 90.

There are two problems remaining:

1.) The clock resets to captive portal once I recycle power. So I have to set the wifi every time I take the clock off power. But I think this is a software issue. Since all the parameters are saved on power loss. Or is this some strange reset happening because of hardware?

2.) I can't get the clocks to tick in unicent. They are around half a second off. Am I hitting the limits of the design, or is it possible to get the seconds closer?

What do you think @liebman?

[liebman]

Sorry for the delay, I've been busy moving. Are you still using a local NTP server? Also it may take some time for the clocks to compensate for network latency - run them for a few days and see if the times don't sync better. I had 4 clocks all synced in an office I worked in previously.

[balzreber]

No worries.
Yes, I'm still using a local NTP. But that shouldn't matter, right?

I'm currently building my third clock. As soon as that is finished, I will let them all run for some days and see what happens. Thanks for the advice!

What do you think about the wifi reconnecting problem? If that is indeed software, I think I can release the SMD board files. The rest seems to work like a charm.

[liebman]

The wifi re-connect could be either - you will need to capture the serial output to analyze this.

[balzreber]

Alright. I will do some more debugging.
You never had this problem? (Which would point more to a hardware issue).

[liebman]

Not that I recall.

[maxlyth]

@balzreber Did the SMD files get finalised? Your version of the repo seems empty.