New TTNer, hello, getting started and advice please!

Hi all

I’m new to LORA, LORAWAN and TTN. I found this after being given some cheap walkie-talkie radios and doing some research. I in turn found Peter Misenko’s (bobricius on github) Armachat and then Andreas Spiess’ videos on Youtube.

Still not put off, I started investigating, discovered TTN and realised there isn’t a gateway close by. I’ve decided to go all in and build an outdoor gateway as per the instructions here: Home · ttn-zh/ic880a-gateway Wiki · GitHub

My iMST iC880a is supposed to arrive today. I still have a few parts to decide on and order.

I have set myself a challenge though. The gateway must be, as far as possible, eco-friendly and wire-free. It will of course connect to my Wi-Fi for backhaul but will otherwise be totally off-grid. It must be solar-powered, run from a Raspberry Pi Zero W, with a suitable UPS hat and have enough battery capacity to comfortably run through the night even in Winter in the UK. I have ordered the RPi, UPS hat and gateway board already.

I would however appreciate any advice offered on the build as I have never setup such a device before.

I do not have a RPi to iMST iC880a back plane as all the ones I’ve found are currently unavailable. If no such thing is available, I will have to resort to jumper wires.

The antenna will be mounted on top of a TV aerial pole above a 2 story house. I have absolutely no idea though what antenna to use to provide the best coverage possible in area. After much reading, this seems to be something of a minefield. If there’s a particular thing people can recommend or someone who would be willing to make one that would work brilliantly, please let me know.

Once my gateway is up and running, I look forward to seeing what I can achieve with it.

Thank you

mikeyp

Baby steps - there’s no end of resources on the interwebs and help to be had on here. But there is a lot of hidden detail that can be a gotcha, so don’t splurge on too many purchases, buy what’s needed for the next stage and hopefully your box of ‘spares’ will be considerably smaller than mine.

The instructions are three years old, so you may need to look around for more info - particularly as we have had a big change from v2 to v3, so some of the settings will need translating to v3 ones.

But also remember that the gateway is a dumb box in the corner with some cryptic and encrypted logs scrolling past - the real fun comes from the devices / sensors, one, preferably two, to let you know know if your gateway is working.

The iMST is a solid product, jumper wires for high speed comms isn’t great but should get you started - keep them very short and keep searching for the adapter / HAT.

Going up aerial poles on a two story house is the start of many Casualty episodes - get going with a stick antenna on the back of the gateway near a window so you will only be going up the pole just the once to install the right antenna. And yes, it is a minefield but the short answer for a good external antenna and the cable to suit is proper money - probably as much as the IMST cost you.

We do like our gateways reliable on the community network as we never know who may utilise a sensor that they’d like the data to arrive all the time, not just when the sun shines, so when you get to the solar aspects, a bigger battery and a bigger solar cell is preferable.

1 Like

Awesome thank you. That’s all sensible advice.

I had seen about the switch from v2 to v3 but will bear in mind your point about the instructions being out of date. I’ll do my usual thing at work, write up the differences and post them back here if I’m successful for someone to update the guide.

Yes, I realise the gateway isn’t the fun part but without one locally, there’s not much I can do.

I reckon I can mount the pins of the iMST and RPi side by side to keep the jumper wires as short as possible. I’m looking at other projects for mounting ideas from what other people have achieved.

Fair point about the stick antenna. I’ll buy cheap small one to get me going and go from there.

I completely agree on the reliability point. The hat is both a UPS and watchdog timer, not that it will ever need it I hope. I intend to run it at ground level for a few weeks over winter to ensure the battery and solar panel are up to task.

Just as a little aside, I looked up the power consumptions stats for the 2 boards. Combined worst case scenario of permanent full load, they should draw at most 800mA. Assuming an equally worst-case scenario of 18 hours of darkness (3pm to 9am), the battery would need to have a 15000mAh capacity. To fully charge this in the remaining 6 hours, any solar panel would need to provide 12.5W or 2.5A at 5V as a minimum.

Where abouts are you? Might I suggest you look to join your local TTN Community (if not already signed up!) if there is one near you as there can be a wealth of knowledge and enthusiastic support available - despite the limits enforced by the current pandemic - with over 100 in the UK. Including many of us using the i880a, RPi’s including the 0W, and even a few of us deploying/experimenting with solar/offgrid deployments (yes even in the UK/Winter! :rofl: )

Hello mikeyp

I’m not a fan of making advertisments in posts, but you can get the IMST iC880a backplane from my store on Tindie: IMST iC880a LoRaWAN backplane from IoTDevices on Tindie

Keep in mind, during cloudy or even rainy days, you will not get much power out of a solar cell. On cloudy days, you wll get only 10-25% out of a solar panel, on rainy days even less. So you should get a much bigger batter as a storage element, and also a beefy solar panel to charge enough during cloudy days.

As soon as your gateway is up, then perhaps a neighbor will see it, and the network will expand. There are a number of gateways in the highway corridor near me, but blocked by low mountains. My lone gateway might someday be “seen” by a neighbor.

You should probably start your experiments with mains power, for simplicitly.

It’s also important to realize that a gateway that appears and disappears from a network with any regularity is extremely detrimental to the function of the public network - arguable it is a denial of service attack, because the nodes using the recommended ADR algorithm can take hours to even days to recover from the disappearance of the closest gateway and start using a longer range mode that can reach the next closest. So running out of power during cloudy weather is a very serious problem.

Given how little power a gateway actually draws compared to the the lifecycle impact of storage batteries, it’s arguably not “green” to try to run one on solar where mains power is an option anyway.

Someone trying to run a gatewail on solar would certainly want to use a low power sx1302 radio rather than the original power hungry sx1301. And they’d preferably use something lower power draw (and less dependent on filesystem state) than a pi.

Really, the parts you have are fine for gaining some familiarity in a mains powered, readily accessed for maintenance setting. But they’re not what you’d want for a field deployed gateway, doubly so one meant to be solar powered.

Whetstone, Leicestershire. I’d be surprised if there is a local community in Leicestershire. Checking the map, the only other gateway is the far side of the city. I’m the red dot in the picture. That said, I’m more than happy to be proved wrong!

image

Perhaps but so far I’d failed to find a backplane in stock. I’ll check it out, thank you.

Yes, an engineering rule my grandpa taught me, work out worst case scencario as a minimum, double it then double it again. My calculations were the minimum, which would assume glorious summer sunshine in the 6 winter hours.

I know. That’s somewhat exciting and exactly why I’m building an outdoor gateway, not just an indoor one for myself.

Truncated quote but replying to the whole. Yes I completely agree. I work with IT, servers and connecting infrastructure for ~100 schools across a city. Downtime is detrimental and definitely to be avoided. Your comments are noted. I’ll rethink the solar aspect, perhaps save it for a remote end of the project.

Radio waves know no boundaries, but coverage is a whole heap better with an external aerial. The only difference between an indoor or outdoor gateway is the kind of box it is in.

Not sure how you class an indoor gateway with a feed to an external antenna.

There is indeed a small community in Leicester (4 members - most recent joined just a couple of weeks back) - set up just under 3 years ago, with another potential member active posting on the Forum who was looking at testing a GW in the area around 18mo-2yrs back (pre-pandemic) - between Leicester & Nottingham IIRC (I had a GW in Nottingham at the time that was having to be relocated and so I offered as a potential for use - it’s since been redeployed back into Nottingham after ~1 year out of the area - some 2-3 months back). If you want to you could reach out to others in Nottingham, Shepshed (Loughborough) or poss S.East to Coventry (one I initiated and where I have another GW deployed), or possibly up towards Derby(shire) or even Chesterfield.

@cslorabox your concerns noted and stated before in other threads but Solar is a great - and often the only - option in many LoRaWAN use cases, requiring off-grid or independent from grid operation… from own experience I know of Agriculture, Viticulture, Agreology, Bee-Keeping/Apriary monitoring, Extractive industries (Mining/Quarrying, etc.), road/rail infrastructure construction phases and later long term monitoring, flood monitoring/early warning, large scale construction site monitoring - wide area or high-rise - e.g. where site assets, site noise, site dust/contaminents levels etc. need to be monitored/tracked (actually some overlap with e.g. quarrying etc.) for the duration of site activity - may be many weeks/months through several years so may be considered a ‘temporary’ deployment in that deployed GW’s may be removed after some time - but hardly would be considered a denial of service attack but rather a welcome, if temporary, extension to the network… a GW going up/down hourly or even for odd hours/days over many weeks or months depending on weather/time of year can be an issue but can be mitigated against - correct panel sizing, correct battery capacity/charging planning, system placement (maximising hours/minimising shadowing etc.), and even network densification such that enough GW’s (even temporary) in an area means any one dropping off due to lack of power doesnt purturb e.g. ADR too much in the scheme of things.

@mikeyp it’s not often that UK weather gets stuck in a bad rut with ‘no’ sun for more than 3 days so 3 day (& night) capacity is a good start point/rule of thumb unless you can tolerate more often drop outs. Even weak sun can ‘hold’ charge and hence maintain operation, even if not enabling battery boost operations. Having small back up batteries that can charge/trickle more quickly than main supply and can be switched in/out on demand is a good safety/mitigation strategy and helps extend battery life. Long term drift (several days or a few weeks) down due to insufficient daily boost can cause some systems to switch out to assist protecting/extending battery life so may need monitoring. This can be seen below in the case of one of my experimental solar rigs (deliberately badly positioned with building and tree shadowing that gradually impeeds solar input as seasons change and sun gets lower to horizon in late autumn/though winter, so I can test behaviour & mitigation strategies).

By coincidence (though Nick might quote an NCIS ‘Gibbs’ rule about this!) to this post it dropped out early hours last night (you see step where load switches out and battery output voltage shows slight recovery):
image

Stepping back to recent days and recent inclement weather you can see the general drift down (wouldnt happen so noticably for a well placed system)
image
And this ‘conditioning’ and gradual ‘exhaustion’ becomes even more obvious over longer time periods - you need to plan for this if GW isnt to disrupt general network use or is required to deliver value for substantive periods when it is operational :wink:
image

Are you thinking rule 23 or the original rule 3?

Thank you. Found and joined it. Will see what happens. My iMST board delivery keeps getting pushed back by UPS. It’s currently estimating Thursday. I work in Nottingham by the way.

I’m going to park the solar idea for now and see about cost and practicality to implement later. I love the idea but big batteries and big solar panels aren’t exactly cheap! I wonder if there’s a RPi hat which will switch between 3 power supplies, solar, battery and mains as a backup?

Not much runs directly off solar is it’s only really two way as it sort of meets at the junction with the battery - but you are looking for a reverse UPS which I doubt is something off-the-shelf - one that uses the solar/battery combo and then switches over to mains if required. Such a bit of cuteness would ideally have some coulomb meters at appropriate points so you can measure how much power comes from the solar, how much from mains and measuring the usage by the Pi & iMST, draw charts & predict battery time etc. Maybe Santa will put some me-time in my stocking and I can knock up a little something.

It looks like it might be achievable with something like a combination of these 2. The first has the benefit of being a small UPS and a watchdog. The second has the benefit of being able to take and switch between 3 inputs of varying voltages but won’t charge a battery. A separate charging circuit would be needed for that. They’ve kept it simple, so it will just use the device with the highest available voltage. You could, for example, supply 12v solar, 7.2v LiPo, 5v mains.

Super Watchdog V2 for Raspberry Pi– The Pi Hut
Zero2Go Omini Rev1: Wide Input Range Power Supply– The Pi Hut

I have one of the Zero2Go’s on order that I am looking to test with one of my Solar + RAK 831+RPi0W set ups so will let you know how I get on with it - may be a week or 2! :wink:

Omini? Not sure about the world wide availability of the ‘bulk’ DC-DC converter. Probably fine for easily accessible gateways if it goes off piste, not for gateways 200 miles up the M40/M6

Let me know how you get on. Remember it will need a separate battery charger if you’re using a battery at all.

Sure, but in my case I’ll only have to go in the loft. :stuck_out_tongue: Still intrigued what you’ll put together if you get time.

I’m getting rather lost in the quagmire of forum threads, guides, videos and mixed advice. What would be a good starter project and end board/node please? I’m thinking something (simple?) like a soil moisture sensor to begin with.

That’s a good start - although soil moisture is a bit random so you can have hours of fun figuring out what the numbers mean. In the end I calibrated some by getting some dry soil and pouring water in whilst using a finger to decide on a subjective scale of dry to mud bath. I think the Hello World for a LoRaWAN device would be a Temperature & Humidity sensor on I2C which unfortunately leads people in to the side pit of hell known as trying to send floating point data.

So, anything that reads analog from the main MCU and perhaps a couple of switches is good. Anything you like on I2C as long as it doesn’t involve floats or if you like to read first then try to shoot yourself in the foot but miss, because you did some prior learning, then you can read this:

https://www.thethingsnetwork.org/docs/devices/bytes/

Then add an LED and send downlinks (very occasionally) to turn it on & off and alter the uplink time/frequency.

Then you can move on to the full autonomous self-driving vehicle with 1s updates on a GPS tracker packed in to 5 Qbits sent via the new LR1110 using 2.4GHz gateways whilst it listens to archives of vinyls backwards trying to find out who shot JFK.

1 Like

Yes, these are good. And can be more interesting than expected - I left some test devices sprinkled around my home while on vacation last winter and it was very interesting to watch.

The sensors themselves usually produce fixed point data, one should indeed try to transmit a fixed point format as well, for example, temperature x 10 or x 100 in two bytes. With care the translation from the I2C register format to the data packet elements can be done without any floating point math at all, though some random example / Arduino library version may use floating point for conceptual (rather than engineering) simplicity.

An end device with a lot of sensors would of course want to look at more optimal formats. And there are things like light levels which really should be floating point, but a carefully considered appropriate floating point not just whatever encoding the MCU’s C compiler has.

My gateway is online! Overview - wololo - The Things Network

Is there anything else I need to do or can check short of actually building a node now?