Permit temperature sensor to be optional

[joelguittet]

Hello,

I would like to reopen an issue that was previously discussed at https://github.com/Lora-net/sx1302_hal/issues/28.

The issue deals with the mandatory temperature sensor required to make the RSSI compensation. All SX1302 boards have not the embedded temperature sensor has expected. I'm using RAK2287 which is a recent product (https://www.rakwireless.com/en-us/products/lpwan-gateways-and-concentrators/rak2287) but without the temperature sensor.

Today the solution is to get the code and patch it to remove the temperature sensor reading and use an arbitrary fixed value (let say 25 or 30°C for example).

It's a shame the RSSI compensation could not be bypassed today. Is it possible to study this use case please ?

If the answer is "yes that something that may be useful" I'm ready to work on it and propose a pull request.

Let me known please.

Regards Joel

(actually working with a patched packet-forwarder v1.0.5 binary because I have not the force to do the patches for all consecutive versions each time a new one is released :-( )

[joelguittet]

Nota bene: I just also notice the I2C Linux device is hard coded:

#define I2C_DEVICE          "/dev/i2c-1"

While the SPI device is available in the configuration... could be enhanced easily as well.

[wong-hao]

Hi there, I don't quite understand your problem.

What you need is to eliminate all the code related to the temperature sensor so that the program that could not run normally can run normally now, right?

[joelguittet]

Well, that's purely what I do today. But basically, doing this each time a release is done by updating a fork and doing the job again is not wanted by any développer. Why don't doing this in the mainline code instead of forking ?

I propose the following:

• as done for the gps (gps_tty_path), introduction of a new parameter "i2c_path" in the "gateway_conf" part of the configuration
• removing the define #define I2C_DEVICE and use the above parameter instead
• permit to not read the temperature of the sensor if "i2c_path" is empty

That what is done for the gps, leaving "gps_tty_path" simply disable this part in the packet-forwarder, so it's reasonable to think the same behavior ca be achieved for the temperature sensor.

If this solution fit, I can do it and create a pull request so you can review and discuss the details on it. I have checked the code and the above solution don't seems to be very complicated. Just need the go.

Joel

[shawaj]

+1 on this

We have the same issue where we have to patch the files with each release - see here https://github.com/NebraLtd/hm-pktfwd/tree/master/sx1302fixes

Having it as an optional, configurable option would be a welcome change

[joelguittet]

@shawaj I'm happy to see people having the same issue. I have identified the modifications to do and will do the PR here asap. It's better to understand the objective of this if we can speak around a real PR and it has more chance to be accepted in my opinion.

Should be a question of days before the PR will be done.

Joel

[shawaj]

Judging by the files / installer in this repo, we are not the only ones doing this either. Looks like a pretty common use case https://github.com/RAKWireless/rak_common_for_gateway/tree/master/lora/rak2287

P.S. thanks for your efforts on this!

[joelguittet]

Wasn't aware of this repo as well, looks to fit my needs. But anyway I'm no confortable with the idea of multiple forks and copies of the orignal project.

RAK has provided GPS with I2C interface. This repo has only serial option. Maybe something to improve too (later).

[joelguittet]

@shawaj @wong-hao PR has been proposed at https://github.com/Lora-net/sx1302_hal/pull/63

Joel

[smtc-bot]

Thank you for your inquiry.

Customers are encouraged to submit technical questions via our dedicated support portal at https://semtech.force.com/ldp/ldp_support.

We invite all users to visit the LoRa Developer Portal Forum at https://forum.lora-developers.semtech.com and to join the thriving LoRa development community!