Not showing up on APRS map

[dnwk]

I have load it to TTGo LoRA board. Set CFG_IS_CLIENT_MODE to false

define CFG_DIGIREPEAT true

define CFG_RF_TO_IS true

define CFG_IS_TO_RF true

define CFG_BEACON true

Also configured Wifi, APRS login. However, the beacon never showed up on APRS map and never forward any other LoRA APRS to APRS-IS What could possibly go wrong? The LoRa board did successfully get an IP address from the router as I could see it from router DHCP table.

[sh123]

@dnwk , does it receive incoming packets? Do you see them in log stream on Arduino console? Do you use this project on client side as well with CFG_IS_CLIENT_MODE set to true? Which exact board type do you choose in Tools -> Boards?

[dnwk]

I am using this project on both iGate board and client board. I have set cfg_is_client_mode to true on the client board and to false on the iGate board.

This is what I get from the serial monitor from iGate board. It could receive packets from APRS-IS server. But doesn't seem to receive any LoRa packet I sent (or the client board didn't send any). I can't get anything from client board off serial monitor. Nothing on display. I set the board to TTGO LoRa32-OLED v1

.ok 192.168.1.206 BT init loraprs2-server...ok APRSIS connecting...ok Periodic beacon is sent /# aprsc 2.1.8-gf8824e8 Unknown payload from APRSIS, ignoring /# logresp {mycallsign} verified, server T2UKRAINE Unknown payload from APRSIS, ignoring KH6IHB-7>T6PQYT,WA2WA,WIDE1*,WIDE2-1,qAR,W7CLI:'.7Ol Z//>"6,}^ /# aprsc 2.1.8-gf8824e8 5 Apr 2021 23:54:53 GMT T2UKRAINE 89.185.8.55:14580 Unknown payload from APRSIS, ignoring /# aprsc 2.1.8-gf8824e8 5 Apr 2021 23:55:13 GMT T2UKRAINE 89.185.8.55:14580 Unknown payload from APRSIS, ignoring

[sh123]

@dnwk, do you see on SDR that client transmits? Can you receive it for example with SDRAngel ChirpChat plugin?

If client transmits, then try to change cfg.LoraUseIsr to false, so it will poll for new data instead of relying on LoRa IRQ line and check your board pinouts, currently Arduino defines them as

 19 // SPI LoRa Radio
 20 #define LORA_SCK 5        // GPIO5 - SX1276 SCK
 21 #define LORA_MISO 19     // GPIO19 - SX1276 MISO
 22 #define LORA_MOSI 27    // GPIO27 - SX1276 MOSI
 23 #define LORA_CS 18     // GPIO18 - SX1276 CS
 24 #define LORA_RST 14   // GPIO14 - SX1276 RST
 25 #define LORA_IRQ 26  // GPIO26 - SX1276 IRQ (interrupt request)

in ~/.arduino15/packages/esp32/hardware/esp32/1.0.4/variants/ttgo-lora32-v1/pins_arduino.h

Maybe your board has different pinouts in use, especially LORA_IRQ.

V1.0 has next pinout layout:

and V2.0

It has some additional DIO LoRa pinouts, mapped to 12 and 11 gpio.

[dnwk]

This is the PIN info I have

LED: IO25

IO5=SCK IO18=NSS/SEL IO27=MOSI/SDI IO19=MISO/SDO IO26=DI0/IO0 IO23=IRQ/RESET

This is more close align with .\Arduino15\packages\esp32\hardware\esp32\1.0.6\variants\ttgo-lora32-v21new\pins_arduino.h which state // SPI LoRa Radio

define LORA_SCK 5 // GPIO5 - SX1276 SCK

define LORA_MISO 19 // GPIO19 - SX1276 MISO

define LORA_MOSI 27 // GPIO27 - SX1276 MOSI

define LORA_CS 18 // GPIO18 - SX1276 CS

define LORA_RST 12 // GPIO14 - SX1276 RST

define LORA_IRQ 26 // GPIO26 - SX1276 IRQ (interrupt request)

define LORA_D1 33 // GPIO33 - SX1276 IO1 (for LMIC Arduino library)

define LORA_D2 32 // GPIO32 - SX1276 IO2

I don't know if this pin definition exactly matches with vendor provided information and how to apply this file.

[dnwk]

And you are right, when I listen to the 433.775Mhz on a receiver, I don't see a transmit with the expectation that sometimes it will transmit when device just turn on. I used meshtastic firmware on them so I know the LoRa radio does work. I guess I need to figure out what those PINs are

[sh123]

@dnwk , strange, checking https://github.com/espressif/arduino-esp32/blob/master/variants/ttgo-lora32-v21new/pins_arduino.h and it has next pinouts

// SPI LoRa Radio
#define LORA_SCK    5   // GPIO5 - SX1276 SCK
#define LORA_MISO   19  // GPIO19 - SX1276 MISO
#define LORA_MOSI   27  // GPIO27 - SX1276 MOSI
#define LORA_CS     18  // GPIO18 - SX1276 CS
#define LORA_RST    12  // GPIO14 - SX1276 RST
#define LORA_IRQ    26  // GPIO26 - SX1276 IRQ (interrupt request)
#define LORA_D1     33  // GPIO33 - SX1276 IO1 (for LMIC Arduino library)
#define LORA_D2     32 // GPIO32 - SX1276 IO2

LORA_RST defined as 12, but not as 14

[sh123]

@dnwk , check from the Arduino console on the client side, it has some log line indicating that LoRa initialized.

LoRa init: ... ok

If LoRa initialization is fine then maybe Bluetooth packets do not arrive for some reason, using it mostly with APRSDroid.

[dnwk]

[dnwk]

I can't get any serial monitor display from client side. I am forcing PIN to be

define LORA_RST 23

define LORA_IRQ 26

I can get it to transmit from APRSDroid app. But not very reliably. Sometimes it will. Sometimes it won't. Codec2_Talkie could get it to transmit a little bit more reliable. However, most of time the receiver won't be able to decode the transmit. Even though the client and iGate are next to each other, the signal report seems weird. rssi: -20.00dBm, snr: 9.25dB, err: 492Hz

[sh123]

@dnwk , report looks ok, haven't seen these modules report more than 10 dB SNR even at close range. If it receives sometimes then pinouts are ok. Unfortunately, do not have this particular board flavor to test. Myself testing with custom shield and RA-01 module (with APRSDroid and codec2_talkie) and another operator was testing with T-Beam LoRa and it was working without any issues.

[dnwk]

OK. it doesn't seem like the problem maybe on the Bluetooth side or KISS processing. I have T-beam too. Will test it on T-beam

[sh123]

@dnwk , also just in case upgraded server and client with Arduino ESP32 lib to latest 1.0.6 (was on 1.0.4) and checked, seems to be working fine.

[dnwk]

I flashed T-Beam with this and still experience similar issue where LoRa packet are not always sent from APRSDroid. However, when I set LoraUseIsr to false, it works very reliably.

[sh123]

@dnwk , updated it, so it will false by default, should be ok for APRS, but speech streaming needs ISR usage.

[dnwk]

Also, the Beacon never actually sent to APRS-IS. I'm still trying to track down on why

[dnwk]

Ok. Problem solved. The Raw beacon is malformed. Thanks

[sh123]

@dnwk , about this ISR problem, I noticed this problem when frequency correction is enabled with cfg.EnableAutoFreqCorrection (it is disabled by default) and delta is set to small value. So when frequency correction is happening too often then module "locks up" and never triggers ISR anymore.

[dnwk]

Ah, Got it. That explains. Thanks

[dnwk]

I want to update you on ISR problem. I am testing this with Codec2 Talkie app. If I set ISR to TRUE as suggest for voice, I can't get a reliable voice stream. Sometimes it will work sometimes it won't. But when I set ISR to FALSE, Codec2 Talkie could get a voice connection fairly reliable. I am not sure why.

[sh123]

@dnwk , do you have cfg.EnableAutoFreqCorrection set to false? Try to enable ESP32 verbose logging, reproduce this problem and post relevant chunk of log output here, please.

[dnwk]

Frequency correction is set to false. I'll try verbose tomorrow. Thanks

[dnwk]

Sorry I still haven't have time to test it. I'm spending most of my time extending this project to use T-Beam GPS for APRS beacon. Are you interested in a pull request? Otherwise, I'll keep it to my fork.

[sh123]

@dnwk, if that feature is configurable then we can merge it, but different esp32 LoRa board flavors may have different pinouts to GPS module and other peripherals, such as screen. These may need some kind of HAL to support different board flavors or be able to disable/enable for boards, which do not have these peripherals. Currently, LoRa module pinouts is the only hardware specific configuration and it is mostly defined in Arduino esp32 board variant files pins_arduino.h.

[dnwk]

I'll submit the pull request. You could review it and see if it's appropriate to merge. Your call.