Heltec Wifi Kit V2 OLED Troubleshooting

[SpeedPermitting]

I'm returning to projects based on NightDriverStrip after some time away, and I'm encountering issues where the OLED screen on the Heltec Wifi Kit V2 doesn't seem to be working with the current version of the code.

Has anybody recently built/uploaded the "heltecv2demo" environment on a Heltec Wifi Kit V2? If so, does the OLED screen work as expected?

I have a few of the Heltec V2 boards, and I had previously flashed them with code based on earlier versions of the NightDriverStrip project (circa 2022), which work fine.

I've validate the OLED pin assignments for the V2 board, which match what is used in versions of the code where the OLED works:

OLED_RST - 16
OLED_SCL - 15
OLED_SDA - 4

These appear consistent with what gets assigned in the current version of "screen.h" under "#if USE_OLED && !USE_SSD1306", based on the "heltecv2demo" environment.

If I clone a fresh copy of NightDriverStrip, create/edit secrets.h, and then build/upload the "heltecv2demo" environment, the screen doesn't work properly. It seems to flicker once right after the device boots or resets, and rarely (and seemingly randomly) it may flicker again while the device remains powered, but nothing remains visible on the screen for any significant period of time. (Just for reference, a connected LED strip will display the rainbow pattern as expected, so overall the code seems to be flashed/running successfully.)

I've reproduced this on a couple different V2 boards, and if I re-flash one of the boards displaying this behavior with older code, the OLED screen works (proving to me the screen itself is not broken).

By chance, has anybody else encountered this same issue, or does anybody have a recommendation on where I should focus my troubleshooting? (e.g., specific code within NightDriverStrip itself or perhaps a dependency such as U8g2?)

I appreciate any recommendations!

[robertlipe]

Welcome or Welcome back...

Has anybody recently built/uploaded the "heltecv2demo" environment on a Heltec Wifi Kit V2? If so, does the OLED screen work as expected?

We had some V3 traffic recently, but I don't remember anyone with V2. As you've seemingly already noticed, chasing the code paths through p*ini, globals.h, screen.*, and into the constructor lf LcdScreen() is not a lot of fun.

I have a few of the Heltec V2 boards, and I had previously flashed them with code based on earlier versions of the NightDriverStrip project (circa 2022), which work

If you want to trade computer time for brain time, you might just try a binary search walking through date-based time travel through the source tree cranking off a build and an upload just to see if you can achieve blinkage. I know git bisect is a thing that's used in this kind of a space, but I'd have to look up the syntax. Honestly, we get so little commit traffic that you can probably dial year and quarter in on a couple of uilds at most. I've validate the OLED pin assignments for the V2 board, which match what is used in versions of the code where the OLED works:

OLED_RST - 16 OLED_SCL - 15 OLED_SDA - 4

I'd still try to catch that in a debugger or preprocessing the source to a file or even just disassemble and look for the constants in the call to oled() to be sure everything gets prprocessed corretly. (That or I'd inttentionally stick a a LOG_I() or even a syntax error in that code to be sure that line 320 (right?) is The Chosen One. I remember that one of our last Heltec users we had a little dust about fixing new boards at the cost of others. We tried to do the right thing, but maybe we missed something in inspection.

If I clone a fresh copy of NightDriverStrip, create/edit secrets.h, and then build/upload the "heltecv2demo" environment, the screen doesn't work properly. It

That's the recipe. If you're building something that doesn't take networking, I think you actualy don't HAVE to edit secrets, but once you've dialed that in, subsequent git checkouts won't clobber that.

reference, a connected LED strip will display the rainbow pattern as expected, so overall the code seems to be flashed/running successfully.)

That's a much less unique/fragile path, so that's comforting. I just don't think we have a lot of uses of the USE_SCREEN hardware, wth the possible exception of the M5's.

I've reproduced this on a couple different V2 boards, and if I re-flash one of the boards displaying this behavior with older code, the OLED screen works (proving to me the screen itself is not broken).

Cool. That answers that obvoius question. a recommendation on where I should focus my troubleshooting? (e.g.,

specific code within NightDriverStrip itself or perhaps a dependency such as U8g2?)

There are libraries I somewhat follow, but https://github.com/olikraus/u8g2/commits/master/ isn't one of them since I have no affected boards. I suppose I have 1306's in stock, so I could MAKE a mesmerizor with a (Ready For The World) Digital Display, but that doesn't expose any real-world coverage. It looks like a library with a lot of traffic, but not one we exactly couple to tightly. You can play with the olikraus/U8g2 @ ^2.28.8 entry in p*ini, followed by a 'pio pkg update' (and I'm pretty sure it'll let you march backward if needed). It looks like we're telling platformio that we're hip with any version newer than their Oct 26, 2020 version (!) I paged all the way back to https://github.com/olikraus/u8g2/commits/master/?after=5f969586c7659fc236fb650c46c8c2f068abe29f+1084 to discover that. So I'd just make my first stop rolling that version all the way back and then treset it and then try the tree-wide binary search. It may not be the hint you wanted, but that's how I'd tackle it. Good luck! R

…

I appreciate any recommendations! — Reply to this email directly, view it on GitHub <#692>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3ZZOSH7NCXINU5U3IT2QVELVAVCNFSM6AAAAABXPXBRZGVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXHE4TEMZYGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rbergen]

Welcome back!

Heads up: some of what I'm going to say will be a repeat of what Robert already mentioned.

Has anybody recently built/uploaded the "heltecv2demo" environment on a Heltec Wifi Kit V2? If so, does the OLED screen work as expected?

Not that I'm aware of. As far as I know, the code to support the Heltec V2 was written by Dave pretty early on in this project's lifetime. I'm not even sure if he even has any devices of that type left.

I have a few of the Heltec V2 boards, and I had previously flashed them with code based on earlier versions of the NightDriverStrip project (circa 2022), which work.
[...]
If I clone a fresh copy of NightDriverStrip, create/edit secrets.h, and then build/upload the "heltecv2demo" environment, the screen doesn't work properly.

So it seems something happened in the past 3 years that broke the screen code for the Heltec V2. As Robert indicated, we don't have a high rate of commits on this project, but going by the commit history of screen.cpp over the past 3 years quite a few changes were still made during that period.

I agree with Robert that the best way to go is probably to apply the binary search approach over the commit timeline, and figure out that way what commit broke things for the Heltec V2. My guess is that it's a change to either screen.h, screen.cpp, or the dependency section of platformio.ini that caused this. At the same time that's just my gut talking, and that's been known to be wrong.

I wish you the best of luck with pin-pointing what the responsible change is. If and when you find it, I'm obviously more than happy to help addressing that, while not breaking the screen functionality for other devices.

Cheers,
Rutger

[SpeedPermitting]

Thank you both for your feedback and suggestions on this! I will try the strategies you've suggested to see if I can pinpoint where the issue is, and I'll share my findings here.

[SpeedPermitting]

Thanks to your recommendations, I eventually figured out what's happening: the monochrome screen on the Heltec Wifi Kit 32 is unable to properly display the "CurrentEffectSummary" screen defined in screen.cpp (although it can display the "BasicInfoSummary" screen just fine).

The issue becomame apparent in commit 775204e due to a change in globals.h, where the "default" for NUM_INFO_PAGES was changed from 1 to 2:

Old:

#ifndef NUM_INFO_PAGES
#define NUM_INFO_PAGES 1
#endif

New:

#ifndef NUM_INFO_PAGES
#define NUM_INFO_PAGES 2
#endif

When NUM_INFO_PAGES is set to 1, the "BasicInfoSummary" screen is the first and only screen displayed.

When NUM_INFO_PAGES is set to 2, the "CurrentEffectSummary" screen loads first, and if the toggle buttons have been defined/enabled, TOGGLE_BUTTON_1 will swap between the two screens.

On the Heltec Wifi Kit 32, with NUM_INFO_PAGES set to 2, TOGGLE_BUTTON_1 essentially toggles between a blank screen ("CurrentEffectSummary" failing to display correctly) and "BasicInfoSummary." Of course, if no toggle buttons have been defined/connected to the board, the screen just non-functional, since it's "stuck" on "CurrentEffectSummary," which won't display.

I can certainly work around this issue by customizing my own local copy of the code. I'm not sure it's worth the effort/impact to try to "fix" this in the project, but there are two approaches I could see:

OPTION 1: Disable the "CurrentEffectSummary" screen for devices with monochrome OLED displays.

For example, this could be added to globals.h after the "#if USE_SCREEN" section:

#if USE_OLED
    #define NUM_INFO_PAGES 1
#endif

To avoid compiler warnings, this would ideally be moved somewhere below the new section:

#ifndef NUM_INFO_PAGES
#define NUM_INFO_PAGES 2
#endif

If somebody enabled USE_OLED and also tried to enable the toggle buttons without modifying their default behavior, the results would be:

• Toggle Button 1: Does Nothing.
• Toggle Button 2: Reduces Brightness. (Since the displayed screen cannot be changed, the behavior of this button would never change to "go to next effect".)

For fairly minimal effort, this essentially "fixes" the issue for users of older Heltec boards with the OLED, assuming they don't use toggle buttons. It just limits the device to the original "BasicInfoSummary" screen only.

OPTION 2: Update the "CurrentEffectSummary" function to support monochrome OLED displays, i.e., if USE_OLED is enabled in globals.h.

This would be more complicated, and probably not worth it. I suspect most people who are taking advantage of onboard screens and toggle buttons are probably using something newer with a more capable screen like the M5 Stick.

I was able to get a partial fix by replacing any references to colors in "CurrentEffectSummary" with "BLACK16" for the background and "WHITE16" for everything else. After making that change, switching screens or pressing TOGGLE_BUTTON_2 while the "CurrentEffectSummary" screen should be displayed now results in a brief flash of readable text instead of a brief flash of solid pixels on roughly half the screen, but the display still goes dark less than a second after pressing the toggle button.

My best guess is that the function is trying to draw something too large to fit on the screen, but I haven't yet worked out if that's the case (or if the screen going black is the expected behavior in that case).

I may continue prodding at this, just to see if I can get it to work... if I do learn anything new, I'll be happy to share!

[SpeedPermitting]

I think I figured out the original issue, at least in part.

The "CurrentEffectSummary" function in screen.cpp seems to be designed deliberately so the majority of content is only redrawn to the screen if the displayed data would have changed. There's even a comment mentioning that.

I don't know this for sure, but I suspect the displays packaged with some ESP32 kits may have some type of "pixel persistence," in other words, pixels might remain lit until they're drawn over without having to constantly refresh the screen.

For the Heltec Wifi Kit 32 V2, I can get the "CurrentEffectSummary" screen to appear correctly if I force "bRedraw = true;" every time the function is called. Interestingly (and expected, now that I have a better idea what's going on), if I place the "bRedraw = true;" here, the screen will "blip" on once per second:

    if (bRedraw || lastFullDraw == 0 || millis() - lastFullDraw > 1000)
    {
        lastFullDraw = millis();

        bRedraw = true;  // Placing this here makes the screen "blip" on every second.

        lastFullDraw = millis();
        if (bRedraw != false ||
            lasteffect != g_ptrSystem->EffectManager().GetCurrentEffectIndex() ||
            sip != WiFi.localIP().toString())
        {

So, to get the "CurrentEffectSummary" working correctly on an older Heltec OLED requires two things:

• Adjust the colors so everything is either "BLACK16" or "WHITE16".
• Force a redraw every time "CurrentEffectSummary" is called.

I happen to have an M5StickC Plus, and I found that both the "BasicInfoSummary" and "CurrentEffectSummary" work correctly without having to modify the code, so I suspect the M5StickC Plus has a screen that doesn't require static content to be constantly re-drawn.

Based on all that, I don't think it's worth trying to get a partially functional "CurrentEffectSummary" working on an older Heltec OLED. What I plan to do locally is essentially what I described as "OPTION 1" in my last update: when targeting this type of board, I'll ensure NUM_INFO_PAGES is defined as '1', essentially disabling the "CurrentEffectSummary" screen altogether.

[robertlipe]

The issue becomame apparent in commit 775204e <775204e> due to a change in globals.h, where the "default" for NUM_INFO_PAGES was

Wow. Good find. I remember reviewing that patch and didn't see that coming. (It's safe to say that none of us did, clearly.) I don't have the board, but from skimming https://heltec.org/project/wifi-lora-32v2/ and https://heltec.org/project/wifi-lora-32-v3/ it looks like they have the same number of buttons, (one - you can reuse the BOOT button, but not reset) and the same 0.96 128x64 mono OLED, though there's a hint that the OLED is actually optional, but defaults to being present. The key difference is that the V3 board uses the ESP32-S3 SoC and USB-C while V2 uses the ESP32-Nothing and USB-Micro B. (This means that the former board is paying for a CP2102 and associated passives Do those pages match reality (and my understanding? On the Heltec Wifi Kit 32, with NUM_INFO_PAGES set to 2, TOGGLE_BUTTON_1

essentially toggles between a blank screen ("CurrentEffectSummary" failing to display correctly) and "BasicInfoSummary." Of course, if no toggle buttons have been defined/connected to the board, the screen just non-functional, since it's "stuck" on "CurrentEffectSummary," which won't display.

Both boards have exactly one (available) button, right?

I can certainly work around this issue by customizing my own local copy of the code. I'm not sure it's worth the effort/impact to try to "fix" this in the project, but there are two approaches I could see:

I think most of us are willing to put in some effort to ensures this Just Works for the next person...and for you.

OPTION 1: Disable the "CurrentEffectSummary" screen for devices with monochrome OLED displays.

Both boards feature a monochrome OLED display, right?

#if USE_OLED #define NUM_INFO_PAGES 1 #endif In globals.h, it appears the intention was to define USE_OLED in both

cases. The SSD1306 is so universal in this application that it's tough to believe that they don't both feature the SAME OLED. luc-github/ESP3D#897 says that's what used on v2. https://esp32.com/viewtopic.php?t=32710 says that's what used on v3 Oh, wait. All their code looks like only the SSD_1306 is mentioned. e.g. https://github.com/HelTecAutomation/Heltec_ESP32/blob/adea0f5622413d4a403c3270eb01a513d18f02c7/examples/OLED/SimpleDemo/SimpleDemo.ino and https://resource.heltec.cn/download/WiFi_LoRa_32_V3/HTIT-WB32LA(F)_V3.1_Schematic_Diagram.pdf S2 is the only available button. Does V3 have another (non-resest) GPIO somewhere?

To avoid compiler warnings, this would ideally be moved somewhere below the new section: #ifndef NUM_INFO_PAGES #define NUM_INFO_PAGES 2 #endif I'd actually rather NOT define that for everything else, actually, Our

namespace issues are already pretty dirty. Let's find another way to get there from here. If somebody enabled USE_OLED and also tried to enable the toggle buttons without modifying their default behavior, the results would be:

- Toggle Button 1: Does Nothing. - Toggle Button 2: Reduces Brightness. (Since the displayed screen cannot be changed, the behavior of this button would never change to "go to next effect".) For fairly minimal effort, this essentially "fixes" the issue for users of older Heltec boards with the OLED, assuming they don't use toggle buttons. It just limits the device to the original "BasicInfoSummary" screen only.

(come back to this)

OPTION 2: Update the "CurrentEffectSummary" function to support monochrome OLED displays, i.e., if USE_OLED is enabled in globals.h. This would be more complicated, and *probably* not worth it. I suspect most people who are taking advantage of onboard screens and toggle buttons are probably using something newer with a more capable screen like the M5 Stick.

We probably agree that "page switch" is the function you need if you have only one button. Maybe you overload long press to cycle through brightness if you don't have a second button. Maybe you change brightness via the web interface or something. But especially if we have zero buttons, our most important page should be the default one. Until the next section, I was understanding the problem is that you think there's a difference in screens on these two models AND that you think the button choice is unfortunate because you have only one button and are therefore stuck on the wrong page. Is that not the case? I was able to get a partial fix by replacing any references to colors in

"CurrentEffectSummary" with "BLACK16" for the background and "WHITE16" for everything else. After making that change, switching screens or pressing TOGGLE_BUTTON_2 while the "CurrentEffectSummary" screen should be displayed now results in a brief flash of readable text instead of a brief flash of solid pixels on roughly half the screen, but the display still goes dark less than a second after pressing the toggle button.

So it's only after you reduce the button count so you can select pages you're getting to this point, right? My best guess is that the function is trying to draw something too large to

fit on the screen, but I haven't yet worked out if that's the case (or if the screen going black is the expected behavior in that case).

CurrentEffectSummary looks more like it's expecting to draw on a TFT/LCD ("Color") screen. Does that screen make sense on an OLED at all? Maybe it was just second and the creator was bravened bith mili BasicInfoSummary() looks like, well, basic info that's text that would make sense on a small mono screen like the 1306's. That screen is also where the #if HELTEC decorations are, making me think that at least one person has actually tried. this. OK, it's using red, orange, green, and blue, but that looks like it may just be relief shading and not a reflection of any pixels we're actually displaying anywhere. Is it possible that a second screen was added, made the default, and is styled in color and just plain renders badly on mono screens? I definitely have SSD_1306 displays, S3 boards, and buttons. If you can confirm pinouts for that device and the GPIO pin for the button (and maybe a link to some other project to verify that my counterfit V2 board matches in the important regard), I'll try to build one next week and join you in solidarity to find what's going on. I've kind of wanted to see this code in practice anyway. Looking at the pictures, I might have a Meshtastic board. Maybe. Is that similar enough?

I may continue prodding at this, just to see if I can get it to work... if I do learn anything new, I'll be happy to share!

Please do. I'm intrigued.

[SpeedPermitting]

Thanks for the reply, Robert! I had just been getting ready to add some more information before you posted, but I wanted to directly address a couple of your questions below. Let me know if there's anything I didn't answer fully between the two posts.

Do those pages match reality (and my understanding?

This is the pinout for the board I have:
https://resource.heltec.cn/download/WiFi_Kit_32/WIFI_Kit_32_pinoutDiagram_V2.1.pdf

While the layout of pins on the board appears different for the Wifi Kit 32 vs. the LoRa, it appears to me that you're correct about them both only having one programmable button, both on pin 0 / GPIO 0, and I can confirm that at least the WifiKit 32 V2 and V3 both have a monochrome OLED display.

However, and perhaps I should have mentioned this before, I was using "TOGGLE_BUTTON_1" and "TOGGLE_BUTTON_2" in a sort of generic sense. For my testing, I actually connected two external momentary switches to pins 37 and 33 and then added in globals.h under "#elif DEMO":

    #define TOGGLE_BUTTON_1 37
    #define TOGGLE_BUTTON_2 33

So for my purposes, I wasn't using the button built into the board.

CurrentEffectSummary looks more like it's expecting to draw on a TFT/LCD
("Color") screen. Does that screen make sense on an OLED at all? Maybe it
was just second and the creator was bravened bith mili

That screen probably doesn't make sense on an OLED. I this it's probably best to just disable it and revert to "BasicInfoSummary" as the only screen shown on OLED devices.

For my own purposes, I intended to deliberately modify the behavior of the buttons compared to what's in screen.cpp in the project. For the Heltec Wifi Kit 32 V2, I'm actually fine with just the "BasicInfoSummary" screen, so rather than dedicating one button to changing screens, I prefer to have one button to change brightness and the other to cycle effects.

[robertlipe]

More later, which probably means late this weekend or early next, but I think we were narrowing down to similar thinking about CurrentEffectSummary just not making sense, but I couldn't "see" it to make a call.. Consider // How many screen pages do we have? #if USE_OLED constexpr uint8_t g_InfoPageCount = 1; // and disable the button or use it as a long press to cycle brightness (prob. not worth it) #else constexpr uint8_t g_InfoPageCount = std::clamp(NUM_INFO_PAGES, 1, 2); // Or maybe just completely disable the listener on Button1.update #endif The one GPIO on 0 thing is common on ESP32. The boot BIOS polls that pin on the way booting up (Harrie is now the group's expert on this and he can explain it more) to force it into the boot monitor instead of letting it try to pick an active partition from the flash and jump to it. On ESP32-C3, this is pin 9. So lots of ESPs have a button here as it's needed for recovery of flash contents hosed. As for constant refresh, I know there's SOMETHING that makes OLEDs self-destruct. I can't remember if refresh is what kills them or if it's needed. Unfortunate, I know. :-) But i have to run for a while. G ood luck!

…

On Fri, Feb 21, 2025 at 12:10 AM SpeedPermitting ***@***.***> wrote: Thanks for the reply, Robert! I had just been getting ready to add some more information before you posted, but I wanted to directly address a couple of your questions below. Let me know if there's anything I didn't answer fully between the two posts. Do those pages match reality (and my understanding? This is the pinout for the board I have: https://resource.heltec.cn/download/WiFi_Kit_32/WIFI_Kit_32_pinoutDiagram_V2.1.pdf While the layout of pins on the board appears different for the Wifi Kit 32 vs. the LoRa, it appears to me that you're correct about them both only having one programmable button, both on pin 0 / GPIO 0, and I can confirm that at least the WifiKit 32 V2 and V3 both have a monochrome OLED display. However, and perhaps I should have mentioned this before, I was using "TOGGLE_BUTTON_1" and "TOGGLE_BUTTON_2" in a sort of generic sense. For my testing, I actually connected two external momentary switches to pins 37 and 33 and then added in globals.h under "#elif DEMO": #define TOGGLE_BUTTON_1 37 #define TOGGLE_BUTTON_2 33 So for my purposes, I wasn't using the button built into the board. CurrentEffectSummary looks more like it's expecting to draw on a TFT/LCD ("Color") screen. Does that screen make sense on an OLED at all? Maybe it was just second and the creator was bravened bith mili That screen probably doesn't make sense on an OLED. I this it's probably best to just disable it and revert to "BasicInfoSummary" as the only screen shown on OLED devices. For my own purposes, I intended to deliberately modify the behavior of the buttons compared to what's in screen.cpp in the project. For the Heltec Wifi Kit 32 V2, I'm actually fine with just the "BasicInfoSummary" screen, so rather than dedicating one button to changing screens, I prefer to have one button to change brightness and the other to cycle effects. — Reply to this email directly, view it on GitHub <#692 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34GE7OMBISXT3H7R732Q27MRAVCNFSM6AAAAABXPXBRZGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRXGE4TQNI> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/692/comments/12271985 @github.com>

[rbergen]

This will be a bit of an aggregate response to a number of previous messages, but bear with me.

The issue becomame apparent in commit 775204e due to a change in globals.h, where the "default" for NUM_INFO_PAGES was changed from 1 to 2

That is a really good find, kudos for it!

OPTION 1: Disable the "CurrentEffectSummary" screen for devices with monochrome OLED displays.

Sold. This is basically how the situation was for these devices anyway. I would like to know if the Heltec V3 suffers from the same problem, because we're discussing disabling the second screen for both devices. Going by discussion #667, it seems to me that things do work for the V3 (now that the fix for that issue has been implemented in #668), and I wouldn't want to deprive V3 owners of their second screen if it does indeed work for them. Here's the snag: I don't own any V3 devices myself.

To avoid compiler warnings, this would ideally be moved somewhere below the new section:

#ifndef NUM_INFO_PAGES
#define NUM_INFO_PAGES 2
#endif

I'm far less against this than @robertlipe is. In terms of earlier exchanges him and I have had about it: at least it's an evil we know, as we use for a lot of things already (see...

NightDriverStrip/include/globals.h

Line 1255 in 339219a

// Default Settings

...and below). And I do genuinely think there is merit to seeking consistency in an otherwise complicated context.

I can certainly work around this issue by customizing my own local copy of the code. I'm not sure it's worth the effort/impact to try to "fix" this in the project, but there are two approaches I could see:

I think most of us are willing to put in some effort to ensures this Just Works for the next person...and for you.

Agreed. It's quite likely others have run into this or will, but then shrug and move on instead of reporting it. I'm a strong proponent of "it it ain't broken, don't try to fix it", but that also works the other way around: if it is broken, then let's.

Concerning the buttons discussion, I'm inclined to lean to the preference of someone actually owning the device, which means I don't really have an opinion myself.

If anyone is willing to put a PR together to fix this in a way that's consistent with how we currently do things, for those devices on which the problem is confirmed to exist then I'm happy to work towards merging it.

[SpeedPermitting]

Thanks for the feedback!

I've ordered some Heltec Wifi Kit 32 (V3) boards and a Heltec Wifi LoRa 32 (V3) to test with (the former I wanted to get anyway; the latter, well, now I'm curious...). So, I should be able to do some testing relatively soon to see whether the behavior of the "CurrentEffectSummary" screen is consistent on either of them compared to the Heltec Wifi Kit 32 (V2).

I would be willing to try to put a PR together with a fix later (although admittedly, it would be my first time doing so!), but I think my first step will be getting more test data to help understand how the fix should be scoped, e.g., to all devices that ultimately trigger "#define USE_OLED = 1" vs. only specific boards, such as the Heltec Wifi Kit 32 (V2) (and maybe the original/"V1").

It may be a couple days, but I'll follow up again once I've tested the V3 Heltec boards.

[rbergen]

While reading the exchange between Robert and yourself I did have a look at the code, and my conclusion is that the USE_OLED define is only set for the Heltec V2 and V3 boards. So I think we're good with focusing on those.

When it comes to this being your first potential PR: duly noted, it won't decrease the appreciation for the effort you make to put it together if and when you do.

Nor is the appreciation for your commitment to getting to the bottom of this in the Heltec board range, the fact you're actively pursuing clarity on the V3 front is very cool. I'm convinced that once we're at the end of this, the NightDriverStrip project will be in a better place than before you started this discussion. :)

Cheers,
Rutger

[SpeedPermitting]

I got my hands on the Wifi Kit 32 (V3) and Wifi LoRa 32 (V3), and I eventually discovered that both those devices and the V2 board I originally started with can be made to work consistently. So, I've submitted a draft PR #693 that basically does three things:

1. Initializes the OLED screen for all tested device types as "SSD1306".
2. Sets the background of the "CurrentEffectSummary" screen to black for all devices using an "SSD1306" (instead of only the LoRa 32 (V3) specifically).
3. Adds my original suggested fix of disabling the "CurrentEffectSummary" screen for devices that set "USE_OLED" but not "USE_SSD1306" (i.e., for the original Heltec Wifi Kit 32; since I don't have one to test with, I don't want to assume it can leverage the "USE_SSD1306" flag properly).

Feel free to send me any further questions or suggestions here or via the PR. I'm open to discussion if there are stylistic issues or potential side effects I haven't considered.

Thanks again for all the support and help!

Greg

[SpeedPermitting]

Awesome, thank you for your help! Once again, I appreciate all the support.

One last question for now: what's the best way to close out this discussion? I was thinking of posting a new answer with just a brief, one-sentence summary and a link to the PR. Hopefully, that won't preclude anybody from adding any additional comments post-facto, if they wish.

[rbergen]

I think that's a very good and helpful proposal. Even without that, everything one needs to track findings and resolution is already here. And of course, anyone who pulls and builds the new code won't experience the problem anyway.

I'm waiting for a tiny PR I opened myself today to get merged, and then I'll also release a new "official" version, which will also trigger the build of an updated web installer.

[SpeedPermitting]

@rbergen can I delete the forked repository I created to submit the PR? Is that something you'd generally recommend? (I figure I would create a separate fork later if I wanted to work on another PR.)

My understanding from Github's documentation is that deleting the fork should have no negative impact on the upstream repository, but since I'm still new to this process, I wanted to ask for advice first.

[rbergen]

@SpeedPermitting The literal answer to your first question is "yes, you can". The code change you've made the fork for is now merged into the main tree, and in that sense "secure".

The answer to your second question is less straightforward: it's up to you, or really your preferred workflow. Personally, once I've made a fork and contributed to the forked project, I keep it. This is just because I've learned that once I've contributed to a project once, there's a reasonable chance I'll do it again.
There is a workflow difference between you and me that may also contribute to my approach, which is that I tend to work with feature branches (GitHub has some documentation about them, your resident AI assistant will also be able to explain).
I create those straight off the main branch of the upstream repo just before I start working on a change. As I tend to sometimes have a tendency to rethink my changes after making then (and having them merged), or come up with ideas for other ones, it's handy that the changes I made for a particular feature or fix are and remain isolated until I delete the feature branch in question. I occasionally perform a "spring clean-up" in my branches, usually when the number of branches VSCode shows me starts to bug me.

To be fair, with me being the "source code manager" for (almost) all of the repos of the PlummersSoftwareLLC/Dave's Garage GitHub organization it makes sense that I interact more commonly with many of my forks. And in that context, creating and deleting forks becomes a hassle - particularly when there is a "lighter" version of the create and clean-up approach (using feature branches) available.

Another factor for me is that there have also been cases I made changes that I then proposed to upstream, which were either rejected or took a longer time to get merged. As I propose most contributions to other (non-PSL) projects because I personally think they are improvements, I then often leave the fork with my changes in it - thereby basically making a "real fork" in the project sense. That is obviously not the case here.

So, like I said, it's up to you. It doesn't hurt anybody or anything if you delete it, it also doesn't if you don't.

[SpeedPermitting]

Understood--thank you for sharing your thoughts and your approach!

• Greg

[SpeedPermitting]

Updated code in PR #693 to resolve this issue and initialize the SSD1306 OLED display in a consistent way on Heltec Wifi Kit 32 (V2) and Heltec Wifi Kit 32 (V3), matching the configuration already used by the Heltec Wifi LoRa 32 (V3).