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 
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.
@cslorabox I think that was what I said above, exchange money for access to support. Calling the need for support a problem is probably the manifestation of what I see as the main issue.
@descartes comparing driving an actual car or ballooning with actual people and a non lethal hobby is not realistic.
@kersing what you say is certainly very true. That is why I have not even attempted to find support here for the many issues I had compiling the firmware for my MCs. I had no expectation to be shown how to use PlatformIO and where to find config.h files to set up the correct frequency plan etc. I figured that out all by myself and a lot of cross referencing information snippets from dozens of websites and YT videos. That is also as I explained further up the reason why I did buy the GW, to have one end of the thing sorted out of the box and only my node/device to worry about. I have not asked for a turnkey solution served on a platter for free.
Well, I think I have exhaustively tried to explain why I am here in the 1st place and how it is frustrating to not be able to ask for help. And just to say this again, I asked, did not demand or gave anyone a hard time getting information about my setup. I have provided as much info as I can to give people a chance to help. The actual solution was quick, probably the 3 post right from the start.
Thank you for your help !
Have FuN!
Jan P.
1 Like
I don’t send people in balloons to 125,000 feet as I can’t afford the Helium, just small tracking devices, cameras & Haribo. The comparison I was making, from which derive part of my living, is aspirations vs the learning motivation.
People want to do things but don’t want to put appropriate effort in to learning - and for HAB, driving, LoRaWAN and flying, learning what you need to learn helps tremendously, but we struggle to get people to even learn the material we signpost them towards.
You asked about a quick-win out-of-the-box experience. The considered opinion for some activities is that it isn’t possible. Or at the very least, the quick-win is a couple of hours of video or reading, the right kit and then the simplest possible device, preferably a well supported one rather than the cheapest DIY components that comes with build issues.
We slow down new registrations for the very good reason that we’d be spammed in to oblivion - I still end up deleting a couple that do sneak through each week. The Raspberry Pi forum is down tomorrow morning for upgrades to combat the flood of Russian advertising posts so I’m well aware that there is a problem out there in that respect. But the other aspect is to encourage people to search the forum (I appreciate that knowing what keywords to use are an issue) and perhaps read a few posts - maybe use the keywords they learn from those posts. And as I said before, as volunteers, we can’t afford to let down the defences otherwise the forum would disintegrate in double-quick time.
It would be very useful to know what made you go with the TTGO LoRa32 as a first device.
It’s not clear that you yet have an identified solution to all of the problem you reported.
Illicit frame counter resets would explain why traffic making it to the TTN gateway page was not making it to the application or device page.
But they do not have anything to do with why traffic reportedly received by the gateway was not showing in the TTN gateway page, as that’s a view of raw traffic before it has been validated by LoRaWan protocol level checks where things like frame counter rollback could first be detected.
So either the issue was mis-reported, or you still have an additional issue - granted, it might have been some sporadic fluke of Internet backhaul connectivity or even server maintenance.
The issue re the counter in the device part was fixed by using OTAA as I stated much further up. Re the showing of GW traffic, It was pointed out that if I see the message counter clock up I should see traffic. I can however not confirm that I have seen the counter clocking up yet no traffic showing because at the time I believed to have that issue I did not look at the message counter. I was not able to reproduce what I though was an issue with the additional information so I just put it aside a user level error for now. Ofc should I see that I am missing traffic to show when I am sure there should be I can with the additional information come back to the issue.
Thank you!
Jan P.
It has a SMA connector, I passionately hate U.FL connectors and still prefer N-Type. It was available quick and cheap from a EU supplier. Quick was the key here, I have a lot of stuff cooking most of the time, between private life, work and other hobbies. I found time to look into something new so It had to be available quick. It can be programmed in the PlatformIO environment. Its based on the ESP32 which I have used before.
What I did not expect is the horrendously bad situation on the library side of things. Granted I am not a software developer and I usually have to muddle through with things but this experience was outstandingly bad and I am still puzzled how nobody in the many YT videos I watched does not pick up on that issue. This just as a side note, not a TTN issue at all !!
Another issue was the identification of the hardware and pin outs, that is however NOT a issue with LoRa or TTN, that’s just common for all kinds of pre made modules made in CN and I knew that I would have issues before I even ordered. Also the ESP32 not in a can, just bare on the board, IDK if that’s compliant with EU regulations but OK.
To have all as complete as possible I also got the Mikrotik GW with their 6.5dB omni, I am familiar with RouterOS since over 10 years, I know its shortcomings and have dealt with MT since over 10 years, I know what to expect (and what not to). The omni came with a very long (800 or 900mm) pigtail made from very thin coax. I don’t like that at all but its easy to replace with something less lossy and shorter. Also got a NanoVNA V 2.2 as shown in Andreas Spiess YT channel. I know from past experience with 900MHz Telemetry radios for Ardupilot (quadcopters, planes etc.) how rarely antennas are what they claim to be, so was a good idea to hit 2 birds with one stone.
If anybody has any specific questions that go deeper feel free, I am happy to provide any info I can.
Regards
Jan P.
1 Like
Some more HW info:
The GW is a normal MT wAP board, only difference is it has the miniPCI-e LoRa radio installed. The wAP board works ONLY with the MT Radio, no 3rd part supported.By default the SMA connector is connected to the radio, there is a PCB antenna inside the case on the right. That could be used optional if one does not need an external antenna.The SIM card slot is for use with a modem in the miniPCI-e slot instead of the LoRa radio. It has wired Ethernet with passive PoE (non IEE802.3af) and WiFi on board. The LoRa specific software is a package as all the other packages in the ROS universe. The LoRa software is also available for the ARM and x86 packages of ROS.
[admin@LoRa] > system package print
Flags: X - disabled
# NAME VERSION SCHEDULED
0 advanced-tools 6.48.1
1 dhcp 6.48.1
2 wireless 6.48.1
3 security 6.48.1
4 lora 6.48.1
5 system 6.48.1
[admin@LoRa] >
The TTGO LORA32 I have is this one:
I am using the following pin definitions for the LoRa SPI bus:
// Pin mapping for TTGO LoRa32 V2.16 (aka T3 1.6)
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 23,
.dio = {26, 33, 32},
};
IDK why 33 and 32 are in the dio line, I have this information from one of the many sites that provide information and it works on my board.
No disagreement there, I spent months getting to grips with the original Arduino LMiC (LoRa Mac in C). I don’t really do YT so I don’t know what’s being presented on that topic but I do see enough YT video to know its got an unhealthy dose of unrealistic success with none of the foibles. The current best release is considered to be the MCCI LMiC, they are working on getting the stack certified. The best but slightly pricey device for it is the Adafruit Feather M0 with RFM95 as that is a prime test platform for the MCCI LMiC. Once you’ve cracked that, you can always use a cheaper Arduino Zero SAMD21 clone with an RFM95 or use STM32. If you’re as daft as me, you can get the LMiC in to an Arduino Pro Mini and still have enough room to read a few sensors but you have to evaluate your RAM usage during development to make sure you don’t end up with a stack overflow.
We do consider this a TTN issue in so much as the Pro Mini + RFM95 was originally one of the cheaper ways to get a device running so there are a lot of tutorials to be found and it is still the cheapest option (in hardware costs, not time). But LMiC is bigger now as it becomes more compliant, but the older web pages doing a how to haven’t been updated. If you have a more flash and RAM, then LMiC is good but still has its foibles for configuration and integrating the sensors & formatting the payload can be a challenge for those with starter coding skills.
Again a common observation - lots of questions in the Big ESP32 topics around pins, people end up using RTOS which wraps itself around the mini-RTOS that’s in LMiC with some interesting side effects but most of all, getting deep sleep working is a huge issue - it doesn’t preserve RAM which means the device loses its OTAA join details unless saved in flash or EERAM and restored on wake up. And again, the forum aims to help.
It’s an odd mixture of topics here - we will try to help any reasonable technical issue that’s about getting a device or gateway going, configuring the backend servers or moving the data out to the end application - it is a community network which exists to help people create solutions in their community.
I had a very quick look, I don’t find that very expensive. On the Adafruit website it shows as 35USD. Did not yet look for a EU supplier, so I guess there will be VAT and import duty etc… I dont mind BUT I am not a fan of the Arduino IDE at all, I have warmed to PlatformIO if it comes to MCs. I much prefer the way that everything is project based, hardware settings, libraries etc… In the Arduino IDE I find it very frustrating to find my way around and also the code looks different and is not like normal C++. anyway, I am not an expert, just someone that usually tinkers with stuff others write to make it suit my needs. I usually work on Unix/Linux systems and compile from source code if I need to but that is usually never such a drama as it appears to be when it comes to MCs.
[edit]
Just to clarify, by not expensive I mean not expensive for a know good working device. I would not have spend that money on a chance purchase for quick shot like I did with the TTGO boards. I assumed worse case its in the bin and no drama. The Adafruit is not that price class to put it in the bin.
[/edit]
The sleep and deep sleep issues will definitely be a problem. I have seen that there is some memory on the ESP32 that does survive deep sleep but I have no clue if its big enough and how to make use of it. I have 2 projects in mind that would require a very low power footprint. One would be a sensor platform deployed on a mooring buoy of a yacht, the other would be a sensor platform to use on a yacht to report battery voltage, bilge water level and maybe wind speed but that’s a bit more involved.
I have no fixed preference for any hardware platform or architecture as long as I can use PlatformIO to make it do what I need and as long as there is properly documented and working example code available.
Regarding payloads, I have not yet added any sensors, only a static “Hello World” type thing. Getting the Hello world out of MQTT on my end has not been a problem, I just use Linux CLI tools like grep,sed,awk etc to work through the json stuff that comes back and pipe it into base64 decoding and there I have it. There is some json related cli tools that I have not yet looked into at all, that could potentially easier than sed, awk etc. I have not yet any intention of using and bloated GUI stuff or node red etc. I work happily with plain text and if needed put stuff into a database or use Cacti for visualization and Nagios for alarms. I also use the VoIP PBX system Asterisk for example for spoken alarms. Most phones have an intercom feature that allows to speak out anything or play back anything without pick up of the handset. Stuff like that does not need anything fancy, only a bit CLI and bash scripting. Definitely no Alexa or Siri in my house 
Have FuN!
Jan P.