British Forum > OGN-R PilotAware
New ATOM Ground station SDR Detection Issues
kevkdg:
Hello,
It seems the updated ATOM software version 20201230 has resolved the RTLSDR USB issues I was having. Early days but fingers crossed.
According to Keith this SW release included a bug fix where a buffer was being overwritten to make it seem like the RTLSDR was losing its value.
1. I am just wondering, is there a way to see the USB’s detected, the USB Port they are plugged into, and the SDR assignment (OGN/FLARM or 1090) as you do when you first run config but without running the config as this shuts down the services. For example:
Found 2 SDR's:
USB Port Top Left : SDR detected ID=1 currently allocated to OGN/FLARM reception on 868Mhz
USB Port Bottom Left : no SDR detected
USB Port Top Right : no SDR detected
USB Port Bottom Right: SDR detected ID=0 currently allocated to ADS-B reception on 1090Mhz
One SDR is currently configured for OGN and the other is configured for ADS-B reception.
Or can you run 'config', 'ctrl+c' out of it, then run just a command to restart services?
2. On the grid view, for OGN traffic you can see ‘l’ or ‘r’, is it possible to add a column to display the receiving station for ‘r’ OGN signals. You can see this on OGN Viewer as it flicks between the receiving stations when you click on the Glider?
3. Out of interesting, for ADSB, sometimes you see an uppercase ‘A’ and sometimes a lowercase ‘a’ in the grid view, what’s the difference?
For example:
---al
---Al
4. When you run 'config' on the new SW release 20201230, more options appear:
Do you want to change the ADSB Antenna Gain value () [y/N]: N
Do you want to change the FLARM Antenna Gain value () [y/N]: N
Do you want to change the PAW Antenna Gain value () [y/N]: N
These aren't documented on the buidling an ATOM Ground Station PDF so am not clear when you might need to answer 'Y'.
Regards
Kevin
exfirepro:
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
Ian Melville:
--- Quote ---Should it be necessary to reconfigure the station, we can now simply log in to the Pi and type config [enter] at the prompt.
--- End quote ---
That is not reflected in the current instructions.
exfirepro:
Hi Ian,
Yes, I appreciate that - nor are the new antenna gain questions reported in Kevin’s latest post.
Unfortunately it’s a case of rapid development to address issues or introduce improvements as they arise, with the instructions playing ‘catch-up’, rather than waiting for the instructions to be rewritten before introducing the fix or improvement.
I have to say, I wasn’t aware of the antenna gain additions to the config myself until I read Kevin’s post and don’t yet fully understand the reason for them, so won’t speculate here. In the absence of any instruction to the contrary, however, I suggest simply reply ‘n’ (no) and accept the defaults. I will make some enquiries and let you know what I find out.
Are you having any more luck with your Pi3 setup yet?
Best Regards
Peter
exfirepro:
Kevin,
I meant to comment (positively) on your points 2 to 4, from yesterday’s post (which in general I agree with and would support) but simply ran out of steam last night due to the lateness of the hour (for which I apologise).
When I come across unannounced and undocumented changes to setups or displays (which happens fairly often when testing beta software/firmware) I echo your frustration. I have raised this with Lee and the rest of the Team on several occasions. It is certainly most frustrating to be presented with new installation or configuration steps or ‘coded’ display terminology with no information or explanation as to what they mean or what we are expected to do with them, though I fully understand why this happens and have tried to explain the reasons in my reply to Ian.
You have obviously worked out (as did I) that ‘l’ and ‘r’ in the Status Column indicate whether the traffic is being received by the ‘local’ receiver or ‘relayed’ from another nearby station via the GRID network respectively and whilst I don’t know the definitive answer, I would suspect that ‘a’ versus ‘A’ may be to differentiate between DF-17 (true ADSB) and DF-18 (CAP 1391) signals, though I could be WAY off the mark here. Hopefully Lee will confirm or advise otherwise.
Good idea about a separate column to indicate the receiving station for ‘r’ signals BTW.
We are as a group definitely NOT against change - where this represents improvement. This is in fact the ethos of PilotAware. Where necessary or desirable, change can be implemented extremely quickly. We are just against over-complicating the system and introducing unnecessary options which can lead to confusion and mistakes - especially for ‘non-technical’ users. To this end ALL suggestions are considered. It’s just that with such a small team and so much happening at pace, improvements have to be prioritised and fixes and development can quickly outstrip the team’s ability to keep the paperwork ‘up to the minute’. We need to work harder on this.
Hopefully Lee will come back with definitive answers if I have got any of this wrong.
Best Regards
Peter
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version