We have gotten a RAK 10701 to test it with our Lorawan stack. I was able to register the sensor on our chirpstack lora server and i can see in the logs that the sensor has joined and was accepted by the server but unfortunatly I don’t get any messages from the RAK10701.
I can see on the display of the RAK10701 that there will be tried to send messages but I don’t get any messages.
Here you can see a pic of the display:
The device will send only a message when it has a valid location. Did you ever see in the bottom part a latitude and longitude?
Did you test the device outside of the house? Indoors it usually cannot acquire a location.
But these values are not constantly on the display.
I have tested it outside too but the same result.
Maybe one information is important too: Unfortunatly I have updated the sensor wistoolbox because the tool told me that there is an update but then it stopped to work. I saw a post from you in the forum that this kind of sensor isn’t supported and reinstalled the firmware which you have posted there. Maybe this information is helpfull.
As the display is still working, the upgrade should be with the correct firmware, otherwise you would not see anything.
GNSS antennas work best with an unobstructed view to the sky. E.g. my roof is metal sheets and I do not get any location indoors with any location tracker I tried.
If you don’t see any packets arriving on Chirpstack after it has joined, it is most likely not sending them because it has no valid location. There is a criteria as well about the precision of the location. If it sees not enough satellites, and the precision is not good, it will not send as well.
What send interval can you see in the settings screen of the device?
Yes the display hasn’t worked and i recovered it with a firmware version you have written to another user in another thread. This was just additional information that you know what happened with the sensor.
The sensor has found 14 sats which is quiet good I think. This test was outside for 30 minutes.
Here you can see the settings of the sensor. The sending interval is 60 seconds.
I will add a pic in the next post because I’m not able to add more than one pic in one post.
I would have an offtopic question too: We have a use case where we want to check the signal quality of lora coverage inside of buildings. Some of our customers want to check first if it would be possible to install Lora sensors inside in buildings. Am I right that this sensor isn’t designed to check indoor positions?
Wait, just see in your screenshot, the Band: entry is empty. That is weird. Should never be empty.
Can you try to change it. Either in the settings screen or from a computer with a terminal app and the AT command:
AT+BAND=
Well it’s getting weird.
It has obviously joined the network (you saw the join request/join accept message in Chirpstack) and it is sending packets (showing Sending in the display), but you say nothing arrives in Chirpstack.
What gateway are you using? If the gateway has an option to see the packet traffic (our WisGate Edge have this option), can you see any messages that could come from the RAK10701?
Hi Bernd!
I have new information. My colleague told me that he has ordered a second device RAK10701 so I has registered this sensor too and this sensor works like expected. It has joined and send lora messages like expected. Unfortunatly I don’t get RSSI measurements on the display. Are there any criteria what are needed to show these measurements on the display?
I have also compared the settings of both of the devices and there is one difference. The device which doesn’t work has an additional setting “working mode”.
Is there anything which we can do to solve the device which isn’t working?
Thanks for the information that the sensor isn’t good for indoor localization. Is it planned to implement a mode where the sensor will send lora messages without the need of GPS localization?
The sensor looks really good but our partners and customers needs just the current RSSI values of the indoor position just to check if the connectivity is good enough. Is there anything like that in the pipeline?
The missing Working Mode is linked to differences between the different variants. The -H version is originally pre-registered on Helium network, but can be switched to use with other networks like TTN or Chirpstack. Then it would be in “Custom” mode.
To get RSSI, SNR, number of gateways and distances, you need to have a backend behind the LoRaWAN server. This is either a backend provided by our our partner which works with Helium Networks and TTN. Or for other LSN like Chirpstack you need to provide this backend by yourself.
The backend receives information from the LNS about the different gateways that have received the packets, which RSSI and SNR levels the gateways saw and then calculates the distance between itself and the different gateways.
There are two steps under the hood of the Field Tester. In step one, the Field Tester is sending out data packets over LoRaWAN. These packets are received by one or multiple gateways. These packets are forwarded from the LoRaWAN network server to another backend server. When the packets are forwarded, they include information about signal strength and the number of gateways that have received the packet.
In the second step, the backend server is calculating the minimum and maximum distance between the Field Tester Pro and the gateways that received the data. Together with the minimum and maximum RSSI levels, this information is then sent back to the Field Tester Pro as a LoRaWAN downlink.
Last not least to your question about indoor device to measure RSSI levels, we do not have such a device ready to use. As the device doesn’t know what RSSI and SNR the gateway(s) saw, you will even in that case have a backend server that collects this information and sends it back to the device.
That is doable and not too difficult, but we have no plans to do it at the moment.
Hi. I am not clear about these two step. do we need to complete all setup from TTN> Chirpstack> Datacake for us to receive accurate distance for Rak10701p? my device only showing 250 m for max and min distance.
In this case either both gateways are close (distances are only in steps of 250m) or you are using the old payload decoder in Datacake. There was a bug in the decoder regarding the distance. Latest decoder can be found in our RAKwireless_Standardized_Payload
Are you using TTN and the proposed integration to disk91 backend server?
If yes, I can only guess the two gateways are really close to the field tester.
I planned to use TTN and Datacake only. will it work?
Another thing I need to clarify, do we need to complete all the setting step by- step of proposed integration for all 3 IoT platform (TTN, ChirpStack, DATACAKE) in Product Configuration to get distance reading for RAK 10701P?if yes, why.
Yes, it will work, but you have to check in Datacake that you have the latest updated payload decoder (the link I sent you earlier).
And there are three independent guides in the documentation.
The first one is using Helium and disk91 back-end
The second one is using TTN and disk91 back-end
The third one is using Chirpstack and Datacake as back-end
At the moment we have no guide how to use TTN and Datacake, but it works, I tried it.
Thank you for your reply. We have followed the provided instructions and we have successfully configured Datacake integration and its receiving data from our device. we also used the latest provided payload decoder.
However, we are still getting same wrong reading for the distance parameter displayed on the field tester display.
kindly please noted that we have done several drive tests far from the gateway to confirm on the issue. Example: max distant on ten mapper is 648m, but we only can see 500m here. (refer to picture).
Additionally, the device does not seem to be charging or perhaps the charge status is always shown as low percentage.
