PilotAware
British Forum => OGN-R PilotAware => Topic started by: kevkdg on December 27, 2020, 02:05:56 pm
-
Hi,
PWUKFUF/UKRUF is a new ATOM ground station, previously only an OGN station.
Having a few issues with detecting SDR's as pasted below and being looked into by the PAW Team (Keith/Chris/Lee).
However, are there any useful commands that can be run without the need to run config every time. For example to reboot the Pi, check the SDR status's?
Regards
Kevin
Config From 19th Dec (First time running after setting up ground station hardware and interestingly the FLARM antenna was NOT plugged into USB Bottom Right but into the Top Left):
(15:32:36) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
USB Port Top Left : SDR detected ID=1 currently unallocated
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 OGN/FLARM reception on 868Mhz
One SDR is currently configured for OGN and you have an unallocated SDR which could be used for ADS-B reception.
Config From 20th Dec (Picked up both dongles and assigned correct ID’s as per the Instruction Manual – ID=1 to OGN/FLARM and ID=0 to ADSB AFTER initially complaining of conflicting SDR serial numbers and following a couple of reboots):
(19:47:31) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
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.
No tinkering post the above config.... until today (27th) as noticed FLARM was not working:
Config Attempt 1 (27th Dec following FLARM dropout) – Issue appears to be the same serial numbers allocated to both SDR’s – How can this happen given nobody has done anything on the Pi since the above config run on 20th?:
(11:40:57) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
WARNING: Either an SDR has no serial number or two or more SDR's have identical serial numbers.
The configuration can only continue once all SDR's have unique serial numbers assighned.
The SDR's will now have their serial numbers changed to randomly assigned values and a reboot will be required.
If any of the SDR's are plugged into a powered USB hub then the hub will also need to be powered down at the same time.
Proceed with updating the serial numbers and reboot [Y/n]: y
SDRs renamed - rebooting in 10 seconds
Please rerun config afterwards
Config Attempt 2 (Following Re-Boot) Picked up ADSB/1090 in correct USB Port:
(11:45:53) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : no SDR detected
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
SDR's serial changed to 868
Do you want to set a Password (recommended first time) [y/N]:
Config Attempt 3 (Now only picks up FLARM in correct USB Port but is assigning ID=0 which was the ADSB assigned number) - Not sure why ADSB/1090 SDR is no longer being detected as it was only a few minutes ago:
(11:47:12) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : SDR detected ID=0 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: no SDR detected
Config Attempt 4:
(11:48:16) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : SDR detected ID=0 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: no SDR detected
-
The important thing is NOT to mess with the software on it...
The only command I can suggest is lsusb. All it does is ask the question, what's happening in USB land on this Pi?
pi@ognpaw:~ $ lsusb
Bus 001 Device 006: ID 1a2c:2124 China Resource Semico Co., Ltd
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@ognpaw:~ $
Here you can see the question has been asked and the Pi says there are two SDRs connected, and gives the device ID and the manufacturer.
There is also a keyboard connected, as I am a terminal based dinosaur.
If this list only gave you one SDR, then you know there is an issue.
My suggestion, not endorsed by PilotAware - I used short USB extension leads so the weight and bending action of the heavy SDR would not damage the motherboard. If the USB connector flexes, this may cause an issue. I could be wrong and clueless though.
-
I ran the lsusb query and then did a sudo reboot and ran config various times, as even when it correctly picked up both SDR's it didn't tune the FLARM, so it looks like it lost it again.
Ended up back where I started with only FLARM up and running, except it seems to one minute locate FLARM SDR in the correct USB socket (Top Left) but then another timein the Bottom Right USB which is where the 1090 antenna SDR is connected. however it seems to tune FLARM OK even when i thinks it is connected to the 1090 USB Port which I don't think it would be able to do using the 1090 antenna!
I am wondering whether it might be a power supply issue??
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
sudo roboot
Now it picks up 2 SDR's:
(18:32:09) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
WARNING: Either an SDR has no serial number or two or more SDR's have identical serial numbers.
The configuration can only continue once all SDR's have unique serial numbers assighned.
The SDR's will now have their serial numbers changed to randomly assigned values and a reboot will be required.
If any of the SDR's are plugged into a powered USB hub then the hub will also need to be powered down at the same time.
Proceed with updating the serial numbers and reboot [Y/n]:
(18:36:08) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
WARNING: Either an SDR has no serial number or two or more SDR's have identical serial numbers.
The configuration can only continue once all SDR's have unique serial numbers assighned.
The SDR's will now have their serial numbers changed to randomly assigned values and a reboot will be required.
If any of the SDR's are plugged into a powered USB hub then the hub will also need to be powered down at the same time.
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Now it has assigned them correctly:
(18:46:20) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
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.
Test tuning however does not pick up the FLARMM
...
Test tuning of rtl-sdr device=1
Testing --ppm=0 --gain=0
Not enough data was collected
Testing --ppm=0 --gain=5
Not enough data was collected
Testing --ppm=0 --gain=10
Testing --ppm=0 --gain=15
Testing --ppm=0 --gain=20
Testing --ppm=0 --gain=25
Testing --ppm=0 --gain=30
Testing --ppm=0 --gain=35
Testing --ppm=0 --gain=40
Testing --ppm=0 --gain=45
Testing --ppm=0 --gain=50
Not a valid number: _UNDEF_ for option ppm
So re-ran config and back to picking up only 1 SDR (ADSB in the correct Bottom Right USB):
Starting Services
(18:48:45) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : no SDR detected
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
SDR's serial changed to 868
So re-ran config again still picking up 1 SDR BUT this time OGN/FLARM in correct Top Left USB and correctly tunes it:
(18:49:55) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : SDR detected ID=0 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: no SDR detected
...
Testing --ppm=-0 --gain=40
Capture @5ppm inrange=43 outrange=0
Frequency Capture Improvement = 42 -> 43
Receiver Xtal correction = 0-0.474 = -0.474 (0.379) ppm [102]
setting APRS_SDR_PPM=-0
setting APRS_SDR_GAIN=40
So, re-ran config again still picking up 1 SDR OGN/FLARM but now thinks it is positioned in the USB in the Bottom Right instead of Top Left but seems to tune it OK (Bottom Right is 1090):
(18:59:00) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : no SDR detected
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 OGN/FLARM reception on 868Mhz
...
Testing --ppm=-0 --gain=40
Capture @5ppm inrange=43 outrange=0
Frequency Capture Improvement = 41 -> 43
Receiver Xtal correction = 0-0.466 = -0.466 (0.369) ppm [102]
setting APRS_SDR_PPM=-0
setting APRS_SDR_GAIN=40
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
-
All I can suggest is that you have intermittent connections to the SDRs, or they are about to croak.
The only thing to double check is that the frequency of the aerial is the correct one in the config program.
You could test the USB sockets by moving to different ones. You need to check the config program has the right SDR + aerial for the socket. If not, the procedure will not receive the signal because of a mismatch, AIUI, between the tuning procedure and the aerial using the wrong aerial to try and tune to a set of frequencies it wasn't designed for.
Check all connections. Check SDR USB into Pi is not strained...
-
Thanks, will check.
-
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
-
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
-
Should it be necessary to reconfigure the station, we can now simply log in to the Pi and type config [enter] at the prompt.
That is not reflected in the current instructions.
-
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
-
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
-
Are you having any more luck with your Pi3 setup yet?
Thanks Peter for the info.
The Pi I was using has a dead Wifi module. I should have known there was a reason it was in a box on the shelf and not in use. Got a feeling it was originally in a PAW, but withdrawn. An own goal ::) New one on order.
-
Thanks Ian for your comments :-)
I agree, if re-running 'config' periodically is now stable (previously if I ran it I would get varying results wrt SDR detection and assignment), then you're right that a separate report is not required. I assume that the GSM tuning process is related to the Flarm, and re-running this via config is not a problem.... having said that, I notice each time it runs, it gives slightly different tuning results, even if run in quick succession.
The reason I wanted to periodically check is due to the recent issues which have now been reported as fixed in the new SW release, but which I wanted to monitor for a while. I believe I was running previously for a period (on previous SW version) where the 1090 RTLSDR was assigned to OGN/FLARM and therefore believe it was affecting (very reduced) the range Flarm signals were being received locally before being relayed from a station much further away. This makes sense as it was using the 1090 antenna which is not tuned for 868.
Incidentally, I noticed that if I only had the 1090 RTLSDR plugged in, config would auto assign it to OGN/FLARM and the option to allowing you to amend this assignment did not appear. Not sure if this is/was another bug, or whether this still is the case in the new SW release. This could affect users only connecting a 1090 antenna, maybe for testing purposes.
With regards to instructions, the "Upgrading an OGN Station" PDF is quite out of date compared to the "Building an ATOM Station". So, either though I was upgrading, I used the latter "Building an ATOM Station" instructions for the software config side of things.
Incidentally, why in Grid view do registrations not always display, yet in radar view they are there for the same aircraft?
-
Hi Again Kevin,
I agree, if re-running 'config' periodically is now stable (previously if I ran it I would get varying results wrt SDR detection and assignment), then you're right that a separate report is not required. I assume that the GSM tuning process is related to the Flarm, and re-running this via config is not a problem.... having said that, I notice each time it runs, it gives slightly different tuning results, even if run in quick succession.
The reason I wanted to periodically check is due to the recent issues which have now been reported as fixed in the new SW release, but which I wanted to monitor for a while. I believe I was running previously for a period (on previous SW version) where the 1090 RTLSDR was assigned to OGN/FLARM and therefore believe it was affecting (very reduced) the range Flarm signals were being received locally before being relayed from a station much further away. This makes sense as it was using the 1090 antenna which is not tuned for 868.
All understood. Thanks for the clarification.
Incidentally, I noticed that if I only had the 1090 RTLSDR plugged in, config would auto assign it to OGN/FLARM and the option to allowing you to amend this assignment did not appear. Not sure if this is/was another bug, or whether this still is the case in the new SW release. This could affect users only connecting a 1090 antenna, maybe for testing purposes.
The software is deliberately configured to automatically configure the 1st (or only) SDR for Flarm Reception - as collecting and rebroadcasting Flarm Positions was the primary reason for extending OGN to OGN-R and Flarm Reception is technically more complicated (see below). In the early days OGN-R didn't do MLAT or data uplinks. 1090 MLAT and data uplinks are a much later addition, so setup of 1090 only takes place where a second SDR is fitted.
With regards to instructions, the "Upgrading an OGN Station" PDF is quite out of date compared to the "Building an ATOM Station". So, either though I was upgrading, I used the latter "Building an ATOM Station" instructions for the software config side of things.
OK on this - I agree the content of these documents does need to be looked at again and any anomalies or inconsistencies addressed.
Incidentally, why in Grid view do registrations not always display, yet in radar view they are there for the same aircraft?
Not sure, I'd need to check with Lee.
I assume that the GSM tuning process is related to the Flarm, and re-running this via config is not a problem.... having said that, I notice each time it runs, it gives slightly different tuning results, even if run in quick succession.
Correct. The GSM Scan is designed to check for frequency offset in the Flarm Receive SDR and set an accurate centre frequency. This is very important as Flarm actually 'frequency hops' between two frequencies spaced slightly apart and also runs at very low power. 'Cheaper' dongles can have a fair degree of inaccuracy and frequency drift, so determining the offset and setting the centre frequency accurately for each specific dongle is extremely important. The GSM scan process tests to determine the frequency offset of your specific dongle by using nearby GSM signals - which is why the results can vary from test to test, though usually within acceptable limits. (It's not so much what it is reporting but what the software then does with this information that counts). In point of fact, Frequency Offset is usually very near zero when we use SDRs with Temperature Controlled Crystal Oscillators (TCXO) like the ones you will have been supplied with if you got them from Keith - but the GSM Scan is still the best way to ensure an effective setup and also allows us to determine the optimum gain setting for the SDR. It isn't needed (or done) for the 1090 MHz Rx SDR (much broader bandwidth and higher power signals) and the P3i frequency is set by the Bridge.
Hope this helps clarify things a bit further.
Best Regards
Peter
-
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.
Without wanting to make myself unpopular or upset anyone, with software it makes sense for the auditing process to help users.
There is a reason why software gets revised, and it should be in the revision notes. Whilst I'm not suggesting that a release that fixes a problem should be delayed for the instructions to be updated, it's about an hour a month for a volunteer to just look through and update the instructions, get them proof read then issue a PDF with a revision version attached to it.
If we keep the instructions up to date (or close to it) then it might lead to less support queries on the forum.
Even if you have a Google or Dropbox document that one liners get dropped whilst development is going and when problems are solved, it's something to beat into a form to update the instructions with. Otherwise, there may be a risk of frustration on the part of those who follow the instructions, and don't know to come here when stuck. They then provide anonymous accounts of how things don't work elsewhere...
-
Hi Peter,
Regarding my earlier point:
Incidentally, why in Grid view do registrations not always display, yet in radar view they are there for the same aircraft?
When I say radar view, I meant the OGN fed www.gliderradar.com radar. This is now fed by our ATOM station and displayed the aircraft registrations for the OGN traffic being received locally by UKRUF, yet the UKRUF Grid and UKRUF VRS did NOT display the registrations for 2 of the Flarm gliders but incidentally did for the Flarm equipped tug (G-OYGC which only has Flarm, no Mode S or ADSB). I wonder if they resolve the Hex/ICAO Id for the aircraft against their own local database for the reg? Please see the attached screenshots:
Keith supplied us with one RTLSDR which we are using for the 1090 antenna. We already had a FLARM antenna and RTLSDR which we used to feed the OGN network for a couple of years before upgrading (the RTLSDR is housed directly beneath the Flarm Antenna in a weatherproof box and a 4m to 5m USB cable runs externally to the Raspberry Pi which is housed inside). These are the figures we're getting post the GSM tuning process (I've no idea what each one means or whether it is good or bad):
Station SDR PPM is : 67
Station SDR Gain is : 40
Station SDR Freq Centr is : 922.800
Both RTLSDR USB's appear to be listed as the same type:
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Finally, as you can see from the attachments, this morning we had some local Flarm signals picked up from 3 aircraft, yet the UKRUF Flarm report is not reflecting these in the "over last 12 hours"
Traffic rates [visible/all]
Aircrafts received over last 12 hours 0/0
Kind Regards
Kevin
-
Hi Kevin,
That’s a similar setup to the one I have used for EastFortune, with the Flarm dongle (in our case an NooElec NESDRSmart TCXO one) mounted at the antenna and fed by USB from the main unit inside the hangar with the P3i Bridge and 1090 dongle.
There is nothing surprising in the GSM Scan results - they look pretty normal for ‘non TCXO’ dongles (both reporting as Realtek RTL2838 DVB-T, this is normal, though they may look different physically).
Re the lack of aircraft Reg details, the standard PilotAware software determines the aircraft Reg from a database of ICAO Hex ID’s. I’m pretty sure it doesn’t include a copy of the Flarm ID database, which would explain why the ATOM firmware also can’t translate Flarm (DD) Codes into Registrations for the Status Page. Have you checked how they display on the built in VRS?
Regards
Peter
-
Thanks Peter,
Both RTLSDR USB dongles are showing when I run "lsusb". I noticed Flarm traffic being picked up from Rufforth Gliding activity yesterday morning (Sun 3rd Jan) before I went out at midday.
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
With reference to FLARM:
When I looked at ...PWUKRUF/flarm on Sun 3rd around 4pm, it showed:
Traffic rates [visible/all]
Aircrafts received over last 12 hours 0/0
Which was surprising given the OGN contacts on the morning of Sun 3rd. Of which the screenshot attached shows in Grid view.
Now it seems PWUKRUF is showing as Red (Down New Stations) on the following page, even though the website reports that it is still detecting a heartbeat (nearby glidign sites PWSuttonB and PWUKPOC are green, and we PWUKRUF have been green previously):
https://ognrange.glidernet.org/?#PWUKRUF,max,lastweek,53.94300_-1.18870,9,#000000ff:#000000ff,
UKRUF is showing offline here (Down since Sun 3rd Jan at 13:04), previously this was green.
http://wiki.glidernet.org/list-of-receivers#toc37
Last time this happened (PW)UKRUF stopped picking up FLARM, but this was due to the RTLSDR issue (I think) which should now have been fixed. However, it doesn't look promising.
With reference to 1090:
We are still looking good here:
https://radar.lowflyingwales.co.uk/pilotaware-contributors/
I guess we will need to wait until they're gliding again to see if the FLARM side has gone off line. But I suspect it has! I shall avoid re-running 'config' as that will stop and restart services and probably start it all working again, but what I need to ascertain is if it truly has gone off on the FLARM side. But how to do this and ascertain the reason why???
-
Glidertracker and Gliderradar both seem to think the FLARM/OGN side is down but the PAW side is up.
-
That confirms my findings. What did you look at on those websites to determine this please?
Anyway to find out why the Flarm side might be down if both RTLSDR USB Dongles are still being detected by the Pi. Is there any log file?
-
That confirms my findings. What did you look at on those websites to determine this please?
http://www.glidertracker.org (http://www.glidertracker.org)
Check RX is ticked in Menu drop down box extreme top LHS.
Click on mast icon to get PAW or OGN version of ground station.One is in yellow writing, one in red.
https://www.gliderradar.com/center/53.91041,-1.06705/zoom/10/time/15 (https://www.gliderradar.com/center/53.91041,-1.06705/zoom/10/time/15)
Clicking the diamond should show two versions of the ground station, one is OGN, one is PAW. Clicking the RUF one now seems to offer OGN...
Anyway to find out why the Flarm side might be down if both RTLSDR USB Dongles are still being detected by the Pi. Is there any log file?
Not sure but if you look at the FLARM status, what do you get?
I get this from the remote console:
RTLSDR OGN demodulator and decoder 0.2.8.ARM/Aug 28 2020
System
Host name ognpaw
Configuration file path+name /home/pi/rtlsdr-ogn-0.2.8/rtlsdr-ogn-paw.conf
Local time 10:47:02
Software RTLSDR-OGN 0.2.8.ARM
CPU load 3.1/3.3/3.6
RAM [free/total] 571.9/972.4 MB
CPU temperature +42.2 ℃
NTP UTC time 10:47:02
NTP est. error 1.0 ms
NTP freq. corr. -1.77 ppm
Position
Position.Latitude +51.19039 deg
Position.Longitude +000.68659 deg
Position.Altitude 51 m
Position.GeoidSepar +46 m
RF
RF.FreqPlan 1: EU/Africa
RF input noise -1.1 dB
Demodulator
Demodulator.DetectSNR 12.0 dB
Demodulator.PipeName localhost:50010
Demodulator.ScanMargin 20.0 kHz
Traffic rates [visible/all]
Aircrafts received over last 12 hours 0/ 0
Aircrafts received over last hour 0/ 0
Aircrafts received over last minute 0/ 0
Positions received over last minute 0/ 0
AntennaPattern ranges 0 0 0 0 0 0 0 0 0 0
This implies the FLARM subroutine is running. I may be wrong.
-
Hi Kev/Steve,
Sorry, missed all the above - I have been checking PWUKRUF via the various sites.
Got a print from Chris Gilbert clearly showing activity yesterday on all modes, but as reported the OGN and OGN supported sites (Spot-the-Gliders, Glidertracker and GliderRadar) all think the OGN side UKRUF has been down since yesterday at 13.04z. I wouldn’t read too much into the balloon colour on OGNRange, they tend to go red for all sorts of reasons - perhaps including time since last received traffic.
More importantly, I have just looked at the PWUKRUF Status via the data.pilotaware site (I have admin access to the network). You should also have received a link via e-mail giving you access to your own site Kev. If you login to it and look at the Flarm Status Screen via the Status Tab, the usual reference to the APRS Beacon and APRS Server links to the OGN Servers which should be showing at the bottom of the PWUKRUF Flarm Status Page are missing - the implication being that there is no link between your site and the OGN servers.
You said earlier that ‘ gliderradar is now fed by our ATOM station’, do you mean via the OGN feed or have you installed software to create a direct feed to gliderradar? If so, that could be the problem.
Regards
Peter
-
I've made no changes to Pi ATOM software not have I introduced any other software.
Monday 4th January Part 1 (due to max post length)
Yep, FLARM will be running now as I have just gone through the following processes, which to me either indicate potential software issues still OR maybe there is an issue with our FLARM RTLSDR and/or USB Lead running from just below the antenna in a weatherproof box for about 4 or 5 metres to the Raspberry Pi. However, this was running previously fine in this configuration when it was just an OGN Station.
Any thoughts? I am getting desperate!!
Due to obvious UKRUF FLARM issues I ran lsusb:
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Looks OK, so I decided to run "config" to check on the allocations etc
(10:36:28) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
It Hung, so had to "CTL-C" to cancel
Service then restarted automatically as reported on screen.
"lsusb" now only shows one SDR as follows:
(10:37:37) FILESYS : Mount RO
~
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@ognpaw:~ $
So, looks like the following (OGN/FLARM RTLSDR USB) has been lost:
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Re-ran "Config":
(10:39:19) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : no SDR detected
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
SDR's serial changed to 868
...
Test tuning of rtl-sdr device=
Testing --ppm=0 --gain=0
Testing --ppm=0 --gain=5
...
Testing --ppm=0 --gain=50
Not a valid number: --ppm for option device
########################## Summary ##########################
Station Name is : UKRUF
Station APRS Server is : aprs.glidernet.org:14580
Station Latitude is : 53.943130
Station Longitude is : -1.188770
Station Altitude AMSL [M] is : 24
Station Altitude GEOID [M] is : 49
Station SDR PPM is : _UNDEF_
Station SDR Gain is : _UNDEF_
Station SDR Freq Centr is : 923.4
########################## Summary ##########################
Starting Services
Does this mean it is re-assigning my 1090 RTLSDR to OGN/FLARM allocation as it's changing the serial to 868? I assume so as the default position is that there is always a FLARM SDR!
I Issued a "sudo reboot" and waited for it to come back online
Logged in and issued "lsusb" Now all RTLSDR's are again detected:
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@ognpaw:~ $
Re-ran config:
(10:47:52) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
WARNING: Either an SDR has no serial number or two or more SDR's have identical serial numbers.
The configuration can only continue once all SDR's have unique serial numbers assighned.
The SDR's will now have their serial numbers changed to randomly assigned values and a reboot will be required.
If any of the SDR's are plugged into a powered USB hub then the hub will also need to be powered down at the same time.
Proceed with updating the serial numbers and reboot [Y/n]: Y
SDRs renamed, you should reboot now
Please rerun config afterwards
Do you want Reboot now [Y/n]: Y
I suspect this is because just before when only the one RTLSDR (1090) was detected, it changed its serial number to 868, so when the other (FLARM) RTLSDR was redetected following the "sudo reboot" it too would still have retained a serial number of 868, hence the clash.
To be continued
-
Monday 4th January Part 2 (due to max post length)
Re-ran "config"
(10:52:37) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
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 unallocated
One SDR is currently configured for OGN and you have an unallocated SDR which could be used for ADS-B reception.
Do you wish to change the SDR(s) configuration [y/N]: y
Which dongle do you want to use for OGN reception on 868Mhz? Enter it's ID, highlighted in yellow above: 1
Writing serial number 868 to dongle ID: 1
Which dongle do you want to use for ADS-B reception on 1090Mhz? Enter it's ID, highlighted in yellow above: 0
Writing serial number 1090 to dongle ID: 0
...
Test tuning of rtl-sdr device=1
...
Testing --ppm=70 --gain=35
Capture @5ppm inrange=43 outrange=1
Frequency Capture Improvement = 32 -> 43
Receiver Xtal correction = 70+0.262 = +70.262 (0.238) ppm [141]
setting APRS_SDR_PPM=70
setting APRS_SDR_GAIN=35
...
Found Rafael Micro R820T tuner
Exact sample rate is: 2000000.052982 Hz
Frequency = 920.000MHz..960.200MHz 2.000MHz step, 20 scans
Sampling rate = 2000000Hz = 2.000MHz
0.250sec per scan
FFT: 1024 bins, 1953.1Hz/bin, 0.256ms/slide
RTLSDR::Open(1,940100000,2000000) => Generic RTL2832U OEM, 940.100 MHz, 2.000 Msps
RTLSDR::Gain[29] = +0.0 +0.9 +1.4 +2.7 +3.7 +7.7 +8.7 +12.5 +14.4 +15.7 +16.6 +19.7 +20.7 +22.9 +25.4 +28.0 +29.7 +32.8 +33.8 +36.4 +37.2 +38.6 +40.2 +42.1 +43.4 +43.9 +44.5 +48.0 +49.6 [dB]
Open(1, 940100000, 2000000) OK
Tuner crystal correction set to 70 ppm
Tuner gain set to 35.0 dB (device reports 33.8 dB)
...
Receiver Xtal correction = 70-0.633 = +69.367 (0.238) ppm [144]
Note: when the receiver warms up the Xtal may drift 5-10ppm
########################## Summary ##########################
Station Name is : UKRUF
Station APRS Server is : aprs.glidernet.org:14580
Station Latitude is : 53.943130
Station Longitude is : -1.188770
Station Altitude AMSL [M] is : 24
Station Altitude GEOID [M] is : 49
Station SDR PPM is : 70
Station SDR Gain is : 35
Station SDR Freq Centr is : 941.000
########################## Summary ##########################
Starting Services
Re-ran config purely to double check the RTLUSB allocation looked OK BUT got this:
(10:57:15) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
WARNING: device 0 with serial number: 1090 cannot be found in dmesg log
Most likely the serial number has been altered and the Pi not rebooted before running this script.
Reboot required
If any of the SDR's are lugged into a powered USB hub then the hub will also need to be powered down at the same time.
Please rerun config afterwards
Do you want Reboot now [Y/n]: Y
To be cont
-
Monday 4th January Part 3 (due to max post length)
After reboot I Logged back in and ran lsusb:
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@ognpaw:~ $ config
Still got both RTLSDRs showing so ran config:
(11:01:03) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
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.
Do you wish to change the SDR(s) configuration [y/N]: N
Test tuning of rtl-sdr device=1
...
Testing --ppm=68 --gain=45
Capture @5ppm inrange=44 outrange=0
Frequency Capture Improvement = 42 -> 44
Receiver Xtal correction = 68-0.292 = +67.708 (0.225) ppm [151]
setting APRS_SDR_PPM=68
setting APRS_SDR_GAIN=45
...
Found Rafael Micro R820T tuner
Exact sample rate is: 2000000.052982 Hz
Frequency = 920.000MHz..960.200MHz 2.000MHz step, 20 scans
Sampling rate = 2000000Hz = 2.000MHz
0.250sec per scan
FFT: 1024 bins, 1953.1Hz/bin, 0.256ms/slide
RTLSDR::Open(1,940100000,2000000) => Generic RTL2832U OEM, 940.100 MHz, 2.000 Msps
RTLSDR::Gain[29] = +0.0 +0.9 +1.4 +2.7 +3.7 +7.7 +8.7 +12.5 +14.4 +15.7 +16.6 +19.7 +20.7 +22.9 +25.4 +28.0 +29.7 +32.8 +33.8 +36.4 +37.2 +38.6 +40.2 +42.1 +43.4 +43.9 +44.5 +48.0 +49.6 [dB]
Open(1, 940100000, 2000000) OK
Tuner crystal correction set to 68 ppm
Tuner gain set to 45.0 dB (device reports 44.5 dB)
...
Receiver Xtal correction = 68-0.531 = +67.469 (0.198) ppm [150]
Note: when the receiver warms up the Xtal may drift 5-10ppm
########################## Summary ##########################
Station Name is : UKRUF
Station APRS Server is : aprs.glidernet.org:14580
Station Latitude is : 53.943130
Station Longitude is : -1.188770
Station Altitude AMSL [M] is : 24
Station Altitude GEOID [M] is : 49
Station SDR PPM is : 68
Station SDR Gain is : 45
Station SDR Freq Centr is : 923.800
########################## Summary ##########################
Starting Services
Now to double check (again), ran "config" and "CTL-C" to cancel and restart services
(11:04:19) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
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.
Do you wish to change the SDR(s) configuration [y/N]: ^CStarting Services
All looked OK.
-
Kevin,
Nothing obvious in any of that to indicate why it keeps ‘losing’ SDRs - as you say, the Flarm one could be faulty, or perhaps moisture has got in somewhere - or there could be a hardware fault on the Pi.
I have just rechecked your Flarm Status page and there are still no APRS Beacon or APRS Status reports at the bottom of the page - so still no link to the OGN servers. I’ll check again in case there is just a delay, but I suspect NOT. There is plenty of 1090 traffic (both ADSB and MLAT) showing on your ATOM Status page and on your VRS Radar Screen, but probably no PAW or Flarm about locally.
Still waiting for a reply as to whether you have additional software running on the Pi to supply feeds to other websites. Edit: missed your reply right at the top of recent post - my apologies!
Also meant to say, that the config protocol is correct - if it only finds one SDR it will automatically suggest setting it up for OGN (ensuring rebroadcast of Flarm is higher priority than MLAT, which will still be received by local PilotAwares as ‘Bearingless’ Traffic - Flarm Traffic just won’t be seen!)
Regards
Peter
p.s. I will ask Lee & Chris to take a look and see if they can determine why it’s not establishing the link to the OGN servers.
-
Hi Kevin, Peter
It looks like a hardware fault, running dmesg shows the following errors, by the way 1-1.2 is USB: Top-Left
[Mon Jan 4 12:33:14 2021] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg
[Mon Jan 4 12:33:19 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:33:35 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:33:35 2021] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg
[Mon Jan 4 12:33:40 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:33:56 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:33:56 2021] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg
[Mon Jan 4 12:34:06 2021] usb 1-1.2: device not accepting address 4, error -110
[Mon Jan 4 12:34:06 2021] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg
[Mon Jan 4 12:34:17 2021] usb 1-1.2: device not accepting address 4, error -110
[Mon Jan 4 12:34:17 2021] usb 1-1.2: USB disconnect, device number 4
[Mon Jan 4 12:34:17 2021] usb 1-1.2: new high-speed USB device number 6 using dwc_otg
[Mon Jan 4 12:34:22 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:34:38 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:34:38 2021] usb 1-1.2: new high-speed USB device number 7 using dwc_otg
[Mon Jan 4 12:34:43 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:34:58 2021] usb 1-1.2: device descriptor read/64, error -110
[Mon Jan 4 12:34:58 2021] usb 1-1.2: new high-speed USB device number 8 using dwc_otg
[Mon Jan 4 12:35:09 2021] usb 1-1.2: device not accepting address 8, error -110
[Mon Jan 4 12:35:09 2021] usb 1-1.2: new high-speed USB device number 9 using dwc_otg
[Mon Jan 4 12:35:20 2021] usb 1-1.2: device not accepting address 9, error -110
[Mon Jan 4 12:35:20 2021] usb 1-1-port2: unable to enumerate USB device
thx
Lee
-
Thanks guys
However looking at the following sites which I believe are fed by the OGN network, it does or at least did for a time come back online:
http://wiki.glidernet.org/list-of-receivers#toc37 - Did say Down Since 03/01/2021 13:04 now says Down Since 04/01/2021 11:12 implying that it cam back following my reboot and config attempts this morning, albeit maybe it only came back briefly!
https://ognrange.glidernet.org/?#PWUKRUF,max,today,53.94300_-1.18870,10,#80000040:#008000ff,circles; - This was showing red (albeit with a current heartbeat), but now shows green.
https://www.gliderradar.com/details/activity/sid/755406 - This shows it coming back online under the activity tab.
And on the OGN Viewer App on my phone, when it was down it only showed PWUKRUF, it then came back showing both PWUKRUF and UKRUF.
However, thought I'd check config again,
Just ran lsusb and looked ok still:
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Then ran config and it hung (as before) so CTRL-C'd out of it.:
(12:33:06) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 2 SDR's:
^CStarting Services
then run lsusb again, Device 004 is now showing as Device 000??
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 000: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Ran config again (no reboot) and CTRL-C'd out... SDR is detected in BOTTOM RIGHT PORT
(12:36:16) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : no SDR detected
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
SDR's serial changed to 868
Do you want to change the ADSB Antenna Gain value () [y/N]: ^CStarting Services
Now lsusb has completely lost the FLARM(?) RTLSDR.
pi@ognpaw:~ $ lsusb
Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
1090 RTLSDR and antenna have been auto re-allocated to 868 FLARM(?)
I ran the following which shows 1090 is not working now. As expected if the 1090 has been re-allocated to FLARM.
pi@ognpaw:~ $ nc localhost 30003
pi@ognpaw:~ $
Ran config again (no reboot). SDR is detected in TOP LEFT PORT... very strange
(12:42:00) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before running this configuration script.
Found 1 SDR:
USB Port Top Left : SDR detected ID=0 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: no SDR detected
...
Testing --ppm=-0 --gain=40
Capture @5ppm inrange=42 outrange=0
Frequency Capture Improvement = 39 -> 42
Receiver Xtal correction = 0-0.420 = -0.420 (0.355) ppm [104]
setting APRS_SDR_PPM=-0
setting APRS_SDR_GAIN=40
...
Found Rafael Micro R820T tuner
Exact sample rate is: 2000000.052982 Hz
Frequency = 920.000MHz..960.200MHz 2.000MHz step, 20 scans
Sampling rate = 2000000Hz = 2.000MHz
0.250sec per scan
FFT: 1024 bins, 1953.1Hz/bin, 0.256ms/slide
RTLSDR::Open(0,940100000,2000000) => Generic RTL2832U OEM, 940.100 MHz, 2.000 Msps
RTLSDR::Gain[29] = +0.0 +0.9 +1.4 +2.7 +3.7 +7.7 +8.7 +12.5 +14.4 +15.7 +16.6 +19.7 +20.7 +22.9 +25.4 +28.0 +29.7 +32.8 +33.8 +36.4 +37.2 +38.6 +40.2 +42.1 +43.4 +43.9 +44.5 +48.0 +49.6 [dB]
Open(0, 940100000, 2000000) OK
Tuner crystal correction set to 0 ppm
Tuner gain set to 40.0 dB (device reports 40.2 dB)
...
Receiver Xtal correction = 0-0.371 = -0.371 (0.332) ppm [100]
Warning: measurements appear inconsistent:
please retry with better initial estimate or with lower gain to reduce distortions
Note: when the receiver warms up the Xtal may drift 5-10ppm
########################## Summary ##########################
Station Name is : UKRUF
Station APRS Server is : aprs.glidernet.org:14580
Station Latitude is : 53.943130
Station Longitude is : -1.188770
Station Altitude AMSL [M] is : 24
Station Altitude GEOID [M] is : 49
Station SDR PPM is : -0
Station SDR Gain is : 40
Station SDR Freq Centr is : 921.200
########################## Summary ##########################
Starting Services
The above warning is typical when it runs FLARM through the 1090 SDR, however, it reported the SDR in TOP LEFT USB PORT (which is defo the FLARM port), but immediately previous config run (no reboots) detected it in the BOTTOM RIGHT which is where the 1090 is plugged in... so again strange things going on!
-
Hi,
Should we purchase a new RTLSDR for the FLARM? Or could it be the USB lead?
Any ideas why it detected the working RTLSDR (1090) on Bottom Right then straight after on Top Left USB Port?
Kevin
Hi Kevin, Peter
It looks like a hardware fault, running dmesg shows the following errors, by the way 1-1.2 is USB: Top-Left
thx
Lee
-
Should we purchase a new RTLSDR for the FLARM? Or could it be the USB lead?
aaah, maybe I overlooked some crucial information ?
Are you saying the SDR is on the end of a USB lead ?
It is very possible you are seeing a voltage drop across that lead, causing the SDR to fail
how long is this lead ?
do you know what wire gauge (for the power) is on this lead ?
are you using a powered hub to drive this SDR over the lead, or is this connected straight into the PI ?
Thx
Lee
-
Hi Lee,
I did wonder, the USB Lead has got to be 5 metres long I would estimate.
I do not know the AWG but do know it is not very thick as this did concern me.
No power hub is being used.
However, this was the pre-existing OGN Station setup, as we upgraded this to ATOM, so left in place the existing FLARM antenna, with the weatherproof box immediately below it that houses the FLARM RTLSDR. It seemed to work fine when it was just an OGN station.
I am thinking in terms of options:
1. Purchase HDF400 co-ax cable and connectors PLUS required adaptors, new Temperature Controlled Crystal Oscillators (TCXO) RTLSDR and house the FLARM SDR in the Pi which is inside the clubhouse. (Same concept as the new 1090 antenna and SDR). Our existing FLARM antenna does not have the larger N type connector at the base, but rather some smaller type of connector (SMA perhaps?). I know the more connectors/adaptors you have the greater the signal loss. Keith has sent me prices.
2. Try a new, lower rated AWG USB lead with existing RTLSDR (the lower the AWG number the better right?)
3. Try a new, lower rated AWG USB lead and new RTLSDR.
4. Just replace the Flarm RTLSDR with existing USB Lead.
-
Lee,
Kevin did say a few posts back that his Flarm dongle is in a waterproof box at the antenna on a 4 to 5m USB lead (so probably not powered) - this is effectively the same as I have run without any issues at East Fortune since Day 1 (though different SDRs). That doesn’t of course mean there can’t be a problem.
Kevin,
I have just come off a long phone call with Chris, who is responsible for the PilotAware GRID Network. He confirms that both your SDRs are running and sending Flarm and 1090 data to the network when traffic is available and that this is being rebroadcast via the PilotAware side so you can set your mind at rest on that score - (http://[u]your ATOM station is working properly[/u]).
When Chris phoned, I was actually in the process of checking the OGN Glidern3 server and saw UKRUF connected for at least 53 seconds, then it disappeared again - but this isn’t uncommon when local traffic levels are low.
That said, it would do no harm to try a new good quality SDR / cable or resite the dongle inside on decent coax.
From what I’ve seen yesterday and today, it would seem that your lack of reporting on the OGN sites is due to some sort of connectivity issue between your station and the OGN servers, Chris has said he will discuss this with Lee and if necessary they can raise this with the OGN developers, who we have found in the past to be very helpful.
Regards
Peter
-
Thanks Lee, Peter and Steve,
By the way, FLARM OGN is now up and running via the 1090 Antenna and SDR (it's only detecting 1 SDR at mo). I can see the following at the bottom of the FLARM tab for UKRUF. Maybe the FLARM tab beacon and status drop off when the FLARM SDR drops off?
I'll leave it like this until we resolve the real FLARM antenna SDR issue.
APRS beacon:
UKRUF>OGNSDR:/134109h5356.58NI00111.32W&/A=000079
APRS status:
UKRUF>OGNSDR:>134328h v0.2.8.ARM CPU:0.6 RAM:684.9/968.2MB NTP:0.0ms/-0.0ppm +39.7C 0/0Acfts[1h] RF:+0-1.0ppm/-0.90dB
-
Hi Kevin. Peter,
The problem is that the performance is intermittent.
please refer to the post I made containing the kernel log message from dmesg
this shows a definite issue when trying to make a USB transfer, this is why the SDR keeps disappearing when typing "lsusb"
This could be due to either one of the following
1. Voltage drop over the long USB cable
2. Signal integrity issue over the long USB cable.
Long USB cables are renowned to suffer from these issues.
The best solution we have found, is to have a run of good quality lo-loss coax, rather than an extended USB cable
Thx
Lee
-
Lee,
Could the fact that the software seems to be reporting the SDRs from different USB ports each time Kevin tries to run the config not be indicative of a fault in the Pi motherboard itself?
Just a thought - possibly wrong!
Peter
-
Are you saying the SDR is on the end of a USB lead ?
It is very possible you are seeing a voltage drop across that lead, causing the SDR to fail
how long is this lead ?
do you know what wire gauge (for the power) is on this lead ?
are you using a powered hub to drive this SDR over the lead, or is this connected straight into the PI ?
I have had this experience with USB and lead length, but just not on a PAW. It was with a USB scanner, but lead length was critical.
The issue is, and the fault is intermittent because the leads and the SDRs warm up/cool down and the voltage is right on the edge.
I'll guess that the highest quality, thickest cable available over the length required will sort the problem, and will be cheaper than a new SDR.
My USB extensions are the thickest, shortest cable I could find. They are only there to avoid damage to the motherboard.
May I make a suggestion with regard to USB power?
This:
https://www.ebay.co.uk/itm/Digital-Voltmeter-Ammeter-USB-Voltage-Current-Meter-Power-Capacity-Tester/184574423883 (https://www.ebay.co.uk/itm/Digital-Voltmeter-Ammeter-USB-Voltage-Current-Meter-Power-Capacity-Tester/184574423883)
or this:
https://www.ebay.co.uk/itm/LCD-USB-Digital-Current-Voltage-Tester-Voltmeter-Ammeter-Power-Capacity-Meter-UK/264906196333 (https://www.ebay.co.uk/itm/LCD-USB-Digital-Current-Voltage-Tester-Voltmeter-Ammeter-Power-Capacity-Meter-UK/264906196333)
can be plugged in line at the end of the USB extension cable, before the SDR.
They will measure the voltage AT THE END of the cable run with the SDR plugged into the other side of it, effectively in line so you will get current AND voltage measurements. The second link is the best one.
I use these all the time to check everything from how good a charger is to if a USB port is dead, alive or low voltage. Got about 4 of them in various bags for various jobs.
A fiver. Amazing. One of those and a new USB lead will be less than a new SDR and less hassle than a re-cable, and if it fails, then new low loss coax for the whole route is the way to go.
-
Just to re-iterate
the issue could be voltage and/or signal integrity
this is a long stretch to have the very high speed signal not degrade as well as the power.
thx
Lee
-
Just to re-iterate
the issue could be voltage and/or signal integrity
this is a long stretch to have the very high speed signal not degrade as well as the power.
thx
Lee
Agreed, this allows us to eliminate, if the power drawn doesn't drop the voltage to an unacceptable level, then the fault lies with the signal. It allows us to see the voltage at the far end and have a clearer picture. We may have two faults.
I'd be very interested to know what the serial data rate is on the USB cable, but I assume this needs to remain confidential. I'm led to believe that it could be anything from 19200 to 115200 baud in the public documents for FLARM?
-
Hi Steve
I think you may be getting confused between USB and RS232 speeds.
The Speed of USB 2.0 is 480 MB/s - this is completely unrelated to FLARM RS232 data rates.
At 480 MB/s, signal integrity is critical. There are USB repeater cables available which are supposed to overcome this.
I think the best results we have are when the SDR is close to the Pi, and good quality low loss coax is used to the antenna
Thx
Lee
-
Hi Lee,
You asked previously about the USB cable. I checked today. Printed on it is:
High Speed Cable 2.0 Revision 28AWG/1P+28AWG/2C
AWM 2725
80 degrees Celsius
30V
Copartner.
Must be 4 to 5 metres in length.
Kevin
-
Must be 4 to 5 metres in length.
Lee gave me some superb off line help yesterday, not 100% PAW, but during the connected research I was doing I found out that 5m/16ft is the maximum length for USB 2.0 cables.
Citation:
http://www.yourcablestore.com/USB-Cable-Length-Limitations-And-How-To-Break-Them_ep_42-1.html (http://www.yourcablestore.com/USB-Cable-Length-Limitations-And-How-To-Break-Them_ep_42-1.html)
So everything has to be in tip-top condition for the 480Mbps data transfer to work.
-
Hi Lee,
You asked previously about the USB cable. I checked today. Printed on it is:
High Speed Cable 2.0 Revision 28AWG/1P+28AWG/2C
AWM 2725
80 degrees Celsius
30V
Copartner.
Must be 4 to 5 metres in length.
Kevin
Hi Kevin
Thanks, 28AWG is pretty bad I have to say. We use 20AWG for PilotAware power cables
the lower the number - the thicker the cable
20AWG = 0.8118mm
28AWG = 0.3211mm
https://www.rapidtables.com/calc/wire/awg-to-mm.html
Assuming the SDR is not suffering a HW fault (test by plugging directly to PI)
Then the way to go is placing the SDR locally, and running good quality (LMR400 ?) coax to the Antenna
thx
Lee
-
Hello,
Just to update, the UKRUF FLARM antenna is now connected using about 4 to 4.5 metres of HDF400 co-axial cable instead of the likely problematic USB extension cable.
A new FLARM RTLSDR USB card was supplied by Keith and is now in use plugged directly into the Raspberry Pi Top Left USB Port.
Ran the config yesterday, looked OK but was seeing a couple of messages as per below:
"WARNING: device 0 with serial number: 1090 cannot be found in dmesg log"
So today I performed a sudo reboot on the pi remotely then got this when I ran config again:
(15:53:52) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before
running this configuration script.
Found 2 SDR's:
WARNING: Either an SDR has no serial number or two or more SDR's have identical serial numbers.
The configuration can only continue once all SDR's have unique serial numbers assigned.
The SDR's will now have their serial numbers changed to randomly assigned values and a reboot will be required.
If any of the SDR's are plugged into a powered USB hub then the hub will also need to be powered
down at the same time.
Proceed with updating the serial numbers and reboot [Y/n]: y
SDRs renamed, you should reboot now
Please rerun config afterwards
Do you want Reboot now [Y/n]: y
Following the second reboot, I re-ran config and the two "WARNING: device blah with serial number: blah cannot be found in dmesg log" messages have now gone.
(15:57:53) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before
running this configuration script.
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.
Do you wish to change the SDR(s) configuration [y/N]: N
Do you want to change the PAW Antenna Gain value (5) [y/N]: N
...
Test tuning of rtl-sdr device=1
...
Testing --ppm=-0 --gain=40
Capture @5ppm inrange=38 outrange=0
Frequency Capture Improvement = 37 -> 38
Receiver Xtal correction = 0-0.235 = -0.235 (0.086) ppm [90]
setting APRS_SDR_PPM=-0
setting APRS_SDR_GAIN=40
Testing --ppm=-0 --gain=45
Capture @5ppm inrange=36 outrange=0
Frequency Capture No Improvement
...
Found Rafael Micro R820T tuner
Exact sample rate is: 2000000.052982 Hz
Frequency = 920.000MHz..960.200MHz 2.000MHz step, 20 scans
Sampling rate = 2000000Hz = 2.000MHz
0.250sec per scan
FFT: 1024 bins, 1953.1Hz/bin, 0.256ms/slide
RTLSDR::Open(1,940100000,2000000) => Generic RTL2832U OEM, 940.100 MHz, 2.000 Msps
RTLSDR::Gain[29] = +0.0 +0.9 +1.4 +2.7 +3.7 +7.7 +8.7 +12.5 +14.4 +15.7 +16.6 +19.7 +20.7 +22.9 +25.4 +28.0 +29.7 +32.8 +33.8 +36.4 +37.2 +38.6 +40.2 +42.1 +43.4 +43.9 +44.5 +48.0 +49.6 [dB]
Open(1, 940100000, 2000000) OK
Tuner crystal correction set to 0 ppm
Tuner gain set to 40.0 dB (device reports 40.2 dB)
...
Receiver Xtal correction = 0-0.340 = -0.340 (0.298) ppm [139]
Note: when the receiver warms up the Xtal may drift 5-10ppm
########################## Summary ##########################
Station Name is : UKRUF
Station APRS Server is : aprs.glidernet.org:14580
Station Latitude is : 53.943130
Station Longitude is : -1.188770
Station Altitude AMSL [M] is : 24
Station Altitude GEOID [M] is : 49
Station SDR PPM is : -0
Station SDR Gain is : 40
Station SDR Freq Centr is : 940.800
########################## Summary ##########################
Starting Services
-
Above Post CONTINUED:
Interestingly before we changed the FLARM setup, and when it was running albeit with the temperamental FLARM set up it would often pick up an inrange number as follows:
"Capture @5ppm inrange=44 outrange=0"
BUT now seems to manage at most 38 so I tried a second run of config below, in which the gain figure differs as do some of the others but the same in range figure of 38 was achieved:
(16:02:00) FILESYS : Mount RW
Stopping Services
Do not plug in or remove any SDR dongles whilst this configuration script is running.
It is strongly advised to have the SDR's plugged in and then reboot the Pi before
running this configuration script.
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.
...
Testing --ppm=-0 --gain=30
Capture @5ppm inrange=38 outrange=0
Frequency Capture Improvement = 37 -> 38
Receiver Xtal correction = 0-0.310 = -0.310 (0.268) ppm [129]
setting APRS_SDR_PPM=-0
setting APRS_SDR_GAIN=30
Testing --ppm=-0 --gain=35
Capture @5ppm inrange=38 outrange=0
Frequency Capture No Improvement
...
Found Rafael Micro R820T tuner
Exact sample rate is: 2000000.052982 Hz
Frequency = 920.000MHz..960.200MHz 2.000MHz step, 20 scans
Sampling rate = 2000000Hz = 2.000MHz
0.250sec per scan
FFT: 1024 bins, 1953.1Hz/bin, 0.256ms/slide
RTLSDR::Open(1,940100000,2000000) => Generic RTL2832U OEM, 940.100 MHz, 2.000 Msps
RTLSDR::Gain[29] = +0.0 +0.9 +1.4 +2.7 +3.7 +7.7 +8.7 +12.5 +14.4 +15.7 +16.6 +19.7 +20.7 +22.9 +25.4 +28.0 +29.7 +32.8 +33.8 +36.4 +37.2 +38.6 +40.2 +42.1 +43.4 +43.9 +44.5 +48.0 +49.6 [dB]
Open(1, 940100000, 2000000) OK
Tuner crystal correction set to 0 ppm
Tuner gain set to 30.0 dB (device reports 29.7 dB)
...
Receiver Xtal correction = 0-0.319 = -0.319 (0.282) ppm [132]
Note: when the receiver warms up the Xtal may drift 5-10ppm
########################## Summary ##########################
Station Name is : UKRUF
Station APRS Server is : aprs.glidernet.org:14580
Station Latitude is : 53.943130
Station Longitude is : -1.188770
Station Altitude AMSL [M] is : 24
Station Altitude GEOID [M] is : 49
Station SDR PPM is : -0
Station SDR Gain is : 30
Station SDR Freq Centr is : 921.800
########################## Summary ##########################
Starting Services
I hope UKRUF now provides a steady and reliable FLARM feed!
-
With regards to the aforementioned "inrange" number being slightly lower than it has been previously when running the FLARM config (44 now 38), and in more general terms....
The new HDF400 Coax cable for the FLARM antenna goes through a hole in the wall that is shared with a Power over Ethernet cable which is routed to an external Internet Wi-Fi extender.
I appreciate you are meant to keep power cables away from Coax, but with it being low voltage(?) and that both the ethernet cable and the coax cable must have some element of shielding, is this likely to cause any noticeable issues?
Can probably re-route it if needed as we have separate holes for 1090 Coax, Pi3 Coax and FLARM coax... so what's another hole lol
Regards
Kevin
-
Hi Kevin
Please don’t worry about the inrange figures, this is simply using gsm signals to calculate the xtal drift
Thx
Lee
-
Hi Kevin,
POE cable running next to good quality (well screened) coax should cause no issues. I also echo Lee's comment about the 'In Range / Out of Range' figures - this refers to GSM signals available and used for calibration and has no relation to traffic or effective receive range.
Out of interest, what's in the box under the Flarm antenna?
Regards
Peter
-
Hi,
All the Coax cable we used (1090/Pi3/FLARM) is the HDF400, so I believe that is good quality low loss and is the stuff Keith supplies. So should be well insulated.
The FLARM antenna we have is not one we ordered from Keith, it was one we had already from our OGN Ground Station. A Gliding club member is a lecturer at a University in the area of radio, comms, antennas, electronics etc and so fine tuned this antenna at the uni. It has a small SMA Male Connector at the end, this is housed inside the waterproof box at the base of the antenna. We purchased an HDF400 SMA Female Crimp Connector which connects the Coax directly to the SMA connector at the base of the antenna (all housed in the small box).
Cheers
Kevin
-
Hi Kevin,
Thanks for the quick reply. As I said earlier, I wouldn’t expect interaction between your POE cable and the good quality coax you have used.
I take it the photo is of the connector on the bottom of the tuned ‘homebrew’ antenna? (not the end of the coax feed).
OK on the box being used to protect the SMA connectors. I was concerned that it might contain a filter/preamp (often used in OGN installations in an attempt to boost range). I had one of these fitted originally at my home station, but experience has shown that these can preclude (or at best seriously skew) the GSM Scan, so mine has since been removed. That was why I asked.
Hopefully all will now be good.
Best Regards
Peter
-
Hi peter,
Yes it's an sma connector at base of antenna in the photo.
Fingers crossed all will be well now.
Kevin
-
Thanks Kevin,
It certainly seems to be working ok now thanks to your hard work. Good to know that we have helped to get it sorted out.
I’ve just had a look at the PWUKRUF coverage via the PilotAware data site (I have access via the admin network) and it’s showing good levels of traffic at fairly impressive range, though probably not surprisingly a little bit ‘sparse’ on the FLARM side at the moment due to lack of recent activity. That should of course build again once we get back out of Lockdown and into better weather. I know I’m certainly experiencing withdrawal symptoms as I haven’t flown since before Christmas. Hopefully not too long now. :)
Best Regards
Peter
-
Thanks Pete,
There has been some FLARM traffic today at Rufforth as the Gliding Instructors have been taking currency flights (as permitted by the DFT and BGA).
What tools are you using to determine coverage?
Kevin
-
One thing I've noticed is that PWUKRUF has a couple of stickys on the Throttled report....
I'm not sure what the "stickys" represent.... do they mean the station has experienced those issues, if so how long does a "sticky" flag remain in place if the ground station is now operating OK
-
What tools are you using to determine coverage?
If you are the ground station maintainer you will have had an e-mail (to the address attached to your station) a while back with a URL + password for your ground station for remote access, and in one of the menus from the home page there is a coverage menu.
Some info here:
https://www.youtube.com/watch?v=VOoZPhzFNDY (https://www.youtube.com/watch?v=VOoZPhzFNDY)
Thread here:
http://forum.pilotaware.com/index.php/topic,1998.0.html (http://forum.pilotaware.com/index.php/topic,1998.0.html)
-
One thing I've noticed is that PWUKRUF has a couple of stickys on the Throttled report....
I'm not sure what the "stickys" represent.... do they mean the station has experienced those issues, if so how long does a "sticky" flag remain in place if the ground station is now operating OK
Sticky’s remain until the next reboot
I presume these are voltage issues?
Thx
Lee
-
I'm not aware of any issues.
So am wondering went the stickys.
-
Kev / Lee,
PWUKRUF is showing UVS and THS on the Database Throttled Screen, so both at some point since the unit was last rebooted, but not at the present time. Kev, as it seems to be working ok at the moment, I’d suggest just monitoring for a period and see what happens, or do a hard reboot to reset the report which will make it easier to see if it happens again.
I used the ‘Coverage’ tool which is accessed at the bottom of the ‘Status’ Dropdown on the ‘PilotAware Data’ Maintainer screen referred to by Steve above (rather than the Vector tab which is more for aircraft reports). You can then easily select the desired coverage type and if appropriate narrow the time period by selecting specific dates from the drop down calendar at the top right of the Coverage screen. Remember that ADSB reports are limited to a maximum of 60Km to control the level of data.
Regards
Peter
-
Thanks Chaps,
I did a remote "sudo reboot" over the weekend, but guess that does not reset the report. I assume I need to switch it off then on again.
It had been running for a while without the FLARM antenna or RTLSDR, maybe that had some bearing?
Regards
Kevin
-
Hi Kev
What is the power supply being used ?
Can you provide a link to where it was acquired?
I understand you are using POE ?
Thx
Lee
-
Hi,
PoE reference was due to a ethernet cable being used to power an external wi-fi antenna routing next to the FLARM Coax, not as a power supply to the ground station Pi.
The Raspberry Pi3 is being powered by the same AC/DC Adaptor that was used when it was just an OGN station. This is 5v 3amp (Model JCY-0530) micro USB.
However, we are showing sticky's rather than current voltage/throttling issues. Is there a log of when these voltage/throttling issues occurred?
I have just done a remote sudo reboot, this has indeed cleared UKRUF from the Throttled report. But if there was a voltage/throttling issue, why would it not be consistent if it was due to the power supply. What would cause intermittent voltage issues?
Kevin
-
Hi Kevin
The circuitry on the RPI which measures the voltage levels has a threshold, when this is crossed, the Flags are set both sticky and now
if the threshold is exited the sticky remains but the now is cleared
During different operations the RPI will draw different levels of power depending upon the processing which is happening.
The heaviest load is from the ogn-rf/ogn-decode processes, when there is a lot of FLARM data to decode, this can take processing upto 100%, this generates cpu load, and draws current, drawing current can cause the voltage to drop, triggering the flags in question
When the station was run as a pure OGN, this would not have been checked - there is nothing for you to observe if the voltage is dropping below the threshold, it could have been happening and you would have no feedback to tell you
I googled the power supply (Model JCY-0530), and could only find this reference
https://www.supremegamegear.com/products/5v3a-power-supply-us-plug
which shows it as a $1.75 power supply :-[
is that for real ?
I think the Official Pi power supply would be a better choice - but lets monitor how you get on with yours
Alternately, if you want an official supply, here is the reference.
https://shop.pimoroni.com/products/raspberry-pi-universal-power-supply
Thx
Lee
-
Thanks Lee,
I'll probably upgrade the power supply to the official Pi3 one for the sake of £8.
However, I notice the official Pi3 ones are only 2.5 amp (5.1v).
-
Hi Kevin
However, I notice the official Pi3 ones are only 2.5 amp (5.1v).
This is perfectly adequate, maintaining 2.5A at 5.1V is what we want to have.
I suspect that your power supply is not providing 3.0A at 5.1V, and
The Pi will not draw more than 2.0A in reality
Thx
Lee
-
Power supply replaced today with:
https://thepihut.com/products/official-raspberry-pi-universal-power-supply?variant=32255455330366¤cy=GBP&utm_medium=product_sync&utm_source=google&utm_content=sag_organic&utm_campaign=sag_organic&gclid=Cj0KCQiA-OeBBhDiARIsADyBcE5GHgnlh8Ntaki8ew4L7Aqmy2-m-AigVC7l87oGASm2SPNwv3gS7KYaAi7wEALw_wcB
Fingers crossed no more voltage drops or throttling.
-
Kev,
I was going to suggest a Pi4 (3amp) PSU with a USB-C to MicroUSB adaptor, just to be sure (though as Lee has said, this shouldn’t really be necessary).
Just a thought.
Best Regards
Peter
-
Hi,
All seems to be running very well now, no voltage issues etc. However, I have noticed that the Flarm tends to drop off still and requires a reboot of the Pi. I think you can tell this from the analysis here:
http://grafana.glidernet.org/d/000000001/receivers?orgId=1&var-receiver=UKRUF
Any ideas as to why?
-
Hi Kev
What makes you think the FLARM reception stops working ?
Thx
Lee
-
Hi Lee,
It seems to periodically (twice now that I'm aware of) to show the FLARM traffic at the local airfield as being rebroadcast from a station much further away (Church Fenton/Leeds East). Then when I reboot the Pi, all the local FLARM traffic starts showing as local again to Rufforth.
I was wondering whether this is corresponding with the RF Noise drops on the following graphs, as the sudden pick up in RF Noise tallies with the two occurrences I became aware of this issue and rebooted the Pi:
3rd April and 17th April. So this is more than a coincidence I suspect, and the drops in RF noise must indicate the loss of FLARM receipt. The reason for which I have no idea!
http://grafana.glidernet.org/d/000000001/receivers?orgId=1&var-receiver=UKRUF
Any ideas? Out of interest, what dates did you push any software updates?
-
Hi Kev
It seems to periodically (twice now that I'm aware of) to show the FLARM traffic at the local airfield as being rebroadcast from a station much further away (Church Fenton/Leeds East). Then when I reboot the Pi, all the local FLARM traffic starts showing as local again to Rufforth.
Interested to know how you determine that
Are you monitoring both stations at the same time ?
I think there may also be some confusion here, so lets clear that up first
if you are referring to the letter 'l' or 'r' on the Front page display, this merely refers to where the last data was received from
it could be local capture (through the RF/SDR), or remote capture (via the GRID) - this data is timestamped, so only the most recent is used internally.
There is a co-ordination from the GRID to tell each ATOM who should rebroadcast, as we do not want to clog the airwaves with un-necessary data. This is quite complicated, but in simple terms lets say, the ATOM(s) closes to the PAW requiring the rebroadcast is chosen - that may not be your ATOM, even though you are closest to the FLARM, you may not be closest to the PAW
In reality, each PAW is informing the ATOMS periodically who it can hear, this is then used as part of the GRID profiling for rebroadcasting, in most cases this relates directly to proximity, but not always - for example, local topography such as buildings, hills etc affect the broadcast in certain directions, the same is try of the aircraft obscuration, if antenna are situated internally to the front or rear
We regularly see a situation where rebroadcast only ever comes from ATOMS at certain directions from a plane, this is usually
due to obscuration either from the perspective of the aircraft, or the ground.
regarding noise - this is completely unrelated, we do not use this information as part of rebroadcast.
Out of interest, what dates did you push any software updates?
I think it was the 4/5 April
thx
Lee
-
Hi Lee,
This website shows a dotted line from the aircraft to the receiving station. This is how I could tell all the gliders were being received by Leeds East instead of Rufforth, despite being on the ground a few hundred yards from our station or in the local circuit.
https://www.gliderradar.com/center/53.93709,-1.17451/zoom/11/time/15
Also, looking at the FLARM page for Rufforth it showed that zero aircraft had been received over the past 12 hours, last hour, last minute etc. As soon as I rebooted these numbers went up.
Steve from Leeds East alerted me to the issue on 3rd April, it then happened again and I became aware on 19th April.
Hope this helps.
Kevin