brocaar / lorawan Goto Github PK
View Code? Open in Web Editor NEWPackage lorawan provides structures and tools to read and write LoraWAN messages from and to a slice of bytes.
License: MIT License
Package lorawan provides structures and tools to read and write LoraWAN messages from and to a slice of bytes.
License: MIT License
Hi,
We are using SX1262 LoRa module with LoRaWAN 1.0.3 to connect with Network Server and this is working fine. When we try to connect using LoRaWAN 1.1.0, we are getting join request and join accept also at ChipStack but at end device side its showing LORAMAC_HANDLER_ERROR. Are we missing something. Please let me know. Thanks.
I didn't find an example of how to use it in the package
Hello, Brocaar.
The OptNeg bit is described in the lorawan 1.1 specification. It is part of DLSetting JOIN ACCEPT. It characterizes the version of lorawan that is being used device. Now, your server not used it . Do you have plans to use it?
Hey !
Awesome job with the package.
Still, one thing raises a question, in the implementation of the MACPayload
the FRMPayload
has a []Payload
type. Looking at LoRaWAN I don't see a clue about several payloads that could be sent within one MACPayload. I may be wrong but then I would appreciate to be enlightened on that point :)
So far, as I understand, the frame payload FRMPayload
either comes from the application embedded on the end-device if it's data related or from a layer above if it's mac-related. In both cases nevertheless it is unique, isn't it ?
Thanks
Hi @brocaar ,
I am trying to get some information about decoding the framepayload at "frames_logs", at LoRa Server.
I can get easily decode the payload at mqtt broker using a python script and then doing decode 64 to hex. So my payload sent over the node is the same hex value!
But at postgresql database, the frame payload is some kind different. :/
When I receive from broker on my python application it appears "AQDwBQHy/1H/Wg==" (base64) --> x0100F00501F2FF51FF5A. Thats correct! It is the same frame I've sent over the node.
However when i check on postgres' database, the frame header value also in base 64 would be the same, but there appears "+OU1NBf6d+EHcg==" --> xf8e5353417fa77e10772,
Converting to hex I can take the data correctly size of information, but the frame payload doesnt.
Please give me a light how to proceed :) I will keep studynd and searching how to. In case i got it I will put here the answer.
Best Regards,
Rogério Cassares Pires.
Hi Brocaar,
We are currently using the LoRaMAC_node stack for LoRaWAN v1.0.3 in our project and are planning to upgrade it. Our target is to move to LoRaWAN 1.1, but we also consider using LoRaWAN v1.0.4. Is there a release of the LoRaBasicsModem from Semtech that supports LoRaWAN 1.1? Additionally, if we opt for LoRaBasicsModem with LoRaWAN v1.0.4, could you highlight the key differences or potential feature limitations compared to LoRaWAN 1.1? Understanding these differences is crucial for us to make a decision.
Thank you,
Sravs
Hi,
I'm trying to understand why i'm getting some error messages in passive roaming.
I have the following architecture:
I've created two DNS resolvers one on deveui.iot-roam.net and netid.iot-roam.net
1st LNS: netid is 000001 and JoinEUI 0000000000000001
2nd LNS: netid is 000000 and JoinEUI 0000000000000002
The hNS (in this case netid is 000001), has no prior information about the ED, then I:
Then I have the first DNS request:
Then, since the hNS has no information about this ED, i can see that there is a second DNS Query:
6. DNS query for 000000.netid.iot-roam.net
7. DNS answer with the hNS IP
8. TLS Handshake
9. TLS App data
Here I'm expecting to have this:
10. HomeNSReq / HomeNSAns
11. PRStartReq / JoinReq
9. JoinAns / PRStartAns
10. JoinAccept
But instead I have this from the logs:
On the sNS :
Nov 02 14:17:12 outils.plido.net chirpstack-network-server[1082]: time="2021-11-02T14:17:12.799863844+01:00" level=info msg="uplink/join: resolved joineui to netid" ctx_id=dbd9ff44-5758-441e-9b10-646e0a75ccd5 dev_eui=da03899bc920e487 join_eui=0000000000000002 net_id=000000
Nov 02 14:17:12 outils.plido.net chirpstack-network-server[1082]: time="2021-11-02T14:17:12.812686895+01:00" level=info msg="lorawan/backend: finished backend api call" message_type=PRStartReq protocol_version=1.0 receiver_id=000000 result_code= sender_id=000001 transaction_id=136598966
Nov 02 14:17:12 outils.plido.net chirpstack-network-server[1082]: time="2021-11-02T14:17:12.812846793+01:00" level=error msg="uplink: processing uplink frame error" ctx_id=dbd9ff44-5758-441e-9b10-646e0a75ccd5 error="PRStartReq error: response error, code: , description: "
On the hNS:
nov. 02 13:18:02 vps768800 chirpstack-application-server[4653]: time="2021-11-02T13:18:02.751940573Z" level=info msg="backend/joinserver: sending response" dev_eui=da03899bc920e487 message_type=HomeNSAns receiver_id=000001 result_code=Success sender_id=0000000000000002 transaction_id=1140153905
nov. 02 13:18:02 vps768800 chirpstack-application-server[4653]: time="2021-11-02T13:18:02.764110007Z" level=info msg="backend/joinserver: request received" message_type=PRStartReq receiver_id=000000 sender_id=000001 transaction_id=3904647844
nov. 02 13:18:02 vps768800 chirpstack-application-server[4653]: time="2021-11-02T13:18:02.764142392Z" level=error msg="backend/joinserver: error handling request" error="invalid MessageType: PRStartReq"
As application server I have in both sides the 3.17.3 version and for the NS I have 3.15.3
Am I doing something wrong?
Sorry if this is not the right place to ask
BR
Ivan
IMT Atlantique
Dear Sir
I work to a representative of Wisol in South America.
I am starting blogs about TINYGO and our module is the LSM110A (STM32WL55)
https://ninab3-python.blogspot.com/2022/12/u-blox-nina-b302-rodando-tinygo.html
https://ninab3-python.blogspot.com/2022/12/wisol-lsm110a-rodando-tinygo-blynk-led.html
Both are running...
Can you help me where to include the LoRaWAN package to compile it on TINYGO FOLDER structure ?
├───bin
├───lib
│ ├───clang
│ │ └───include
│ ├───CMSIS
│ │ └───CMSIS
│ │ └───Include
│ ├───compiler-rt-builtins
│ │ ├───aarch64
│ │ ├───arm
│ │ ├───Darwin-excludes
│ │ ├───hexagon
│ │ ├───i386
│ │ ├───macho_embedded
│ │ ├───ppc
│ │ ├───riscv
│ │ ├───ve
│ │ └───x86_64
│ ├───macos-minimal-sdk
│ │ ├───download
│ │ ├───src
│ │ │ ├───arm64
│ │ │ ├───usr
│ │ │ │ └───include
│ │ │ │ ├───arm
│ │ │ │ ├───arpa
│ │ │ │ ├───i386
│ │ │ │ ├───libkern
│ │ │ │ │ ├───arm
│ │ │ │ │ └───i386
│ │ │ │ ├───mach
│ │ │ │ │ ├───arm
│ │ │ │ │ ├───i386
│ │ │ │ │ └───machine
│ │ │ │ ├───machine
│ │ │ │ ├───malloc
│ │ │ │ ├───protocols
│ │ │ │ ├───secure
│ │ │ │ ├───sys
│ │ │ │ │ ├───_pthread
│ │ │ │ │ └───_types
│ │ │ │ ├───xlocale
│ │ │ │ └───_types
│ │ │ └───x86_64
│ │ └───test
│ ├───mingw-w64
│ │ ├───mingw-w64-crt
│ │ │ ├───def-include
│ │ │ └───lib-common
│ │ └───mingw-w64-headers
│ │ ├───crt
│ │ │ ├───sdks
│ │ │ ├───sec_api
│ │ │ │ └───sys
│ │ │ └───sys
│ │ └───defaults
│ │ └───include
│ │ └───sdks
│ ├───musl
│ │ ├───arch
│ │ │ ├───aarch64
│ │ │ │ └───bits
│ │ │ ├───arm
│ │ │ │ └───bits
│ │ │ ├───generic
│ │ │ │ └───bits
│ │ │ ├───i386
│ │ │ │ └───bits
│ │ │ └───x86_64
│ │ │ └───bits
│ │ ├───crt
│ │ ├───include
│ │ │ ├───arpa
│ │ │ ├───net
│ │ │ ├───netinet
│ │ │ ├───netpacket
│ │ │ ├───scsi
│ │ │ └───sys
│ │ └───src
│ │ ├───env
│ │ ├───errno
│ │ ├───exit
│ │ │ └───arm
│ │ ├───include
│ │ │ ├───arpa
│ │ │ └───sys
│ │ ├───internal
│ │ │ ├───i386
│ │ │ └───sh
│ │ ├───malloc
│ │ ├───math
│ │ │ ├───aarch64
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ ├───mips
│ │ │ ├───powerpc
│ │ │ ├───powerpc64
│ │ │ ├───riscv64
│ │ │ ├───s390x
│ │ │ ├───x32
│ │ │ └───x86_64
│ │ ├───mman
│ │ ├───signal
│ │ │ ├───aarch64
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ ├───m68k
│ │ │ ├───microblaze
│ │ │ ├───mips
│ │ │ ├───mips64
│ │ │ ├───mipsn32
│ │ │ ├───or1k
│ │ │ ├───powerpc
│ │ │ ├───powerpc64
│ │ │ ├───riscv64
│ │ │ ├───s390x
│ │ │ ├───sh
│ │ │ ├───x32
│ │ │ └───x86_64
│ │ ├───stdio
│ │ ├───string
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ └───x86_64
│ │ ├───thread
│ │ │ ├───aarch64
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ ├───m68k
│ │ │ ├───microblaze
│ │ │ ├───mips
│ │ │ ├───mips64
│ │ │ ├───mipsn32
│ │ │ ├───or1k
│ │ │ ├───powerpc
│ │ │ ├───powerpc64
│ │ │ ├───riscv64
│ │ │ ├───s390x
│ │ │ ├───sh
│ │ │ ├───x32
│ │ │ └───x86_64
│ │ ├───time
│ │ └───unistd
│ │ ├───mips
│ │ ├───mips64
│ │ ├───mipsn32
│ │ ├───sh
│ │ └───x32
│ ├───nrfx
│ │ ├───doc
│ │ │ ├───buildfiles
│ │ │ └───config_dox
│ │ ├───drivers
│ │ │ ├───include
│ │ │ └───src
│ │ │ └───prs
│ │ ├───hal
│ │ ├───helpers
│ │ ├───mdk
│ │ ├───soc
│ │ └───templates
│ ├───picolibc
│ │ └───newlib
│ │ ├───libc
│ │ │ ├───ctype
│ │ │ ├───include
│ │ │ │ ├───machine
│ │ │ │ ├───rpc
│ │ │ │ ├───ssp
│ │ │ │ └───sys
│ │ │ ├───locale
│ │ │ ├───string
│ │ │ └───tinystdio
│ │ │ └───ryu
│ │ └───libm
│ │ ├───common
│ │ └───math
│ └───wasi-libc
│ └───sysroot
│ ├───include
│ │ ├───arpa
│ │ ├───bits
│ │ ├───net
│ │ ├───netinet
│ │ ├───netpacket
│ │ ├───scsi
│ │ ├───sys
│ │ └───wasi
│ └───lib
│ └───wasm32-wasi
├───pkg
│ ├───thumbv6m-unknown-unknown-eabi-cortex-m0
│ │ ├───compiler-rt
│ │ └───picolibc
│ │ └───include
│ ├───thumbv6m-unknown-unknown-eabi-cortex-m0plus
│ │ ├───compiler-rt
│ │ └───picolibc
│ │ └───include
│ └───thumbv7em-unknown-unknown-eabi-cortex-m4
│ ├───compiler-rt
│ └───picolibc
│ └───include
├───src
│ ├───crypto
│ │ ├───internal
│ │ │ └───boring
│ │ │ └───sig
│ │ └───rand
│ ├───device
│ │ ├───arm
│ │ ├───arm64
│ │ ├───avr
│ │ ├───esp
│ │ ├───kendryte
│ │ ├───nrf
│ │ ├───nxp
│ │ ├───riscv
│ │ ├───rp
│ │ ├───sam
│ │ ├───sifive
│ │ └───stm32
│ ├───examples
│ │ ├───adc
│ │ ├───blinkm
│ │ ├───blinky1
│ │ ├───blinky2
│ │ ├───button
│ │ ├───button2
│ │ ├───can
│ │ ├───caninterrupt
│ │ ├───dac
│ │ ├───echo
│ │ ├───echo2
│ │ ├───gba-display
│ │ ├───hid-keyboard
│ │ ├───hid-mouse
│ │ ├───i2s
│ │ ├───mcp3008
│ │ ├───memstats
│ │ ├───microbit-blink
│ │ ├───pininterrupt
│ │ ├───pwm
│ │ ├───rand
│ │ ├───serial
│ │ ├───systick
│ │ ├───temp
│ │ ├───test
│ │ ├───uart
│ │ ├───usb-midi
│ │ └───wasm
│ │ ├───callback
│ │ ├───export
│ │ ├───invoke
│ │ ├───main
│ │ └───slices
│ ├───internal
│ │ ├───bytealg
│ │ ├───fuzz
│ │ ├───reflectlite
│ │ └───task
│ ├───machine
│ │ └───usb
│ │ ├───cdc
│ │ ├───hid
│ │ │ ├───keyboard
│ │ │ └───mouse
│ │ └───midi
│ ├───net
│ ├───os
│ │ └───exec
│ ├───reflect
│ ├───runtime
│ │ ├───cgo
│ │ ├───debug
│ │ ├───internal
│ │ │ └───sys
│ │ ├───interrupt
│ │ ├───pprof
│ │ ├───trace
│ │ └───volatile
│ ├───sync
│ ├───syscall
│ └───testing
└───targets
Thanks!
I have a question(not so a issue), by the documentation MHDR has one more field RFU. Why you skipped in your implementation, is there some reason?
On 15 November, the LoRa Alliance released the LoRaWAN 1.0.2 Specification and LoRaWAN Regional Parameters 1.0 that includes specifications for the Asian 923 MHz bands and the South Korean 920-923 MHz band.
Shouldn't be much work to implement these in the band
package. Let me know if I can help with this.
Hi,
refer to RP2-1.0.1 LoRaWAN® Regional Parameters wich saying that AS923-1 represents the original AS923 plan; AS923-2 shifts the plan down 1.8MHz and AS923-3 shifts the plan down 6.6MHz, is there any update or how can i change the AS923 original default frequency to meet AS923-2 frequency plan??
LoRaWAN allows 32-bits frame counters. When computing a MIC you can't just cast the 16-bits value from the header to 32 bits assuming the 16 MSB are 0. You would need to add a parameter to the functions to pass the 16 MSB's.
The LoRaWAN Regional Parameters 1.0.2 are changing the TX power from absolute ERP to values relative to MaxEIRP
. The purpose is that TX Power 0 means max tx-power for all devices, but that each device could implement its own MaxEIRP
value.
The TXPower table should therefore contain the delta relative to the MaxEIRP
value instead of the absolute TX Power value.
Important to note is that in the 1.0.2 revision the deltas have been updated. For example in the EU band the delta between TX Power 0 to TX Power 1 was -6dB
, this has been changed to -2dB
. As from the LoRaWAN protocol it is unknown which LoRaWAN Regional Parameters revision the node is implemented, this could potentially break ADR.
Other idea:
Refactor the DefaultTXPower
into a method called GetDownlinkTXPower
. By making this a method, we could also take the number of active channels into account.
Hi,
I’m working on a firmware for a GPS/Lora tracking device (Dragino LGT92 device)
This firmware is written in TinyGO and open-source (https://github.com/ofauchon/zaza-tracker)
This is the device I'm working on :
The firmware is still PoC/WIP, but I can already send GPS position through the Lora tranceiver (SX127x - RFM95).
(with a point to point Lora communication mode, not yet connected to Lorawan network)
I was wondering if I could use "brocaar/lorawan" code to add LoraWAN compatibility.
According to the README:
“Package lorawan provides structures and tools to read and write LoRaWAN 1.0 and 1.1 frames from and to a slice of bytes.”
… So I guess i could build and send all the required packets to join and communicate to Lorawan networks, with this code, right ?
Any comment welcome
Thanks
Olivier
Hi i have ported complete semtech Lorawan Stack to my MCU and using sx1276 via spi. I am able to send packet but my rssi value is -65 when i placed my end node close to gateway. whereas when i used Risinghf Modem with gateway at same distance his rssi value is -20 to -25. I am unable to debug error.
Reading test File phypayload_test.go
, from row 374, it looks that Packet is encrypted with AppSKey instead of NwkSEncKey
as stated in the Lorawan Specification 1.1 (Page 25 / 26).
When Port is 0 and there are Mac Commands in payload, shouldn't be use NwkSEncKey
instead of AppSKey
? or am I missing something ?
Kalik1
Hi, Brocaar,
I am wondering whether this package support RN2483 chip because the encryption algorithm at gateway seems not same as the one at node. Please follow my thought below.
For example, assuming that we have a string data "longtest" needs to be sent to a node. And we have network session key and app session key go like this:
char NWK_SESSION_KEY[] = "01020304050607080910111213141516";
char APP_SESSION_KEY[] = "000102030405060708090A0B0C0D0E0F";
The downlink packet sent by your lorawan system (lora-gateway-bridge/ lorawan-server/ lorawan-app-server) goes like this:
Assuming base64-encoded packet
YOLyEQYgAgAK68z9jEUZBpOUYg==
Message Type = Data
PHYPayload = 60E2F211062002000AEBCCFD8C451906939462
( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
MHDR = 60
MACPayload = E2F211062002000AEBCCFD8C4519
MIC = 06939462
( MACPayload = FHDR | FPort | FRMPayload )
FHDR = E2F21106200200
FPort = 0A
FRMPayload = EBCCFD8C4519
( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
DevAddr = 0611F2E2 (Big Endian)
FCtrl = 20
FCnt = 0002 (Big Endian)
FOpts =
Message Type = Unconfirmed Data Down
Direction = down
FCnt = 2
FCtrl.ACK = true
FCtrl.ADR = false
When my RN2483 node receive this downlink, the decrypted buffer is not the ASCII for string "longtest".
9689e0b5eb2d
Later, I found another tool for encrypting/decrypting LoRa packets here: https://github.com/anthonykirby/lora-packet/
And I write a script (test.js) to illustrate the problem:
var lora_packet = require('lora-packet');
//-----------------
// packet decoding
// decode a packet
// Base64 Downlink Packet: YOLyEQYgbAEKW0lk2KCLHg==
//var packet = lora_packet.fromWire(new Buffer('60e2f2110620020001112a735eda5127e74afea1f7', 'hex')); // right encrypted packet
var packet = lora_packet.fromWire(new Buffer('60E2F211062002000AEBCCFD8C451906939462', 'hex')); // the gateway tx encrypted packet
// debug: prints out contents
// - contents depend on packet type
// - contents are named based on LoRa spec
console.log("packet.toString()=\n" + packet);
// e.g. retrieve payload elements
console.log("packet MIC=" + packet.getBuffers().MIC.toString('hex'));
console.log("FRMPayload=" + packet.getBuffers().FRMPayload.toString('hex'));
// check MIC
var NwkSKey = new Buffer('01020304050607080910111213141516', 'hex');
console.log("MIC check=" + (lora_packet.verifyMIC(packet, NwkSKey) ? "OK" : "fail"));
// calculate MIC based on contents
console.log("calculated MIC=" + lora_packet.calculateMIC(packet, NwkSKey).toString('hex'));
// decrypt payload
var AppSKey = new Buffer('000102030405060708090A0B0C0D0E0F', 'hex');
console.log("Decrypted='" + lora_packet.decrypt(packet, AppSKey, NwkSKey).toString('hex') + "'");
console.log("Decrypted='" + lora_packet.decrypt(packet, AppSKey, NwkSKey).toString('') + "'");
var constructedPacket = lora_packet.fromFields({
MType: 'Unconfirmed Data Down', // (default)
DevAddr: new Buffer('0611F2E2', 'hex'), // big-endian
FCtrl: {
ADR: false, // default = false
ACK: true, // default = false
ADRACKReq: false, // default = false
FPending: false // default = false
},
FCnt: new Buffer('0002', 'hex'), // can supply a buffer or a number
payload: 'longtest'
}
, new Buffer("000102030405060708090A0B0C0D0E0F", 'hex') // AppSKey
, new Buffer("01020304050607080910111213141516", 'hex') // NwkSKey
);
console.log("constructedPacket.toString()=\n" + constructedPacket);
var wireFormatPacket = constructedPacket.getPHYPayload();
console.log("wireFormatPacket.toString()=\n" + wireFormatPacket.toString('hex'));
The output shows that the encryption algorithm of this package is not same as that running on cooking-hacks RN2483. (The encryption algorithm running in the RN2483 nodes is same as the one in JavaScript repo I mentioned before.) Would you please give me some help on this issue? Thank you.
Best Regards,
Xuanliang
Code here appears to invoke an encypt function when it is supposed to be decrypting. Is this a bug? Ditto for the encrypt function (which is decrypting).
https://github.com/brocaar/lorawan/blob/master/phypayload.go#L363
Hi,
Can we make host controller to sleep mode when LoRa module (SX1262) is in receive mode (RX1 and RX2 windows)??
The current solution run the whole subscription phase in a separate go-routine, unfortunately in some fast flows this results in the subscription not being setup completely before the response is published on the Redis channel.
Typically one can find these errors:
Dec 10 11:27:22 lns-roaming.demo.netmoregroup.com chirpstack-network-server[9990]: time="2021-12-10T11:27:22.663521545Z" level=info msg="roaming: api request received" async_client=true ctx_id=21933ed4-7124-467e-8399-a73c2de975c1 message_type=XmitDataAns receiver_id=000001 sender_id=c00012 transaction_id=3816299885
Dec 10 11:27:24 lns-roaming.demo.netmoregroup.com chirpstack-network-server[9990]: time="2021-12-10T11:27:24.67452184Z" level=error msg="downlink/data: XmitDataReq failed" ctx_id=1dba3435-a83d-48b3-90ba-54bf2cc0ffaa dev_eui=0018b20000020450 error="async timeout" net_id=c00012
I have made a pull request to solve this by
For further info/explanation, please review this issue redis/go-redis#575 (comment)
I want to analyze the lorawan packages ... any way to do it?
Hey !
I just stumble across a small issue. How to unmarshal a payload if you don't know by advance if its uplink or downlink ?
payload = new(PHYPayload) // or PHYPayload{}, doesn't really matter here
payload.UnmarshalBinary(raw)
PHYPayload.uplink
is false
by default, so, the above line is equivalent to:
payload = NewPHYPayload(false)
payload.UnmarshalBinary(raw)
But what if can't make the assumption whether the payload is relative to an uplink or a downlink ?
I feel a bit uncomfortable with having to handle externally to the PHYPayload
itself the way it is going to be marshalled or unmarshalled regarding to an unexported attribute. Do you agree ?
Shall we find a way to make unmarshalBinary
works in both cases in order to obtain the correct under-relying structure ?
Otherwise, each time one transmits a raw sequence of bytes representing a physical payload, one's also has to transmit whether or not its an uplink or downlink payload (this is obvious when you consider a context where the receiver / sender knows what they are doing, but considering libraries which manipulate payloads out of any context, this is not that straightforward).
As far as I see in the implementation, the uplink
attribute is only used by MAC commands to check if the payload refers to a valid command depending on its nature (commands are split into two groups, uplink-related commands, and downlink-related commands). Nevertheless, isn't the nature of the payload defined by the command (and not the opposite way) ?
Let me know,
Thanks.
Hi Brocaar!
It's me, again :)
Just summing up:
-> lora server-setup is ok, up and running
-> lora gateway bridge is correctly giving the outputs
-> lora server and lora server-app is running ok !
-> I know the node is activated, transmiting and receiving by the LoRa server analysing the "sents frames" on Gateway guide. (we've signal with a LED flash when node receive confirmed data).
So, lastly I could run the lorawan in Go packets!
I've installed Go and go tools correctly and also I've run the "golang -getting started" an some "golang examples" from repository on github.
I've prepared, install and build your packages from this repository, by using "go get github.com/brocaar/lorawan" so the packets are correctly installed on repository on my computer.
Questions:
It's possible run this program in the same local network? The server is in a PC "10.193.101.11" and i'am tryng to run the go package in "10.193.101.12". they are connected by a just by-pass router.
In case of running ok from different PCs how can I point? there is in the codes?
There is a ready example implementation that I can run and see the data from the node, please? Or I have to make the 'main" package with the import "github.com/brocaar/lorawan" command line and respectives functions in func main () ?
I will looking forward your answer!
Best Regards,
Rogerio
It seems that only the go language can receive such support.
Аt startup I get the following error:
FATA[0000] NetID parse error: lorawan: exactly 3 bytes are expected
[Service]
Environment="NET_ID=010203"
Environment="BAND=EU_863_870"
Environment="HTTP_BIND=0.0.0.0:8000"
Environment="POSTGRES_DSN=postgres://loraserver:dbpassword@localhost/loraserver$
Host platform: Raspberry PI3
Hi @brocaar,
And thanks for your awesome projects!
I'm working on a LoRa deployment for Australia and just seen that the current config for au915_928 is not compatible with "LoRaWAN™ 1.0.2 Regional Parameters" specs.
When we try to connect a 1.0.2 device, we get the error "get join-accept txinfo error: lorawan/band: the given data-rate does not exist" during the join request.
That's because 1.0.2 introduces new datarates for Australia.
I'm not sure the backwards compatibility are maintained between 1.0.0 and 1.0.2 so I don't know how to create a pull request for your project.
To start, i'll work on my own fork, but it could be good to integrate new datarates here.
Do you have any idea?
Thanks!
Hi, I’m trying to utilize 2.4GHz band for communication with a STM32 based sensor and although I’m getting the data consistently, I’m still seeing this error in the network server logs:
The frequency field is 24 bits, thus the max value is (2^24)-1) which is same for both Sub-GHz and 2.4GHz. Only difference is for 2.4GHz is that the frequency is multiplied by 200 instead of 100.
Hi,
I am in LORAWAN 1.0.2, and I am looking for the function that generates the NwkSKey and the AppSkey fromroot key (appKey).
I know it's two keys are generated in the generation of the join accept.
Are the two keys generated here?
*"lorawan / backend / join_request.go/" ====> func createJoinAnsPayload(ctx context) error
After I read RP2-1.0.3 LoRaWAN Regional Parameters. I found that the receive windows datarate value did not limit to DR5 as before. So I start to search for the beginning of this change. And found this value has changed in RP002-1.0.0.
So does this need to change?
Lines 73 to 75 in 63df695
Hi,
I'm trying to run the func ExamplePHYPayload_lorawan10Decode()
from phypayload_test.go.
The result i had is :
=== RUN ExamplePHYPayload_lorawan10Decode --- PASS: ExamplePHYPayload_lorawan10Decode (0.01s) PASS Process finished with exit code 0
But the output should be more detailed like :
// Output: // {"mhdr":{"mType":"ConfirmedDataUp","major":"LoRaWANR1"},"macPayload":{"fhdr":{"devAddr":"01020304","fCtrl":{"adr":false,"adrAckReq":false,"ack":false,"fPending":false,"classB":false},"fCnt":0,"fOpts":[{"cid":"DevStatusReq","payload":{"battery":115,"margin":7}}]},"fPort":10,"frmPayload":[{"bytes":"4mTU9w=="}]},"mic":"e117d2c0"} // [1 2 3 4]
There is a specific option i should add in the go test, to show all the information ?
M.A
Hi,
I am sending Confirmed downlink to a C type device.
I have observed the following:
"The downlink is not sent immediately to the device. The downlink is sent after the next uplink message. And if the device does not send ACK back to the server then the server keeps on sending the downlink after each subsequent uplink. It never stops."
Please help.
Returning an error in https://github.com/brocaar/lorawan/blob/master/fhdr.go#L198 stops processing of the entire message, while the LoRaWAN specification only says that "the first unknown MAC command terminates the processing of the MAC command sequence" (v1.0.1, bottom of page 22).
A simple break
would resolve this issue, but in some cases it might be good to log an error as well. (See https://github.com/TheThingsNetwork/lora-gateway-bridge/commit/d5662313741364a129709b9b522ef29eacce0438)
Hello Brocaar.
When I marshal PHYPayload struct with MacCommands in it, I always have the same name for MACcommand in both directions.
( (on pictures the same behavior we can see via redis pubsub in chirpstack)
I see that there is a String() method generated for CID so it has no idea about the direction and there is no simple solution.
Any plans or ideas on how to improve this?
In LoRaWan spec 1.1 and LoRaWAN Remote Multicast spec 1.0.0, the "Conventions" sections all mentions that fields with multiple bytes are transferred in little endian:
The octet order over the air for all multi-octet fields is little endian
But in the implementation, the "McKeyEncrypted" field which is 16 bytes long is just copied in its original order. Why is it not encoded in little endian form?
Is there any reliable way to change the RTC?
When I set the RTC date and time (HAL_RTC_SetTime / HAL_RTC_SetDate), the currently running timers (TimerEvent_t) may be broken!
We may need to stop all timers first, then change/set the date and time, and then restart the timers. But it's not quite easy ... How to do it easily?
EDITED: Sorry you are right I got the wrong repository!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.