@Mike - many thanks - I think I'm getting it.
 - Richard

On Friday, 3 November 2023 at 11:15:27 UTC Mike Mitchell 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+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/81af8ec0-5f1f-49d5-a486-18d248566e2bn%40googlegroups.com.

Reply via email to