Big ESP32 + SX127x topic part 2

(Linar) #551

Is there any TTN Mapper software for ESP32 and LMIC ?

About a week ago I was looking for an answer on the same question…
I have not found anything directly applicable.
There is a design published there, but the author did not give any comments on how to build it.

Finally, I’ve written my own code. It was easier than I expected.
I took reference ttn-abp and ttn-otaa LMIC examples first, then altered payload to match values I need to send to comply with TTN Mapper input data.

Then I’ve integrated the ttn-abp example and now it is a part of my project:

(LoRaTracker) #552

Thanks for the comment, I saw the design you linked too, but as you say no code.

I am keen to keep such a program within a standard Arduino environment, and for me the least painfull way of doing that is perhaps a LMIC fork that does not expect the compiler to fix the datatype miss-matches.

I thought of trying to make the changes starting from a known working example, so I loaded up the Dragino TTN Mapper and whilst that sends LoRa packets through the gateway I have here it does not appear to be sending a join request.

(LoRaTracker) #553

One of the difficulties I am having is locating some documentation that explains what happens when nodes communicate with a Gateway, what packets are sent and received during the different join requests and normal data gathering and their respective formats.


(Linar) #554

I am not 100% sure because I did this clone a year ago, but likely I took this repo as a reference source and can’t remind if I had any difficulties of building it either for ESP8266 or ESP32 Arduino Core.
There is also a branch there that is known to run well on Raspberry Pi in command line environment.

(LoRaTracker) #555

That library produces the same missmatch as the other LMIC library I was using.

It shows as a compiler warning;

warning: invalid conversion from ‘uint8_t {aka unsigned char}’ to ‘xref2u1_t {aka unsigned char*}’ [-fpermissive]

I am not saying the ‘fix’ is difficult and you could claim that its only a warning and the compiler can make the ‘fix’ for you. But that is only the case if for the hardware you are using the -fpermissive flag is set, and it is not for ESP32 and ATMEAG1284. Not difficult to add the --fpermissive but it does involve a manual edit of a text file. Fixing the core issue seems to make more sense to me.


Just curious, when/where do you get this warning?:
– In Arduino IDE or PlatformIO?
– Using arduino-esp32 or esp32-idf?
– Do you get the warning only with Dragino TTN Mapper or also with the standard LMIC TTN examples?


I’ve been working with the M5Stack platform (ESP32-based) and just shared with you my work so far. I think it could be a great platform for all sorts of moving nodes, including a TTNMapper node.

(LoRaTracker) #558

I am using the Arduino IDE, with the Dragino TTN mapper and another ESP32 TTN mapper I found, when compliling for ESP32.

The standard TTN-ABP example compliles OK, although it appears to use memcpy_p to copy the NWKSKEY from one area of memory (buffer) to another.

Maybe I just dont understand C\C++ well enough.


I was wondering where the error occurs because I had not seen it with the LMIC TTN examples.
So the error occurs ‘only’ with the TTN Mapper programs(?).
Because they use LMIC-Arduino features that are not used by the LMIC TTN examples?

(LoRaTracker) #560

Possibly, I noticed that in oslmic.h there are quite a few typdefs, such as;

typedef const u1_t* xref2cu1_t;

So you can loose track of what going on if you have -fpermisive set.


Hello Verkehrsrot,

Looking at your v2.1 picture, I don’t see any wiring for the DIO pins like on earlier TTGO v2 or v1 devices.
Does that mean LMIC code will work without any wiring on the TTGO v2.1 or is it something specific to paxcounter?


(Verkehrsrot) #562

Yes, TTGO v2.1 has DIO0, DIO1 and DIO2 wired on pcb. No need for external cabling when using lmic.

(Verkehrsrot) #563

You can use my ESP32 Paxcounter software, it has GPS support now. Just disable the counter features, then you have a ESP32 device ready to use for ttnmapper.

(LoRaTracker) #564

And how do I get this code into an ESP32 ?

(Verkehrsrot) #565

äähm - flash it into?


Well, I have a TTGO v2.1, I have flashed paxcounter v1.3.81 with PlatformIO, I choose the correct env_default = ttgov21 target in platformio.ini. I am getting an error when the device starts:

[I][lorawan.cpp:89] printKey(): DevEUI: (removed)
[I][lorawan.cpp:89] printKey(): AppEUI: (removed)
[I][lorawan.cpp:89] printKey(): AppKey: (removed)


I have tested on on 3 different TTGO v2.1 devices so far, including one that was just out of the box, same problem.

Any idea ?

(LoRaTracker) #567

Flash what ?

(Verkehrsrot) #568

Flash the code into the ESP32, e.g. using

(LoRaTracker) #569

My preferred IDE is Arduino, so how do I build and upload the code with Arduino ?

(Verkehrsrot) #570

I checked v1.3.81 on my TTGO v2.1, but i can not reproduce this.

Lines 694 in radio.c is a chip select SX1272 / SX1276 assertion:

  // some sanity checks, e.g., read version number
    u1_t v = readReg(RegVersion);
#ifdef CFG_sx1276_radio
    ASSERT(v == 0x12 );
#elif CFG_sx1272_radio
    ASSERT(v == 0x22);

Maybe there are TTGO v2.1 production batches with different LoRa chips.

You may try to change this line in your /src/hal/ttgov21.h file:

#define CFG_sx1276_radio 1 // HPD13A LoRa SoC


#define CFG_sx1272_radio 1 // HPD13A LoRa SoC

and recompile the code.

Note: If you use PlatformIO, use “clear” button after saving the .h file, before “build”.

If the error disappears after this change, your board has another LoRa chip than my sample.