Frequently Asked Questions
LoRa transmissions are almost unaffected by vehicle speeds due to the type of modulation used.
LoRa is one of the most robust low power transmissions with respect to moving objects and does not suffer the kind of Doppler issues that limit ultra-narrow-band transmissions to very slow speed. LoRa can happily accommodate normal vehicular speeds.
With respect to location, as frequency diversity (read multiple transmissions on different frequencies) is a powerful tool in reducing the uncertainty this is not so easy with high-speed moving objects. With a moving object algorithms that analyse the speed and direction of movement and other things like ‘is it tracking a road’ can be used. Semtech’s first release does not include moving sensor optimisation.
What sensors support ‘data fusion techniques' and what does it do to the accuracy, cost and power consumption?
There are already GPS based sensors available in the LoRa catalog. There is currently a lot of activity within the ecosystem combining sensors with gyros, sniffers and other technology that will open up a whole range of possibilities for accurate location determination. It is currently too early to demonstrate these with Semtech’s in-house system however, it is expected that within 2016 some of these will start to appear on the market.
Semtech says that multi-path is the largest contribution to location uncertainty, how can multi path be mitigated in the sensor?
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.
Semtech says that multi-path is the largest contribution to location uncertainty how can multi path be mitigated in the deployment?
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.
Semtech is actively looking at all options for improving the performance offered to all licensees. Semtech has been in active development both internally and with third parties up to the point of the first release and this is expected to continue. Semtech does not believe that the common solver approach will best serve the specific use cases of all users so is expecting Licensees to integrate multiple solvers some of which might be application specific in order to cover the needs of the wider use cases.
Semtech has built a system upon which development and differentiation is expected in the market place. Licensees are given the source code for Semtech’s solver. The Licensee is then entirely at liberty to use any means to improve the solution to reach the performance that is important to the use cases that drive the Licensee’s business. The Licensee can choose whether to invest development resources, sub-contract, purchase I.P. or rely on Semtech.
Semtech has built ‘base camp’. This is a generalised solver without any knowledge of the application of the sensor. There are many ways that the solution could be improved such as knowing if and when a sensor moves, bursting several packets rapidly, knowing any geographic constraints such as ‘stick to roads’ etc. etc.
With the release of version 1, Semtech is involving the partners in the eco-system to build more networks, capture data and develop the solution to fit various use cases.
How will updated Semtech solvers be made available to the market; system integrators, network operators and end customers?
Semtech will make the updated solvers available directly to the licensees of the Location service. This, in general is the system integrator. Semtech makes the solvers available as source code and, following receipt, the system integrator will choose whether to integrate the new version into their product. Since the solver is provided in source code, it is expected that the development of the solvers are not limited to the work conducted within Semtech. It is expected that third parties will become involved and create differentiation in the market place. Therefore, the schedule of updates should be discussed between the end user and the provider of the location service.
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.
Which frequency offset has to be taken into account to avoid disturbance of 3G and 4G telecom networks?
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.
Semtech states that target gateway diversity is 4 for location and 2 for data, does that mean that a deployment for location requires twice as many gateways?
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.
If gateways are using GPS for precision timing, do you have any guidelines for the GPS installation?
There is a lot of data to confirm that GPS timing performance is significantly affected by (1) the constellation of satellites in view, (2) interference or multipath. The recommendation is that the GPS antenna location is carefully considered to give the maximum ‘view’ of the open sky and if possible to reduce the effects of signal reflections from other sources. Semtech can provide a short study on the effects of GPS antennas and chipset configuration on the timing accuracy of the recovered 1pps signal. For deployment, the main influence is the antenna installation.
Results show that location uncertainty reduces with the number of packet repetitions, but the effect diminishes after 6 to 8 packets, why is that? Would increasing the number of channels help?
Evidence suggests that increasing the number of channels would make a positive impact on accuracy since it would increase frequency diversity. Any kind of diversity aids the algorithms in the solver to make better choices and weight the data presented in a more effective manner. Until now, the field data has only been collected for 8 channel European LoRaWAN deployment. Once more data is available this assumption can be validated and more detail added to this.
Results show that location uncertainty reduces with the number of packet repetitions, but the effect diminishes after 6 to 8 packets. Why is that, if I need better precision can I just send more packets?
To some extent the answer is yes, however, that is not the whole story. The main benefit of packet repetition is obtained due to the fact that the different packets are sent on different frequencies. Since the channel selection is random, there is no guarantee that 8 packets sent will cover all the channels in an 8 channel system, however, one would expect that, statistically most of the channels would have been used. The effect of changing the frequency is to change the multipath effects experienced by the signal bouncing off the different buildings and other objects. Once the algorithm has received a packet on each available frequency then the improvement becomes rather small. There is some variance of the multipath due to time but field data suggests that it is rather less than the frequency related and would, therefore, give minimal benefit. So, for an N channel LoRaWAN deployment, the benefit is mostly brought with approximately N packets transmitted.
Until June 2016 the only non-urban data that is available is a rural near-line-of-sight trial. The trial is detailed in a separate report but the summary is that in a near-line-of-sight trial, the mean uncertainty measured was 20 to 50 metres as shown below:
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