Heltec wireless tracker v1.1 no response

#4

You’re welcome :slight_smile: happy to give back to the community!
You shouldn’t need a programmer nor really have to dig into all USB modes.
All you should need to do, is change any reference to Serial into USBSerial and you’ll see that the device is still alive.
As long as your USB cable is capable of uploading to the board, it’ll work fine for serial communication.

#5

Hurray, more success: display working!

Edit the following file:

  • C:\Users\{user}\AppData\Local\Arduino15\packages\Heltec-esp32\hardware\esp32\0.0.8\libraries\DISPLAY\src\HT_st7735.h

Pin definitions should read as follows:

/*** Redefine if necessary ***/
#define ST7735_CS_Pin        38
#define ST7735_REST_Pin      39
#define ST7735_DC_Pin        40
#define ST7735_SCLK_Pin      41
#define ST7735_MOSI_Pin      42
#define ST7735_LED_K_Pin     21
#define ST7735_VTFT_CTRL_Pin -1

Edit the following file:

  • C:\Users\{user}\AppData\Local\Arduino15\packages\Heltec-esp32\hardware\esp32\0.0.8\variants\wireless_track\pins_arduino.h

Line 74 should read as follows:

static const uint8_t Vext = 3;

In your .ino file, the VextON() and VextOFF() should read as follows:

void VextON(void)
{
  pinMode(Vext,OUTPUT);
  digitalWrite(Vext, HIGH);   // active HIGH
}

void VextOFF(void)
{
  pinMode(Vext,OUTPUT);
  digitalWrite(Vext, LOW);
}
1 Like
Heltec HTIT-Tracker V1.0
#6

Maybe just check those suggestions there in relation to switching Vext ON and OFF.

Heltec haven’t helped the situation with their pin labelling in this case, but the pin identified as Vext in the pins_arduino.h file, the one usually referred to when coding, is usually actually the pin identified as Vext Control or Vext_Ctrl (Heltec is not consistent in their documentation in this regard either) in pinout diagrams, not the Vext power pin itself. Vext_Ctrl, in turn, is used to control a MOSFET that switches Vext ON or OFF, and this is where the confusion arises. To switch Vext ON, Vext_Ctrl (which is identified in the pins_arduino.h file, and hence in your code, as Vext) is set LOW, and to switch Vext OFF, Vext_Ctrl is set HIGH.

There was also a recent thread in relation to one of the other Heltec boards that indicated that, in spite of what might have been suggested in the relevant schematic diagram, the OLED display is not powered through Vext.

None of this is based on any understanding to the Wireless Tracker board, but given that it applies to other Heltec boards, it may be relevant in the present case.

#7

USBSerial.begin Is throwing a “USBSerial” was not declared in this scope. Do I need to include a different library? All I have found is references to SerialUSB.

#8

Hi Todd, do you have the same values set in the Tools menu of the Arduino IDE?
image

#9

Yes I do! I also have USB CDC on Boot =enabled. I tried it disabled but still no joy.

#10

Hmm, interesting. But you are able to program the board?
If so, could you then try to get the display alive using the edits I proposed?

#11

I added a: #define USBSerial Serial

which gets it to comlile but the board is still “Dead”.

I have the edits you mentioned above completed. I went through the schematic last night and I see why you changed some of the pin numbers and the Vext.

#12

Do you have access to a multimeter (or an LED with a resistor)?

What happens with the following sketch?

#define Vext 3

void setup() {
  pinMode(Vext, OUTPUT);
}

void loop() {
  digitalWrite(Vext, HIGH);
  delay(5000);
  digitalWrite(Vext, LOW);
  delay(5000);
}

(of course, measure the voltage difference over Ve and GND / plug a LED into those)

1 Like
#13

That works! I should have thought of that test! I added in a serial.begin and was able to print to the serial port. USBSerial still wont compile. Now I’ll try to add in the display.

#14

I just added in the init and include for the display and now the back light is flashing with the Vext pin! Making progress!

1 Like
#15

I have a Display!

PXL_20230818_233954682
PXL_20230818_233954682.jpg3840×2160 348 KB

I made my own stripped down test for the display since the examples still don’t seem to work. I don’t understand how the examples are controlling the Vext pin. The tracker V1.1 schematic (V0.5?) shows the Vext Ctrl signal enabling a 3.3V LDO, which powers the display and the backlight. The back light also has a Mosfet controlled by LED K from the MCU. I have not figured out how LED K is being enabled as I am not doing anything with it. Maybe the ST7735 init function? Maybe it defaults On somehow?

My discovery was making sure Vext was high before I allowed the display enable function. I am using all of the changes listed above by @bns -Thank you Sir!

My working code:

#include "HT_st7735.h"
#include "Arduino.h"
HT_st7735 st7735;

void setup() {
  pinMode(Vext, OUTPUT);
  digitalWrite(Vext, HIGH); //LCD needs power before init.
  Serial.begin(115200);
  st7735.st7735_init();
  Serial.printf("Ready!\r\n");
}

void loop() {
  // Check border
    st7735.st7735_fill_screen(ST7735_BLACK);
    st7735.st7735_write_str(0, 0, (String)"gps_test");
    Serial.print("made it to BLACK");

    for(int x = 0; x < ST7735_WIDTH; x++) {
        st7735.st7735_draw_pixel(x, 0, ST7735_RED);
        st7735.st7735_draw_pixel(x, ST7735_HEIGHT-1, ST7735_RED);
    }

    for(int y = 0; y < ST7735_HEIGHT; y++) {
        st7735.st7735_draw_pixel(0, y, ST7735_RED);
        st7735.st7735_draw_pixel(ST7735_WIDTH-1, y, ST7735_RED);
    }

    delay(3000);

}
1 Like
#16

I added the two lines below to set Vext high and the Heltec example ST7735_SPI.ino is now working too. I feel like there is a better way to do this. I’m not a coder so I’ll be struggling along.

void setup()
{  
    pinMode(Vext, OUTPUT);
    digitalWrite(Vext, HIGH); //LCD needs power before init?
    st7735.st7735_init();
    Serial.printf("Ready!\r\n");
    Serial.begin(115200);
#17

Your insistence that setting ‘Vext’ HIGH enabled Vext really troubled me but now, having access to the schematic diagram, I can see that the Wireless Tracker is different to other Heltec boards. In this case, Vext is not controlled by a MOSFET, which is switched on by setting ‘Vext’ LOW, but rather now appears to be directly connected to its own regulator, which is indeed enabled by setting ‘Vext’ HIGH—a bit of a trap for old players there…

Perhaps it should then also be no surprise if the OLED display is actually powered through Vext in this case.

1 Like
AB02 Low Power Mode consumption 45uA
#18

I have everything in the Wireless tracker factory test.INO functioning except for the LoRa radio. I’m not sure what to do next with it. I’m in the US at 915Mhz, beyond that I’m not sure what settings to use or how to connect to a network. I had found a page that is using the Helium network but I’m not sure if that’s what I need or not. The end result is intended to be a Vehicle tracker in case of theft.

#19

Great to hear you’ve got it all going! :smiley:
I actually managed just fine to get my device talking to TTN - just copy the set of EUIs/keys, set a more appropriate dutycycle and disable confirmed uplinks.
I am however located in the 868MHz zone, so all other parameters were correct by default.
Are you eyeing to use TTN as well?

#20

TTN does not seem to be very prevalent around here (North Texas) There are quite a few helium gateways here. I went through a document helium has for the Cubecell. I copied the code and started going through clearing all the compile errors since its for a V2? esp32. but I cant get it working. I also found the LoRaWAN_Downlinkdatahandle.INO from Heltec and it does compile. I added the Device and App EUI’s I got from Helium and the App key, but it fails to connect. I drove the Wireless tracker to the street where the closest gateway is and it still wont connect. I don’t know which of the myriad of settings I have wrong.

#21

I would definitely recommend to use any of the LoRaWAN examples for a V3 board, as the V2s have an other chip which is partly incompatible. So that’s a no-go.
I have zero experience with Helium, but there are at the bare minimum a couple things to pay attention to:

  • frequency (not the default 868 that is configured)
  • how you generate the devEui (default is generated by ESP’s chipID, but you should set to Custom if generated by Helium)

Note that I am unsure if Helium gateway locations are always correct - at least on TTN, some users purposely set a similar but incorrect location to hide their address or gateway location. So it may not actually be the case that you are exactly at the correct location. And maybe that person deployed it within a house or basement for personal testing, which may limit coverage as well.

#22

I’m at 915Mhz and thanks for the tip about the devEUI. Luckily I’m already set to custom. I have a long week of travel. Hopefully I’ll get some time to try it out in a different location- San Francisco and Oklahoma city.

#25