VORs and SDRs Part 1 & 2 Supplemental materials


Part 1

Part 2

I want to share some supplemental materials to go along with this video. In the attached zip file, I’ve included the raw samples (32k/sec sample rate, roughly centered carrier) and the GNU Radio Companion file for basic processing. I’d be very interested to see if others can squeeze out a little better performance.

Also, this is the path that I took. It may help understand the angles. I need to make clear that I’m not at all certain that the absolute angles are representative to compass points. I’m only looking at relative angles at this point. Eventually I’ll calibrate the system using a known VOR calibration location (there is one at the Corvallis airport).

This is the path I took while collecting the VOR data. Ignore the drive time

This is the path I took while collecting the VOR data.

  1. #1 by Chris on January 11, 2015 - 2:05 pm

    Very cool project.

    Is it possible to capture data from all the VOR stations in range at the same time, with the same radio dongle, or do you need separate ones? I thought that receiving multiple signals at once was one of SDR’s superpowers.

  2. #2 by hpux735 on January 11, 2015 - 2:26 pm

    @ Chris

    In principle, yes. I had hoped to use my BladeRF, which would have been able to capture just about all of them. The problem is that it only tunes down to 300MHz. I’m tempted to get the down converter.

  3. #3 by michael winthrop on January 18, 2015 - 12:22 pm

    Very cool project. 15 years ago I wrote a software VOR mapping program in PocketC (Jeremy Dewey) for the Palm Pilot. I called it 1speed-distance and put it out free with source under the GPL. It generates lat/lon based on the “from” VOR reading of two stations. Using two fixes and a time between fixes gives ground speed. I still have the source code, and am slowly converting it to ANSI C for my android phone. The program has a database of VOR locations from that era. I tested the software against readings provided in a station handbook. I converted magnetic bearing to map bearing to get a map track. There is a rudimentary map display, but I did not integrate it with a flight chart. I man a VFR private pilot, my plane is N9777W.

  4. #4 by hpux735 on January 18, 2015 - 6:44 pm

    That’s awesome! Did you just hand-enter the radials, or did you have some automated way of getting them in there?

  5. #5 by David on August 26, 2015 - 8:15 am

    I had a question. Do you publish your xcode project to this so people can see how you coded it?

    That would be really cool to look at!

    David

  6. #6 by hpux735 on August 26, 2015 - 8:37 am

    I’m torn. My code crashes the Swift compiler, and it’s written in Swift 1.2 syntax. I can update it to Swift 2.0, but that would require you to have access to the beta Xcode from Apple. I’m happy to do that, but would be no point if you can’t do anything with it.

  7. #7 by steve on September 29, 2015 - 1:58 am

    In watching your videos on sdr and VORs, i was reminded on something I was reading about the nav system for the Boeing 777 Flight Management System. When it is in range of multiple navigation signals it does a quality assessment of the system by comparing GPS, radio nav aids, and inertial nav. Instead of using VORs as the cross check, it uses multiple DME readings to compute a position. I was surprised at this choice, which the Boeing authors attributed to accuracy. Your results seem to validate that choice. I wonder if the combination of differing mag variation baseline dates might skew the size of your VOR navigation solution error circle. (BTW I think that Flight Aware tracks might be ADS-B track data.)

  8. #8 by hpux735 on September 29, 2015 - 7:26 am

    That’s awesome! Yah, I definitely wouldn’t try to build a “real” system using VORs. It really is hard to get a fix that has any precision. I could believe that DME would be a much more precise system. The problem, for me anyway, is that DME requires transmission, and I’m not even going to get into the (il)legality of that! 🙂

    The magnetic variation could be a good clue to the issue, too. I ended up tweaking an offset for the stations (I used the same offset, assuming it was an error in my signal chain), but assuming slight changes in angle for each station would allowed me to come up with a better solution.

    Finally, yah, FlightAware can use ADS-B and radar. They started with radar only (getting a feed from the FAA), but now they offer a kit where you can use a SDR dongle to feed ADS-B into their network.

  9. #9 by Martin on November 2, 2015 - 7:31 am

    Are you near a VOT? That would allow you to calibrate your setup. I see several in Oregon listed here:
    http://www.pilotnav.com/browse/Navaids/continent/North%20America/country/UNITED%20STATES/state/OREGON

  10. #10 by hpux735 on November 2, 2015 - 7:44 am

    Yep, I used the CVO VOR to test my system. I didn’t need to calibrate it much, per se, because the way the phase detector works, it doesn’t need calibration. I do think that magnetic variation is the most likely explanation for small errors.

  11. #11 by Martin on November 3, 2015 - 11:05 pm

    I was really referring to a VOT not a VOR but I understand your answer. Phase shift of zero is zero, so you don’t need a reference test transmitter.
    Concerning variation, the only thing I can think of is that you maybe apply the variation of today to the VOR radial while you should be applying the variation that was valid when the VOR was built / calibrated? VORs don’t point to magnetic north unless they were built this year.
    Other errors I have seen elsewhere are maybe wrong geo math formulas. In Excel I calculate a radial as (note: excel needs swapped atan2 parameters):
    =MOD(ATAN2(COS(vorlat/180*PI())*SIN(mylat/180*PI())-SIN(vorlat/180*PI())*COS(mylat/180*PI())*COS((mylon-vorlon)/180*PI()),SIN((mylon-vorlon)/180*PI())*COS(mylat/180*PI()))/PI()*180,360)
    Then of course the variation needs to be added.
    Does that match your radials?
    Other than that I would verify the integration function of your phase detector. Maybe something is not linear with the phase shift angle?

  12. #12 by hpux735 on November 5, 2015 - 1:47 pm

    @Martin

    Oh, interesting. I didn’t know about VOTs. That would be a cool thing to try.

    The math I’m using for radial calculations all come from the “Aviation Formulary” http://williams.best.vwh.net/avform.htm

    If you’re interested in my implementation of a radial (really, just a vector between two locations) here’s the code (it’s in Swift):

    // The difference between two locations is the vector from
    // location 1 to location 2.  This is computed along the
    // surface of the earth without consideration of elevation,
    // then the elevation is linearly computed between the given
    // locations.
    func -(loc2Deg: Location, loc1Deg: Location) -> Vector {
        let loc1 = loc1Deg.toRadians()
        let loc2 = loc2Deg.toRadians()
    
        // Compute the distance
        var lat = sin((loc1.latitude  - loc2.latitude)  / 2.0)
        var lon = sin((loc1.longitude - loc2.longitude) / 2.0)
        let clL = cos(loc1.latitude)
        let clJ = cos(loc2.latitude)
        lat = lat * lat
        lon = lon * lon
        let d = 2.0 * asin(sqrt(lat + clL * clJ * lon))
    
        // The formula below does not work if location 1 is a pole
        // Therefore, we can handle it as a special case.
        // Unfortunately, it's basically meaningless.
    
        // Assume starting from the north pole
        var tc: Double = M_PI
        if cos(loc1.latitude) < eps {
            // Starting from the south pole
            if loc1.latitude < 0.0 {
                tc = 2.0 * M_PI
            }
        }
        // We're not at a pole
        else {
            tc = (sin(loc2.latitude)-sin(loc1.latitude)*cos(d)) / (sin(d)*cos(loc1.latitude))
            tc = acos(tc)
            if sin(loc2.longitude - loc1.longitude) < 0.0 {
                tc = 2.0 * M_PI - tc
            }
        }
    
        // Output value
        return Vector(
            course: tc / M_PI * 180,
            distance: d * 180 * 60 / M_PI,
            vertChange: loc2.elevation - loc1.elevation)
    }
    

    I wrote a unit testing suite with known points and distances, and my implementation matches the known values. I have fairly high confidence that this part of it is correct.

    The phase shift computation could be problematic. It may be a good idea for me to generate pretend VOR modulation that I can control and test the demodulator’s sensitivity and linearity. I don’t have time to do it now, though.

  13. #13 by meg on February 19, 2016 - 7:53 am

    Hi,

    Yes, very cool project.
    Has anyone already build a grc which simulate the VOR transmitter ? because I am away of any VOR, and would like to send the VOR signal out of my HackRF transmitter.

    meg

  14. #14 by hpux735 on February 19, 2016 - 8:22 am

    Hi Meg,

    I don’t know of anyone that’s made a VOR simulator yet. I thought about it, but it was easy enough to get signals from a real one. It would be a cool project, and it shouldn’t be too hard.

  15. #15 by meg on February 19, 2016 - 10:01 am

    Hi,

    I will try…. and let you know…
    of course… any input are welcome 😉

    meg

  16. #16 by Ignazio on February 23, 2016 - 12:20 am

    Hi all,

    First of all, congratulation for your project. I simulated a VOR transmitter in GRC, but until USRP do not arrive to the University i will not test it. My question is quite easy, It will work with a DVOR (Doppler VOR). When i went to the Sevilla VOR (http://ourairports.com/navaids/SVL/Sevilla_VOR-DME_ES/#lat=37.42789840698242,lon=-5.762209892272949,zoom=10,type=Satellite) i couldn’t see the commonly known VOR signal in frequency. I’ll try to decode the MORSE identificator.

    @hpux735 could you send me the grc parameters which you use to catch the VOR’s signal.

    Thanks so much

  17. #17 by ashley on January 31, 2018 - 4:48 pm

    Hi,
    We are working on a project to do a similar thing and think that your work could be extremely useful! Watching the part 2 video, what do you do to the data exactly before opening it in audacity? We recorded data from our local VOR beacon just as you did in the first video, and I am worried that we are missing some steps. Do you create a new file using “VOR-complete”? What file are you looking at in audacity? Any help would be EXTREMELY helpful. This work is really cool and I would love to learn more. Thanks.

  18. #18 by hpux735 on January 31, 2018 - 5:12 pm

    Hi Ashley,

    Yes, quite a bit happens to the raw files before what you see in audacity. Are you familiar with GnuRadio? What receiver did you use? What sample rate? Have you seen these additional files ( http://www.housedillon.com/other/vor/ )?

  19. #19 by ashley on January 31, 2018 - 6:45 pm

    I am only a little familiar with GNU radio I have spent about a week trying to learn the basics here and there. We used a NESDR SMArt SDR with a telescopic antenna mast. We plugged it right in to the “VOR-complete” GRC that you provided. I assume the link that you attached in the comment can be inputted into the gnu radio command terminal?

  20. #20 by Ross on March 13, 2018 - 4:50 pm

    When I downloaded your additional files from github the “VOR-post2” file had a “missing block” (key phase_detect). Is this a block from a specific tool box/kit? Or did you write this block yourself? Thanks for your help.

(will not be published)

Please complete this capcha. I get almost 1000 spam comments a day! * Time limit is exhausted. Please reload CAPTCHA.