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.
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.)
I think that the menu entry mainly configures the clock multiplicator/divisor and that Bluetooth and WiFi require a speed of at least 80 MHz. The XTAL reference is somewhat misleading.
Whoever designed the the Heltec WiFi LoRa 32(V2) board definition probably knew that this board only exists with a 40MHz crystal and designed the entries accordingly:
Compare this to the Heltec WiFi LoRa 32 board, which has a 26 MHz crystal.
The higher frequencies are approximations only and are off by 2.5%.
I actually didn’t notice but the Heltec V1 and V2 indeed have different crystals.
I was not aware before that ESP32 can be used with CPU frequencies lower than 80MHz (it’s just that WiFi/BT are not supported anymore then).
Have not been using Arduino IDE for a long time and PlatformIO does not show these values in a nice dropdown. Previously those lower frequencies were not listed (not yet supported).
The low CPU frequencies appear interesting for low-power applications.
Do you have any experience with using the ESP32 @ 10MHz (or 13MHz)?
Does it draw substantially less power than the default 80MHz?
Do you possibly have any comparison figures available?
Most of them use a 40MHz crystal.
| Board | Crystal frequency | |
|---|---|---|
| Heltec WiFi LoRa 32 V1 | 26MHz | |
| Heltec WiFi LoRa 32 V2 | 40MHz | |
| TTGO LoRa32 V2.0 | 40Mhz | (integrated in ESP32-PICO-D4) |
| TTGO T-Beam V0.5 | 40 MHz |
(Will need input from others for more recent versions of TTGO LoRa32 and T-Beam.)
No, I have never tried it.
Anybody else?
I conducted some basic power consumption tests with an ESP-WROOM-32 module on a bare breakout board, and a simple test script using the Arduino framework.
Script: Switch a GPIO port between high and low state with a 5s interval (delay(5000)) and write state information to the serial port.
Tested with CPU frequencies 240MHz, 160MHz, 80MHz, 40MHz and 10MHz.
The tests ran fine with correct timing.
(As expected but I had not tested this with lower ESP32 CPU frequencies before).
ESP-WROOM-32 module supply current consumption:
| CPU frequency | ESP-WROOM-32 supply current |
|---|---|
| 240 MHz | 37.7 mA |
| 160 MHz | 27.8 mA |
| 80 MHz | 21.6 mA |
| 40 MHz | 11.9 mA |
| 10 MHz | 8.0 mA |
(The ESP-WROOM-32 module used for these tests is an older version with ESP32 gen 0.)
The tests show that lowering the CPU frequency results in substantial power savings.
This looks promising for ESP32 low-power applications that do not need WiFi or Bluetooth (but it will require a board that respects low-power usage).
Note that use of WiFi and Bluetooth requires a CPU frequency of at least 80MHz.
The test setup was kept very basic to minimize influence from external components. The CPU load was small. Results for real applications may vary and it will be interesting to see low CPU frequency results from others.
Deep sleep: 18 uA
https://www.tinypico.com/
A nice board but with a price tag of $20 plus $15 for shipping it is quite expensive for what you get.
Hi
I am having a an issue with a Heltec V2 board. Using the example sketches to test as recommend.
In ABP mode everything functions fine.
In OTAA mode I can see the device register in the TTN console but the device never seems to get a joined response and the registration in the TTN console repeats over and over. (lighting bolt symbol)
As a test I connected an external RFM95 (used different pins for nss and di01,di02) this works perfectly in OTAA mode. So it has be something with the onboard radio ?
Pin setup as below for the default configuration.
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = { 26, 35, 34 },
.rxtx_rx_active = 0,
.rssi_cal = 0,
.spi_freq = 0
};
Any help with this odd behaviour would be greatly appreciated.
Regards
Jman
(If this is the wrong place to post this please relocate as necessary)
The most obvious causes would be:
When ttn-abp.ino appears to work correctly (do you see the messages arriving at the console?) that at least shows that the SPI connection to the SX1276 is functioning.
Assuming that you have used the exact same ttn-otaa.ino sketch (with same LoRaWAN keys/id’s defined) for both the on-board SX1276 and the external RFM95, that would rule out that the keys/id’s are entered incorrectly as they do work with the external RFM95.
Is the board explicitly labeled V2 on the PCB (next to the antenna connector)?
If not, then it’s a V1.x board and you should try .dio = { 26, 33, 32 } instead.
If it is a true V2 board then the pin mapping as you described is correct. In which case there might be something wrong with the board, either a connection problem between ESP32 and SX1276 DIO pins or a faulty SX1276.
Hi
Yes I can see messages in the console in abp mode.
Correct exact same sketch.
Yes 100%
So I can only assume its a faulty board.
While we are at it could you explain the difference in the use of the DIO pins in adp vs otaa mode
Many thanks for the help
Regards
Jman
There should not be any difference. LMiC uses the same radio functions for both.
What is critical is that the DIO that indicates transmit complete, and especially receive success correctly change and be seen. But that is critical for any downlink in either mode.
If I remember correctly: DIO1 is needed by LMIC for handling of downlink messages. For OTAA, DIO1 is required to be able to join. A succesful join is required to send normal uplink messages.
Using OTAA, when DIO1 is not correctly wired or its LMIC pin-mapping is set incorrectly, the node will be unable to join and will be unable to send uplink messages (other than join requests).
When using ABP and DIO1 is not correctly wired/mapped this will not restrict the node from sending uplink messages (but downlink messages will fail).
So there actually is a practical difference related to DIO1 between OTAA and ABP.
As a result, when DIO1 is incorrectly wired/mapped, when using ABP the node can still successfully send uplink messages, while this is not possible when using OTAA.
I have succeded in flashing my TTGO with micro python firmware for ESP32 http://micropython.org/resources/firmware/esp32-idf3-20191220-v1.12.bin
Micro Python works but does not include SX127x nor LMIC library.
Does somebody knows a LoRaWAN library for micro python ?