ESP32 Wroom Chip with RFM95

Hello !!!
I will like to build my own LoRa Node Device with esp32 Wroom chip and one RFM95.
P2P was successful but now i whanna active ton the TTN. Can someone help me on this project ? i am over than one week on this but i cant send any information packet to the TTN Consol.
Thank you for advance

P2P requires different signals of the RFM95 to be connected to the controller.

Please provide more information in the hardware (circuit diagram would be helpful) and what software you are trying to use.

I am using ESP32 Wroom chip (witout development board).
I am trying to use the examples from TTN and TT Message libraries. As for the circuit I connect
RFM95 ESP32 Wroom chip
and i dont know the rest. Is posible to use ESP32 Wroom chip with RFM95 as node >?

Yes possible I plan to do the same.
Have a look to to how to connect the RFM95 and what library they uses.
They just connect it to simple Prozessor but you can do same with Wroom. Or have a look to Adafruit Feather M0 with RFM95.

@piperidisalexandros for full communication between RFM and processor you should also connect the CLK and NSS signals.And then I don’t know what stack you are using, but most stacks also use DIO0 and DIO1 from the RFM to signal TX-complete and RX-complete/RX-timeout events.

I am using the following connections
RFM95 ESP32 Wroom

The code is:

 * Copyright (c) 2015 Thomas Telkamp and Matthijs Kooijman
 * Copyright (c) 2018 Terry Moore, MCCI
 * Permission is hereby granted, free of charge, to anyone
 * obtaining a copy of this document and accompanying files,
 * to do whatever they want with them without any restriction,
 * including, but not limited to, copying, modification and redistribution.
 * This example sends a valid LoRaWAN packet with payload "Hello,
 * world!", using frequency and encryption settings matching those of
 * the The Things Network.
 * This uses ABP (Activation-by-personalisation), where a DevAddr and
 * Session keys are preconfigured (unlike OTAA, where a DevEUI and
 * application key is configured, while the DevAddr and session keys are
 * assigned/generated in the over-the-air-activation procedure).
 * Note: LoRaWAN per sub-band duty-cycle limitation is enforced (1% in
 * g1, 0.1% in g2), but not the TTN fair usage policy (which is probably
 * violated by this sketch when left running for longer)!
 * To use this sketch, first register your application and device with
 * the things network, to set or generate a DevAddr, NwkSKey and
 * AppSKey. Each device should have their own unique values for these
 * fields.
 * Do not forget to define the radio type correctly in
 * arduino-lmic/project_config/lmic_project_config.h or from your BOARDS.txt.

 // References:
 // [feather] adafruit-feather-m0-radio-with-lora-module.pdf

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

// For normal use, we require that you edit the sketch to replace FILLMEIN
// with values assigned by the TTN console. However, for regression tests,
// we want to be able to compile these scripts. The regression tests define
// COMPILE_REGRESSION_TEST, and in that case we define FILLMEIN to a non-
// working but innocuous value.
# define FILLMEIN 0
# warning "You must replace the values marked FILLMEIN with real values from the TTN control panel!"
# define FILLMEIN (#dont edit this, edit the lines that use FILLMEIN)

// LoRaWAN NwkSKey, network session key
// This should be in big-endian (aka msb).
static const PROGMEM u1_t NWKSKEY[16] = { msb form };

// LoRaWAN AppSKey, application session key
// This should also be in big-endian (aka msb).
static const u1_t PROGMEM APPSKEY[16] = { msb form };

// LoRaWAN end-device address (DevAddr)
// See
// The library converts the address to network byte order as needed, so this should be in big-endian (aka msb) too.
static const u4_t DEVADDR =  0x******** ; // <-- Change this address for every node! cant use msb form

// These callbacks are only used in over-the-air activation, so they are
// left empty here (we cannot leave them out completely unless
// DISABLE_JOIN is set in arduino-lmic/project_config/lmic_project_config.h,
// otherwise the linker will complain).
void os_getArtEui (u1_t* buf) { }
void os_getDevEui (u1_t* buf) { }
void os_getDevKey (u1_t* buf) { }

static uint8_t mydata[] = "Hello, world!";
static osjob_t sendjob;

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

// Pin mapping
// Adapted for Feather M0 per p.10 of [feather]
const lmic_pinmap lmic_pins = {
    .nss = 14,                       // chip select on feather (rf95module) CS
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 27,                       // reset pin
    .dio = {13, 12, LMIC_UNUSED_PIN}, // assumes external jumpers [feather_lora_jumper]
                                    // DIO1 is on JP1-1: is io1 - we connect to GPO6
                                    // DIO1 is on JP5-3: is D2 - we connect to GPO5

void onEvent (ev_t ev) {
    Serial.print(": ");
    switch(ev) {
        case EV_SCAN_TIMEOUT:
        case EV_BEACON_FOUND:
        case EV_BEACON_MISSED:
        case EV_BEACON_TRACKED:
        case EV_JOINING:
        case EV_JOINED:
        || This event is defined but not used in the code. No
        || point in wasting codespace on it.
        || case EV_RFU1:
        ||     Serial.println(F("EV_RFU1"));
        ||     break;
        case EV_JOIN_FAILED:
        case EV_REJOIN_FAILED:
        case EV_TXCOMPLETE:
            Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
            if (LMIC.txrxFlags & TXRX_ACK)
              Serial.println(F("Received ack"));
            if (LMIC.dataLen) {
              Serial.println(F("Received "));
              Serial.println(F(" bytes of payload"));
            // Schedule next transmission
            os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
        case EV_LOST_TSYNC:
        case EV_RESET:
        case EV_RXCOMPLETE:
            // data received in ping slot
        case EV_LINK_DEAD:
        case EV_LINK_ALIVE:
        || This event is defined but not used in the code. No
        || point in wasting codespace on it.
        || case EV_SCAN_FOUND:
        ||    Serial.println(F("EV_SCAN_FOUND"));
        ||    break;
        case EV_TXSTART:
            Serial.print(F("Unknown event: "));
            Serial.println((unsigned) ev);

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"));
    } else {
        // Prepare upstream data transmission at the next possible time.
        LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
        Serial.println(F("Packet queued"));
    // Next TX is scheduled after TX_COMPLETE event.

void setup() {
//    pinMode(13, OUTPUT);
    while (!Serial); // wait for Serial to be initialized
    delay(100);     // per sample code on RF_95 test

    #ifdef VCC_ENABLE
    // For Pinoccio Scout boards
    pinMode(VCC_ENABLE, OUTPUT);
    digitalWrite(VCC_ENABLE, HIGH);

    // LMIC init
    // Reset the MAC state. Session and pending data transfers will be discarded.

    // Set static session parameters. Instead of dynamically establishing a session
    // by joining the network, precomputed session parameters are be provided.
    #ifdef PROGMEM
    // On AVR, these values are stored in flash and only copied to RAM
    // once. Copy them to a temporary buffer here, LMIC_setSession will
    // copy them into a buffer of its own again.
    uint8_t appskey[sizeof(APPSKEY)];
    uint8_t nwkskey[sizeof(NWKSKEY)];
    memcpy_P(appskey, APPSKEY, sizeof(APPSKEY));
    memcpy_P(nwkskey, NWKSKEY, sizeof(NWKSKEY));
    LMIC_setSession (0x13, DEVADDR, nwkskey, appskey);
    // If not running an AVR with PROGMEM, just use the arrays directly
    LMIC_setSession (0x13, DEVADDR, NWKSKEY, APPSKEY);

    #if defined(CFG_eu868)
    // Set up the channels used by the Things Network, which corresponds
    // to the defaults of most gateways. Without this, only three base
    // channels from the LoRaWAN specification are used, which certainly
    // works, so it is good for debugging, but can overload those
    // frequencies, so be sure to configure the full frequency range of
    // your network here (unless your network autoconfigures them).
    // Setting up channels should happen after LMIC_setSession, as that
    // configures the minimal channel set.
    LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);      // g-band
    LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
    LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK,  DR_FSK),  BAND_MILLI);      // g2-band
    // TTN defines an additional channel at 869.525Mhz using SF9 for class B
    // devices' ping slots. LMIC does not have an easy way to define set this
    // frequency and support for class B is spotty and untested, so this
    // frequency is not configured here.
    #elif defined(CFG_us915)
    // NA-US channels 0-71 are configured automatically
    // but only one group of 8 should (a subband) should be active
    // TTN recommends the second sub band, 1 in a zero based count.

    // Disable link check validation

    // TTN uses SF9 for its RX2 window.
    LMIC.dn2Dr = DR_SF9;

    // Set data rate and transmit power for uplink

    // Start job

void loop() {
    unsigned long now;
    now = millis();
    if ((now & 512) != 0) {
      digitalWrite(13, HIGH);
    else {
      digitalWrite(13, LOW);



Still can’t active the end device to TTN

Please learn to format your messages before dumping large amounts of code in a message!

Ok i will do that. Thanks for advice.
Did you know how to make LoRa End device with only one microcotroller ESP32 (Chip not development board ) and RFM95?

Its straightforward enough, you can simply use an external serial adapter to program it. Its really going to need a PCB designed to take it though.

Why do you want to build one ?

The idea is to make a collar for wildlife. more specifically about deer. I want to know their exact locations and pass them through the TTN. I’ve solved the issue of how to program the microcontroller. The problem is how I’m going to connect the chip into the module in order to active it .

How are you going to obtain the location information to send?

Some variation on your idea can probably be made to work, but it is a very complex and challenging one.

Before doing it over from scratch, you should spend a lot of time studying existing attempts to learn what does (and frequently does not) work about them, and why.

Some of the issues you’ll likely face, where reading about existing efforts will save you a lot of frustration and bring you up to date on what is, - and is not yet - solved:

  • Trouble getting downlink timing right with the ESP32, especially ESP32-Arduino and LMiC
  • ESP’s more limited low power modes and mode transitions compared to traditional MCUs
  • Power issues when trying to run for useful time off small batteries
  • GPS power issues, and power vs. time-to-fix
  • GPS data issues, GPS parsing, not seeing enough satellites
  • Doing something with the data after the LoRaWAN stage

Currently TTGO has an ESP32 GPS->LoRa device on the market and RAK has an STM32L073 based one. Spend some time learning about what works and does not on each of those.

I have all ready the TTGO T-Beam. I will get the location from GPS module for now and after that i will move to the Geolocation. But i have only 2 question. How can i connect those bad boys together and make a simple end device known as Node.

The ESP32 would not be my first choice for that sort of tracker where extended battery life is important. Whilst you can with care get the sleep current down to 8uA, the running current, such as when the tracker is talking to the GPS is quite high, more than the GPS normally.

And what form of ‘Geolocation’ did you have in mind ?

Geolocation more info here :
The multilateration algorithm form

You have right it not worth to do this project with esp32. I will change the microcotroller with Atmel.

The ‘theory’ is understood, but current TTN gateways do not support timestamping that is anywhere near accurate and repeatable to be of use.

I recall @Borroz posting the details of 3 gateways in the same room receiving the same packet from a node, I forget the exact distance, but the timestamps showed that the gateways were something like 20,000km apart, although they were in the same room.

To get a location to with 1km you need to be able to take timestamps of incoming packets to within an accuracy of around 3uS.