This may result in data that takes forever to figure out the answers on. The devices are relatively simple and all of them use the same radio chip from only one source - Semtech - so in broad terms, they are either normal or broken. And running them with simple firmware for a short period should answer that.
If one is way out of wack, it’s not worth the effort to debug it as it’s unlikely to be something that can be corrected. If it works OK near to a gateway, use it for office work only.
Any and all data is useful as it can be paired up with various logs. And you could send a couple of downlinks to help, but the most important thing is that will report on the signal it got from the Join Accept that it was sent
Sorry, I didn’t really mention that we will be calibrating all other sensors (temp, pres, hum, co2, loudness etc…) in the boxes. To do so, both devices will be sending their values every 10 minutes as well so that could give a ton of additional data if required (although they won’t be rejoining, just normal messages from within a classroom).
Ahh yes that is very useful, indeed. Got it. Will implement lora.callback() and lora.stats() Monday.
Yeah that’s the old building on which they slapped AC a couple of years ago. Other building has integrated AC so much cleaner setup
How much would it help to mount the antenna on top of the weather station (depicted on the right in the photo)?
I cannot say whether it is possible to rout a cable through the wind-gauge, but the location itself would seem quite okay to me. (Although the current antenna seems to be quite long which might cause problems in storms like Eunice currently.)
Very helpful on two counts - you get what looks like another 2-3m height and you remove the absorbtion from the corrigated wall behind and anything onward behind there. No need to try to get above the wind speed sensor (likely not possible) just offset mount perhaps with a 90deg mount/bracket - 1-1.5m - away from the pole that is holding the weather station Ant shouldnt present too much wind resistance/force…unlike the 3 sections my neighbours fence that have just uprooted themselves & snapped their posts!
Even at the base of that pole will help, as long as you get a few meters away from the pole. As the pole will cast a bit of a RF shadow, so the effect is less the further you are away.
In you area there are 2 other gateways besides yours.
ttn-foodvalley-vdl-icr3ate-mc
On v2 but will still forward your data
-1.5km away from your “home”
I am not sure if it is indoor or outdoor
Last heard at 2022-02-18T14:03:01.555667Z
ESP32-gateway - lorablaster
On V3
300m away from your “home”
I am not sure if it is indoor or outdoor
Last heard at 2022-02-18T14:13:45.793765
You defiantly need to check the versions and config with @descartes
Also double check the antennas on the nodes.
Also look in your application (TTN Console) when your node sends data and it is RX by TTN it loges the gateways, “rx_metadata” “gateway_ids” so this way you can also tell from what gateway your node is working.
Something to keep in mind when working with LoPy modules, PyComm uses RP SMA antenna’s where other vendors usually use SMA. It might be worth checking the antenna and antenna connectors on the nodes.
Besides all the helpful comments (our antennas are in fact RP-SMA so that’s fine, and both gateways, while being online, don’t seem to influence any results while testing at home), I also got a message from a fellow Dutch user which gave me an idea that might solve potentially ‘unsolvable’ problems.
Our boxes have a push-button integrated; when powered on, the device will join the network at / close to school; then going into nearly indefinite deepsleep during which the students can take the box home and press its button in order to wake it up after which the program continues with saved LoRa info.
The functionality will be quite similar to ABP, except that it joins at school with OTAA, discarding potential problems related to ABP.
So, while I of course will try to maximize our possibilities, if the TX on the boxes is powerful enough over a longer distance where RX cannot keep up, we’ll at least have a decent solution!
If they join at college and then go somewhere with some marginal coverage but have already settled on a lower SF, it will take many uplinks (typically 60) before the device will do a link check and discover it’s not being heard.
Whereas ABP and fixing it to something like SF10 for the few downlinks, or coding in some Blind ADR which is more straight forward with the PyCom modules than using LMIC or LoRaMAC-node will potentially better results.
Blind ADR, designed for any device that is moving or prone to being moved, is basically having a lower base value for the SF which is used most of time, but interleaving the occasionally forced higher SF(s). You’ll see from the title on this page that Blind ADR was pretty much documented for this exact scenario: “LoRa® Device Mobility: An Introduction to Blind ADR”
Thanks for the suggestions!
I have just been trying to get lora.stats() to work. Sadly, it does not save any information on the join-accept message , I can only get results after normal packages.
I ran a test the last one and a half hour and the results are in. I messaged full results to Nick; I am sure one of us will share the necessary details later. (TTN console logs of both devices as well as gateway, plus serial logs of both devices using CoolTerm.)
I confirmed that both devices run identical software (v1.9.4-94bb382 on release 1.20.0.rc13) and I uploaded identical software to both except for LoRa credentials. Software was set to uplink BME680 results every 10 minutes five times (that’s 50 minutes), after which it restarted (except I used wrong statement and had to push reset-button myself) so they would rejoin.
Gateway logs do not show relevant information regarding exact time of join-accept or forwarding as far as I could find.
Interesting to point out already is that one join-request of one of the two devices (MJLO-15) resulted in “Failed to schedule on path to …GW-ID…” so I had to reboot it once more.
Also very weird behaviour is that after the manual reset both devices sent their second message 3 times (software reported only one), after which cayenneLPP crashed reporting “OSError: [Errno 11] EAGAIN”; I have never seen this behaviour before, but maybe I screwed up something in the software I put together for this test. Although it did not show up on the first boot
I used s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, True) to request a downlink affirmation in order to find RX values on the nodes, since lora.join() does not result in a downlink that triggers callback with useful information.
Both devices reported RX RSSI values between around -85 to -105 with most showing up around -100 and -90… even though they are sitting 20 meters from the antenna (5 meters below).
TX to GW reported mostly -75 to -85 RSSI values on TTN console
3 km away from a gateway is in my experience on the edge of a good final LoRa join. The join requires an acknowlegd datagram reception which might fail due to local circumstances. The way how we encounter that problem is two-fold:
use an initial SF of 12 via the connection routine (Data Rate). See PyCom LoPy doc for the how to.
if that fails we use the following trick: LoPy (see the PyCom doc) one can store LoRa status and restore before the join (LoPy will not join but just continue as it knows it has joined already. This tactic is e.g. used if you apply a deepsleep. The node in first doing a join say 1 km away, then powered off and recolated to end location and powered on.
PyCom doc has code examples for a how to.
If you want to know how we have coded that for the LoPy in MySense see: https://github.com/teusH/MySense e.g. folder PyCom/lib lora.py
You should be able success or not on TTN console: on a join the datagram count is reset to 0. Some TTN LoRa gateways have the possibility to see datagrams passing by.
I am using SF12 on all above posts; I disabled ADR and forced SF12 on all communication. I know that this is not meant to happen on final products (I will most likely use some form of blind ADR), but for these ‘debugging’ sessions I do not want to be tricked by low or changing SF.
That is what I suggested in message #47 but got torpedo’ed by Nick and Johan apparently milage will vary in that case.
I know, but I planned to only run it for 10 messages… including two joins that’s slightly above the limit; I’m sorry. I hope I made it clear that I only used the affirmation for this test case, which is exactly the case. These messages were the first ever where I used that and hopefully the last
As far as I can tell with my limited knowledge and understanding, both devices are functionally almost identical - something (maybe the powerbank or the two boxes cramped on top of each other) must have distorted the signals of one box more than the other during the trip on my bike. And the weird behaviour of sending three times is maybe bad implementation by me when waking up from deepsleep and restoring LoRa info.
That would mean that the problem reduces to the ‘normal’ LoRa coverage problems - to which we (I) would still need a solution. Node to GW communication is acceptable but definitely not exceptional (given the RSSI values when sending from home); GW to node communication is lackluster for using OTAA.
In an urban area a couple of KM (2-3) is actually not bad and about expected. It all depends on gateway antenna placement, type of buildings and construction materials used and of course the amount of obstructions in the line of sight. The mythical 15km is not achievable in a city only in a rural area.
Powerbanks can be notoriously noisy power sources. LoRa modulation is much more resistant to such power conducted noise than other schemes, but a receiver that misses weak signals is exactly how this would show up.
I would not be surprised if there are other electrical problems with the setup however.
Considering there are only two nodes to compare for a relatively short amount of time, it all looks pretty normal stuff - certainly no one data line that suddenly deviates.
One of the many problems with this technology is that there are lots of little variables that can be over-read when in reality environmental issues can just knock back a signal strength, an uplink may go missing, it rains hard, you have a particularly noisy power supply and so forth. Out of a batch of a hundred devices I can easily end up with a nice bell curve for all sorts of parameters. And then ship the very best device, have it deployed where it is baked in the sun causing issues for the circuitry or battery and then it becomes one of the lower performing devices.
Judging from the other discussions, the next step is to get the college antenna in a better position and then crack on.
Ant shouldnt present too much wind resistance/force…unlike the 3 sections my neighbours fence that have just uprooted themselves & snapped their posts! 
, I can only get results after normal packages.
apparently milage will vary in that case.