Yes, see also:
thank you so much
@brocaar Good. I have never had a problem starting a packet-forwarder on a Pi3 Strange you suggest it takes several attempts to start. Any idea of the root cause? I can have a closer look if you have some idea of the cause.
I don’t know, but I have read others have posted the same on the TTN forum. If there is a better solution, then please let me know! This was actually the reason to also add Monit monitoring to the image, so Monit would handle the restart instead of hacking a re-try meganism into the /etc/init.d/lora-packet-forwarder script.
First reaction, Monit is probably the best solution. Anything like a hardware watchdog timer won’t be able to (easily) monitor different processes. Similarly some form of loop in the packet-forwarder start script would also be somewhat limited in what it can detect.
BTW, I also create a cron job to reboot a Pi at 2am every morning. Have done this in around 100 RasPis and they have been running reliably for years using this approach. Some are Pi1 installed in 2012.
Was there any specifc reason for a daily reboot?
Not really, when I first started it was more out of ignorance. I am worried about leakage where buffers, memory etc overflow in time for unexpected reasons. Probably now just do it as its simple to implement and don’t even think any more, just part of my standard configuration.
I am looking at watchdog timers mainly to handle power supply brownouts where the voltage drops to stop the processor but not low enough to trigger to power on reset circuit. Don’t think the internal Watchdog timer in the Broadcom chip is suitable, may implement an external device
You can also let Monit restart services when they consume more resources than expected 
1 Like
Have you considered allocating a core to monitoring and the others to Lora functions, to minimise the effect of load on the monitoring performance?
No, I have not, but that could be interesting. Have you seen the need for this, even when there is not a high load in general? For now this is not a high priority for me, as I prefer to focus first on a stable release with the OTA update meganism in place. Also many ARM based gateways don’t have multiple cores so this would be for RPi based gateways only.
Agree, would work on a Pi3 but not on a PiZero. Then as you say there are the other ARM processors to consider.
I am looking at this in another application where I get the ARM chip to use the General Purpose Clock to generate signals up to 100MHz and not be interrupted by the OS.
Awesome … that’s great news
@Tony how are you progressing with the channel-configuration? Please let me know if you have any questions 
Looking forward to have more channel configuration added!
Hi @brocaar, have been side tracked with a gateway problem. I have been looking at the number of json files to create and it looks like there is a complete set for each different gateway manufacturer. If this is the case there will be a large number of files to create. I fully understand how the RF chips operate and how to create the IF frequencies and so looking if we can create a set of rules to create the json file rather than simply copy.
Maybe it might be an idea to modify the gateway-config script to show the channel-plans per shield type. E.g. the iC880A does only support the EU868 band, so it doesn’t make sense to addn and display other band-configurations. Then we can merge this in in smaller chunks
In addition only the RAK831 has the GPS, Lorix has implemented variations in power in response to different antennas. So, I was thinking about implementing some form of capability table which determines which options are requested. I’m thinking about how to create flexibility for the next manufacturer that could be added.
Could not agree more. I’m reviewing the json files with the purpose to propose an architecture on how the gateway-config could work and then as you say, implement in small chunks, one at a time
I believe currently they are all the same (e.g. all folders contain the same global_conf_eu868.json file), but it should be possible to modify them per concentrator shield because of the tx_lut_ values I believe as these could be vendor / model specific (that is what I understood), so I don’t think that we can avoid duplication.
I am looking to see if we could create the vendor, country and Channel Block as data which would be populated into a master template. You are already doing the same with “gateway_ID”. For GPS, we just append the extra lines. As far as I can see the same approach would work for Lorix, all they are changing is some of the power and RSSI settings.
Lorix have the right idea of adjusting power dependant on the antenna gain. I haven’t seen that in any other gateway configurator, it seems it up to the installer to manually change this. I’m guessing a lot of gateways would not be compliant due to ignorance of the installer. The approach I am thinking about could be extended (in the future) to ask a series of questions about antenna gain, antenna cable length and loss and from this set the correct power levels.