Good morning everyone, I have a problem, I need to know the rssi and snr of the package sent by the LoRaWan Shield LA66 + Arduino via AT_COMANDS which are AT+SNR=? /AT+RSSI=?, but both return 0, is it possible to check this via commands, without looking at the TTN platform? I need help, as this is part of my academic research in the area of networks.
Just as “beauty is in the eye of the beholder” so RSSI and SNR are what is perceived by the Receiver (as your shield is sending this is therefore the GW!) You can get that from the TTN console or if you parse the full Rx metadata for any uplinks sent by your device from your end application platform. Otherwise you would need to to extract this info on reception (e.g. at your application server) then re-encode the data and send via appropriate encoding as a downlink message to your Node, where you would then need to unpack it. Of course as TTN FUP limits you to max 10 downlinks per day (better yet per week or more optimaly per month and ideally through the useful life of the device!) 
) including join accepts and other network commands etc. this would be very limiting!
What aspect of your
Are you trying to satisfy with this request (there may be other ways to achieve same ends…)
IIRC what you are asking the sheild is the Rx stats for any packets received by the shield (sent by a GW).
I need a comparison of packets sent by the la66 shield and those received by the gateway to know if there was an understood collision? Currently I can see the packets sent by the dragino gateway (lps8v2), but I’m trying to register the frequencies sent on the sdcard +timestamp, but I can also record other information from snr rssi, do you know of any approach I can use to analyze whether there was a collision in the network, packets sent x received? Att,
There is no reliable way to detect a collision. Any transmission can fail to receive correctly due to a number of reasons, one of them being a collision, but more likely some other kind of interference. If you could look at the raw data stream from the receiver chip a collision might be detectable by finding a new preamble while procession another incoming transmission, however I don’t think the hardware provides access to this (standard software most certainly does not so if the hardware provides the required information you will have to write your own software)
Using one or more SDR setups you might succeed.
Just to ensure we understand what you think you are hoping for & need to do:
- There are eight channels / frequencies
- A gateway can hear on all of them, across a range of spreading factors, all at the same time.
- To manufacture a collision you will need two devices configured to the same channel & SF set to transmit at the same time.
- You will need some way to monitor the frequency to see what the gateway will be hearing.
And in terms of collision, there is preamble to preamble and preamble to packet collisions which will likely yield different results.
Look very very hard at what @Kersing has told you - he has considerable experience writing gateway code so if he says this will be a challenge, you should set your expectations appropriately.
@wollacebomfim and more subtley than even that you need to consider the classic RF ‘near/far’ problem of co-incident reception, and then also investigate/research how LoRa modulation behaves in those conditions and how its properties might mitigate for any classical behaviours usually seen with ‘legacy’ modulations, which in turn also changes with whether devices/transmissions are on the same or alternate SF’s as the properties change - then consider that this is ISM band typically and hence you are not just looking at LoRa/LoRa collisions but also all other modulation types that might exist in the same environment (again LoRa capabilities and mitigations depend on just which modulation is potentially interfering).
Also, when considering e.g. preambles to consider how timing wise two (potentially) interfering signals might actually interact. The selected FEC schema will impact at the macro level but also the fact that LoRa can typically loose up to half a symbol and still recover a valid piece of info so imprecise overlap might still allow valid data recovery etc.
A complex situation, especially where theorectical behaviours meet real world instantiations! Often best resolved using statistics and probabilities vs theoretical ‘certainties’ 
That is why I find published academic studies often of limited value in informing how real environments will behave, and I often find I am pleasently suprised by just how well LoRa copes 
vs what had been anticipated, but also get negative suprises from unexpected situations 
1 Like
Thanks everyone for the answers!