Vacuum Fluorescent Display Driver

[pqass]

Page 53 on the schematics show things like VFDSCLK, but the label changes to BVFDSCLK. On the front panel schematic it's shown again as VFDSCLK.

I've soldered the wires to the three pins (12, 16, and 18), but wanted to verify this is correct. Normally the "B" would indicate a different node, but I'm guessing this was done because they go through the series current limiting resistors and the two nodes can't have the same name.

It's just odd they revert to removing the "B" when it goes to the front panel board.

This should be fine.
I don't think you'll have an issue driving the extra inputs of the 1488 through the 1K resistors.
Schematics don't always make sense; can be contradictory.

[bostonman]

Thanks.

Seemed odd to rename the node names, but, as you stated, schematics don't always make sense.

I agree and assumed the 1k resistors (1.92k on VFDSEN) won't affect anything. Just wanted to confirm I wasn't overlooking the nodes going elsewhere.

[bostonman]

I began building the external display circuits on a perf board, however, I got annoyed at trying to run all the jumpers, so I made a PCB.

Attached is the schematic. It began as a simple circuit, but I didn't want to make two separate boards, and put everything on one board with the idea I'll only populate what is needed for each board.

Unfortunately I didn't create a good schematic because I used too many ports. I should have placed the connections next to the IC rather than separate the circuits with ports. Also, my pet peeve is placing too many circuits on a single page, and I did just that.

I'm uncertain whether I'll use all the "features" I placed on the board, but thought have LEDs would be cool, connectors for future troubleshooting, and a regulator should I need one rather than use the one on the Arduino.

[bostonman]

Thankfully this past weekend I made time to somewhat complete the external display.

The "transmitter" board (the SN75188 portion) is installed in a 3D printed box mounted to the inside side panel. All connections from the counter PCB go to this box, and then an eight wire twisted pair Ethernet cable goes from this box to the rear panel where I installed a connector.

The external "receiver" board (the SN75189 portion) is connected to the same type eight wire twisted pair Ethernet and plugs into the rear panel of the counter where I installed the connector. Due to not knowing whether this would work and location of the external display, I left this cable long, approximately 3' (1m).

This "receiver" board makes all the connections (currently a hacked wiring job) to the Arduino; and then from the Arduino to the display (also currently a hacked wiring job).

For the external display, I went with: HiLetgo HD44780 2004 LCD 20x4 2004A Character LCD Screen Display Module Blue Backlight with IIC/I2C Serial Interface Adapter

Things seem to work well except for two issues. The first is poor refresh rate on the external display. I increased the counter gate time to two and three seconds, and both still showed ghosting. It's quite poor quality and not exactly ideal for taking measurements. I thought this size display would be nice and why I went with it.

Any suggestions on a nice size display with a good refresh rate?

The other is the counter front panel displays fine, but the external display places an 'X' where any and all numerical digit 3s' go. Unless it's also missing something else that hasn't been displayed yet (or I overlooked) all numerical digits display fine except the number '3'.

Maybe I overlooked a connection or a wire broke, but would think a missing connection would have more than just a single number display wrong.

[bostonman]

Earlier I checked many functions of the counter and the external display seems to display everything just fine except the number '3' regardless of position. The front panel (VFD) on the counter displays just fine.

[pqass]

The other is the counter front panel displays fine, but the external display places an 'X' where any and all numerical digit 3s' go. Unless it's also missing something else that hasn't been displayed yet (or I overlooked) all numerical digits display fine except the number '3'.

Earlier I checked many functions of the counter and the external display seems to display everything just fine except the number '3' regardless of position. The front panel (VFD) on the counter displays just fine.

It would appear you've found a bug in the software. 
Given your counter displays the flat-top "3" (see your reply #129), the code probably doesn't expect that so it substitutes "x". 
From hp_msg_parse.cpp:

Code: [Select]

/* map a character segments combination into a character to display, x for unknown */
uint8_t map_seg14_code_x(uint16_t segs14) {
  for (int i = 0; i < seg_n; i++) {
    if (seg_codes[i] == segs14) {
      return seg_mapped_chars[i];
    }
  }
  add_unk_seg14(segs14);
  return 'x';
}
Where seg_codes[ ] is initialized in segmapgen.c  whose 4th value (index 3) is 0x4489 corresponding to seg_mapped_chars[ 3 ]="3".

Given the front panel schematic 75518 pin mapping to segments and what you've provided here, I'll have to confirm which bit in seg_codes[ i ] corresponds to which segment.  Then you can change that 0x4489 value accordingly for your style of "3".

[bostonman]

Wow, you're awesome!

I was thinking about this logically and was stuck on the hardware being an issue (especially since I hacked the wiring on the Nano and display to confirm the design worked before making a 3D box to hold everything.

With everything else displaying correctly, I couldn't figure out what it would be.

It didn't occur to me that the software could have a bug, but, even more, remembering I have a flat top '3'.

Once I get this fixed, then it's a matter of whether a better display exists. The ghosting is really bad in my opinion and makes reading the numbers difficult.

[pqass]

I've manually confirmed the first 4 elements of seg_codes[ ] and the bit patterns correspond to the segment ordering: EDJNMCPQAILKBFGH
For a flat-top "3", the K segment should be 1 vs the B segment of a normal "3"
So, replace the 0x4489 with 0x4491 in the segmapgen.c file.  Recompile, then re-flash.

[bostonman]

Thanks.

I should have time either tomorrow or over the weekend. Maybe I'll comment the line instead and add the new HEX code with a comment on why it's different.

Wish I knew more programming rather than a few basic 'Hello World!' stuff, then maybe I could have found this myself and/or followed along with your analysis.

[bostonman]

Wow, that did the trick.

Not only would this external display project never have taken place without the assistance of this thread (not including the many others who have contributed to questions in other threads), but I would have been lost with the X in place of a 3.

I have to ask, but sure it's not worth typing, so don't trouble yourself, but how did you understand how to change the HEX code to that number? I would have assumed seven (if I counted correctly) segments would need to be a '1' in order to produce a '3', but the HEX code you told me to use is 17545 in decimal and neither the HEX or DEC code seem to make sense of it.

Obviously I don't know C well (I can read some of it and understand it), but I couldn't follow it, so I was lost when I tried to make sense of things (hence why I wouldn't have solved this on my own).

As for the ghosting, now that I have the hardware and software working, I'll have to experiment with other displays. I assume the ghosting isn't related to cable length or anything like that, it's just slow to refresh.

Also, I have two questions. The first is somewhat easy. In the steps to program the Nano, I have to download "hd44780" by Bill Perry version 1.3.2. In order to preserve the files for future needs should this library go extinct, does a way exist to save this as a local file so I can program more Nano units in the future should something happen to this one (obviously I can buy a few extra spare Nano units and flash them)?

The other question is regarding whether I found another bug. When powering the unit, the external doesn't display all the characters (which is probably due to size restrictions), displays the pound sign instead of all the segments, and repeats some info (see the double -Wid?).

Is this normal or another bug?

[pqass]

For the external display, I went with: HiLetgo HD44780 2004 LCD 20x4 2004A Character LCD Screen Display Module Blue Backlight with IIC/I2C Serial Interface Adapter

Things seem to work well except for two issues. The first is poor refresh rate on the external display. I increased the counter gate time to two and three seconds, and both still showed ghosting. It's quite poor quality and not exactly ideal for taking measurements. I thought this size display would be nice and why I went with it.

I'm not sure if by "ghosting" you mean text update time or the faint square background.

These LCD modules are slow to react (they have a shitty MCU on-board) but could also be the LCD reaction time too.  So if you're updating multiple times per second it's probably not going to meet expectations.

From your picture of the LCD module, it doesn't look like you've connected pin 3 (VO).  It should be connected to a 10K pot to control/adjust the contrast. That's why there's a faint square behind each character.  Are you using your I2C module at all?  Because the project code (lcd_20x4_hd44780.cpp) doesn't look like it's using the functions to send to a I2C address.  Just like your I2C module (see here; 2nd and 4th images)  attach a 10K pot, wiper to pin 3, ends to Vcc and GND just like in the schematic.

The other is the counter front panel displays fine, but the external display places an 'X' where any and all numerical digit 3s' go. Unless it's also missing something else that hasn't been displayed yet (or I overlooked) all numerical digits display fine except the number '3'.

I knew it was a software bug given your description since if everything worked except "3" that told me the SPI link worked fine (not a flaky/length of cable issue).  The software's job is to map symbols (which anodes are on) to ASCII (what the LCD understands), ergo, it must not expect your (flat top) "3" since "x" is quite a deliberate substitution.  Checking the map_seg14_code_x() code confirmed it.  It even says in the README here (a blurb that I found after I'd checked the code first).

... but how did you understand how to change the HEX code to that number? I would have assumed seven (if I counted correctly) segments would need to be a '1' in order to produce a '3', but the HEX code you told me to use is 17545 in decimal and neither the HEX or DEC code seem to make sense of it.

I looked at the front panel schematic to understand the segment ordering and your segment-to-anode mapping.
Assuming SPI sends most-significant-bit first, each 16-bit seg_codes array element should have this bit-to-segment mapping: EDJNMCPQAILKBFGH
Decoding the first 4 array elements confirmed it; "0" has all outside anodes on, "1" has two center vertical anodes on, "2" has ABDEGH on, "3" has ABCDH on.
But that's not your "3". Yours is ACDHK which corresponds to 0x4491.   See attached.


WRT libraries... adjacent to your Arduino/hp_display project directory there's a Arduino/libraries/hd44780 directory. You can back that up too.  I doubt this library will disappear anytime soon; been around since 2014.  Besides, there are many LCD module libraries around that can be reworked.  I've made my own too from scratch using only the datasheet.

The other question is regarding whether I found another bug. When powering the unit, the external doesn't display all the characters (which is probably due to size restrictions), displays the pound sign instead of all the segments, and repeats some info (see the double -Wid?).

Is this normal or another bug?

Like I said, it's trying to map (anodes) symbols to ASCII but the LCD can't really accommodate the colon+semicolon as part of the same character nor the annunciators all on a 20 character line.
See the video here.   It's a "feature".

[bostonman]

I'm not sure if by "ghosting" you mean text update time or the faint square background.

By ghosting, the digits take about 1-2 seconds to fully turn off. I haven't used it to measure frequencies, but suspect trying to adjust a pot to calibrate a piece of equipment will not be easy. Even something simple like turning on/off x10 took a good two-seconds before the '0' fully vanished.

From your picture of the LCD module, it doesn't look like you've connected pin 3 (VO).  It should be connected to a 10K pot to control/adjust the contrast.

Initially I didn't connect this because I wanted to see how the display would look (and whether it worked). All I cared about at that point was whether my PCB and wiring was correct (which it was) and not how it looked.  When I saw a pot on the back (see attached picture - this is how the back of my LCD is), I turned it and the brightness increased/decreased, so I thought: okay, maybe this is already completed for me, so I didn't connect a pot.

Let me know if this is wrong, but I wasn't trying to cut corners or didn't follow the information, since the pot "worked", I just assumed the need for a pot wasn't necessary and I have a display that incorporated it for me.

I doubt this library will disappear anytime soon; been around since 2014.  Besides, there are many LCD module libraries around that can be reworked.  I've made my own too from scratch using only the datasheet.

I'm sure you're correct, but things seem to change fast. It may not necessarily be the library that vanishes, but incompatibility with the library and future Nano boards.

Also, since I'm not on the software end (I'm sure it's obvious), I'm limited on implementing software into new displays.

The good news (I think) is that all signals come out the back eliminating the need to work inside the unit for any future changes. Instead of dropping the +12V on the inside as I planned, I brought it to the rear of the unit for any future needs. Initially I was going to drop the 12v down to approx. 8v by going through six diodes, but thought it would be better to send 12v out the back and then drop the voltage on my external PCB.

I also planned to use the 5v regulator on the Nano (with 8v going into it) to power the external 75189, but placed a 5v regulator on my PCB instead since I had several dozen regulators in my inventory already.

As my schematic shows, I went overboard on the design, but figured, if I'm spending the time/money on a PCB, I might as well add everything onto it and then not populate whichever I felt wasn't needed later.

Now that I know my display works, maybe I'll dive into whether any better displays exist that have faster refresh. I'd really like to put this counter back on the shelf and move on though; but think the hard part is now over.

[pqass]

Initially I didn't connect this because I wanted to see how the display would look (and whether it worked). All I cared about at that point was whether my PCB and wiring was correct (which it was) and not how it looked.  When I saw a pot on the back (see attached picture - this is how the back of my LCD is), I turned it and the brightness increased/decreased, so I thought: okay, maybe this is already completed for me, so I didn't connect a pot.

Let me know if this is wrong, but I wasn't trying to cut corners or didn't follow the information, since the pot "worked", I just assumed the need for a pot wasn't necessary and I have a display that incorporated it for me.

I was concerned that you still have the I2C board attached and wires connecting RS,RW,E,D4-7 to your Nano at the same time; ie. connecting two outputs together for each line!   BUT then I looked at the datasheet for the PCF8574. It says:  "The internal Power-On Reset (POR) initializes the I/Os as inputs with a weak internal pull-up 100 μA current source."   So no concern here WRT connected outputs.  Just don't connect/use the SDA, SDL pins if you're driving the LCD in parallel mode.  And the existing I2C module pot is connected so no need for another external pot.

[bostonman]

The Excel spreadsheet you provided showing the binary and HEX codes made this much clearer. I tend to get overwhelmed by excessive documentation and don't put the pieces together (hence why I'm a better hands on tinkerer than creating). All the documentation will be there, but I just don't make the mental connections.

I wasn't focusing on the segments (that ironically I posted) but a binary '1' would display 1, binary '2' would display 2, etc...

Now that I understand, I could even replace segment C with M and have two diagonal lines for a '3'; but I won't mess with what works.

Yesterday I placed the cover on my counter in hopes of never needing to open it again (I'll post a pic of the board and 3D box I made). My plan is to improve the hacked wire connections on the Nano, make them permanent, and maybe make a 3D printed box for it (or I may wait and make one large box for the display and Nano); and actually 3D boxes for the Nano already exist online so I don't need to recreate the wheel.

Just to be clear, the Nano connections are connected to the display where the red arrow is (see attached). The Nano only has pin names on the silk screen where the headers are and where I soldered the wires (both for the input cable and wires going to the display). I contemplated making the Nano pretty, but figured let me see if this all works first; worst case I hack the Nano bad enough that I need a new one.

The display doesn't have any silk screen on the I2C board (I didn't know this is an I2C - I just thought it was something to house the display driver chip), so all wire connections go where the red arrow is. I'm assuming the outputs aren't tied together (although you confirmed this on the datasheet), so I don't need to concern myself with outputs tied together.

The SDA and SDL are for programming anyway, so I shouldn't need to touch those (unless I'm wrong).

Unless you see something wrong with how I wired it, guess the hard part is over.

The focus now is dealing with the display. Does the software limit me to a 20x4 display or can I go bigger, maybe LED (or something that refreshes faster)?

If something happens to the VFD, then beggars can't be choosers, so I'd settle on the current ghosting image display, but the ghosting would limit the ability to tweak something if you're trying to read digits in the 10s and 100ths place.

[bostonman]

WRT libraries... adjacent to your Arduino/hp_display project directory there's a Arduino/libraries/hd44780 directory.

Am I overlooking something? I had asked whether the HD44780 library by Bill Perry can be backed up should this be unable to be downloaded in the future. For some reason I can't seem to locate a directory as listed above.

Some confusion over alternate displays exist. It seems other displays are suggested in the Github docs, but not sure if they are compatible with the existing HD44780 (?) driver stuff.

I also purchased some tiny LCD displays (I think they were in the video), but they only have four connections: Vcc, GND, SDA, SCL.

Ignoring the fact I don't see any other connections, these are too small, but I'd like to get a display that doesn't ghost. Ideally a larger one would be great too.

The Github docs mention one that's similar in size to the existing, but I didn't see whether it's compatible with the existing code.

[pqass]

WRT libraries... adjacent to your Arduino/hp_display project directory there's a Arduino/libraries/hd44780 directory.

Am I overlooking something? I had asked whether the HD44780 library by Bill Perry can be backed up should this be unable to be downloaded in the future. For some reason I can't seem to locate a directory as listed above.

That is the installed location of the library if you are running version 2.x of the Arduino IDE (I assumed you are using).  If you're running 1.x.y of the Arduino IDE then you'll find it under <home dir>/arduino-1.x.y/libraries/hd44780   or  <home dir>/sketchbook/libraries/hd44780.

However, rather than save the post-install directory content, it would be better to just download the zip file direct from the github page here (press green Code button at top right, choose Download ZIP).  See main README file for installation instructions.

Some confusion over alternate displays exist. It seems other displays are suggested in the Github docs, but not sure if they are compatible with the existing HD44780 (?) driver stuff.

I also purchased some tiny LCD displays (I think they were in the video), but they only have four connections: Vcc, GND, SDA, SCL.

Ignoring the fact I don't see any other connections, these are too small, but I'd like to get a display that doesn't ghost. Ideally a larger one would be great too.

The Github docs mention one that's similar in size to the existing, but I didn't see whether it's compatible with the existing code.

There is a display-specific doc that discusses your display options.  You've got the default 20x4 HD44780 character display.  This is a parallel data interface that's become an industry standard since the early '80s.  The HD44780 controller ICs are under the black blobs on the main PCB.   However, this requires many control signals to the MCU so it is common to attach a serial-to-parallel daughter-board instead. These are I2C serial or SPI serial.  You have the former serial board attached (hence just SDA, SCL, and power pins).  But you're not using this mode and as I wrote earlier, the serial board won't interfere if you've directly attached the parallel signal wires to the MCU.

The project really only uses I2C or SPI to the small OLED displays so serial to the HD44780 is not an option for you without non-trivial code changes.  The display-specific doc says how to change the hp_display_config.h file (commenting/uncommenting #defines) to use one of the OLED displays instead of the parallel HD44780 character display.   And will also require a U8g2 serial library version 2.24.3.

With regards to ghosting... you can try slowing down the display update rate to say, half a second. 
Edit the lcd_20x4_hd44780.cpp file and insert the red lines below at around line 74.
(caveat emptor - it compiles and should work)

...
void lcd_20x4_hd44780_update() {
  static unsigned long lastmillis = 0;
  if ((millis() - lastmillis) < 500) return; else lastmillis = millis();
  static char line[LCD_COLS+1];

  if (disp_change & (CHANGE_TEXT_COMB | CHANGE_UNITS_COMB)) {
...

[PCB.Wiz]

By ghosting, the digits take about 1-2 seconds to fully turn off.

That seems strange, I do not recall Character LCD's being that slow.
Did you confirm with a scope that the data transfer was very fast? (ie it really is the optical display that is slow)

I did find a newhaven Char LCD spec
https://newhavendisplay.com/content/specs/NHD-C0220BiZ-FSRGB-FBW-3VM.pdf
that claims 
Optical rise time 150ms typ, 250ms MAX
Optical fall  time 200ms typ, 300ms MAX

that uses a 3.3V supply and a charge pump to increase LCD drive to 5.5V

This larger 4x20 display specs the same response times
https://newhavendisplay.com/content/specs/NHD-0420E2Z-FSW-GBW.pdf

[pqass]

I don't see any code to throttle-down the LCD update rate.   As soon as an SPI frame is received (see loop() in hp_display.ino) a call to lcd_20x4_hd44780_update() in lcd_20x4_hd44780.cpp is made where there are multiple pairs of lcd.setCursor(...) and lcd.print(line) calls.  Hence, the code in my previous post to stop the constant overwriting, giving the characters a chance to settle for 500ms.

[bostonman]

That is the installed location of the library if you are running version 2.x of the Arduino IDE (I assumed you are using).  If you're running 1.x.y of the Arduino IDE then you'll find it under <home dir>/arduino-1.x.y/libraries/hd44780   or  <home dir>/sketchbook/libraries/hd44780.

I need to focus more and not get overwhelmed by all the documentation. This was fully my mistake as I was searching the hp_display software directory and not the Arduino-IDE directory.

As for the tiny displays I have, I mentioned the SDA and SCL and didn't understand this was serial data; I thought these were programming pins (although the device doesn't have any noticeable chips that would be programmed).

Prior to reading these messages, I connected the small display to the Nano SDA and SCL to A4 and A5 respectively (update: and also 5V and GND) and didn't get any images. After reading the documentation, I came across needing to un-comment a line and got the error about needing U8g2 when I tried compiling; so I was on the correct track.

I'll try implementing the updated code you provided and will update after.

That seems strange, I do not recall Character LCD's being that slow.
Did you confirm with a scope that the data transfer was very fast? (ie it really is the optical display that is slow)

Just to clarify, the PCB I laid out has the wire holes next to the ICs, so the signals are not traveling far at all. On the other hand, the cable I used (which I'm kind of regretting due to it being too stiff) is typical twisted pair, but solid wire (hence the stiffness).

As mentioned, the cable lengths are a bit long and maybe this is an issue. Inside the unit the signal wires go from the main board to my "transmitter" board over about 12" (I'm estimating the higher end). From that board (which is now providing buffered signals) about another 12" to the connector I installed on the rear of the unit.

The external cable that plugs into the rear to my "receiver" board is about 3' (1m). From there maybe another 12" to the Nano, and then about 8" of wire for all the lines to the display.

I went overboard on wire lengths due to not being sure whether I'd be cutting wires due to troubleshooting, external display location, etc... Maybe the lengths are too long and causing issues.

I'll gladly measure signals with a scope (and why I incorporated test connectors onto my PCBs).

Are you asking I measure "data transfer" by comparing signals from the transmitter board and when they are received by the receiver board or for rise time at the receiver end (or both)?

[pqass]

Are you asking I measure "data transfer" by comparing signals from the transmitter board and when they are received by the receiver board or for rise time at the receiver end (or both)?

Your wire length is fine. It's not about the propagation or rise time of a digital signal down a wire.  It's about the frequency of the E signal (pin 6). 

Every time the E signal is toggled (low-high-low) a new 4-bit word of command or data (in D4..D7) is transferred to the LCD.  A SetCursor command (~2ms) or PrintCharacter command (~40us) each need two E toggles to transfer so it should take 2+20*2 E toggles to transfer a whole line. Times that by four for a whole display (or about 8ms). If the MCU sends as fast as the LCD can receive it then that's a 125Hz update rate.  That's unnecessarily fast which may be the cause of your ghosting.  These displays have memory and do their own multiplexing so the MCU should limit the update rate to what a human can perceive (2-10Hz) which should allow each character to settle.

[bostonman]

I changed the code to 500ms and it became unbearably slow. So slow that I enabled 50ohms and the main screen cleared the words before the external display showed it.

After I tried 50ms and that was faster (obviously), but still slow.

I took scope captures of the E line (see attached), but getting the scope to trigger was impossible, so doubt this is useful. The pulses kept jumping phase regardless of triggering or trying to find something on the Nano to use as a trigger.

Also, I managed to get a picture of the external display in transition (prior to trying the 500ms code) to give an idea of what I'm seeing.

[pqass]

I see what you mean by ghosting now.

I wanted to recreate it myself so I modified the HelloWorld Arduino example (from the IDE: File -> Examples -> LiquidCrystal -> HelloWorld).  The loop() function is hammering setCursor() and print() as fast as possible (no delays) but the static "Hello World" text seems fine/stable; no flickering (see attachment).  This destroys my earlier argument that constant fast updates causes redraw flicker due to an erase before writing a character.   In hindsight, this makes sense since a data write is just updating memory inside the LCD controller.  The controller is still multiplexing at its normal pace.   However, I've modified the HelloWorld example to "millis()/100" instead of the original "millis()/1000" (see code below).  This causes the rightmost digit to be blurry. This confirms that a data change at 10 times per second makes it unreadable.  Given what PCB.Wiz wrote about rise/fall-times, it looks like you could probably only get 2 updates per second to maintain some readability.  Yes, these LCDs do suck.

Code: [Select]

void loop() {
  lcd.setCursor(0, 1);
  lcd.print(millis() / 100);
}

But I'm at a loss to understand how a fast update is usable even on the main VFD. The value is useless except to tell you the source isn't constant.  The same behaviour is seen in the project video at the 1 min mark .

If you want to snapshot the ever changing numeric value at twice per second, make the following code changes in red to the lcd_20x4_hd44780.cpp file.
This should still keep annunciator/label changes reacting instantly.

void lcd_20x4_hd44780_update() {
  static unsigned long lastmillis = 0;
  static bool canUpdate = ((millis() - lastmillis) > 500);
  if (canUpdate) lastmillis = millis();
  static char line[LCD_COLS+1];

  if (canUpdate && disp_change & (CHANGE_TEXT_COMB | CHANGE_UNITS_COMB)) {
    // check if we can fit text/numbers and units in one line
    if ((disp_text_combined_len + 1 + disp_units_combined_len) <= LCD_COLS) {
...

[bostonman]

Did I overlook something or did you not post the video? Besides the 'hello world' picture, I see a blurry picture (I assume this is the video).

I apologize, I'm a bit confused over the issue. The data is "hammering" the controller, but that doesn't change the refresh rate the controller is updating the screen, correct?

If this is correct, then why would the ghosting exist if the controller is made the communicate with the display at a rate it can (or should) handle?

But I'm at a loss to understand how a fast update is usable even on the main VFD. The value is useless except to tell you the source isn't constant.  The same behaviour is seen in the project video at the 1 min mark here.

I'm uncertain how others use their their counter, but in almost all cases I reference it to a Cesium atomic clock and adjust stuff that requires calibration. A slow moving counter will make tweaking a piece of equipment harder whereas I can see how the frequency is changing instantly.

Maybe I'm use to doing it my way, but it's typically how I utilize my counter.

Actually, after reassembling it, I wanted to adjust the reference on the counter by feeding a 10MHz from the Cesium. I think the spec is 10MHz +/- 5Hz and having a fast moving display allowed me to gt it better than 5Hz; although I know these type circuits will deviate over temp/time.

[pqass]

Did I overlook something or did you not post the video? Besides the 'hello world' picture, I see a blurry picture (I assume this is the video).

The video I was linking to is the one on the github project page.  I've put a link in my "...1 min mark here." text.  To me, it appears as a video player box (following that text) ready to click the play button.  "here" might be underlined (a link to the video) in your case.

The picture (not a video) of the green LCD with the blurry right-most digit was my re-creation of your problem.

I apologize, I'm a bit confused over the issue. The data is "hammering" the controller, but that doesn't change the refresh rate the controller is updating the screen, correct?     YES

If this is correct, then why would the ghosting exist if the controller is made the communicate with the display at a rate it can (or should) handle?

I wasn't sure if the high frequency writes (with no data changes) was causing the ghosting.  My HelloWorld test proved that although we can print() to the LCD controller very fast, the unchanging text ("Hello, world") didn't flicker but the changing right-most numeric digit at just 10 times per second made the character unreadable.  That points to the optical response as the culprit.

But I'm at a loss to understand how a fast update is usable even on the main VFD. The value is useless except to tell you the source isn't constant.  The same behaviour is seen in the project video at the 1 min mark here.

I'm uncertain how others use their their counter, but in almost all cases I reference it to a Cesium atomic clock and adjust stuff that requires calibration. A slow moving counter will make tweaking a piece of equipment harder whereas I can see how the frequency is changing instantly.

Maybe I'm use to doing it my way, but it's typically how I utilize my counter.

Actually, after reassembling it, I wanted to adjust the reference on the counter by feeding a 10MHz from the Cesium. I think the spec is 10MHz +/- 5Hz and having a fast moving display allowed me to gt it better than 5Hz; although I know these type circuits will deviate over temp/time.

In your use case, when the counter and the source almost agree then the displayed frequency should be stable; or at most the last digit may change. I thought you found the ghosting distracting and wanted to slow the update rate down. 

With my last code snip you can dial it down to 250ms (4 times per second) so it's still responsive but just above the threshold of blurring.  For example, if the source was jittery then the LSD would blur (be superimposed) between, say "3" and "4". But with my slow-down code, then it would switch between "3" and "4", 4 times per second.  You would see the digit clearly bouncing between "3" and "4".  Or so I believe.

[PCB.Wiz]

Also, I managed to get a picture of the external display in transition (prior to trying the 500ms code) to give an idea of what I'm seeing.

Is the VO pin connected to a correct bias voltage here?
(note the image in #196 has a small trimpot on VO)