As best I can tell the reset pin is not necessary, only in this specific library is it done and it appears to be done primarily for SPI based displays. Now, this Heltec ESP32 LoRa OLED board may be an odd ball hybrid. As best I can tell though, SDA and SCL are on standard pins (https://github.com/espressif/arduin...riants/heltec_wifi_lora_32/pins_arduino.h#L23). However, that said, this could still be an odd ball board with an SPI/I2C hybrid with the reset pin exposed. It shouldn't be too difficult to add a display reset piece if the pin is defined in Config.h for it. I have a board sitting on my desk that matches up with the ESP32 Lolin OLED board that is on the wiki, I will see if I can get some testing in with that and see if it also needs a reset. I will also order a pair of Heltec ESP32 LoRA boards but they will take time to get here from China.
Scratch that! I found a pinout on aliexpress which confirms your pin mappings! Thankfully the pins used are not critical for the base station operations! I will add the RESET support and have a flag to enable it soon.
I'm also curious about this reset pin. Remember what I said about the display not completely resetting in between flashing code with different screen orientations? I never could figure out exactly why that was happening with the DCCppESP32 code, but when I go back to my bridge test code which only does a simple clearscreen, it fully wipes the screen each time it starts up. Similar code in DCCppESP32 seems to have no effect.
Yeah, which board do you have again? Is it the heltec wifi kit or Lora board or is it one of the lolin boards? Sent from my ONEPLUS A5010 using Tapatalk
Mine is marked as a Wemos Lolin32 (it's the one you had in the wiki a couple months ago). I've seen the pinouts from the board itself but never anything about the internal wiring of the board. Mine does use pins 4/5 for sda/scl though and I haven't seen any mention of a reset pin. Judging by all the OLED-connected pins on the diagram above, that certainly looks more like an SPI connection rather than an I2C connection though, so I doubt it's likely my board has that feature.
@jrob3rts Would you share the platformio.ini? I did the same as you did before and it wont work. so I have to define the SDA and SCL explicitly and assign SDA and SCL to the INFOR_SCREEN_xxx_PIN respectively...
@Atani Not sure if this is the correct/best way to do this, but here is what I have in my platformio.ini Code: [env:heltec] extra_scripts = build_index_header.py platform = espressif32 board = heltec_wifi_lora_32 and Config.h and InfoScreen.cpp Code: // Config.h #ifdef ARDUINO_Heltec_WIFI_LoRa_32 #define SDA 4 #define SCL 15 #define RST 16 #endif // InfoScreen.cpp ::init() #ifdef ARDUINO_Heltec_WIFI_LoRa_32 pinMode(RST, OUTPUT); digitalWrite(RST, LOW); delay(50); digitalWrite(RST, HIGH); #endif Wire.begin(INFO_SCREEN_SDA_PIN, INFO_SCREEN_SCL_PIN);
Guys, does this station has short curcuit protection? Does it depend on the motorshiled being used? And is there a good manual with pictures explaining how to set up, except for that placed on github?
Yes it has short circuit protection, that is a standard feature in the way motor shields are used. It does depend on the motor shield for the trigger point. This thread has a few more pictures which will be out up on GitHub soon. I am working on expanding the documentation but it is taking time due to other commitments. Sent from my ONEPLUS A5010 using Tapatalk
Atani, I've been noticing that the current detection on the BTS board seems to be all over the place. I saw once that the displayed current draw while running a loco very closely matched what my meter was showing, but since then it always shows 0.00 even with the loco running. Also playing with that light bulb again which draws about 2.5A -- on one BTS board it will continue running fine and on the other BTS board it shuts down the track with fault warnings. I have this feeling I'm going to have to set up a voltage divider rather than using the db adjustments in code. Just wondering if you had any chance to experiment with this particular board yet?
Hi, I'm using the non Lora version, so mine shows this: Code: platform = espressif32 board = heltec_wifi_kit_32 I have this in my infoScreen.cpp (just after Wire.begin(INFO_SCREEN_SDA_PIN, INFO_SCREEN_SCL_PIN); on line 64): Code: #if defined(INFO_SCREEN_RST_PIN) pinMode(INFO_SCREEN_RST_PIN, OUTPUT); digitalWrite(INFO_SCREEN_RST_PIN, LOW); delay(50); digitalWrite(INFO_SCREEN_RST_PIN, HIGH); #endif I have this in my config.h Code: #define INFO_SCREEN_SDA_PIN 4 #define INFO_SCREEN_SCL_PIN 15 #define INFO_SCREEN_RST_PIN 16 // OLED SCREEN PARAMETERS #define INFO_SCREEN_OLED true // OLED SUPPORTED CHIPSETS: SH1106, SH1306 #define OLED_CHIPSET SH1306 #define INFO_SCREEN_OLED_I2C_ADDRESS 0x3C #define INFO_SCREEN_OLED_VERTICAL_FLIP false #define INFO_SCREEN_OLED_LINES 5
Hi Atani, Following on from Texas Tim's findings I have added a pull request to handle the Heltec OLED screens. I believe this is zero impact to those without those screens. James
One note there change coming for the oled screen type, SH1306 is not correct and will be changed to SSD1306 to match the part numbers. Sent from my ONEPLUS A5010 using Tapatalk
Thanks, I will review and merge it shortly. Likely with a couple small adjustments. It should be possible to detect the esp32 variant and automatically handle reset only for the heltec boards . Sent from my ONEPLUS A5010 using Tapatalk
Updated the naming and merged to master. v1.1.2 is up now on master but not on the releases tab (will handle shortly). Thanks for the fix. I am going to look at a few adjustments to how the config is done so that we can handle some of it in an automated fashion so this may be adjusted further in an upcoming release.
Just to add to your findings @Curn, I did most of the testing of @Atani's S88 code on an ESP32 Arduino form factor board, but also tested using many others - Wemos LoLin32, those with integrated OLED boards, (Not the LoRa board) and the small "mini" boards. In general, his code is Very generic and I would venture to say that apart from paying attention to minor issues such as I2C and SPI pin assignments, all board versions using the WROOM-32 chip should be good to go
Yes the code is very generic to the esp32, just be sure to set the correct board type in the platformio.ini file and set pins accordingly in Config.h. I plan on adding some auto-config support soon based on board types. There are a few with integrated hardware and we can auto-config those. Sent from my ONEPLUS A5010 using Tapatalk
Thanks for the info. I’m going to order in one of the black esp32 unos (looks like a Wemos board) and give it a try.
