why would lora try to start on heltec wifi lora v3

[BigDurl]

I have a heltec wifi lora v3 board. I first tried the normal heltecv3demo because I know the boards are very similar. The led strip did the rainbow effect just fine and the board connected to my wifi but the oled screen was mostly "white" except for a large black bar thru the middle. so I copy pasted some things in an effort to make helteclorav3demo but now the led strip is just frozen and the oled screen just says "Starting LoRa failed!".

[rbergen]

[EDIT: What I said about USE_SCREEN not being defined was wrong, it does get set through configuration inheritance, so I changed that. The rest stands.]

Chances are pretty good that you're seeing the white screen with the black bar because screen.cpp and/or screen.h don't contain the right logic to drive the specific screen on the Heltec WiFi Lora v3.

I obviously don't have a clue what things you copy pasted in an attempt to put your helteclorav3demo configuration together, but it sure sounds to me like you broke something in the process.

I think your safest bet at the moment is to stick with the non-Lora Heltec WiFi v3 project, and live with the fact that the OLED display doesn't work. At least until someone with the Lora variant figures out how to drive the OLED display on that board, and takes the trouble to add that capability to NightDriverStrip.

[rbergen]

Updated my own comment because it contained a factual error at first. Never comment before your first coffee of the day...

[robertlipe]

What he said... Of course.

It should "just" be a matter of adding screen support if you want that. I'd expect it to be not terribly difficult as LVGL and tftspi are both supported, IIRC, and between them, they support about every LCD/OLED out there. (I've only briefly looked at our LCD support because most of my controllers are out of sight and an LCD isn't needed.)

I'd have low expectations for actually mixing lora comms and a billion pixels. Both are rather timing sensitive and it's not difficult to imagine either disturbing the other... Never mind the actual work required to stitch the lora stack into ND. That's far more than a copy paste exercise. It's easy to imagine glitches in the display under heavy sx1262(?) traffic or lora rx traffic being lost if a large dma to the strip is in progress. Maybe it works well enough with only a few bulbs, tolerance for glitches, and a robust retransmission protocol.

I'm rusty on the naming conventions, but there are two mutants of the Heltec Lora boards. One has the legacy esp32 and the other has the esp32-s3 with copious PSRAM. I personally wouldn't even try mixing both on the legacy boards for their weaker DMA.

If your goal is to just use this board because you have it and not try to do lora AND blinkies, that's more realistic. If you REALLY need both functions in one box, consider just using two controllers, communicating with each other ofer SPI, i2c, or even serial. (Serial over one inch of copper trace can run quickly and quite error-free, but I think the dma support for i2c is stronger and has conveniences like error detection.) WiFi in such an environment would be a poor choice as the radios would interfere with each other and overdrive the other.

Getting the LCD working should be an afternoon task for someone with access to the hardware and an interest in making it happen.

Choose your own adventure...

[BigDurl]

After messing around in the code for awhile I found that in include/screen.h on line 363 its:
Heltec.begin(true /*DisplayEnable Enable*/, true /*LoRa Disable*/, false /*Serial Enable*/);
when it's supposed to be:
Heltec.begin(true /*DisplayEnable Enable*/, false /*LoRa Enable*/, false /*Serial Enable*/);

[rbergen]

"[When it's supposed to be] for the Lora model", I think. As in, for the non-Lora boards, the current code is correct.

But there you go, sometimes it can be that simple.

[BigDurl]

I checked and the current code is incorrect for non-LoRa boards. With boards that don't have LoRa. The code is smart enough to just pass on by and print to serial that the board does not have LoRa function. The only reason it ever caused a problem for me is. With the current code. we enable LoRa but then we never tell it what band to use.

[robertlipe]

This is a(nother) case where I have strong opinions but not actual qualifications, as I don't think I've ever seen a Heltec board that wasn't in retail packaging on a shelf. If that's all the case and we take things quite literally, then I think the prescription for this would be to clone env:heltecv3demo and make ; Heltec V3 board, which is an S3 with USB-C [env:heltecv3lora*demo*] extends = dev_heltec_wifi_v3 build_flags = -DDEMO=1 -DENABLE_WIFI=1 -DUSE_SSD1306=1 -*DFIX_LORA=1* ${dev_heltec_wifi_v3.build_flags} and change that block to be something like #if FIX_LORA Heltec.begin(true /*DisplayEnable Enable*/, false /*LoRa Enable*/, false /*Serial Enable*/); #else Heltec.begin(true /*DisplayEnable Enable*/, true /*LoRa Disable*/, false /*Serial Enable*/); #endif I wish we could extend the env, but I don't think that works. I'm not totally thrilled with this from a duplication standpoint, but it's in line with other targets. The layman's version of the above in something like a GNU ChangeLog format is platformio.ini "env:heltecv3lorademo: add new target environment build_flags: add FIX_LORA flag include/screen.hSSD1306() Use LORA_FLAG. I'll let you work out if this is desired/wise, who tests it, the spelling of the environment name, the name of FIX_LORA (which I dislike) and so on. But I think that's the approximate way to convert this into code that's useful for anyone else stumbling upon this. It would result in an avalanche of env:heltecv3heltec-EVERYTHING targets, but at some point, we just punt things off to the DIY builders after showing that DEMO works. {shrug} Otherwise, our build matrix would be even more torturous <https://community.platformio.org/t/distributed-build-with-distcc/11518/2> than it now is. HOWEVER, if https://github.com/HelTecAutomation/Heltec_ESP32/blob/adea0f5622413d4a403c3270eb01a513d18f02c7/src/heltec.cpp#L22 really is the Heltec.begin() in question, then we have at least a highly misleading comment in the original SSD1306 ctor and very possibly a plain wrong option passed on the OTHER Heltec boards. This is also why a list of untyped arguments in a function signature is a terrible idea. If LoraEnable was of type LoraEnableFlag which was an enum of {Lora_Enable, Lora_Disable} or a hash map of options or functions of well named setters or literally any other API designed by grown-ups, this would be much easier to pencil whip. On the third hand (gotta play all the bases...) the Heltec issue <https://github.com/HelTecAutomation/Heltec_ESP32/issues> tracker lists at least four different issues with the OLED displays not working at all, so I'm not sure if that Library is what's actually being used on your board, it's not clear if there's some key difference, a different library is actually used under the covers somehow (maybe they provide a binary from different code?), or if they just ignore their tracker. If this isn't actually th code in question, then the first option is probably the one to pursue and just do whatever works instead of whatever hte code says. As a maintainer, I'd be reluctant to do anything without someone authoritative on the science of Heltech to break some ties. As a final(?) footnote, if you intend to drive more than one strand, I'd expect conflicts if you try to use whatever pins are associated with the arguments in: SPI.begin(SCK,MISO,MOSI,SS); LoRa.setPins(SS,RST_LoRa,DIO0 ...as well as RST_OLED and possibly others. All that extra hardware is connected to the ESP32 somewhere. But I can't find definitions for SCK, MISO, MOSI, SS, RST_LoRa, or Dio0 in this code, so I can't recommend how to dodge them. They're probably in the schematic, but I can't find the code definitions for these. Good luck!

[rbergen]

I'd actually argue for creating a new dev_heltec_wifi_lora_v3 device section in platformio.ini, that inherits from dev_heltec_wifi_v3 and defines HELTEC_LORA=1 on top of what's already in dev_heltec_wifi_v3. The to be created helteclorav3demo environment in platformio.ini would then be based on dev_heltec_wifi_lora_v3 and the #if #else construct around the Heltec.begin() call in screen.h @robertlipe shows would then be based on the new HELTEC_LORA define.

Motivation: I think this is more in line with how additive defines are set and used in the code we already have. One might be of the opinion that that's expanding "the evil we know", but it is what we know.

BUT, that is also just an opinion. 🙂

[robertlipe]

HELTEC_LORA is unquestionably a better name. Sold! I'd earlier advocated for a scheme of building up chips, boards, effects and it didn't go over well. The existing entanglement around the heltec configurations is a good argument for moving more toward that, like you're proposing; I'd like that, but it highlights the surrounding messy items that I chose to flee instead of engage. I picked a (lazy) path more in line with existing code, but I like this approach better, so if you're down, I'm OK with that. - M5DEMO is both an effect (effects.cc) and a board (in config.h) - TMK, the only ESP32 that doesn't have WiFi is one we don't support - and can't support without major changes. So is there a relevant heltec-wifi-not? Why do we keep calling them WiFi? - env:heltecv3demo does a -DUSE_SSD1306. Shouldn't that also more belong at the board layer than at the effect layer? It's super-weird to have it in what we'd normally treat as an an effect definition sitting atop a board. - The heltec targets are the only ones that set ENABLE_WIFI in platformio instead of in config.h. Is there a (good) reason for that? - Our M.O. is usually to turn features ON in platformio.ini. Why do we have two that turn USE_SCREEN off? Why does Atomlight uniquely -U USE_SCREEN? It's really unfortunate that inheritance just doesn't work sensibly in platformio, only taking the last configuration and not merging them. Having wrestled with platformio.env and friends, I've seriously wondered if we could make a target maker that could generate more concise and accurate target definitions than we'd ever. We currently have over 760 configurations "just" of boards and targets alone without getting into options of which pin the remote is on, if it's present at all or what audio subsystem is in use. I have a mixed reaction of both fear and loathing of our build system... That said, I could probably take our combined opinions and convert them to something resembling code if it's deemed worthy of your review and of BigDurl's testing/review. It just feels kind of dirty not REALLY understanding how the defaults became exactly backward, how we'll impact the Lora-not, models, etc. LMK if you want me to pursue with with the above approach of our shared implementation ideas. RJL

…

On Wed, Nov 20, 2024 at 3:54 AM Rutger van Bergen ***@***.***> wrote: I'd actually argue for creating a new dev_heltec_wifi_lora_v3 device section in platformio.ini, that inherits from dev_heltec_wifi_v3 and defines HELTEC_LORA=1 on top of what's already in dev_heltec_wifi_v3. The to be created helteclorav3demo environment in platformio.ini would then be based on dev_heltec_wifi_lora_v3 and the #if #else construct around the Heltec.begin() call in screen.h @robertlipe <https://github.com/robertlipe> shows would then be based on the new HELTEC_LORA define. Motivation: I think this is more in line with how additive defines are set and used in the code we already have. One might be of the opinion that that's expanding "the evil we know", but it is what we know. BUT, that is also just an opinion. 🙂 — Reply to this email directly, view it on GitHub <#667 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD322I7MZWD2GQJZEYR32BRL3RAVCNFSM6AAAAABSBI4OBSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZSGAZDOMQ> . You are receiving this because you were mentioned.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/667/comments/11320272 @github.com>

[rbergen]

First off, you know I value your opinion even if I disagree, so you "adopting" my proposal for the define name is a clear win for me. :)

Within the range of disagreements we have about our build (configuration) setup, I believe there are some important things we do agree on. A probably non-exhaustive list:

• Across platformio.ini, globals.h, and other (header) files that secretly also include build configuration, we're combining completely different approaches (philosophies?) about defining and interpreting that configuration.
• The approaches have completely isolated namespaces that are very loosely coupled in a way that does not effectively implement any (cross-approach) integrity checking.
• Within each approach, there are certain inconsistencies that are rooted in different things (but one of them being the codebase having existed for more than 6 years by now).
• All of this is suboptimal, to put it euphemistically.

(Some things we disagree on is how annoying these aspects are on their own and in unison, and how expected but as of yet unproven benefits of bold changes weigh against the risks of making them - and that's definitely a non-exhaustive list.)

All that said, if you are willing to take the time to come up with a production-ready implementation of support for the Lora Heltec boards and @BigDurl is willing to test it, then I am more than willing to review it!

Thanks, Rutger

[BigDurl]

In case I wasn't clear. I figured out the screen does seem to get initialized correctly on startup but then gets some garbage black and white bars draw to it. I have yet to figure out where that comes from.

[BigDurl]

So I figure out that in screen.cpp on line 254 there is this:
uint16_t backColor = Screen::to16bit(CRGB(0, 0, 64));
so this gets read and drawn as white on my screen when line 285 does it's thing and obscures the text.
can someone explain why this is set to this odd value.

[rbergen]

@BigDurl Without wanting to point fingers to the cause (the problem may be in the sending or the receiving of information), but I am confused now.

Based on what you now say, I understand that:

1. You concluded the line in screen.h is incorrect, but for a different reason than the screen on the Lora board not working.
2. You also claim that line is incorrect for non-Lora boards, even though those boards obviously don't have a Lora module, which makes it seem sensible to me to not try and enable it. Also, the current non-Lora-oriented code has been confirmed working by Dave on his non-Lora Heltec Wifi V3 board(s), screen included.
3. The screen problem on your Lora board is actually not solved yet, at all.

Is this correct?

If so, can you please indicate what I'm missing with point 2, and if you have indeed confirmed on a non-Lora Heltec Wifi V3 board that everything (including screen) works with the second parameter set to false?

[BigDurl]

1. I hate the way this code is written.
   I have to attach a button and press it to see a info screen.
   I'm still confuse where the black and white bars come from when it starts up.

2. I'm very much a beginner but if I look at this:
   Heltec.begin(true /*DisplayEnable Enable*/, true /*LoRa Disable*/, false /*Serial Enable*/);
   screen.h line 363
   and then I look at this:
   void Heltec_ESP32::begin(bool DisplayEnable, bool LoRaEnable, bool SerialEnable, bool PABOOST, long BAND)
   heltec.cpp line 22
   and this
   void begin(bool DisplayEnable=true, bool LoRaEnable=true, bool SerialEnable=true, bool PABOOST=true, long BAND=470E6);
   heltec.h line 60
   it's fairly easy for me to tell that the parameter passes is wrong and the comment beside it is also wrong.

[rbergen]

Concerning 1, what Dave said.

Concerning 2, after also taking a look at heltec.h I'd now say that the code is correct (it enables the display AND the Lora module in all cases), but the comments are wrong. It should look like this:

Heltec.begin(true /*DisplayEnable Enable*/, true /*LoRa Enable*/, false /*Serial Disable*/);

Which means there's room for improvement from a code documentation perspective, but the code itself is correct.

[BigDurl]

why would anyone want to enable LoRa when this project never touches it and it has the potential to cause problems and frustration.
It should be set to disabled by default

[rbergen]

I guess I misread your earlier comment:

With boards that don't have LoRa. The code is smart enough to just pass on by and print to serial that the board does not have LoRa function.

I thought you meant to say it can be enabled on non-Lora boards, because if the Heltec code doesn't find a Lora module, it will just ignore the request to enable it. Which I still think is true, but I now understand was not the point you tried to make.

At the same time, if we don't want to enable the Lora module for either non-Lora or Lora boards, then we don't need to make a distinction between the two boards from that perspective. The only reason to make that distinction would then be to figure out what screen driver logic to use, if there is a difference between non-Lora and Lora boards on that front.

[BigDurl]

As far as i can tell there seams to be very little to no difference between the screen driving logic on the LoRa and non-LoRa boards.
Only possible difference is how some color stuff is handled. Like in my one other comment.

[davepl]

That’s the beauty of open source. If it doesn’t work the way you like it, and folks agree your way is better, you can check the fix right into the code! - Dave

…

On Nov 20, 2024, at 10:09 AM, BigDurl ***@***.***> wrote: I hate the way this code is written. I have to attach a button and press it to see basic info. I'm still confuse where the black and white bars come from when it starts up. I'm very much a beginner but if I look at this: Heltec.begin(true /*DisplayEnable Enable*/, true /*LoRa Disable*/, false /*Serial Enable*/); screen.h line 363 and then I look at this: void Heltec_ESP32::begin(bool DisplayEnable, bool LoRaEnable, bool SerialEnable, bool PABOOST, long BAND) heltec.cpp line 22 and this void begin(bool DisplayEnable=true, bool LoRaEnable=true, bool SerialEnable=true, bool PABOOST=true, long BAND=470E6); heltec.h line 60 it's fairly easy for me to tell that the parameter passes is wrong and the comment beside it is also wrong. — Reply to this email directly, view it on GitHub <#667 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF4M3W7NKUZEWD2I3MD2BTF5JAVCNFSM6AAAAABSBI4OBSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZSG4YDMNA>. You are receiving this because you are subscribed to this thread.

[rbergen]

I think the core point of this discussion got addressed with the merge of #668.