No live data in TTN and no payload transmitted with SX1276 and Arduino Pro Mini

End Devices (Nodes) LMIC
1

Hi everyone,
Since I could not find any working solution on the forum, I am sharing my problem with you.
I am trying to send “Hello world” with the SX1276 module and an Arduino Pro Mini (3.3V 8MHz) to TTN with the ttn-abp example provided by the MCCI LoRaWAN LMIC Library (Version 4.1.1). I am sure that my SX1276 is working correctly, since I have a second board, and communication could be succesfully established when sending messages between the two SX1276 (>100meters).
I am in Europe using 868MHz config, and in a big city with gateways very close (<500m). I dont have my own gateway.

I created an end-device on TTN for abp with:

  • Europe 863-870 MHz (SF9 for RX2 - recommended)
  • LoRaWAN Specification 1.0.3
  • RP001 Regional Parameters 1.0.3 revision A

I followed ttn-abp and replaced FILLMEIN by NWKSKEY and APPSKEY with big-endian format (msb) and DEVADDR in big endian too

static const u4_t DEVADDR = 0x260BF156 ; // ← Change this address for every node!

I am using default wiring setup:

// Pin mapping
// Adapted for Feather M0 per p.10 of [feather]
const lmic_pinmap lmic_pins = {
.nss = 8, // chip select on feather (rf95module) CS
.rxtx = LMIC_UNUSED_PIN,
.rst = 4, // reset pin
.dio = {6, 5, 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
};

So I connected RST to Pin 4, DI00 to Pin 6 and DI01 to PIn 5.

I also uncommented

#define CFG_eu868 1
#define CFG_sx1276_radio 1

in MCCI_LoRaWAN_LMIC_library/project_config/lmic_project_config.h

I use an external 3.3V supply for my SX1276 to make sure to have sufficient current/power.

Unfortunately, here is what appears in my Arduino monitor:

20:21:21.618 → 130186000: EV_TXSTART
20:21:21.618 → Packet queued
20:21:23.742 → 130316816: EV_TXCOMPLETE (includes waiting for RX windows)
20:21:33.746 → 130942812: EV_TXSTART
20:21:33.746 → Packet queued
20:21:35.866 → 131073625: EV_TXCOMPLETE (includes waiting for RX windows)
20:21:45.871 → 131699618: EV_TXSTART
20:21:45.904 → Packet queued
20:21:47.991 → 131830596: EV_TXCOMPLETE (includes waiting for RX windows)
20:21:58.026 → 132456591: EV_TXSTART
20:21:58.026 → Packet queued
20:22:00.113 → 132587405: EV_TXCOMPLETE (includes waiting for RX windows)

No obvious errors but no ACK message or "Received ?? bytes of payload.
Same in TTN, no live data transmitted.

Am I doing something wrong?

I would greatly appreciate your help please !

PXL_20221029_193230112
PXL_20221029_1932301121920×2560 223 KB

2

The good news is that LMIC will tell you if it’s not happy with the pin config, so in theory the hardware is OK.

The bad news is that responses are likely to be very muted whilst you are hammering the network, breaching both Fair Use Policy and the law. Best start saving for the suit & tie for the court appearance.

LoRaWAN doesn’t do ACKs unless you specifically request it, which we DO NOT want you to do on TTN as it blocks all other devices.

Why would you expect to receive ?? bytes of payload? Which direction is that payload that you are referring to? Up or Down?

Developing devices without access to your own gateway makes debugging very very very extra very hard - you have no idea if your device was heard by a gateway.

It’s a very nice picture of a radio module but it only tells us that the soldering looks OK but that your antenna is likely to be taking output backwards - like -3dB - but I’m not one of the resident antenna experts, I just do LMIC & FUP sarcasm.

3

Ahah yes I already bought the suit, it s ready !

Thank you for your answer @descartes !

I am just trying to uplink “Hello world” to the Things Network. So I should better buy my own gateway.

4

It might sound counter intuitive, switch to OTAA.

5

Thank you for your answer @kersing

I tried to switch to OTAA. So I am using the ttn-otaa sketch example in Arduino IDE.

// 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.
static const u1_t PROGMEM APPEUI[8]={ 0xEF, 0xCD, 0xAB, 0x90, 0x78, 0x56, 0x34, 0x12 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}

// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8]={ 0x78, 0x70, 0x05, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
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.
static const u1_t PROGMEM APPKEY[16] = { 0xF7, 0x65, 0x21, 0xBD, 0x92, 0xF1, 0xB8, 0x1E, 0xD9, 0xB9, 0x3F, 0xD0, 0xAA, 0xAA, 0x4B, 0x47 };
void os_getDevKey (u1_t* buf) {  memcpy_P(buf, APPKEY, 16);}

after filling the FILLME by the infos in the TTN control panel.

image

I adapted the wiring.
I am still using the #define CFG_eu868 1 in lmic_project_config.h

Unfortunately, I have:

10:35:51.811 -> Starting
10:37:13.648 -> Packet queued
10:37:13.681 -> 2567: EV_JOINING
10:37:19.745 -> 381893: EV_TXSTART
10:37:26.042 -> 775187: EV_JOIN_TXCOMPLETE: no JoinAccept
10:38:30.989 -> 4828033: EV_TXSTART
10:38:37.317 -> 5221333: EV_JOIN_TXCOMPLETE: no JoinAccept
10:39:38.334 -> 9028727: EV_TXSTART
10:39:44.624 -> 9422026: EV_JOIN_TXCOMPLETE: no JoinAccept
10:40:53.937 -> 13746043: EV_TXSTART
10:41:00.295 -> 14142558: EV_JOIN_TXCOMPLETE: no JoinAccept

And no data are received in the TTN live data.

Any idea of what is going on there?

6

little-endian format - Do you understand what the means?

7

Huh? There is no wiring change required - it’s all in software.

What do you see on the gateway console log? Or the gateway internal log? That will tell you if the radio is actually transmitting.

Your EUI’s are the wrong way round - the instructions in the code say LSB - that’s what the little arrows do for you.

Have you adjusted the send rate for both sketches to work with the FUP?

8

Guys, it finally works. It had nothing to do with the MSB/LSB or ABP/OTAA activation method.
I just had to walk in the streets in my neighborhood to finally see arriving messages in the TTN live data (ABP method).

I am bit surprised that in a city like Paris, the coverage is not so great, some streets are not covered at all, even in the center. Is it something expected?

In the Arduino IDE, ttn-abp and ttn-otaa dont propose the same pinconfig, so either you change the wiring (hardware) or you change the pinconfig (software). Moreover, they propose to use the pin DI02 in OTAA.

I dont have any gateway.

I let the 60 seconds default TX_INTERVAL.

I do.

Thank you for your help though!

9

Which is exactly what you were told at the beginning - no forced error on part of the volunteers answering here - either you weren’t in range or there was a setup issue.

Please don’t expect further help if you are going to compromise the shared community gateways - particularly as you are using someone else’s gateways.

1 Like
10

Adjust for your payload and DR and please have regard for the FUP line if using TTN GW’s & servers.
https://avbentem.github.io/airtime-calculator/ttn/eu868/22

11

Imagine if you are so kind to add a gateway to the community, you will have better coverage.

12

Put a gateway on the Eiffel-tower and you will get a huge coverage. In large cities like Paris a coverage of only a few 100m is normal although the antenna is on the roof if you are standing on the floor. If the antenna is inside a building you may achieve only a few streets.

13

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.