RSSI (received signal strenth indication) is available only for downlink messages.
This could be the reason why you don’t see RSSI on the display.
can i not use the ack for that ?
ACK is received via a downlink message so RSSI should be available when receiving ACK.
The basic Arduino-LMIC examples and your linked code (which is based on ttn-abp.ino) however only print RSSI when data is received in a downlink message (ACK is not data).
To print RSSI when ACK is received but no data is received you will have to modify the code for EV_TXCOMPLETE.
Hi,
i’m having this board: TTGO ESP32-Paxcounter LoRa32 V2.1 1.6 Version 868MHZ
but can’t get it to work (the TTN console won’t receive anything) … here’s my settings:
- I’m using the MCCI LoRaWAN LMIC Library -> trying to activate via ttn-abp script (yes I think i’ve set up anything properly in my TTN account)
- modified lmic_project_config.h -> setting the frequency:
#define CFG_eu868 1(also in config.h) - in config.h i set the debug level:
#define LMIC_DEBUG_LEVEL 2 - in Arduino IDE: as board I used TTGO LoRa32-OLED V1 (is there a V2.1?)
my ttn-abp script uses the following settings:
NWKSKEY, PROGMEM APPSKEY, DEVADDR <- i’ve pasted it directly from TTN - or do i need to use reverse order? (read it somewhere)
my pin mapping:
const lmic_pinmap lmic_pins = {
.nss = 18, // chip select on feather (rf95module) CS
.rxtx = LMIC_UNUSED_PIN,
.rst = 19, // reset pin
.dio = {26, 33, 32}, // 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
};
^^ there’s a sketch on the Amazon page where i bought it which shows different pins(?)
but I’m not sure how to use them / if they’re correct …
here’s my serial monitor output:
⸮⸮⸮⸮8896
load:0x40080400,len:5816
entry 0x400806ac
Starting
RXMODE_RSSI
9650: engineUpdate, opmode=0x808
9694: EV_TXSTART
9765: TXMODE, freq=867500000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
75368: setupRx1 txrxFlags 00 --> 01
start single rx: now-rxtime: 3
75500: RXMODE_SINGLE, freq=867500000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 77052 rxtime: 75493 entry-rxtime: 1559 now-entry: 4 rxtime-txend: 61863
138252: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 4
138384: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 140704 rxtime: 138377 entry-rxtime: 2327 now-entry: 4 rxtime-txend: 124747
140723: processRx2DnData txrxFlags 0x2 --> 00
140768: processDnData_norx txrxFlags 00 --> 20
141023: EV_TXCOMPLETE (includes waiting for RX windows)
141331: engineUpdate, opmode=0x900
3891331: engineUpdate, opmode=0x908
3891355: EV_TXSTART
3891421: TXMODE, freq=867700000, len=26, SF=7, BW=125, CR=4/5, IH=0
Packet queued
3957023: setupRx1 txrxFlags 0x20 --> 01
start single rx: now-rxtime: 3
3957154: RXMODE_SINGLE, freq=867700000, SF=7, BW=125, CR=4/5, IH=0
rxtimeout: entry: 3958707 rxtime: 3957148 entry-rxtime: 1559 now-entry: 4 rxtime-txend: 61863
4019907: setupRx2 txrxFlags 0x1 --> 02
start single rx: now-rxtime: 3
4020038: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
rxtimeout: entry: 4022359 rxtime: 4020032 entry-rxtime: 2327 now-entry: 3 rxtime-txend: 124747
4022378: processRx2DnData txrxFlags 0x2 --> 00
4022438: processDnData_norx txrxFlags 00 --> 20
4022698: EV_TXCOMPLETE (includes waiting for RX windows)
4023013: engineUpdate, opmode=0x900
Any ideas what’s wrong? Thanks
If you see this log, the LMIC stack is sending data, so your pin mapping will be correct and the LoRa radio is working.
You probably did not join the network yet, so check your ABP procedure, esp. the setup for the network.
Any pointers how to modify this code ?
what should i add ?
this original:
case EV_TXCOMPLETE:
Serial.println(F(“EV_TXCOMPLETE (includes waiting for RX windows)”));
u8x8.drawString(0, 5, “EV_TXCOMPLETE”);
digitalWrite(BUILTIN_LED, LOW);
if (LMIC.txrxFlags & TXRX_ACK)
Serial.println(F(“Received ack”));
u8x8.drawString(0, 5, "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, 1);
u8x8.printf(“RSSI %d SNR %.1d”, LMIC.rssi, LMIC.snr);
i changed it into :
case EV_TXCOMPLETE:
u8x8.setCursor(0, 1);
u8x8.printf(“RSSI %d SNR %.1d”, LMIC.rssi, LMIC.snr);
Serial.println(F(“EV_TXCOMPLETE (includes waiting for RX windows)”));
u8x8.drawString(0, 5, “EV_TXCOMPLETE”);
digitalWrite(BUILTIN_LED, LOW);
if (LMIC.txrxFlags & TXRX_ACK)
that did not work 
My TTGO paxcounter V2.1 finally works - i can confirm these settings (Arduino IDE):
Flashed with board setting “TTGO LoRa 32-OLED V1” (there was no other TTGO Board preset)
const lmic_pinmap lmic_pins = {
.nss = 18, // chip select on feather (rf95module) CS
.rxtx = LMIC_UNUSED_PIN,
.rst = 19, // reset pin
.dio = {26, 33, 32}, // 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
};
I’m now having problems with power supply, when connecting a powerbank (USB) it works like a charm,
but when connecting a Battery to the battery connector there are massive dropouts - see the counter, it should send each 10 seconds:
I’m using this battery (which was recommended for the TTGO board) and it should be fully charged:
Is that battery too weak? Any other recommendations?
PS: no success at all with my Heltec V2 - I assume it’s either not the board as expected or it’s damaged … 
To prevent further confusion, that is not the real name of your board.
The correct name of the board is TTGO LoRa32 V2.1-1.6 like shown below.
LilyGO is not very consistent in their naming of this board series.
The board’s model name is actually TTGO LoRa32, also referred to as ‘T3’ which is confusing.
V2.1 is the version of the model, while 1.6 is the revision number of this model version. Again confusing due to the double ‘version’ number. ‘TTGO LoRa32 V2.1 rev1.16’ would have been easier to understand.
ESP32-PaxCounter is the name of software that came probably installed on it.
There is a dedicated topic for PaxCounter: Wifi/BLE Paxcounter Project with ESP32 boards
thanks for your info - btw. do you know if there’s also an Arduino (IDE) version of paxcounter?
No there is not. To my understanding PlatformIO is used because the Arduino IDE is much more limited, lacks important features and is much less productive.
1 Like
Please properly format code and logs in your posts, see: How do I format my forum post? [HowTo]
To print RSSI and SNR for acknowledgements (ACK) independent from if data was received or not, do the following:
In the original code, from the if (LMIC.dataLen) { ... } code block remove:
u8x8.setCursor(0, 1);
u8x8.printf(“RSSI %d SNR %.1d”, LMIC.rssi, LMIC.snr);
And place it in a separate if statement after (not within) that code block as follows:
if (LMIC.dataLen) {
...
}
if ((LMIC.txrxFlags & TXRX_ACK) || LMIC.dataLen) {
u8x8.setCursor(0, 1);
u8x8.printf(“RSSI %d SNR %.1d”, LMIC.rssi, LMIC.snr);
}TTGO LoRa32 V2.1 rev1.6 versus TTGO LoRa32 V2.0 pin layouts
A while ago I made a comparison between the pin layouts of TTGO LoRa32 V2.1 rev1.6 and TTGO LoRa32 V2.0. There are important differences and a comparison was not available from LilyGO.
The layouts are included below in png and pdf formats.
Blue labeled pins are GPIO ports for the JTAG interface. Green labeled pins are GPIO ports used for the SD Card. Red labeled pins are LoRa DIO ports that are not connected to GPIO ports (and require explicit wiring to a GPIO pin when needed).
PDF: TTGO LoRa32 V2.1 rev1.6 versus V2.0 pin layout comparison rev1.1.pdf (2.2 MB)
UPDATE:
Different from what the above comparison says DIO1 and DIO2 on the TTGO LoRa32 V2.1.6 (V2.1 rev 1.6) seem to be already wired on the PCB.
3 Likes
Hi i have it now this way
indent preformatted text by 4 spaces
case EV_TXCOMPLETE:
Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
u8x8.drawString(0, 5, "EV_TXCOMPLETE");
Serial.println(LMIC.rssi);
digitalWrite(BUILTIN_LED, LOW);
if (LMIC.txrxFlags & TXRX_ACK)
Serial.println(F("Received ack"));
u8x8.drawString(0, 5, "Received TACK ");
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"));
}
if ((LMIC.txrxFlags & TXRX_ACK) || LMIC.dataLen) {
u8x8.setCursor(0, 1);
u8x8.printf("RSSI %d SNR %.1d", LMIC.rssi, LMIC.snr);
}
that doesnt work
ill think the if is not fullfilled, if i remove the LMIC.txrxFlags &
there is a line on the display rssi o snr o
Well, that should work but as said before only when you receive a downlink message (with ACK or data), which apparently you are not receiving.
Are you familiar with the details of downlink messages? If not then better start learning about the LoRaWAN protocol first.
The ‘SNR %.1d’ above makes little sense because SNR is an integer (int8_t) and not a float.You therefore should change it to ‘SNR %d’ instead.
But be aware that this is not the reason why both RSSI and SNR are not printed.
1 Like
the sreens says “recieved ACK”, so ill asume the node received an ack.
how can i debug to see if actually an ACK is recieved ?
btw i am using this code from gtihub:
today i searched some more, it looks like there is no ack sending to the node.
i see no download arrows if i look in the gateway, only upload.
i i test the with downlink i see messages with a dowload arow, the node doesn’t doe anything with it ill think.
i don’t see the rssi either after a download form the gateway.
i think there is something fundamentaly wrong with my code.
can some one help me with this ?
the code i use is above.
I don’t have an Arduino IDE to check at the moment. But if I remember correctly, the XTAL frequency is mentioned in the Tools menu where you select and cofigure your board.
Also from memory: The ESP-IDF framework provides a function to estimate the XTAL frequency and the Arduino framework uses it to simplify usage. The default in ESP-IDF however is to set it explicitly.
If you somehow configure the XTAL frequency incorrectly, serial communication will only transmit gibberish. So it’s quite obvious if it’s incorrect and therefore it can’t be the cause of LMIC timing issues.
Also from memory: The ESP-IDF framework provides a function to estimate the XTAL frequency and the Arduino framework uses it to simplify usage. The default in ESP-IDF however is to set it explicitly.
That’s right, the actual clock frequency is by default setting in arduino-esp32 guessed based on an internal 8 MHz clock source, using ESP-IDF option “Autodetect”. As long as this works, selection of 26 vs 40 Mhz crystal should not have any impact.
No gibberish so that is probably unrelated then, but I see no reference for XTAL frequency.
In the Arduino IDE Tools menu (and in the ESP32 Arduino Core files) I only see settings for CPU frequency and SPI frequency but no explicit setting for crystal frequency.
If I interpret the list of possible CPU frequencies it appears like WiFi/BT will only work for CPU frequencies 80MHz and up and lower frequencies can be set only with 40MHz XTALs (but not sure if those assumptions are correct).
Related thread (external): ESP32 40Mhz vs 26MHz XTAL
(But does not give much details about differences.)
(Ah, I overlooked @Verkehrsrot’s last post.)