India, as per your previous post, lists three frequencies and the Dragino documentation doesn’t mention supporting the India plan. Getting the gateway to listen to frequencies you shouldn’t be transmitting on seems to be the wrong way round.
Good sir,
The Dragino LSN50 v2 page lists IN865 frequency.
It is already configured to transmit on 8 channels between 865 MHz to 867 MHz.
865 MHz to 867 MHz is legal in India. I can use any frequency between 865 to 867.
I am not doing anything illegal here. I am following my country’s law, I obviously don’t want to land in any trouble.
And the Dragino LSN50 v2 is already transmitting on the following three frequencies:
- 865.0625
- 865.4025
- 865.9850
I can see them on the RAK2245. It is receiving the Dragino LSN50 v2’s data on the above frequencies.
But I also want the RAK2245 to listen to the below frequencies:
- 865.6025
- 866.1850
- 866.3850
- 866.5850
- 866.7850
All of them, are between 865 to 867 MHz.
So again, there is nothing illegal I am doing here. I can do anything I want between 865 to 867 MHz.
Perhaps you can ask Dragino for a suitable global_conf.json for the custom frequency plan they have dreamed up, since what you are configuring here is the SX1301/SX1308 chip that everyone uses, not any aspect of the rest of the gateway that differs by brand.
Or else evolve the existing one a single change at a time, making sure to check the packet forwarder log for errors and making sure you still get packets at the standard frequencies after each change.
Well, yes, I could do that but my supplier said,
As my application will have more than 10 nodes, there is a chance of data loss and these are going to be used in the industry so there will be a lot of interference from other devices and machinery in the factories so it’s better to make the gateway listen to more frequencies.
The RAK2245 is a 8 channel gateway. I am trying to make it a 8 channel gateway by editing the config. I am failing to do so.
If you don’t want me to use it in 8 channel mode, why even advertise it as an 8 channel gateway?
That’s all quite misleading. 10 nodes is a truly tiny network, which in no way requires more than 3 frequencies.
The types of interference sources you mention aren’t likely to affect LoRa much, and not in a frequency unique way…
This is basically a bunch of “we don’t want to help you” false-excuse hand waving.
The helpful thing for your supplier to do would be to either
a) tell you how to configure the node for a standard band plan
or
b) tell you how they suggest you configure the IF’s and offsets of the standard SX130x chip (same as used in their own actual gateways) for the unique bandplan they have chosen.
If you don’t want me to use it in 8 channel mode, why even advertise it as an 8 channel gateway?
It works just fine for 8 channels in the situations where the agreed upon band plan has 8 channels. It could support 8 appropriately chosen custom channels in other situations as well, but it’s up to the person choosing the channels to do so with consideration to how that channel plan is going to map onto the capabilities of an SX130x
This is a problem of Dragino’s creation, so the solution should be up to them.
Note additionally that a non-standard band plan is probably not going to work with the TTN servers - they are likely to be confused in how to respond to uplinks on non-standard frequencies. And they’re likely to try to command the node via MAC commands to use only the standard frequencies.
RAK advertise it as an 8 channel gateway because it can do 8 channels. But India has only authorised 3 channels. That’s not RAK’s fault.
And whilst the front page for the Dragino node may say they support IN, their technical documentation has the option of only one frequency or the frequencies for US, AU & CN.
LoRaWAN is pretty robust, but it is not designed for 100% guaranteed delivery. Using very rough maths, if transmissions are ~200ms, sending every 15 minutes, over three channels, there’s capacity for ~13,500 nodes, but lets assume that half the time they clash, that’s still 6,750.
I had to go look this up, it turns out that the LoRa alliance has only specified three channels as standard but seemingly invited network operators to define additional ones if doing so is legal.
The network channels can be freely attributed by the network operator. However the three following default channels MUST be implemented in every India 865-867MHz end-device. Those channels are the minimum set that all network gateways SHOULD always be listening on.
So what is being attempted may not be illegitimate - but it’s up to the people going beyond the standard to explain how they think their custom scheme should be implemented. OP has a generic SX1301 or SX1308 hanging off a raspberry pi, if the channel plan is sane the people who dreamed it up should be able to tell how to configure the chip to operate it.
And the network server would also have to support the custom scheme…
I don’t get it.
Why does the custom scheme fail?
The RAK2245 listens to:
- 865.0625
- 865.4025
- 865.9850
If I change 865.9850 to 865.9849, the scheme will fail.
Why so?
Has it been hardwired to fail?
Because you’ve incorrectly configured the chip. You cannot simply drop arbitrary numbers in, someone wanting to use a non-standard channel scheme needs to plan out how the parts of the radio receiver are actually going to achieve all of them as small offsets from two tunable IFs.
If I had to guess right now, even apart from the likelihood of not achieve the intended frequencies, I’d suspect that packet forwarder is rejecting your configuration file due to some error in it and simply refusing to run at all, but you’ve not seemingly made any attempt to examine the logs and figure out what is going on.
The only “wiring” that applies is in the silicon from Semtech. That is the same for every gateways manufacturer.
So if there is a radio configuration that works in Dragino’s own gateways, that same configuration (or at least the numeric aspect of it) will work here.
How do I check the logs?
All I got was:
ERROR: invalid configuration for Lora multi-SF channel 3
Don’t know what I expected.
Okay, so final question guys,
Is it safe to run a node in single channel mode when there will be 10 devices around? Cause I am having a hard time settings multi-channel mode.
Your IF offsets are out of range. They should be as small as possible, something like +/- 400 KHz may be enforced at some level as a practical limit.
This is what I mean about not being able to put in arbitrary numbers, but needing to actually design how the parts of the hardware will achieve the channel plan as a set of offsets around two IFs.
If Dragino has their node working on their own gateways, then they already have worked out how to implement this channel plan. Ask them for the IF’s and offsets, basically their global_conf.json
Okay, thanks. I will do that.
Oh and I forgot to mention, if I do jumps of 20000 then my configuration gets accepted.
So I did that and it worked, but 1 frequency cannot be achieved with the jumps of 20000.
So I will go contact my supplier and Dragino now.
Much of your problem seems to be that you’re trying to do almost everything with only one of the two IF’s. You probably want to move the 866 MHz channels to the second radio and perhaps increase its tuned frequency towards their middle. But it may not be simple to get that implemented and there may be compromises, so figuring out what the people who dreamed it up went with is likely best for now.
You have three frequencies setup and working on the gateway. If you use single channel mode you can set what frequency the node will be on - so you can allocate three nodes to one frequency, three nodes to another and the final four to the last frequency.
As per the math above, if you have nodes taking 200ms to transmit once every 15 minutes, a single frequency can support 5 x 60 x 15 nodes (=4,500) if by some fantastic co-incidence they are all spread evenly over the 15 minutes.
Even if by some miracle you managed to turn them all on at exactly the same time, they will start to drift within the space of an hour. I have about 10 nodes permanently running spread over my own Arduino + RFM95 thing to a TTN Node to RAK nodes (various) and none of them could be regarded as a precision timebase - just silly little things like which cycle of data acquisition that means the ATmega has to setup a different ADC channel or the temperature of the node all induce nanosecond differences in timing that mean they all show a tiny drift in their precise check-in interval.
If you have yours set over a range of 14 to 16 minutes as my example and you turn them on, you may see the occasional collision in transmission, but it will be very random.
In this scheme, if you look at the logs and see that two nodes are transmitting uncomfortably close together, just cycle the power on one of them.
Alternatively, buy some nodes that support the IN frequency scheme properly.
Thank you @cstratton and @nmcc ,
I did as you suggested and set the nodes onto single channel mode.
It’s working great.
I just hope that by some coincidence the data does not become incorrect, because on its basis I am running another application and it’s purpose will become wrong.
My supplier doesn’t seem to have an idea what offsets and intermediate frequencies are, he replied to by email just by telling me the frequencies.
One final question. From a theoretical point of view, if I have 4 nodes on a single frequency transmitting every 1 minute, what is the change of error? They take about 1.3 seconds to transmit the data.
I most definitely do not and did not recommend single channel operation
My supplier doesn’t seem to have an idea what offsets and intermediate frequencies are, he replied to by email just by telling me the frequencies.
It would seem that your supplier is not really able to support making the product they have designed usable. In particular, they’ve not put you in contact with anyone who actually understands the engineering of its strategy for operation in your country.
Or perhaps they have no actual strategy and just wrote up some code in an afternoon to fulfill a request from the marketing department, without testing it as part of an actual LoRaWAN network.
That part I was referring to @nmcc .
This is a common practice in India. People are running business that they are not really qualified to. But I don’t blame them and they need to run those businesses as the extreme overpopulation has increased the demands for jobs. But yes, at the price of the quality of service / products.
I bought Dragino nodes and they forward all my queries to their Indian supplier (which I don’t want to name because even though they might be unqualified, they are good people and trying their best).
I asked him about the offsets and intermediate frequencies, even sent my config file because he probably is using some other gateway but he just sent me the list of frequencies I was supposed to use which he already gave me.
I don’t think he understood my question.