Im really enjoing using this well supported project!
I set up a 8 channel gateway and logged all packets received at my urban location for 24 hrs to see any trends in channel activity.
I found that TTN channel 0 - 868.100 and SF 8 were by far the most active.
This brings up two questions for me;
I thought that idea of using many frequencies in a system was to reduce collisions and therefor increase goodput, so why is there not an even spread of packets across channels and spreading factors being seen at my gateway? It this typical?
If this is typical, would it be smart to avoid these channels/SF when I deploy my private chirpstack network?
“The network channels can be freely attributed by the network operator.However,the three following default channels SHALL be implemented in every EU868MHzend-device. Those channels are the minimum set that all network gatewaysSHALLbe listening on.”
It means that for EU868 end-devices, they must implement at least those 3 frequencies for transmiting.
Apart from that you have two different things:
Which frequencies your device transmit through.
At least they will transmit to 868.1, 868.3 and 868.5.
Apart from those they usually transmit throught some other frequencies, usually but not mandatory are 867.1, 867.3, 867.5, 867.7 and 867.9
Which frequencies your Network Server is listening to.
At least 868.1, 868.3 and 868.5.
If you use the default config of Network Server it is also listening to 867.1, 867.3, 867.5, 867.7 and 867.9
I found some end-devices that only had 868.1, 868.3 and 868.5 frequencies available, perhaps it is your case.
Did you find some 867.1, 867.3, 867.5, 867.7 and 867.9 transmisions?
HI, Yes I realise what it means. And my devices are set that way.
Back to my original post:
I am seeing that a very large number of packets arriving at my gateway are on 868.100 SF8.
My question is what the reason to design Lorawan like this?
Surly it would be “better” for all devices to use as many different channels as possible to reduce collisions and gain full frequency diversity?
Are the 3 channels 868.1/3/5 legacy from a time when the other frequencies were not allowed?
Yes I did see packets on other frequencies but not very many, they are concentrated on 868.100 MHz.
Thanks Chopman, interesting study.
Well my conclusion is that there appears to be no reason to actually use Channels 0,1,2 except in the case where end-devices are joined to a system but there is no possibility to program them to be setup on using other frequencies and there not be co-ordination between system operator and end-node integrator.
In my case, I will surely aim for a system and end-node which make maximum usage of the ISM EU868 band as per Etsi requirements but perhaps not restrict myself to the LoraWan Alliance spec.
The 0,1,2 Channel are “just needed” on first join with OTAA. If you use ABP you can setup your frequencies however you want (if I remember correctly). After that the devices gets new channel information. So it might get crowded in the first 3 - after that not so much - depending on the frequencies you setup for your network.
Hi Chopman, I see your point.
So if there are a many end-devices doing OTAA joins, often, then we have a little over-crowding on these channels… Perhaps an explanation for the channel activity Im seeing here?
Better designed end-devices, (power cycling/deep sleep, wake-up+OTAA joins etc) could make these channels less heavily used perhaps.
Well designed devices have, pseudo-random channel hopping and might even come with Listen-before-Talk. It’s not just the devices themselves who need to comply with the regulations, the gateways are so to speak devices (from the regulators point of view) and have the same restrictions on duty cycle.
I see chirpstack has gateway ping
So yeah, we also could have 868.100 being loaded up with gateway proprietary frames as well!
Right, well im staying off that channel for my system, cant see the point of using a frequency at a higher risk of collisions.
Happy frequency hopping!
Looking at my LMIC device today, (MCCI LMIC lib) it just cycles through the frequencies, not random.If you were really unlucky you could have to end-devices cycling through the same list of frequencies at the same time…oops
@subgig I’d recommend you to stick to the “defaults” first. Measure if there is significant packet-collision and move your channels accordingly. You’ll be playing a whack-a-mole game if you have no infrastructure to infer/count packet collisions. They are public bands, so not only LoRa traffic is going to affect you. You might get really unlucky and find/setup a band already heavily used by “someone” else.