@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, <[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/f9cd29b8-08a2-4f39-a55e-f2286bae05dbn%40googlegroups.com.
