Concentratord SX1302 Not transmitting data

ChirpStack Concentratord
1

Hi there,

I am running Chirpstack on a Raspberry Pi 4B utilizing a RAK2287 SX1302 US915 radio with a yocto-based system. I seem to be having some issues getting the concentrator to work well with it. In a similar configuration, I am able to run the entire stack with the RAK2245 SX1301 US915 radio. So, I am trying to keep the environment similar to support both radios. Below is the output from the chirpstack-concentrator-sx1302 program.

root@gateway-9999:~# chirpstack-concentratord-sx1302 -c /etc/chirpstack-concentratord/global.toml
Opening SPI communication interface
Note: chip version is 0x10 (v1.0)
INFO: Configuring SX1250_0 in single input mode
INFO: using legacy timestamp
INFO: LoRa Service modem: configuring preamble size to 8 symbols
ARB: dual demodulation disabled for all SF
INFO: no temperature sensor found on port 0x39
INFO: no temperature sensor found on port 0x3B
INFO: no temperature sensor found on port 0x38
ERROR: no temperature sensor found.
ERROR: invalid I2C file descriptor
...
ERROR: invalid I2C file descriptor

And below is the config I am using:

root@gateway-9999:~# cat /etc/chirpstack-concentratord/global.toml 
# Concentratord configuration.
[concentratord]

# Log level.
#
# Valid options are:
#   * TRACE
#   * DEBUG
#   * INFO
#   * WARN
#   * ERROR
#   * OFF
log_level="DEBUG"

# Log to syslog.
#
# When set to true, log messages are being written to syslog instead of stdout.
log_to_syslog=true

# Statistics interval.
stats_interval="30s"

  # Configuration for the (ZeroMQ based) API.
  [concentratord.api]

  # Event PUB socket bind.
  event_bind="ipc:///tmp/concentratord_event"

  # Command REP socket bind.
  command_bind="ipc:///tmp/concentratord_command"


# LoRa gateway configuration.
[gateway]

# Antenna gain (dB).
antenna_gain=0

# Public LoRaWAN network.
lorawan_public=true

# Gateway vendor / model.
#
# This configures various vendor and model specific settings like the min / max
# frequency, TX gain table.
model="rak_2287_us915"

# Gateway vendor / model flags.
model_flags=["GNSS",]

# Gateway ID.
gateway_id="my-gateway-id" #in application, this is a real gateway ID

# Reset pin.
#
# Note: most model configurations come with a pre-defined reset_pin, in which
# case the setting below will be ignored.
reset_pin=0
# Beacon configuration.
#
# This requires a gateway with GPS / GNSS.
[gateway.beacon]

# Compulsory RFU size.
compulsory_rfu_size=5

# Beacon frequency / frequencies (Hz).
frequencies=[
  923300000,
  923900000,
  924500000,
  925100000,
  925700000,
  926300000,
  926900000,
  927500000,
]

# Bandwidth (Hz).
bandwidth=500000

# Spreading factor.
spreading_factor=12

# TX power.
tx_power=14
# LoRa concentrator configuration.
[gateway.concentrator]

# Multi spreading-factor channels (LoRa).
multi_sf_channels=[
  902300000,
  902500000,
  902700000,
  902900000,
  903100000,
  903300000,
  903500000,
  903700000,
]

# LoRa std channel (single spreading-factor).
[gateway.concentrator.lora_std]
frequency=903000000
bandwidth=500000
spreading_factor=8

Like I mentioned before, I have a working SX1301 setup and really the only changes I have made are to the model and model_flags items in the configuration (as well as using the sx1302 version of the concentrator).

The error being output about the Invalid I2C Descriptor seems to be a bit of a red herring as far as I can tell. I believe it is in reference to the temperature sensor, which looking at the schematics for the RAK SX1302 board is not wired through and is not an error that is crashing the program. I even tried forking the sx1302_hal repo and commenting out the checks for that I2C device. It builds and runs without that check, but ultimately runs into the same issue.

I’m a bit unsure on how to proceed. As far as I can tell, my configuration is correct. Please let me know if that is not the case. I have been quite hung up on this issue for too long now so it is definitely time to ask for help! Thanks for taking the time to assist. And please do let me know if you have any additional questions.

1 Like
2

The RAK2287 doesn’t have the temperature sensor specified by the Semtech reference design for which this code is intended, so you need to use modified code that eliminates the reliance on that - not just the initial presence check, but the periodic reads and also the use of measured temperature to compensate received RSSI.

I think if you look around you’ll see versions of other packet forwarders that do this either always (rak’s version) or by configuration option (some 3rd party ones), which could at least provide some guidance on possible mechanisms - ultimately they come down to assuming the temperature, either as itself, or as an assumption of the RSSI offset which would result from it.

Putting in a temperature sensor elsewhere in the system wouldn’t give great results, it really should be a probe as close as possible to the radio front end chips and inside the shielding that captures the degree to which digital processing in the SX1302 heats them, though fortunately the more power efficient SX1302 does so much less than first generation chips like the SX1301.

1 Like
3

The ChirpStack Gateway OS contains a patch (originally from RAK) to deal with the missing temperature sensor. The HAL does print the error message, but the patch prevents the HAL from returning an error message. Last week I discovered that this was causing an issue in case of re-configuring the gateway as the lgw_stop did not contain the patch and would error because of the missing temp. sensor / already closed i2c bus.

Patch 1:

Patch 2:

4

@brocaar Thank you for those patches. I have it all working now thanks to them! Really appreciate your time on this. :slight_smile: