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!
So press the button when you are home and see what happens.
Watch the application and see which gateway it is using.
Remember your nodes can use any of the gateways on the TTN network
There are less potential problems with ABP.
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.
Don’t. This will result in an attempted downlink for every uplink and you are allowed just 10 downlinks a day for each node.
Given the directonality of your antenna that is to be expected. It is tuned to look at the horizon, not below/above it.
That hugely depends on the hardware and line of sight. I’ve seen joins over 15+ km without any issues when there were no obstacles.
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 
1 Like
That’s what everyone says 
There are good times & places for using them, don’t rule them out, just keep them rare!
I’ll dig through the data later on, certainly tonight.
What is your gut feeling?
1 Like
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.
I’ve looked that serial logs & the console data.
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.
Thank you very much for looking at them!
I spoke to support staff today and they will have a look at the possibilities to mount the antenna parallel to the weather station with some offset.
Later this week the CMA calibration equipment should arrive, and once calibration is completed (may take another week since it’s holiday next week), we will place orders to convert the already existing boxes to the current version of hard- and software.
I’ll likely do a couple of tests regarding ABP while we’re waiting for the hardware to arrive, to see how far the TX power of the nodes will be able to get us.
Once the 60 boxes are built (will probably take a while), we will be able to do full coverage mapping. Might open a new thread around then; for now I have learned a lot of new stuff which I will definitely be passing on to my students. I thank you all a lot!
Please try to erase this concept from your mind.
LoRa = Long Range which actually means Longer Penetration Than Most Other Radio Modulations but I think Semtech marketing kiboshed that phrase as being too clumsy = LPTMORM
So the Tx power either gets us up & down five floors of a high rise office, anywhere between 50m and 2km and some other randomly plucked out the air number for an urban setting - 50m at ground level when surrounded by tower blocks and the antenna is on the top of a tower block, 3.4km at either end of the strip at Las Vegas when you are crossing the road and temporarily have line of sight with the antenna on the top of Bellagio (although the uplinks never get to your integration, because what gets uplinked in Vegas, stays in Vegas), my “record” is 118km line of sight - the transmitter was at 31,000m, in the Netherlands (we got a crash course in why it’s not Holland last year) in rural areas that are as flat as Norfolk (the exact mirror image the other side of the channel but without trying to reclaim the land so hard), probably a good 10km or more but in rural Derbyshire aka The Peak District, when I lived there I could go from my house (on top of a hill) to another hill 10km easy, but not from the bakery on the village main street at the bottom of the hill due to the stone buildings - unless you stepped between a gap & bingo, line of sight, reception very easy.
TL;DR, YMMV and Que Será, Será
Get the students to build them?
Great learning experience but in that case need to order kits to build 100 + spares to fix another 10… “sorry Sir the soldering iron/wire cutters/hammer slipped…the legs just fell off…oh so that was pin 1…” 
I definitely understand that but it’s quite hard to phrase something like ‘we will see what conditions are required for a reliable range of so many kilometers in this direction, that direction etc’…
That’s very optimistic xD I do NOT expect that even a third of my students will be able to pull off a working miracle in one go
It’s me plus four support staff that will be doing to job… so propably two full days of resoldering sensors and cutting a few additional holes plus reflashing software - not too bad. But kinda scary after sooo much time has been put into it!