I set the Fuses as follows
LF=E2 (OSC)
HF=DA (Flash size)
EF=FC (BOD)
From this I read it will use the internal OSC to 8mhz
When I put the chip in the PCB
first tube displays 4
second displays blank
third displays 3
fourth display 4
fifth displays 3
sixth displays 4
I changed ```
if (millis() - laststrobeAtMs > 4 to 1 and lot less flicker
I changed uint8_t display[6] = { 0, 9, 1, 4, 5, 2 }; to 1,2,3,4,5,6
And not the display reads 34 34 34
I see where J4 is hooked to U3IC and the outputs are jumbled I guess that would account for the messed up display because of strobeing the tubes? I just checked the Documentation It still looks right.
Try commenting out the Serial.begin(). This is not appropriate if pins 0 and 1 are used by the application. It is a relic of my tests.
That something different is being displayed on the tubes is a good sign. I guess also the inputs to the K155 could be crossed.
The flicker indicates a low clock rate. You could try loading the standard blink sketch and see if the led blinks for one second on.
I think I found another root of the problem with this kit. It has been showing 3 & 4 across the tubes
no matter what I set K155ID1 to the two chip I have here are also blown!!!!
So I'll have to put this on hold till I get back to Buffalo next week to use the chips I have at home then pretty curtain they are good chips. But I should check the Opto-isolators to make sure that good as well even the DS3231 is now in question!! Maybe they went through a EMP!
So I'll get back with you later next week. Thank you very very much for your help and guidance!
I've looked at the data sheet for what appears to an equivalent of the k155id1
The 'D' pin is the high order bit and the 'A' the low order bit. This means the following statement group appears to be inverted:
// for later optimisation
digitalWrite(A, digits[display[tube]][3]);
digitalWrite(B, digits[display[tube]][2]);
digitalWrite(C, digits[display[tube]][1]);
digitalWrite(D, digits[display[tube]][0]);
It should be:
// for later optimisation (corrected)
digitalWrite(A, digits[display[tube]][0]); // A = 0
digitalWrite(B, digits[display[tube]][1]); // B = 1
digitalWrite(C, digits[display[tube]][2]); // C = 2
digitalWrite(D, digits[display[tube]][3]); // D = 3
This inversion was taken over from the code you originally supplied which appears in the meantime to have been deleted. Having said that, it can't explain everything because your test data "1,2,3,4,5,6" should have only showed even numbers so the 3 you saw is difficult to explain unless there is a wiring error between the k155id1 and the tubes.
Anyway, if there are further wiring errors on the output side of the k155id1 and that board you made up, these can, if it easier, be corrected in software if the error is always consistent. That is for example whenever a 5 should be displayed an 8 is displayed instead and all digits are displayable even if the "wrong" digit has to be sent.
One other odd thing that I have noticed on that schematic is that the resistors comprising the voltage divider on the ~170v output of the Nixie power supply appear to be interchanged. The MC34063 has a 1.25v reference. That voltage divider should deliver approx 1.25v at 170v. It looks like it is delivering nearer 169v which would surely destroy the chip. I'm guessing that on the board, the labels R2 and R3 have been interchanged otherwise the tubes would not have lit at all.
If you are still seeing problems with displaying the correct digits after making the code correction (post #28), check that the board matches the schematic
ATmega328 pin K155ID1 pin
(package pin)
------------- -----------
18 ..... 3
19 ..... 4
2 ..... 6
3 ..... 7
and that no pin is directly grounded, connected to Vcc, or connected additionally to another K155ID1 pin (maybe through an solder bridge etc.)
I seen no solder jumpers, I'm pretty good at soldering to say the least.
I sent Onsemi a question about that MC34063 as shown in the schematic you posted. I want to see what they say about that.
As far as the K155ID1 I'm going to breadboard the chip and see whats going on there with the help of some LED's. Maybe I'm spinning my wheels now that he replied what I typed below.
Maybe even spin my own clock now that your helping. I've learned much! Thank you!
What do you think should his be in PM?
As far as the defective parts. I put in a dispute with Paypal and now the guy asked me how many chips I need if I'd remove the Paypal dispute. Go figure.
Getting a set of numbers to display across six multiplexed Nixie tubes is relatively simple assuming the hardware is there and correctly documented. The big work is in the user interface part to configure the correct time, and timezone for correct DST handling and, if required, setting alarms etc.
It looks like you have only 3 buttons to get all that stuff in so it will be quite miserable to set up.
The Nixie clocks I have built (3 in all so far plus some VFD clocks) generally are based on an ESP8266 (I'd use ESP32 in future) and have a web interface for such configuration settings and use NTP or GPS as a time source. I would not really want to use an ATmega328P for that unless using GPS as a time source and prepared to hard code the time zone settings so no configuration is required at all.
What I would recommend is getting at least one of those kits working with the original firmware. If you can get something displayed correctly on the tubes and you can verify the performance of the DS3231 there is not much left to go wrong and if the supplied ATmega328P chips don't work then you can be confident that the problem is with the chips themselves and should be able to convince the supplier also. I could imagine that the supplied chips have their lock bits set so you are restricted with what you can do with a programmer (apart from wiping them completely for reuse). Secondly, if you want to consider your own design, keep the main components from the other kits and maybe redesign the clock using one of the many Arduino designs out there for the control logic. The main thing is having the source code so you can modify it yourself.
For the design of the Nixie tube pcb pads, I'd recommend something like this taken from https://www.tindie.com/products/akafugu/vfd-modular-clock-iv-6/ :
These are much nicer if you have to replace some tubes. Maybe, though, not all board houses can do these what I guess are internal castellated pads but, looking closely, the guy could have broken out the centre section himself.
I got a positive response from the seller and he now willing to send me three ATMEGA328P's.
Hopefully with this I can get a clock working as designed with some change in wiring as so of the lines going to the cathodes do not line up o my pins on my board even though his schematic of the wiring don't even match with his board, I verified this ohming them out from the K155ID1 to the output 1~0 on the PCB for the Cathodes.
0>8
1>7
2>1
3>2
4>5
5>6
6>4
7>3
8>0
9>9
So till I get the chips his program may be correct with the software.
No wonder I was getting Such crazy numbers!
I do like the PCB you had for the link I like your recommendations
Again, thank you for the help, I owe you a cup of coffee!
Now that I'm home I can check out this other kit to see if this micro is good but I do have to rewire the cathodes on my board. FYI, That guy sent me 3 chips I asked for, not sure how long from Lithuania. Again thank you for the help!
We'll look forward to hearing some sort of success story out of all this. I'm always fascinated by Nixie clock projects and I have in stock enough tubes to build two more 6 digit clocks. These will anyway to my own design because developing them is half the fun. The other half is seeing them in action. The weird ordering of the cathodes you have mentioned may be to do with the pinouts of the recommended tubes for that design and these may not always follow a logical order.
I agree on the pinout but his Doc shows in order. Anyway I found my third kit. That chip is won't read in my programmer and I also found out they are ATMEGA168P and from what I read the difference is minor and double the programming space, but his schematic show 328P that's why I really never looked at the chip. The new chips should be here next Wednesday.
Well the chips came in today. The new chips worked. I sent him a picture of it working and thanked him. Case closed. I still owe you a coffee!
1 Like
I think I had something else going on before I need to run your code as we first started.
If you would I'd love to collaborate on clock design that would use either Nixie or VFD's
I have a few hardware ideas, but like I said I'm not good at software but can hack something else to some degree to get by.
I'm pleased that that story ended well.
That's great. What I prefer is that we work in an thread in this forum so everything is public and other people can bring in their ideas too and possibly benefit also. I have a basic controller design which gives a web interface for setting up the clock with time zone etc. and can synchronise with NTP (internet time) so adapting it for whatever design you decide on should be no problem. Currently it esp8266 based but the next application will be ESP32 based. Anyway, when you have narrowed down your choice of tubes and clock features, just open a thread and point it out to me.
I'll send you my paypal account by PM so you buy me that coffee!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.