Flickering on Wemos Nixie display (IN-12 tubes.)

I agree that the scope trace looks glitchy. Ian is the only one with access to the schematic and source code for this particular model clock, so we really need to wait for him to have a look at this thread.

Some thoughts meanwhile:

I believe the digit drivers (the optos) are controlled by the parallel outputs of the 595 shift register. I'd expect the Wemos to be cranking out (serially - to the 595's serial input pin) the bit patterns needed to fire each digit driver in sequence (typical multiplex scheme). I'd further expect to see the Serial Clock (Pin 8) and Storage Clock (Pin 11) of the 595 being driven by the Wemos with something resembling consistent streams of pulses, with the Serial Clock running at ~8 times the rate of the Storage Clock.

The above is pure speculation based on what I can get from looking at the clock PCB in the assembly manual and the way I use 595s in my own designs.

It might be interesting to see what you can see with the scope on the aforementioned pins of the 595. Might help clarify whether the issue is with the 595, the Wemos or firmware.

74HC595 data sheet:
www.ti.com/lit/ds/symlink/sn74hc595.pdf

Also - make sure that 595's Output Enable (Pin 13) is in fact tied to ground and its Master Reset (Pin 10) is tied to +5. If either of those pins is noisy for whatever reason, anything could happen!

Hmmm that's a weird one.

In the Wemos clock we're forcing the controller into doing a LOT.

• It's keeping the display multiplexed: it does this around 100 times per second.
• It needs to do internal housekeeping to keep the Wifi going - this needs constant attention otherwise the connection to the network gets dropped.
• It needs to send an update to the LEDs - this is managed by hardware, but we still need to calculate the new values to send
• It needs to do all the other things a clock does, which frankly isn't that much in comparison to the display management

The output for the display is done with a single 8 bit write to the 595. 4 bits are used to say which display is on (through the optos) and the other 4 bits are used to drive the K155ID1. If during the process of writing out the display, we have a moment when the controller has to go and do something else, you can get a glitch. We schedule the housekeeping between digits, and the main clock running is done between impressions.

So, long introduction, but here's the point: If for any reason the WiFi needs more attention than usual, or the controller is running below spec, we can see problems like this.

First of all, go to the summary page and make sure that the Wemos is clocked at 160MHz. If it is running at 80, we won't get the housekeeping tasks done on schedule.

Secondly, is your WiFi signal strong? Are you maybe in an area with a lot of other WiFi networks? If the airwaves are crowded, the management of the signal needs more time than usual.

If it persists, I'll have a look at re-organising the code a bit. I have learnt a lot recently about the ESP, and there's always the possibility to improve.

@Ian - Looks like Bob has what's needed to load code into a Wemos, so how about sending him a binary of a substantially older firmware rev? Perhaps he can load it up and let us know if there is any difference.

If the code is to blame, why has nobody else reported this problem?

@Bob - Just to be sure: you did test the Serial Clock and Storage Clock pins, as well as the Output Enable and Master Reset pins, right? I was really expecting one or both of the clock lines to be unstable as that would be consistent with the busy CPU latency scenario Ian described.

So how do we get missing (or late?) bits in the 595 without missing or late clocks? Hmm. I'm pretty sure (?) the routine that writes out the 8 bits isn't in an interrupt handler so I don't see how it could get skipped. Could there be noise on the serial data line to the 595? Just thinking out loud here.