Multiplexing Displays

[Richard Scales]

The time has come when I need to get a handle the dark and mysterious art of multiplexing.

I have an understanding of what needs to happen though am mostly at a loss of how to implement it.

I am broadly assuming that I should be using some kind of interrupt routine to make the actual display work whilst the rest of the code gets on with the job of working out what to display and when to display it.

Is it even going to be feasible to have some kind of interrupt routine that decides what digits to light - set all the bits and then sets the right anode(s) on and then off again giving enough time for the persistence of vision to produce a non flickering display when using something like a wemos D1?

I am thinking that the interrupt routine needs to increment which digit(s) is/are being illuminated - set up the right bit pattern for the cathodes and turn on the relevant anode(s) - wait a little and then turn them off again.

My worry is that the amount of time that the displays should be left on might be a little too long for the ISR as my understanding is that these should be kept as lean as possible.

Do I even need multiple interrupts (my covid addled brain is struggling to type let alone contemplate multiple ISR's!)?

Can the rest of my code run in a non time critical manner as it works out what it wants to display where whilst the interrupt routine merryly illuminates digits based on values which I store in a buffer somewhere?

... or does the rest of my code have to work in come kind of state-machine fashion?

I would expect (hope) to handle display brightness via PWM signals to HV Drivers. 
I have no need for cross fade effects either - just basic multiplexing of say 10 different multi segment displays. I am more than happy to break up the displays into say 2 (or more) groups in order to makes things a little easier.

Can anyone point me in the right direction - ideally with some code snippets that I can use as a foundation?

Just to confirm, it is only the general implementation  to drive the displays that eludes me - the rest of the clock code is well defined and working well in a direct drive capacity.

The desire to move to multiplexed operation is born out the the desire to drive a greater number of displays with a greater number of segments which could be done via direct drive but I foresee that multiplexing the displays will simplify the electronics required.

So many questions I know. I would be grateful for any pointers, thank you.

 - Richard

[Richard Scales]

Actually - I just looked through an example over at: https://www.hackster.io/doug-domke/multiplexed-nixie-tube-clock-759ff5

... and it all seems fairly understandable, have I overthought this?

 - Richard

[Nick Sargeant]

Hi, 

It’s not difficult. My fumbling attempts at a Nixie clock some time ago used a 4:1 multiplex ratio, using four digits and only one decoder. I used the same MPSA42/MPSA92 driver as your example. My multiplex function was called at 100Hz, so each digit was refreshing at 25Hz. It doesn’t flicker, and (whoa!) it is working 15 years later. 

The only mod I had was when switching between digits, I turned the cathode drive off for a period of 20 microseconds, before selecting the correct anode and turning on the next digit. This helped prevent ghosting. 

[Richard Scales]

Many thanks Nick. 

Unless anything else comes to light I think I will forge ahead on that basis. I want to drive 15 segment panaplex displays (16 including the DP) so plan to use HV5530 or similar driver for the segments, probably two of them. Then the same MPSA42/MPSA92 driver arrangement for the HV though there are going to be 5 of those - I might be running low on pins it using a Wemos - I might consider a port expander for the extra pins needed - I need to check pins required - I think 4 for the HV register chain, 6 for the Anode switching (two drivers driving a 12 digit device - perhaps 5 for a 10 digit device) plus I want to read a PIR and talk to a BMP-280 sensor. Certainly a Wemos + port expander would do it - might get away with a Node MCU or similar.
OK, I just realised that I can use a single 32 bit driver  with two sets of 16 bits, one going to each bank of displays.
It still has the same pin requirements of the processor I think. That will be a juggling excersise!

 - Richard

[David Pye]

Hi,

I offer you one caution with the ESP8266 boards - almost everything is implemented in the libraries in software rather than onchip hw. 

That means doing things like updating addressable LEDs can cause the multiplexing to glitch slightly because of the need to send LED data at strict timings.   (Or, if you sacrifice led timings to run your multiplex interrupt routine, it can glitch the LEDs.  ).  Chips which have DMA/more complex peripherals might avoid this.

You might get away with it with certain combinations of things but it was a bit of a pain for me.

David

--
You received this message because you are subscribed to the Google Groups "neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neonixie-l+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/e576bff1-8d65-4d53-b0cc-2ba5ba574232n%40googlegroups.com.

[Paul Andrews]

Hi Richard,

Remember that the Microchip chips (HV5530 etc.) are just high voltage port expanders. You can use them to control the MPSA42/MPSA92 transistors too, so assign a bunch of their pins to the cathodes and some to the anodes. Slight wrinkle is that that specific chip is open-drain, so you might need a pull-up on the MPSA42 base, not sure, I would have to check my circuit.

[Benoit Tourret]

Hello, 

if an ESP8266 is not enough powerful, the ESP32 will do the job.

the ESP_WROVER can be a good platfom.

you should have a look to Mose's work on https://neonixie.com/Z57XM6DV2/

the code is a bit "strong" as it can be used both on an 6 IV-9 clock and a more traditional  6 digits Z57, superb clocks, all they need is addressable LEDs for a more colorful background. and deactivable.

the BH1750 luxmeter does a great job and is more sensible than a standard photoresistor.

[Richard Scales]

@David - many thanks for that caution though there will not be (nor ever will there be!) any LEDS for this project!

@Pauld - thank you - I had thought of that but I was endeavouring to keep the code inside the ISR to an absolute minimum so thought that it would be best handled outside of it and hence separate from the HV chain. Using SPI.Transfer  to send 32, 64 or 96 bits - I guess it all happens fairly quickly!

@Benoit - I will look at that - ESP32 - another bridge thus far uncrossed!

 - Richard

[Richard Scales]

@Paul - I have no idea of the sense of scale and the relative times taken. If I were to hang another HV driver on the chain with associated electronics to switch the HV, is there going to be enough time to do the following:

Set the bits for the segments required- I add this step just in case any settling time might be be required

Set the bits for the segments required and the anode(s) on

Wait for 400us (typical on time for the panaplex segments I have in mind

Set the digits and anode(s) off again
Loop to the next set of digits

With 12 individual anodes - there would be 12 passes - one for each anode that needed to be switched on

If I used 2 drivers (using 3 x 16 bits for cathodes, I could use bits from the remaining 16 to control the anodes. Thus there would be only 3 passes.

Please stop me when I've gone off the scent (still mid-covid) :-(

In Summary:

Using the HV55xx for cathodes AND anodes

Given i want 12 characters:

with 1 driver I have 16 segments and 16 spare for the 12 anodes - easy but slowest

with 2 drivers I have 3 lots of 16 segments and then group the displays into lumps of 4 (12 characters/3) and still have 16 bits to control the anodes, of which there will now only be 3)

Am I anywhere near close with the driver split and the pseudocode for the ISR?

I was thinking that there should be some uS delays either before and/or after lighting the segments

- Richard

[Richard Scales]

@David - I should have said - I'm not against LEDs and Nixies in any way - just not for this project - it is for panaplex displays which don't really lend themselves to backlighting - though I have done something recently with FFD21 Minitrons (which are equally opaque) by using side facing leds under the minitrons.

 - Richard

[Paul Andrews]

Well you don't wait in an ISR, so in the ISR it is really just:

- figure out what bits to set

- set them

- figure out when you next want the ISR to trigger

- arrange for that to happen

I've only ever set 64 bits in an ISR so I've no idea if it would break if I tried to set more, but make sure you use SPI to do it. If you are doing your own bit-twiddling, don't use the arduino functions, they have a lot of overhead. If you can't use SPI (so you have to do your own bit twiddling) you can get the important stuff from the arduino functions and write your own methods to do it without all the overhead, but really your circuit should be designed so that you can use SPI.

[gregebert]

Multiplexing might not be possible in certain software environments. Several years ago I switched to Linux-based Raspberry Pi systems in my projects, and with the unpredictable overhead of Linux I cant rely on the CPU being available every millisecond to update the display. Instead of using Arduino or a custom OS, I add an FPGA or CPLD to handle the time- critical tasks.

Just by coincidence, I'm putting the final touches on the software and RTL code for a board I recently had fabbed to do this. I know it's blasphemy, but the first project using this is LED-based...I got a bunch of large 8x8 red/green LED arrays for just under 1 USD apiece and the need a multiplexed driver. Dont worry, there are several nixie and nixie-ish projects in the pipeline that will use this board.

[Craig Garnett]

I'm using a Pico in my project, I run the tube driving routine on one core and everything else on the rest so it doesn't suffer from slowdowns.

I've had to introduce a delay to slow it down to a 1ms refresh!

Craig

[Richard Scales]

Dual Core Processors - now my head really hurts - I mean - I love the idea but don't think my programming skills are ever going to stretch that far!
Just woke early (03.13) - still full of Covid and had a wrestles thinking session on this during which I reminded myself of all the success that I have had with B-7971/ZM1350 Smart sockets - can you see where this might be going?

 - Richard

[gregebert]

Where it all leads to, I think, is that you no longer need to do custom logic design, and you can skip the need for certain ICs such as realtime clocks, by switching to a software-based design, whether it's RasPi, Arduino, or any other embedded controller.

It's gotten so "bad" that I rarely need to use a scope or logic analyzer to hunt down a bug. Several years ago I literally logged-in remotely to the RasPi controlling my NIMO clock and did quite a bit of software development and debug from thousands of miles away.

Even now, I'm too lazy to get out of my chair, and go out into the chilly garage to work on my Pi+FPGA board. Instead, I will write a new test and run/debug logic simulations rather than push new (untested) code onto the FPGA to see if it works.

[Mike Mitchell]

My most recent Nixie project uses ZM1032 tubes.  They are a 9-pin tube, with five cathode pins and two anodes.  I'm using direct-drive on all the cathodes, but skimp on the tens-of-hours digit where I only drive three cathodes instead of all five.  I'm using four SN75468 darlington arrays to drive the cathodes and two opto-isolators to drive the anodes, multiplexing the anodes as all evens and all odds.

I'm using a Teensy 4.1 processor to control everything, though I could have used an ESP32.  I just wanted something with a lot of pins to handle driving the 28 cathodes.  I'm not using a timing interrupt at all. In the main loop I use the built-in arduino "micros()" call to keep track of the time and compare it to the time of the next event.  I use a state variable to keep track of what to do next.  Here's some pseudo code:

if (long)(micros() - timeNextDisp) >= 0 {
  switch(dispstate) {
    case DISP_DELAY_EVEN:
      timeNextDisp = micros() + 200
      turn off all anodes, turn on all cathodes
      dispstate = DISP_EVEN
      break;
    case DISP_EVEN:
      timeNextDisp = micros() + disp_even_time

      turn off all cathodes

      turn on appropriate cathodes

      turn on even anode
      dispstate = DISP_DELAY_ODD
      /* split work between even/odd anodes */
      read PIR

      read GPS
      break;
    case DISP_DELAY_ODD:
      timeNextDisp = micros() + 200

      turn off all anodes, turn on all cathodes
      dispstate = DISP_EVEN
      break;
    case DISP_ODD:
      timeNextDisp = micros() + disp_odd_time
      turn off all cathodes

      turn on appropriate cathodes

      turn on odd anode
      dispstate = DISP_DELAY_EVEN
      /* split work between even/odd anodes */
      read RTC
      read ADC
      calculate time display values
      break;

}

In my case the even digits are behind a screen electrode which blocks their light.  I keep the even digits on for about twice as long as the odd digits to even out the brightness.  I could have increased the even digit's current by reducing the even's anode resistor, but I decided to keep the current the same for even/odd and just increase the "on" time.  My timings are roughly 10.1ms on for even, 0.2 ms for dead time, 5.1ms on for odd, 0.2 ms dead time, for 15.625 ms per cycle (64 times a second).

A more typical multiplexing scheme could have two state variables, one selects either displaying a digit or discharging the tube, the other selects what tube to display.

[Richard Scales]

@Mike, many thanks.

I'll work through that.

 - Richard

[Richard Scales]

@Mike

So, I have been getting my head around the whole state-machine concept. I have one I did before - curiously also running on  a Teensy but that was because I was worried about speed (I had no idea!).
Regardless.

Here is what I think my state-machine might look like:

Set State to 'Turn Off Displays'

:Main program loop

If state = 'Turn off Displays' then turn off all the anodes and change state to 'Delay before turn on'

//This state exists to allow the injection of any required delay between display of each digit / group of digits 

if state = 'Delay before turn on' then if there there has been sufficient delay, change state to 'Turn on desired display'

//This state works out which cathodes and anodes to set and turns them on

if state = 'Turn on desired display' then set the required cathodes and anodes and turn them on and change state to 'Display is on'

//This state works out whether the display has been on long enough

if state = 'Display is on' then has it been on long enough? If so, change state to 'Turn off Displays'

Rest of clock code goes here - and by that I mean the business of working out what to display be it time, date, temp, pressure etc.

Obviously everything must be non-blocking so if I want to do fancy things like scrolling messages then I assume that I will need to introduce more 'states' to control all that

:End of main program loop

I think this differs from yours in as much as I have lumped all the 'rest of clock code' into one place on the basis that it should not be blocking anything and execute quickly.

Is this at all wise?

 - Richard

[Mike Mitchell]

That's basically what I'm doing for my simple case.  The upkeep work is done after tubes are energized, where I have significantly more time before the next event.  The off time is only 200us so I don't do anything during the off time.  With the fast processors of today you could do "quick" things in the off time, but any complex computation I'd put in the longer on time.  I'm using the FastLED module to drive a short string of LEDs during my "DISP_EVEN" time, but calculate what to put into the LEDs in the "DISP_ODD" time.

[Richard Scales]

@Mike - many thanks - I think I'm getting it.

 - Richard

[David Pye]

Hi,

Next time I do a clock, I am going to separate my hw into 2:

A cheap ARM based MCU using SPI/DMA to do multiplexing and dimming, with enough IO to drive anodes and cathodes via individual transistors, with Comms to the main MCU via spi or i2c.

An esp32 or esp8266 to provide application logic

Using the ARM MCU and transistors solves the issues with the HV driver ICs needing 9v and both the STM32 and the esp8266 can communicate with 3v3 signal levels and will be cheaper albeit with higher component count.

David

To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/1bc508d5-1f0c-4b6e-af2f-3f9a0092ecc6n%40googlegroups.com.

[Richard Scales]

@ David - that is an interesting idea - I did that already in another design  where I wanted to reduce the workload on an ESP8266 so I used a Teensy running a state machine based piece of code to do the heavy lifting - the ESP8266 just fed data to the Teensy over a serial connection - I kid you not - it works really well - though that is all running a lot slower than what I need for this multiplexed display project.
I am actually hoping to do it all on ESP8266 this time round with a couple of 595's driven via SPI transfers and some state-machine based code which manages the display.

The next part of my planning is to gain the understanding of what delays are required and where.

I am broadly assuming that I need to do things in the following order:

{

Set the cathodes for the number to be displayed

Delay before turning on anode

Set the desired anode on

Wait for the desired 'anode on' time

Set the anode off

Wait for the desired 'anode off ' time

Increment the current anode number (reset to 0 if we got past the max)

}

In this way, the anode on and off times can be set - thus controlling fading etc

My next question is - do I need to wait at all after setting the cathodes up and before turning the required anode on?

For the hardware I was thinking that one of the 595's would connect to low sided drivers (MPSA42 etc) to ground the required cathodes whilst the other 595 would connect to high sided drivers (MPSA42+MPSA92 etc) to connect the desired anode to the HV supply.

I was then thinking that all anodes and cathodes would connect to something like 80V via a suitable resistance - as per the Bally schematic for driving multiplexed panaplex displays in pinball machines.

As detailed here: bally_as2518_15_6digit.pdf (pinitech.com)

Am I anywhere near the right track on any of this?

- Richard

[Jon]

>For the hardware I was thinking that one of the 595's would connect to low sided drivers (MPSA42 etc) to ground the required cathodes whilst the other 595 would connect to high sided drivers (MPSA42+MPSA92 etc) to connect the >desired anode to the HV supply

Yes, that approach works really well. See this clock from a few years back: https://youtu.be/4FnxWsp58EM

Each six tube row is a 2 x 3 multiplex controlled by a pair of 595s driving discrete transistor high-side drivers for the anodes, low side drivers for the decimal points and a pair of Russian K155ID1 (near equivalents of the 141) to decode and low side drive the digits. The K155ID1 route was chosen instead of a regular logic decoder and discrete low side drivers to save board space without getting into lots of fiddly SMD stuff. And then each of the seven rows simply have their pairs of 595s hooked up to make a 14 device total daisychain that controls the whole display. There's a single PIC18 running the show which bit blasts display refreshes down the daisychain  as well as managing USB comms, talking to a DS3232 RTC - plenty of compute time and power to do that. The nice thing is that this approach reduces all the display composition and management to software - multiplexing, cross-fading, all the funky display animations shown in the video; it's all just a matter of figuring out what bits to set when in the 144 bit output stream. Took me right back to my programming roots writing for bit-mapped displays on 8 bit micros in the early 80s! :)

Jon.

[Richard Scales]

Very nice work - a lot more sophisticated than I dare to dream to achieve!

 - Richard

[gregebert]

I took a similar approach on my designs. Nowadays, all of my projects are based on the Raspberry Pi (specifically, the Pi Zero W because of it's low-cost and integrated WiFi). In some cases, the Pi lacks horsepower for timing-critical needs, so I have an FPGA adaptor PCB that bolts an Altera FPGA onto the Pi, so the FPGA can be controlled by software and also run it's autonomous hardware tasks in hardware at high speed.

Now that I'm retired and on a fixed income, keeping the PCBs below 100mm x 100mm is a priority so I can fab them very cheap at PCBWay. It was a bit of work to get the hardware and software infrastructure in-place, but now that I have completed it, projects are moving again.

[Nicholas Stock]

The Niximatrix is a sight to behold!! I must dig mine out....... Do you have any more kits Jon?

Nick

To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/2edcc2a6-37e5-44db-ae77-ce3a4286aa63n%40googlegroups.com.

[Jon]

Nothing like the Niximatrix for lighting up a whole room in lovely neon! Well, apart from Dalibor's H tube installation of course, but that's in a different league to everything :)

Yes, if people have the interest (and the tubes and sockets!), I should have the PCBs and components for at least a couple of Niximatrix kits without getting into a major reorder. Don't think I've got any of the acrylic front and back panels lying around, but that should just be a matter of getting some lasered up if needed.

Jon.

[martin martin]

very cool

I may need one

~

mcve...@gmail.com

To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/1b79f48b-e932-468f-ba64-cdc0f00ad175n%40googlegroups.com.