Nixie Clock 2 - Revision history

Alnwlsn: /* Python control program (rev1) */

2020-01-30T03:50:01Z

Python control program (rev1)

@@ Line 62: / Line 62: @@
          return
      psend = b'\x03'+nvar.to_bytes(4, byteorder='big')+b'\x00'
      sock.sendto(psend, (IP,PORT))
 </pre>

Alnwlsn: /* Files */

2020-01-29T03:07:08Z

Files

← Older revision		Revision as of 23:07, 28 January 2020
Line 89:		Line 89:
	* [[File:Nixie2-hardware.zip]] - Hardware files - PCB and STL for case		* [[File:Nixie2-hardware.zip]] - Hardware files - PCB and STL for case
	* [[File:Nixie2-software-rev1.zip]] - Arduino sketch and Python functions		* [[File:Nixie2-software-rev1.zip]] - Arduino sketch and Python functions
			===Revisions===
			====Software====
			* Revision 1 - first version, supports setting the RTC from the computer's time, and displaying integers on the tubes

Alnwlsn: /* Files */

2020-01-29T03:00:40Z

Files

← Older revision		Revision as of 23:00, 28 January 2020
Line 88:		Line 88:
	==Files==		==Files==
	* [[File:Nixie2-hardware.zip]] - Hardware files - PCB and STL for case		* [[File:Nixie2-hardware.zip]] - Hardware files - PCB and STL for case
			* [[File:Nixie2-software-rev1.zip]] - Arduino sketch and Python functions

Alnwlsn: /* Notes on the firmware */

2020-01-29T02:59:50Z

Notes on the firmware

← Older revision		Revision as of 22:59, 28 January 2020
Line 68:		Line 68:
	To make the PCB design easier, I drive the tubes "out of order"; the digits do not display in the same order the shift register sends out data. So, I need to shift some bits around before the display comes out looking right. Here's the routine I came up with. It isn't very elegant but gets the job done. This will display a long unsigned int on the tubes, with a decimal point mask.		To make the PCB design easier, I drive the tubes "out of order"; the digits do not display in the same order the shift register sends out data. So, I need to shift some bits around before the display comes out looking right. Here's the routine I came up with. It isn't very elegant but gets the job done. This will display a long unsigned int on the tubes, with a decimal point mask.
	<pre>		<pre>
	void nixie(long k, byte dp){		void nixie(long k, byte dp){ //displays data on tubes; k is the number, dp is a decimal point mask
	byte dig0=(k%10);		byte dig0=(k%10);
	byte dig1=(k%100)/10;		byte dig1=(k%100)/10;
Line 82:		Line 82:
	digitalWrite(srLatchPin,LOW);		digitalWrite(srLatchPin,LOW);
	digitalWrite(srLatchPin,HIGH);		digitalWrite(srLatchPin,HIGH);
			yield();
	}		}
	</pre>		</pre>

Alnwlsn: /* Python control program */

2020-01-29T02:16:57Z

Python control program

@@ Line 40: / Line 40: @@
 |}
-===Python control program===
+===Python control program (rev1)===
-Of course, to make things a little more useful, I needed some way to generate the UDP packets other than by writing them by hand, and then send them. You can do this however you want; I made a few Python functions to do some of the common things.
+Of course, to make things a little more useful, I needed some way to generate the UDP packets other than by writing them by hand, and then send them. You can do this however you want; below are a couple Python functions to set the RTC time and display integers on the tubes.
-[COMING SOON]
+<pre>
 ===Notes on the firmware===

Alnwlsn: /* Notes on the firmware */

2020-01-27T03:45:33Z

Notes on the firmware

← Older revision		Revision as of 23:45, 26 January 2020
Line 45:		Line 45:

	===Notes on the firmware===		===Notes on the firmware===
	To make the PCB design easier, I drive the tubes "out of order", so I need to shift some bits around before the display comes out looking right. Here's the routine I came up with. It isn't very elegant but gets the job done.		To make the PCB design easier, I drive the tubes "out of order"; the digits do not display in the same order the shift register sends out data. So, I need to shift some bits around before the display comes out looking right. Here's the routine I came up with. It isn't very elegant but gets the job done. This will display a long unsigned int on the tubes, with a decimal point mask.
	<pre>		<pre>
	void nixie(long k, byte dp){		void nixie(long k, byte dp){

Alnwlsn: /* Electronics Overview */

2020-01-27T03:41:50Z

Electronics Overview

← Older revision		Revision as of 23:41, 26 January 2020
Line 13:		Line 13:
	I made a couple mistakes in PCB revision 1: a missing resistor on the I2C bus, and trying to use GPIO15 as the shift register latch pin, without realizing the logic level converter I made pulls it low on startup, not allowing the ESP8266 to boot. I fixed this by cutting the trace and attaching it to another pin.		I made a couple mistakes in PCB revision 1: a missing resistor on the I2C bus, and trying to use GPIO15 as the shift register latch pin, without realizing the logic level converter I made pulls it low on startup, not allowing the ESP8266 to boot. I fixed this by cutting the trace and attaching it to another pin.

	==~~Electronics~~ Overview==		==Control Overview==
	Again, the base design is almost the same as in [[Nixie Clock 1]]. A small switch mode boost converter converts 9 VDC to about 185 VDC. Each tube has its own K155D1 driver IC that switches the digits on and off. These are BCD decoders; each one takes in 4 input lines, which covers the input range [0-9] in binary. A 74HC595 shift register has 8 output lines, so I connect 2 K155D1s to each shift register, and use 3 shift registers hooked in series. A 4th shift register is used to switch the 6 tubes' decimal points through dedicated transistors. I can therefore control all 6 tubes using only 3 pins over an SPI compatible interface, but I need to use a level shifter to change the 5V of the shift register / K155D1 voltage to the 3.3V of the ESP8266.		Again, the base design is almost the same as in [[Nixie Clock 1]]. A small switch mode boost converter converts 9 VDC to about 185 VDC. Each tube has its own K155D1 driver IC that switches the digits on and off. These are BCD decoders; each one takes in 4 input lines, which covers the input range [0-9] in binary. A 74HC595 shift register has 8 output lines, so I connect 2 K155D1s to each shift register, and use 3 shift registers hooked in series. A 4th shift register is used to switch the 6 tubes' decimal points through dedicated transistors. I can therefore control all 6 tubes using only 3 pins over an SPI compatible interface, but I need to use a level shifter to change the 5V of the shift register / K155D1 voltage to the 3.3V of the ESP8266.

Line 39:		Line 39:
	\| 0x03 \|\| Display number on the tubes. Data format is an unsigned long (4 bytes, MSB first), followed by a bitmask for the decimal points.\|\| {four,bytes,unsigned,long, decimal mask}		\| 0x03 \|\| Display number on the tubes. Data format is an unsigned long (4 bytes, MSB first), followed by a bitmask for the decimal points.\|\| {four,bytes,unsigned,long, decimal mask}
	\|}		\|}

			===Python control program===
			Of course, to make things a little more useful, I needed some way to generate the UDP packets other than by writing them by hand, and then send them. You can do this however you want; I made a few Python functions to do some of the common things.
			[COMING SOON]

	===Notes on the firmware===		===Notes on the firmware===

Alnwlsn: /* =UDP packet format */

2020-01-27T03:20:23Z

=UDP packet format

← Older revision		Revision as of 23:20, 26 January 2020
Line 22:		Line 22:
	I use raw UDP packets for remote control. UDP is a good choice for something like this - for realtime display applications like this, we want fast response of the display, and don't care that much about lost packets because new data is being sent all the time.		I use raw UDP packets for remote control. UDP is a good choice for something like this - for realtime display applications like this, we want fast response of the display, and don't care that much about lost packets because new data is being sent all the time.

	====UDP packet format===		====UDP packet format====
	When a UDP packet is received by the clock, it looks at the first byte, and uses that to decide what to do with the rest of the bytes.		When a UDP packet is received by the clock, it looks at the first byte, and uses that to decide what to do with the rest of the bytes.

Alnwlsn: /* UDP control */

2020-01-27T03:19:56Z

UDP control

@@ Line 20: / Line 20: @@
 ===UDP control===
 In normal operation, the tubes display the hour, minutes and seconds from the RTC on the tubes. At night time, all the tubes cycle through their digits to preserve the life of the tubes. Commands can be sent to the clock, which can set the RTC time, but also display raw data on the tubes instead. When a display command is sent, it will immediately display on the tubes, and stay that way for about 10 seconds, before returning to display of the time. So, to display something using the commands, it's best to update the tubes every few seconds.
 I use raw UDP packets for remote control. UDP is a good choice for something like this - for realtime display applications like this, we want fast response of the display, and don't care that much about lost packets because new data is being sent all the time.
 ===Notes on the firmware===

Alnwlsn: /* Notes on the firmware */

2020-01-27T03:04:36Z

Notes on the firmware

← Older revision		Revision as of 23:04, 26 January 2020
Line 22:		Line 22:
	I use raw UDP packets for remote control. UDP is a good choice for something like this - for realtime display applications like this, we want fast response of the display, and don't care that much about lost packets because new data is being sent all the time.		I use raw UDP packets for remote control. UDP is a good choice for something like this - for realtime display applications like this, we want fast response of the display, and don't care that much about lost packets because new data is being sent all the time.

	===Notes on the firmware===		===Notes on the firmware===
	To make the PCB design easier, I drive the tubes "out of order", so I need to shift some bits around before the display comes out looking right. Here's the routine I came up with. It isn't very elegant but gets the job done.		To make the PCB design easier, I drive the tubes "out of order", so I need to shift some bits around before the display comes out looking right. Here's the routine I came up with. It isn't very elegant but gets the job done.
	<pre>		<pre>