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. On Tuesday, January 9, 2024 at 7:20:17 PM UTC Nicholas Stock wrote: > The Niximatrix is a sight to behold!! I must dig mine out....... Do you > have any more kits Jon? > > Nick > > On Tue, Jan 9, 2024 at 12:55 AM Jon <deka...@nomotron.com> wrote: > >> >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. >> >> >> On Tuesday, January 9, 2024 at 5:03:52 AM UTC Richard Scales wrote: >> >>> @ 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) >>> <https://www.pinitech.com/retrofit/schematics/bally_as2518_15_6digit.pdf> >>> >>> Am I anywhere near the right track on any of this? >>> >>> - Richard >>> >>> >>> On Friday 3 November 2023 at 12:12:03 UTC David Pye wrote: >>> >>>> 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 >>>> >>>> On Fri, 3 Nov 2023, 11:15 Mike Mitchell, <mmit...@gmail.com> wrote: >>>> >>>>> 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. >>>>> >>>>> On Friday, November 3, 2023 at 12:43:40 AM UTC-4 Richard Scales wrote: >>>>> >>>>>> @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 >>>>>> >>>>>> >>>>>> On Thursday, 2 November 2023 at 13:32:57 UTC Richard Scales wrote: >>>>>> >>>>>>> @Mike, many thanks. >>>>>>> >>>>>>> I'll work through that. >>>>>>> >>>>>>> - Richard >>>>>>> >>>>>>> >>>>>>> On Thursday, 2 November 2023 at 12:20:53 UTC Mike Mitchell wrote: >>>>>>> >>>>>>>> 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. >>>>>>>> On Thursday, November 2, 2023 at 12:56:33 AM UTC-4 gregebert wrote: >>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> On Wednesday, November 1, 2023 at 9:23:25 PM UTC-7 Richard Scales >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wednesday, 1 November 2023 at 16:29:32 UTC Craig Garnett wrote: >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> On Wednesday, 1 November 2023 at 15:47:33 UTC gregebert wrote: >>>>>>>>>>> >>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [image: raspi_fpga.JPG] >>>>>>>>>>>> >>>>>>>>>>>> On Wednesday, November 1, 2023 at 8:19:48 AM UTC-7 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, < >>>>>>>>>>>>>>>> ric...@scalesweb.co.uk> 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 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> <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 neonixie-l+...@googlegroups.com. >>>>> >>>> To view this discussion on the web, visit >>>>> https://groups.google.com/d/msgid/neonixie-l/1bc508d5-1f0c-4b6e-af2f-3f9a0092ecc6n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/neonixie-l/1bc508d5-1f0c-4b6e-af2f-3f9a0092ecc6n%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 neonixie-l+...@googlegroups.com. >> > To view this discussion on the web, visit >> https://groups.google.com/d/msgid/neonixie-l/2edcc2a6-37e5-44db-ae77-ce3a4286aa63n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/neonixie-l/2edcc2a6-37e5-44db-ae77-ce3a4286aa63n%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 neonixie-l+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/neonixie-l/1b79f48b-e932-468f-ba64-cdc0f00ad175n%40googlegroups.com.
