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
On Wednesday, 1 November 2023 at 11:10:02 UTC Nick Sargeant wrote: > 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. > > > > On Wednesday, 1 November 2023 at 10:14:25 UTC Richard Scales wrote: > >> 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 >> >> >> On Wednesday, 1 November 2023 at 09:22:03 UTC Richard Scales wrote: >> >>> 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 >>> >>> -- 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/e576bff1-8d65-4d53-b0cc-2ba5ba574232n%40googlegroups.com.
