Home > Best Practices

LoRa Technology and MultiTech Products FAQ

Introduction

Welcome to the MultiTech LoRa Technology and MultiTech Products FAQ!  LoRa is an amazing technology, but still relatively new to the IoT market.  As such, MultiTech regularly receives questions about LoRa technology and how MultiTech has implemented it in our products from various players in the market:  prospects, customers, channel partners, ecosystem partners, analysts and hobbyists.  As a result, we have created this document to answer the questions we are most frequently asked. 

This FAQ will be updated on a regular basis and posted on MultiTech’s LoRa microsite at lora.multitech.com.  Be sure to check out the “Best Practices” section of the MultiTech LoRa microsite (http://lora.multitech.com/best-practices-gallery) as that contains detailed documents addressing some of the questions from this FAQ.
 

HARDWARE/ANTENNA FAQ

H1: What is the mDot's input voltage range?
A1: 3.5Vdc - 5Vdc

H2: Which frequencies are supported by the mDot?
A2:  Specifically, 868 MHz (860-870Mhz) (Europe), 915 MHz (902-928Mhz)(North America).

H3: Which microcontroller is used on the mDot?
A3:  STM32F411RE

H4: How much flash/RAM is available on the mDot?
A4: 512 KB Flash (400 KB customer usable), 128 KB RAM

H5: What IO are available on the mDot?
A5: mDot has 6 digital I/O, 2 analog, SPI, I2C, and UART. The I/O is directly connected to the microcontroller. 
      The microcontroller has multiplex functions on the pins, so there are multiple options for the I/O. 
      The default pin assignments match the I/O for a standard Xbee type interface.

H6: What are the A/D converter characteristics of the mDot?
A6: Resolution 12 bits, Range: 0-3.3 VDC for VCC > 3.6 VDC Conversion speed 2.4 Mbps maximum

H7: What is the mDot's sleep/active current?
A7: The latest Dev guide has the information:   http://www.multitech.com/documents/publications/manuals/s000612_6.pdf 

H8: What is the battery life of the mDot?
A8: The mDot itself doesn't have a battery. When connected to a system utilizing a battery for power, then battery life will depend on usage: 
      e.g. how much data and how frequently is it being sent, spreading factor, how far away is mDot from gateway, single or bi-directional traffic

H9: Is the mDot XBee footprint pin-for-pin compatible?
A9: Yes

H10: Why does the mDot look like an XBee device?
A10: The mDot is pin-for-pin compatible with XBee devices. However, as of March 2015 they do not support the XBee command protocol.   One of the applications for the mDot is as a replacement module for applications that use Xbee footprint compatible module, but need the improved range performance of LoRa.

H11: Which antenna is certified for mDot?
A11: MultiTech certified the Pulse W1063 antenna for use with mDot and MTAC-LORA.
       However, any RSMA antenna that meets the performance requirements published in the mDot FCC (or ESTI) certification can be used without re-certification.

H12: Can I attach my own coax for longer antenna runs?
A12: Conditionally, yes, but only if the performance of the resulting antenna system meets the performance requirements published in the mDot FCC (or ESTI) certification.

H13: How do I design my own Printed Circuit Board (PCB) antenna?
A13: MultiTech has no PCB antenna designs published in its certification specifications, so any design using a PCB antenna would need additional certification testing.  There are future plans to certify specific chip and/or PCB antenna designs. Recommended design layouts would be supplied at that time. 
 

H14: Do you have an enclosure for the mDot?
A14: We have created an MTDOT-BOX, which contains an mDot enclosed in a chassis.  The MTDOT-BOX supports Site Survey and has accelerometer, pressure, ambient light, temperature and electrical current sensors to enable quick LoRa POC creations.  There is also a board only version called the MTDOT-EVB, which support LoRa and POC testing and developing.  These products will be commercially available in February 2016 and can be purchased on a limited basis today.   If you need assistance in developing a box for deployment, please contact us to discuss.

        
H15: Will external antenna designs outperform internal antenna designs? If so, then by how much?
A15: In general an external full dipole antenna will always perform better than internal chip or PCB strip line antennas. 
       Performance difference can be 2 dBi or more. 
       Also external antenna can be placed in more ideal locations to improve performance.

H16: What distances can the mDot cover?
A16: Typical usage will give you 1-2 miles in typical urban settings.  A true line of site application could go further depending on height of antenna – as much as 10 miles, though we most frequently see 5-10 miles direct line of site performance with our customers.
       
H17: Can I use my own processor?
A17: Yes. The mDot ships with an AT command (modem-like) interface so that you can send data from your processor using AT commands.   The AT commands would also be used to set modes of operation.

H18: Can the mDot firmware by customized?
A18: Yes. By using the ARM mbed ecosystem you may customize the functionality of the mDot.  The mDot is ARM Embed Enabled.

H19: What is ARM mbed?
A19: ARM mbed is a free, open-source platform and operating system for embedded devices based on 32-bit ARM Cortex-M micro-controllers.  For more information, go to https://www.mbed.com/en.

H20: How do I program the microcontroller on the mDot?
A20: The microcontroller is programmed using the ARM mbed ecosystem.  Compile in the cloud or compile locally, copy the resulting binary file to the mbed USB drive, and reset the mDot.  An ST-Link/mbed compatible programmer is also required, such as the Multitech UDK 2.0.

H21: Will MultiTech provide source code or just binary libraries?
A21: Source code will be provided for all portions of software that are not directly connected with control of the RF portion of the mDot and MTAC-LORA card. In order to receive FCC and ETSI module certification, certain portions of the software will be released as binary libraries only.


General LoRa - mDot FAQ

M1:  What is Spreading Factor? Bandwidth?
A1:  Spreading Factor: Basically, it is the amount of redundant data that is transmitted to increase the success of a completed message being assembled by the receiving end. The higher the spreading factor, less data rate and longer range (e.g. more redundant data).  Higher spreading factors are used the further away the mDot (or LoRa endpoint) is away from the gateway.
    Bandwidth: The frequency range (in hertz) of the transmitted signal.

M2:  Can I configure the mDots and mCards for LoRa spread spectrum mode or FSK mode?
A2: FSK mode is not supported at this time.

M3:  What is the LoRa transport packet size?
A3: The maximum transport packet size is 255 bytes plus preamble.  But, due to on-air transmission restrictions (e.g., the FCC limits on-air transmission time to 400 mS in the U.S.), the maximum packet size may be smaller.  Higher spreading factors, lower data rates, and longer preamble lengths will reduce the maximum allowed transport packet size.

M4:  How much payload in each LoRa packet?
A4: The maximum payload is 242 bytes. This all depends on the spreading factor used.

M5:  Is there a way to increase the limit/size of the payload?
A5: The major limit to packet size is due to on-air time or duty cycle restrictions.  It is not possible to increase the packet size and maintain FCC or ETSI certification.

M6:  Is there a minimum waiting period between transmission from the client radio?
A6:  By default, the radio waits for incoming packets for 2 seconds after a transmission.  This time can be reduced, see commands AT+RXTO and AT+TXW in the dev guide - http://www.multitech.com/documents/publications/manuals/s000612_6.pdf 
    
M7:  What kind of security does LoRa provide? Is the data encrypted?
A7:  The MDOT and Conduit use AEA128 bit encryption for transmission.

M8:  Do all LoRa gateways in range see all mDots in the field? How would I isolate my mDots so other gateways don't receive my data?
A8:  Since this is RF, all gateways in range of an mDot would see the mDot.   Packet encryption, network keys, and channel selection can be used to force an mDot to only communicate with one gateway.   Encryption keys are generated when an mDot joins a specific network using nonce values and a pre-shared network key.  If each gateway in range of an mDot uses a different encryption key, they will only be able to process packets from mDots with matching keys.

M9:  Does mDot/MTAC-LORA send bidirectional data? Is it half-duplex or full-duplex communication?
A9:  Since this is single-channel RF on the mDot side, all communication is half-duplex.

M10:  Can the LoRa gateway interrogate mDots in the field or are only the mDots able to initiate communication to the Gateway?
A10:  Yes, the gateway can transmit data to the mDots. The MTAC-LORA card has a single beacon transmit channel that can transmit to 1 or more mDots.

M11:  For Serial mode, is this like setting up a stream that will transmit when the SDxx values are met? Serial mode still has a packet and payload?
A11:  LoRa transmits only in packets. There are limits on the size of a packet based on on-air time restrictions.  In serial mode the mDot will wake up at the expiration of the +SDWI value. It will set the XBEE_ON_SLEEP pin, and wait the +SDWD value in ms.  Then it will read the serial data until the +SDTO time elapses without a byte on the serial port.  It will place the received data into a packet and send it out the radio.
      
 Serial mode will automatically packetize data from the serial port and send based on the settings for:
        AT+SDWI - how often to expect data
        AT+SDTO - timeout between characters to know end of data
        AT+SDWD - time to wait at beginning of interval for data to arrive on serial
 Serial mode will only send one packet per time period set by the ATSWI command.
 
AT mode will send packets as fast as the controlling system can send them within the confines of physical limitations and FCC, or other, regulations.

When serial data mode is enabled, the mDot follows the process below:
        - mDot goes to sleep until the AT+SDWI interval (seconds) is reached 
        - mDot wakes up
        - mDot starts accepting serial data 
           * goes back to sleep if no data received within AT+SDWD milliseconds
        - If it starts receiving data, the mDot will receive until no data is received for AT+SDTO milliseconds
        - At that point, the mDot transmits received data and goes back to sleep (toggling the sleep pin again)
        - AT+SDWI seconds from when the mDot last went to sleep, it will wake up and repeat this process
    * Note: The +++ escape code must be sent in the window when the mDot is awake.


M12:  How many mDots can attach to a MultiConnect Conduit with LoRa support (e.g. MTAC-LORA)?
A12:  Approximately 3500 mDots per MTAC-LORA card. A Conduit can support 1-2 MTAC-LORA cards, but firmware as of 8/28/2015 only supports one (1) MTAC-LORA card.  The greatest variable in determining the number of nodes/mDots that can be supported is the frequency each device will be reporting and whether or not a response is required for each packet.  A single SX1301 (used in the MTAC-LORA) can receive up to 8 packets simultaneously but can only transmit a single packet at a time. Also, while it is transmitting it cannot receive.   Therefore, the approximate support for 3500 mDots is a rough estimate based on devices reporting hourly, half of which may require acknowledgements.
 

M13:  According to AT&V, the RX Timeout is 3000 ms. Is this the lockout period to prevent a new transmission? Does lowering this lower the lockout period?
A13: The RX timeout parameter is the time value the mDot waits for an incoming packet and is configurable per the LoRaWAN 1.0 specification.   It will open two RX windows. The first at one second after end of transmission, the second at two seconds after end of transmission.   The AT+SEND command is expecting to display a received packet payload if it arrives.  If a packet is not expected then this timeout can be reduced which will effectively ignore any received packets.

M14:  Where do I find the UDK2 ST Windows serial driver and ST micro data sheet
A14:  https://developer.mbed.org/teams/st/wiki/ST-Link-Driver 
     http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1877/PF260049

M15:  Can you point me to where these air restrictions are listed or defined?  Also, are these air restrictions hardcoded into your devices?
A15:  In the 915 band (US), the FCC limits us to a maximum of 400ms on air per transmission.  Our software ensures that you are meeting FCC regulations and, in fact, prevents you from breaking them.  We use the 400ms time on air to calculate the maximum packet size based on the set data rate/spreading factor.  With a high spreading factor of 10 (AT+TXDR=10), we can only transmit 11 payload bytes within 400ms.  At this setting you get longer range but less throughput.
     Check here for latest information on Lora:
     http://www.multitech.net/developer/software/lora/introduction-to-lora/

     This is in the FCC regulations, and it's repeated in the LoRaWAN spec. 
     There is a link on the this page to request the LoRaWAN specification
     http://www.lora-alliance.org/

M16:  Will the external flash be accessible for users to use?
A16:  We have added this function to the latest mDot library.  Included will be the ability to move a user file into the upgrade area of flash to be installed on next boot.
      https://developer.mbed.org/teams/MultiTech/code/libmDot/ 

M17: How can I calculate the actual bit rate and time on air for a LoRa system?
A17: http://www.multitech.net/developer/software/lora/introduction-to-lora/ 

     Here is a LoRa calculator from Semtech:
     http://www.semtech.com/apps/filedown/down.php?file=SX1272LoRaCalculatorSetup1%271.zip


Conduit FAQ

C1: How do I get started with my AEP Conduit?
A1: www.multitech.net/developer/software/aep/getting-started-aep/

C2: What version of Node Red are we shipping with the Conduit AEP? We are looking to use MQTT-TLS want to confirm that the Conduit Node-Red will support.
A2: AEP currently ships with Node-RED 0.10.4 and Nodejs 0.8.28

C3: I need to support other brand Class A Devices. I am working with microchip RN2483 + the LoRaWAN LoRaMote devices.
      Does Conduit Lora firmware support, OTA and ABP join modes?
      Where do I find the details and setup. 
      For OTA Join {AppEui,AppKey}
      For ABP Join {NwkSKey,AppsKey}
A3: http://www.multitech.net/developer/software/lora/conduit-aep-lora-communication/aep-lora-use-third-party-devices/

C4: How do I find out the version number for the Network Server and Package Forwarder?
A4: To list the currently installed versions of LoRa packages on Conduit:
$ opkg list | grep lora
Upgrade page for mLinux:
http://www.multitech.net/developer/software/mlinux/using-mlinux/upgrade-lora-server/
Upgrade page for AEP:
http://www.multitech.net/developer/software/aep/upgrading-the-aep-firmware/