brocaar / chirpstack-network-server

ChirpStack Network Server is an open-source LoRaWAN network-server.
https://www.chirpstack.io
MIT License
1.49k stars 546 forks source link

Test of CN_470_510 #45

Closed yzk0281 closed 8 years ago

yzk0281 commented 8 years ago

1 Packets receive from nodes successfully as following log:

time="2016-07-18T15:32:19+08:00" level=info msg="starting http server" bind="0.0.0.0:8000"
time="2016-07-18T15:33:04+08:00" level=info msg="get apps length" get apps=1
time="2016-07-18T15:37:55+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:37:55+08:00" level=error msg="processing rx packet error: unknown MType: ConfirmedDataDown" data_base64="oEdH4QAKAgADUQcAYQNRBwBhzC9E7A=="
time="2016-07-18T15:39:29+08:00" level=error msg="gateway/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
time="2016-07-18T15:39:29+08:00" level=info msg="gateway/mqttpubsub: connected to mqtt server"
time="2016-07-18T15:39:29+08:00" level=info msg="gateway/mqttpubsub: subscribing to rx topic" topic="gateway/+/rx"
time="2016-07-18T15:39:29+08:00" level=error msg="application/mqttpubsub: mqtt connection error: pingresp not received, disconnecting"
time="2016-07-18T15:39:29+08:00" level=info msg="application/mqttpubsub: connected to mqtt server"
time="2016-07-18T15:39:29+08:00" level=info msg="application/mqttpubsub: subscribing to tx topic" topic="application/+/node/+/tx"
time="2016-07-18T15:43:51+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:43:51+08:00" level=info msg="packet(s) collected" CRCStatus=[1] Channel=[3] CodeRate="4/5" Frequency=[472900000] LoRaSNR=[7.2] RFChain=[1] RSSI=[-114] dev_eui=0000000000000007 gw_count=1 gw_macs=fffeb827ebcf3879 mtype=UnconfirmedDataUp time_s=[2016-07-18 07:43:48.684365 +0000 UTC]
time="2016-07-18T15:43:51+08:00" level=info msg="controller/mqttpubsub: publishing rxinfo payload" topic="application/0000000000000011/node/0000000000000007/rxinfo"
time="2016-07-18T15:43:51+08:00" level=info msg="application/mqttpubsub: publishing rx payload" topic="application/0000000000000011/node/0000000000000007/rx" 
time="2016-07-18T15:43:51+08:00" level=info msg="node-session saved" dev_addr=00e14747
time="2016-07-18T15:45:45+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:45:45+08:00" level=error msg="processing rx packet error: unknown MType: ConfirmedDataDown" data_base64="oEdH4QAKAgADUQcAYQNRBwBhzC9E7A=="
time="2016-07-18T15:48:00+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:48:00+08:00" level=info msg="packet(s) collected" CRCStatus=[1] Channel=[7] CodeRate="4/5" Frequency=[472100000] LoRaSNR=[7.2] RFChain=[0] RSSI=[-109] dev_eui=0000000000000007 gw_count=1 gw_macs=fffeb827ebcf3879 mtype=UnconfirmedDataUp time_s=[2016-07-18 07:47:57.22486 +0000 UTC]
time="2016-07-18T15:48:00+08:00" level=info msg="controller/mqttpubsub: publishing rxinfo payload" topic="application/0000000000000011/node/0000000000000007/rxinfo"
time="2016-07-18T15:48:00+08:00" level=info msg="application/mqttpubsub: publishing rx payload" topic="application/0000000000000011/node/0000000000000007/rx" 
time="2016-07-18T15:48:00+08:00" level=info msg="node-session saved" dev_addr=00e14747
time="2016-07-18T15:53:54+08:00" level=info msg="gateway/mqttpubsub: rx packet received"
time="2016-07-18T15:53:54+08:00" level=info msg="packet(s) collected" CRCStatus=[1] Channel=[2] CodeRate="4/5" Frequency=[472700000] LoRaSNR=[8.8] RFChain=[1] RSSI=[-109] dev_eui=0000000000000007 gw_count=1 gw_macs=fffeb827ebcf3879 mtype=UnconfirmedDataUp time_s=[2016-07-18 07:53:51.035185 +0000 UTC]
time="2016-07-18T15:53:54+08:00" level=info msg="controller/mqttpubsub: publishing rxinfo payload" topic="application/0000000000000011/node/0000000000000007/rxinfo"

2 but some error occur says: processing rx packet error: unknown MType: ConfirmedDataDown

I found it in internal/loraserver/loraserver.go:126, why not handle type "ConfirmedDataDown" ?

ivajloip commented 8 years ago

The network server should be the one that sends ConfirmedDataDown so there is no point (to the best of my knowledge) of handling this. An end-node should not send ConfirmedDataDown, but ConfirmedDataUp.

brocaar commented 8 years ago

Yes, ConfirmedDataDown should not be handled by LoRa Server, as this is the data sent to the node (might be a misconfiguration at the gateway side). Before I merge the band config into master, could you confirm if:

works for you?

yzk0281 commented 8 years ago

@brocaar I modify band_cn470_510.go to follow and data up/OTAA all works well, mainly about the uplink and down link channel & frequency should be the same:

package band

import "time"

func newCN470Band() (Band, error) {
    band := Band{
        DefaultTXPower:   14,
        ImplementsCFlist: false,
        RX2Frequency:     505300000,
        RX2DataRate:      0,

        MaxFCntGap:       16384,
        ADRACKLimit:      64,
        ADRACKDelay:      32,
        ReceiveDelay1:    time.Second,
        ReceiveDelay2:    time.Second * 2,
        JoinAcceptDelay1: time.Second * 5,
        JoinAcceptDelay2: time.Second * 6,
        ACKTimeoutMin:    time.Second,
        ACKTimeoutMax:    time.Second * 3,

        DataRates: []DataRate{
            {Modulation: LoRaModulation, SpreadFactor: 12, Bandwidth: 125},
            {Modulation: LoRaModulation, SpreadFactor: 11, Bandwidth: 125},
            {Modulation: LoRaModulation, SpreadFactor: 10, Bandwidth: 125},
            {Modulation: LoRaModulation, SpreadFactor: 9, Bandwidth: 125},
            {Modulation: LoRaModulation, SpreadFactor: 8, Bandwidth: 125},
            {Modulation: LoRaModulation, SpreadFactor: 7, Bandwidth: 125},
            {}, // RFU
            {}, // RFU
            {}, // RFU
            {}, // RFU
            {}, // RFU
            {}, // RFU
            {}, // RFU
            {}, // RFU
            {}, // RFU
            {}, // RFU
        },

        MaxPayloadSize: []MaxPayloadSize{
            {M: 59, N: 51},
            {M: 59, N: 51},
            {M: 59, N: 51},
            {M: 123, N: 115},
            {M: 230, N: 222},
            {M: 230, N: 222},
            {}, // not defined
            {}, // not defined
            {}, // not defined
            {}, // not defined
            {}, // not defined
            {}, // not defined
            {}, // not defined
            {}, // not defined
            {}, // not defined
            {}, // not defined
        },

        RX1DataRate: [][]int{
            {0, 0, 0, 0, 0, 0},
            {1, 0, 0, 0, 0, 0},
            {2, 1, 0, 0, 0, 0},
            {3, 2, 1, 0, 0, 0},
            {4, 3, 2, 1, 0, 0},
            {5, 4, 3, 2, 1, 0},
        },

        TXPower: []int{
            17,
            16,
            14,
            12,
            10,
            7,
            5,
            2,
            0, // rfu
            0, // rfu
            0, // rfu
            0, // rfu
            0, // rfu
            0, // rfu
            0, // rfu
            0, // rfu
        },

        UplinkChannels:   make([]Channel, 96),
        //DownlinkChannels: make([]Channel, 48),
        DownlinkChannels: make([]Channel, 96),

        getRX1ChannelFunc: func(txChannel int) int {
            //return txChannel % 48
            return txChannel % 96
        },
    }

    // initialize uplink channels
    for i := 0; i < 96; i++ {
        band.UplinkChannels[i] = Channel{
            Frequency: 470300000 + (i * 200000),
            DataRates: []int{0, 1, 2, 3, 4, 5},
        }
    }

    // initialize downlink channels
    //for i := 0; i < 48; i++ {
    for i := 0; i < 96; i++ {
        band.DownlinkChannels[i] = Channel{
            //Frequency: 500300000 + (i * 200000),
            Frequency: 470300000 + (i * 200000),
            DataRates: []int{0, 1, 2, 3, 4, 5},
        }
    }

    return band, nil
}
brocaar commented 8 years ago

@yzk0281

Looking at the changes you made to the initial version: image

And the LoRaWAN specs (v1.0.1): image

I'm wondering where you got the info that the uplink & downlink channels must be the same? Following the specs, there are 48 downlink channels, starting at 500.3Mhz.

yzk0281 commented 8 years ago

@brocaar I am Chinese and I am working on it now, I have confirmed that the band_cn470_510.go I provided works fine. The LoRaWAN you mentioned above is, maybe one of the solutions as the frequency assignment is different one another.

yzk0281 commented 8 years ago

@brocaar We working on class A, the uplink & downlink channels must be the same as downlink window is right after the uplink window and it is short. The frequency assignment in loraserver should cover the settings in gateway && node Our gateway && node working frequency has 8 point witch is 471.3 471.5 471.7 471.9 421.1 421.3 421.5 421.7 and they all in covered by the band_cn470_510.go I mentioned above, this is why, I think, my test of data-up/data-down/OTAA all passed. Data-down I mean here is, as my observe, the acks of data-up. By the way, how to test other kind of data-down like MIC commends or self-defined ones?