No. ADR does not override the frequency channel but enable the use of the pre-configured channels through a channel mask. 

The maximum number of uplink channels is dependent on the PHY band in use. PHY bands like the European one handle a maximum of 16 channels. 3 default channels which can't be modified + 13 channels which can be created/deleted/enabled/disabled. PHY bands like the US915 handles a maximum of 72 channels. They exist all the time but can be enabled/disabled according to the local regulator rules. PHY bands like the CN470 handles a maximum of 96 channels. They exist all the time but can be enabled/disabled according to the local regulator rules. The channels are defined as described below. Channel frequency between 100 MHz and 1.67 GHz in 100 Hz steps. Data rate range (min. and max.)

Yes, LoRa technology can potentially apply to any frequency band, although its spread-spectrum nature makes it more relevant when at least a few MHz of spectrum is available.Currently, the use of LoRa is limited to the bands of frequency proposed in the SX1276 device. Our next generation devices will implement continuous coverage from VHF to 1 GHz.

Antenna diversity has been tested in the field. Mathematically, one would expect a 3dB gain in link budget with two antennas vs. a single one. The important effect with antenna diversity is that when one antenna is in a deep fade, the other can sometimes been seen to report a 10-12dB gain in signal-to-noise ratio. The uncertainty of the time-stamping in the gateway is significantly improved as signal-to-noise ratio rises. The uncertainty of the time-stamping rapidly rises as the signal approaches the extent of the sensitivity. Therefore, when a gateway is close to the maximum range, or simply in a deep fade caused by strong multipath the antenna diversity can make all the difference between presenting a usable time-stamp and one that is simple thrown away. Statistically the field test data show that increasing antenna diversity form one to two reduces the average uncertainty by 20%. In this test, both antennae were vertical 5dBi omni-directional spaced 1 meter apart horizontally. See the graph below for further details: 

The MAC command RXParamSetupReq/Ans are used to change the RX windows parameters (including the delay between end of TX and start of RX window). This command is acknowledged by a RXParamSetupAns uplink from the device. However if the acknowledgement uplink is lost , the network server has no ways to know if the device did or did not changed the timing , therefore the device can become unreachable.

This issue is addressed by the LoRaWAN specification starting at version 1.0.1 and GitHub LoRaMac-node firmware starting at version 4.3.0.

Mainly the solution is to make RXParamSetupAns and RXTimingSetupAns sticky up until a downlink from the server is received by the end-device.

Please refer to LoRaWAN 1.0.1 specification chapters 5.4 and 5.7 "The RXParamSetupAns / RXTimingSetupAns commands should be added in the FOpt field of all uplinks until a class A downlink is received by the end-device. This guarantees that even in presence of uplink packet loss, the network is always aware of the downlink parameters used by the end device."

Please note that for end-devices based on versions prior to 1.0.1 of the LoRaWAN specification there is no real solution.  

Tx Power: this should be done with a power-meter or a spectrum analyzer (SA). If using the latter, make sure that the RBW (Resolution Band Width) is made large enough (typically 1MHz for a LoRa BW of 125kHz) to integrate the whole power during CSS modulation. Ensure that the transmitter is set to Tx Continuous mode for this test.

• Channel masks should be checked with a SA, according to the latest EN 300-220.
• Spurious emissions and harmonics should be checked as with any other RF transmitter, also in accordance with the European norm.
• Sensitivity measurement should be performed with a Packet Error Rate (PER) test, as opposed to Bit Error Rate (BER) test, because of the nature of the LoRa modem. At present, none of the instrumentation vendors supports LoRa modulation natively (unlike Wi-Fi or BT for instance). Therefore, we need to use an Arbitrary Waveform Generator (ARB) to perform this test. Semtech supports Rohde &Schwarz's (R&S) SMBV100A ARB, and can provide pre-calculated frame in .wv format in order to perform tests.

LoRa Alliance is an open, non-profit association of members that believe the internet of things era is now. Our mission to standardize Low Power Wide Area Networks (LPWAN) being deployed around the world to enable Internet of Things (IoT), machine-to-machine (M2M), and smart city, and industrial applications. The Alliance members will collaborate to drive the global success of the LoRa protocol (LoRaWAN), by sharing knowledge and experience to guarantee interoperability between operators in one open global standard.

In other words, the Alliance drives the standardization of LoRaWAN such that sensors can be connected anywhere around the world where network operators roll our LoRaWAN networks. The driving forces behind the Alliance are the Mobile Network operators and big industrial companies who all benefit from one global standard: LoRaWAN.

For a short introduction on the LoRa Alliance check this animation. 

The LoRa Alliance defines the processes for certification of modules, modems and sensors related to the LoRaWAN compliance. The actual certification is executed by test houses around the world and us such a company does not need to be a member of the LoRa Alliance to certify a module, modem or sensor.

When using a pre-certfified module or modem the sensor does not need to be certified for LoRaWAN compliance again. However additional certification for ETSI or FCC compliance (related to output power and duty cycle) will be required for any sensor before it can be subscribed to a LoRaWAN network.

For further information please check the LoRa Alliance website  or send an email to [email protected] 

Out of the 50 billion predicted nodes to be connected to the Internet by 2020 fewer than 10% are predicted to use cellular technology. Telecommunications companies will need long range, high capacity systems to consolidate the fragmented battery operated wireless market for sensor networks, smart cities, smart metering, security systems, smart home, and industrial control.

With our LoRa RF platform, we have developed a 2-way wireless solution that complements M2M cellular or WiFi infrastructure, and provides a low-cost way to connect battery operated and mobile devices to either the network infrastructure or end point.

To visit Semtech's LoRa website click here.

LoRa is a wireless technology that has been developed to enable the Internet of Things using unique low data rate communication to be made over long distances by sensors and actuators. As LoRa technology is able to provide a wide area network capability, it is often referred to as LoRaWAN.

A LoRa network consists of several crucial elements to build an Internet of Things solution:

End points:  The endpoints are the elements of the LoRa network where the sensing or control is undertaken. They are normally remotely located.

LoRa gateway:  The gateway, also referred to as Base Station or concentrator, receives the communications from the LoRa endpoints and then transfers them onto the backhaul system. This part of the LoRa network can be Ethernet, cellular or any other telecommunications link wired or wireless. The gateways are connected to the network server using standard IP connections. On this way the data uses a standard protocol, but can be connected to any telecommunications network, whether public or private. In view of the similarity of a LoRa network to that of a cellular one, LoRa gateways may often be co-located with a cellular base station. In this way they are able to use spare capacity on the backhaul network.

Network server:  The LoRa network server manages the network and provides OSS, BSS and billing functions. The network server acts to eliminate duplicate packets, schedules acknowledgement, and adapts data rates. In view of the way in which it can be deployed and connected, makes it very easy to deply a LoRa network.

IoT Application:  applications connected to the network server can control the actions of the endpoints or collect /send data - the LoRa network being the transparent, secure and scalable connectivity layer.

The LoRa gateways are designed to be used in long range star network architectures and are utilized in a LoRaWAN system. They are multi-channel, multi-modem transceivers, can demodulate on multiple channels simultaneously and even demodulate multiple signals on the same channel simultaneously due to the properties of LoRa. The gateways use different RF components than the end-point to enable high capacity and serve as a transparent bridge relaying messages between end-devices and a central network server in the backend. Gateways are connected to the network server via standard IP connections while end-devices use single-hop wireless communication to one or many gateways. All end-point communication is generally bidirectional, but also supports operation such as multicast enabling, software upgrade, over the air or other mass distribution messages to reduce the on air communication time. There are different gateway versions depending the desired capacity and installation location (home versus tower). 

A LoRa Gateway is buit using the SX1301 whereas the final product operates as a base station in a LoRa Network. The base stations sends/receives all data to and from the sensors (end nodes) and is connected (backhaul) to a network server (OSS/BSS) for further processing of the data.

The LoRa® modulation is the PHY, and LoRaWAN is a MAC protocol for a high capacity long range and low power star network that the LoRa Alliance™ is standardizing for Low Power Wide Area Networks (LPWAN). The LoRaWAN protocol is optimized for low cost, battery operated sensors and includes different classes of nodes to optimize the tradeoff between network latency and battery lifetime. It is fully bi-directional and was architected by security experts to ensure reliability and safety. The architecture of LoRaWAN was also designed to easily locate mobile objects for asset tracking, which is one of the fastest growing volume applications for Internet of Things (IoT). LoRaWAN is being deployed for nationwide networks by major telecom operators, and the LoRa Alliance is standardizing LoRaWAN to make sure the different nationwide networks are interoperable. 

LoRaWAN is designed to provide Low Power Wide Area Networks with features specifically needed to support low-cost, mobile, secure bi-directional communication for Internet of Things (IoT), machine-to-machine (M2M), and smart city, and industrial applications. It is optimized for low power consumption and to support large networks with millions and millions of devices. It has innovative features, supports redundant operation, location, low-cost, low-power and can even run on energy harvesting technologies enabling the mobility and ease of use to Internet of Things.

To see a short introduction about the LoRa Alliance go here.

Specification.

The specification document describes the LoRaWAN network protocol, this can be downloaded from here.

Certification.

The LoRa Alliance is committed to interoperability, quality of the network as well as the end-points. LoRa Alliance member products are available throughout the eco-system. The LoRa Alliance Certified program leverages the expertise of industries and certification groups around the world and their expertize to ensure the vision of the alliance is maintained .

Members benefits of such a program are:

• Certified Product
• Interoperability testing
• Use of LoRa Alliance Certified logo
• Product listing on the Alliance website
• Product promotion in Alliance collateral
• Inclusion in Alliance product demonstrations

Types of Certification

LoRa Alliance Certified Product program ensures that product meet national frequency regulations as well as the LoRaWAN required and optional features to ensure interoperability and compliance.

LoRa Alliance Compliant Platform program ensure LoRaWAN interoperability and compliance of network infrastructure, components and offerings according to national frequency regulations and the alliance specification.

Authorized Test Service Providers and certification process

Only LoRa Alliance authorized test houses may perform testing for the alliance certified program. Applicable national conformity test reports and registrations are supplied together with the LoRa Alliance conformity report to the Alliance Certification body before receiving the right of Certified product or Certified platform.

Capacity is, first and foremost, a consequence of the number of packets that can be received in a given time. A single SX1301 with8 channels can receive approximately 1.5 million packets per day using LoRaWAN protocol.

So, if your application sends one packet per hour, then a single SX1301 gateway can handle about 62,500 end devices.

Yes, LoRais IPv6 and 6LoWPAN compatible. Actility (a LoRa partner) and other partners enabled 6LoWPAN on top of LoRaWAN.

The LoRa modulation itself is a PHY that can be used in all network topologies. A mesh network extends the range of the network but comes at the cost of reduced network capacity, synchronization overhead, and reduced battery lifetime due to synchronization and hops. With the increased link budget and range capability of LoRa, there is no need for a mesh network architecture to extend the range so a star architecture was chosen for LoRaWAN to optimize the network capacity, battery lifetime, and easy installation. 

The SX127x LoRa device has a FIFO of 256bytes in LoRa mode. In theory, all the 256Bytes can be used for TX or RX. However, with a low data-rate configuration, the time on air with a 256byte payload will be very long (several seconds or even longer), which is not good for resisting fading and high interference environments. This is not a robust configuration in most environments so it is suggested that if a long payload is desired with a low data-rate then the packet be split into a few shorter packets. 

Follow the steps (I – V) listed below:

The RegPktRssiValue and RegRssiValue are both useful in LoRa mode. RegPktRssiValue refers to the packet RSSI level, and the RegRssiValue is similar to the RSSI that can be found in (non LoRa) FSK mode. As you know, LoRa can demodulate the packet below the noise floor (PktRssi result) then CurrentRssi will then be equal to or more than the noise floor.

For more details about how to calculate these two RSSI Values, please refer to the Semtech API or latest LoRa datasheets. 

When you start your design, check the DIO Mapping in both the LoRa mode and FSK mode. You can find the DIO Mapping information in SX127x LoRa® datasheets. The DIOs do not function as normal (typical) MCU GPIOs. There are some special interrupt signals (or clock outputs) to indicate the event or status of the chipset, which then make your FW design easier to implement. In theory, you could connect no DIOs and then poll the related register to know the status result. However, we suggest that you connect the DIO as much as possible for external interrupt functionality which saves on the resource loading of the MCU and permits a very low-power operation mode (the MCU can sleep while packet it Tx’ed or Rx’ed). 

No, the maximum packet length is 256 bytes in LoRa mode