As very first device in my TTN-configuration, trying to setup an EndDevice of type Dragino LSN50_v2-D20 basically according to this Dragino-manual.
The device is brand-new.
But some ‘alignment’ problems for which assistance requested:
the QR-picture on the package and devies is refused by the TTN-read-out as ‘invalid’
=> manual setup required
when manually inserting data at the web-interface for the LSN50 via the repository,
it comes forward as a device using ABP instead of the OTAA mentioned in the Manual.
The information asked at the web-interface does not seem to match the information on the package-sticker/device-sticker vs. the Manual,
in such way that the stickers only have 4 lines (= DEV EUI, APP EUI, APP KEY and 8SN), while the manual shows 7 lines.
the web-interface does not ask for Joining Server and for APP EUI (which to me seem rather significant as entry info).
Have inserted info to best understanding, and tellback is that end device has been updated and ‘Console: stream reconnected’, but no live data seen.
IMHO, that may have 2 causes:
EndDevice is out of range of a Gateway.
some wrong entries in the setup of the EndDevice.
Aspect 1. is a technical issue, solvable by setup of own, local Gateway.
To tackle aspect 2., where to find actual&unambiguous info for startup-procedure in combination with the sticker-info?
Technically & obvious, it is a complication when no communication is running between EndDevice and TTN-Server. IF some sign of tellback would show, at least one would know that ‘traffic’ is possible.
In this perspective a simple, basic heartbeat-function would be very helpful as signal for existence of communication.
If there is an entry in the serial log saying it’s transmitting, that’s what the MCU thinks is happening.
If there is a corresponding entry in the gateway log, that shows the device is actually transmitting.
If there is an appropriate entry in the gateway web console, that shows the device is transmitting correctly and it’s got to the Network Server layer.
If there is an entry in the devices web console, that shows it’s all working.
The MCU doesn’t know if the antenna is attached or the radio is working properly. The radio does not know if a gateway heard the transmission.
As a device relies on a multi-step process, it’s pointless providing a red/green light on the device as it will only come on when you see traffic in the console. It can’t diagnose anything, just say that it is reaching the network server (and the way it would know we wouldn’t want it to do that too often), or if you had an application process running, say it had reached your end point. Both of which you can see for yourself.
Pretty much all debugging to get started with LoRaWAN involves reading the Learning section and having your own gateway to look at local logs & the gateway console. Particularly the learning section - OTAA & ABP are authentication methods, not modes of communication - once a device is in contact the data format is the same. The learning section should cover the App vs Join EUI renaming as well.
The hints to ‘operation’ you mention are already luxurious in my view:
as ShortWaveListener I was more thinking in the direction of S-meter-reading, just indicating the presence & level of the received signal, nothing more.
As response to the bottomline of your message:
at the Console under joinEUI a ‘none’ is reported, which in my opinion not a good sign.
As part of testing the past week, very emperically/practically toured the neighbourhood by bike with the actieve device, but no reaction visible around the gateways marked at TTN’s maps.
Sign to me that setup is at fault, although in line with the Dragino-manual:
reason for my first question for ‘correct&applicable’ documentation.
Present experience also reason to asap get an operational local Gateway, to avoid having the risk of at least 2 hurdles at the path for communication.
I don’t think LoRaWAN signal strength would register.
Not sure that’s actually possible, never tried, an App/JoinEUI is pretty much core to the device’s ability for a the LNS to know how to route the uplink. Please can you tell us exactly what layout you are looking at and a screen shot. The only secret is the AppKey, most of everything else is transmitted in plain text at some point, so if that’s showing, feel free to redact that, but not anything else.
As to registering the device, use the DevEUI, AppEUI (as JoinEUI) and AppKey - things move on with inventory in the sales channel vs the almost instant changes on the web, so by learning the fundamentals you can translate older docs to the newer environment. Picking too hard at the details for a common off-the-shelf device just holds you back.
Using different expressions, but probably we are at same aiming-line:
last months reading the documentation within reach for understanding the ‘basics’
and with that trying to realise a very simple configuration to test the water.
On purpose choosing ‘mainstream’ items, expecting proven, valid & simple manuals etc…
Experience has taught me to be very watchful for jargon:
handicapped by “outsider’s view”, needing guidelines as unambiguous & simple as possible.
In future will add screenshots to responses where it might help.
TTI keeps updating the TTN Community Network software which results in manuals no longer matching what is currently deployed. Device manufacturers can’t update their manuals every time the TTN site gets updated, that would be a full time job as TTN installs new software every couple of weeks.
Also some resellers might have stock that doesn’t match the published manual, either because the units are too new or too old to match the manual.
Having a good understanding of the LoRaWAN basics makes it easy to map old LoRaWAN naming to the new names being used.
That said, after working with TTN for over 7 years every now and then I still need time to find things because they’ve moved and/or have been renamed.
Understood.
Have overestimated the stability at TTN-side:
extends my learning curve for different plan of attack with more reading, more frequent own try & error and less questions in the forum.
As this is a well indexed site, stability usually referring to things like up-time etc, stability is good.
However fixes & enhancements are run on a two week schedule - occasionally the layouts of a data entry page change - the fundamentals apply, the boxes may move or have additions.
“Unambiguous text” is & remains a sensitive aspect, especially if using non-native language.
In my previous message tried to refer to stabiltity of setup-procedures and -documentation, not so much to the technical state of data traffic, uptime etc.
Perspective:
most users generally less interested what happens in the (technical) background,
but MMI is always at the front-row.
LoRaWAN is not an end-user system, it’s up there with the routers that run the backbone of the internet - think complexity two or three orders of magnitude than your average home router.
The TTIG gateway and, frankly, most of the Dragino range are about as close as you are going to get as being deployable by technically savvy users.
Rather than hoping that better instructions will materialise, the best way is to try stuff out, make mistakes, look at logs, read up on the messages you see and ask highly focused detailed questions.
