Multiple Cubecell HTCC-AB01 only intermittently connecting to the gateway - US915 TTN

noebl1 · September 22, 2021, 12:31am

This problem has been plaguing me for awhile and just looking back into it again as really want to use the Cubecell HTCC-AB01 for a project. I have a simple app which is basically the Heltec interrupt example, but doesn’t matter as can reproduce this with the stock example from of https://github.com/HelTecAutomation/platform-asrmicro650x/tree/develop/examples/LoRa/LoRaWAN/LoRaWAN by changing the relevant keys.

Essentially I am only intermittently hitting my gateway (about 2 floors up) on several different CubeCell HTCC-AB01 and AB02 boards and about to give up on them which is disappointing. Sometimes it reaches the gateway on the first try, sometimes it can go several minutes and never connect. I have a Dragino temp/humidity sensor that’s been rock solid during this time and connects every 20mins like clockwork (almost to the second). I was starting to doubt my RAK2287 based gateway… So tonight I pulled up an Heltec ESP32 v2 LoRa board, and once I properly set the subchannel for TTN in the US915, worked solidly every time. I also ordered a Heltec Wireless Stick lite, but won’t be in until tomorrow. I’ve tried different antennas that came with the different boards, and two other 900mhz antennas.

Info… US915 connecting thru TTN and OTAA and using PlatformIO with the latest v1.3.1 asrmicro650x release from github. I’m 100% certain the AppEUI, devEUI and appKey are correct, as it does intermittently go through. Since in the US915 and TTN, I’m using this channel mask as recommended by several posts here and on the TTN forum (though I’ve tried 0x00FF as well):

uint16_t userChannelsMask[6]={ 0xFF00,0x0000,0x0000,0x0000,0x0000,0x0000 };

Here’s my platform.io config:

[env:cubecell_board]
platform = asrmicro650x
board = cubecell_board
framework = arduino
monitor_speed = 115200
upload_port = /dev/ttyUSB0
monitor_port = /dev/ttyUSB0

board_build.arduino.lorawan.region = US915
board_build.arduino.lorawan.class = CLASS_A
board_build.arduino.lorawan.netmode = OTAA
board_build.arduino.lorawan.adr = OFF
board_build.arduino.lorawan.uplinkmode = CONFIRMED
board_build.arduino.lorawan.net_reserve = OFF
board_build.arduino.lorawan.rgb = ACTIVE
board_build.arduino.lorawan.debug_level = FREQ_AND_DIO
board_build.arduino.lorawan.at_support = ON

Here’s what a good transmission looks like as seen from my gateway:

JSON up: {"rxpk":[{"jver":1,"tmst":4037155309,"time":"2021-09-21T21:46:32.227211Z","tmms":1316296011226,"chan":1,"rfch":0,"freq":904.100000,"mid": 8,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","rssis":-75,"lsnr":14.2,"foff":6642,"rssi":-74,"size":23,"data":"REMOVED"}]}
INFO: [down] PULL_RESP received  - token[0:10] :)

JSON down: {"txpk":{"imme":false,"tmst":4042155309,"freq":923.9,"rfch":0,"powe":26,"modu":"LORA","datr":"SF7BW500","codr":"4/5","ipol":true,"size":17,"ncrc":true,"data":"REMOVED="}}


JSON up: {"rxpk":[{"jver":1,"tmst":4051809424,"time":"2021-09-21T21:46:46.881327Z","tmms":1316296025880,"chan":4,"rfch":1,"freq":904.700000,"mid": 8,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","rssis":-75,"lsnr":14.2,"foff":6655,"rssi":-75,"size":17,"data":"REMOVED"}]}
INFO: [down] PULL_RESP received  - token[0:11] :)

JSON down: {"txpk":{"imme":false,"tmst":4056809424,"freq":925.7,"rfch":0,"powe":26,"modu":"LORA","datr":"SF7BW500","codr":"4/5","ipol":true,"size":22,"ncrc":true,"data":"REMOVED"}}

When I watch the gateway on a one that doesn’t go through, this is what I see from the output of the app:

Copyright @ 2019 Heltec Automation.All rights reserved.
Interrupts attached

AT Rev 1.3
+AutoLPM=1

+LORAWAN=1

+KeepNet=0
+OTAA=1
+Class=A
+ADR=0
+IsTxConfirmed=1
+AppPort=2
+DutyCycle=1200000
+ConfirmedNbTrials=4
+ChMask=00000000000000000000FF00
+DevEui=REMOVED
+AppEui=REMOVED
+AppKey=REMOVED
+NwkSKey=REMOVED
+AppSKey=REMOVED
+DevAddr=REMOVED


LoRaWAN US915 Class A start!

joining...TX on freq 904500000 Hz at DR 3 power 20 dBm
TX on freq 904500000 Hz at DR 3 power 20 dBm
Event : Tx Done
RX on freq 925100000 Hz at DR 13
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 905100000 Hz at DR 0 power 20 dBm
TX on freq 905100000 Hz at DR 0 power 20 dBm
Event : Tx Done
RX on freq 926900000 Hz at DR 10
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 904100000 Hz at DR 3 power 20 dBm
TX on freq 904100000 Hz at DR 3 power 20 dBm
Event : Tx Done
RX on freq 923900000 Hz at DR 13
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 903900000 Hz at DR 0 power 20 dBm
TX on freq 903900000 Hz at DR 0 power 20 dBm
Event : Tx Done
RX on freq 923300000 Hz at DR 10
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 904900000 Hz at DR 3 power 20 dBm
TX on freq 904900000 Hz at DR 3 power 20 dBm
Event : Tx Done
RX on freq 926300000 Hz at DR 13
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 904300000 Hz at DR 0 power 20 dBm
TX on freq 904300000 Hz at DR 0 power 20 dBm
Event : Tx Done
RX on freq 924500000 Hz at DR 10
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 904700000 Hz at DR 3 power 20 dBm
TX on freq 904700000 Hz at DR 3 power 20 dBm
Event : Tx Done
RX on freq 925700000 Hz at DR 13
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 905300000 Hz at DR 0 power 20 dBm
TX on freq 905300000 Hz at DR 0 power 20 dBm
Event : Tx Done
RX on freq 927500000 Hz at DR 10
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 904500000 Hz at DR 3 power 20 dBm
TX on freq 904500000 Hz at DR 3 power 20 dBm
Event : Tx Done
RX on freq 925100000 Hz at DR 13
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 904700000 Hz at DR 0 power 20 dBm
TX on freq 904700000 Hz at DR 0 power 20 dBm
Event : Tx Done
RX on freq 925700000 Hz at DR 10
Event : Rx Timeout
RX on freq 923300000 Hz at DR 8
Event : Rx Timeout
TX on freq 905300000 Hz at DR 3 power 20 dBm
TX on freq 905300000 Hz at DR 3 power 20 dBm
Event : Tx Done
RX on freq 927500000 Hz at DR 13
Event : Rx Done
joined
BatteryVoltage:4066
Sending dev status packet
confirmed uplink sending ...
TX on freq 904900000 Hz at DR 3 power 20 dBm
TX on freq 904900000 Hz at DR 3 power 20 dBm
Event : Tx Done
RX on freq 926300000 Hz at DR 13
Event : Rx Done
received unconfirmed downlink: rssi = -68, snr = 10, datarate = 13

I’ve tried toggling to UNCONFIRMED for the uplink mode, as well as ADR On as well. Looking for any ideas/suggestions as I can’t figured what I may be missing.

Thanks!

shaffer · September 22, 2021, 2:06am

What is your gateway frequency?

noebl1 · September 22, 2021, 11:28am

Thank you for the reply It’s supposed to be US915, here’s I think the relevant start up bits:

*** Packet Forwarder ***
Version: 2.0.1
*** SX1302 HAL library version info ***
Version: 2.0.1;
***
INFO: Little endian host
INFO: found configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX130x_conf, parsing SX1302 parameters
INFO: com_type SPI, com_path /dev/spidev0.0, lorawan_public 1, clksrc 0, full_duplex 0
INFO: antenna_gain 0 dBi
INFO: Configuring legacy timestamp
INFO: no configuration for SX1261
INFO: Configuring Tx Gain LUT for rf_chain 0 with 16 indexes for sx1250
INFO: radio 0 enabled (type SX1250), center frequency 904300000, RSSI offset -215.399994, tx enabled 1, single input mode 0
INFO: radio 1 enabled (type SX1250), center frequency 905000000, RSSI offset -215.399994, tx enabled 0, single input mode 0
INFO: Lora multi-SF channel 0>  radio 0, IF -400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 1>  radio 0, IF -200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 2>  radio 0, IF 0 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF 200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 4>  radio 1, IF -300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 5>  radio 1, IF -100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 6>  radio 1, IF 100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 7>  radio 1, IF 300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora std channel> radio 0, IF 300000 Hz, 500000 Hz bw, SF 8, Explicit header
INFO: FSK channel 8 disabled
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to REMOVED
INFO: server hostname or IP address is configured to "nam1.cloud.thethings.network"
INFO: upstream port is configured to "1700"
INFO: downstream port is configured to "1700"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: GPS serial port path is configured to "/dev/ttyS0"
INFO: Reference latitude is configured to 0.000000 deg
INFO: Reference longitude is configured to 0.000000 deg
INFO: Reference altitude is configured to 0 meters
INFO: Beaconing period is configured to 0 seconds
INFO: Beaconing signal will be emitted at 923300000 Hz
INFO: Beaconing channel number is set to 8
INFO: Beaconing channel frequency step is set to 600000Hz
INFO: Beaconing datarate is set to SF12
INFO: Beaconing modulation bandwidth is set to 500000Hz
INFO: Beaconing TX power is set to 27dBm
INFO: global_conf.json does contain a JSON object named debug_conf, parsing debug parameters
INFO: got 2 debug reference payload
INFO: reference payload ID 0 is 0xCAFE1234
INFO: reference payload ID 1 is 0xCAFE2345
INFO: setting debug log file name to loragw_hal.log
INFO: found configuration file local_conf.json, parsing it
INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to REMOVED
INFO: server hostname or IP address is configured to "nam1.cloud.thethings.network"
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will be forwarded
INFO: packets received with no CRC will be forwarded
INFO: GPS serial port path is configured to "/dev/ttyS0"
This is uart for GPS.
INFO: [main] TTY port /dev/ttyS0 open for GPS synchronization
CoreCell reset through GPIO17...
Opening SPI communication interface
Note: chip version is 0x10 (v1.0)
INFO: using legacy timestamp
INFO: LoRa Service modem: configuring preamble size to 8 symbols
ARB: dual demodulation disabled for all SF
INFO: found temperature sensor on port 0x39
INFO: [main] concentrator started, packet can now be received
INFO: concentrator EUI: REMOVED
WARNING: [gps] GPS out of sync, keeping previous time reference
WARNING: [gps] GPS out of sync, keeping previous time reference
INFO: [modify_os_time] local_time=1632309957, gps_time=1632309956

noebl1 · September 22, 2021, 10:02pm

Just got the Heltec Wireless Stick lite, worked the first time and after several beacons and resets. Not sure the deal on the Cubecells

shaffer · September 23, 2021, 3:56am

You can check whether the frequency points of the gateway and the node completely correspond, and view the gateway log to check whether the gateway has downlink when the node rx timeout.

noebl1 · September 23, 2021, 11:37pm

I think I get what you mean. Most of the time I don’t see it hitting the gateway watching it’s live output, occasionally I see a join, but not very often.

shaffer · September 24, 2021, 2:35am

Can you display more gateway and node log information? It’s best to bring a time stamp.

jezd · September 26, 2021, 10:20pm

You using the wrong language, a device broadcasts and listens, it does not connect to any single gateway - gateways listen and transmit, its not like wifi

noebl1 · September 26, 2021, 10:39pm

Fair enough and I get that. Regardless while several other devices are working fine hitting my gateway, these Cubecell’s for whatever reason are not using the same antennas, same location (have tried closer.) There’s no other gateways in this region within range, so this is the only one it’s able to reach.

Going to work to get some log info from the gateway, but most of the time I don’t even see a join message… It’s really strange.

jezd · September 27, 2021, 10:35am

Are you getting join requests on the gateway?

noebl1 · October 1, 2021, 11:31am

Only occasionally am I seeing Accept join-request in the TTN console. Watching the output for the Cubecells, I can see the transmit frequencies look correct for TTN US915. After it transmits, I can see it receiving on the correct frequencies as well waiting for a response.

I double checked the gateway and the frequencies look correct for US915. I also got a new Dragino LSN50v2 this week for a project, and it’s working quite reliably as well so believe my local gateway is working correctly unless I am missing something glaring.

EDIT: When I say occasionally, I mean like 1 out of maybe 40+ TX on the Cubecell side for it’s debug out on average happen before I see an accept join show up in the logs.

noebl1 · October 24, 2021, 5:46pm

Update on this, thinking it may be a receiving issue based on antenna location. My only reachable gateway in my area is in my attic at the opposite end of the house. When working in my office, the Cubecell’s have to go through several walls to eventually reach that antenna. In addition to that, I need to look at the gateway’s antenna pattern for reception. It’s very possible since I am below it by a bit, I may be in a dead spot for the monopole I got for 900mhz. Reason I suspect this is when testing inside and outside on my deck, I’ve basically been under the gateway’s antenna. I picked up one of the TTN indoor gateways, and in “close” proximity to it, have had no issues with the Cubecells reaching 100% of the time. I think to really test it, I need to get back outside a bit more a distance from the attic gateway where another working unit is. The other possibility is something isn’t quite right with my Rakwireless Pi based gateway, however other devices are working fine, so I don’t believe it’s that (but not impossible).