Documentation, schematic and tools are available on the SX1308 product page, under the tab “Datasheets and Resources".

Control from a Windows 7/10 machine host through a GUI

- PicoUI Demo App tool

- PicoCell Gateway GUI User Guide

Control from a Linux host (e.g. Raspberry)

- picoGW_mcu***, picoGW_hal and picoGW_packet_forwarder source code

- User Guide to the LoRa PicoCell Gateway

Note: All libraries are provided as Reference Design, please refer to the built-in license agreement.

Transceivers used in LoRa®-connected end-devices are frequency-agile, i.e. they have a fast switching PLL onboard. During the uplink, they use a first channel (say 902 MHz), and it is very easy and fast to change the frequency to, for instance, 920 MHz, before the transceiver is turned to reception mode. This takes typically 100 microseconds to do.

Both the uplink and downlink messages are transmitted on determined channels. For example, on class A devices the uplink channels are controlled by the channel mask (ChMask) , whereas the downlink channels are either a function of the uplink channel or configurable through MAC commands.

You can perform firmware upgrade from the server, the time needed for the upgrade depends on the size of the firmware to be updated. The idea is to switch the node in class B or in class C and to send data from the server. There are examples of FUOTA (firmware upgrade over the air) available from several partners of the LoRa Alliance.

The maximum LoRaWAN packet time-on-air duration is 3 seconds. After the packet is transmitted by the end-device (uplink message), the timer event "OnRxWindow1TimerEvent( )" occurs precisely after 1 second (± 20 µs), corresponding to the RECEIVE_DELAY1. Then the radio goes into Rx mode on the same RF channel as the transmitted packet, with a data rate which is function of the uplink data rate (refer to LoRaWAN specification Section 7). In case a downlink message has not been received, the timer event "OnRxWindow2TimerEvent( )" occurs 2 seconds (± 20 µs) after the uplink message (RECEIVE_DELAY2) and leads to the configuration of the radio for a second receive window in the function "RxWindowSetup()". The RF channel and the data rate used for the second receive window are defined in the LoRaWAN specification, Section 7.

However, before changing the radio, the code checks the radio status with the call GetStatus(). At this stage, either the radio is in "RF_IDLE" state and the code configures the radio to go into Rx mode, or the radio is in another state (meaning the radio is already busy) and the code will simply drop the command until the next IRQ from the radio.

The minimum receive window duration must be at least the time required by the end-device‘s radio to effectively detect a downlink preamble.

Any device able to perform frequency hopping in Tx is also able to do it in Rx. We have an example code on MBED where we show how it works. This may be found here.

One should distringuish LoRa® (PHY) and LoRaWAN®, a protocol working on top of LoRa. LoRaWAN needs a gateway, but doesn't support intra-packet hopping.

LoRaWAN mandates inter-packet hopping, where every next packet is sent on a new frequency, pseudo-randomly chosen. Other customers have successfully implemented LoRa in synchronous systems with FHSS, mostly relevant in point-to-point communication scenarios.

The best way is certainly to restore factory defaults by using the DFuse utility and the factory-default binary file, both provided with the LoRaMote Configuration Utility, along with an instruction set in the LoRaMote user guide.

There are two primary reasons why you should use a module:

1. It accelerates development, and you don’t have to write a whole bunch of underlying code to implement the radio system.
2. It’s already fully FCC or ETSI certified, so you don’t have to go through expensive testing.

The open source code available online for LoRaWAN is implementing the LoRaWAN protocol for a chip-down implementation. If you go down this route the RF certification and LoRaWAN Certification will need to be re-done. 

Frequency diversity is a really powerful way to mitigate multipath. Sensor firmware can be optimised to change the data-rates, channels and pack burst rates can certainly help. Also, data fusion techniques can have very powerful effects.

Data fusion with sniffing has been proven in mobile phones over several years. These kind of techniques could be used to significantly reduce the location uncertainty.There are a great many possibilities by using the LoRa uplink to convey meta-data for use in the solver. Semtech is expecting that many partners and third parties will work to add features to the sensor and solver that work together to bring a high accuracy low cost solution.

The best mitigations for multi path are to increase diversity:

• Increased antenna diversity- adding multiple antennas to gateways. This is good for all sensors.
• Gateway diversity- adding more gateways. This is good for all sensors.
• Gateway height- reducing the objects present within the first Fresnel zone in the transmission field. This is good for all sensors.
• Frequency diversity- more channels spread over a wider spectrum allow more packets to be analysed and discarded. This is particularly good for static or semi-static sensors.

The length of a receive window must be at least the time required by the end-device’s radio transceiver to effectively detect a downlink preamble. Minimum 6 symbols are required to do so e.g.:

• For BW = 125kHz, SF7 it should be at least 6.1ms
• For BW = 125kHz, SF12 it should be at least 196.6ms

If the end-device did not receive the downlink frame during the first receive window “RX1”, it must open a second  receive window “RX2”. Note that the end-device does not open the second receive window if a frame intended for this end-device has correctly checked the address and MIC (message integrity code) during the first receive window.

• RECEIVE_DELAY1 is a fixed configurable delay in seconds. Default is 1 second. If RECEIVED_DELAY1 implemented in the end-device is different from the default value, RECEIVED_DELAY1 must be communicated to the network using an out-of-band channel during the end-device commissioning process. The network server may not accept parameter different from its default value.
• RX1 frequency uses the same frequency channel as the uplink.
• RX1 Data Rate is programmable, can equal or lower than the uplink data rate. By default the first receive window data rate is identical to the data rate of the last uplink.  

• RECEIVED_DELAY2 is a fixed configurable delay in seconds. Must be RECEIVE_DELAY1 + 1 second. Default is 2 seconds. If RECEIVED_DELAY2 implemented in the end-device is different from the default value, RECEIVED_DELAY2 must be communicated to the network using an out-of-band channel during the end-device commissioning process. The network server may not accept parameter different from its default value.
• RX2 frequency is a fixed configurable frequency.
• RX2 Data Rate is a fixed configurable data rate.

The LoRa endpoints are the elements of the LoRa network where the sensing or control is undertaken. They are remotely located and battery operated. These endpoints can be setup to communicate with a LoRa Gateway (Concentrator or Base Station) using the LoRaWAN network protocol.