very cool I may need one
~ *mcvei...@gmail.com <mcvei...@gmail.com>* On Tue, Jan 9, 2024 at 12:27 PM Jon <dekat...@nomotron.com> wrote: > 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 > <https://groups.google.com/d/msgid/neonixie-l/1b79f48b-e932-468f-ba64-cdc0f00ad175n%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/CAKYv7NR%2B8vmYV_RtUnEwiW9kGuY4jNn_DD13LFHoYNdCQMGrkg%40mail.gmail.com.
