Looking for confirmation about the process to add this gateway to V3. Looking through the gateway configuration options on http://192.168.55.1/ I find a Device ID (same as printed on label). How should this be modified to function as EIU or is the EIU somewhere else?
It reports as not exactly 16 characters.
And of course are there any other snags when adding Gateway to v3 ?
Can you provide a link to documentation of this gateway?
The local IP address you posted is by definition not routable, but only usable from within the same subnet (in and of itself a good, thing, you don’t want other people poking at your gateway itself)
The screenshot “Figure 1.4.1.1-A GateWay Info” does not show a proper 16-hex-digit (8-byte) gateway ID for the Semtech protocol that it otherwise seems to be using.
You’ll probably need to ask the manfufacturer or temporarily point the gateway at a system running something like netcat listening on a UDP port piped into hexdump and figure out what it is actually using as an ID in comparison to the protocol documented at packet_forwarder/PROTOCOL.TXT at master · Lora-net/packet_forwarder · GitHub
Then there’s also the issue of getting the channel configuration right.
It’s really unfortunate that a lot of vendors use silly non-standard GUI configuration rather than using a standard global_conf.json file.
It’s possible with a little effort you’d be able to build your own software for it from standard sources, it looks to be running a fairly ordinary Linux.
Found a long thread in the Forum which concludes with a set-up guide (for the US version). https://vinduino.freshdesk.com/helpdesk/attachments/48016288533
Will update the ticket when I figure out the next steps and complete connection to v3. Of course if you’ve made these steps already do share your wisdom.
Having created a thread here which future readers may find, it would have been useful if you’d posted the key piece of information about getting from a 12-digit factory ID to a 16-digit protocol one, and not just a link which might die:
Allegedly that would be to
Add 0000 in front of the Gateway ID obtained from Step 3
There shouldn’t really be much specific to V3 vs V2 involved, other than making sure the server address and UDP port are correct for the V3 servers applicable to a region - naturally the factory document still mentions V2 if it even correctly identifies a TTN server at all.
A packet forwarder used on V3 really should be a version recent enough to include the downlink JIT queue added upstream a few years ago but it’s not immediately apparent how you’d determine that in a vendor build - the appearance of the string “JIT” in logs or via greppping strings in the binary would be a positive sign. If not there’s supposed to be (eventually?) be a checkbox for registering an older packet forwarder which requires server-side downlink queue management.
There is
My device was supplied pre-provisioned.
required actions
login to the wifi area network emitted from the device
default admin : admin
Packet forward > Settings note the Gateway ID and add leading 0000 to make EUI
edit server address as required
The gateway is good value apart from poor documentation. wifi access point is a smart feature.
For info, extract of the log:
### [JIT] ###
# SX1301 time (PPS): 1030988148
src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####