Implement regional configuration for AS923 MHz ISM Band.

sophiekovalevsky commented 4 years ago

Is this a bug or a feature request?

Neither of both. Contribution.

What did you expect?

Make chirpstack-gateway-os to have predefined AS923 MHz configuration files, so that can gateways using concentrador component can be able to work at aformentioned ISM band region.

What happened?

Currently chirpstack-gateway-os supports EU868, AU915, US915.

What version are your using?

v3.3.0-test.3

Being said that, my initial plan is to bring support to this region at concentrador component level and afterwards generate the corresponding configuration files on network-server and adding the how-to documentation on the oficial site.

This is something that I would be more than excited to contribute to. What are your thoughts?

brocaar commented 4 years ago

This would be great to have! I can provide support where needed :)

The Concentratord does already have this configuration:

https://github.com/brocaar/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1301/src/config/vendor/generic/as923.rs

This is a "generic" configuration, good for testing, but probably not well calibrated for the board your are using. Ideally each vendor (e.g. rak) would have its own directory and then each shield model would have a configuration file in that directory with the calibration specific to that model.

I'm making a few minor changes to the gateway-config.sh script at the moment which I have not yet pushed (will do today or tomorrow). Recently I removed the _gps suffix from the model names and added model_flags to turn on GNSS (GPS) or indicate the module slot (in case of the Conduit). This makes the list of model names more compact :) See also: https://github.com/brocaar/chirpstack-concentratord/commit/2b6feaafb83b2e7b458d9778003b74e6877b18b2

sophiekovalevsky commented 4 years ago

@brocaar I did not check that there was an already implementation. I do only have one single gateway model here that I can test with, then let's see how it goes.

About changes on the gateway-config.sh, no problem it all I don't think it will be able to test it in the upcoming two days or so. Probably I will get laser-focus into this feature at friday or so. In any other case, I will ping you so to coordinate if you are still working on that section of the project.

sophiekovalevsky commented 4 years ago

Hallo @brocaar, I hope you are doing great.

I took this weekend to inspect the code and get familiar with how is that the configuration for the concentrator chips are established within concentradord. While I was reading the code I found that for the calibration of the gateway chips, e.g. ic880a @ 868 MHz, you have use the LUT provided by the vendor. In this matter, aside of having those calibration values, have you measured in real scenarios and verified that actually the obtained values are as expected?

sophiekovalevsky commented 4 years ago

Hi there @brocaar, I hope that you are doing okey in these moments.

Last week I was diving and getting my hands-on in the calibration of the actually gateway that I hava and there are some points that I would like to know your thoughts.

Gateway model used during test: RAK2245 - Pi Hat board V. A

It turns out that there is some discrepancy with official documentation coming from RAKWireless resulting in not having a clear path to follow. During my research, these following resources were found:

RAK2245-RAK831-LoRaGateway-RPi-Raspbian-OS This configuration seems that has not been updated since a while. Furthermore, it's the only file that contains LUT in that repo and it's not region specific though.
Global configuration for AS 923 at RAK Common for Gateway This one looks quite updated over the last months however, during my tests I didn't get same results (asumming that I've replicated the experiment within same conditions).
Transmitter RF Characteristics These parameters are completely different from what it is in 2, besides that there is no detailed explanation about how these values were obtained, nevertheless, these ones make more sense to me and while testing, results were quite similar.

Measurements were made at T ~ 25 C, Vdd ~ 5 V @ 2 A, BW: 125 kHz, SF: 7 @ 923.2 MHz using a continuous wave transmission. Concentrator Chip: SX1301 (FPGA included: not sure at the time being) Radios connected to concentrator chip: Both SX1257

The following table represents gains applied at each stage of the rain chain along with their corresponding power level provided by RAK and the ones that I found during measurements.	PA Gain	Mix Gain	Dig Gain	Tx Power by RAK (dBm)
0	8	6	-6	-5
0	10	0	-3	-3
0	14	0	0	1
1	9	0	4	2
1	8	0	8	5
1	9	0	10	8
1	11	0	12	11
1	12	0	14	13
1	13	0	16	14
2	12	0	17	18
2	13	0	19	19
2	14	0	20	20
3	10	0	0 (Probably mistaken)	24
3	11	0	0 (Probably mistaken)	25
3	12	0	25	27
3	13	0	26	27
3	14	0	27	28

Based on these, the following questions arises:

Can we move forward with this calibration knowning that RAK225 Pi Hat has been tested to be comply with spectrum regulations? About AS923, AFAIK the maximum EIRP is 16 dBm.
How do we take into consideration the antenna gain? I've seen that when you acquired a RAK2245 PiHat you can use several antennas provided by RAKWireless and hence the antenna gain will be different e.g. here and here. Beng said, we will assume that end user knows the implications of using antenna gain and must provide this value to reduce the actual EIRP and not exceed the maximum limit.

brocaar commented 4 years ago

Hi @sophiekovalevsky thanks for digging into this. Interestingly, I had the same issue (and discussion) with RAK. Maybe it would be best to go with option 2) + create an issue at https://github.com/RAKWireless/rak_common_for_gateway about the differences?

The advantage that I see of going with option 2) is that we can add a link to the calibration config (like https://github.com/brocaar/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1301/src/config/vendor/multitech/mtac_lora_h_868_eu868.rs#L11), ideally including the commit hash of the file (e.g. https://github.com/RAKWireless/rak_common_for_gateway/blob/7f110c2f00/lora/rak2245/global_conf/global_conf.as_923.json). That should make it easier to notice if there are any modifications being made :)

sophiekovalevsky commented 4 years ago

@brocaar

I would go with option 2 as well since if we think that chirpstack-concentratord will support several gateway models, it should be a way to automate as much as possible the updates process if something change.

I wrote down an issue into their repository so that we can be clear about which source we could take and why some measurements differs, however I saw that there are several issues without no response, so, hoping we could get some reply back :-)

sophiekovalevsky commented 4 years ago

@brocaar I got response back from RAK as you can see on the issue I am not sure when they are planning to change the value, but probably 2 option would be the one. Would that be okey if I can move forward with the implementation and let those values to be push at the end?

brocaar commented 4 years ago

@sophiekovalevsky yes that would be great :+1:

chirpstack / chirpstack-gateway-os