TTGO LoRa32-OLED V1 Configuration

[mczakk]

Hi Matthias - me again!
I have complied and uploaded this code to my esp32 (TTGO LoRa32-OLED V1 with

// Enable debug mode (debug messages via serial port)
// Arduino IDE: Tools->Core Debug Level: "Debug|Verbose"
#define CORE_DEBUG_LEVEL ARDUHAL_LOG_LEVEL_DEBUG
//#define CORE_DEBUG_LEVEL ARDUHAL_LOG_LEVEL_VERBOSE

defined, but am not seeing anything in the serial monitor.
how can i check that the board is recieving the data from the bresser?

Cheers
Matt

[matthias-bs]

Hi Matt,

actually you do not have do change anything in the code - just follow this description:
https://github.com/matthias-bs/BresserWeatherSensorReceiver/blob/main/DEBUG_OUTPUT.md

(Yes, this should be added to the TTN project, too!)

Regards
Matthias

[mczakk]

ok, an update !
I now get one recieved message in the serial monitor, the code then fails as can be seen below..

16:13:35.816 -> [D][WeatherSensor.cpp:238] getMessage(): [SX1276] Receive failed: [0]
16:13:45.421 -> [V][WeatherSensor.cpp:217] getMessage(): [SX1276] Data: D4 F6 77 38 05 35 05 18 FE EE FE 10 28 02 16 90 FF F0 B7 AA 00 00 00 00 00 00 00 
16:13:45.421 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -76.5
16:13:45.421 -> [V][WeatherSensor.cpp:284] findSlot(): find_slot(): ID=38053505
16:13:45.421 -> [V][WeatherSensor.cpp:338] findSlot(): find_slot(): Storing into slot #0
16:14:21.424 -> [V][WeatherSensor.cpp:217] getMessage(): [SX1276] Data: D4 4B EF 38 05 35 05 18 FF FF FF 10 28 FF 6F 69 FF 01 64 AA 00 00 00 00 00 00 00 
16:14:21.424 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -77.0
16:14:21.424 -> [V][WeatherSensor.cpp:284] findSlot(): find_slot(): ID=38053505
16:14:21.424 -> [V][WeatherSensor.cpp:332] findSlot(): find_slot(): Updating slot #0
16:14:21.424 -> [D][BresserWeatherSensorTTN.ino:1075] setup(): Receiving Weather Sensor Data o.k.
16:14:21.456 -> [D][BresserWeatherSensorTTN.ino:587] setup(): mySensor.setup() - done
16:14:21.456 -> [D][BresserWeatherSensorTTN.ino:591] setup(): myLoRaWAN.setup() - done
16:14:21.456 -> [D][BresserWeatherSensorTTN.ino:1147] getVoltage(): Voltage = 284mV
16:14:21.456 -> [D][BresserWeatherSensorTTN.ino:1164] getVoltage(): Voltage = 284mV
16:14:21.489 -> [D][BresserWeatherSensorTTN.ino:1272] doUplink(): --- Uplink Data ---
16:14:21.489 -> [D][BresserWeatherSensorTTN.ino:1276] doUplink(): Air Temperature:     2.1 °C
16:14:21.489 -> [D][BresserWeatherSensorTTN.ino:1277] doUplink(): Humidity:            90   %
16:14:21.489 -> [D][BresserWeatherSensorTTN.ino:1278] doUplink(): Rain Gauge:         909.6 mm
16:14:21.489 -> [D][BresserWeatherSensorTTN.ino:1279] doUplink(): Wind Speed (avg.):    0.0 m/s
16:14:21.523 -> [D][BresserWeatherSensorTTN.ino:1280] doUplink(): Wind Speed (max.):    0.0 m/s
16:14:21.523 -> [D][BresserWeatherSensorTTN.ino:1281] doUplink(): Wind Direction:     102.0 °
16:14:21.523 -> [D][BresserWeatherSensorTTN.ino:1306] doUplink(): Supply  Voltage:    284   mV
16:14:21.523 -> [D][BresserWeatherSensorTTN.ino:1309] doUplink(): Battery Voltage:    284   mV
16:14:21.523 -> [D][BresserWeatherSensorTTN.ino:1325] doUplink(): 
16:14:21.554 -> [D][BresserWeatherSensorTTN.ino:1414] doUplink(): Rain past 60min:      0.0 mm
16:14:21.554 -> [D][BresserWeatherSensorTTN.ino:1415] doUplink(): Rain curr. day:       0.0 mm
16:14:21.554 -> [D][BresserWeatherSensorTTN.ino:1416] doUplink(): Rain curr. week:      0.0 mm
16:14:21.554 -> [D][BresserWeatherSensorTTN.ino:1417] doUplink(): Rain curr. month:     0.0 mm
16:14:21.554 -> FAILURE 
16:14:21.554 -> c:\Users\mtc20tfq\Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\lmic\lmic_us_like.c:51

as yet the esp32 has not been registered on TTN as my gateway will arrive to tomorrow, but is this error to be expected if there is no lorawan connection?

Also, my board has a jumper from spio12 to the LORA chip, as described in Ulrich's post on Hackaday: https://hackaday.io/project/186339-lora-for-bresser-5-in1-weather-station-make-iot and shown here:

I'm unsure wether this is needed, but he does use your code!!

Cheers

Matt

[matthias-bs]

Hi,
yes... Another point I should add to the docs - you have to edit
Arduino/libraries/MCCI_LoRaWAN_LMIC_library/project_config/lmic_project_config.h to set the region, e.g. for Europe:

// project-specific definitions
#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP      /* for as923-JP; also define CFG_as923 */
//#define CFG_kr920 1
//#define CFG_in866 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS
#define hal_init LMICHAL_init
#define LMIC_ENABLE_DeviceTimeReq 1

[matthias-bs]

You can have a look if a TTN or Helium gateway is within reach:
https://www.thethingsnetwork.org/map
https://explorer.helium.com/

[matthias-bs]

Let's see if we get the voltage measurements for your board to work.
Do you know the purpose of this wire?

[mczakk]

No, I haven't managed to connect with Ulrich to ask!
I know there is no TTN within reach, as i have a TTN registered node on my desk which is not connecting. There is a Helium gateway nearby, but as i will need to connect to TTn when i replace my bresser in the field, i'm not sure if I'm going to be able to connect it to both helium and TTN?

with your amendment to Arduino/libraries/MCCI_LoRaWAN_LMIC_library/project_config/lmic_project_config.h it now fails here!:

16:45:57.539 -> [D][BresserWeatherSensorTTN.ino:1415] doUplink(): Rain curr. day:       0.0 mm
16:45:57.539 -> [D][BresserWeatherSensorTTN.ino:1416] doUplink(): Rain curr. week:      0.0 mm
16:45:57.539 -> [D][BresserWeatherSensorTTN.ino:1417] doUplink(): Rain curr. month:     0.0 mm
16:45:57.539 -> FAILURE 
16:45:57.539 -> c:\Users\mtc20tfq\Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\lmic\radio.c:1164

Edit: i removed the jumper and it still fails in with the same message

[matthias-bs]

Did you see that the pin configuration has to be done in two places?
https://github.com/matthias-bs/BresserWeatherSensorTTN#configure-the-rf-transceiver-gpio-wiring

Maybe this thread also helps:
matthias-bs/BresserWeatherSensorReceiver#16

lmic_project_config.h should look like this:

// project-specific definitions
#define CFG_eu868 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS
#define hal_init LMICHAL_init
#define LMIC_ENABLE_DeviceTimeReq 1

[matthias-bs]

BTW: Did you check that none of the required pins is assigned for other purposes?

[mczakk]

I followed your link :https://github.com/matthias-bs/BresserWeatherSensorTTN#configure-the-rf-transceiver-gpio-wiring
and was unsure about what to change. I have defined 'ttgo lora32' - so do i have to change the entries in weathersensor.cfg.h for that (lines 171-181?)

Not sure how i'd check other pins, I haven't assigned them knowingly!

[matthias-bs]

No, the you mentioned configuration above is just fine. It is used for the sensor reception based on the BresserWeatherSensorReceiver library which in turn uses RadioLib.

Now you additionally have to modify the pin configuration to be used for LoRaWAN by BresserWeatherSensorTTN, which is based on MCCI Arduino LoRaWAN Library.

In BresserWeatherSensorTTN.ino, you should try to make the following changes:

// Pin mapping for ESP32 (MCCI Arduino LoRaWAN Library)
// Note: Pin mapping for BresserWeatherSensorReceiver is done in WeatherSensorCfg.h!
// SPI2 is used on ESP32 per default! (e.g. see https://github.com/espressif/arduino-esp32/tree/master/variants/doitESP32devkitV1)
#if defined(ARDUINO_TTGO_LoRa32_V1)
    // https://github.com/espressif/arduino-esp32/blob/master/variants/ttgo-lora32-v1/pins_arduino.h
    // http://www.lilygo.cn/prod_view.aspx?TypeId=50003&Id=1130&FId=t3:50003:3
    // https://github.com/Xinyuan-LilyGo/TTGO-LoRa-Series
    #define PIN_LMIC_NSS      LORA_CS
    #define PIN_LMIC_RST       LORA_RST
    #define PIN_LMIC_DIO0    LORA_IRQ
    #define PIN_LMIC_DIO1    cMyLoRaWAN::lmic_pinmap::LMIC_UNUSED_PIN
    #define PIN_LMIC_DIO2    cMyLoRaWAN::lmic_pinmap::LMIC_UNUSED_PIN
#else
    // LoRaWAN_Node board
    // https://github.com/matthias-bs/LoRaWAN_Node
    #define PIN_LMIC_NSS      14
    #define PIN_LMIC_RST      12
    #define PIN_LMIC_DIO0     4
    #define PIN_LMIC_DIO1     16
    #define PIN_LMIC_DIO2     17
#endif

Since the SPI configuration worked without changes for the sensor receiver, I assume it will also work out-of-the-box for the LoRaWAN transceiver.

And in BresserWeatherSensorTTNCfg.h:

//--- Select Board ---
#ifndef ARDUINO_TTGO_LoRa32_V1
    // Use pinning for LoRaWAN Node 
    #define LORAWAN_NODE
#endif
[...]

// ADC for supply/battery voltage measurement
// default: on-board connection to VB on FireBeetle ESP32 (with R10+R11 assembled)
//          on-board connection to VBAT on TTGO LoRa32
#ifdef ADC_EN
    #if defined(ARDUINO_TTGO_LoRa32_V1)
        #define PIN_ADC_IN        35
    #else
        #define PIN_ADC_IN        A0
    #endif
    //#define PIN_ADC_IN        34
#endif

// Additional ADC pins (default: FireBeetle ESP32) 
//#define PIN_ADC0_IN         A0
//#define PIN_ADC1_IN         A1
//#define PIN_ADC2_IN         A2
#ifdef LORAWAN_NODE
  #define PIN_ADC3_IN         A3
#endif
[...]
#ifdef ONEWIRE_EN
    #if defined(ARDUINO_TTGO_LoRa32_V1)
        #define PIN_ONEWIRE_BUS   21
    #else
        #define PIN_ONEWIRE_BUS   5
    #endif
#endif

This sets a board specific define, avoids a conflict of GPIO5 used for the LoRa radio and the OneWire bus at the same time and hopefully selects the correct ADC input for battery voltage measurement.

There actually seems to be no connection of the supply voltage to an ADC.

[mczakk]

ok, i think i've made the changes correctly, but now get this:

15:02:28.889 -> [D][BresserWeatherSensorTTN.ino:592] setup(): RTC sync required
15:02:28.889 -> [D][BresserWeatherSensorTTN.ino:598] setup(): myEventlog.setup() - done
15:02:28.889 -> [D][BresserWeatherSensorTTN.ino:1162] getVoltage(): Voltage = 4221mV
15:02:28.889 -> [D][WeatherSensor.cpp:81] begin(): [SX1276] Initializing ... 
15:02:28.930 -> [D][WeatherSensor.cpp:94] begin(): success!
15:02:28.930 -> [D][WeatherSensor.cpp:129] begin(): [SX1276] Setup complete - awaiting incoming messages...
15:02:34.751 -> [V][WeatherSensor.cpp:217] getMessage(): [SX1276] Data: D4 02 A4 38 05 35 05 18 FF 99 FF 27 68 07 26 60 FF F0 CE AA 00 00 00 00 00 00 00 
15:02:34.751 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -86.5
15:02:34.751 -> [V][WeatherSensor.cpp:284] findSlot(): find_slot(): ID=38053505
15:02:34.751 -> [V][WeatherSensor.cpp:338] findSlot(): find_slot(): Storing into slot #0
15:03:10.729 -> [V][WeatherSensor.cpp:217] getMessage(): [SX1276] Data: D4 9B BF 38 05 35 05 18 FF 88 FF 28 28 FF 6F 69 FF 01 C3 AA 00 00 00 00 00 00 00 
15:03:10.762 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -87.5
15:03:10.762 -> [V][WeatherSensor.cpp:284] findSlot(): find_slot(): ID=38053505
15:03:10.762 -> [V][WeatherSensor.cpp:332] findSlot(): find_slot(): Updating slot #0
15:03:10.762 -> [D][BresserWeatherSensorTTN.ino:1090] setup(): Receiving Weather Sensor Data o.k.
15:03:10.762 -> [D][BresserWeatherSensorTTN.ino:602] setup(): mySensor.setup() - done
15:03:10.762 -> 
15:03:10.762 -> c:\Users\mtc20tfq\Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\hal\hal.cpp:36

i also now have a ttn gateway, so should see if the ttgo tries to connect

[matthias-bs]

O.k.

Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\hal\hal.cpp:

    // NSS and DIO0 are required, DIO1 is required for LoRa, DIO2 for FSK
    ASSERT(plmic_pins->nss != LMIC_UNUSED_PIN);
    ASSERT(plmic_pins->dio[0] != LMIC_UNUSED_PIN);
    ASSERT(plmic_pins->dio[1] != LMIC_UNUSED_PIN || plmic_pins->dio[2] != LMIC_UNUSED_PIN);

The last line is line 36. The execution stops there, because DIO1 may not be unconnected.

The problem is, there is no official definition

• in the pinout diagram: http://www.lilygo.cn/prod_view.aspx?TypeId=50060&Id=1326&FId=t3:50060:3
• in the Arduino pin definitions for this board: https://github.com/espressif/arduino-esp32/blob/master/variants/ttgo-lora32-v1/pins_arduino.h
• or in this pinout table: https://github.com/Xinyuan-LilyGo/TTGO-LoRa-Series

The only clue I currently have is this circuit diagram:
https://github.com/LilyGO/TTGO-LORA32/blob/master/schematic1in6.pdf
I'm not sure if this is the correct one for your board (if the photo above is your board -> yes). According to it, IO33 would be the ESP32's GPIO pin connected to the radio transceiver's DIO1 pin.

So please try this in BresserWeatherSensorTTN.ino:

// Pin mapping for ESP32 (MCCI Arduino LoRaWAN Library)
// Note: Pin mapping for BresserWeatherSensorReceiver is done in WeatherSensorCfg.h!
// SPI2 is used on ESP32 per default! (e.g. see https://github.com/espressif/arduino-esp32/tree/master/variants/doitESP32devkitV1)
#if defined(ARDUINO_TTGO_LoRa32_V1)
    // https://github.com/espressif/arduino-esp32/blob/master/variants/ttgo-lora32-v1/pins_arduino.h
    // http://www.lilygo.cn/prod_view.aspx?TypeId=50003&Id=1130&FId=t3:50003:3
    // https://github.com/Xinyuan-LilyGo/TTGO-LoRa-Series
    #define PIN_LMIC_NSS      LORA_CS
    #define PIN_LMIC_RST       LORA_RST
    #define PIN_LMIC_DIO0    LORA_IRQ
    #define PIN_LMIC_DIO1    33
    #define PIN_LMIC_DIO2    cMyLoRaWAN::lmic_pinmap::LMIC_UNUSED_PIN
#else
    // LoRaWAN_Node board
    // https://github.com/matthias-bs/LoRaWAN_Node
    #define PIN_LMIC_NSS      14
    #define PIN_LMIC_RST      12
    #define PIN_LMIC_DIO0     4
    #define PIN_LMIC_DIO1     16
    #define PIN_LMIC_DIO2     17
#endif

If this does not work, you have to find out the connection otherwise - maybe you can check it with a multimeter, toggle one pin after another until you see the signal arriving at the required pin or try to google it.

[matthias-bs]

Maybe this is where the red wire comes into play: If we do not know the on-board connection, we create our own...
If you want to use it, you can use this:

#define PIN_LMIC_DIO1    12

Would you please do me a favor and try both variants?

[mczakk]

is that with the wire connected?

[matthias-bs]

Which antenna are you going to use? According to the circuit diagram, the large one (SMA) is connected (via R29 - 0 Ohms), while the small one (uFL) is unconnected (R28 - not assembled). You can change this if required (a solder bridge works well).
Both connections should not be made at the same time (RF circuit...)

An antenna should be connected, otherwise the transmitter RF front end could be destroyed!

[mczakk]

i'm using the antenna provided

[mczakk]

Damn, its now failing to compile with the error :

c:\Users\mtc20tfq\Arduino\libraries\MCCI_Arduino_LoRaWAN_Library\src\lib\arduino_lorawan_sessionstate.cpp: In member function 'void Arduino_LoRaWAN::BuildSessionState(Arduino_LoRaWAN::SessionState&) const':
c:\Users\mtc20tfq\Arduino\libraries\MCCI_Arduino_LoRaWAN_Library\src\lib\arduino_lorawan_sessionstate.cpp:104:76: warning: enumeral and non-enumeral type in conditional expression [-Wextra]
     constexpr unsigned maxCh = MAX_CHANNELS < State.V1.Channels.EUlike.nCh ? MAX_CHANNELS : State.V1.Channels.EUlike.nCh;
                                                                            ^
In file included from c:\Users\mtc20tfq\Arduino\libraries\MCCI_Arduino_LoRaWAN_Library\src\lib\arduino_lorawan_sessionstate.cpp:22:0:
c:\Users\mtc20tfq\Arduino\libraries\MCCI_Arduino_LoRaWAN_Library\src/Arduino_LoRaWAN.h: In member function 'bool Arduino_LoRaWAN::SessionChannelMask_EU_like<a_nCh, a_nBands>::setFrequency(uint8_t (&)[(nCh * 3)], unsigned int, uint32_t) [with unsigned int a_nCh = 16u; unsigned int a_nBands = 4u; uint8_t = unsigned char; uint32_t = unsigned int]':
c:\Users\mtc20tfq\Arduino\libraries\MCCI_Arduino_LoRaWAN_Library\src/Arduino_LoRaWAN.h:371:25: error: control reaches end of non-void function [-Werror=return-type]
                         }
                         ^
cc1plus.exe: some warnings being treated as errors

exit status 1

Compilation error: exit status 1

I'm losing the will to live!!!

[matthias-bs]

Keep cool! ;-)
In the end everything gonna be alright! If not, it's not the end...

Did you apply the fixed mentioned in this section?
https://github.com/matthias-bs/BresserWeatherSensorTTN#software-build-setup

[mczakk]

Yes, I re downloaded all the files and tried again with verbose debugging off. It seems that it was treating warnings as errors and not compiling. I think I just need to sort out the payload formatter now!

[matthias-bs]

To be clear, you should fix these mentioned bugs as described:
mcci-catena/arduino-lorawan#204
mcci-catena/arduino-lmic#714 (comment)

[matthias-bs]

Yes, I re downloaded all the files and tried again with verbose debugging off. It seems that it was treating warnings as errors and not compiling. I think I just need to sort out the payload formatter now!

Does that mean the code seems to work now? With which pin config?

[matthias-bs]

is that with the wire connected?

Yes, the red wire is the connection between the radio module pin 10 (DIO1) and the ESP32 GPIO pin 12.

[mczakk]

Using
#define PIN_LMIC_DIO1 12
With the wire connected.
"To be clear, you should fix these mentioned bugs as described:
mcci-catena/arduino-lorawan#204
mcci-catena/arduino-lmic#714 (comment)"
Ill do these tomorrow!
Thanks for your help Matthias 😁😁

[mczakk]

as far as i can see the two fixes are done in the current code, I've uploaded the payload formatter to ttn.
The code seems to complie and upload fine, this is the output from serial monitor:

12:23:22.543 -> �[V][Preferences.cpp:341] getUChar(): nvs_get_u8 fail: ws_timeout NOT_FOUND
12:23:23.043 -> [D][BresserWeatherSensorTTN.ino:573] setup(): Preferences: weathersensor_timeout: 180 s
12:23:23.043 -> [V][Preferences.cpp:365] getUShort(): nvs_get_u16 fail: sleep_interval NOT_FOUND
12:23:23.043 -> [D][BresserWeatherSensorTTN.ino:575] setup(): Preferences: sleep_interval:        360 s
12:23:23.043 -> [V][Preferences.cpp:365] getUShort(): nvs_get_u16 fail: sleep_interval_long NOT_FOUND
12:23:23.076 -> [D][BresserWeatherSensorTTN.ino:577] setup(): Preferences: sleep_interval_long:   900 s
12:23:23.076 -> [D][BresserWeatherSensorTTN.ino:582] setup(): 
12:23:23.076 -> [D][BresserWeatherSensorTTN.ino:955] printDateTime(): 1970-01-01 00:00:00
12:23:23.076 -> [D][BresserWeatherSensorTTN.ino:590] setup(): RTC sync required
12:23:23.076 -> [D][BresserWeatherSensorTTN.ino:596] setup(): myEventlog.setup() - done
12:23:23.117 -> [D][BresserWeatherSensorTTN.ino:1160] getVoltage(): Voltage = 4071mV
12:23:23.117 -> [D][WeatherSensor.cpp:81] begin(): [SX1276] Initializing ... 
12:23:23.117 -> [D][WeatherSensor.cpp:94] begin(): success!
12:23:23.117 -> [D][WeatherSensor.cpp:129] begin(): [SX1276] Setup complete - awaiting incoming messages...
12:23:24.410 -> [V][WeatherSensor.cpp:217] getMessage(): [SX1276] Data: D4 C6 DB 38 05 35 05 18 FF FF FF 21 68 00 96 96 FF F0 CF AA 00 00 00 00 00 00 00 
12:23:24.410 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -75.5
12:23:24.410 -> [V][WeatherSensor.cpp:284] findSlot(): find_slot(): ID=38053505
12:23:24.410 -> [V][WeatherSensor.cpp:338] findSlot(): find_slot(): Storing into slot #0
12:23:36.394 -> [V][WeatherSensor.cpp:217] getMessage(): [SX1276] Data: D4 C0 13 38 05 35 05 18 FF FF FF 21 68 FF 6F 69 FF 01 13 AA 00 00 00 00 00 00 00 
12:23:36.394 -> [D][WeatherSensor.cpp:219] getMessage(): [SX1276] R [D4] RSSI: -74.0
12:23:36.394 -> [V][WeatherSensor.cpp:284] findSlot(): find_slot(): ID=38053505
12:23:36.394 -> [V][WeatherSensor.cpp:332] findSlot(): find_slot(): Updating slot #0
12:23:36.394 -> [D][BresserWeatherSensorTTN.ino:1088] setup(): Receiving Weather Sensor Data o.k.
12:23:36.427 -> [D][BresserWeatherSensorTTN.ino:600] setup(): mySensor.setup() - done
12:23:36.427 -> [D][BresserWeatherSensorTTN.ino:895] NetGetSessionState(): failed
12:23:36.427 -> [D][BresserWeatherSensorTTN.ino:604] setup(): myLoRaWAN.setup() - done
12:23:36.427 -> [D][BresserWeatherSensorTTN.ino:1160] getVoltage(): Voltage = 4626mV
12:23:36.427 -> [D][BresserWeatherSensorTTN.ino:1177] getVoltage(): Voltage = 335mV
12:23:36.459 -> [D][BresserWeatherSensorTTN.ino:1285] doUplink(): --- Uplink Data ---
12:23:36.459 -> [D][BresserWeatherSensorTTN.ino:1289] doUplink(): Air Temperature:     0.9 °C
12:23:36.459 -> [D][BresserWeatherSensorTTN.ino:1290] doUplink(): Humidity:            96   %
12:23:36.459 -> [D][BresserWeatherSensorTTN.ino:1291] doUplink(): Rain Gauge:         909.6 mm
12:23:36.459 -> [D][BresserWeatherSensorTTN.ino:1292] doUplink(): Wind Speed (avg.):    0.0 m/s
12:23:36.494 -> [D][BresserWeatherSensorTTN.ino:1293] doUplink(): Wind Speed (max.):    0.0 m/s
12:23:36.494 -> [D][BresserWeatherSensorTTN.ino:1294] doUplink(): Wind Direction:     216.0 °
12:23:36.494 -> [D][BresserWeatherSensorTTN.ino:1319] doUplink(): Supply  Voltage:   4626   mV
12:23:36.494 -> [D][BresserWeatherSensorTTN.ino:1322] doUplink(): Battery Voltage:    335   mV
12:23:36.494 -> [D][BresserWeatherSensorTTN.ino:1338] doUplink(): 
12:23:36.527 -> [D][BresserWeatherSensorTTN.ino:1427] doUplink(): Rain past 60min:      0.0 mm
12:23:36.527 -> [D][BresserWeatherSensorTTN.ino:1428] doUplink(): Rain curr. day:       0.0 mm
12:23:36.527 -> [D][BresserWeatherSensorTTN.ino:1429] doUplink(): Rain curr. week:      0.0 mm
12:23:36.527 -> [D][BresserWeatherSensorTTN.ino:1430] doUplink(): Rain curr. month:     0.0 mm
12:23:36.527 -> [D][BresserWeatherSensorTTN.ino:881] NetSaveSessionState(): 
12:23:36.560 -> [V][BresserWeatherSensorTTN.ino:837] printSessionState(): Tag:		1
12:23:36.560 -> [V][BresserWeatherSensorTTN.ino:838] printSessionState(): Size:		216
12:23:36.560 -> [V][BresserWeatherSensorTTN.ino:839] printSessionState(): Region:		1
12:23:36.560 -> [V][BresserWeatherSensorTTN.ino:840] printSessionState(): LinkDR:		5
12:23:36.560 -> [V][BresserWeatherSensorTTN.ino:841] printSessionState(): FCntUp:		0
12:23:36.560 -> [V][BresserWeatherSensorTTN.ino:842] printSessionState(): FCntDown:		0
12:23:36.594 -> [V][BresserWeatherSensorTTN.ino:843] printSessionState(): gpsTime:		0
12:23:36.594 -> [V][BresserWeatherSensorTTN.ino:844] printSessionState(): globalAvail:	-877103
12:23:36.594 -> [V][BresserWeatherSensorTTN.ino:845] printSessionState(): Rx2Frequency:	869525000
12:23:36.594 -> [V][BresserWeatherSensorTTN.ino:846] printSessionState(): PingFrequency:	869525000
12:23:36.594 -> [V][BresserWeatherSensorTTN.ino:847] printSessionState(): Country:		0
12:23:36.627 -> [V][BresserWeatherSensorTTN.ino:848] printSessionState(): LinkIntegrity:	0
12:23:36.627 -> [D][BresserWeatherSensorTTN.ino:868] NetSaveSessionInfo(): 
12:23:36.627 -> [V][BresserWeatherSensorTTN.ino:809] printSessionInfo(): Tag:		2
12:23:36.627 -> [V][BresserWeatherSensorTTN.ino:810] printSessionInfo(): Size:		52
12:23:36.627 -> [V][BresserWeatherSensorTTN.ino:811] printSessionInfo(): Rsv2:		0
12:23:36.660 -> [V][BresserWeatherSensorTTN.ino:812] printSessionInfo(): Rsv3:		0
12:23:36.660 -> [V][BresserWeatherSensorTTN.ino:813] printSessionInfo(): NetID:		0x00000000
12:23:36.660 -> [V][BresserWeatherSensorTTN.ino:814] printSessionInfo(): DevAddr:		0x00000000
12:23:36.660 -> [V][BresserWeatherSensorTTN.ino:821] printSessionInfo(): NwkSKey:		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
12:23:36.660 -> [V][BresserWeatherSensorTTN.ino:829] printSessionInfo(): AppSKey:		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
12:23:36.694 -> [D][BresserWeatherSensorTTN.ino:881] NetSaveSessionState(): 
12:23:36.694 -> [V][BresserWeatherSensorTTN.ino:837] printSessionState(): Tag:		1
12:23:36.694 -> [V][BresserWeatherSensorTTN.ino:838] printSessionState(): Size:		216
12:23:36.694 -> [V][BresserWeatherSensorTTN.ino:839] printSessionState(): Region:		1
12:23:36.694 -> [V][BresserWeatherSensorTTN.ino:840] printSessionState(): LinkDR:		5
12:23:36.727 -> [V][BresserWeatherSensorTTN.ino:841] printSessionState(): FCntUp:		0
12:23:36.727 -> [V][BresserWeatherSensorTTN.ino:842] printSessionState(): FCntDown:		0
12:23:36.727 -> [V][BresserWeatherSensorTTN.ino:843] printSessionState(): gpsTime:		0
12:23:36.727 -> [V][BresserWeatherSensorTTN.ino:844] printSessionState(): globalAvail:	-886088
12:23:36.727 -> [V][BresserWeatherSensorTTN.ino:845] printSessionState(): Rx2Frequency:	869525000
12:23:36.769 -> [V][BresserWeatherSensorTTN.ino:846] printSessionState(): PingFrequency:	869525000
12:23:36.769 -> [V][BresserWeatherSensorTTN.ino:847] printSessionState(): Country:		0
12:23:36.769 -> [V][BresserWeatherSensorTTN.ino:848] printSessionState(): LinkIntegrity:	0
12:23:47.101 -> 18282 ms:[I][BresserWeatherSensorTTN.ino:754] operator()(): TX @18282 ms: ch=0 rps=0x01 (SF7 BW125 CR 4/5 Crc IH=0)
12:23:47.101 -> 
12:24:58.725 -> 89900 ms:[I][BresserWeatherSensorTTN.ino:754] operator()(): TX @89900 ms: ch=1 rps=0x01 (SF7 BW125 CR 4/5 Crc IH=0)
12:24:58.725 -> 
12:26:09.875 -> 161067 ms:[I][BresserWeatherSensorTTN.ino:754] operator()(): TX @161067 ms: ch=2 rps=0x01 (SF7 BW125 CR 4/5 Crc IH=0)
12:26:09.875 -> 
12:27:19.620 -> 230742 ms:[I][BresserWeatherSensorTTN.ino:754] operator()(): TX @230742 ms: ch=1 rps=0x02 (SF8 BW125 CR 4/5 Crc IH=0)
12:27:19.620 -> 
12:29:23.093 -> [D][BresserWeatherSensorTTN.ino:1232] doUplink(): busy
12:29:26.719 -> 357849 ms:[I][BresserWeatherSensorTTN.ino:754] operator()(): TX @357849 ms: ch=2 rps=0x02 (SF8 BW125 CR 4/5 Crc IH=0)
12:29:26.719 ->  

if i leave it it just repeats the last line and there is no messages recieved on ttn

[matthias-bs]

Did you configure your secrets.h with the same values as in the network provider's console?
e.g.:

#define SECRETS

// deveui, little-endian
static const std::uint8_t deveui[] = { 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88 };

// appeui, little-endian
static const std::uint8_t appeui[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

// appkey: just a string of bytes, sometimes referred to as "big endian".
static const std::uint8_t appkey[] = { 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF, 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99 };

Besides, this looks good! Normally you have to wait a while (several minutes for a public network is quite normal) until the node has joined the network. After the first join, the connection details are saved and the next join will be much faster (~2...3 minutes).

And the supply voltage measurement seems to be valid, too.

[mczakk]

as far as i know, yes:


as far as the join goes, I have a gateway on my desk, which is connected, and anither lorawan node which connects to it successfully, so i'm guessing that there is something in my code which is not allowing the join. Whetther it is my ttn settings or the esp32 code is a mystery to me though!

[matthias-bs]

If you have a decent multimeter, it would be great to have a current measurement for this board in deep sleep mode. For this, we need the current drawn from the battery input, not the USB port. In fact, the USB may not be connected for this.

[mczakk]

aaaarg, i'm getting the mqtt out of ttn, but it doesn't show the wind!

[matthias-bs]

???
But it's in your decoded output according to the screenshot! If you mean an MQTT client: maybe the topic names are too long? You can change them in the decoder, of course.

[mczakk]

I've used the ttn mqtt integration to publish the mqtt message, and am subscribing with node-red.
the mqtt i recieve is truncated at 's1_dec_ok'
(see attached .txt)
ttn-nodered-output.txt
i tried taking out the bitmap and 'status' decoder, but this just threw the decode out!

[matthias-bs]

Maybe there is a way to increase a buffer size for MQTT messages in node-red? The JSON string from TTN is quite big!

[mczakk]

what are the topic names in the decoder, maybe i can just subscribe to the topics i need?

[matthias-bs]

Presumably, you only need "decoded_payload".

I'm always using https://mqtt-explorer.com/ for debugging.

[mczakk]

just trying mqtt decoder, can't get past the 'up' topic, and nodered mqtt in node wont accept v3/bresserttn@ttn/devices/bresseresp32/up
or v3/bresserttn@ttn/devices/bresseresp32/up/# as a topic :(
giving up for the day i think!

[mczakk]

D'oh, forgot to tell the Node-red mqtt in node to output parsed Jason!
All is good now, just have to get the data into aws now 😱🤣😂🤣

[matthias-bs]

Cool! Mission completed!

[matthias-bs]

Some interesting information/discussion regarding the TTGO LoRa32 board:
LilyGO/TTGO-LORA32#3

[mczakk]

Cool! Mission completed!

For you, maybe! For which I and my PhD project are eternally grateful! 😁🙏😁.

[matthias-bs]

What is the subject of your project?

[mczakk]

What is the subject of your project?

I'm developing a model to predict how much rainfall gets through forest canopies to become groundwater (and later floodwater) so I have off grid weather stations and rainfall gauges connecting via iot. My weather station was connected to a pi and a gateway in an enclosure in a forest, but the enclosure leaked, and the pi was pulling to much current. That's why I've moved to the esp32. It should be going live next week, thanks in no small part to you!

[matthias-bs]

⁹Good luck!

From what I've read, the TTGO LoRa32 is not optimal regarding standby (deep sleep) current consumption and LoRaWAN range.

You might consider https://github.com/matthias-bs/LoRaWAN_Node if any of this proves to be a concern.

[mczakk]

We have developed our own lora node for the rain gauges, and hopefully the ttgo will work.
It would be interesting if you could have a chat with myself and my network guy about the project. Can we connect via zoom? Do you have twitter to exchange contact details?

[mczakk]

Hi again, unfortunately it seems we have another issue :(
the payload formatter seems to output the temperature, wind and rain values as strings, is it possible to output them as floats?

[matthias-bs]

That is easy: just replace return f.toFixed(1); by return f; (other variables accordingly)

The reason for this was that I cannot set the number of decimals in my MQTT panel and therefore converted it in the decoder to a string with one decimal. The MQTT panel does not care it it's a string or a float.

[mczakk]

that seems to have changed them to 'int' - no decimal places, can we make it a float?

[matthias-bs]

From the oldest version I kept:

    var uint16fp1 = function(bytes) {
    if (bytes.length !== uint16.BYTES) {
        throw new Error('int must have exactly 2 bytes');
    }
    return bytesToInt(bytes) * 0.1;
    };
    uint16fp1.BYTES = 2;

It seems I snipped the previous example from rawfloat.

[mczakk]

hmm, at line 37?
has no effect!

[matthias-bs]

Please check this version: https://github.com/matthias-bs/BresserWeatherSensorTTN/blob/21a5de1b01874a554f31626768fac11cc6cd7853/decoder_basic.js

[mczakk]

copied that code into ttn. tested it and it gives :

  "bytes": {
    "air_temp_c": 4.8,
    "humidity": 87,
    "id": 939865349,
    "rain_day": 0,
    "rain_hr": 3.9796876386824805e-43,
    "rain_mm": 910,
    "rain_mon": 0,
    "rain_week": 0,
    "status": {
      "ble_ok": false,
"res0": false,
      "res1": false,
      "res2": false,
      "s1_batt_ok": false,
      "s1_dec_ok": false,
      "ws_batt_ok": true,
      "ws_dec_ok": true
    },
    "supply_v": 284,
    "wind_avg_meter_sec": 0,
    "wind_direction_deg": 186,
    "wind_gust_meter_sec": 0

so still no decimals for wind or rain, and a seemingly random value for rain_hr_mm!

[matthias-bs]

It's up to the application how to display floating point numbers. If the value is 0, it might well display it as 0 instead of 0.0.
air_temp_c is now shown as 4.8 (no quotation marks, i.e. it's shown as floating point), but it could also be shown as 4.799999999 if the internal representation would lead to this result.
Accordingly, rain_hr could be correct - a very small number, almost zero but not exactly zero.

https://stackoverflow.com/questions/19554972/json-standard-floating-point-numbers
https://stackoverflow.com/questions/35709595/why-would-you-use-a-string-in-json-to-represent-a-decimal-number

So apparently, you can not have both a machine readable floating point value and a nice, human-friendly display.

[mczakk]

Unfortunately i think there is a bit of an issue with the decoder! I decided to test the device by adding a little water to the rain counter, I made it tip four times. the 'rain_mm' value went from 910.0mm to 910,7999 (perfectly normal), the others ......
air_temp_c: 2.5
humidity: 93
id: 939865349
rain_day: -33619248
rain_hr: -107481312
rain_mm: 910.7999877929688
rain_mon: -33619248
rain_week: -33619248
status: object
supply_v: 284
wind_avg_meter_sec: 0
wind_direction_deg: 354
wind_gust_meter_sec: 0

not sure whats going on here!, maybe you can shed a little light?

[matthias-bs]

We have developed our own lora node for the rain gauges, and hopefully the ttgo will work. It would be interesting if you could have a chat with myself and my network guy about the project. Can we connect via zoom? Do you have twitter to exchange contact details?

I do not have Twitter, but chances are that you can find me on LinkedIn. Or is there a way to start a private conversation in GitHub? For sure I can join a zoom call if you set up one. Maybe on Friday?

[mczakk]

I don't think you can pm on github, I'll find you on linkedin. Friday might be difficult, hopefully I'll be installing the esp32 in the field!

[matthias-bs]

wire

Finally I found the purpose of this wire: Big ESP32 + SX127x topic part 2 has an excellent section about the different versions of the TTGO LoRa32 OLED boards. According to this, V2 lacks an on-board connection between the ESP and the LoRa radio chip!

In general, the version numbering/documentation of these boards is confusing and a schematic is not even available for most of them.