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.

Whether private or public, overlapping networks in a specific geographical area will share the medium, and therefore the collision rate will increase.

The common techniques which can be used to alleviate this situation is the use of Clear Channel Assessment, which evaluates the "cleanness" of a channel by using spectral scanning techniques (and therefore adapt the channel plan), and implements retries in packet transmission to maximize success rate.

When it comes to the access point side (gateways), the use of the"private" sync word versus "public" sync word is useful to ensure that the gateways don't report a vast majority of the incoming traffic using a different setting.

Each SX1257 chip can digitize almost 1 MHz of spectrum, therefore two are required typically to achieve 8 channels with a channel separation of 200 kHz or so.

The limitation of using one SX1257 chip and one SX1301 chip is that you can only digitize 1 MHz of spectrum (and not 2 MHz) and can only build a 4 channel modem since the channels are spaced 200 kHz apart.

For noise immunity (digital to RF), it is safer to use a separate 3.3 V power rail between SX1308 baseband chip and SX1257 RF transceivers.

SE2435L RF front-end uses two power rails: 3.3 V (VCC0) and 2.0 V (VCC1 and VCC2). Concerning the 3.3 V (VCC0), it is already shared with the 3.3 V LDO SX1257 radio_A on the reference block diagram and schematic of Picocell Gateway. You can keep it this way.

You can share the same 3.3 V power rail between the two SX1257 radio_A and radio_B RF transceivers.

This 3.3 V power rail can also be used to supply the 32MHz TCXO.

In summary, two separate 3.3V power rails are recommended:

• the first one to supply SX1308 baseband chip
• the second one to supply the two SX1257 radio_A and radio_B RF transceivers, VCC0 of SE2435L RF front-end and 32 MHz TCXO.

For more details, see the Picocell Gateway reference design.

The gateway power consumption is mostly independent of incoming traffic. Therefore, the transmit current posted on the specifications is valid.

We're speaking about a couple of watts (below 10 watts for sure), but for a precise answer please get in touch with your gateway maker. The overall consumption depends on the supply strategy, peripherals, CPU used, and backhaul among others.

There is no definite answer to this question as it depends on four dimensions:

• RSSI/SNR of the received packets (simultaneous reception on the same channel)
• Time-on-Air of the packets (equivalent to data rate, the longer the packet, the longer one demodulator of the gateway is used)
• Frequency of the packets (two packets with the same data rate and the same RSSI/SNR will collide unless they are on two different frequencies).
• Number of times per day an end device will send a packet (taking resources another node could use)

In Europe LBT+AFA ( Listen-Before-Talk + Adaptive-Frequency-Agility ) is not desired or implemented, however in certain regions LBT is mandated.

The reference design now implements LBT, specifically to be in compliance with regulations in Korea and Japan.

No, you do not need a gateway. You can easily implement simple protocols using LoRa, either with modules or with the chips themselves.

The SX1301 device is the baseband signal processor for LoRa gateways. It takes 32 MHz, 1-bit I/Q digital baseband samples as an input. It is generally paired with two SX1257 front end digitizers, though it can be used with other forms of digital RF. This is often done with the 8 x SX1301 gateway architecture Senet uses in its network deployment.

Lora gateways or concentrators 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 and 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 via standard IP connections while end-devices use single-hop wireless communication to one or many gateways.

All end-point communication is generally bi-directional, but also supports operations 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 vs. tower).

The term gateway and concentrator are both used, but they are equivalent components in a LoRa system. In other industries the definition of gateway and concentrator may imply different components.

With the early trial data, Semtech is recommending a 3km ISD in most rural cases as a guideline. There is, however, no substitute for detailed network planning and the coverage target should be four gateways. Targeting a configuration giving a four gateway redundancy means that in most cases, the sensor will be in coverage of all four, and in almost all cases will have the required minimum of three. 

The license requires the gateway manufacturer to stick with certain components to ensure consistency and also to submit a sample for time-stamping consistency tests. This will ensure consistency across different vendor’s products and allows best-in-class choices for network deployment at all stages.

Manufacturing partners wishing to manufacture location-ready gateways can license the technology by signing an agreement with Semtech. Semtech will ensure that the partner can offer the consistency and quality required of such a gateway.

Gateway firmware updates are released from Semtech to (i) gateway manufacturer licensees, (ii) location service licensees. Firmware updates are expected to be infrequent and no more than annually unless an urgent bug-fix is required. The location service licensees will be responsible for integrating the new firmware into their solution and planning the in-field deployment to the gateways. For further details the system integrator partner/location service provider should be contacted. 

The time-stamping firmware has been extensively tested. The performance in the resolution of the received signal is very close to the lower bound of Cramer Rao lower bound for estimation of arrival time. As shown in the graph below, the uncertainty is dependent on the signal-to-noise ratio at the receiver compared to the sensitivity level. The development of the time-stamping firmware is not expected to make any big leaps forward. There may be some minor improvements but in general, it is felt that improvements will come from the solver and statistical analysis of packets and location rather than time-stamp improvement. 

As can be seen the estimation uncertainty reduces very rapidly with increasing signal-to-noise ratio above the threshold of sensitivity. This is one of the reasons why antenna diversity is important; as when a packet arrives with poor signal-to-noise ratio on one antenna there is a chance that the second antenna will receive it at s significantly better signal-to-noise ratio and, hence have a much improved arrival time estimation. 

The gateway reference designs are specified to coexist with 3G, and more importantly with 4G base stations, when co-located with a 4G base station with 50 dB of antenna isolation. The main risk is the injection by the LoRa® GW of noise into the LTE uplink band 20, but this is taken care of by the Semtech reference designs.

No data is available on using sectored antenna with LoRa location at this time. 

The GPS time-base has been measured to generally contribute less than 20-30 meters uncertainty to the calculation. A more stable time-base and one that mitigates the problems of GPS (GNSS) transmissions and multipath would remove one of the uncertainties. Semtech has measured some different GNSS receivers with a variety of antennas and it is possible to improve the precision. The GPS time-base error is, however, one of the smaller parts of the uncertainty in the resolved location.

It is feasible to create a near-line-of-sight deployment in a rural area. It is almost impossible to create a true line-of-sight deployment (ie. without any multipath element to the signal received). Semtech has made experiments with NLOS deployment and even without keeping the first Fresnel zone clear (due to lack of antenna height) very good results were achieved. 

The answer to this question is ‘not necessarily’. It is always recommended to have a gateway diversity of at least 2 for data coverage for a fixed sensor for a number of reasons including minimization of black spots in coverage, downlink collisions, interference local to the gateway etc.To answer the question on the density of gateways required for LOC one first has to answer,

a: is the data coverage planned to cover indoor?

b: Is the location required primarily outdoor?

If the answer to both of the questions above is ‘yes’, then the additional gateways required for location is likely to be very small. The reason for this is that the path loss from outdoors to indoors is normally well in excess of 20db. Therefore, if a deployment provides the recommended diversity of two indoors, then it is highly likely that outdoors in a similar location will have a gateway diversity of 4.

If, however, the answer to the above question is that indoor coverage is only targeted at one or even not at all, then additional gateways should be planned to operate the location service.