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.
On Wednesday, November 1, 2023 at 7:54:43 AM UTC-4 Richard Scales wrote: > 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/b404abb6-c45d-4aa6-9614-cbab8209f5ccn%40googlegroups.com.
