Cisco IXM Gateway Setup - Common Packet Forwarder (BasicStation)

LoRaWayne · April 10, 2021, 1:31pm

Hi All,

I have a couple of Cisco LoRa Gateways here that I’ve been successfully using with ChirpStack on FW: 2.0.3.2 with packet-forwarder/ChirpStack Gateway Bridge combo. I’ve recently installed FW: 2.1.0.2 so I can trial the Cisco Common Packet Forwarder (CPF) and Basic Station backend on the Gateway Bridge, as it requires less hacking around on the gateway to get things going. All ChirpStack components have been updated to the latest version at the time of writing this. Gateway 1 has two antennas connected which are both Omni, and configured as omni on the gateway CLI. Gateway 2 has two sectors and the config reflects this.

Both have been configured by following this guide:
ChirpStack Gateway Bridge Cisco Configuration

I’ve come up against a couple of issues using Basic Station that i’m hoping someone may know the answers to:

Before the upgrade, when sending an uplink from a device I would get two entires in the Application Server ‘Live Frames’ view, one for the frame received via antenna 1 and one for antenna 2. Now I only get one. Given that the gateways have two antennas, I would expect that if I disconnect one antenna, the other would easily have the best RSSI/SNR and the reported figures in the uplink would barely change, however if i disconnect one antenna and send a new frame the reported RSSI goes from -45 to -95 - which says to me only one Antenna is being used. If i drill down into the metadata the frames only ever reference antenna: 0 whereas before i’d get one for antenna: 1 also. Is there a way I can verify/debug this?
I no longer get an automatic GPS position from the Gateway. Is there a way to enable this?
I’ve enabled debug cpf on the gateway which confirms the GPS has been enabled and used as a time source. I’m wondering if this feature isn’t supported, as i get the entry ignoring unsupported/unknown field: gps_conf
The logs on my ChripStack Gateway Bridge are now getting hammered with timesync message sent to gateway messages. Is this normal?

Thanks in advance,

Wayne

LoRaWayne · April 12, 2021, 11:49am

@brocaar Perhaps you can shine some light on this from a Gateway Bridge/Network Server perspective?

brocaar · April 14, 2021, 9:49am

It could be that the BasicStation only reports the data received by one antenna, I don’t know. I do believe that the BasicStation does not report the gateway location, see https://doc.sm.tc/station/tcproto.html.

Are you sure that you are running the latest ChirpStack Gateway Bridge, it implements responding to the timesync requersts:

Basic Station timesync request/response support. (#179)

LoRaWayne · April 23, 2021, 4:41pm

Thanks for the info @brocaar

##Updated## 24/04/21
Here are some logs from the gateway and ChrirpStack Bridge regarding GPS:

2021-04-24 12:36:12.569 [AIO:DEBU] [7|WS] > {"msgtype":"event","evcat":"gps","evmsg":{"evtype":"move","lat":xx.6285,"lon":-x.84577,"alt":72.7,"dilution":2.38,"satellites":6,"quality":1}}
2021-04-24 12:36:12.569 [AIO:DEBU] ------------------------------
2021-04-24 12:36:12.569 [GPS:INFO] GPS move 0.0000000,0.0000000 => xx.6285324,-x.8457704 (alt=72.7 dilution=2.380000 satellites=6 quality=1)
2021-04-24 12:36:12.569 [AIO:DEBU] ------------------------------
2021-04-24 12:36:12.569 [AIO:DEBU] sending msg...len=134
2021-04-24 12:36:12.569 [AIO:DEBU] [7|WS] > {"msgtype":"alarm","text":"GPS move 0.0000000,0.0000000 => xx.6285324,-x.8457704 (alt=72.7 dilution=2.380000 satellites=6 quality=1)"}
2021-04-24 12:36:12.569 [AIO:DEBU] ------------------------------

Apr 24 12:36:12 GATEWAY1 chirpstack-gateway-bridge[27679]: time="2021-04-24T12:36:12+01:00" level=info msg="backend/basicstation: raw packet-forwarder event received" gateway_id=xxxxxxxxxxxx0880 raw_id=db7a9515-abe7-4c46-9293-cd4c7f93cb94
Apr 24 12:36:12 GATEWAY1 chirpstack-gateway-bridge[27679]: time="2021-04-24T12:36:12+01:00" level=info msg="integration/mqtt: publishing event" event=raw qos=0 raw_id=db7a9515-abe7-4c46-9293-cd4c7f93cb94 topic=gateway/xxxxxxxxxxxx0880/event/raw
Apr 24 12:36:12 GATEWAY1 chirpstack-gateway-bridge[27679]: time="2021-04-24T12:36:12+01:00" level=info msg="backend/basicstation: raw packet-forwarder event received" gateway_id=xxxxxxxxxxxx0880 raw_id=8703619f-9882-4599-9907-6e6bfe5bd02c
Apr 24 12:36:12 GATEWAY1 chirpstack-gateway-bridge[27679]: time="2021-04-24T12:36:12+01:00" level=info msg="integration/mqtt: publishing event" event=raw qos=0 raw_id=8703619f-9882-4599-9907-6e6bfe5bd02c topic=gateway/xxxxxxxxxxxx0880/event/raw

It looks as though the GPS updates aren’t being interpreted by the bridge? Not sure. Interested to hear your thoughts.

I’ve taken some more time to watch the timesync requests and after a while they eventually disappear, so I think it’s behaving as it’s supposed to.

I’ve done some digging into the antenna issue and spoken with the manufacturer - basically the gateway will configure the SX1301’s to what’s been specified in the router_config message, I think there’s a discrepancy between what’s configured in the chirpstack bridge config file and what’s received or implemented by the gateway.

Config:

# Gateway backend configuration.
[backend]

# Backend type.
type="basic_station"

  # Basic Station backend.
  [backend.basic_station]

  # ip:port to bind the Websocket listener to.
  bind=":3001"

  # Region.
  region="EU868"

  # Minimal frequency (Hz).
  frequency_min=863000000

  # Maximum frequency (Hz).
  frequency_max=870000000

  # Concentrator configuration.
  # Note: this is defined twice as the Cisco gateway has two SX1301 chips.
  [[backend.basic_station.concentrators]]
    # Multi-SF channel configuration.
    [backend.basic_station.concentrators.multi_sf]

    # Frequencies (Hz).
    frequencies=[
      868100000,
      868300000,
      868500000,
      867100000,
      867300000,
      867500000,
      867700000,
      867900000,
    ]

    # LoRa STD channel.
    [backend.basic_station.concentrators.lora_std]

    # Frequency (Hz).
    frequency=868300000

    # Bandwidth (Hz).
    bandwidth=250000

    # Spreading factor.
    spreading_factor=7

    # FSK channel.
    [backend.basic_station.concentrators.fsk]

    # Frequency (Hz).
    frequency=868800000

  [[backend.basic_station.concentrators]]
    # Multi-SF channel configuration.
    [backend.basic_station.concentrators.multi_sf]

    # Frequencies (Hz).
    frequencies=[
      868100000,
      868300000,
      868500000,
      867100000,
      867300000,
      867500000,
      867700000,
      867900000,
    ]

    # LoRa STD channel.
    [backend.basic_station.concentrators.lora_std]

    # Frequency (Hz).
    frequency=868300000

    # Bandwidth (Hz).
    bandwidth=250000

    # Spreading factor.
    spreading_factor=7

    # FSK channel.
    [backend.basic_station.concentrators.fsk]

    # Frequency (Hz).
    frequency=868800000

And this is the debug from the gateway:

{
    "msgtype": "router_config",
    "NetID": null,
    "JoinEui": null,
    "region": "EU863",
    "hwspec": "sx1301/2",
    "freq_range": [
        863000000,
        870000000
    ],
    "DRs": [
        [
            12,
            125,
            0
        ],
        [
            11,
            125,
            0
        ],
        [
            10,
            125,
            0
        ],
        [
            9,
            125,
            0
        ],
        [
            8,
            125,
            0
        ],
        [
            7,
            125,
            0
        ],
        [
            7,
            250,
            0
        ],
        [
            0,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ],
        [
            -1,
            0,
            0
        ]
    ],
    "sx1301_conf": [
        {
            "radio_0": {
                "enable": true,
                "freq": 867500000
            },
            "radio_1": {
                "enable": true,
                "freq": 868500000
            },
            "chan_FSK": {
                "enable": true
            },
            "chan_Lora_std": {
                "enable": true,
                "radio": 1,
                "if": -200000,
                "bandwidth": 250000,
                "spread_factor": 7
            },
            "chan_multiSF_0": {
                "enable": true,
                "radio": 0,
                "if": -400000
            },
            "chan_multiSF_1": {
                "enable": true,
                "radio": 0,
                "if": -200000
            },
            "chan_multiSF_2": {
                "enable": true,
                "radio": 0,
                "if": 0
            },
            "chan_multiSF_3": {
                "enable": true,
                "radio": 0,
                "if": 200000
            },
            "chan_multiSF_4": {
                "enable": true,
                "radio": 0,
                "if": 400000
            },
            "chan_multiSF_5": {
                "enable": true,
                "radio": 1,
                "if": -400000
            },
            "chan_multiSF_6": {
                "enable": true,
                "radio": 1,
                "if": -200000
            },
            "chan_multiSF_7": {
                "enable": true,
                "radio": 1,
                "if": 0
            }
        },
        {
            "radio_0": {
                "enable": true,
                "freq": 867500000
            },
            "radio_1": {
                "enable": true,
                "freq": 868500000
            },
            "chan_FSK": {
                "enable": true
            },
            "chan_Lora_std": {
                "enable": true,
                "radio": 1,
                "if": -200000,
                "bandwidth": 250000,
                "spread_factor": 7
            },
            "chan_multiSF_0": {
                "enable": true,
                "radio": 0,
                "if": -400000
            },
            "chan_multiSF_1": {
                "enable": true,
                "radio": 0,
                "if": -200000
            },
            "chan_multiSF_2": {
                "enable": true,
                "radio": 0,
                "if": 0
            },
            "chan_multiSF_3": {
                "enable": true,
                "radio": 0,
                "if": 200000
            },
            "chan_multiSF_4": {
                "enable": true,
                "radio": 0,
                "if": 400000
            },
            "chan_multiSF_5": {
                "enable": true,
                "radio": 1,
                "if": -400000
            },
            "chan_multiSF_6": {
                "enable": true,
                "radio": 1,
                "if": -200000
            },
            "chan_multiSF_7": {
                "enable": true,
                "radio": 1,
                "if": 0
            }
        }
    ]
}

At current, even though there are two radios in these gateways and both antennas are connected, only one (ANT1) is working. On the gateway both have been configured:

gatewayid <GATEWAYID>
gps enable
ipaddr 192.xxx.xxx.xxx port 3001
antenna 1 sector gain 8.0 loss 0.1
antenna 2 sector gain 8.0 loss 0.1
cpf enable

Even with both antennas disabled on the gateway, it’s still able to receive packets so I’ll post an update when i’ve had more clarity from the manufacturer on this issue.

brocaar · April 25, 2021, 4:12pm

This msgtype is not documented / not part of the official Basic Station protocol:

https://doc.sm.tc/station/tcproto.html

LoRaWayne · April 29, 2021, 12:08pm

Good point

If I can get the message structure, would it be possible to impliment this feature?