Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tlora-v2 shows flickery progress bar when connected over USB serial #341

Closed
gkelly opened this issue Aug 26, 2020 · 15 comments
Closed

tlora-v2 shows flickery progress bar when connected over USB serial #341

gkelly opened this issue Aug 26, 2020 · 15 comments
Assignees
Labels
bug Something isn't working

Comments

@gkelly
Copy link
Contributor

gkelly commented Aug 26, 2020

Describe the bug
When my tlora-v2 is connected to a PC via USB and then connected to with screen/tio/meshtastic the display shows a progress bar over top of the current display, which kind of flickers and restarts: https://youtu.be/443GvUBXtm0

A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

  1. Load 0.9.2 or 0.9.3 onto a tlora-v2.
  2. Connect the lora32 to a PC via USB.
  3. Run meshtastic.
  4. Look at tlora-v2 display.

Expected behavior
I expect no change to the screen contents.

Screenshots
https://youtu.be/443GvUBXtm0

Device info:

  • Device model: tlora-v2
  • Software Version: 0.9.2 and 0.9.3

Comments from thread
@gkelly
I’ve noticed that on 0.9.2 and 0.9.3 if I connect the USB serial console (or just running meshtastic for logging) that the OLED display on my lora32-v2 will kind of dim out and then show a progress bar in a loop: https://youtu.be/443GvUBXtm0

@geeksville
Hmm. Does that device have a button for next screen? I forget.

It looks like it thinks that button is being pressed. Would you mind filling a bug and hopefully one of the devs they have that board type can take a look? Can you copy in these comments?

@geeksville
Copy link
Member

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/ttgo-lora-v2-board-specific-issues/1138/3

@geeksville
Copy link
Member

I forget, @slavino did you also have have a lora-v2 board? do you see this same behavior on this board? Can anyone here point me at PDF for the schematics of the board and I'll take a look?

@geeksville geeksville added the bug Something isn't working label Aug 26, 2020
@gkelly
Copy link
Contributor Author

gkelly commented Aug 26, 2020

I believe that this is the schematic for the LORA32 v2 (which is the device I'm using): https://github.com/LilyGO/TTGO-LORA32/blob/master/schematic1in6.pdf

@thomslik
Copy link

This sounds like the same issue as #272 on the LoRa32-V2.1.

@aHVzY2g
Copy link
Contributor

aHVzY2g commented Aug 26, 2020

@gkelly checkout #274, I guess if you flash firmware-tlora-v2-1-1.6-*.bin you will be fine.

@geeksville
Copy link
Member

yep - now that I thought about it, that change should also fix this. #322

@geeksville
Copy link
Member

(please reopen if it doesn't)

@gkelly
Copy link
Contributor Author

gkelly commented Aug 27, 2020

@gkelly checkout #274, I guess if you flash firmware-tlora-v2-1-1.6-*.bin you will be fine.

I've flashed firmware-tlora-v2-1-1.6-US-0.9.3.bin from the 0.9.3 release and it results in a boot loop.

@gkelly
Copy link
Contributor Author

gkelly commented Aug 27, 2020

yep - now that I thought about it, that change should also fix this. #322

I've checked out master and flashed the tlora-v2 variant, which exhibits the same brightness-bar problem and also the tlora-v2-1-1.6 variant which results in the splash screen and then the device turning off.

This is the device in question:

IMG_20200826_202602

IMG_20200826_202613

Which was sold as "TTGO LORA32 V2.0". The 2.0-1-1.6 variant appears to have an SMA connector, which this one does not, so I do think that the tlora-v2 board is the correct environment.

I checked out the 0.9.1 tag and verified that the behavior isn't present there, and that the device works on the tlora-v2 environment.

I used git bisect to track down the change that introduced the problem:

ca75dcd64dfe087feaa8554e39f2ee3f67b0b54c is the first bad commit
commit ca75dcd64dfe087feaa8554e39f2ee3f67b0b54c
Author: geeksville <kevinh@geeksville.com>
Date:   Thu Aug 20 15:42:36 2020 -0700

    Add support for SX1262 based TBEAMs, see below for more details.
    
    We probe dynamically for the SX1262 or RF95 based radios on TBEAM1.0
    boards now.  If either is present it will be used.

 src/configuration.h            | 82 ++++++++++++++++++++++++++++--------------
 src/main.cpp                   | 41 ++++++++++++++++-----
 src/mesh/RadioLibInterface.cpp |  1 -
 3 files changed, 88 insertions(+), 36 deletions(-)

That change does touch pinout definitions, but I'm not familiar enough with how those definitions work here to see the bug.

I don't have permission to reopen this issue, but I do think it's an issue that exists at master for tlora-v2.

@geeksville geeksville reopened this Sep 8, 2020
@geeksville
Copy link
Member

ok - I'll add the same fix for lora-v2 that was applied to lora-v2-1.6. Thanks for the investigation.

@geeksville geeksville self-assigned this Sep 8, 2020
@geeksville geeksville added this to To do in Meshtastic work via automation Sep 8, 2020
@geeksville geeksville moved this from To do to In progress in Meshtastic work Sep 8, 2020
@geeksville
Copy link
Member

Ok - I just checked code to treat the internal pullup on these boards the same as lora-v2-1.6. Could one of ya'll who has this problem try it and report back (I'll release a build later today). Please @ me in the comment to make sure github yells at me ;-).

@gkelly
Copy link
Contributor Author

gkelly commented Sep 8, 2020

@geeksville, I checked out your Meshtastic-esp32 fork, and ran pio run --environment tlora-v2 -t upload. The issue persists unfortunately.

@gkelly
Copy link
Contributor Author

gkelly commented Sep 8, 2020

I wrote #369 thinking that it might make sense to ship tlora-v2 without BUTTON_PIN defined, but I know that breaks the contract a bit with people who've already attached a button.

@geeksville
Copy link
Member

@gkelly I like #369 anyways for different reasons. But when this new build comes out I bet turning on the internal pullup (which I just did to configuration.h in a different commit) will fix both button and non button installed boards. Do you mind trying it and reporting back?

@geeksville geeksville moved this from To do to Done in Meshtastic work Sep 10, 2020
@gkelly
Copy link
Contributor Author

gkelly commented Sep 10, 2020

@geeksville Happy to try any change, but are you referring to geeksville@0a9f714? If so, that was in the build I tested on Wednesday that still exhibits the issue.

Dafeman pushed a commit to Dafeman/Meshtastic-device that referenced this issue Sep 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Development

No branches or pull requests

4 participants