[Peter Ferland]

In the US 915 band there are 64 uplink channels. The Conduit’s MTAC-LORA cards can listen to 8 channels at a time yielding 8 unique subbands. There are 8 downlink channels. The downlink channel used after an uplink is based on the uplink channel, dividing by 8 for private mode and modulo 8 for public mode.

For example, if a Conduit with a MTAC-LORA card is configured to listen on US sub band 1 it is listening on LoRa channels 0-7. If it received a LoRa packet on channel 3 it would respond on downlink channel 0 in private mode and channel 3 in public mode.

[Peter Ferland]

That is a strong possibility – LoRa (or any other 800-900MHz signal) will not make it through the ground very far! You can certainly see “dead spots” just like in a cellular phone network.

[Peter Ferland]

That should work. Are you using a LoRa input node? If so, go to the node’s configuration and confirm that it is in byte mode and not UTF-8 mode.

[Peter Ferland]

The IP67 gateway is the same hardware inside. Other than the addition of a PoE injector for power and a rugged external antenna it is the same hardware.

I checked survey data for other locations and have indeed seen RSSIs reported for connections between an mDot and MTCDT down to -133. -110 is the cutoff seen when there are a large number of 900MHz devices near the gateway.

[Peter Ferland]

Losing connection around -110 RSSI is typical. Regarding range, it depends greatly on the positioning of the gateway and node. The Conduit performs best when it is raised off the ground and the antenna is not close to any sheets of metal.

The longest advertised ranges are all unobstructed line of sight. If you have multiple obstructions (especially metal) between the transmitter and receiver range can be 500m or less.

[Peter Ferland]

What would you recommend instead for the XDot development board?

[Peter Ferland]

The API end point for lora is under api/loraNetwork. Specifically the eui and network keys are api/loraNetwork/eui and api/loraNetwork/key. If you are using hex EUI and keys be sure to set the ascii name and passphrase to empty strings.

For testing you can also try setting these options from the web interface to figure out what you’ll need to set.

• This reply was modified 7 years, 3 months ago by Peter Ferland.

[Peter Ferland]

Are you trying to secure the MQTT server running on the Conduit or creating a secure connection from the Conduit to another MQTT server? The built in MQTT nodes do not support certificate based authentication, but do support a username and password over tls.

[Peter Ferland]

By default leases do not expire. Even if you changed the lease time option it will not change the session keys – you’ve hard coded them through the manual join process.

[Peter Ferland]

Double check that the AppSKey you entered for the node matches what you’re using to encrypt the payload on the device.

[Peter Ferland]

Are you trying an OTA join or a manual join? It sounds like your device is sending a manual join request and the node is not already known by the Conduit.

To set up a manual join you’d have to follow the mLinux instructions on this page: http://www.multitech.net/developer/software/lora/conduit-mlinux-lora-communication/conduit-mlinux-lora-use-third-party-devices/
(this will work on an AEP conduit – the only difference is that the username will be admin)

[Peter Ferland]

Unfortunately the very low level logging that you’d need for this is not available.

The most common issue with third party devices is that by default the Conduits are in a “private” network configuration with the sync word set to 0x12. Unless configured differently, most LoRa devices will expect the sync word 0x34 which is the “public” network configuration.

On an AEP conduit you can change this on the “LoRa Network Server” page by checking the “Public” box.

[Peter Ferland]

There is extensive discussion on adding nodes to node-red on the Conduit in this thread: http://www.multitech.net/developer/forums/topic/adding-nodes-to-node-red/page/2/

Once you figure out what commands need to be run, you can execute them in the install script in a custom application package and use DeviceHQ to deploy the custom application to each of your gateways. http://www.multitech.net/developer/software/aep/creating-a-custom-application/

[Peter Ferland]

Conduit to Conduit LoRa communication is not supported currently – Conduits can only act as gateways.

mDots and xDots however can operate in peer to peer mode.

[Peter Ferland]

For a MQTT input node you are correct, there is no way to programmatically set the topic on an input using the built in nodes so you would have to create a custom node to handle that.

[Peter Ferland]

For MQTT topics the wildcard is ‘+’ so if you wanted to subscribe to every gateway’s input topic you would use “gateway/+/input”.

If you wish to put your own string there for a specific gateway’s serial number, you’d need to build the string in a javascript node and then set the string as the topic property in the msg.

[Peter Ferland]

You can also try using python with sqlite. You would just need the package python-sqlite3 to get started (ie, opkg install python-sqlite3 )

[Peter Ferland]

Do you see any different output if instead of:
var payloadRawData = new Buffer(msg.payload);
You use
var payloadRawData = new Buffer(msg.payload, 'base64');

[Peter Ferland]

You should be able to wire the LoRa input node directly to the MQTT output node – the LoRa input node outputs JSON encoded data. You can inspect it by wiring to a debug node and configuring it to show all packet data instead of just the payload.

[Peter Ferland]

Hi Chad,
Do you have deep_sleep set to true or false? If you have it set to “true” can you see if there is a different behavior for false?
What version of libxDot mbed-os are you using?

There is an old mbed bug for the STM32L1 series related to improper clock setup after restart from deep sleep. More detail including a resolution can be found on the mbed forum here: https://developer.mbed.org/questions/52467/Cant-read-ADC-after-WakeUp-from-deepslee/
Can you try putting the commands for manually resetting the HSI clock from the answer in that thread after the sleep command?

[Peter Ferland]

The developer guide reports a worst case inrush charge of 0.132mC over 153us – you can simply divide that to get a mean inrush current of ~0.86A. You will definitely need a larger regulator. The xDot developer board uses a SPX3819 LDO voltage regulator rated at 500mA nominal and transients up to 950mA. You can see the supply circuit on page 49 of the developer guide.

[Peter Ferland]

Regarding the DOT devices, they are based on STM32 microcontrollers and there is direct access to the MCU’s ADC and other peripherals. More details about the modules including code examples can be found on multitech.net or the devices’ mbed pages:
https://developer.mbed.org/platforms/MTS-mDot-F411/
https://developer.mbed.org/platforms/MTS-xDot-L151CC/

As for the LoRa network server, both AEP and mLinux Conduits run the LoRa network server out of the box.

[Peter Ferland]

Hi Alexey,
Can you describe the network setup you’re working with in more detail? The MultiConnect Conduit is a LoRa gateway. xDot and mDot are the LoRa edge point devices. Both mDot and xDot have UARTs that can be used for serial communication. With the appropriate circuitry and firmware either DOT could communicate with a device and then transmit the sensor reading over LoRa to the Conduit which then sends the reading over a backhaul (cellular or ethernet) to either the internet or your corporate network.

Thanks!
Peter

[Peter Ferland]

Hi Lucas,
If I understand your scenario you should be able to use one Node-RED flow on the “main” AEP Conduit. You would have one input node for whatever interface you’re using and then take actions based on that message to package and transmit the message to the appropriate server on your network. What would the additional flows be doing? Performance is going to depend more on the number of nodes and what each node is doing so it is difficult to answer without knowing more about what each flow would be doing.

[Peter Ferland]

Hi Lucas,
To reset the Conduit to factory defaults you need to hold in the reset button for a full 30s. After the 30s you will see the LEDs flash. Can you confirm that the reset switch was depressed for this long?

In addition to SSH, there are two micro USB ports that can be used to access a terminal. The port on the front of the Conduit behind a removable panel (one screw) provides debug access including the ability to enter u-boot. More detail on this debug port can be found here: http://www.multitech.net/developer/software/mlinux/using-mlinux/mlinux-configure-and-use-hardware-io/
Can you connect to the serial debug port and access the system from there?

[Author]

Posts