NOTHING WORKS

[NorthBaandee]

The examples as published upload successfully to my esp32s (I have TTGO_OLED_LORA and NodeMCU-32S boards) but nothing is ever displayed on the OLEDs or received in the serial monitor. The NodeMCU-32S just gets hot. There is nothing wrong with the boards. I can run most other sketches without problems.

[timmbogner]

Hi @NorthBaandee ,
I've compiled and uploaded the 1_UART_Gateway sketch to a variety of ESP32 boards, including the TTGO LoRa32 V1 and they all send some form of the following message over the serial port after boot:

19:03:33.318 -> ets Jun  8 2016 00:22:57
19:03:33.318 -> 
19:03:33.318 -> rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
19:03:33.318 -> configsip: 0, SPIWP:0xee
19:03:33.318 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
19:03:33.318 -> mode:DIO, clock div:1
19:03:33.318 -> load:0x3fff0030,len:1344
19:03:33.358 -> load:0x40078000,len:13964
19:03:33.358 -> load:0x40080400,len:3600
19:03:33.358 -> entry 0x400805f0
19:03:33.612 -> Address:1
19:03:33.612 -> Initializing ESP-NOW!
19:03:33.679 ->  ESP-NOW Initialized.

I am using the newest version of both Arduino IDE and the ESP32 board definitions. Without more details, I can't really tell you why it's not working on your end. What exactly does the serial monitor display when your ESP32 is booting?

Note that the OLED screen is not enabled by default, and should be configured and enabled using these configs:

// OLED -- Displays console debugging messages on an SSD1306 I²C OLED
#define USE_OLED    
#define OLED_HEADER "FDRS"
#define OLED_PAGE_SECS 30
#define OLED_SDA 4
#define OLED_SCL 15
#define OLED_RST 16

[timmbogner]

Any time the ESP32 boots, it sends some data out over it's serial port. If you aren't able see some data on the serial monitor every time you reset the ESP32 module, that indicates you have an issue between your module and your computer. For the sake of testing, try running this example sketch from Espressif and see if anything changes: Examples/ESP32/ResetReason

[NorthBaandee]

serial output of reset reason:
10:40:31.457 -> CPU0 reset reason:
10:40:31.457 -> POWERON_RESET
10:40:31.457 -> Vbat power on reset
10:40:31.457 -> CPU1 reset reason:
10:40:31.457 -> EXT_CPU_RESET
10:40:31.457 -> for APP CPU, reseted by PRO CPU
10:40:31.457 -> Going to sleep

[timmbogner]

There is something wacky going on with serial now, that never previously occured. I have a sketch that sets up an access point which controls four relays. The access point starts, I can join it, load it's web page and control the relays, but I see nothing on the serial monitor. This is new behaviour. Previously it showed the IP, the relay states etc. Now I see absolutely nothing. I just uploaded a sketch which does nothing more than Serial.println("hello"); over and over. nothing.

It sounds like intermittent serial interruptions, which could be as simple as replacing your USB cable.

[timmbogner]

Also could be something with USB permissions in Linux. I've dealt with that in Ubuntu but it's been a while.

[NorthBaandee]

Yep I don't get it at all. I'm on linux Mint. BTW just to add to my woes I cannot get grafana to work on raspi zeroW. The whole package seems to be seriously broken, and either segfaults or "performs illegal instructions". Maybe Trump has been tampering with it.
anyway I think you are antipodal to me and therefore 12hours time difference.

[svdrummer]

Is this one of those boards with USB built in like the S3 boards,? I had issues with serial. it is a config setting on the IDE

[NorthBaandee]

What sort of issues? This board works perfectly with every other sketch i have uploaded to it. Ive had it controlling 4 mains power outlet relays and correctly reporting it over /dev/ttyUSB0.
I have noticed that arduino 2 sometimes cannot decide whether usb is on /dev/ttyAMA0 or /dev/ttyUSB0 but that is not a big deal.

[svdrummer]

Just trying to rule out an issue. following the fault. Ie, the code works for Tim, not for you. Hence the issue could be at your end. Some chips dont release the USB programming to the serial port, unless it is set. As you have your board working with other projects, then that must be okay.

[NorthBaandee]

There is something wacky going on with serial now, that never previously occured. I have a sketch that sets up an access point which controls four relays. The access point starts, I can join it, load it's web page and control the relays, but I see nothing on the serial monitor. This is new behaviour. Previously it showed the IP, the relay states etc. Now I see absolutely nothing. I just uploaded a sketch which does nothing more than Serial.println("hello"); over and over. nothing.

[svdrummer]

Check

USB CDC On Boot | Enabled

In the config section on the IDE. This tells the programming port to switch to serial monitor after programming. If disables, the serial monitor is blank.

[NorthBaandee]

I had a look at top on the zeroW and yeah influxdb really hogs it. So i have disable it for the tome being.
I have configured it so that /dev/ttyAMA0 is on pins 8 and 10 and if i wire them to the TX and RX pins on the nodeMCU32-S i can see the output of ResetReason.ino by doing cat /dev/ttyAMA0
However if I load the frds uart gateway sketch nothing is received.
Looking at the fdrs_gateway_serial.h file there are no RXD2 and TXD2 pin definitions matching the nodeMCU32-S, which is TX on GPIO1 and RX on GPIO3.
Or am i barking up the wrong tree here?

[timmbogner]

I'm not sure what's up with your serial ports. I use a Win10 machine for the most part, so I'm not sure where to start debugging that. I'll revisit this if I get reports of more UART issues with FDRS.

In case it helps here is the overview of UART (serial) works on the ESP32 gateway:

The ESP32 chip has three UART interfaces, two of which may be used in FDRS. The pin assignments of all three can be changed, but the first usually shouldn't be.

• The first, 'Serial' or UART0 is the serial port used for the USB interface. It is the interface that generally programs the chip, as well as displays messages in the serial monitor. It is by default connected to GPIO3 and GPIO1, and in most cases it is physically connected to USB-UART chip via these two pins. If you change this assignment, your serial monitor will go blank. This is because the pins that the USB interface is connected to are no longer being used for UART. In FDRS, this interface will display debugging information as long as FDRS_DEBUG is defined. It will always display any JSON data being sent by the sendSerial() function.

• The second interface, 'Serial1' or UART1 is the one which can be configured within FDRS. This interface does not display debugging information, and only prints JSON data. Define them with TXD2 and RXD2 in the gateway config file, or FDRS will choose default pins that are friendly to your chip.

[NorthBaandee]

The serial ports are driving me insane. I got rxd2/txd2 working on the nodeMCU32-s by setting them to RXD2 = gpio16 and TXD2 = gpio17. I cannot understand why some sketches produce reliable transmissions on USB serial and others do not. Perhaps there is an issue with nodeMCU32-s boards. The ttgo boards don't seem to have any problems. Another thing i have noticed is the lora range seems poor using radiolib at 866mhz 17db compared to the sandeep library. (Yes i know we are supposed to use 915 in australia but i only have 866 antennae at the moment). I might do some more testing once i get my basic setup more reliable. Just need to modify the lora gateway sketch to send rx dbi telemetry i think. Thanks for putting up with me. I'm a bit of a noob

[svdrummer]

Just as a side, if you are closer to cities, Telstra monitor frequencies as they have the rights to those. I think they are setting up a public/for a fee LORA/IOT network. Fines from ACCC have been threatened. I am waiting on the correct frequency lora at the moment. I am not happy about Telstra sticking it's nose in.

[NorthBaandee]

I am in a very remote location so not worried about telstra yet. 433 should give the best range. In my experience as a radio amateur ACMA will only move if there is a complaint, and even then they will try for a technical rather than a punitive solution.