Re: [neonixie-l] Re: Seven digit nixie clock

[Ian Sparkes]

Hi Carl, Mitch,

A couple of thoughts in decreasing order of ease of implementation:

1) Software only: As a first step I'd bypass the digitalWrite() and control 
the port directly. I agree that assembler is probably too much for the 
first round of improvement. I see that your "dataPin" is a constant. 

It's best not to pass it as a parameter: it can be referenced from directly 
within the "shiftItOut" code and the variable referencing can be skipped. 
I'd also do away with the number of bits variable. It's a known constant in 
the code which is required, and you can just call the right one straight 
away, skipping another comparison.

I'd also tend in the longer term to prepare a full static "data packet" to 
be shifted out and use the "shiftItOut" routine to just dump that to the 
output. This section is the innermost loop and needs the most optimisation.

2) Software only: I was mulling this over, and it occurred to me that out 
of each 10 cathode group, only 1 cathode is lit at a time (perhaps two if 
you implement a cross fade that way - but I wouldn't). This means a lot of 
the time you're only twiddling the clock line without toggling the data 
line. You're *nearly* doing this in "shiftItOut", but we have:

  if (val == i - 1) digitalWrite(dataPin, HIGH);
  else digitalWrite(dataPin, LOW);

and it might be better as:

  if (val == i - 1) digitalWrite(dataPin, HIGH);
  else if (val == i) digitalWrite(dataPin, LOW);

in order to save 8 writes to the data pin at the cost of 8 comparisons. I 
don't have any benchmarks about the speed of a digitalWrite as opposed to a 
comparison, but I'd be surprised if they were comparable.

3) Software only: We can do quite a bit of software optimisation in the 
code, without much restructuring. For example in "displayD" there are some 
variable declarations which we could do away with, and we tend to be 
shifting variable values around quite a lot. I would personally prefer 
something along the lines of a "display buffer" where changes are made when 
required. For example we only need to change the hours when they really 
need changing. This is the next most inner loop and needs the next most 
attention.

4) Software and hardware change: The most obvious improvement I can see 
would be to drive the 5530 clock from a PWM output in CTC mode, and use the 
ISR to do the shifting. As a nice side effect, it would have an easily 
programmable (in software) refresh rate. Unfortunately, I think you are 
using pin 4 as the clock pin and this is not PWM capable (unless I am 
looking at the wrong data sheet).

Just thoughts... Happy to discuss...

Ian


On Wednesday, 2 September 2015 14:33:51 UTC+2, H. Carl Ott wrote:
>
>
> On Tue, Sep 1, 2015 at 1:34 PM, Mitch  
> wrote:
>
>>
>> And I have a question - For the IN-18 version, would it be better to 
>> connect all three HV5530s to the processor using separate data, latch, and 
>> clock lines? The processor does have enough spare pins and the code changes 
>> are trivial. 
>>
>> Mitch
>>
>>
>>
>  If you are using level shifters, then you will need additional hardware 
> on all the lines. 
>  I would not bother,
>
>  There is a possible advantage to just using separate data lines, while 
> keeping the CLK/LE/BLANK lines paralleled. You could clock out the data in 
> 1/3 the time.  
>  
> But, it's a trade off when you are bit-banging the serial data.
>  The determining factor is how fast you can shift the data, set io ports 
> and then toggle the clk line in software. 
>
> I did it all in an  ISR written in AVR  assember. I clock out 96 bits of 
> buffer data into 3 chained HV5522s. The ISR fires at 4096hz off a timer. I 
> get very smooth cross fades.
> I spent a lot of time optimizing  those inner loops, shaving cycles 
> wherever possible . 
>
> I doubt that I could actually do it much faster if the data lines were 
> separate. I'd now have to de-mux the data and manipulate 3 IO lines before 
> I could toggle the clock line,  All those extra cycles take time. 
>
> I think you'd gain more by tweaking the code a bit, using the SPI 
> hardware, or just by running  the AVR at a higher clock rate.  
>
>
> carl
> 
> Henry Carl Ott   N2RVQhcar...@gmail.com 
>  
>
>
>   
>
>
>  
>

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/79791722-2212-4aee-bf99-379e22462ccc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [neonixie-l] Re: Seven digit nixie clock

[Mitch]

Thanks again for the comments, Ian.

#1 - Yesterday I removed the pin numbers that were passed as parameters. 
I'll work on removing digitalWrite() by Monday or Tuesday.

#2 - Easily done at the same time. It's probably best to remove the 
'vibrate' code that is more of a kluge than good programming, and do fades 
correctly.

#3 - Would the overhead to assemble a data buffer be worth the cycles to do 
it? I'm thinking about separating the data lines as Carl mentioned. Even if 
that's done, three bits could be located with an offset and written to all 
three HV5530s with one clock write. That could be done on your board with 
two trace cuts and four jumpers. The extra level shifters are there. What 
do you think about that?

#4 - That's beyond my understanding. I was thinking of using a hardware 
interrupt to update the display, but it would require some changes to the 
menu function as it runs in its own loop.And that is on the list of changes 
to be made.

Mitch


On Thursday, September 3, 2015 at 5:28:14 AM UTC-4, Ian Sparkes wrote:
>
> Hi Carl, Mitch,
>
> A couple of thoughts in decreasing order of ease of implementation:
>
> 1) Software only: As a first step I'd bypass the digitalWrite() and 
> control the port directly. I agree that assembler is probably too much for 
> the first round of improvement. I see that your "dataPin" is a constant. 
>
> It's best not to pass it as a parameter: it can be referenced from 
> directly within the "shiftItOut" code and the variable referencing can be 
> skipped. I'd also do away with the number of bits variable. It's a known 
> constant in the code which is required, and you can just call the right one 
> straight away, skipping another comparison.
>
> I'd also tend in the longer term to prepare a full static "data packet" to 
> be shifted out and use the "shiftItOut" routine to just dump that to the 
> output. This section is the innermost loop and needs the most optimisation.
>
> 2) Software only: I was mulling this over, and it occurred to me that out 
> of each 10 cathode group, only 1 cathode is lit at a time (perhaps two if 
> you implement a cross fade that way - but I wouldn't). This means a lot of 
> the time you're only twiddling the clock line without toggling the data 
> line. You're *nearly* doing this in "shiftItOut", but we have:
>
>   if (val == i - 1) digitalWrite(dataPin, HIGH);
>   else digitalWrite(dataPin, LOW);
>
> and it might be better as:
>
>   if (val == i - 1) digitalWrite(dataPin, HIGH);
>   else if (val == i) digitalWrite(dataPin, LOW);
>
> in order to save 8 writes to the data pin at the cost of 8 comparisons. I 
> don't have any benchmarks about the speed of a digitalWrite as opposed to a 
> comparison, but I'd be surprised if they were comparable.
>
> 3) Software only: We can do quite a bit of software optimisation in the 
> code, without much restructuring. For example in "displayD" there are some 
> variable declarations which we could do away with, and we tend to be 
> shifting variable values around quite a lot. I would personally prefer 
> something along the lines of a "display buffer" where changes are made when 
> required. For example we only need to change the hours when they really 
> need changing. This is the next most inner loop and needs the next most 
> attention.
>
> 4) Software and hardware change: The most obvious improvement I can see 
> would be to drive the 5530 clock from a PWM output in CTC mode, and use the 
> ISR to do the shifting. As a nice side effect, it would have an easily 
> programmable (in software) refresh rate. Unfortunately, I think you are 
> using pin 4 as the clock pin and this is not PWM capable (unless I am 
> looking at the wrong data sheet).
>
> Just thoughts... Happy to discuss...
>
> Ian
>
>
> On Wednesday, 2 September 2015 14:33:51 UTC+2, H. Carl Ott wrote:
>>
>>
>> On Tue, Sep 1, 2015 at 1:34 PM, Mitch  wrote:
>>
>>>
>>> And I have a question - For the IN-18 version, would it be better to 
>>> connect all three HV5530s to the processor using separate data, latch, and 
>>> clock lines? The processor does have enough spare pins and the code changes 
>>> are trivial. 
>>>
>>> Mitch
>>>
>>>
>>>
>>  If you are using level shifters, then you will need additional hardware 
>> on all the lines. 
>>  I would not bother,
>>
>>  There is a possible advantage to just using separate data lines, while 
>> keeping the CLK/LE/BLANK lines paralleled. You could clock out the data in 
>> 1/3 the time.  
>>  
>> But, it's a trade off when you are bit-banging the serial data.
>>  The determining factor is how fast you can shift the data, set io ports 
>> and then toggle the clk line in software. 
>>
>> I did it all in an  ISR written in AVR  assember. I clock out 96 bits of 
>> buffer data into 3 chained HV5522s. The ISR fires at 4096hz off a timer. I 
>> get very smooth cross fades.
>> I spent a lot of time optimizing  those inner loops, shaving cycles 
>> wherever 

[neonixie-l] Re: Seven digit nixie clock

[gregebert]

Once I finish the clock (a few months from now, I hope...) and post a 
video, I'll probably give copies of my design report to people in this 
forum who request it.

Each of my display boards has two HV5530 devices that are connected in 
series, but I have separate clock signals in order to guarantee hold-time 
margin by using a 2-phase clock. When multiple display boards are used (for 
more than 6 tubes), they each have their own separate serial-data-in 
signal. All other signals are shared in-common. 


-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/5dc74e3f-841b-44db-a223-1cc5a59b736e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [neonixie-l] Re: Seven digit nixie clock

[Mitch]

Thanks for the advice. I checked the Mod 6 and looking closely, there is no 
flicker whatsoever. Hopefully I can get to 4ms updates or close, by writing 
directly to the port, bypassing digitalWrite(), and optimizing the code. 
Assembly language is not an option. Last time I did that was in college, on 
a General Automation minicomputer.

The CD4504 has two unused level shifters so I will connect each of the 
three HV5530's data lines directly to the processor, clocking three bits at 
the same time, without adding hardware. Data for each digit is stored 
separately, so the software changes are easy, at least for that part. 

Hopefully fading will get done, after all.

 

>  There is a possible advantage to just using separate data lines, while 
> keeping the CLK/LE/BLANK lines paralleled. You could clock out the data in 
> 1/3 the time.  
>  
>
>  

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/e37a4a79-d84d-462d-9f58-2d9c3e601df2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [neonixie-l] Re: Seven digit nixie clock

[H. Carl Ott]

On Tue, Sep 1, 2015 at 1:34 PM, Mitch  wrote:

>
> And I have a question - For the IN-18 version, would it be better to
> connect all three HV5530s to the processor using separate data, latch, and
> clock lines? The processor does have enough spare pins and the code changes
> are trivial.
>
> Mitch
>
>
>
 If you are using level shifters, then you will need additional hardware on
all the lines.
 I would not bother,

 There is a possible advantage to just using separate data lines, while
keeping the CLK/LE/BLANK lines paralleled. You could clock out the data in
1/3 the time.

But, it's a trade off when you are bit-banging the serial data.
 The determining factor is how fast you can shift the data, set io ports
and then toggle the clk line in software.

I did it all in an  ISR written in AVR  assember. I clock out 96 bits of
buffer data into 3 chained HV5522s. The ISR fires at 4096hz off a timer. I
get very smooth cross fades.
I spent a lot of time optimizing  those inner loops, shaving cycles
wherever possible .

I doubt that I could actually do it much faster if the data lines were
separate. I'd now have to de-mux the data and manipulate 3 IO lines before
I could toggle the clock line,  All those extra cycles take time.

I think you'd gain more by tweaking the code a bit, using the SPI hardware,
or just by running  the AVR at a higher clock rate.


carl

Henry Carl Ott   N2RVQhcarl...@gmail.com

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/CAP_hP_SL7cWdbgEEymvfb%2BpLtU6JFbpqt2g5YXxNr%2BEncZDn9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[Mitch]

Greg, I'd like to understand this so I can do the same for the IN-18 design 
and the next, fifteen digit clock that will use five, HV5530s. Please let 
me know if this is correct:

Latch, blanking, and data, are connected in parallel, on each of your 
boards. Each clock line is connected to a separate pin on the processor. 
How do you clock the data so that it moves across all HV5530s if they are 
not clocked at the same time? 

Would it be an advantage to connect each clock and each data line to a 
separate pin, to load each HV5530 separately rather than serially?






On Wednesday, September 2, 2015 at 2:17:17 AM UTC-4, gregebert wrote:
>
> Once I finish the clock (a few months from now, I hope...) and post a 
> video, I'll probably give copies of my design report to people in this 
> forum who request it.
>
> Each of my display boards has two HV5530 devices that are connected in 
> series, but I have separate clock signals in order to guarantee hold-time 
> margin by using a 2-phase clock. When multiple display boards are used (for 
> more than 6 tubes), they each have their own separate serial-data-in 
> signal. All other signals are shared in-common. 
>
>
>

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/349f61ab-db27-45c2-83a7-549545a2870a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[Mitch]

The 1284P runs at 5v, and I use a CD4504 level shifter. Someone here 
suggested that, and even though none of the commercial clocks I'm familiar 
with use one they are cheap and easy to include. That will also make it 
easy to go to a 3.3v chip in the future, with only some adjusted resistor 
values. I think every other solid state component on this design is 3.3v 
compatible.

I'm not sure if there is any advantage to connecting the HV5530s in 
parallel to the processor, maybe faster updating. That's why I asked. The 
current design works fine as is, with three connected in series. I'm not 
sure if it will work for a fifteen digit clock with five HV5530s, though.

I like the IN-18, too. It is certainly the best large tube for the money, 
nothing else comes close price wise.

I use acrylic disks under the IN-14 and Z570M series tubes, and I'll do the 
same for the IN-18. Check the picture. They are 5mm think, but I went to 
3mm for the reorder. Illustrator files are included for them in the zip. 
I'll have an IN-18 version soon, too.

The Spectrum 18 also uses acrylic disks under each tube, and individual 
pins. If the component layout for the IN-18 is done carefully and the pins 
are soldered while on the tubes, there should not be any stress on them.

I run most clocks from 6pm-11pm, which is when I'm around. This clock has 
three override periods that are weekday and weekend aware, so I run it 6-11 
during the week, and all day weekends. I don't use the PIR now, but after I 
build a few I'll set one up that way.

Do you plan to share your design?



On Tuesday, September 1, 2015 at 6:43:41 PM UTC-4, gregebert wrote:
>
> You can certainly connect the HV5530's "in-parallel" to the CPU. I would 
> be more concerned about signal-levels, because the HV5530 is intended to 
> run with 12V logic levels and your CPU is probably 3.3V. I'm using a 
> level-shifter IC in my design, along with an FPGA.
>
> BTW, I'm putting the finishing touches on my first IN-18 clock PCB; It's 
> definitely worth the extra expense of IN-18's to get large and 
> properly-formed digits (no funky upside-down 2's and 5's).
>
> I decided to use socket pins soldered to the pcb, rather than actual 
>  IN-18 sockets, because of space constraints. I hope I'm not going to 
> regret this decision, and I'm definitely going to be very careful to form 
> the pins to minimize stress. I also will not be swapping tubes around to 
> even-out their usage (using de-poisoning algorithm instead).
>
> Do you plan to run your IN-18's 24/7, or will you use a motion-sensor, etc 
> ?
>

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/71f1a635-7dec-4219-9273-51fc24524aae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[gregebert]

You can certainly connect the HV5530's "in-parallel" to the CPU. I would be 
more concerned about signal-levels, because the HV5530 is intended to run 
with 12V logic levels and your CPU is probably 3.3V. I'm using a 
level-shifter IC in my design, along with an FPGA.

BTW, I'm putting the finishing touches on my first IN-18 clock PCB; It's 
definitely worth the extra expense of IN-18's to get large and 
properly-formed digits (no funky upside-down 2's and 5's).

I decided to use socket pins soldered to the pcb, rather than actual  IN-18 
sockets, because of space constraints. I hope I'm not going to regret this 
decision, and I'm definitely going to be very careful to form the pins to 
minimize stress. I also will not be swapping tubes around to even-out their 
usage (using de-poisoning algorithm instead).

Do you plan to run your IN-18's 24/7, or will you use a motion-sensor, etc ?

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/5b940109-e1fb-4213-846a-39c992e3a732%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[gregebert]

Mitch - Do you run any simulations on your design before fabbing boards ?

As a rule, I run a lot of spice simulations on the analog, particularly the 
power supplies. My second clock had a subtle wiring error that caused spice 
not to converge, and if I had not fixed the error it would have smoked at 
power-on. So far, I've done 3 boards with no errors; the boards were right 
the first time. The spice deck is partially created from the PCB netlister.

For digital stuff, I do verilog simulations, and I do have to spend a lot 
of time coding-up models for various ICs.

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/3dbc969d-1921-405e-abc5-ca52fa419fdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[Mitch]

Hi Ian,

Thanks for your comments.

I do use three, HV5530s to control all seven nixies and six neons. The 
lower right most neon is the decimal for 1/10 seconds, and the upper right 
neon represents degrees for the temperature display.

All four indicator LEDs and seven 2N3904s to turn each RGB LED on or off, 
are connected to the port expander.  The RGB LED anodes are connected to 
three PWM lines on the 1284P using 2N7000 FETs.

No doubt the code can be greatly improved, especially the display function, 
but that will have to be done by someone else if it's going to be done at 
all. I think I'm at the limit of what I can accomplish, here. I think I 
mentioned that the maximum refresh rate at the moment, is around 17ms.

The third release of the board is on order, unfortunately, because there 
are some extra lines available that could have been used to clock the 
HV5530s separately. I was hoping for no jumpers this time around, but that 
is an option.

Mitch

On Saturday, August 22, 2015 at 4:09:06 PM UTC-4, Ian Sparkes 

 Hey Mitch

 I did a smooth fading on a AVR, and the code is up there on GitHub already:

 https://github.com/isparkes/ArdunixNix6

 I do it a different way than I think you will want to, because I use an 
 old fashioned K155,and use 6 I/O pins to control the anodes. I have an 
 inner loop of 1000 iterations (to display each digit), and an outer loop of 
 6 iterations (one for each digit). I manage dimming by defining the off 
 time for each digit (earlier off time = more dimming), and the fading by 
 the switch point between the old and new digit. Each display impression, 
 the switch point is progressed until the fade is done. Of course the code 
 has to be quick enough so that all of this is done without letting flicker 
 creep in. On my 1 x 6 multiplexed clock, this is a challenge, but with 
 careful software design it is perfectly possible.

 What exactly was the problem with the fading? Not smooth? Too hard to 
 program? I guess is that it was not really smooth, because the process of 
 clocking in the data was not quick enough, and that to resolve this, you'll 
 have to be really careful about writing the clock and data lines, probably 
 using bit level operations directly on the ports. Possibly clocking the 
 HV5530s in parallel could help.

 PV Electronics does smooth fading, but using the 20 bit HV5812, so it is 
 possible if you are multiplexing 3 x 2.

 If you post the code up, I'm sure someone will be able to add the special 
 sauce to make s smooth fade. If you have some boards made, I'd like to get 
 one and have a play around with it.

 Regards

 Ian

 My own workings to try and understand the issue:

 In my design I'm transferring 60 bits per impression. cathodes: 6 digits * 
 4 bits * 2 values (before and after fade). Anodes: 1 bit * 6 digits * 2 
 (anode on, anode off). I don't have to toggle a clock line. If I needed to, 
 I would write the registers directly, but right now I don't need to. 
 Standard Arduino ditigalWrite() is fast enough.

 You appear to be using 3 HV5530s, I suppose two managing 3 digits each 
 with the odd 2 bits for the colons, and the last one for the 7th digit? I 
 suppose you are running the RGB back lighting off Atmel's PWM outputs?

 An impression for you is 74 raw bits, but using bit banging on the clock 
 line to clock the data in, so that's tripling that number. However, you 
 only need to toggle the data line 20 times (2 for each digit, 2 for each 
 colon point), which means about 168 bits toggled. If you don't optimize the 
 handling of the data line, you'll end up writing 224 bits per impression.

 That's nearly 3 times the amount of data transferred per impression, and 
 all because of the clock line. I think this is where you need to optimize.


 On Wednesday, 19 August 2015 21:15:54 UTC+2, Mitch wrote:

 I tried doing something similar, and that's how I came up with the 
 vibration effect, which is really just a failed attempt at cross fading. 
 I'm not sure whether the limitation is with the hardware or software, 
 probably both. Writing to registers rather than using digitalWrite() may 
 speed it up enough. That can be someone else's project at this point, I 
 don't think I'll spend more time on it for now.

 The clock on the Metronome in Union Square, uses 15 digits. Time, time to 
 midnight, and 1/100 seconds in between. I think 1/10 makes more sense 
 because at least you can see the digits. I like your idea better, but a 
 combination would make it very interesting.
 Here's the info:
 https://en.wikipedia.org/wiki/Metronome_(public_artwork)



 On Wednesday, August 19, 2015 at 11:55:34 AM UTC-4, gregebert wrote:

  I don't see a way to dim just one digit. With multiplexing, as each 
 digit is selected the PWM rate could be set differently, but I don't see 
 how to do it with direct drive.

 Dimming individual digits is possible with hardware control, but 
 probably not with software. The idea is to resend the serial data to 

[neonixie-l] Re: Seven digit nixie clock

[Ian Sparkes]

Hey Mitch

I did a smooth fading on a AVR, and the code is up there on GitHub already:

https://github.com/isparkes/ArdunixNix6

I do it a different way than I think you will want to, because I use an old 
fashioned K155,and use 6 I/O pins to control the anodes. I have an inner 
loop of 1000 iterations (to display each digit), and an outer loop of 6 
iterations (one for each digit). I manage dimming by defining the off time 
for each digit (earlier off time = more dimming), and the fading by the 
switch point between the old and new digit. Each display impression, the 
switch point is progressed until the fade is done. Of course the code has 
to be quick enough so that all of this is done without letting flicker 
creep in. On my 1 x 6 multiplexed clock, this is a challenge, but with 
careful software design it is perfectly possible.

What exactly was the problem with the fading? Not smooth? Too hard to 
program? I guess is that it was not really smooth, because the process of 
clocking in the data was not quick enough, and that to resolve this, you'll 
have to be really careful about writing the clock and data lines, probably 
using bit level operations directly on the ports. Possibly clocking the 
HV5530s in parallel could help.

PV Electronics does smooth fading, but using the 20 bit HV5812, so it is 
possible if you are multiplexing 3 x 2.

If you post the code up, I'm sure someone will be able to add the special 
sauce to make s smooth fade. If you have some boards made, I'd like to get 
one and have a play around with it.

Regards

Ian

My own workings to try and understand the issue:

In my design I'm transferring 60 bits per impression. cathodes: 6 digits * 
4 bits * 2 values (before and after fade). Anodes: 1 bit * 6 digits * 2 
(anode on, anode off). I don't have to toggle a clock line. If I needed to, 
I would write the registers directly, but right now I don't need to. 
Standard Arduino ditigalWrite() is fast enough.

You appear to be using 3 HV5530s, I suppose two managing 3 digits each with 
the odd 2 bits for the colons, and the last one for the 7th digit? I 
suppose you are running the RGB back lighting off Atmel's PWM outputs?

An impression for you is 74 raw bits, but using bit banging on the clock 
line to clock the data in, so that's tripling that number. However, you 
only need to toggle the data line 20 times (2 for each digit, 2 for each 
colon point), which means about 168 bits toggled. If you don't optimize the 
handling of the data line, you'll end up writing 224 bits per impression.

That's nearly 3 times the amount of data transferred per impression, and 
all because of the clock line. I think this is where you need to optimize.


On Wednesday, 19 August 2015 21:15:54 UTC+2, Mitch wrote:

 I tried doing something similar, and that's how I came up with the 
 vibration effect, which is really just a failed attempt at cross fading. 
 I'm not sure whether the limitation is with the hardware or software, 
 probably both. Writing to registers rather than using digitalWrite() may 
 speed it up enough. That can be someone else's project at this point, I 
 don't think I'll spend more time on it for now.

 The clock on the Metronome in Union Square, uses 15 digits. Time, time to 
 midnight, and 1/100 seconds in between. I think 1/10 makes more sense 
 because at least you can see the digits. I like your idea better, but a 
 combination would make it very interesting.
 Here's the info:
 https://en.wikipedia.org/wiki/Metronome_(public_artwork)



 On Wednesday, August 19, 2015 at 11:55:34 AM UTC-4, gregebert wrote:

  I don't see a way to dim just one digit. With multiplexing, as each 
 digit is selected the PWM rate could be set differently, but I don't see 
 how to do it with direct drive.

 Dimming individual digits is possible with hardware control, but 
 probably not with software. The idea is to resend the serial data to the 
 HV5530's twice every few milliseconds or so: Once to turn off the digit(s) 
 to be dimmed, then again to turn all digits on. By adjusting the on and off 
 times, you are doing PWM. I have 2 cascaded HV5530's (64 bits), and I clock 
 them at 1.5Mhz, so it's possible to do PWM up to a few kHz.

  

 A 14 digit IN-18 clock sounds interesting. What are you doing with the 
 extra digits?


 I went overboard, so it displays hours, minutes, seconds, date, month, 
 year = 14 digits. My wife saw the nixie clock in the movie Tomorrowland 
 and ordered me to build one for her (yeah, like I'm going to say no ???). I 
 saw no purpose for 12 digits, so I super-sized it to 14 digits. To 
 level-out the tube usage, I swap date and time locations hourly, then run a 
 depoisoning routine at 4AM for 1 hour.

 The clock will be in our vacation home, so the tubes will be off most of 
 the time. It will be an art-deco theme, in a wooden case complete with 2 
 large toggle switches and 1950's-era incandescent panel lamps. I expect it 
 will be 30 inches wide x 5 inches deep x 5 inches 

[neonixie-l] Re: Seven digit nixie clock

[Mitch]

Thanks, Dave. Everything will be included, Diptrace schematic, pc layout, 
Arduino sketch, and operations manual. I have no intention of 
commercializing the project in any way.

This was my first experience with pc board design, and I'm hoping that 
someone here with good hardware experience will improve the design and pc 
board layout. Same with the software. I'll start reviewing and improving it 
in a couple weeks, but someone with extensive Arduino and C++ experience 
can certainly take it much farther.

I'll post more pictures in about two weeks, after the IN-14 and IN-12B 
boards arrive.


On Wednesday, August 19, 2015 at 8:15:03 AM UTC-4, Dave wrote:

 Mitch,
 This is very nice work indeed !

 Thanks for sharing.

 When you post to github, will it be the code and the diptrace files?

 I deeply appreciate your willingness to share your work.




-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/04f10880-bd2b-4088-8235-bba09f18813a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

['Dave' via neonixie-l]

Mitch,
This is very nice work indeed !

Thanks for sharing.

When you post to github, will it be the code and the diptrace files?

I deeply appreciate your willingness to share your work.


-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/ab4a6be6-c683-4d90-bc6f-85c07a862c88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[gregebert]

  I don't see a way to dim just one digit. With multiplexing, as each 
 digit is selected the PWM rate could be set differently, but I don't see 
 how to do it with direct drive.

 Dimming individual digits is possible with hardware control, but probably 
not with software. The idea is to resend the serial data to the HV5530's 
twice every few milliseconds or so: Once to turn off the digit(s) to be 
dimmed, then again to turn all digits on. By adjusting the on and off 
times, you are doing PWM. I have 2 cascaded HV5530's (64 bits), and I clock 
them at 1.5Mhz, so it's possible to do PWM up to a few kHz.

 

 A 14 digit IN-18 clock sounds interesting. What are you doing with the 
 extra digits?


I went overboard, so it displays hours, minutes, seconds, date, month, year 
= 14 digits. My wife saw the nixie clock in the movie Tomorrowland and 
ordered me to build one for her (yeah, like I'm going to say no ???). I saw 
no purpose for 12 digits, so I super-sized it to 14 digits. To level-out 
the tube usage, I swap date and time locations hourly, then run a 
depoisoning routine at 4AM for 1 hour.

The clock will be in our vacation home, so the tubes will be off most of 
the time. It will be an art-deco theme, in a wooden case complete with 2 
large toggle switches and 1950's-era incandescent panel lamps. I expect it 
will be 30 inches wide x 5 inches deep x 5 inches tall. I'm leery about the 
reliability of non-Burroughs tubes, and we already have 3 nixie clocks 
running 24/7 (why not, they are Burroughs tubes) in our permanent home. 

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/ff087b7e-c23d-4a93-b723-4ac10830957b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[Mitch]

I tried doing something similar, and that's how I came up with the 
vibration effect, which is really just a failed attempt at cross fading. 
I'm not sure whether the limitation is with the hardware or software, 
probably both. Writing to registers rather than using digitalWrite() may 
speed it up enough. That can be someone else's project at this point, I 
don't think I'll spend more time on it for now.

The clock on the Metronome in Union Square, uses 15 digits. Time, time to 
midnight, and 1/100 seconds in between. I think 1/10 makes more sense 
because at least you can see the digits. I like your idea better, but a 
combination would make it very interesting.
Here's the info:
https://en.wikipedia.org/wiki/Metronome_(public_artwork)



On Wednesday, August 19, 2015 at 11:55:34 AM UTC-4, gregebert wrote:

  I don't see a way to dim just one digit. With multiplexing, as each 
 digit is selected the PWM rate could be set differently, but I don't see 
 how to do it with direct drive.

 Dimming individual digits is possible with hardware control, but probably 
 not with software. The idea is to resend the serial data to the HV5530's 
 twice every few milliseconds or so: Once to turn off the digit(s) to be 
 dimmed, then again to turn all digits on. By adjusting the on and off 
 times, you are doing PWM. I have 2 cascaded HV5530's (64 bits), and I clock 
 them at 1.5Mhz, so it's possible to do PWM up to a few kHz.

  

 A 14 digit IN-18 clock sounds interesting. What are you doing with the 
 extra digits?


 I went overboard, so it displays hours, minutes, seconds, date, month, 
 year = 14 digits. My wife saw the nixie clock in the movie Tomorrowland 
 and ordered me to build one for her (yeah, like I'm going to say no ???). I 
 saw no purpose for 12 digits, so I super-sized it to 14 digits. To 
 level-out the tube usage, I swap date and time locations hourly, then run a 
 depoisoning routine at 4AM for 1 hour.

 The clock will be in our vacation home, so the tubes will be off most of 
 the time. It will be an art-deco theme, in a wooden case complete with 2 
 large toggle switches and 1950's-era incandescent panel lamps. I expect it 
 will be 30 inches wide x 5 inches deep x 5 inches tall. I'm leery about the 
 reliability of non-Burroughs tubes, and we already have 3 nixie clocks 
 running 24/7 (why not, they are Burroughs tubes) in our permanent home. 


-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/a3c6259a-3219-4403-9913-6bc82df603ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[Mitch]

I forgot to mention that as hard as I've tried, I have not been able to 
figure out smooth, digit cross fading. For now the clock uses a 'vibration' 
effect that you can see in the video, or a no effects digit change.




-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/68296203-baef-4d36-b89d-c5815ee74275%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[Mitch]

David, I will put everything on Github when the new boards arrive. The 
schematic and board were done with Diptrace.

Greg, the 1/10th second digit won't fade or use effects because it changes 
so quickly. The 'vibrate' effect works only on the other six digits. 

A level shifter is used, and all three 5530s use the same clock. I don't 
see how to implement separate clocks, and it works fine as is. I did some 
quick timing tests and it appears that the display can be updated no faster 
than 17ms, as the code stands. It is only updated at 100ms now, and 25ms 
when the vibrate effect is used.

The blanking line on the 5530s dims the display with PWM. I don't see a way 
to dim just one digit. With multiplexing, as each digit is selected the PWM 
rate could be set differently, but I don't see how to do it with direct 
drive.

A 14 digit IN-18 clock sounds interesting. What are you doing with the 
extra digits?




On Tuesday, August 18, 2015 at 8:11:09 PM UTC-4, gregebert wrote:

 Regarding fading, I've seen clocks that gradually make 1 digit dimmer as 
 the next digit becomes brighter (with overlap), and it looks more like a 
 blurry mess. You may want to use PWM to dim the changing digit in a 100-200 
 msec, before you gradually turn-on the next value. It might be annoying for 
 digits changing every second (or in your case, 1/10 second ??), but for 
 tens-seconds and beyond it should look OK. None of the clocks I've built so 
 far will support this, but the next one will be capable of it.

 Based on the HV5530 driver, I'm assuming your clock is direct-drive, so 
 you will have more options for effects.

 Did you add a level-shifter to drive the 5530's inputs at the recommended 
 12V signal-levels ? I'm also curious if you cascaded the serial 
 data-in/data out signals if both 5530's use the same clock; per the 
 datasheet, doing so is a timing risk (data-hold time is 10nsec, and there 
 is no min-prop delay specified hence assume 0. This implies a 10nsec timing 
 risk).

 I'm finalizing the PC board for my 14-digit IN-18 clock, and took no 
 risks: Using a level-shifter, and separate clocks for each HV5530. I'm 
 using an FPGA instead of a microcontroller, and I have enough room on the 
 FPGA for a small CPU (probably Z80) if I decide to go that route instead of 
 pure Verilog code.


-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/1b67d00c-9881-4bbd-85f6-3145ebe49bf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [neonixie-l] Re: Seven digit nixie clock

[David Forbes]

Mitch,

Are you willing to share your code? There are many pairs of sharp eyes here that 
could help you figure that out.



On 8/18/2015 1:27 PM, Mitch wrote:

I forgot to mention that as hard as I've tried, I have not been able to
figure out smooth, digit cross fading. For now the clock uses a 'vibration'
effect that you can see in the video, or a no effects digit change.








--
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/55D3B4D6.70409%40dakotacom.net.
For more options, visit https://groups.google.com/d/optout.

[neonixie-l] Re: Seven digit nixie clock

[gregebert]

Regarding fading, I've seen clocks that gradually make 1 digit dimmer as 
the next digit becomes brighter (with overlap), and it looks more like a 
blurry mess. You may want to use PWM to dim the changing digit in a 100-200 
msec, before you gradually turn-on the next value. It might be annoying for 
digits changing every second (or in your case, 1/10 second ??), but for 
tens-seconds and beyond it should look OK. None of the clocks I've built so 
far will support this, but the next one will be capable of it.

Based on the HV5530 driver, I'm assuming your clock is direct-drive, so you 
will have more options for effects.

Did you add a level-shifter to drive the 5530's inputs at the recommended 
12V signal-levels ? I'm also curious if you cascaded the serial 
data-in/data out signals if both 5530's use the same clock; per the 
datasheet, doing so is a timing risk (data-hold time is 10nsec, and there 
is no min-prop delay specified hence assume 0. This implies a 10nsec timing 
risk).

I'm finalizing the PC board for my 14-digit IN-18 clock, and took no risks: 
Using a level-shifter, and separate clocks for each HV5530. I'm using an 
FPGA instead of a microcontroller, and I have enough room on the FPGA for a 
small CPU (probably Z80) if I decide to go that route instead of pure 
Verilog code.

-- 
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 post to this group, send an email to neonixie-l@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/neonixie-l/3e76599d-cfa9-4b47-af31-4d8060d21cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.