Hi Kevin,
Sorry to come late to this thread. I have been monitoring it closely, but didn’t like to comment as you had said you were already dealing with Keith/Chris/Lee. Now that a resolution to the problem has been achieved, however, I feel that comment is now appropriate.
Firstly, I’m very glad to hear that the latest 20201230 firmware has resolved the issue with the naming of your SDRs. I had noticed a couple of similar glitches myself during some recent setup tests, though they were nowhere near as serious or persistent as those you were reporting and in my case were easily resolved, so I understand your concern. What I am concerned about, however, especially now that Lee has resolved the issue, is why you still feel the need to ‘tweak the system’ by introducing options so that you can check the USB setup, when this can already be safely and effectively done simply by re-running the config? IMO the more additional ‘options’ we introduce, the greater the risk of mistakes being made by inexperienced users and we should therefore discourage such ‘alternatives’ unless absolutely necessary.
As you are obviously aware, stopping the services is necessary prior to making any changes. Many early users fell foul af this and other issues when trying to establish and configure their stations and simply couldn’t manage to complete the setup. With the significant improvements Lee has introduced over the years, users no longer have to go through the exhaustive process of setting up the stations from scratch and need only a very basic set of instructions and almost no knowledge of Linux. Lee has even simplified the more regularly needed commands so that we no longer need to change directories or run extended configure scripts. Should it be necessary to reconfigure the station, we can now simply log in to the Pi and type config [enter] at the prompt. This stops the services, checks and reports the USB status, and if you don’t need to make any changes it’s simply a case of answering ‘No’ to each question to maintain the status quo. MUCH easier than it used to be. OK it also reruns the GSM scan, but that’s no particular hardship - and before it was automated was probably the major cause of failure to complete the setup and subsequent poor quality operation.
Since we first started the OGN-R project, all of us in the Development Team have maximised our efforts towards simplifying and standardising the setup process to ensure that (as far as possible) all stations on the network are configured to exactly the same standard, regularly automatically updated and operating in exactly the same manner. Preventing unauthorised or inappropriate modification or ‘tinkering’ is essential to this process. This makes things infinitely simpler both for ‘non-techie’ installers and for those of us who have to support them, makes fault finding easier and minimises the potential for errors or incompatibilities to be introduced.
Perhaps more importantly, it also detracts from the opportunity for others to levy criticism that the network fails to achieve an acceptable common standard and has been ‘cobbled together by amateurs’. This is becoming ever more increasingly important in the light of the polarised opinions expressed on the various forums and elsewhere and in the areas and at the levels at which we are now striving to operate.
I hope you can understand my reasons for these comments, they are intended as an explanation, not a criticism.
Best Regards
Peter