Closed yzk0281 closed 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
.
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?
@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
}
@yzk0281
Looking at the changes you made to the initial version:
And the LoRaWAN specs (v1.0.1):
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.
@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.
@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?
1 Packets receive from nodes successfully as following log:
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" ?