US915 Tx default Power

Hi.

I am trying US915 and an odd thing is happening

I read that the default TxPower for US915 is 20: https://github.com/brocaar/lorawan/blob/master/band/band_us902_928.go

But seems to not be working:
imagen
imagen
imagen

Thanks

EDIT: It could be a problem with my gateway (RisingHF). As it seems that its not sending downlinks either

Another weird thing:
imagen

Seems to not be using the correct downlink channels

So it seems to be working now.
I killed everything and restarted the server. Still needs to test if everything is working fine

Have 2 servers now EU868 and US915
I don’t know why US915 was trying to use EU868 configuration

imagen

Happens again.

GW: RHF2S008
Module : RHF76-052
Never had a problem with EU868

Does anyone managed to have EU868 and US915 together?
Docker-compose file:

version: "2"

 services:
   loraserver:
     image: loraserver/loraserver
     restart: always
     volumes:
       - ${PWD}/volumes/loraserver/config_01:/etc/loraserver

   loraserver_us:
     image: loraserver/loraserver
     restart: always
     volumes:
       - ${PWD}/volumes/loraserver/config_us_01:/etc/loraserver

   appserver:
     image: loraserver/lora-app-server
     restart: always
     ports:
       - 8080:8080
     volumes:
       - ${PWD}/volumes/lora_app/certs:/etc/lora-app-server/certs
       - ${PWD}/volumes/lora_app/config:/etc/lora-app-server

   gatewaybridge:
     ports:
       - 1700:1700/udp
     image: loraserver/lora-gateway-bridge
     restart: always
     volumes:
       - ${PWD}/volumes/gw_bridge/config:/etc/lora-gateway-bridge

   postgresql_ns:
     image: postgres:9.6-alpine
     restart: always
     ports:
       - 5432
     environment:
       - POSTGRES_PASSWORD=loraserver_ns
       - POSTGRES_USER=loraserver_ns
       - POSTGRES_DB=loraserver_ns

   postgresql_ns_us:
     image: postgres:9.6-alpine
     restart: always
     ports:
 - 5432
     environment:
       - POSTGRES_PASSWORD=loraserver_ns
       - POSTGRES_USER=loraserver_ns
       - POSTGRES_DB=loraserver_ns

   postgresql_as:
     image: postgres:9.6-alpine
     restart: always
     ports:
       - 5432
     environment:
       - POSTGRES_PASSWORD=loraserver_as
       - POSTGRES_USER=loraserver_as
       - POSTGRES_DB=loraserver_as

   redis:
     restart: always
     ports:
       - 6379
     image: redis:4-alpine

   mosquitto:
     restart: always
     ports:
       - 32797:1883
       - 32798:1884
     image: eclipse-mosquitto
     volumes:
       - ${PWD}/volumes/mosquitto/config:/mosquitto/config

Forget it seems to work odd anyway.

Seems to be something from config. If I stop EU868 server everything seems to be working fine.

I see some error in log. And did see something strange:

868 device entering through an 868 gateway that is not configured in appserver. Gateway bridge delivers package to both server EU868 and US915. US915 sees the package and decides to upload the 868 device to appserver. This seems kind of odd, considering that the gateway 868 is not configured.

Do I need 2 gateway_bridges with different mqtt publish configuration for each server/band?

Please note that in both LoRa Server and LoRa Gateway Bridge you can configure the MQTT topics. I recommend you to prefix them with the region :slight_smile: Thus eu868/gateway/... and us915/gateway/... that way you can still use one MQTT broker, but you do need two LoRa Gateway Bridge instances (or you install it on each gateway).

1 Like

Got news, deleted everything and restarted all the dockers components.

Now seems to be working, but I have some troubles with my LoRa modules and US915 they keep restarting after first messages, it is a module fault.

Thanks.

Keeps happening.

Now is happening every time I move the device between applications. Seems that when I delete a device the device is not properly flushed and the activations persist. Example

Deleted an activated device
Create it again (OTAA)
Messages keep coming and are valid lora-app-server consider that devices are NOT activated but keep forwarding them.
Delete device again.
Create it in another server (915)
Messages keep coming even they are from another server. Download messages not forwarded because frequencies are not valid.

So it seems a bad idea to “move” devices between applications before flushes are made

I’ve created a ticket to keep track of this issue. I need to investigate this: https://github.com/brocaar/loraserver/issues/321.

1 Like

You were right, a device-session was not flushed on deleting a device. This has been fixed, see:

1 Like

That was fast.
Thanks!

Hi fma. Please your answer, do you receive the data of two frequencies with the same antenna?