The time to shift out the bits is not critical, the clock rate is as fast 
as you implement it, there is only a minimum clock time, but no maximum one.
Brightness should be the same as putting the tube pin directly to ground, 
the internal resistance of the mosfet in the HV5530 is in the Ohms range, 
while your anode resistor will probably will be a few kiloohms, so no 
visible issue.

About voltage:
The HV5530 is specified for 10.8 to 13.2V, but alot of people seem to use 
it with 5V logic and it works. If you want do operate ith with 12V logic, 
you need a 12V source and a level shifter. HEF4104 
<https://www.digikey.com/en/products/detail/nexperia-usa-inc/HEF4104BT-653/1156435>
 
could work


On Saturday, 13 August 2022 at 19:04:21 UTC+2 flata...@gmail.com wrote:

> Thanks.
>
> In terms of nixie brightness, is there any advantage in using serial to 
> parallel converter+shift register vs multiplexing using high voltage 
> transistors on anodes and cathodes of the nixies? Other than saving 
> component and uC pins, of course. 
>
> -------- Original message --------
> From: Bill Stanley <billsta...@gmail.com> 
> Date: 13/08/2022 17:32 (GMT+00:00) 
> To: neonixie-l <neoni...@googlegroups.com> 
> Subject: [neonixie-l] Re: Nixie Clock - Direct Drive HV5530 
>
> I use that part for my NIXIE, Panaplex and LED displays and I also write 
> in assembly (8051, not PIC)
> For my code, I send the serial data for NEXT time to display in the time 
> after a 1 second update. On the 1 second "hack"
> I update the display by doing the serial to parallel pulse.
>
> Here is the code I use:
>
> ;************************************************************************
> ;*                                    *
> ;*    Serial clock the data in the raw buffer to the H/W drivers.     *
> ;*    Note: this routine does not strobe the data to the display.    *
> ;*                                    *
> ;*    On Entry: None.                            *
> ;*    On Exit:  Display H/W drivers updated from ram.            *
> ;*                                    *
> ;************************************************************************
>
> WRT_NIXIE_HW:    MOV    R0,#DISP_RAW_TH        ;point at start of raw 
> display ram
>                                  MOV    R1,#12d            ;12 bytes of 
> data to send
> RAW_BYTE_LP:     MOV    R2,#5            ;5 bits per byte
>                                 MOVX    A,@R0            ;get a 5 bit value
>                                 INC    R0            ;bump the pointer
>
> RAW_BIT_LP:        RRC    A            ;bit 0 into carry
>                                MOV    DISP_DAT,C        ;put the bit into 
> the I/O port
>                                CALL    HV_BIT_DELAY        ;delay
>                                SETB    DISP_CLK        ;clock high
>                                CALL    HV_BIT_DELAY        ;delay
>                                CLR    DISP_CLK        ;clock low
>                                DJNZ    R2,RAW_BIT_LP        ;loop 5 bits
>                                DJNZ    R1,RAW_BYTE_LP        ;loop 12 bytes
>                                RET                ;and return
>
>
> ;************************************************************************
> ;*                                    *
> ;*    Update the NIXIE readouts with the data in the H/W buffers.    *
> ;*                                    *
> ;*    On Entry: None.                            *
> ;*    On Exit:  NIXIE displays show updated values.            *
> ;*                                    *
> ;************************************************************************
>
>
> UPDATE_DISP:    CALL    HV_BIT_DELAY        ;delay
>                               SETB    DISP_STRB        ;strobe the data
>                               CALL    HV_BIT_DELAY        ;delay
>                               CLR    DISP_STRB        ;un-strobe NIXIE 
> drivers
>                               RET
>
>
>
> On Saturday, August 13, 2022 at 8:40:39 AM UTC-7 flata...@gmail.com wrote:
>
>> Thank you both.
>>
>> Say that I want to drive high HVOUT12 on pin2 (that is binary 
>> b'00000010') of the HV5530... and reading your previous messages, do I 
>> simply...:
>>
>> drive pin28 (CLOCK) low
>> drive pin31 (LE) low
>>
>> drive pin28 (CLOCK) high
>> drive pin32 (DATA Input) low ; send 0 for bit 0 of b'00000010'
>> drive pin28 (CLOCK) low
>> drive pin28 (CLOCK) high
>> drive pin32 (DATA Input) high ; send 1 for bit 1 of b'00000010'
>> drive pin28 (CLOCK) low
>> drive pin28 (CLOCK) high
>> drive pin32 (DATA Input) low ; send 0 for bit 2 of b'00000010'
>> drive pin28 (CLOCK) low etc
>> etc...
>> drive pin31 (LE) high.
>>
>> Of course, I'd need to do it do it within a certain time frame (nS, I 
>> suppose)
>>
>> Then I guess I would need a level shifter as while the input voltage is 
>> 12V, the PIC is at 3.3V (LF series). Argh. 
>>
>> I'm starting to think whether that is really a better approach than using 
>> an 80pin or 100pin PIC with HV transistors to drive the cathodes of the 
>> Nixies (pic18f46k22 would do for instance). It would increase component 
>> count and cost of PIC etc, but it's not a commercial project, I'm only 
>> making 3 clocks in total.
>>
>> Indeed, I'm building a clock with Dalibor's RZ568M (beautiful!).
>>
>> Il giorno sabato 13 agosto 2022 alle 15:46:58 UTC+1 gregebert ha scritto:
>>
>>> Be sure to use a level translator to drive the 5530-type devices at the 
>>> proper signal voltages (12 VDC). Some people have driven them at 5V, which 
>>> is out-of-spec and not guaranteed to work.  I use these drivers in some of 
>>> my clocks and they work very well. 
>>>
>>> Pardon my rant below, but I've been designing IC's for a living since 
>>> the 1980's and too often I see others having problems with serial devices  :
>>>
>>>   One thing that annoys me about the HV5530 (and similar) devices is 
>>> that the datasheet specs are incomplete for the serial data signals. The 
>>> data-in hold time (tH) is 10nsec, but there is no *minimum* propagation 
>>> time in the spec (tDLH, tDHL). The only have a maximum (100ns). What this 
>>> means is that per the datasheet, you cannot simply cascade multiple 
>>> devices. It might work if you do, but if you want to guarantee that it will 
>>> always work, place a rising-edge flip-flop between cascaded devices). In 
>>> order to have reliable shifting, the minimum propagation-delay of the 
>>> driving device *must be greater* than the hold-time of the next device. 
>>> If there is no minimum prop-delay spec, assume it's zero (a very safe and 
>>> reasonable assumption). 
>>>
>>> My current clock project (6-tube RZ 568m) has multiple PC boards with 
>>> ribbon cables interconnecting them. Not just for the three HV5530's that 
>>> drive the tubes, but also many other devices in the same serial chain for 
>>> reading switches and controlling lamps. After many weeks of testing with 
>>> billions of bits, there are zero bit errors.....because I made sure setup 
>>> and hold times are met.
>>>
>>>
>>> On Saturday, August 13, 2022 at 6:32:31 AM UTC-7 SWISSNIXIE - Jonathan 
>>> F. wrote:
>>>
>>>> Hi Max,
>>>> The HV5530 and other HV-Series IC's are "Serial to Paralell" converters 
>>>> which allow to be control 32-pins (or even more with multiple ic's) from 
>>>> single clock and data lines. They are basically normal serial to parallel 
>>>> converters with high voltage transistors attached. 
>>>>
>>>> To operate these you will need a clock source (for easy way a gpio that 
>>>> goes high/low) and a data source, which means either a pin that is high or 
>>>> low at the time of clock. After you've sent the required amount of data 
>>>> (number of outputs on the IC) the first data will transfer to "DATA OUT" 
>>>> pin and into the next IC (if there is one).
>>>>
>>>> For a 6 digit clock you need 2 pcs of HV553
>>>>
>>>> I cannot provice ASM code for PIC, but here is a low level code of 
>>>> ATMega:
>>>>
>>>> *#define thePort PORTD *
>>>> *#define DATA PD5*
>>>>
>>>> *#define CLK PD7 *
>>>>
>>>>
>>>> *PORTC |= _BV(PC1);  //Set OE/LE Signal LOW*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * for (int i = 0; i < 32; i++) {    thePort &= ~_BV(DATA);  //Data LOW  
>>>>   if ( bitRead(val_one, i) == 1) {      thePort |= _BV(DATA);  //Data HIGH 
>>>>  
>>>>   }    thePort |= _BV(CLK);  //CLK HIGH    thePort &= ~_BV(CLK); //CLK LOW 
>>>>  
>>>> }*
>>>> *PORTC &= ~_BV(PC1);  //Set OE/LE Signal HIGH* 
>>>>
>>>> The general operation of the 5530 is as following.
>>>>
>>>> 1.) Drive Data pin and Clock pin LOW
>>>> 2.) Before starting to send data, drive LE pin LOW
>>>> 3.) For each bit you need to do a clock signal and data pin, for this:
>>>> 3.1) Drive CLOCK High
>>>> 3.2) Drive DATA high or low, depending if you want to turn the digit on 
>>>> or off
>>>> 3.3) Drive CLOCK Low
>>>> 3.4) Drive DATA Low
>>>> 4.) This needs to be done for all Inputs of an ic, if you have two ic's 
>>>> chained you need to to it two times.
>>>> 5.) After all Data has been sent, drive LE pin HIGH, Outputs will now 
>>>> be set to the data you've just send
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Saturday, 13 August 2022 at 12:13:24 UTC+2 flata...@gmail.com wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm starting to design my first 6 digit nixie clock and I'd like to 
>>>>> use direct drive of the tubes (my power supply can take 6 nixies without 
>>>>> multiplexing).
>>>>>
>>>>> So far I have built my Nixie watch, coding in ASM, worked on extreme 
>>>>> power saving etc.
>>>>>
>>>>> I could multiplex the nixies as I did in this project 
>>>>> https://fb.watch/eTb69SnxEP/ , but since I have a good power supply I 
>>>>> wanted to build a clock with direct drive of the tubes.
>>>>>
>>>>> I prefer to code in ASM (don't ask why :)  ), I could use a 100pin 
>>>>> PIC18 to drive each digit individually through MMBTA92 & A42 transistors. 
>>>>> However, if I want to use a PIC with a lower pin count (say 40pins), I 
>>>>> may 
>>>>> use a driver such as HV5530.
>>>>>
>>>>> Would I still get same brightness as a genuine direct drive as when 
>>>>> using A92&A42 transistors? I suppose the switching that happens using 
>>>>> CLK/SDA on the HV5530 is not too different than a good multiplexing. I 
>>>>> may 
>>>>> be wrong.
>>>>>
>>>>> And if I were do code ASM to use HV5530, does anyone have sample ASM 
>>>>> code? I managed to write myself the code to read/write time from an RTC 
>>>>> using CLK/SDA so I suppose it's very similar but I cannot figure it out 
>>>>> from the datasheet of HV5530.
>>>>>
>>>>> Any help is much appreciated.
>>>>>
>>>>> Max
>>>>>
>>>> -- 
> 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/c2e49484-d56e-4545-b635-942952d2c1f4n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/neonixie-l/c2e49484-d56e-4545-b635-942952d2c1f4n%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/e7145848-36e9-48cc-a5c5-f5fec8fcbcdfn%40googlegroups.com.

Reply via email to