Testing today.
Total Crap. Beep base seem not to be in even alpha stage regarding consistency and reliabilty. My wife took out the power supply for the gateway this morning. One BEEP refused to reconnect. The other one also lost connection and will not regain connection while testing, wasting again multiple precious hours. 
I am starting to understand while no real world data is being put out on the BEEP website. Prolly is none.
Thatās not how LoRaWAN works: devices do not āconnectā to a gateway. Instead, once they get some secrets by activating on the network through one or more gateways, they simply just transmit when they want, and hope that the same or other gateways will receive their transmissions and forward their data to TTN.
However, with ADR enabled and sending every minute, then if the only gateway around was offline for a longer time, chances are that the device detected that its transmissions may have gone missing quite soon. For ADR, it will then have lowered its data rate step by step, until hitting DR0 (SF12 BW125). If not getting ADR responses at SF12 either, then at that point a device could choose to start a new OTAA join. But many devices donāt as it itās not likely to help at all. Maybe BEEPās source code can reveal more.
Assuming the device would just be stuck at SF12, the gateway should receive its packets once powered on again (without the need for a new OTAA join), and ADR should help the device to get to a better data rate again.
Indeed, TTN only forwards the data to the application that owns the device. (So, the one for which the settings in TTN Console match those in the device.) Iād assume you should copy and safely store the existing AppEUI and AppKey if visible in the app, and could restore those any time you like. But I donāt know.
Then apparently the reception quality was okay at that time?
And this may also allow for positioning the existing internal antenna vertically? That could help:
1 Like