TTN Console gateway traffic and device data only sporadic

Hi Jan the search function is really powerful and as noted there are many years of experience logged in the forum, so please do try even if you think it might be impossible. Yes, you have to do some reading but the answers are often there :slight_smile:

remember I stated

Well I looked at your OP and saw you were using ABP, you could see increasing or incrementing counters in the console. It took me 10 secs to type those 3 words in the search function…and low and behold 4th item on the list tells you pretty much what Jac said above … and the post even had some pictures posted to give you more of a clue :wink: If you have other questions give search a go - if nothing else it will lead you through places where you can learn and find out lots of background which will help smooth your LoRaWAN & TTN experience. Of course if really stuck always come back and post as forumites always willing to pitch in and help. Another good start point is the TTN documetation https://www.thethingsnetwork.org/docs/index.html and if in doubt check out TTN CTO Johan Stockings recent LoRaWAN in 60 mins on YouTube frm the recent TTConf… wont solve issues like the counter issue directly but all helps with background and understanding. https://www.youtube.com/watch?v=ZsVhYiX4_6o Also I would encourage you to join in with one of the local TTN Communities - I guess its a long way frm the Batry Bay/Dumanus Bay area to either Cork (about a half dozen members) or Limerick (Larger at about a dozen). Of perhaps you guys out in West Cork can start another for the area ( I see another GW up in Bantry itself - from little acorns etc). And in post pandemic times (when they come!) always a good excuse to meet up and have a pint of the black stuff :wink:

Hi, I am not disputing that if I had known what I know now, that I could have searched with more relevant words but I also know from own experience that ppl that are in the know of something expect to much of “connection making” of someone that is totally new to a subject. I was indeed talking about a counter but that was the message counter of the GW, not of the devices. Also ABP was in any YT video I have seen shown as the easy to start with thing, nowhere have I seen that this will cause issues with counters. So looking for ABP issues would also not come to mind as a thing to look for. So all of you that are in the comfortable position to know a lot may have to just expect ppl not to be able to correlate 2 seemingly totally different ends of a problem. And I have also not just given it a shot with posting here because I have not looked elsewhere, I 1st of all spend days to find out how I can just compile example code in PlatformIO and to figure out what pin definitions are needed for the particular boards I have. I have also spend hours on Andreas Spiess YT channel to get information. That for example is the reason to buy a GW instead of building one to start. I felt it was enough of a challenge with the home brew clients and I needed a known working factor as GW. It is the norm for pretty much every forum I have seen since the beginning of my internet use that ppl unacquainted with the subject matter will not know the right words to search for, this forum here being no different. I am totally new to LoRa but I am not new to IT, my background is TCP/IP networking and WAN infrastructure. I like to think that I have a reasonable grasp on technology. Maybe you in the know expect to much from “new players”.

That is easy to say for someone intimate with LoRa,

So please all accept my apologies for not knowing the right words to search for. I am sure it wont be the last time and I am surely not the last user that experiences difficulties.

Again, thanks to all and maybe just reconsider what you expect from new users.
Kind Regards
Jan P.

Definitely will do once we can meet up again :smiley: I have the use of a number of prominent mountain radio mast sites to deploy GWs. My goal is to run a server my GWs connect to and handle my own data myself and forward all other clients that may connect to my GWs to TTN. I have not read in depth but I will have a closer look at the ChirpStack. Anyway, that’s for the future but its what I am aiming for.

Regards
Jan P.

That would put you outside the scope of the TTN, and naturally we would refer you to the Chirpstack forum in that event, for now lets assume we can persuade you to use and stick with TTN - afterall why have a dog & bark yourself (other than academic interest :wink: )

We all started somewhere - I spent the 1st 2-3 weeks after I joined just reading posts, absorbing and watching, and that after dipping in occasionally, annonimously, over a couple of months before that before I started asking questions … though I knew a little on LoRa/LoRaWAN before that so answered a few before ever asking my own. Like you I started with prebuilt GW’s then moved on to self builds as I gained enough knowledge/confidence to be dangerous, after a background that also included a bit of IT, networking and some wireless, though more sales/mktg/biz dev than deep techy - so I’m confident you will get there if I can.

Envy you your location and general West of Ireland position - love the area - used to be frequent visitor (mostly the Dublin/Cork/Limerick/Shannnon/Ennis triangle) for biz and occasionally pleasure. Also around Tralee, Ballybunion, Kilkenny/Killkee & Galway…so hopefully once we are plague free and all opens up again I will get back - might just look you up and buy you one of those pints to see how you are getting on. Have a look around the forum and the Irish communities as there are a number of active members in country and many started in last year or two as new to LoRa/LoRaWAN also so might help learning curve and share experiences :slight_smile:

Absolutely no need to apologise - all we ever ask is that you try : and as mentioned earlier we are currently underway with a project to hopefully make it easier for the new guys & gals to start up and find their way around

That depends entirely on how well I can deal with the airtime limitations. Since I have no practical experience yet I can’t tell. Running my own private would only be needed if I can see that the airtime becomes an issue and if I can configure that to suit my needs on my own system. But that’s future. For now I am fighting a battle again with PlatformIO and the example code for OTAA … I am Network and Systems engineer, not software developer so there are clearly my limitations.

Re location, I am only a blow in here, I am from DE originally and live here since 2003. West-Cork is no doubt one of the nicest places to be :smiley:

If you have a suite of devices that are going to be in excess of the 30s Tx FUP per device per day, LoRaWAN may not be right for you.

What sort of data are you hoping to collect? Best to do some calculations now rather than end up with kit & infrastructure and find out you’ve hit the ceiling?

@descartes I am not to bothered spending a few euro on a test setup. So having one or two GWs for testing and a hand full of clients would be OK. The data collected would be mostly environmental and possibly also downlink to react to a value I read back. LoRaWAN is pretty much the only possibility short of using dedicated 8xxMHz ISM band modems with RS232. For “good times” I can easy use devices such as Wireless Point to Point links but I need something more resilient and only low bandwidth. The Airtime limitations are kind of weird. If I for example need to read 5 values and send them from one device I might be bad on Airtime, Yet if I have 5 devices sending those 5 values I am OK if I understand the limits correct.

Well, I fight my OTAA issue 1st, that appears to be the most pressing now to avoid that counter issue I had with ABP and then deploy a few devices to see how I get on with Airtime.

Regards
Jan

PS: What other tech than LoRaWAN would consider as alternative ?

At the very least put the 5 readings in the same packet so that you only pay the penalty of the network headers once for all of them together, not for each individually

1 Like

So very deeply unlikely, we can pack rather a lot of data in to a single transmission. I’ll post some links when I’m not on iPad.

1 Like

For debugging next time something is amiss:

This means your gateway is operational and you should be seeing packets in the traffic tab of the gateway in the TTN console. Keep in mind that tab only shows traffic arriving while the page is open, no historical data.

You are thinking WiFi. In LoRaWAN a node connects to the network. The gateway is just a ‘media convertor’ receiving RF data and forwarding it to the backend and transmitting packets when instructed to do so by the backend.

At any time when traffic is shown in the gateway traffic tab and not in the application you can stop thinking about gateway issues. Once the data is received by the backend the gateway is no longer involved.
If there is no data listed in the application data you need to consider issues with:

  • uplink frame counter (mostly ABP only issue)
  • DevEUI, AppEUI and AppKey for OTAA
  • Device address, AppSKey and NetworkSKey in case of ABP

When the EUIs/Address and the keys don’t match the packet will fail the message integrity check (MIC) and not be passed on to the application.

BTW, for MikroTik devices, please make sure only packets with correct CRC are forwarded. Packets with CRC errors won’t pass the next check anyway and only increase traffic to the backend. It may account for the amount of packets your gateway has received.

If TTN airtime limitations are an issue you should consider what happens when you start exceeding them and other users in your vicinity do the same. You will all be using the same shared resources (radio spectrum) and there is limit on what you can use before things start to fail. LoRaWAN in EU does not use LBT so in a busy locality before you know it traffic from one node will collide with another nodes traffic and both transmissions will be lost. LoRaWAN scales really well for low bandwidth applications and really is not suitable for high bandwidth ones.

You understand both the legal limits (active max 1% of the time, but do go to something even close as you will effectively kill all LoRaWAN applications in that region) and the TTN fair access policy of 30 seconds average daily.
That policy has been created to grant every device a fair allowance of airtime without monopolizing it. It also means a device only uses a fair amount of the shared backend infrastructure which TTN provides for free.

1 Like

Keep in mind there is absolutely no guarantee the downlink will get to your node. Or that it gets there in a timely manner. LoRaWAN class A (what most people and devices use and certainly the only option in the version of the TTN backend you are using) is not a good match for control applications. The node should have its own logic on how to handle things and downlinks can be used to change settings in a non time critical way. If you need to control anything from a central location check Class C (and even then there is no guaranteed delivery) or go for another protocol as LoRaWAN is not the right technology.

2 Likes

This isn’t a thing with OTAA as it resets the counter for you with the join accept. And for your ABP question about stopping it happening, you can, for the purposes of development, turn off counter checks.

You may benefit from the following:

Read all of:https://www.thethingsnetwork.org/docs/lorawan/
The devices section of: https://www.thethingsnetwork.org/docs/devices/
The gateways section of: https://www.thethingsnetwork.org/docs/gateways/
The network section of: https://www.thethingsnetwork.org/docs/network/
The applications and API sections of: https://www.thethingsnetwork.org/docs/applications/

LoRaWAN from device to dashboard has as many moving parts as High Altitude Ballooning - without even the basic introduction to the topics in the links above, new users don’t know what they don’t know. It will save you hours of bench time & searching & asking questions if you can read them.

As to airtime, have a look at this calculator: https://avbentem.github.io/airtime-calculator/ttn/eu868/27 which I’ve set to 27 byte payload which for an optimistic data transfer rate allows you to send once every 4 minutes. In LoRaWAN terms, that’s a lot of data. Typically a device may send that once per hour or if there has been a significant change. With a 27 byte payload, even on the slowest normal data rate you can still send every fifteen minutes.

1 Like

Hello,

@kersing the word connect is probably wrong, I should have said my GW can receive my node. Which was very important for me to know because I could very quickly figure out the frequency plan must be set wrong in the source code. Also SPI bus pin mapping for the LoRa module was not so straight fwd and seeing that my GW can receive my node helped to know the radio as such works. Did I not have that access to the GW I would have struggled a lot longer.

I am in a location so far away from any urban center or population center I doubt that will ever be an issue. If TTN had an option for a paid service I would be more than happy to pay, I am not one that expects everything for free.

My expectation are low, I don’t intend to control anything that could have serious consequences if there is a break down in communication.

I did not imply that OTAA as such is the issue, as I had stated above the example code found on the internet that comes with the lmic (various versions of lmic) libraries has never worked for me out of the box. So that issue relates to getting OTAA to work in the 1st place on my MC. Expectation where that this would solve the counter issue. Now that I have OTAA working on my MC and tried to reboot the node I see that OTAA is a solution for the issue I had originally when this topic started.

I am aiming to have approx 10 bytes of payload send every 5 minutes. Obviously trying that with my temporary setup here at home wont be any use. I will deploy my GW 1st to a suitable mountain site and then just give that a shot. Since the airtime is part of the meta data I should be able to calculate very easy if I am within reasonable limits.

I did read some of the information on accessing my data via MQTT and looked at the API reference to see how the payload is encoded. I tend to google for the buzz words that come to mind if I have an issue and if I do so TTN sources rarely show up. Except my failure to correlate “No data for device” to having an issue caused with ABP and the counter not resetting. I actually have no problem with LoRa or TTN, the most grief I have is so far MC and compiler related. I have not come across any information from TTN that would have helped there and I would not expect that TTN would be able to help. There are just to many badly build and documented MC boards out there.

Anyway, I was in the end able to compile the firmware for my MC and have OTAA working on a test node. This fixes my original problem thanks to the suggestions you guys made.

All happy on my end. Looking fwd to put my GW on a mountain site and run a test node for a few days. Should be there by next WE latest.

Have FuN!
Jan P.

PS: REALLY ? I can not reply now because I am new here ?!?!? “You’ve reached the maximum number of replies a new user can create on their first day. Please wait 56 minutes before trying again.” You are definitely going over board !!

Strangely enough, they do, how do you think TTN gets funded!

https://www.thethingsindustries.com

It works for us given the four volunteer moderators not only moderate but bring some expertise to the party as well.

This comes to mind :wink:

1 Like

OK i just checked, somehow the option in the middle, between TTN and TTI is missing to make that work. 1000 devices and 190 Euro per month, not what I had in mind. I would not mind paying somewhere in the region of 30-50 euro if there is tech support.

I just take your word for it. Some how just not encouraging to new people to get involved any deeper.

Kind Regards
Jan P.

Interesting figure - it would cover servers and “the servers are broken” tech support. But wouldn’t cover “how do I …” issues, which is the thing we really struggle with. ideally we need to find time & funding for someone to write a guide …

As for the forum settings, if we stop because we can’t cope with the already silly amount of time we spend here because we love TTN & LoRaWAN and the things they can do in a community (flood monitoring, animal feed, gates open, little old lady in freezing cold house etc), the forum would devolve in to something akin to the Wild West.

@descartes If one needs to read a number of documents before even getting started its already to much. A full on enthusiast maybe OK, but someone just putting a foot in the water definitely no. There needs to be minimal reading with a high chance of success.

What I have done in the past and still do. If I use an open source or free of charge product and I am happy with it and like to help maintain and develop it further I support the project financially. I do not have the skills or time to help out with code or community work. In return most of those have a channel to their supporters to make it easier for them to use the product. TTN could do the same. Either you have time to spend on reading a lot or you spend the money on easy access. Its peoples choice then. TTN could then use that money to develop a " Getting started with success" guide. That way everybody would benefit.

Does that statement in itself not suggest that there is an issue for newbies getting started ? Documentation is maybe not as accessible and easy for new ppl as full on knowledgeable LoRa/TTN experts think ?

BTW, I did not think I elaborate any further re my 1st experience with new user restrictions, I have posted my thoughts on that in the relevant topic.

Kind Regards
Jan P.

PS: Just to emphasize that again, I am thankful for the help I got for my initial issue with the frame counter and ABP. I don’t mean to be a “dick” here. Thanks to you guys I have gotten my issue resolved.

The part of LoRaWAN you are looking at is not at consumer level and probably won’t get there. I have commercial LoRaWAN trackers which shield the LoRaWAN part by offering a device you buy and a mobile app you use to check where the tracker is located. That is consumer level.

LMIC on your own selected hardware will never be at that level due to the amount of possible combinations of hardware and versions of the LMIC stack. If you buy Heltec Cubecell you would have an easier entry point. Or use Dragino LT-22222-L LoRa I/O Controller where you just connect your external hardware, you’ll have yet a different experience, much more consumer oriented.

1 Like

That was tried with flight training at the beginning of the 20th century with poor results. Every year in High Altitude Ballooning we have newcomers who don’t read the docs (which are much better than LoRaWAN) fly Alkaline batteries - which freeze and the tracker stops working.

There is an ongoing debate about this with the new Raspberry Pi Pico. It’s not very Arduino to get started as you need to spend an hour diligently installing stuff (or use a Pi, run a script, have beer, get started).

Somethings you can’t just dive in and have success within a shortened timescale. You have to build up and read the docs. Even with the junior programmers I coach, it can take half a dozen device builds, gateway setups & server configs before they start ‘getting it’ - about one call in three I terminate because they haven’t done their homework.

My wife used to be a driving instructor. She stopped because of the other drivers, the learners were fine. But despite giving them DVDs and a book so that the briefing time could be kept short and they could do more driving, hardly anyone made use of them.

The links I gave have been refined over the last couple of years as the bare minimum. It barely covers integrations (getting the data out, which is rather the point of having devices).

This all assumes the new comer can actually code. Many can. Too many think they can. Some can but haven’t done anything on CS theory - where data types, float representation and bit shifting comes in handy. Some try to do this stuff without any coding skills - they can buy an off the shelf device, but then find they struggle with a payload formatter (JavaScript) or the integration.

We live in the time of FaceBook, but not all things can be FaceBookable.

Both the TTN stack and Chirpstack are open source software you’re free to host and use yourself.

The problem is that you’re asking for support rather than software. And support is what costs money.

Quantities of nodes aren’t expensive to support, unique nodes and unique users are.