AB-02 node can not join M-02 gateway in US915

ubicaware · January 10, 2021, 8:12pm

Hello there, and thanks on your attention.

I am trying to connect a HTTC-AB02 to TTN as a node, using a M-02 gateway, in the US915 space.

I can see the gateway and the device in TTN console, however I can not see the sample data sent; the ab02 display just shows “Joining”, and I can see from the serial port that there is a timeout waiting for an answer.

In the gateway packet logger, I can see that the packet is received and the gateway accepts the join; however, this is sent over 869.525 frequency, which is out of the space for US 915.

Also, I would like to know the correct masking for 0-15 channels on this space. Is there any doc where this masking is explained in detail?

I have tried to use the US915 as well as the US915-Hybrid setting on the AB02. The M-02 is configured to use band US915, channels 0-15.

Any leads on what may be wrong?

Serial log from the AB-02 (private information edited out):

13:28:53.297 -> Copyright @2019-2020 Heltec Automation.All rights reserved.
13:28:55.748 ->
13:28:55.748 -> AT Rev 1.1
13:28:55.748 -> +AutoLPM=1
13:28:55.748 ->
13:28:55.748 -> +LORAWAN=1
13:28:55.748 ->
13:28:55.748 -> +KeepNet=0
13:28:55.748 -> +OTAA=1
13:28:55.748 -> +Class=A
13:28:55.748 -> +ADR=1
13:28:55.748 -> +IsTxConfirmed=1
13:28:55.748 -> +AppPort=2
13:28:55.748 -> +DutyCycle=600000
13:28:55.748 -> +ConfirmedNbTrials=4
13:28:55.748 -> +ChMask=00000000000000000000FF00
13:28:55.748 -> +DevEui=008AXXXXXXXXF1DB(For OTAA Mode)
13:28:55.748 -> +AppEui=70B3XXXXXXXXB33B(For OTAA Mode)
13:28:55.781 -> +AppKey=CBXXXXXXXXXXXXXXXXXXXXXXXX6E(For OTAA Mode)
13:28:55.781 -> +NwkSKey=XXXXXXXXXXXXXXXX(For ABP Mode)
13:28:55.781 -> +AppSKey=XXXXXXXXXXXXXXXX(For ABP Mode)
13:28:55.781 -> +DevAddr=XXXXXXX(For ABP Mode)
13:28:55.781 ->
13:28:55.781 ->
13:28:55.781 -> LoRaWAN US915 Class A start!
13:28:55.781 ->
13:28:55.949 -> joining…TX on freq 904900000 Hz at DR 3 power 20 dBm
13:28:56.015 -> Event : Tx Done
13:29:01.019 -> RX on freq 926300000 Hz at DR 13
13:29:01.051 -> Event : Rx Timeout
13:29:02.020 -> RX on freq 923300000 Hz at DR 8
13:29:02.086 -> Event : Rx Timeout
13:29:02.954 -> TX on freq 903900000 Hz at DR 0 power 20 dBm
13:29:03.384 -> Event : Tx Done
13:29:08.390 -> RX on freq 923300000 Hz at DR 10
13:29:08.423 -> Event : Rx Timeout
13:29:09.383 -> RX on freq 923300000 Hz at DR 8
13:29:09.450 -> Event : Rx Timeout
13:29:09.982 -> TX on freq 904500000 Hz at DR 3 power 20 dBm
13:29:10.049 -> Event : Tx Done
13:29:15.052 -> RX on freq 925100000 Hz at DR 13
13:29:15.085 -> Event : Rx Timeout
13:29:16.097 -> RX on freq 923300000 Hz at DR 8
13:29:16.130 -> Event : Rx Timeout
13:29:16.991 -> TX on freq 904700000 Hz at DR 0 power 20 dBm
13:29:17.423 -> Event : Tx Done
13:29:22.426 -> RX on freq 925700000 Hz at DR 10
13:29:22.460 -> Event : Rx Timeout
13:29:23.421 -> RX on freq 923300000 Hz at DR 8
13:29:23.487 -> Event : Rx Timeout
13:29:24.017 -> TX on freq 905100000 Hz at DR 3 power 20 dBm
13:29:24.084 -> Event : Tx Done
13:29:29.092 -> RX on freq 926900000 Hz at DR 13
13:29:29.125 -> Event : Rx Timeout
13:29:30.086 -> RX on freq 923300000 Hz at DR 8
13:29:30.152 -> Event : Rx Timeout
13:29:31.046 -> TX on freq 905300000 Hz at DR 0 power 20 dBm
13:29:31.477 -> Event : Tx Done
13:29:36.448 -> RX on freq 927500000 Hz at DR 10
13:29:36.481 -> Event : Rx Timeout
13:29:37.475 -> RX on freq 923300000 Hz at DR 8
13:29:37.508 -> Event : Rx Timeout
13:29:38.038 -> TX on freq 904100000 Hz at DR 3 power 20 dBm
13:29:38.138 -> Event : Tx Done
13:29:43.113 -> RX on freq 923900000 Hz at DR 13
13:29:43.179 -> Event : Rx Timeout
13:29:44.140 -> RX on freq 923300000 Hz at DR 8
13:29:44.206 -> Event : Rx Timeout
13:29:45.068 -> TX on freq 904300000 Hz at DR 0 power 20 dBm
13:29:45.499 -> Event : Tx Done
13:29:50.503 -> RX on freq 924500000 Hz at DR 10
13:29:50.536 -> Event : Rx Timeout
13:29:51.496 -> RX on freq 923300000 Hz at DR 8
13:29:51.565 -> Event : Rx Timeout
13:29:52.096 -> TX on freq 904900000 Hz at DR 3 power 20 dBm
13:29:52.162 -> Event : Tx Done
13:29:57.165 -> RX on freq 926300000 Hz at DR 13
13:29:57.198 -> Event : Rx Timeout
13:29:58.159 -> RX on freq 923300000 Hz at DR 8
13:29:58.228 -> Event : Rx Timeout
13:29:59.120 -> TX on freq 904500000 Hz at DR 0 power 20 dBm
13:29:59.550 -> Event : Tx Done
13:30:04.528 -> RX on freq 925100000 Hz at DR 10
13:30:04.561 -> Event : Rx Timeout
13:30:05.557 -> RX on freq 923300000 Hz at DR 8
13:30:05.590 -> Event : Rx Timeout
13:30:06.122 -> TX on freq 904700000 Hz at DR 3 power 20 dBm
13:30:06.188 -> Event : Tx Done
13:30:11.193 -> RX on freq 925700000 Hz at DR 13
13:30:11.227 -> Event : Rx Timeout
13:30:12.221 -> RX on freq 923300000 Hz at DR 8
13:30:12.254 -> Event : Rx Timeout
13:30:13.148 -> TX on freq 903900000 Hz at DR 0 power 20 dBm
13:30:13.579 -> Event : Tx Done
13:30:18.551 -> RX on freq 923300000 Hz at DR 10
13:30:18.618 -> Event : Rx Timeout
13:30:19.578 -> RX on freq 923300000 Hz at DR 8
13:30:19.645 -> Event : Rx Timeout

Here the packet log from the M-02 -please note the frequency of the Join Accept packets:

Mtype Time Freq Rssi SNR CRC Mode Code Data CNT

Join Accept 13:30:18 869.525 NO_CRC LORA 4/5 SF12BW125
Join Request 13:30:13 903.9 -21 9.2 CRC_OK LORA 4/5 SF10BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Accept 13:30:11 869.525 NO_CRC LORA 4/5 SF12BW125
Join Request 13:30:06 904.7 22 10.2CRC_OK LORA 4/5 SF7BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Request 13:29:59 904.5 -18 9 CRC_OK LORA 4/5 SF10BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Request 13:29:52 904.9 -21 8.8 CRC_OK LORA 4/5 SF7BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Request 13:29:45 904.3 -20 7 CRC_OK LORA 4/5 SF10BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Accept 13:29:43 869.525 NO_CRC LORA 4/5 SF12BW125
Join Request 13:29:38 904.1 -25 9.5 CRC_OK LORA 4/5 SF7BW125A AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Accept 13:29:36 869.525 NO_CRC LORA 4/5 SF12BW125
Join Request 13:29:31 905.3 -21 8.5 CRC_OK LORA 4/5 SF10BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Accept 13:29:22 869.525 NO_CRC LORA 4/5 SF12BW125
Join Request 13:29:17 904.7 -21 8.8 CRC_OK LORA 4/5 SF10BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Request 13:29:03 903.9 -20 6.5 CRC_OK LORA 4/5 SF10BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB
Join Request 13:28:56 904.9 -20 8 CRC_OK LORA 4/5 SF7BW125 AppEUI 70 B3 XX XX XX XX B3 3B DevEUI 00 8A XX XX XX XX F1 DB

Current channel mask:

/LoraWan channelsmask, default channels 0-7/
// Changed { 0x00FF to { 0xFF00 as per MrPhisch’s suggestion (heltec forum, cubecell + ttn + us915)
uint16_t userChannelsMask[6]={ 0xFF00,0x0000,0x0000,0x0000,0x0000,0x0000 };

jasonXu · January 11, 2021, 4:06am

hi,

what is your M02 version? POE or 4G/LTE.

And could you refer this docs?
https://heltec-automation-docs.readthedocs.io/en/latest/gateway/ht-m00/connect_to_gateway.html

ubicaware · January 11, 2021, 4:52pm

Hello, Jason.

The M02 is the POE version.

Thanks on the link. I have read it before, and tried:

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

In order to use the second segment (i.e., channels 16-31) but apparently it keep trying to use channels in the 0-15 segment. Is that correct, or is there something else to change?

jasonXu · January 12, 2021, 7:53am

hi,

Are you modfied these?

BTW, This is to open the 16-31 channel.
uint16_t userChannelsMask[6]={ 0x0000,0xFFFF,0x0000,0x0000,0x0000,0x0000 };

Your code is to open channels 16-23.

ubicaware · January 12, 2021, 5:50pm

Yes, I have modified the gateway parameters. It is connecting to TTN server, and is correctly connecting there.
I have tried to change the channel bank because I can not connect, as described in the initial post; so I changed the configuration in the gateway to use the 16-31 bank, and changed the channel on the node as well. But it did not work, the node still can not join, see attached image.

The Gateway is configured using band US-915, Channels 16-31, Custom server linked to TTN. Here is part of the configuration for the node with LORAWAN_REGION=“REGION_US915”:

// OTAA 63XXXXXXX23
uint8_t devEui[] = { 0x00, 0x8a, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx };
uint8_t appEui[] = { 0x70, 0xb3, 0xxx, 0xxx, 0xxx, 0xxx, 0xb3, 0x3b };
uint8_t appKey[] = { 0xx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx, 0xxx };

/LoraWan channelsmask, default channels 0-7/
uint16_t userChannelsMask[6]={ 0x0000,0xFFFF,0x0000,0x0000,0x0000,0x0000 };

/LoraWan region, select in arduino IDE tools/
LoRaMacRegion_t loraWanRegion = ACTIVE_REGION;

jasonXu · January 14, 2021, 7:43am

hi,

At present, it is not easy to confirm the problem.

could you try the Internal server with the HT-M02?

ubicaware · January 14, 2021, 6:13pm

I think that the problem is that the gateway is trying to accept the join request over a frequency that is not part of the US915 plan.

We have tried using the internal server -as a matter of fact it was the very first try- and the gateway did not accept the join requests. I have restored the configuration to the one we used before, and tried. By the way, we have a lot of questions regarding the configuration of the internal server. Is it ok if I open a new thread to discuss that? Anyway, next is a packet log:

Join Request 10:45:13 902.3 -15 11.5 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:45:06 903.1 -17 9.5 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:59 903.5 -17 11.5 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:52 902.7 -13 7.2 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:45 903.7 -16 9.8 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:37 902.9 -16 10.5 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:34 903.3 -17 9.8 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:23 903.3 -17 9.8 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:17 902.9 -15 11.2 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:09 903.1 -17 10 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:44:03 903.7 -13 8.2 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:43:55 902.3 -15 8.5 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:43:49 902.5 -14 11.2 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:43:41 902.7 -14 7.2 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:43:35 903.5 -16 12 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:43:27 903.3 -17 9.5 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:42:51 902.3 -16 10 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:42:43 902.7 -15 7.2 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:42:37 903.7 -16 8.2 CRC_OK LORA ‘4/5’ SF10BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B
Join Request 10:42:29 902.5 -13 8.8 CRC_OK LORA ‘4/5’ SF7BW125 AppEUI70 B3 XX XX XX XX B3 3B DevEUI 21 5B XX XX XX XX 25 1B

At some point, we were able to join the network (with a very specific combination of the channels used and unconfirmed sends, I will update as soon I am able to recreate the situation), but were very stuck trying to upload the data to our database. Since it would not work to us using unconfirmed sends, we moved to try using our own server (based on ChirpStack), TTN and/or your cloud service.

I do not know if it would be relevant to the situation, but we have succesfully set a node using ABP with unconfirmed Tx, to either TTH or your cloud server; in this configuration, we sporadically see successful transmissions from the GW to the node, but those are using frequencies with the US915 plan.

ubicaware · January 14, 2021, 6:33pm

Well, that was actually much more easy that I envisioned.

The node is configured using US915, and the following Channel Mask:

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

Please note that changing the mask to any higher value will result on the node not joining, even when the gateway settings are changed to reflect that; i.e. a mask like

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

would not work even if the M2 channel bank is setted as 16-31, and neither would

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

with the M2 setted in the 0-15 bank.

Join Accept,12:14:27,923.3,CRC,LORA,‘4/5’,SF7BW500
Join Request,12:14:27,902.3,-14,8.8,CRC_OK,LORA,‘4/5’,SF7BW125,AppEUI 70 B3 XX XX XX XX B3 3B,DevEUI 00 8A AB CB 8B 05 F1 DB

In this configuration, however, I am not able to see the payload, nor is the internal server reporting it to my API, and we have observed that the last seen timestamp does not make any sense; this screenshot is from a minutes ago, after the node correctly joined the network, as per the log.

jasonXu · January 15, 2021, 9:32am

please refer the picture

ubicaware · January 15, 2021, 5:45pm

Here is the Gateway Configuration screen:

From this page, I click in the LoRa Application menu, then I clink on my application, and I got this screen:

From here, I would suppose that clicking on the devEUI would take me to a screen like you showed, but I get this:
GwAppDEUI

So, no way to see the data from the device… Will continue on another post.

ubicaware · January 15, 2021, 5:57pm

Under the current configuration, using the internal server as per your suggestion, we have to use the following mask:
uint16_t userChannelsMask[6]={ 0x001F,0x0000,0x0000,0x0000,0x0000,0x0000 };

as well as unconfirmed Tx, because using confirmed Tx will often result on a helluva of retransmits; I’ll annex a packet log if you need it.

That being said, the original problem still subsists: I can not join a network using an external server because somehow the GW accepts the join request over a channel in the 869.925 frequency, out of the space for the plan intended.

ubicaware · February 21, 2021, 4:50pm

Hello there. After this standstill, I am hoping to retake this issue in a expeditious manner.

As a summary of the situation: M-02 POE gateway, will work correctly using the internal server, but when using TTN or a private chirpstack server, it will answer a join request in a channel outside the US915 space, as per the initial post.

Trying to work around this, I have addtional questions regarding the configuration of the internal server, that I will express on other post.

jasonXu · February 22, 2021, 10:44am

We have not encountered such a problem before (including the feedback from our own customers). Could you check your servers’ config?

We have the 4G version HT-M02 gateway. It can only use external servers, We didn’t also get such feedback.

ubicaware · February 25, 2021, 1:25am

Configuration is as shown before.

I will add that one of the gateways we are working with has a slight difference in presentation, as shown in the image:

I am referring to the fact that in this gateway the selection box for Channels shows the range for downlink channels as well as the uplink channels (i.e. “Channels 0-15, 64, 65”, instead of the simple “Channels 0-15” on the other gateway). This particular M02 is working OK, and so I believe there must be some issue with that particular software version.

I am in the process of making an image based on the working gateway, as the image we have (downloaded from https://resource.heltec.cn/download/HT-M02/firmware/heltec-M02-POE-debian-v4.img) looks exactly like the first example -and it has the same problem. Anyway, I would be quite grateful if you point me to the factory image for this very particular version of the gateway. Of course I am at your service if you need any additional information regarding this issue.

jasonXu · February 25, 2021, 2:03am

hi,

we have updated the firmware. you can Perform a firmware update.
%E5%9B%BE%E7%89%87
https://resource.heltec.cn/download/HT-M02/firmware

ubicaware · February 26, 2021, 4:01pm

That is working now, thank you very much.