it’s targeted also at the rn2483 (see tab right corner) but I use it for antenna and reach testing firing single frames at different SF… and testing joins ect.
but off course not very handy mobile 
1 Like
I have 2 Heltec LoRa boards, v2: one set as node and another as GW (I followed the instructions found in post #123 of the Part 1 topic), both with OLED display.
For the node I’m using LMIC 1.5 with ABP method. The problem is that after a while (random) I see the node sending data (both on the GW display and TTN console in the GW Data) but the same data is not recorded anymore in TTN Console, Node Data.
The only way I found to make it register again in the TTN Console, is to reset the frame counters and restart the node.
How could I solve this issue?
Guessing: Sounds like your Heltec node makes a reset meanwhile and starts with frame counter = 0, while the TTN backend still has frame counter = n.
Solutions:
- use OTAA, not ABP
- find out, why your node makes unsolicited resets
- as a workaround while using ABP: make frame counter on node persistent
Thanks! For the moment I disabled the “Frame Counter Checks” option.
I’m using the default LMIC 1.5 Node code for Heltec LoRa boards.
Hi there
I released this old repo with an ESP32 LoraShield (sorry not doing it sooner)
I forked ESP32 Paxcounter need to make it compatible with this shield 
…but don’t join on every transmission.
2 Likes
Attached suggestion for paxcounter config files.
Would be nice if you add a LED control routine for the WS2812 LED, would be useful for LoPy, too.
---------------------------------
/src/hal/lolin23.h
// Hardware related definitions for WeMos LoLin32 board with ch2i Lora Node32 shield
#define CFG_sx1276_radio 1
//#define HAS_LED GPIO_NUM_13 // LED routine to be enhanced with WS2812 control routine
#define HAS_BUTTON GPIO_NUM_15 // button
// re-define pin definitions of pins_arduino.h
#define PIN_SPI_SS 5
#define PIN_SPI_MOSI 23
#define PIN_SPI_MISO 19
#define PIN_SPI_SCK 18
// non arduino pin definitions
#define RST 25
#define DIO0 27
#define DIO1 26
#define DIO2 4
---------------------------------
platformio.ini
[env:lolin32]
platform = espressif32
board = esp32dev
framework = arduino
monitor_baud = 115200
lib_deps =
U8g2
ESP32 BLE Arduino@>=0.4.9
build_flags =
;set log level, we need build_flag for this, otherwise we can't use ESP_LOGx in arduino framework
-DCORE_DEBUG_LEVEL=ARDUHAL_LOG_LEVEL_VERBOSE
; -DCORE_DEBUG_LEVEL=ARDUHAL_LOG_LEVEL_NONE
;needed for ESP32 BLE Ardunio v0.4.9
-fexceptions
-std=c++11
;override lora settings from LMiC library in lmic/config.h and use main.h instead
-D_lmic_config_h_
-include "src/main.h"
-include "src/hal/lolin32.h"It’s on the way, but lib NeoPixelBus don’t compile in pio, I need to tweak it ;-(
Since new version of IDF browout detection is sensible and I got my board reseting at boot, it’s a known problem and I added an option to disable brownout on my fork. Would you mind check it out and try?
you need to add the line in src/hal/yourtargetdevice.h (see device lolin32_lora.h)
// disable brownout detection (avoid unexpected reset on some boards)
#define DISABLE_BROWNOUT 1 // comment out if you want to keep brownout feature
let us know if it’s better
how did you know I ordered this board yesterday ?
1 Like
haha, I know you Rob 
If you give me your postal address, I can send you a free PCB, got one in spare it will be faster than PCBs.io
1 Like
Thanks for the hint & change.
I hope this will solve the brownout problem with TTGOv2, too, because my TTGOv2 makes reset if powered on battery and wifi if switched on during boot.
Unfortunatley can’t test it in the next days, because i currently have no TTGOv2 in hand.
Pull rerquest accepted, now integrated in paxcounter v1.5.
But i think we have to work on
#define HAS_LED NOT_A_PIN
since this is not evaluated in main.cpp yet.
1 Like
Should be no problem, long time ago I searched for this constant and found it in arduino, it’s classic, and any digital pin control (write, mode, …) when seeing NOT_A_PIN just do nothing
Oh while writing, you’re correct, we’re in ESP-IDF not sure of what is done, but looks like does not hurt, the constant definition is set to -1 (at least used to be set to this value)
1 Like
Charles, in your github repository, in https://github.com/ch2i/arduino-lmic/tree/master/src/hal I see only 2 files: hal.cpp and hal.h
It’s not in LMIC it’s in main project ESP32 Paxcounter, it’s now merged in master repo
https://github.com/cyberman54/ESP32-Paxcounter/tree/master/src/hal
1 Like
Downloaded and configured Platformio. Compiled and flashed but I always see on the OLED display: packet queued.
It finds the mac addresses of the active wifi devices.
Packet Queued means, that the LoRa stack is trying to send data, but can’t, either because there is no join yet, or the duty cycle cap is reached.
Check your network credentials and coverage, probably your device doesn’nt join the TTN.
I double checked: Device EUI, Application EUI, App Key and they are correct.
The gateway is 1 meter away from the node and when I restart the node, I get something on the gateway.
I have " #define DISABLE_BROWNOUT 1 " in /src/hal/heltec.h
The “Join Wait” messagge dissappeared. Does this mean it has joined the network?
PS: now I see “Lora wait” and “Lora Busy” messages. How often does the node send data to the GW? Every time a new active device is found?
After “join wait” you should see a “Joined” and after that the default display should be “TX completed”. If you see “Lora wait” und “Lora Busy” your device don’t send for some reason, see my post above.
The node sends after each completion of a wifi + bluetooth scan cycle. How long a cycle is, can be configured via remote commands. Defaults are 240 sec. Wifi scan, Bluetooth scan disabled. So by default the device sends all 240 secs.
I think i your case you have no join. Check on your gateway, if the join accept message goes out from the gateway. If yes, your device does not receive it for some reason.