Big ESP32 + SX127x topic part 3

End Devices (Nodes)
41

I’ve tried researching the use of a solar panel with the TTGO ESP32 SX1276. I have discovered that there are solar panels such as the SC20050 - Monocrystalline Solar Cell 200mA 5.0V 94W9305 which I thought that would work, but I have a couple of problems.

The DC connector would have to be adapted to micro USB through an adapter such as this.

I don’t believe enough power would be supplied to power the board and charge the battery if I base my logic on an Arduino, so I think this is a no go, but I could be wrong. So here are my questions:

  1. Has anyone powered a TTGO using solar and therefore charged the battery?
  2. Is the solar panel I suggested suitable, or should I look elsewhere for something which is better value for money?
  3. What is the model of solar panel someone has used and how did you connect it to the TTGO?
  4. What are the necessary power requirements to power both the TTGO and charge the battery? I can seem to find plenty of power information about normal Arduino boards, but not much about the TTGO.
  5. Would I need a power booster circuit the solar panel?

I do have one condition and it’s the fact that it shouldn’t be wider than about 55mm so it can fit in this enclosure, however I’m open to other options.

I know I have a lot of questions, but I just can’t seem to find much information on using solar with the TTGO, so I’ve got a bit stuck.

UPDATE:

I have also found this solar panel sold by Adafruit, but am unsure if a power circuit is necessary for the TTGO which charges the battery via the micro USB connection.

42

In addition, does anyone know where I can source the spec sheet for the TTGO ESP32 SX1276? It seems to be a Chinese no name board, which means trying to find information on it is quite difficult. This would probably assist me with my solar enquiry.

1 Like
43

TTGO boards are made by LilyGO.
Unfortunately LilyGO is not very clear and not consistent in the naming of their boards (and different revisions of those boards). Similar for providing (or not) and (not) keeping up to date any documentation (e.g. pinout diagrams).

This board looks like a TTGO LoRa32 V1 but without the OLED display mounted. See the TOPIC START.
Information about how to configure these boards is provided in the TOPIC START.
You can find some LilyGO information on their GitHub page: LilyGO (LILYGO) · GitHub but I’m not sure if you will find anything specific for this board.

The board appears to be an imitation/copy (of a TTGO board) because there is written “Designed by Heltec” on the bottom. I have only seen boards with white PCB from Heltec, not black ones.
Also “Wemos® TTGO” is bogus. Neither Heltec nor LilyGO is related to Wemos.

44

The latest revision of the Heltec board has arrived (the one saying V2 next to the antenna connector, also see Aliexpress).

image

I have unscrewed the display to beep out the connections. And the Heltec pinout is indeed incorrect as suspected by @bluejedi.

The most relevant SX1276 connections are:

  • DIO0 is connected to pin 26 (with the blue LoRa_IRQ label)
  • DIO1 is connected to pin 35 (with the blue LoRa_DIO1 label)
  • DIO2 is connected to pin 34 (with the blue LoRa_DIO0 label – very confusing)

So the correct pinmap for LMIC is:

const lmic_pinmap lmic_pins = {
    .nss = 18,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 14,
    .dio = { 26, 35, 34 },
    .rxtx_rx_active = 0,
    .rssi_cal = 0,
    .spi_freq = 0
};

Note that this is different from what @rodri16 and @Verkehrsrot have described above (see pins DIO1 and DIO2).

I propose to call the new device V2 and rename the one that was previously called like this to V1.1. (Calling it V3 when it has V2 printed on the board would cause endless confusion.)

4 Likes
45

Heltec diff cart v1 / v2:
http://www.heltec.cn/wifi-lora-32-new-edition-comparison/?lang=en

1 Like
46

Hello, I got my Heltec from aliexpress

and installed the lmic library according to this blog. I’m still not sure which exact heltecversion I got.
I used the following pin mapping:

// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = {26, 33, 32},
};

After quite some time I got after the EV_JOINING
the message EV_JOIN_FAILED

Does this mean I do not have signal coverage, or is the pin mapping wrong? I installed the lmic from GitHub - matthijskooijman/arduino-lmic: ⚠ This library is deprecated, see the README for alternatives.
How could i further debug the problem?

Thanks for your help

⸮ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:808
load:0x40078000,len:6084
load:0x40080000,len:6696
entry 0x400802e4
RXMODE_RSSI
36654: engineUpdate, opmode=0x8
Packet queued
39383: EV_JOINING
45145: engineUpdate, opmode=0xc
286339: engineUpdate, opmode=0xc
286381: TXMODE, freq=868300000, len=23, SF=7, BW=125, CR=4/5, IH=0
599738: RXMODE_SINGLE, freq=868300000, SF=7, BW=125, CR=4/5, IH=0
665247: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
681656: engineUpdate, opmode=0xc
4460846: engineUpdate, opmode=0xc
4460881: TXMODE, freq=868500000, len=23, SF=7, BW=125, CR=4/5, IH=0
4774238: RXMODE_SINGLE, freq=868500000, SF=7, BW=125, CR=4/5, IH=0
4839746: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
4856154: engineUpdate, opmode=0xc
9079518: engineUpdate, opmode=0xc
9079552: TXMODE, freq=868100000, len=23, SF=8, BW=125, CR=4/5, IH=0
9396255: RXMODE_SINGLE, freq=868100000, SF=8, BW=125, CR=4/5, IH=0
9461635: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
9478042: engineUpdate, opmode=0xc
16679381: engineUpdate, opmode=0xc
16679416: TXMODE, freq=868300000, len=23, SF=8, BW=125, CR=4/5, IH=0
16996117: RXMODE_SINGLE, freq=868300000, SF=8, BW=125, CR=4/5, IH=0
17061497: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
17077905: engineUpdate, opmode=0xc
25045526: engineUpdate, opmode=0xc
25045560: TXMODE, freq=868500000, len=23, SF=9, BW=125, CR=4/5, IH=0
25368245: RXMODE_SINGLE, freq=868500000, SF=9, BW=125, CR=4/5, IH=0
25433433: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
25449845: engineUpdate, opmode=0xc
39321730: engineUpdate, opmode=0xc
39321764: TXMODE, freq=868100000, len=23, SF=9, BW=125, CR=4/5, IH=0
39644451: RXMODE_SINGLE, freq=868100000, SF=9, BW=125, CR=4/5, IH=0
39709639: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
39726047: engineUpdate, opmode=0xc
53267835: engineUpdate, opmode=0xc
53267869: TXMODE, freq=868300000, len=23, SF=10, BW=125, CR=4/5, IH=0
53601242: RXMODE_SINGLE, freq=868300000, SF=10, BW=125, CR=4/5, IH=0
53666046: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
53682454: engineUpdate, opmode=0xc
80288310: engineUpdate, opmode=0xc
80288345: TXMODE, freq=868500000, len=23, SF=10, BW=125, CR=4/5, IH=0
80621718: RXMODE_SINGLE, freq=868500000, SF=10, BW=125, CR=4/5, IH=0
80686522: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
80702930: engineUpdate, opmode=0xc
107275635: engineUpdate, opmode=0xc
107275670: TXMODE, freq=868100000, len=23, SF=11, BW=125, CR=4/5, IH=0
107638098: RXMODE_SINGLE, freq=868100000, SF=11, BW=125, CR=4/5, IH=0
107702135: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
107718543: engineUpdate, opmode=0xc
159483077: engineUpdate, opmode=0xc
159483112: TXMODE, freq=868300000, len=23, SF=11, BW=125, CR=4/5, IH=0
159845540: RXMODE_SINGLE, freq=868300000, SF=11, BW=125, CR=4/5, IH=0
159909577: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
159925984: engineUpdate, opmode=0xc
219817315: engineUpdate, opmode=0xc
219817350: TXMODE, freq=868500000, len=23, SF=12, BW=125, CR=4/5, IH=0
220222528: RXMODE_SINGLE, freq=868500000, SF=12, BW=125, CR=4/5, IH=0
220285028: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
220301436: engineUpdate, opmode=0xc
325144457: engineUpdate, opmode=0xc
325144491: TXMODE, freq=868100000, len=23, SF=12, BW=125, CR=4/5, IH=0
325549670: RXMODE_SINGLE, freq=868100000, SF=12, BW=125, CR=4/5, IH=0
325612170: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
325628579: EV_JOIN_FAILED
325636016: engineUpdate, opmode=0xc
420703267: engineUpdate, opmode=0xc
420703303: TXMODE, freq=868300000, len=23, SF=12, BW=125, CR=4/5, IH=0
421108482: RXMODE_SINGLE, freq=868300000, SF=12, BW=125, CR=4/5, IH=0
421170982: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
421187395: engineUpdate, opmode=0xc
520868426: engineUpdate, opmode=0xc
520868460: TXMODE, freq=868500000, len=23, SF=12, BW=125, CR=4/5, IH=0
521273639: RXMODE_SINGLE, freq=868500000, SF=12, BW=125, CR=4/5, IH=0
521336139: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
521352548: EV_JOIN_FAILED
521359991: engineUpdate, opmode=0xc
622308730: engineUpdate, opmode=0xc
622308767: TXMODE, freq=868100000, len=23, SF=12, BW=125, CR=4/5, IH=0
622713946: RXMODE_SINGLE, freq=868100000, SF=12, BW=125, CR=4/5, IH=0
622776446: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
622792854: engineUpdate, opmode=0xc
729429457: engineUpdate, opmode=0xc
729429492: TXMODE, freq=868300000, len=23, SF=12, BW=125, CR=4/5, IH=0
729834671: RXMODE_SINGLE, freq=868300000, SF=12, BW=125, CR=4/5, IH=0
729897171: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
729913580: EV_JOIN_FAILED
729921024: engineUpdate, opmode=0xc
837755367: engineUpdate, opmode=0xc
837755404: TXMODE, freq=868500000, len=23, SF=12, BW=125, CR=4/5, IH=0
838160582: RXMODE_SINGLE, freq=868500000, SF=12, BW=125, CR=4/5, IH=0
838223082: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
838239490: engineUpdate, opmode=0xc
935268860: engineUpdate, opmode=0xc
935268895: TXMODE, freq=868100000, len=23, SF=12, BW=125, CR=4/5, IH=0
935674074: RXMODE_SINGLE, freq=868100000, SF=12, BW=125, CR=4/5, IH=0
935736574: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
935752983: EV_JOIN_FAILED
935760423: engineUpdate, opmode=0xc
1030019765: engineUpdate, opmode=0xc
1030019801: TXMODE, freq=868300000, len=23, SF=12, BW=125, CR=4/5, IH=0
1030424981: RXMODE_SINGLE, freq=868300000, SF=12, BW=125, CR=4/5, IH=0
1030487481: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
1030503890: engineUpdate, opmode=0xc
1131636784: engineUpdate, opmode=0xc
1131636819: TXMODE, freq=868500000, len=23, SF=12, BW=125, CR=4/5, IH=0
1132041998: RXMODE_SINGLE, freq=868500000, SF=12, BW=125, CR=4/5, IH=0
1132104498: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
1132120907: EV_JOIN_FAILED
1132128559: engineUpdate, opmode=0xc
1239266735: engineUpdate, opmode=0xc
1239266772: TXMODE, freq=868100000, len=23, SF=12, BW=125, CR=4/5, IH=0
1239671951: RXMODE_SINGLE, freq=868100000, SF=12, BW=125, CR=4/5, IH=0
1239734451: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
1239750863: engineUpdate, opmode=0xc
1344446347: engineUpdate, opmode=0xc
1344446381: TXMODE, freq=868300000, len=23, SF=12, BW=125, CR=4/5, IH=0
1344851561: RXMODE_SINGLE, freq=868300000, SF=12, BW=125, CR=4/5, IH=0
1344914061: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
1344930470: EV_JOIN_FAILED
1344938122: engineUpdate, opmode=0xc
1446683767: engineUpdate, opmode=0xc
1446683804: TXMODE, freq=868500000, len=23, SF=12, BW=125, CR=4/5, IH=0
1447088984: RXMODE_SINGLE, freq=868500000, SF=12, BW=125, CR=4/5, IH=0
1447151484: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
1447167892: engineUpdate, opmode=0xc
1545000557: engineUpdate, opmode=0xc
1545000591: TXMODE, freq=868100000, len=23, SF=12, BW=125, CR=4/5, IH=0
1545405771: RXMODE_SINGLE, freq=868100000, SF=12, BW=125, CR=4/5, IH=0
1545468271: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
1545484680: EV_JOIN_FAILED
1545492332: engineUpdate, opmode=0xc

Here the arduino code:

#include <lmic.h>
#include <hal/hal.h>
#include <SPI.h>
#include <U8x8lib.h>

#define BUILTIN_LED 25

// the OLED used
U8X8_SSD1306_128X64_NONAME_SW_I2C u8x8(/* clock=*/ 15, /* data=*/ 4, /* reset=*/ 16);

// This EUI must be in little-endian format, so least-significant-byte
// first. When copying an EUI from ttnctl output, this means to reverse
// the bytes. For TTN issued EUIs the last bytes should be 0xD5, 0xB3,
// 0x70.
// Set your AppEUI and AppKey
//appEui = "70 B3 D5 7E D0 01 3B 72";

static const u1_t PROGMEM APPEUI[8] = { 0x72, 0x3B, 0x01, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getArtEui (u1_t* buf) {
  memcpy_P(buf, APPEUI, 8);
}
 //01 23 45 67 89 AA BB CC
// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8] = { 0xCC, 0xBB, 0xAA, 0x89, 0x67, 0x45, 0x23, 0x01 };
void os_getDevEui (u1_t* buf) {
  memcpy_P(buf, DEVEUI, 8);
}

// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
// The key shown here is the semtech default key.
// appKey = "D9 EB BB 95 63 FC 98 E2 87 5A 67 04 20 09 53 3A";
static const u1_t PROGMEM APPKEY[16] = { 0xD9, 0xEB, 0xBB, 0x95, 0x63, 0xFC, 0x98, 0xE2, 0x87, 0x5A, 0x67, 0x04, 0x20, 0x09, 0x53, 0x3A };
void os_getDevKey (u1_t* buf) {
  memcpy_P(buf, APPKEY, 16);
}

static uint8_t mydata[] = "Hi";
static osjob_t sendjob;

// Schedule TX every this many seconds (might become longer due to duty
// cycle limitations).
const unsigned TX_INTERVAL = 30;

// Pin mapping
const lmic_pinmap lmic_pins = {
  .nss = 18,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = 14,
  .dio = {26, 33, 32},
};


void onEvent (ev_t ev) {
  Serial.print(os_getTime());
  u8x8.setCursor(0, 5);
  u8x8.printf("TIME %lu", os_getTime());
  Serial.print(": ");
  u8x8.clearLine(7);
  switch (ev) {
case EV_SCAN_TIMEOUT:
  Serial.println(F("EV_SCAN_TIMEOUT"));
  u8x8.drawString(0, 7, "EV_SCAN_TIMEOUT");
  break;
case EV_BEACON_FOUND:
  Serial.println(F("EV_BEACON_FOUND"));
  u8x8.drawString(0, 7, "EV_BEACON_FOUND");
  break;
case EV_BEACON_MISSED:
  Serial.println(F("EV_BEACON_MISSED"));
  u8x8.drawString(0, 7, "EV_BEACON_MISSED");
  break;
case EV_BEACON_TRACKED:
  Serial.println(F("EV_BEACON_TRACKED"));
  u8x8.drawString(0, 7, "EV_BEACON_TRACKED");
  break;
case EV_JOINING:
  Serial.println(F("EV_JOINING"));
  u8x8.drawString(0, 7, "EV_JOINING");
  break;
case EV_JOINED:
  Serial.println(F("EV_JOINED"));
  u8x8.drawString(0, 7, "EV_JOINED ");

  // Disable link check validation (automatically enabled
  // during join, but not supported by TTN at this time).
  LMIC_setLinkCheckMode(0);
  break;
case EV_RFU1:
  Serial.println(F("EV_RFU1"));
  u8x8.drawString(0, 7, "EV_RFUI");
  break;
case EV_JOIN_FAILED:
  Serial.println(F("EV_JOIN_FAILED"));
  u8x8.drawString(0, 7, "EV_JOIN_FAILED");
  break;
case EV_REJOIN_FAILED:
  Serial.println(F("EV_REJOIN_FAILED"));
  u8x8.drawString(0, 7, "EV_REJOIN_FAILED");
  //break;
  break;
case EV_TXCOMPLETE:
  Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
  u8x8.drawString(0, 7, "EV_TXCOMPLETE");
  digitalWrite(BUILTIN_LED, LOW);
  if (LMIC.txrxFlags & TXRX_ACK) {
    Serial.println(F("Received ack"));
    u8x8.drawString(0, 7, "Received ACK");
  }
  if (LMIC.dataLen) {
    Serial.println(F("Received "));
    u8x8.drawString(0, 6, "RX ");
    Serial.println(LMIC.dataLen);
    u8x8.setCursor(4, 6);
    u8x8.printf("%i bytes", LMIC.dataLen);
    Serial.println(F(" bytes of payload"));
    u8x8.setCursor(0, 7);
    u8x8.printf("RSSI %d SNR %.1d", LMIC.rssi, LMIC.snr);
  }
  // Schedule next transmission
  os_setTimedCallback(&sendjob, os_getTime() + sec2osticks(TX_INTERVAL), do_send);
  break;
case EV_LOST_TSYNC:
  Serial.println(F("EV_LOST_TSYNC"));
  u8x8.drawString(0, 7, "EV_LOST_TSYNC");
  break;
case EV_RESET:
  Serial.println(F("EV_RESET"));
  u8x8.drawString(0, 7, "EV_RESET");
  break;
case EV_RXCOMPLETE:
  // data received in ping slot
  Serial.println(F("EV_RXCOMPLETE"));
  u8x8.drawString(0, 7, "EV_RXCOMPLETE");
  break;
case EV_LINK_DEAD:
  Serial.println(F("EV_LINK_DEAD"));
  u8x8.drawString(0, 7, "EV_LINK_DEAD");
  break;
case EV_LINK_ALIVE:
  Serial.println(F("EV_LINK_ALIVE"));
  u8x8.drawString(0, 7, "EV_LINK_ALIVE");
  break;
default:
  Serial.println(F("Unknown event"));
  u8x8.setCursor(0, 7);
  u8x8.printf("UNKNOWN EVENT %d", ev);
  break;
  }
}

void do_send(osjob_t* j) {
  // Check if there is not a current TX/RX job running
  if (LMIC.opmode & OP_TXRXPEND) {
Serial.println(F("OP_TXRXPEND, not sending"));
u8x8.drawString(0, 7, "OP_TXRXPEND, not sent");
  } else {
// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, mydata, sizeof(mydata) - 1, 0);
Serial.println(F("Packet queued"));
u8x8.drawString(0, 7, "PACKET QUEUED");
digitalWrite(BUILTIN_LED, HIGH);
  }
  // Next TX is scheduled after TX_COMPLETE event.
}


void setup() {

  Serial.begin(115200);

  u8x8.begin();
  u8x8.setFont(u8x8_font_chroma48medium8_r);
  u8x8.drawString(0, 1, "LoRaWAN LMiC");

  SPI.begin(5, 19, 27);

  // LMIC init
  os_init();
  // Reset the MAC state. Session and pending data transfers will be discarded.
  LMIC_reset();
  // This tells LMIC to make the receive windows bigger, in case your clock is 1% faster or slower.
  LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

  // Start job (sending automatically starts OTAA too)
  do_send(&sendjob);

  pinMode(BUILTIN_LED, OUTPUT);
  digitalWrite(BUILTIN_LED, LOW);
}

void loop() {
  os_runloop_once();
}
47

Slightly off-topic…

In PlatformIO.org for ESP32 you can choose between the Arduino and the ESP-IDF framework.

What are the pros and cons for taking the one or the other?

1 Like
48

Arduino versus ESP-IDF

Arduino

Arduino core for ESP32

Pros

  • Cross-platform e.g. AVR, SAM(D/L), ESP8266, ESP32.
    Some STM32 (but STM32 family is not well supported and ST Microelectronics’ support for the Arduino platform is very limited).
  • Very large community.
  • Broad support.
  • Many existing libraries available.

Cons

  • Quirks/limitations of the Arduino platform. Initially designed to create simple, low cost tools for creating digital projects by non-engineers. Was not designed as a professional development platform.
  • While many libraries are available, not all are well designed (and have their quirks) and not every library supports each architecture.
  • Originally developed for 8-bit AVR, later ported to other architectures. Not designed to support all features of different architectures.
  • Not the most efficient (speed and size), lacks architecture specific optimizations.

ESP-IDF

Espressif IoT Development Framework

Pros

  • ESP-IDF is the official development framework for the ESP32 chip.
  • Full native control of all ESP32 features.
  • Better suited for professional development, allows optimal use of all ESP32 features.
  • No Arduino legacy / (design) limitations.
  • FreeRTOS OS that comes with ESP-IDF is capable of multi-core preemptive multi-threading (allowing for a more intuitive way of writing software).
  • Better debugging support.
  • Well documented.

Cons

  • ESP32-only, not cross-platform.
  • A (much) smaller (though more professional) community.
  • Another learning curve (if already familiar with Arduino).
    .

(No personal experience with ESP-IDF yet.)

Also see Neil Kolban’s (author of the free ESP32/ESP8266 books) perspective on Arduino versus ESP-IDF.

3 Likes
49

Nice summary, thank you!

1 Like
50

Remind me to buy you a beer sometime… you’re a genius for figuring this out, thanks!

51

Maybe worthy to note that both approaches can be combined, if you use Platform.io as IDE together with the arduino-esp32 framework. Then you can mix using arduino libraries while also have access to all native features of the ESP32 API.

52

It is possible to call ESP-IDF functions from Arduino but that is not something provided by or limited to PlatformIO (see below).

53

The Arduino framework also have some ESP32 specific bindings like RTOS, etc…

54

Yes, that functionality is provided by Arduino core for ESP32, not by PlatformIO.

Update:

To clear things up:

There are two possible scenarios for combining Arduino core for ESP32 with ESP-IDF:

  1. Call ESP-IDF SDK functions from Arduino core for ESP32 code.
    This requires the proper SDK header file(s) to be included in the Arduino sketch.

  2. Use Arduino core for ESP32 (code) as a component in ESP-IDF.
    See: use arduino-esp32 as a component of ESP-IDF

This is functionality of the Arduino core for ESP32 and the ESP-IDF. It is independent from the IDE used for development e.g. PlatformIO.

The ‘Arduino platform’ is supported by both the ‘Arduino IDE’ and PlatformIO. The ‘ESP-IDF platform’ is supported by PlatformIO but not by the ‘Arduino IDE’. However, when using the ‘Arduino IDE’ it is possible to call ESP-IDF SDK functions from Arduino code.
Arduino core for ESP32 is based on the ESP-IDF SDK. The SDK is included with Arduino core for ESP32.

55

That’s my understanding as well

56

Hi.
I have a TTGO ESP32 LORA OLED V2 as node with the frequency 868 “https://github.com/matthijskooijman/arduino-lmic” with the example of “ttn-abp.ino”,
I have made the jumpers with cable between DIO2 - GPIO32 (although I have read in some sites is not necessary) AND DIO1 -GPIO33, I modified the att-abp .ino file in the LMIC library with:

"const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {26, 33, LMIC_UNUSED_PIN} "

and in the IDE console I see this.

"Starting
8687: EV_TXSTART
Packet queued
275104: EV_TXCOMPLETE (includes waiting for RX windows)
4025124: EV_TXSTART
Packet queued
4257177: EV_TXCOMPLETE (includes waiting for RX windows)
8007196: EV_TXSTART
Packet queued "

I have another TTGO V2 with “https://github.com/things4u/ESP-1ch-Gateway-v5.0” version 5.3.3 “ESP-sc-gway.ino” as gateway to frequency 868.
READY SSID = appears on the screen (my home wifi) and appears on the TTN console as connected.

"Local UDP port = 1700
Connection successful
Gateway ID: XXXXXXXXXXXXXX, Listening at SF7 on 868.10 Mhz.
setupOta :: Started
Ready
IP address: 192.168.100.47
Time: Monday 04:33:56
Gateway configuration saved
WWW Server started on port 80
OLED_ADDR = 0x3C
--------------------------------------
A readUdp :: NTP msg rcvd "

I understand that my gateway is well configured?
The node because I do not receive resouesta?

58

are you sure that node and gateway work on one single channel ?

59

Sorry, I did not answer your question, I assumed that being a single-channel gateway, I would only have one channel.
I have read about 3 or 4 times, and I will read it again BIG ESP.
So what am I doing wrong, how do I solve it so that the node is understood with the “gateway”?

Compiled from the subject: Frec:868

TTGO LORA ESP32 LORA OLED V2

(ESP-sc-gway.ino v.5.3.3)

ESP-sc-gway.h:

// We support a few pin-out configurations out-of-the-box: HALLARD, COMPRESULT and TTGO ESP32.
// If you use one of these two, just set the parameter to the right value.
// If your pin definitions are different, update the loraModem.h file to reflect these settings.
// 1: HALLARD
// 2: COMRESULT pin out
// 3: ESP32 Wemos pin out
// 4: ESP32 TTGO pinning (should work for 433 and OLED too).
// 5: ESP32 TTGO EU433 MHz with OLED
// 6: Other, define your own in loraModem.h
#define _PIN_OUT 4 // TTGO ESP32 LORA OLED V2

oLED.h:

"#elif _PIN_OUT==4||||||||// TTGO (onboard version used, also for DIY)|
#define OLED_SCL 22||||||||// GPIO15 // TTGO ESP32 LORA OLED V.2
#define OLED_SDA 21||||||||// GPIO4 // TTGO ESP32 LORA OLED V.2
#define OLED_RST 16||||||||// Reset pin (Some OLED displays do not have it)

I have left only the DIO1 bridge with GPIO 33.

60

Your node will send messages (hop) over different channels, but your single channel gateway can only listen on one single channel so it will miss many of the node’s messages.

If both node and single channel gateway are properly working then you should at least see part of the node’s messages (in TTN console/gateways/<gateway>/traffic and console/applications/<application>/data) but it may take some time before you see them. That time strongly depends on the time between subsequent messages (and you should keep the messages short to prevent possible air-time budget related delays).

It is possible to configure the node so it will use only one single channel. Information for how to do this is already available on the forum but I don’t have a pointer at hand.

For single-channel gateways and related issues (nodes included) the most appropriate thread is:
Single Channel Gateway part 3

1 Like
61

Im sorry… my mistake :pleading_face:

1 Like