Big ESP32 / SX127x topic part 1

If the test was carried out under exactly the same RF conditions, so that we can exclude i.e. an EMI effect, the root cause for different ping results must stay on the digital side. That’s, on the one hand, the SPI interface between SX127x chip/mode, and on the other hand the LoRa software stack.

If an LMiC stack was used for the ping test: Sure, that the TX_COMPLETE event was properly handled by the stack, i.e. no events were missed? Data reception with LMiC stack requires properly processing of the events generated by SX127x DIO lines, and properly timing that ensures that the LoRaWAN RX-slot is not missed.

The statemen over 30 mating cycles for a u.fl connector is incorrect, also in Wikipedia. The datasheet specifies only the contact resistance when 30 mating cycles have been performed. There is no limit on the number of mating cycles in the datasheet, for so far as I can see. Using extreme care, not twisting the cable are obvious precautions to be taken with this very small connector. But for regular connecting/unconnecting actions I agree that e.g. a SMA connector would be far preferable.

On the subject itself, it might be worth the effort to analyse the RF behaviour of the Heltec board with a VNA. As you may recall, on the famous LoRa thingie handed out on the E&A fair in Utrecht last year, they managed to screw up the matching circuit to the ProAnt on-board antenna severely. Perhaps an even trivial case of not entirely understanding the RF part could have happend on this board.

–Ajj

Sorry I made mistake, PIN20 looks like problem in transmitting but new measurement show that its ok

The connectors on my 1.13 mm coax cables are I-PEX part number 20278-112R-13.
Hirose lists its part number U.FL-LP-068 as being compatible.
On the Hirose product site it says “Mating/Unmating Cycles: 30”. In their U.FL catalog they call it ‘Durability’.
So I guess this is probably best interpreted as ‘confirmed specs for (max) 30 mating cycles’.

Is there really anyone out there who can connect a U.FL connector more than 30 times without breaking it? :face_with_raised_eyebrow:

I think I can. :grin:

I learned today that there exist tools for manual insertion/removal of I-PEX MHF connectors.

I-PEX Push Pull JIG Manual Tool

This brochure Accessories_for_MHF_series.pdf (73.9 KB) and this drawing 90224C0(MHF).pdf (234.3 KB) show a version (90224-001) for both insertion and removal.
But I can’t find a source where the 90224-001 is available.

This one (90192-001) is suitable for removal only.

2 Likes

I Thought you might be interested with a test I just did using one of those TTGO type devices with the stock antenna provided .
I Connected to Kotahi Net (in Auckland NZ)
I am 42Km’s away from their gateway on the sky tower .
They reliably receive all my transmissions but I couldn’t get an ACK back to any confirmed messages I sent…
I Connected an 8dbi yagi to the TTGO & Started getting Acknowledges Back .
The antenna is like one of these 8dbi antenna

1 Like

I’m having a bit of a weird issue with IRQ
I added a line to print when arduino_lmic reads interrupts.

359586: engineUpdate, opmode=0x808
359767: Uplink data pending
359924: Airtime available at 359767 (channel duty limit)
360239: Ready for uplink
360437: TXMODE, freq=902300000, len=48, SF=7, BW=125, CR=4/5, IH=0
FIRING IRQ: 0
366547: irq: dio: 0x0 flags: 0x8
366555: Scheduled job 0x3ffcce90, cb 0x400d42d8 ASAP
366561: Running job 0x3ffcce90, cb 0x400d42d8, deadline 0
366735: Scheduled job 0x3ffcce90, cb 0x400d3ff4 at 428320
428320: Running job 0x3ffcce90, cb 0x400d3ff4, deadline 428320
428447: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
FIRING IRQ: 0
429936: irq: dio: 0x0 flags: 0x40
429951: Scheduled job 0x3ffcce90, cb 0x400d57e8 ASAP
429955: Running job 0x3ffcce90, cb 0x400d57e8, deadline 0
430150: Received downlink, window=RX1, port=0, ack=1
LORA EVENT EV_TXCOMPLETE

Now this works perfectly but every now and then that IRQ gets fired but somehow lmic code misses it.
I added ESP32 IRQ handling with callback and saw this happening. esp32 interrupt detects interrupt, but lmic doesn’t.
So it never fires EV_TXCOMPLETE and gets stuck.
This can happen anywhere from packet 2 to packet 70. its pretty random!
Anybody else seen anything like this?ve tested this on 2 heltec modules and 1 TTGO module.
I’ve already opened issue:

From ESP32-Arduino i understand attach/detach interrupts used by arduino-lmic hal.cpp is not actually implemented in esp32.

2 Likes

Ok! I figured this out.
I used ESP32 IDF methods and threads.
So when mixing arduino and esp-idf code you have to make sure sending data is performed from the same thread/core as LMIC. I think there can be race conditions.

Hi I’m trying to get my first Lora node connected to my RAK gate way, and I need some help.
I’m using the LmiC code and everything seems to work however I don’t have the Device EUI,
how can I get this from the Heltec Board? The board got an LCD so I can printe it to that.
Also is there a way to confirm that I’m transmitting on 915 AU.
I can see on the TCP dump on my gateway that I receive some packets but not able to see anything on the ThingsNetwork.

Thank you for your help

I’m also coding with mixed arduino (for LMiC) and ESP32 IDF, using platformIO on Visual Studio Code.
Had some trouble with race conditions, too. Not sure if i really cleared them.
Could you share your code here or on github?

I’m looking for a solution to switch off core 1. In ESP-IDF this is done with a build option, but doen’t work on arduino framework, probably because it uses precompiled ESP32 libs. Any ideas how to switch off core 1 in platformIO?

Great thread. Thanks to everyone who shared information. It’s gotten me almost the whole way.

I’m running the Heltec at 915 MHz, and have adjusted my arduino-lmic library config.h to reflect this. I’m running @nicbkw example code, but can’t get past “EV_JOIN_FAILED”

I see OTAA join requests up at TTN, and my APPEUI, DEVEUI are in LSB format, and APPKEY is in MSB format. All looks good, but I just still get stuck at the ev join failed message.

Any ideas on what I might be missing?

Ok, I plugged in my second module and it works fine. I’m guessing I have a bad board.

Guys, this is a great thread, but I need you help.
I have a ESP32 dev module with a Adafruit RFM95W breakout and I can’t get it to work, neither OTAA or ABP.
I used the examples from the arduino-lora repo… with OTAA, I always get the EV_JOIN_FAILED and with ABP it seems that the message goes out but I don’t see any activity on TTN.

Here is my prototype:

image

The big question is… EV_TXCOMPLETE (using ABP) means that my wiring between the ESP32 and the RFM95w module is working? Is this maybe a configuration error?

Thanks in advance!

PD: Here is my gateway:

image

You can’t; the board does not provide one.

You could generate a semi-random one yourself (possibly based on the onboard WiFi’s MAC address), see DevEUI for non-hardware assigned values for rules to take into account. Or simply have TTN Console generate one for you by clicking the :twisted_rightwards_arrows: icon at the start of the input field; see screenshots and a warning at the same link.

2 Likes

I have one Heltec board working properly, and one not working with LMiC, too. That one not working has issues when data is to be transmitted.

Found out that one working has a CPU ESP32 Hw Revision 1, while that one not working has a CPU ESP32 Hw Revision 0.

Can you check this with your boards, please? Perhaps this is the reason, eventually timings or something else on the SPI interface between ESP32 and SX1276 goes wrong.

You can see the CPU revision when flashing with esptool, it shows CPU type and revision.

There are some bugs reported for CPU ESP32, esp. for revision 0.

1 Like

3 posts were merged into an existing topic: DevEUI for non-hardware assigned values

Greetings, @Verkehrsrot -

it looks like I have two Rev 1 boards.

.\Documents\Arduino\hardware\heltec\esp32\tools>esptool -p com9 -b 115200 flash_id
esptool.py v2.1
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Manufacturer: ef
Device: 4016
Detected flash size: 4MB
Hard resetting...

.\Documents\Arduino\hardware\heltec\esp32\tools>esptool -p com9 -b 115200 flash_id
esptool.py v2.1
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Manufacturer: ef
Device: 4016
Detected flash size: 4MB
Hard resetting...

.\Documents\Arduino\hardware\heltec\esp32\tools>

I’ve noticed that I don’t have consistent performance on my second board either, to my local RAK831 gateway. So, I’m not out of the woods yet.

I need some help trying to connect my Helltec board to my RAK 831 Gatway.

I’m using the Lmic source in the Arduino environment.

Here is my code
Hi I was wondering if you know of a working Heltec configuration on the AUS915 spectrum.
I set up a gateway in Mount Kuring Gai and it is connected to the The Thingsnetwork.

But I’m having a bit of a hard time to get the node I have configured.

I have a Helltec board and using the Arduino Core Lmic.
However I fail to register EV_JOIN_FAILD.
Find the code and the serial window output from the Arduino IDE.

May thanks for your help.

Here is the code I’m using:
// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8] = { 0x9B, 0xF6, 0x59, 0x64, 0x71, 0xFB, 0x02, 0x00 };
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.
static const u1_t PROGMEM APPKEY[16] = { 0xA9, 0x43, 0xB5, 0x11, 0xEB, 0xFB, 0xA5, 0xC1, 0xB7, 0xA1, 0x42, 0xBC, 0x7E, 0xB4, 0x7C, 0x79 };
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(": ");
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();

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

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

void loop() {
os_runloop_once();
}

And this is the serial output from the Arduino IDE
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:956
load:0x40078000,len:0
load:0x40078000,len:13076
entry 0x40078a58
RXMODE_RSSI
39430: engineUpdate, opmode=0x8
Packet queued
42206: EV_JOINING
46471: engineUpdate, opmode=0xc
46504: TXMODE, freq=902300000, len=23, SF=7, BW=125, CR=4/5, IH=0
362894: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
426139: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
428712: engineUpdate, opmode=0xc
439700: engineUpdate, opmode=0xc
439725: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
754027: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
817271: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
819844: engineUpdate, opmode=0xc
907207: engineUpdate, opmode=0xc
907232: TXMODE, freq=911900000, len=23, SF=8, BW=125, CR=4/5, IH=0
1226861: RXMODE_SINGLE, freq=923300000, SF=8, BW=500, CR=4/5, IH=0
1290082: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1292654: engineUpdate, opmode=0xc
1332794: engineUpdate, opmode=0xc
1332819: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
1647121: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
1710366: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
1712938: engineUpdate, opmode=0xc
2169543: engineUpdate, opmode=0xc
2169568: TXMODE, freq=912500000, len=23, SF=9, BW=125, CR=4/5, IH=0
2495037: RXMODE_SINGLE, freq=925100000, SF=9, BW=500, CR=4/5, IH=0
2558209: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
2560782: engineUpdate, opmode=0xc
2571713: engineUpdate, opmode=0xc
2571738: TXMODE, freq=907800000, len=23, SF=8, BW=500, CR=4/5, IH=0
2886040: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0
2949284: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
2951859: engineUpdate, opmode=0xc
3188834: engineUpdate, opmode=0xc
3188859: TXMODE, freq=906700000, len=23, SF=10, BW=125, CR=4/5, IH=0
3524727: RXMODE_SINGLE, freq=926900000, SF=10, BW=500, CR=4/5, IH=0
3587804: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
3590376: engineUpdate, opmode=0xc
3613090: engineUpdate, opmode=0xc
3613115: TXMODE, freq=912600000, len=23, SF=8, BW=500, CR=4/5, IH=0
3927417: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0
3990661: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
3993234: EV_JOIN_FAILED
3998768: engineUpdate, opmode=0xc
4250120: engineUpdate, opmode=0xc
4250148: TXMODE, freq=911900000, len=23, SF=10, BW=125, CR=4/5, IH=0
4586017: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
4649093: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
4651665: engineUpdate, opmode=0xc
4666741: engineUpdate, opmode=0xc
4666766: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
4981070: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
5044313: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
5046886: EV_JOIN_FAILED
5052402: engineUpdate, opmode=0xc
5164684: engineUpdate, opmode=0xc
5164711: TXMODE, freq=908700000, len=23, SF=10, BW=125, CR=4/5, IH=0
5500581: RXMODE_SINGLE, freq=923300000, SF=10, BW=500, CR=4/5, IH=0
5563657: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
5566229: engineUpdate, opmode=0xc
5598334: engineUpdate, opmode=0xc
5598359: TXMODE, freq=903000000, len=23, SF=8, BW=500, CR=4/5, IH=0
5912661: RXMODE_SINGLE, freq=923300000, SF=7, BW=500, CR=4/5, IH=0
5975906: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
5978478: EV_JOIN_FAILED
5983995: engineUpdate, opmode=0xc
6820817: engineUpdate, opmode=0xc
6820845: TXMODE, freq=906100000, len=23, SF=10, BW=125, CR=4/5, IH=0
7156714: RXMODE_SINGLE, freq=925100000, SF=10, BW=500, CR=4/5, IH=0
7219790: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
7222364: engineUpdate, opmode=0xc
7277965: engineUpdate, opmode=0xc
7277990: TXMODE, freq=907800000, len=23, SF=8, BW=500, CR=4/5, IH=0
7592292: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0
7655536: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
7658109: EV_JOIN_FAILED
7663645: engineUpdate, opmode=0xc
8514192: engineUpdate, opmode=0xc
8514219: TXMODE, freq=909300000, len=23, SF=10, BW=125, CR=4/5, IH=0
8850089: RXMODE_SINGLE, freq=925100000, SF=10, BW=500, CR=4/5, IH=0
8913165: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
8915737: engineUpdate, opmode=0xc
8969401: engineUpdate, opmode=0xc
8969426: TXMODE, freq=907800000, len=23, SF=8, BW=500, CR=4/5, IH=0
9283728: RXMODE_SINGLE, freq=925100000, SF=7, BW=500, CR=4/5, IH=0
9346973: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
9349545: EV_JOIN_FAILED
9355057: engineUpdate, opmode=0xc
10130487: engineUpdate, opmode=0xc
10130515: TXMODE, freq=905100000, len=23, SF=10, BW=125, CR=4/5, IH=0
10466383: RXMODE_SINGLE, freq=926900000, SF=10, BW=500, CR=4/5, IH=0
10529460: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
10532032: engineUpdate, opmode=0xc
10584482: engineUpdate, opmode=0xc
10584507: TXMODE, freq=912600000, len=23, SF=8, BW=500, CR=4/5, IH=0
10898810: RXMODE_SINGLE, freq=926900000, SF=7, BW=500, CR=4/5, IH=0
10962054: RXMODE_SINGLE, freq=923300000, SF=12, BW=500, CR=4/5, IH=0
10964627: EV_JOIN_FAILED

https://www.thethingsnetwork.org/forum/t/rn2903-au-firmware/7127/7

this is not very forum friendly… please read How do I format my forum post?