Display Support Feature Request

[KC5CQW]

Add LCD and VFD libraries and code for standard 2x16, 4x20 and Noritake-ITRON VFD’s (such as the CU-U LCD replacement line). Unused display modules may be commented out.

[pigrew]

I may be able to work on the 2x16 display, but purchasing a VFD is out of my budget currently.

However, I don't know what to display on the panel. The OLED I have is nice since it has a enough pixels to show everything I want simultaneously. However, a less dense display couldn't show as much simultaneously.

So, what do you propose to show in the two lines? Or do you propose to add a button to scroll through display screens? What do you want to learn from the display?

[KC5CQW]

I like the idea of a button to scroll through the screens with. Several screens each with a dedicated function would be slick. (eg. UTC and local time, number of locked satellites and RSSI, OCXO status and temp, [un]lock state timer etc.)

What about one of those cheap numeric stick-on membrane key pads? (0-9, *, #) Perhaps some form of parameter or settings activation may be possible with one in stand alone mode without having to use a computer. I think the STM should have enough I/O pins left over to support one (7 pins) This would be much more capable than just a single button.

I have a CU-3000 VFD, perhaps I can help test a beta version with the Noritake library compiled in and try out.

[pigrew]

If you want an accurate GPS-based clock, the micro would need a PPS signal input. I've put no effort in trying to make it accurate, I wouldn't be surprised if the display is 1.5 seconds off.

What is the advantage of your VFD display (versus the OLED)? Bigger text? The LCD would have a longer lifetime than both VFD and OLED.

To me, the alphanumeric keypad is too large to be reasonable. I use my computer to configure it when needed.

Would you be able to work on implementing this feature? (I can lend guidance).

EDIT: Also, I'm worried about how to set the layout for various screen sizes. Currently, everything is hard coded for a 128x64 display (very common for the OLED display I selected). But, the Noritake displays you mentioned seem to come in a huge variety of sizes/aspect-ratios. I don't know which one should be selected.

[KC5CQW]

After looking in the oled code, I can see what you mean about hard coding... In this case, I would assume this feature request to take a back seat for now.

Having said that, what I did read covered the white text on black background OLED’s. Would there be an issue if one of the other color hardware options is used (e.g., blue on black or yellow/blue on black)?

For the clock display accuracy, I plan to use a second (outboard) mcu to drive a display and a 32kHz PLL reference (from eBay) into an RTC divided down from a 10MHz output signal. This will be separate from and unassociated with this project except for a common rack enclosure (maybe). I will however use the USB link into a laptop with TAC32 and/or Lady Heather for computer control and monitoring.

[pigrew]

The color doesn't matter. The code is programmed to initialize SSD1306-based OLED displays, and the initialization routine is the same for all of them. The bi-color ones (yellow/blue?) have the top 16 pixels yellow, but I don't think that the line height is correct for a purely yellow line... it'd need a bit of rearrangement.

The I2C OLED has a bit of latency due to the amount of time needed to refresh the display. I2C is a slower protocol with these displays. The SPI panels should be faster (some code changes needed). The STM32 can accurately update the displayed clock... just I've not put enough time into it. 50ms accuracy should be easily doable, unless you need better than that?

I still need to build a case for my GPSDO, and plan to switch to using a larger SPI display when I build the case. I'll keep the code compatible with both interfaces, probably trying I2C first, and if the display doesn't respond, defaulting to SPI (which can't tell if the display is connected or not).

[KC5CQW]

Sounds like a plan for the displays. I was looking at a few on eBay, do they use the same driver chip for I2C and SPI? The one I saw had jumpers for either protocol. I’ll need to find a datasheet and read up on it. I was thinking about installing the GPSDO in an Extron rack mount distribution amplifier (if the power supply isn’t too noisy).

[pigrew]

Yes, they use the same driver IC. Probably SPI4 is the easier interface to implement (though it'll take an extra wire). If I get the chance, I'll work on a small case tomorrow. The display will probably be the only thing on the front (I'll put all of the ports on the back).

[pigrew]

I bought a larger (1.3") SPI display for my unit, and then realized that it uses a different driver IC.

So, now the code should work for SPI for both drivers, though there is a #define that must be changed to switch between SSD1306 and SH1106. I don't really know if I got the initialization correct, but it seems to work. The display refresh is slightly faster, though I'm upset at the STM32F103 for not having a mode where it drops \CS low between every word of data. The \CS has to be handled via software GPIO. Because of that, it's not nearly as fast as it should be, but it is slightly faster (but probably not enough to warrant the use of SPI versus I2C.

I'm not exactly sure when I'll update the documentation for it, but I eventually will. At that time, I'll post a new build.

I'm a little bit worried about display burn-in, so the next substantive thing I'll add is a sleep mode, and a wake-up button.

[KC5CQW]

I would recommend a momentary button for survey “on demand” for portable use or when modifying the setup. This is useful if the coax or antenna are moved or changed. I can’t decide on a box. Metal is best for EMI but plastic is better for thermal stability. I’m using nylon standoff’s for the PCB and the OCXO is covered in self adhesive cork and a layer of kapton tape. Without a schematic, I question if the whole board must be thermally insulated. I have the newer version and it has an IC temp sensor mounted with a thermal moat. Not sure if it measures ambient or if it’s isolated to prevent thermal noise.

[pigrew]

I started to 3D-print a box, but I think that I'll switch to one of the RM2 ABS boxes from Hammond, and 3D-print the front and back. Mine reports a temperature between 45 and 50 C, which I'm assuming is beneath the OCXO (though I've not seen it). I'm sure if it's a good idea to thermally insulate the OCXO any more than it is. Its control loop may require some cooling to be stable? Which OCXO do you have? Which board revision? (I have a description of the SN in GPSDO_commands.h:98) I do see some slight thermal oscillations in the reported value (perhaps of 0.3 C amplitude), and my board seems to go unlocked every eight hours or so. Being able to run the OCXO Training command is also useful. Up to now, I've connected my laptop via USB to send commands if I need to. I guess one button is enough to navigate menus? (short-press vs long press).

[KC5CQW]

I just received a pair of the OLED SPI displays. Now I need to get back to school work! Anyway, not much time to play with them yet but I did notice something... As such small screens, perhaps a wake up button and a 10min (or whatever) timer then power off. Not much chance of being able to read it from across the room anyway... The next chance I get, I’ll look in the code for the pinout locations and driver chip info. If all goes well, I’ll report back. Much more free time after the new year.

73, Damon

On Oct 31, 2017, at 17:02, Nathan Conrad notifications@github.com wrote:

I bought a larger (1.3") SPI display for my unit, and then realized that it uses a different driver IC.

So, now the code should work for SPI for both drivers, though there is a #define that must be changed to switch between SSD1306 and SH1106. I don't really know if I got the initialization correct, but it seems to work. The display refresh is slightly faster, though I'm upset at the STM32F103 for not having a mode where it drops \CS low between every word of data. The \CS has to be handled via software GPIO. Because of that, it's not nearly as fast as it should be, but it is slightly faster (but probably not enough to warrant the use of SPI versus I2C.

I'm not exactly sure when I'll update the documentation for it, but I eventually will. At that time, I'll post a new build.

I'm a little bit worried about display burn-in, so the next substantive thing I'll add is a sleep mode, and a wake-up button.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pigrew]

I did implement a different display driver chip in the latest code. You have to switch the configuration in main.h now. It also should support both I2C and SPI.

Uncomment the driver model you use.

define OLED_SH1106

//#define OLED_SSD1306

[KC5CQW]

I feel this issue is satisfied and can now be closed out. TNX!