[Jason Reiss]

In the case of a private network the appeui can be chosen at random.
If you are using a public network or provider then the appeui may be assigned by them.

This forum also has lots of lora specific info
http://openlora.com/forum/viewtopic.php?f=15&t=796&p=1376&hilit=session+keys#p1376

[Jason Reiss]

Yes, this appears to be a bug in the 0.0.9.2 network server.

[Jason Reiss]

The LoRa Network Server provides and interface through MQTT or UDP.

Details and a sample app written in nodejs can be found here:

Conduit mLinux: LoRa Communication

[Jason Reiss]

Jonathan,

Please open a support case. We can provide the testing certifications there as we work on updating the regulatory info documentation on the website.

Thanks,

Jason

[Jason Reiss]

Default is empty. Maybe you had switched back and forth? The setting will stay if you choose the local network server.

Sample configurations to connect to Semtech demo site are here:
http://www.multitech.net/developer/software/aep/aep-lora-packet-forwarder/

[Jason Reiss]

The session keys need to match on both sides.
The nwkskey is used to compute the MIC (message integrity check)
The appskey is used to encrypt the data

[Jason Reiss]

Conduit mLinux: LoRa Use With Third-Party Devices

[Jason Reiss]

By “Yep!” you mean AEP 1.1.2?

You can double check the network server version with
/opt/lora/lora-network-server –version

With the lora-network-server 0.0.9 the port should be in the MQTT up packets and is an option for down packets.

Just set the port in the packet sent to the lora out node.

[Jason Reiss]

Are you running the latest AEP version?

Downloads

[Jason Reiss]

I created a document for the network server commands

LoRa Network Server

[Jason Reiss]

The flash part can be corrupt if it is not provided with enough current.
Low battery operation may have caused the memory loss.

Does the device report errors in the debug output?

[Jason Reiss]

The device id is stored in flash. Open a support portal case and we can help get the id reprogrammed.

support.multitech.com

[Jason Reiss]

The network server will wait until the last moment before a packet needs to be sent in case the application has data to send with the current downlink. We have found that occasionally the network server cannot service the packet to be sent the radio before the timestamp expires.
Increasing the priority of the network server and packet forwarder reduce the occurrence of a late packet. Our next release will contain this fix.

renice -n -20 $(pgrep lora-network-se)
renice -n -20 $(pgrep basic_pkt_fwd)

mDot.h – you case pass false as the second parameter to do non-blocking send.

/** Send data to the gateway
         * validates data size (based on spreading factor)
         * @param data a vector of up to 242 bytes (may be less based on spreading factor)
         * @returns MDOT_OK if packet was sent successfully (ACKs disabled), or if an ACK was received (ACKs enabled)
         */
        int32_t send(const std::vector<uint8_t>& data, const bool& blocking = true, const bool& highBw = false);

[Jason Reiss]

It is base64 encoded so any bytes can be sent via json string using plain ascii characters.

There is no setting that would allow you to change it.

[Jason Reiss]

It is base64 encoded so any data can be passed via json string.

> echo MTExMTEx | base64 -d
111111

[Jason Reiss]

In our current releases the counter is not saved in NV.

In our upcoming release session information can be saved in NV or uplink/downlink counters can be maintained outside of the library.

Please open a support case if you would like to work with release candidate software.

[Jason Reiss]

You could also disable the network server in the GUI.

[Jason Reiss]

Here is the AEP documentation with sample conf files for EU868 and US915.
http://www.multitech.net/developer/software/aep/aep-lora-packet-forwarder/

[Jason Reiss]

Here are the downlink parameters the mote should be listening with.
“codr” : “4/6″,
“datr” : “SF7BW500″,
“freq” : 925.10000000000002,

In the LMIC code they attempt to open the rx window 1.5 symbols into the preamble. Others have been able to get this working by removing the offset.

// Called by HAL once TX complete and delivers exact end of TX time stamp in LMIC.rxtime
static void txDone (ostime_t delay, osjobcb_t func) {
...
    // Setup receive - LMIC.rxtime is preloaded with 1.5 symbols offset to tune
    // into the middle of the 8 symbols preamble.
...
        LMIC.rxtime = LMIC.txend + delay + (PAMBL_SYMS-MINRX_SYMS)*dr2hsym(LMIC.dndr);
        LMIC.rxsyms = MINRX_SYMS;
    }
    os_setTimedCallback(&LMIC.osjob, LMIC.rxtime - RX_RAMPUP, func);
}

static void schedRx2 (ostime_t delay, osjobcb_t func) {
    // Add 1.5 symbols we need 5 out of 8. Try to sync 1.5 symbols into the preamble.
    LMIC.rxtime = LMIC.txend + delay + (PAMBL_SYMS-MINRX_SYMS)*dr2hsym(LMIC.dn2Dr);
    os_setTimedCallback(&LMIC.osjob, LMIC.rxtime - RX_RAMPUP, func);
}

Remove this offset in both functions

+ (PAMBL_SYMS-MINRX_SYMS)*dr2hsym(LMIC.dndr)

• This reply was modified 9 years, 1 month ago by Jason Reiss.
• This reply was modified 9 years, 1 month ago by Jason Reiss.
• This reply was modified 9 years, 1 month ago by Jason Reiss.

[Jason Reiss]

James,

The log cut off just before it got interesting. Can you open a support case to exchange files more easily?

Have you tried to enable the hybrid mode in LMIC and use frequencySubBand 1 on the Conduit?

[Jason Reiss]

James,

Can you set the log level to 50 or 60 as shown below to get more info in the lora-network-server.log

“log” : {
“level” : 60, /* error=10, warn=20, info=30, debug=50, trace=60, max=100 */
},

Just to confirm you still have these settings on conduit.
"network" : { "public" : true }
and
"lora" : { "frequencySubBand": 7 }

[Jason Reiss]

If you increase the logging level to debug you should see the frequencies received and attempting to transmit on.

What frequencies are you expecting?

[Jason Reiss]

Roman,

That is exactly how we have the bands setup.

Here is the latest reference doc I could find.
http://www.erodocdb.dk/docs/doc98/official/pdf/rec7003e.pdf

We have noticed that Semtech is following note 5 for h1.3 LoRaMAC-node reference implementation.

Note 5: Duty cycle may be increased to 1% if the band is limited to 865-868 MHz.

This will not allow frequencies that fall between the defined bands above 868 to be used. Making 869.3 invalid.

[Jason Reiss]

The Transmit datarates take into account waiting for rx windows in LoRaWAN.

In the LoRaWAN protocol a device cannot transmit until it has received a downlink packet or both rx windows expire.

The highest uplink datarate in LoRaWAN for US is SF8BW500.

Regarding the dwell time. You will need to hop channels between packets for 400 ms average dwell time of a period of time relative to the number of frequencies.

[Jason Reiss]

If you are using the network server on the Conduit then it is fine to be a random value and ensure uniqueness locally.
A device will only be able to join if it has the app-eui and app-key corresponding to that Conduit.

If you were joining a public network, yes then it would be important to ensure global uniqueness.

[Jason Reiss]

The “gateway_ID” will be auto-populated with an EUI from the MTAC-LORA card installed in the Conduit, so you don’t need to configure that.

If you want to know the EUI value login into the GUI and query the api
https:///api/system/accessoryCards

Change “serv_port_down” and “serv_port_up” to 1700 and “server_address” to “croft.thethings.girovito.nl”

You can also change the crc settings if you wish to match the TTN example below. CRC failed messages can be filtered at the gateway, no sense sending them over the internet.

From things network doc:

{
  "gateway_conf": {
      "gateway_ID": *YOUR_OWN_SERIAL*,
      "serv_port_up": 1700,
      "serv_port_down": 1700,
      "server_address": "croft.thethings.girovito.nl",
      "forward_crc_valid": true,
      "forward_crc_error": false,
      "forward_crc_disabled": true
  }
}

[Jason Reiss]

Each Dev EUI has an OUI prefix.
The OUI prefix can be registered with IEEE to ensure global uniqueness of each assigned EUI.
https://en.wikipedia.org/wiki/IEEE_Registration_Authority

mDot are assigned an EUI using the Multitech OUI

The frequencySubBand configures the radio for eight 125k and a one 500k upstream channels. In private mode one downstream channel will be used for each subband.

Issuing AT+TXCH on an mDot will list the channels

at+fsb=7

OK

at+txch
0: 911900000 125k
1: 912100000 125k
2: 912300000 125k
3: 912500000 125k
4: 912700000 125k
5: 912900000 125k
6: 913100000 125k
7: 913300000 125k
U: 912600000 500k
D: 926900000 500k

OK

[Jason Reiss]

The above posts had the ‘”‘ elements changed to not be quotes.
I have fixed the above posts. Let me know if it works now.

[Jason Reiss]

Here is a curl example that works.

curl 127.0.0.1/api/loraNetwork -X PUT -d '{"udp":{"allowPublic":true}}' -H "Content-Type: application/json"

• This reply was modified 9 years, 2 months ago by Jason Reiss.

[Jason Reiss]

I am seeing the issue using curl.

However if you web to the Conduit web gui.
When entered through the browser URL after logging in the query is accepted.

https://[AEP-IP]/api/loraNetwork?method=PUT&data={"udp":{"allowPublic":true}}

• This reply was modified 9 years, 2 months ago by Jason Reiss.

[Author]

Posts