What kind of menu do you mean?
What would you expect to do it?
Just curious, wanted to see how it’s handled. A menu selecting SF, ACK, Len, … and send test packets for example 
Ah ok, so you are looking for a test node with some ‘dashboard’ where you can tweak several options and settings for (connection) testing purposes. 
That is also on my ‘would like to have/do’ list. 
Also neat would be the possibility to easily (‘on the fly’ + node restart) switch between OTAA and ABP activation. But not practically feasible because the node type has to be defined on the backend. This can possibly be done via an API call but would be too much hassle and too complex.
A workaround is to create two separate (logical) devices in the TTN console for the same physical node. One for OTAA and one for ABP. This will allow the node to be switched from OTAA to ABP and vice versa for testing purposes without requiring changes in the (hardcoded) configuration on the node or backend.
Another nice option would be to have the UI run on a phone, connected via BLE with the node. Useful for field testing and does not require display, buttons, rotary encoder etc. on the (test)node. ESP32 already has the BT built in.
passthrough sketch and this freeware… (works only with rn2483)
1 Like
Nice, but that’s a complete IDE targeted at ESP8266. Not a solution that runs on the node independently that can be used for easy mobile field testing.
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