ICE TUBE Second digits are DIM

[remote_m]

I recently assemble the ICE TUBE clock and the second digit is dimmer than the other digits. Any help would be appreciated.
Also while in the menu some digits appear more dim than others... Dont know if that is also related or not.

Thanks.

IMG_0060.JPG (179.7 KiB) Viewed 2896 times

IMG_0063.JPG (134.8 KiB) Viewed 2896 times

IMG_0064.JPG (133.62 KiB) Viewed 2896 times

[adafruit_support_bill]

There is typically a brightness gradient from one end of the tube to the other. (see the last entry in the FAQ) Since these are NOS tubes there is a lot of variability and it shows on some more than others.

[wbp]

Is this the last digit only? I think I have just discovered a fix for this... Do you have the ability to reprogram your clock?

William

[KennyP]

I have the problem with the last digit only ... actually it appears to me like the digits get steadily dimmer going left to right. I'm interested in rolling my own firmware for the clock... can you tell me what the fix is for this?

Is this the last digit only? I think I have just discovered a fix for this... Do you have the ability to reprogram your clock?

William

[wbp]

BY "roll your own" do you mean make changes to the code or download an alternative firmware and load that? I just finished an update in my firmware that has a menu option for this change. All I did was add an option to display the last digit twice in the output multiplexer routine.

I added a definition for "lastdigit":

Code: Select all

uint8_t currdigit = 0;        // which digit we are currently multiplexing
uint8_t lastdigit = DISPLAYSIZE-1;  // last digit before starting over
volatile uint8_t ldbb = 0;  // Last Digit Brightness Boost

Then I changed "setdisplay":

Code: Select all

// This changes and updates the display
// We use the digit/segment table to determine which
// pins on the MAX6921 to turn on
//void setdisplay(uint8_t digit, uint8_t segments) {  // wbp
void setdisplay(uint8_t digit) {
   if (digit > lastdigit)
      digit = lastdigit;  // hack to display last digit twice
  uint8_t segments = display[digit];
  uint32_t d = 0;  // we only need 20 bits but 32 will do
  uint8_t i;
  // Set the digit selection pin
  d |= _BV(pgm_read_byte(digittable_p + digit));
  // Set the individual segments for this digit
  for (i=0; i<8; i++) {
    if (segments & _BV(i)) {
      t = 1;
      t <<= pgm_read_byte(segmenttable_p + i);
      d |= t;
    }
  }
  // Shift the data out to the display
  vfd_send(d);
}

Then this in the "SIG_OVERFLOW0" routine:

Code: Select all

  // Cycle through each digit in the display
  // Set the current display's segments
  setdisplay(currdigit);
  // and go to the next
  currdigit++;

   // currdigit is allowed to go past the end of display bytes.
   // setdisplay will limit the max index value
   // this has the effect of displaying the last digit multiple times
  if (currdigit > lastdigit+ldbb)  // hack to display last digit twice - wbp
    currdigit = 0;  // start over with first digit

"ldbb" stands for "last digit brightness boost" - set it to 1 to brighten the last digit.

William

[KennyP]

Thanks for the quick reply and code. I don't have my AVRProgrammer yet, but my plan is to write my own firmware (probably starting from the "stock" firmware) to run the display a bit differently, and to do a wifi mod similar to viewtopic.php?f=41&t=23116 . Just looking over the code I didn't see any obvious reason for the display to dim from left to right ... maybe it's just my clock ... but I thought while I was at it I'd see if I could fix that as well.

*EDIT*
I just came across the post by neutron spin in viewtopic.php?f=41&t=13057&start=15 explaining the reason for the gradual dimming (due to the driving of the tube filament with d.c.). So I'm now thinking of adding way to vary the brightness of each digit independently.

[wbp]

(obviously) my hack is not going to fix gradual dimming. it was done as a quick fix for the tubes that have a significantly dimmer last digit - I've seen two now that exhibit this.

It will be interesting to see what you come up with. Since SIG_OVERFLOW0 is running at around 30 kHz, it should be pretty easy to have an array of values, one for each digit, which controls how long the digit is on for. Or, the current display update runs at around 900 hz per digit, plenty of room for tweaking there too. The challenge will be to do it without making the refresh rate too slow, and without messing up the millisecond timer. Sounds like fun!

William

[cgpiper]

The coding change to "fix" the second digit is neat. Do you know of a source that would recode a chip for resale? I don't have any of the programming tools for this, but the option would really improve the readability. Did your programming change make the difference you sought?

[wbp]

I tested the coding change and it works, I have "on 8888" and "off 8888" in the menu so you can easily see the difference. Thing is, with my own clock the digits are very uniform, so I don't need it. I'm actually curious if this might be due to the way I handle the interrupts, it is a bit different from the "stock" firmware...

If you want I can program a chip and send it to you for a reasonable fee, assuming you are in the US - how does $20 sound (chip, programming, Priority Mail)? I don't think it makes sense for you to send your chip to me because they cost less than the postage to send it ($3.17 at Mouser). Or you could purchase a USBtiny for $22 and program it yourself (when they come back in stock).

William

[kinderwood]

wbp,
I just tried the firmware you uploaded and it does seem to help the last digit brightness problem on my tube. The last digit is quite a bit dimmer than the others though. Is there any way to increase the brightness further by display the digit more than two times? Such as changing

Code: Select all

  if (currdigit > DISPLAYSIZE)  // hack to display last digit twice - wbp

to

Code: Select all

  if (currdigit > DISPLAYSIZE+1)  // hack to display last digit twice - wbp

Any advice would be appreciated, thanks!

[neutron spin]

wbp,
I just tried the firmware you uploaded and it does seem to help the last digit brightness problem on my tube. The last digit is quite a bit dimmer than the others though. Is there any way to increase the brightness further by display the digit more than two times? Such as changing

Code: Select all

  if (currdigit > DISPLAYSIZE)  // hack to display last digit twice - wbp

to

Code: Select all

  if (currdigit > DISPLAYSIZE+1)  // hack to display last digit twice - wbp

Any advice would be appreciated, thanks!

Sorry but messing with the code is not a fix for this situation. If it really bothers you perhaps purchase a couple tubes and you may get lucky and get one that is a little brighter and the gradient will not be as noticeable. These tubes as hashed out in earlier discussions were designed to use AC for the filament and the gradient is due to the use of DC on the filament. These tubes are nothing more than triode vacuum tubes and each have slightly different emissions or transconductance. Also the phosphor on the anodes vary between different tubes. Other than a re-design of the clock (which is unlikely) you will have to live with this...

[wbp]

neutron spin - I don't understand the negativity - what's wrong with messing with the code if it works? And it does... All we're doing is changing the duration of the last digit. In fact some of us have been discussing a way to set the display times on a digit by digit basis, not all that hard and could be a nice way to even out an uneven tube.

kinderwood - your change would increase the display time of the last digit by 50%, so try it and let us know what happens.

William

[neutron spin]

neutron spin - I don't understand the negativity - what's wrong with messing with the code if it works? And it does... All we're doing is changing the duration of the last digit. In fact some of us have been discussing a way to set the display times on a digit by digit basis, not all that hard and could be a nice way to even out an uneven tube.

kinderwood - your change would increase the display time of the last digit by 50%, so try it and let us know what happens.

William

I am not being negative...just explaining the physics behind the design. What will you do as the tube ages...as all vacuum tubes do?....just tweak the code again or perhaps it may make a digit brighter or will the tweak actually make the digit(s) age prematurely? Then when the user replaces the tube...as it will happen eventually...will they have to "tweak" it again to even out the brightness between the digits ?....just sayin!

[wbp]

It's a hack! and it's a menu option, it can be turned off as easily as it was turned on (in my firmware anyway). I have two clocks. One has perfectly even digits, the other has a noticeably dim last (rightmost) digit. This simple hack made it look much better. If it wears the tube out sooner (which I doubt), then I'll throw in another one, not exactly a big deal. But meanwhile I'm making use of the tube that came with the clock.

[kinderwood]

neutron spin, I appreciate your input, and I will admit that fixing this in software is not an ideal solution. However, given the hardware constraints it is the most practical way to solve the problem. The gradient on mine is not a gradual decrease in brightness from left to right, but rather all digits are bright and perfectly readable, except the last. With the default adafruit firmware, I could barely read the digit at 50% brightness even in a dark room. Obviously the situation was even worse in a lit room. The display needed to be turned up to 90% for readability. That is not a usable state. This simple fix has helped make the clock more usable, and more aesthetically pleasing. If it shortens the lifespan of that digit, so be it, I could barely see it at all before this hack, so what am I losing?

wbp, thank you very much for your suggested changes to the code. I am a hardware guy, not a software guy and your code helped a lot as a good starting point. The fix works quite well, and I can bring the last digit up until it is just barely dimmer than the second to last digit. I do have to display it for more than one extra cycle though! Displaying it 3 or 4 times for every display cycle seems to do the trick. I suppose I got unlucky with the tube I got, a combination of bad tolerances added up. I think I may attempt to refine the solution further changing the timings of the refresh rate and perhaps changing the order of the digit display, interleaving the last digit displaying with the others. Such as 0,1,8,2,3,8,4,5,8,6,7,8. That way instead of simply displaying the last digit longer at the end, it is displaying it more frequently. Not sure if the overall effect would be better or not.

I did not mean to stir the pot so to speak. I simply had a last digit that was so dim I could barely read it, and wanted to attempt some way to improve it to a more usable state. I may also attempt buying a few spare tubes and adafruit tube PCBs and headers. I agree with neutron spin that this may shorten the lifespan as it effectively doubles or triples the amount of on time for that digit only. I am not sure what contributes to loss of phosphor efficiency exactly, on time, loss of vacuum, or diffusion of impurities in the phosphor are all candidates I suppose.