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, <[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/7de838a4-7cfc-4f2b-b358-5ded19c1d744n%40googlegroups.com.
