@robert-hh So a remote raw lora receiver with a lot of nodes sending it is just inevitable that collisions happen? My current "solution" is to send and wait for it to send back an acknowledge, if not just wait a random period of time.

@obladio I'm not sure if the Raspberry Pi code works in the current form, it's been a while since I tried it - almost as long as that code has been sitting there unchanged (1 1/2 years) but maybe it does. I do know downlinks are not supported at all in that code which is what TTN is really annoyed about - in the past gateways without downlinks were blocked from participating in TTN https://www.thethingsnetwork.org/forum/t/resolved-some-single-channel-gateways-stopped-working/6529 and https://www.thethingsnetwork.org/forum/t/the-future-of-single-channel-gateways/6590/72 I'd recommend using a single channel gateway which supports downlinks, such as the LoPy with nano-gateway code or some of of the suggestions on that 2nd thread I linked. If you want to use the Raspberry Pi code you have I guess you have to do some tests to understand if it's currently working.

@rskoniec Thank You sir

@siejak simple use e.g.: try: s.send(data) except: connectToRouter()

@nilam Just to be pedantic, I simplified hexdump a bit. This is old code, collected when I started with Python. FILTER=''.join([(len(repr(chr(x)))==3) and chr(x) or '.' for x in range(256)]) def hexdump(src, length=16): N=0; result='' while src: # loop through string s,src = src[:length],src[length:] hexa = ' '.join(["%02X"%x for x in s]) s = ''.join([FILTER[_] for _ in s]) result += "%04X %-*s %s\n" % (N, length*3, hexa, s) N += length return result I have my doubts whether I did all of that myself at that time, especially the FILTER= .. expression.

@jcaron Hi Jcaron, Thanks for your explaination. We'll make te intervals longer so that we don't breach the regulations. I understand what your saying, but could you describe how you calcluate the collision rate? The strange thing is, that almost every time it is a single node who is not recieved well by the gateway. Not always two nodes at the same time. They are indeed close to each other, but we're now testing it with one node, to see how that works. We'll add a random interval. I'll post if this changes solved our problem.

@jmarcelino said in US915 OTAA - Cannot communicate with packet forwarder: LoRaWAN network server Hi @jmarcelino. Thanks for your help. I'm using the brocaar's one network server https://www.loraserver.io/ I have copied below the docker-compose config file content: version: "2" services: app: build: . expose: - "8090" ports: - "8090:8090" volumes: - .:/app depends_on: - gatewaybridge - loraserver - appserver - postgres - mosquitto - redis postgres: image: library/postgres:10.2 volumes: - ./db/pgdata:/pgdata ports: - "54322:5432" environment: - POSTGRES_PASSWORD=loraserver - POSTGRES_USER=loraserver - POSTGRES_DB=loraserver - PGDATA=/pgdata command: -p 5432 elasticsearch: image: elasticsearch:2.4 container_name: elasticsearch environment: - cluster.name=docker-cluster - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" ulimits: memlock: soft: -1 hard: -1 mem_limit: 1g volumes: - esdata1:/usr/share/elasticsearch/data ports: - 9200:9200 # # STARTS BROCAAR SERVERS # loraserver: image: loraserver/loraserver environment: - DB_AUTOMIGRATE=true - LOG_NODE_FRAMES=true - NET_ID=010203 - BAND=US_902_928 - REDIS_URL=redis://redis:6379 - GW_MQTT_SERVER=tcp://mosquitto:1883 - GW_SERVER_JWT_SECRET=verysecret - POSTGRES_DSN=postgres://loraserver_ns:loraserver_ns@postgresql_ns/loraserver_ns?sslmode=disable - JS_SERVER=http://appserver:8003 appserver: image: loraserver/lora-app-server ports: - 8080:8080 environment: - DB_AUTOMIGRATE=true - REDIS_URL=redis://redis:6379 - POSTGRES_DSN=postgres://loraserver_as:loraserver_as@postgresql_as/loraserver_as?sslmode=disable - MQTT_SERVER=tcp://mosquitto:1883 - JWT_SECRET=verysecret - HTTP_TLS_CERT=/etc/lora-app-server/certs/http.pem - HTTP_TLS_KEY=/etc/lora-app-server/certs/http-key.pem - AS_PUBLIC_SERVER=appserver:8001 gatewaybridge: ports: - 1700:1700/udp image: loraserver/lora-gateway-bridge environment: - MQTT_SERVER=tcp://mosquitto:1883 postgresql_ns: image: postgres:9.6-alpine ports: - 5432 environment: - POSTGRES_PASSWORD=loraserver_ns - POSTGRES_USER=loraserver_ns - POSTGRES_DB=loraserver_ns postgresql_as: image: postgres:9.6-alpine ports: - 5432 environment: - POSTGRES_PASSWORD=loraserver_as - POSTGRES_USER=loraserver_as - POSTGRES_DB=loraserver_as redis: ports: - 6379 image: redis:4-alpine mosquitto: ports: - 1883:1883 image: eclipse-mosquitto volumes: esdata1: driver: local Then, once the docker servers are running I config the lorawan platform through the web admin ui like this: [image: 1521381818589-screenshot-from-2018-03-18-11-00-47-resized.png] Device profile [image: 1521381870928-screenshot-from-2018-03-18-11-04-07-resized.png] Service profile [image: 1521381909551-screenshot-from-2018-03-18-11-05-00-resized.png] Gateway configuration [image: 1521381946945-screenshot-from-2018-03-18-11-05-28-resized.png] Not sure if that's enough @jmarcelino . Let me know if you need some extra data. Thanks!

@robert-hh There is a PR for that to fix the issue OK, thank you for the heads up

@jmarcelino Thanks, it works!

Wow. This is really a great debugging technique @robert-hh :)

@bmarkus said in LoRaWAN default channel allocations: Maybe I'm wrong, I do not have a live US environment here, but what is the default LoPy US channel allocation? I'm not saying it is wrong, just how to get it? The LoPy US915 channel allocation comes from the same place as the EU 868 channel allocation, the official LoRaWAN Regional Parameters specification published by the LoRa Alliance "2.2.2 US902-928 Channel Frequencies The 915 MHz ISM Band shall be divided into the following channel plans. Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from DR0 to DR3, using coding rate 4/5, starting at 902.3 MHz and incrementing linearly by 200 kHz to 914.9 MHz Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR4 starting at 903.0 MHz and incrementing linearly by 1.6 MHz to 914.2 MHz" so you get: channel 0: 902300 kHz dr: 0-3 channel 1: 902500 kHz dr: 0-3 channel 2: 902700 kHz dr: 0-3 channel 3: 902900 kHz dr: 0-3 ... and so on until channel 71: channel 71: 914200 kHz dr: 4