TheThingsNetwork/gateway-conf

"Invalid configuration Std Channel" on AU915-928

matheusrabuske opened this issue · 9 comments

matheusrabuske commented

I'm trying to run Semtech Packet Forwarder using the AU-global_conf.json file provided (without any changes).
When I start the Packet Forwarder service, all of the multi-SF channels seems to be configured without problems, except for the LoRa Standard Channel, whose the following error appears:

`INFO: Lora std channel> radio 0, IF 400000 Hz, 500000 Hz bw, SF 8

ERROR: invalid configuration for Lora standard channel`

I switched to US-global_conf.json, just for testing purposes, and the PF starts without problems, but using AU-global_conf.json, I can't make it work because the PF initialization breaks after this error.

Am I doing something wrong?

ama9910 commented

Hi @matheusrabuske. That data rate is correct for AU915 (SF8BW500 on 917.5MHz). I use @kersing 's packet forwarder on my Multitech gateways here in Australia - https://github.com/kersing/multitech-installer.

If you're not using a Multitech, you can maybe take some queues from its configuration files.

matheusrabuske commented

Actually, I'm running a Raspberry Pi 3 + RisingHF RHF0M301 Concentrador Module as gateway.
I will give a look at the @kersing's packet forwarder to see if there is something that I can do to make Semtech's PF work with AU configs.

Thanks!

matheusrabuske commented

Ok, guess I figured it out.

Looking at the AU json file, we can see that radio_0 frequency is 917.1 MHz.

But, according with Frequency Plans, we can see that this frequency doesn't exist on AU plan; only 917.0 MHz (or 917.2 MHz).

Same case occurred with US json file, which where fixed on last commit of the file; there were an "offset" between the radio_0 and the Frequency Plans frequencies available to US, and the packet forwarder could not start because the same error on LoRa Standard Channel configuration during startup. That error was fixed changing the radio_0 frequency and adjusting the other channel (related to radio 0) frequencies according to Frequency Plans (although I did not undertood why he changed the tx_freq_min, and to a value so high).

But I'm a newbie with LoRa, so, do you guys think I'm right on those assumptions?

jpmeijers commented

The tx_freq_min and tx_freq_max are specified in the config file as a fail safe. It defines the endges of the ISM band that we are allowed to transmit in. The exact frequency the gateway transmits on is specified by the network server. If the frequency the network server tells to use falls outside of the tx_freq_min and tx_freq_max range, the packet will not be transmitted. Therefore these settings should not have any effect on your receive channels.

I went to have a look at the config file, and for the 125kHz channels everything seems fine, taking the radios' freq and the channels' if into account.

The problem comes in with the 250kHz channel. It is located at 917.5MHz. To reach this frequency we use an IF of 400kHz on radio 0. A radio (sx1257) only has an 800kHz bandwidth, so this puts this channel right on the edge of its reach. For the center frequency of the channel this is still fine, but taking the channel's bandwidth into account we see: 917.5MHz + (250kHz/2) = 917.625MHz. This is 525kHz higher than radio 0's centre frequency, which is too high.

We can see in the source code of the gateway's HAL this check to prevent channels outside of the radio's range:

    bw_hz = lgw_bw_getval(conf.bandwidth); /* channel bandwidth */
    if ((conf.freq_hz + ((bw_hz==-1)?LGW_REF_BW:bw_hz)/2) > ((int32_t)rf_rx_bandwidth/2)) {
        DEBUG_PRINTF("ERROR: IF FREQUENCY %d TOO HIGH\n", conf.freq_hz);
        return LGW_HAL_ERROR;
    }

There is no easy solution to this, and the 800kHz limited bandwidth of the two radios is the reason for the radio's very specific freq and the channels' ifs. The only way I see we can fix this is by moving the 250kHz STD channel a bit lower. Maybe follow a similar setup as in the EU band and put the 250kHz channel on 917MHz. @tftelkamp what do you think about this?

Edit:
I just realised that the Australian STD channel is actually 500kHz wide. Also from the sx1257 datasheet the bandwidth is actually 1MHz, and from the libloragw HAL the usable bandwidth for 500kHz channels is 1.1MHz.

Redoing the calculations:
400kHz + (500kHz / 2) = 650kHz, which is higher than 550kHz (= 1.1MHz / 2).

ama9910 commented
jpmeijers commented

You are absolutely correct. That does make things even more tricky.

Maybe we should reconsider which 8 125kHz channels we are using and choose them so that the 250kHz channel falls within the sx1257's range.

ama9910 commented

Maybe we should reconsider which 8 125kHz channels we are using

We have standardised on sub-band 2 (916.8-918.2) and there are many devices out there configured for these frequencies, so that would break existing installations.

I haven't come across this problem before. I thought that SF8BW500 was working OK here?

jpmeijers commented

Gettings some notes together:
https://docs.google.com/spreadsheets/d/19eM86jakni-SdGvr5UBNzLkNNzjNRk90vyTYw1Wy7jg/edit?usp=sharing

It is strange that the LoRaWAN alliance will set a frequency plan that is impossible with standard hardware. I will investigate the HAL and sx1257 specs a bit more, and try contacting Semtech to ask.

jpmeijers commented

I got a reply from Semtech: https://semtech.force.com/lora/LC_Answers_Questions?id=9064400000090AxAAI

The recommendation is to change the freq of radio0 to 917.2MHz, which puts the STD channel on an if of 300kHz:
300kHz + (500kHz / 2) = 550kHz, which is exactly the limit for the sx1257, 550kHz (= 1.1MHz / 2).

I will update the global_conf via a pull request now.