I believe that in the first instance we need a lot more detailed documentation and logging with regards the the procedure the board goes through at startup; with this information the community can then perform some help diagnose of issues and possibly make recommendations based off logs and code. This however needs The Things Network to publish good full documentation detailing status/error codes, given that most backers have waited over two years patiently for the gateways and for them to arrive with what seems on the face of it to be a fundamental issue that could/should have been detected in QA/certification isn’t ideal, but I for one am willing to assist and work through this with other of the community, but we need TTN to
1.acknowlege there is an issues/issues
2.group issues based on symptoms
3.open communications with user forums
4.establish versions of hardware/firmware
and origin of manufacturing that have issues.
all this needs to be public
sorry for the rant, but I feel direction is needed
Re-seating the LoRa-board (which by itself already seemed to be seated well) did not help for me, also not when I left out the foam block altogether and applied some more downwards pressure to the board. (The length of the white plastic fasteners makes the board to not be parallel to the main PCB. It seems that there’s quite some pressure on the board, but I’m not an expert.)
Also powering without the board once and re-seating afterwards, did not change things: I still get one or more LORA: Configuration failed, retry, eventually followed by a reboot showing Reboot reason: 0x13 (where I’ve also seen Reboot reason: 0x53.)
As an aside: patience helps to make the glue come loose. Lifting the board will put some tension on the glue, which will come loose slowly. My LG8271 LoRa board says on its bottom side:
I think in my case it started correctly once because I left the gateway untouched for a day or two. That is also one thing I have noticed, it you don’t have it powered on for some them and then do, it seems to connect most of the times once for a short while, and after that it fails every time, until you switch it of for some time again. Strange…
Hey guys,
is it possible to change the gateways config to send all packages to a private “lora gateway bridge”? As i mentioned in this post Parking sensor with TTN gateway I like to use parking sensors with the TTN Gateway. The problem is that it is not possible to change the devAddr of the parking sensors, because they are hardcoded (0x70030051).
I installed the lora gateway bridge on a linux machine in my LAN and tried to change the router id of the gateway via
(I’m the author of the LoRa Gateway Bridge / LoRa Server project) I don’t think this is possible. The LoRa Gateway Bridge expects the packet-forwarderUDP protocol. The TTN gateway uses their own Protobuf over MQTT format (if I’m not mistaken).
Thanks for your response.
Do you have an idea how I could use my parking sensors with fix devAddr which be filtered by TTN? Is it possible with the TTN Gateway? Or do I have do buy or build my own gateway and configure the packet forwarder?
Can someone of the tech team/ moderator confirm that this is not possible please?
So I can talk to my prof for my master thesis and look for an alternative solution…
I’d just like to make an observation with regards The Things Network, and this forum & Kickstarter etc; We the loyal backers that have/or are wait the gateways need the communications to be better, communication from The Things Network is at best slow and inconsistent. (correct me if I’m wrong) I’ve not received or seen any acknowledgement from the team with regards any issues or what cause of action that those reporting issues need to take; yet the team and founder is re-tweeting and like all positive comments, which leads me to believe the either he/team is unaware of all these gateways that have issues or simply us backers are getting ignored as they try to push for more sales and promotion of the product as the conference!?
I was so hopeful but feel like I’ve forked out £££ for a product that has suffered delay after delay and has then been delivered with some fundament issues across the product range; as before happy to work to get this resolved; but not to be ignored by The Things Network team or see them liking good comments and hiding way from the true picture of this project.
I guess my frustration is starting to show, but I feel I like many other have given a fare chance for a response/acknowledgement
I agree. I’m lucky that mine works. But I fully understand your frustration.
In fact, as I’ve said before, TTN team should focus on getting product out, documentation out, and helping those with problems.
The upcoming conference is nice… but should be lower priority really. And the lack of an official statement or response on these forums about what they are doing to help the unlucky backers with dead on arrival gateway is not professional.
Yes Grahame, I fully agree. Most of the backers could settle for a bit of tweaking to make things work smoothly, is my estimate. However, there appear to be quite a number of people having very similar issues with the TTN-gateway. And lots of ideas, suggestions and test results are doing the rounds, also from users that managed to activate their gateways. But, apart from some forum moderation and participating in these technical discussions, there is nothing from The Things Network. No acknowledgment, no task force announcement, no status & outlook. This needs to improve.