@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.
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.
@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):
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
I have my doubts whether I did all of that myself at that time, especially the FILTER= .. expression.
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.
"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