Hello.
Arduino IDE, uploading “WiFi Lora 32 V3 Factory Test V1” sketch from Heltec ESP32 Dev Boards library works fine. Display works.
Uploading any other sketch in the dev board examples list, or in the ESP32_LoRa_V3 library does not show anything on the screen.
What is the difference here, and how do I get it to work?
Thanks.
Most of the example sketches don’t use the display… Did you try Examples > HeltecExample > DriverTest > OLED? That’s one example, apart from the Factory Test, that does use the display.
Tons of them do. There’s a whole folder of display demos under the examples category for the device, none of which work. The ‘minimal demo’ sketch display does not work. I can copy the display constructor from the single sketch I have that works, but it sure seems like the sketches that contain display, in the example folder for the specific device I’m using, should work with the display, without me doing debug on how the driver class is screwed up.
I suspect that we are each working with different software revisions somewhere along the line. Can you find the sketch to which I referred above? Either way, the most likely problem, if you’re not familiar with the Heltec boards, is that you will need to be sure that Vext is ON, and exactly how you do this may depend on which revision of the board you have.
Example sketches provided by Heltec will invariably turn Vext ON. Example sketches provided by other vendors most likely will not, and if Vext is not ON, neither will the display be.
These are all examples provided by heltec in the library that installs to Arduino ide.
Perhaps you need to post a simple example of one of the sketches that doesn’t seem to be working. (When you post the code, please select it and click on the “</>” icon in the tool bar to have it presented in a scrollable box.)
If one sketch works, but others don’t, then it’s most likely a software/configuration issue. The most common problems people seem to encounter are not ensuring that Vext is ON and, on some boards, that the I2C bus on which the display is configured has been inadvertently redefined.
Harsh reality check which you can confirm by forum search. Heltec creates great value hardware, but the supporting software suffers from bitrot. It is reasonable, within the limits of applying the right release for the hardware version, to expect examples to just work. But it is a moving target and Heltec generally choses not to chase that.
As @UniquePete says, we can help you so much more if we know what board packages you’ve installed, if you are using Arduino IDE or PlatformIO and which version of the v3 you are using.
That’s fine. I can just take the working Display class from the single sketch that works, and use it where I need display. I’m not going to dig into all of the classes and header files to figure out where they’ve gone wrong. The real answer is the last here, and that’s that the libraries are not properly maintained for hardware/firmware revisions. I can work with that and move forward accordingly. I just wanted to make sure I was not missing something obvious. It’s especially egregious in this case, because the library is specifically named for the hardware revision I’m working with – it’s not a generic driver. My guess is they simply copy pasted the code from the previous rev, renamed it for the new one, and fixed the Factory Acceptance sketch so that it worked and they could load it on the way out the door.
It might help other users who read this thread if you were to post the code segment or definition that you found in error, and what you replaced it with to resolve your problem. If it is an error in a particular version of the relevant library package, it would really help others if they knew what might need updating.
I specifically mentioned the sketch that works, and the ones that don’t, which is every single other one. I also said which platform I was using, and which steps I used to get where I am.
In the file that works, the FactoryTest, in the ESP32 Dev Boards Library, this works:
SSD1306Wire factory_display(0x3c, 500000, SDA_OLED, SCL_OLED, GEOMETRY_128_64, RST_OLED); // addr , freq , i2c group , resolution , rst
This class is from the library HT_SSD1306Wire.h, and a derived class of ScreenDisplay.
In, for example, UIDemo, which is in the ESP32_LoRa_V3 Examples, the following is used:
class OLEDDisplayUi {
private:
OLEDDisplay *display;
This is a subclass of OLEDDisplay, which is found in OLEDDisplay.h. This library is in a general ESP32 ESP8266 driver library.
In minimal_demo, which again is in the same ESP32_LoRa_V3 Examples, we have:
heltec_setup();
which comes from heltec_unofficial.h, which is in the device-specific library. It includes SSD1306Wire.h and OLEDDisplayUi.h. We have there:
SSD1306Wire display(0x3c, SDA_OLED, SCL_OLED, DISPLAY_GEOMETRY);
Note that this is from SSD1306Wire, not HT_SSD1306Wire, and comes from the generic driver library. It also subclasses OLEDDisplay.
Anyway, my point is that I don’t want to chase all of this crap down. It’s obviously not been maintained, and at the end of the day, I just need something that will work. I have the display and hardware up using micropython anyway, so I probably won’t be messing at all with these libraries once I have that running.
Providing power to the display, however, which is generally achieved on the Heltec boards by explicitly turning the ‘external’ power supply, Vext, ON, is entirely independent of the display driver. Unfortunately, the logic required to turn Vext ON is the opposite on the V3.2 board to that on the earlier V3 boards, and, as you might imagine, this can be problematic if one is trying to run a sketch that claims to be intended [simply] for a ‘V3 board’.
Then there should be an appropriate rev note to this effect. The board should have been up-revd and this made clear. Really, they should not have changed the logic at all and simply inverted it on the board. That’s just a silly decision. Or, all of the display programs could use the same driver classes, and then one could see in a single note at the top of the relevant class that revision is important in this context.
I can see in several instances they have made provision for including Vext in the display class itself, as well as reset. It’s worth noting that simply setting Vext to the appropriate state does not fix the problems I encountered, so it’s not that simple. Anyhow, I’m done spending time on this, and this is too much already.
So even with the display piece from the Factory sketch working, during initialization,
Mcu.begin(HELTEC_BOARD,SLOW_CLK_TYPE);
breaks the display. I cannot look up McuClass, because it’s rolled up into a binary that I don’t have access to. So who knows if there’s anything I need in there. This code base is garbage. Spaghetti nonsense. Next.
Correct. So my first piece of advice, if you’d provided a complete sketch for us to work with, would have been to use only generic libraries, none of the ‘packaged’ stuff that Heltec provides. There are some that some boards require for some activities, but the best way to sort out these sorts of problems is to start without any of them.
I use the standard SSD1306Wire library without anything special in the constructor and I manage Vext ‘directly’. As you have noted, several Heltec libraries fiddle with Vext, and it can be more than irritating trying to work out what state it’s in when this happens. Some Heltec libraries also quietly create display constructors ‘internally’ and this too can cause problems.
Things changed a lot with the introduction of the V3 boards, and also between the V3 releases, and as a result software behaviour is very dependent on the versions of the necessary support software that a user has loaded, and this includes the example sketches.
This can all be seriously frustrating for a new user but people on this forum have worked through most of these problems and can help if provided with the necessary information. Yes, Heltec themselves could be doing a lot more in this regard, but it is what it is and we as a user community do what we can with what we have.
That’s all just dumb and irresponsible. Package code that works, labeled for the version of hardware you are selling, with notes to that effect, or just don’t package it at all. It’s a great way to get people to not use your product.
Yeah, we know, we’ve all been frustrated with it at some point. It is unlikely to change any time soon so you may want to focus on making good use of the hardware rather than hope that all the code base will suddenly come right.
The reason we stick with it is because, to quote a wise man, “Heltec creates great value hardware” and we’ve accumulated enough knowledge collectively to work around software issues.
If you tell us what your project is, maybe we can help you kickstart it with a recommended software setup.
Yeah, I’ve moved on from the examples. I’ll just grab what I need and put it together. For the moment, I just want a send and receive pair that I can take to sites and test range and reception between endpoints for future deployments. I’ve got a couple of the LoRa v3 with the little boxes, antennas, and batteries. Looks like I can piece that together from the rx_tx and ping pong sketches. Just want nodes periodically sending and receiving, displaying success/failure rates and RSSI, probably battery status as well.
Ultimately, I will be integrating these as a transmit receive pair between control panel pairs. To that end, I’ll spend time getting micropython up on the radio library, and set each up as a modbus tcp/ip server to mirror data between them. The screen was not difficult to get up using standard micropython libraries.
I ended up getting it working with Micropython and the schematic. One thing I can’t figure out still is how the battery monitor works. It reads the same voltage of about 1V, regardless of whether there is a battery or USB connected, or at least that’s my math on about 1000 counts upon 3.3V with the divider factored in.
So that’s interesting, because from what I can tell, the 3.2 schematic, here, uses a different configuration. Instead of the dual-channel mosfet, it looks like they have used a BJT controlling the gate of a single mosfet. What’s funny is that from their product page, they have a linked a schematic labeled 3.1, with the dual channel mosfet chip, to both the 3.1 and 3.2 links.
Anyway, the fet is a p-channel a03401 with a pull-up, with an NPN S9013 labeled there controlling the gate. So the S09013 pulls the gate down and connects ADC to Vbat. The factor of the divider is the same at about 0.2.
So it looks as though we are to pull GPIO37 low, and read the ADC on GPIO1. This all yields basically zero counts on the ADC, however, when it is read. Figuring the logic was reversed for some reason, I tried reading it after setting GPIO37 high. That is when I get a reading that, while non-zero, does not appear to reflect a real battery voltage, and does not change, as I mentioned when I disconnect either the battery or the cable (independently, obviously).