there’s little reason to depend on external services when the data is flowing through your own gateway
The idea behind the community network is that you share your gateway with other users and other users share their gateways with you. Recommending people to implement their own ‘network’ is not in the spirit of TTN and takes resources away from the community network.
That’s not actually what I recommended; I suggested extracting and decoding your own data directly, without relying on TTN - I did not mention disconnecting the gateway from TTN.
However, as long as the architecture doesn’t make it easy to do this in parallel, flakiness in the TTN infrastructure does indeed point people who have real needs towards entirely private setups.
Long range, it makes a lot of sense to handle (at least in the sense of having backup decoding for) your own data locally, while still exchanging data with the servers to support other’s sensors in your coverage area and your sensors in others’ coverage areas.
For the decoding side this is fairly straightforward, what is missing is a way to arbitrate a gateway’s single transmitter between distinct network servers - ie, your gateway might be in the best position to respond to someone else’s TTN node, but if it were busy transmitting to a node TTN didn’t know about, then someone else’s gateway that was 2nd best for received signal would actually be the best choice for that particular transmission.
But ideally, a node should be designed to keep feeding data even if they don’t receive any downlink for a day or two, so a decode-only scheme (which causes no transmitter usage contention) is a viable fallback compared to having complete outages.
Both poly_pkt_fwd and mp_pkt_fwd allow forwarding data to multiple destinations. Having two sources for downlinks is an issue as it might cause duty cycle violations even if the transmissions do not overlap. (The network keeps track of the duty cycle, not the gateway, that might be something worth building into the gateway software some day. Anyone with an urgent need and willing to sponsor development?)
Good point kersing, I had different gateway and application regions. All running smoothly again now, at least through the RAK image.
Tried running Balena image again, but it worked for a while, then started getting what I can only assume was bogus packets. 12,896 RF packets seems too high to me. Especially when it’s 58 per second.
I think I might give up and just use the RAK image.
14.08.19 19:19:47 (+1200) main ##### 2019-08-14 07:19:47 GMT #####
14.08.19 19:19:47 (+1200) main ### [UPSTREAM] ###
14.08.19 19:19:47 (+1200) main # RF packets received by concentrator: 12896
14.08.19 19:19:47 (+1200) main # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
14.08.19 19:19:47 (+1200) main # RF packets forwarded: 12896 (296608 bytes)
14.08.19 19:19:47 (+1200) main # PUSH_DATA datagrams sent: 0 (0 bytes)
14.08.19 19:19:47 (+1200) main # PUSH_DATA acknowledged: 0.00%
14.08.19 19:19:47 (+1200) main ### [DOWNSTREAM] ###
14.08.19 19:19:47 (+1200) main # PULL_DATA sent: 0 (0.00% acknowledged)
14.08.19 19:19:47 (+1200) main # PULL_RESP(onse) datagrams received: 0 (0 bytes)
14.08.19 19:19:47 (+1200) main # RF packets sent to concentrator: 0 (0 bytes)
14.08.19 19:19:47 (+1200) main # TX errors: 0
14.08.19 19:19:47 (+1200) main ### BEACON IS DISABLED!
14.08.19 19:19:47 (+1200) main ### [JIT] ###
14.08.19 19:19:47 (+1200) main # INFO: JIT queue contains 0 packets.
14.08.19 19:19:47 (+1200) main # INFO: JIT queue contains 0 beacons.
14.08.19 19:19:47 (+1200) main ### [GPS] ###
14.08.19 19:19:47 (+1200) main # No time keeping possible due to fake gps.
14.08.19 19:19:47 (+1200) main # Manual GPS coordinates: latitude -45.91360, longitude 170.46727, altitude 0 m
14.08.19 19:19:47 (+1200) main ### [PERFORMANCE] ###
14.08.19 19:19:47 (+1200) main # Upstream radio packet quality: 100.00%.
14.08.19 19:19:47 (+1200) main ### [ CONNECTIONS ] ###
14.08.19 19:19:47 (+1200) main # thethings.meshed.com.au: Connected
14.08.19 19:19:47 (+1200) main # Semtech status report send.
14.08.19 19:19:47 (+1200) main ##### END #####
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [TTN] thethings.meshed.com.au RTT 99
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [TTN] send status success for thethings.meshed.com.au
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:47 (+1200) main 07:19:47 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:48 (+1200) main 07:19:48 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
14.08.19 19:19:49 (+1200) main 07:19:49 INFO: [up] TTN lora packet send to server "thethings.meshed.com.au"
The contrast between the 12896 packets allegedly received, all with correct CRC, and the 0 datagrams sent seems rather odd.
These stats should actually be resetting every time they print - so if you keep seeing messages like this, something is imagining traffic.
I’d probably be wanting to build the packet forwarder from source and add some debug code to it - your SPI clock might still be too fast, though one would think you’d be getting CRC failures or even total communication loss leading to packet forwarder crash and restart.
I have no experience with Balena, but there should not be any great mystery in getting an ordinary packet forwarder source base to work on this hardware, provided that you use a low SPI clock.