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

More
1 month 3 weeks ago #11314 by Ty_Eeberfest
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

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

More
1 month 3 weeks ago #11315 by Ty_Eeberfest
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!

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

More
1 month 3 weeks ago #11316 by Ian
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.

Please Log in or Create an account to join the conversation.

More
1 month 3 weeks ago #11317 by BobM
Thank you Ian for taking the time to look at my post. I can confirm that the Wemos clock is running at 160MHz - at least according to the summary webpage.
I live out in "the sticks" so not too many WiFi signals to cause me problems. The clock is currently about 4m from an access point so the signal is very strong. If there's any other information I can supply you with Ian please let me know.

Apart from this one thing I'm really pleased with the clock. It functions perfectly in all other respects.

Please Log in or Create an account to join the conversation.

More
1 month 3 weeks ago - 1 month 3 weeks ago #11318 by BobM
@Ty_Eeberfest

I've had a look at the pins you mention and, as far as I can tell, all appears to be OK. I've changed both the 595 and the Wemos. Unfortunately the problem remains the same.
Last edit: 1 month 3 weeks ago by BobM.

Please Log in or Create an account to join the conversation.

More
1 month 3 weeks ago #11319 by Ty_Eeberfest
@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.

Look into it later when the dust is clearing off the crater.

Please Log in or Create an account to join the conversation.

Time to create page: 0.168 seconds

Search

Tube Suppliers

Go to top
JSN Boot template designed by JoomlaShine.com