Big ESP32 + SX127x topic part 2

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.

1 Like

And how do I get this code into an ESP32 ?

ää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)
FAILURE

lib\arduino-lmic-1.5.0-arduino-2-tweaked\src\lmic\radio.c:694

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 ?

Flash what ?

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

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

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

to

#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.

Well, we need a tool here, not a toy.
So, use PlatformIO, not Arduino IDE.

But, of course, you can taylor all the source files and libs by hand to your Arduino IDE and flash the ESP32 this way. That should work, but requires some work. With PlatformIO it’s less than 10 clicks.

Thank you for the tip. Unfortunately, I am getting a similar error, related to the code change:

[I][main.cpp:584] setup(): Features LED OLED
[I][lorawan.cpp:89] printKey(): DevEUI: (removed)
[I][lorawan.cpp:89] printKey(): AppEUI: (removed)
[I][lorawan.cpp:89] printKey(): AppKey: (removed)
FAILURE
lib\arduino-lmic-1.5.0-arduino-2-tweaked\src\lmic\radio.c:696

Well, I don’t know if it’s an hardware problem or just needs some software changes.
These are recent boards I have received yesterday.

I’ll get in touch with ttgo on Aliexpress to see what they suggest.

Fair enough.

I will continue to use my ‘toy’ as will no doubt will many people who participate in these forums.

1 Like

There could be two reasons:

  1. The LoRa chip on board answers with different version than Lmic expects from a Semtech SX1276/1272 chip.

RegVersion: Version code of the chip. Bits 7-4 give the full revision number;
bits 3-0 give the metal mask revision number. Default value: 0x22

The default value is checked by Lmic in radio.c line 694 / 696.

  1. There is no answer from the chip seen by Lmic, causing radio.c to stop. This could be caused by a different wiring of the SPI interface (MISO/MOSI/SCLK) of your TTGO v2.1 boards.

Can you please post high resolution photos of your boards here? Then we can compare.

Another thing what you could do, if you do not worry on health of your board is:

Comment out lines 694 and 696 in radio.c and build the code again.

#ifdef CFG_sx1276_radio
//    ASSERT(v == 0x12 );
#elif CFG_sx1272_radio
//    ASSERT(v == 0x22);

This should not affect functionality of lmic.
Then see what happenes.

Thank you for your suggestions.

I have restored the initial radio configuration in ttgov21.h

#define CFG_sx1276_radio 1 // HPD13A LoRa SoC

commented the whole block in radio.c

/*
#ifdef CFG_sx1276_radio
ASSERT(v == 0x12 );
#elif CFG_sx1272_radio
ASSERT(v == 0x22);
#else
#error Missing CFG_sx1272_radio/CFG_sx1276_radio
#endif
*/

Still not working, now fails in:

FAILURE
lib\arduino-lmic-1.5.0-arduino-2-tweaked\src\lmic\radio.c:550
Which is
ASSERT((readReg(RegOpMode) & OPMODE_LORA) != 0);

As for the boards picture, here it is:

If needed I’ll make new pictures with better lighting and focusing on specific PCB areas.

I’ve tested my 4th and last board, same issue as the 3 others ones.

Cheers.

Looks indeed slighlty different to my one:

  • my one has no print “T3 v1.5”
  • LoRa chip (or only the sticker on the chip?) rotated 180°

IMG_20180613_235149IMG_20180613_235136

Can you check wiring of Lora1 + Lora1 labelled pins to the LoRa Chip with multimeter?

Picture while running paxcounter v1.3.81 compiled IMG_20180613_235830with /hal/ttgov21.h

This looks like a broken SPI connection between the LoRa chip and ESP32 cpu.
Perhaps they really soldered the LoRa chip 180 degrees rotated? That would mean that they don’t test the boards, or test it using a software which has no error handling on the internal SPI interface, just “fire & forget” the commands to the LoRa chip…

You could validate correct or wrong orientation of the HPD13A LoRa chip on board by tracing it’s GND pins with a multimeter. It has 3 GND pins, see here:

https://de.aliexpress.com/item/CFsunbird-HPD13A-868MHz-SX1276-wireless-transceiver-modul-LoRa-daten-bertragung-SPI-fernbedienung-alarm-Kapstadt/32839694558.html

On the photo it can be seen that the HPD LoRa module is not rotated.
There are gaps in the soldering of the shield. On one (pin row) side there is only one gap. This is also the side with a marker dent on top (not visible because covered by the label). This should be on the same side as the SD card slot. (The shield soldering on the other side of the HPD module has 2 gaps.)

Ok, then probably the pin configuration / wiring of the SPI interface was changed on the pcb.

Again here we see the problems with chinese hardware…