@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
On Wednesday, 1 November 2023 at 15:19:48 UTC Richard Scales wrote: > @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 > > > On Wednesday, 1 November 2023 at 15:01:20 UTC Richard Scales wrote: > >> @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 >> >> >> On Wednesday, 1 November 2023 at 14:54:53 UTC Benoit Tourret wrote: >> >>> 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. >>> >>> Le mercredi 1 novembre 2023 à 14:38:44 UTC+1, David Pye a écrit : >>> >>>> 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 >>>> >>>> On Wed, 1 Nov 2023, 11:54 Richard Scales, <[email protected]> >>>> 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/e576bff1-8d65-4d53-b0cc-2ba5ba574232n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/neonixie-l/e576bff1-8d65-4d53-b0cc-2ba5ba574232n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- 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/915eb85f-cfe3-4e01-8270-60722ffbf9c5n%40googlegroups.com.
