Jason Reiss
Forum Replies Created
-
AuthorPosts
-
Jason Reiss
KeymasterThat console is connected to the conduit. It is the linux environment.
Try another port to connect to the Dot. Drivers may be needed before the ports appear in windows.
https://docs.mbed.com/docs/mbed-os-handbook/en/5.1/getting_started/what_need/KeymasterHave a look at the following documentation on our site.
For using node-red on a pc please refer to this documentation.
https://nodered.org/docs/Please let us known if you have specific questions or issues following these guides and tutorials.
KeymasterIn Node-RED on the Conduit use a lora-in and debug node to see the packet data in the debug log.
If you want to send this data to a remote server TCP,UDP,HTTP or MQTT nodes can be used to connect.
If you want to manipulate the data before sending to the remote server use a function node between the lora-in and the selected TCP,UDP,HTTP or MQTT output nodes.
UDP and TCP nodes will require the least amount of configuration.
KeymasterCheck
# lora-query -nDoes a node with DevAddr 00000001 appear in the list?
Remove the existing record
# lora-query -d 00000001Fields needed to add a new OTAA device record.
# lora-query -a <NET-ADDR> [CLASS] <APP-EUI> <DEV-EUI> [APP-KEY]-
This reply was modified 7 years, 4 months ago by
Jason Reiss.
KeymasterThe first Adr downlink is used to setup the channel mask to the channels supported by th e gateway in case a device joined with 64 channels enabled.
The datarate is not adjusted until 6 uplinks have been received to determine best datarate.
Max tx power is gw transmit.
Dwell time is only used in AS923.Keymaster# curl 127.0.0.1/api/loraNetwork -X PUT --data '{"lora":{"enableStrictCounterValidation":false}}' -H "Content-Type: application/json" # curl 127.0.0.1/api/command/save -X POST --data ""KeymasterYou have this result in response to what exactly?
KeymasterWhat issues are you having with compiling the provided examples?
KeymasterSince the join happens at the Gateway there is no round trip to a set of remote servers that requires a possible long delay.
The LoRaWAN spec defines the default, however these changes to the default settings require out-of-band configuration of end-devices.
KeymasterWhat browser are you using?
This tool can be used to remove the white space, this should cut down the size below 4000.
https://codebeautify.org/jsonviewerKeymaster36:21 shows 35-b3-3e-20 join request with nonce 6b9b
Same nonce is used at 36:27KeymasterThe end-device needs to provide a new nonce value with each join request.
A join request using the same dev eui and nonce value is not valid.
The nonce values are held in memory so a restart of the network server should allow the joins.
The real issue is still the end device stack RNG
KeymasterTurn off wifi and manually configure your ethernet port to:
IP: 192.168.2.100
Mask: 255.255.255.0
Gateway: 192.168.2.1After this is working, turn wifi back on and google configuration tips for wifi and ethernet.
This will depend on operating system.KeymasterThat is correct.
A single gateway card can listen on 8 – 125 kHz channels, 1 – Fixed Lora datarate channel (US:DR4:SF8BW500) and 1 – FSK channel (EU) simultaneously.
If max datarate is set to DR4 then the close end-devices will use DR4 on only one channel.
Of course the effective bandwidth of one 500 kHz channel vs eight 125 kHz channels is halved so the datarate increase has a trade-off.
It may be best to use DR3 as max datarate for ADR and use DR4 for special cases.
KeymasterUse a function node to reformat your message and send to your app tcp connection?
November 28, 2017 at 11:07 am in reply to: MQTT topics published to by LoRaWAN network server. #21913KeymasterThe documentation has been updated prior to an upcoming release.
More details to come.KeymasterPlease open a case at support.multitech.com to discuss early access.
KeymasterIf you have MTAC-LORA 1.0 with USB there is no update to version 2 protocol available.
When version 2 protocol was released the USB support in the lora-packet forwarder was removed. Now only SPI is supported.
MTAC-LORA-H 1.5 SPI card will be needed to use the version 2 protocol.
KeymasterDo you request ACK from the end-device for class C downlinks?
The current implementation will transmit a Confirmed downlink once and wait for uplink.
The packet will stay queued until ACK is received as with class A but there is no timeout implemented in the current release that will replay the downlink.We are testing a new release with major improvements to downlink scheduling with retry max settings and ACK retry timeouts.
KeymasterThe current end-device datarate is provided with the uplink.
Downlink datarates use DR8-DR13 in US915
Response to uplinks using DR0-DR4 in Rx1 use DR10-DR13 which all allow 242 bytes payload.
DR8 allows 53 bytes and is default Rx2 datarate. Rx2 datarate can be set at network server to DR10 and the setting will be transmitted to the end device on OTAA join.
KeymasterThe USB MTAC-LORA cards are supported only with the version 1 protocol packet forwarder.
An MTAC-LORA-H card will be needed to use the SPI interface of the version 2 protocol if the network server supports only version 2.
KeymasterSounds good. Just wondering if there was something you still needed from the server side.
Cheers.
KeymasterThe mtac-card 1.0 is USB.
The non USB utils need SPI interface.KeymasterWhat do you propose as a better solution?
Adding a configuration option to not queue the downlink? Your application is already able to override the default behavior. What more is desired?
Additional information for OTA nodes is required to be sent in the first downlink.
Otherwise the device may assume it can use unavailable channels.
KeymasterThe spectral scan requires mtac-lora-h card with v31 fpga firmware.
$ mts-io-sysfs show lora/*
KeymasterClass C is supported.
The xDot module is fully programmable using os.mbed.com online compiler or offline sdk.
KeymasterTry entering the escape sequence +++
This should exit the join sequence of AT command mode if the device was configured AT+NJM=2Then configure for regular join mode.
AT+NJM=1
AT&WOtherwise the config can be erased from the bootloader.
Press enter directly after reset button is pushed in a debug port terminal.bootloader :> erase lora.cfg
KeymasterHave you looked at the xDot module? 1.8 uA sleep with RAM retained so rejoin on every wakeup is not necessary.
It also allows saving session to flash for full power down.
KeymasterCheck also the frequency accuracy of the node. 15-20 Khz off can cause bad packets.
Keymaster1.0.13 will have crc enabled on downlink packets.
I have only seen corrupt packets when the crc settings are mismatched between gw and node. Perhaps try enabling crc on the node to experiment.
Have you tried swapping cards to rule out hw issue?
-
This reply was modified 7 years, 4 months ago by
-
AuthorPosts