I made a sensor node using STM32 and arduino-LMIC library and i’ve successfully send data to TTN using public gateways.
I moved my sensor to a remote area covered only by a gateway 1km from my sensor. My sensor is about 2m high with a standard 1/4 wave monopole antenna. Now i have lots of missing packets, RSSI and SNR looks terrible, around -115 and -5.
For the LMIC side i’m using the basic OTAA example to communicate.
So, what do you suggest to improve the communication? Other kind of antenna? increase SF?
Evaluate terrain in between node and gw and consider any moving obstructions or helpful reflectors (changes in these might account for occasional lost packets) - evaluate freznel zone impact if any. Assume you can inflence he GW placement as not yours? (Can owner get it higher?), failing that add a meter or two of high quality low loss feeder cable to get you own antenna higher, or lift the full sensor. if hieght improvemen not posssible what about lateral moves? a few meters either way may improve obsticals or reflections impacting signal… its often a suck it and see approach to get improvement. Could you deploy an infill gw in better location - thereby also improving community coverage and capacity along the way?
Unfortunately i do not have control of the gateway and i already try moving my node a few meters away, but that did not improve reception.
My payload is only 12 chars sent every hour. Yesterday i only receive 3 messages instead of 24.
Google says RSSI closer to 0 is better and NSR <0 is bad, so am i assuming wrong that my signal is terrible?
For RF in general that might be correct with caveats especially for legacy modulations however did you search specifically for LoRa signals and what is considered good in practice?
The higher the signal the better in principal - ie the less negative the better. In absolute terms you can get too low (larger negative number) and then fall below the receivers sensitivity. For LoRa unlike say FSK this is in part determined by the SF. Similarly as signals get higher that is good - for -80dbm is better than -90dbm, -70dbm is better than -80dbm etc. to a point. Devices and circuits will have an upper limit above which they will start to saturate and become somewhat non-linear in response. Indeed if signal at the active component - the rf input of the LoRa tranceiver in this case it is possible to actually overload to the point of damaging the device…will leave you to read specs if interested. Many read the specs and assume it safe to push high (device on top of GW when testing etc.) and think all ok, but that non-linear and unpredictable behaviour catches out and fact is once signal gets too high you get issues like channel bleed or distortions where filters start to pass too much sideband signal and device gets confused…it can start to see a (say) -90dbm signal - ie. one of a size it might expect to see in normal deployment and try to discriminate that (and fail), ignoring the -10dbm main signal that is far higher than was expected. Search Forum for examples of ranges that people often call as good - especially for testing - such that you are debugging the device vs fighting RF extremes issues. Similarly SNR is a moving feast. >0 is good for legacy modulations like AM, FM, FSK etc., there is also the need to look at how well a circuit will perform in the face of an interfere on same freq and with similar modulation. Typical guidance for fsk would be have the signal of interest atleast 6db above level of interferer to avoid deconstructive interference, preferable 8db+ for reliable operation. LoRa on the otherhand, because in part of the Spread Spectrum tech that is used (plus techniques like FEC etc.), is designed to work with signals below the local noise floor. i.e. in google terms that would have been n<0 e.g. -3, -6. -14 or whatever. The actual tolerance again being largely SF dependent. As a guide think SF good to ~-7db, where SF12 good to ~-20db. In real world deployments you find actual PER is determined by a mix of these two characteristics, plus in addition there is a complication/benefit depending on the type of intereference and noise…and where bursty or constant. Will leave you to research that aspect.
SO depending on local RF environment your values of
Might actually be ok… depending!
Indeed sitting here I can see a couple of nodes over the other side of the Thames Valley barely missing a beat with signals in the -113 to -117 range over time and with SNR around -4 to -9 over time. As @Piet_Pillay mentions there can be specific interferers with particular characteristics that may come into play. Always worth investing in a cheap SDR to look at what your local environment is carrying.
Remember RF isnt guaranteed as a delivery mechanism - makes a mockery of people offering SLA’s IMHO! - indeed more googling will probably tell that packet loss of around 2-5% is not uncommon, even for a LoRa based network, with many network operators setting expectations with number around 10% and even 20% loss before they would consider it poor performance. For production deployment I typically aim for RSSI in range -50 to -110 (some cases I do push out to <-115 where application can tolerate), with SNR limit typically 3db better than SF specific limits at a given point, and with that I would say most of my deployments come in <<5% loss on fixed installs. (Moving or moveable nodes are a whole new ball game!). For testing I look for typically -55 to -95dbm, to avoid having to debut RF issues in parallel with device issues…others may have different views…
If RSSI is >-114 and SNR >-8, it can still be considered as acceptable. This is also where LoRa is considered different to other protocols, when being able to still operate below Noise Level.
But if your GW is only 1Km away, then there are other factors to be considered as obstacles. Is there direct Line of sight from the end node spot to the antenna site? Trees/Leaves can be a source of blocking factors besides buildings with steel infrastructure. The terrain topology is as well to be considered.
The gateway antenna is on top of a communications tower, so my node being 1 km away i expect to get some good coverage. My node is on a public park in the border of the town, so i have some buildings in between, but they are not very tall (maybe 4 to 5 floors).
My node is on a plastic case, so no good ground plane available. I bought a commercial antenna for Lora 868Mhz.
When i get a packet at TTN console i see SF7.
I created a webhook and i’m saving all the traffic of that node on a text file. I can see some requests sent by the node but it seems the node does not receive the AKN from the TTN
Here’s the example of a node at my desk with public Lora coverage:
Depending on clutter in between and noise types and environment SF7 ‘should’ be ok but might be marginal. Does your node support ADR (if not moving - I assume not if fix location in a park) and if so have you enabled it? Device should auto negociate with the network (server) and optimise SF choice if enabled…
…have you evaluated the terrain (heights) in between to check if in LOS even if GW on a tower…
You are not making the mistake to join for every uplink, are you? A node has to join once and reuse the information for all future uplinks. Only when a reset is required (for instance on battery change) you should rejoin.
AKN being the Join Accept message - always good to use the correct nomclementure so it’s clear to everyone what you mean - see Learn section (linked top of page) for the basics with all the right songs for the LoRaWAN drinking songs.
Apart from not even thinking about joining for each uplink, with LMIC - current version which is 4.1.1 - you can set the starter DR/SF to something a little higher and then leave ADR to settle on a reasonable rate.
Apart from a join each time not being to spec, it also means you are spamming the whole of your area with the Join Accept being repeatedly broadcast from a gateway with extensive coverage - and a gateway transmitting is entirely deaf to any other uplinks - so whilst your device is trying to phone home a a fair amount of other people will be losing uplinks as well.
If you are doing a wake, join, send cycle, is it because you are powering down the device?
Do you know what other services use this tower, especially what frequencies they use?
The receiver of the gateway might be overloaded by signals on frequencies nearby. It won’t hear the Join Request of your node.
There’s no indicated issue with the Join Request - there are some unknowns about the config for joining on each uplink but the main issue is the reception of the Join Accept.
