search

chirpstack / chirpstack-concentratord

Concentrator HAL daemon for LoRa gateways.
https://www.chirpstack.io/
MIT License
76 stars 53 forks source link

Hardware configuration file #171

Closed map588 closed 2 months ago

map588 commented 2 months ago

Summary

My SX1302 has a pinout which is different from any of the ones you have configured, and when I went to try and fix it I noticed that the configurations are defined in several separate files, and I would need to find all of the parameters and recompile if I wanted to add my hardware. I'm not very familiar with rust, and there is likely a technical reason this was done, but if the program can parse the config.toml file and substitute the values into the code, why couldn't it parse a hardware config file so I could define them in a central place?

Again, I'm not the most familiar with rust, but it makes sense that those values maybe need to be compiled in for efficiency reasons, but could the hardware config file be parsed at compile time?

What is the use-case?

Users who don't have a device which is supported by the program directly could use concentratord by defining the parameters and recompiling.

Implementation description

A "custom" keyword added to the list of hardware configurations in the toml, which signals the program to confirm that another "hardware configuration path" is defined in the toml.
The parameters that you already define in the other vendor configurations could be templated into its own toml file, and parsed by the program/compiler when the values are needed; whether at compile time or runtime.

Can you implement this by yourself and make a pull request?

No, I would just add the one vendor hardware configuration if I could, but I can't find where to put the values.

brocaar commented 2 months ago

Please note that there is already (hidden) configuration to override the pin mapping: https://github.com/chirpstack/chirpstack-concentratord/blob/master/chirpstack-concentratord-sx1302/src/config/mod.rs#L99

The reason that the config is stored in code is that normally the calibration values are provided by the gateway vendor and should not be changed by the end-user. Incorrect calibration values could mean that a gateway will transmit with more power than legally allowed.

If you would like to add an existing SX1302 shield to this project, please create a separate issue (or even better PR) with all the details of this shield.

map588 commented 2 months ago

One thing I cannot change is the i2c address given those options, and I know the correct value, but its trying 0x3B. I notice that the i2c_temp_sensor_addr is not in that list, just the chip path. Is there a workaround for this? @brocaar

map588 commented 2 months ago

And disabling things as well. I have a device very similar to a pre-configured one, but it doesn't have an sx1302_power_en pin, so I just set it to a gpio pin that was not in use, but ideally I could give it a "None" value, is there a way to do this?