GPS: Galileo reception possible on Kiwi? [working as of v1.178]

jksjks
edited April 2018 in KiwiSDR Discussion
Does anyone understand the specifics of the Galileo E1 OS (open service) signal transmitted on the GPS/Navstar L1 C/A frequency? (1575.42 MHz) http://www.navipedia.net/index.php/Galileo_Signal_Plan

Specifically I'm wondering about the required bandwidth and the necessity of receiving and using the pilot signal in decoding. The main lobe of an L1 C/A BPSK signal is about 2 MHz wide. The IF filter in the GPS front-end chip of the Kiwi has a -3 dB bandwidth of 2.2 MHz.

The Galileo E1B data signal main lobe is about 4 MHz wide. The Kiwi front-end has 8 dB loss at 4 MHz b/w. But the E1C pilot signal center frequencies are at +/- 6.138 MHz; over 12 MHz b/w. The Kiwi front-end has 23 dB loss at 8 MHz b/w which is a problem. Is the pilot just an optional aid to weak signal acquisition or tracking loop performance? I.e. can you get by without using it?

Thanks.


Comments

  • jksjks
    edited February 2018
    Think I found my answer. From http://gps.aau.dk/fileadmin/gps/Dowloads/Papers/galileo_sig.pdf

    "The minimum bandwidth is generally twice the chipping rate for simple codes,
    while for BOC codes it is twice the sum of chipping rate and offset code rate.
    Thus, the minimum practical bandwidth for the Galileo E1 is 8 MHz."

    GPS is a simple code, so chip rate 1.023 MHz means a minimum b/w of 2 MHz for GPS.





  • jksjks
    But, experiments with this: https://github.com/jks-prv/GNSS-DSP-tools (thanks Peter Monta) are starting to say otherwise..

  • jksjks
    edited February 2018
    The problem in a picture. If you push a Galileo E1B signal through the Kiwi SE4150L front-end chip you really only get the bandwidth shown in green below with about 8dB loss (4 MHz). All sources say you really need the b/w shown in yellow at a minimum (8 MHz) and preferably the b/w shown in blue (14 MHz). But why exactly? Would using just the two main BOC(1,1) lobes work at all? If it works how bad would the degradation be?


    image

    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/c5/9fdc92c8a0db1b90bef867919baeb3.jpg
  • KA7UKA7U
    John,
    What is your plan? Once you have this time base and precise location information, do you plan to use it to locate transmitters by triangulation of two or more KiwiSDR on the signal, or what is it you are up to? how will this Gallelio system help with your project beyond what the existing GPS code provides you with. Is it time to upgrade the KiwiSDR hardware to a new and improved KiwiSDR?

    I doubt I'll understand your answer, but go ahead.
    Ron
    KA7U
  • jksjks
    edited February 2018
    The recent addition of the QZSS sats (Asia/Oceania reception only) increases the percentage of time enough sats are available for fixes (minimum 4 sats required). This is especially true for GPS antennas that don't have a full view of the sky (i.e. shadowed by terrain or buildings). It certainly made a big difference at my NZ location. Since the Galileo E1 signal transmits on a frequency compatible with the Kiwi the question has been asked if it can also be received. It has worldwide reception and so would be very helpful.

    I think the majority of Kiwi owners struggle just to get the supplied antenna near a window, let alone outside and up high. Anything we can do to increase the percentage of Kiwis with functioning GPS would be very useful (e.g. more candidate Kiwis to participate in direction finding experiments). Plus they benefit from automatic, accurate frequency calibration of the SDR.

    I don't know much about HF-DF / triangulation, but fortunately we have a Kiwi user that does. He's already got it working! See: http://hcab14.blogspot.com

    KA7U
  • bbachmannbbachmann
    Hi John.
    I can see that you are working with til Galileo satellites. Are they useable in your part of the world, or du you need receivers in Europe?
    Regards
    Bjarne Bachmann
  • jksjks
    Hi Bjarne. Galileo has global coverage. So it would be very helpful to receive them with the Kiwi together with the existing Navstar GPS.

    I noticed the other day the beta test Kiwi near Stockholm was receiving one of the Asia/Oceania region QZSS satellites. It was less then 20 degrees above the horizon but decoding just fine. I'm surprised the geometry worked out to allow this.

  • bbachmannbbachmann
    Hi John
    My antenna is located at a too low altitude to see the QZSS satellites. I need at least 25 meter more to look that low.
    It must also be an antenna with a large opening.
  • jksjks
    edited March 2018
    So on the Internet I found a file of GPS samples taken using the same front-end chip as the Kiwi uses (SiGe/Skyworks SE4150L). Note: finding a file is necessary because currently the Kiwi has no mechanism to record a large set of samples from the SE4150L chip in real-time (16.368 MHz) to a file. I ran the samples through Peter's GNSS-DSP-tools and got acquisition of Galileo sats. More importantly I also got tracking of individual sats with correct decoding of the navigation message sync pattern.

    This is excellent news and is an existence proof that the limited bandwidth of the SE4150L can indeed handle a Galileo signal. Peter however points out that there is no free lunch and that there is going to be a sacrifice in sensitivity and multi-path resistance by not processing the full bandwidth. But ultimate performance is not the goal here. We just need to increase the pool of sats available to Kiwis with less-than-ideal antennas.

    I added Galileo support to my software simulation of the FPGA parts of Andrew Holme's GPS software (much easier to debug than running on real FPGA hardware). But so far I have not been able to get tracking to work.

  • jksjks
    edited March 2018
    After five straight weeks of 12/7 days I finally succeeded in getting decoded Galileo subframes using the actual Kiwi. No position/time solutions yet -- that will take a little more work as the subframe format is a bit different from Navstar.

    There are lots of problems still. The LO PLL (Costas loop) isn't locking quite reliably and I'm not sure why. There are some other strange things that need to be understood.

    Shout out to Peter Monta for some valuable discussions and his Python GNSS simulation code (github.com/pmonta/GNSS-DSP-tools). Also Taro Suzuki for github.com/taroz/GNSS-SDRLIB which saved me a lot of time. And of course where would we be without Phil Karn's (KA9Q) venerable FEC/Viterbi work (github.com/Opendigitalradio/ka9q-fec)

    Galileo 9 (PRN E24) being received alongside Navstar PRN 2:


    image


    image

    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/e2/1ec2340833f3541210f39d825ea199.jpg
    https://forum.kiwisdr.com/uploads/Uploader/b1/b12112f8ce35d8cc1cdb47a3557999.png
  • bbachmannbbachmann
    Sounds great :-)
    Looking forward to test the new code 

    Bjarne
    OZ1AEF
  • WA2ZKDWA2ZKD
    I see QZSS pop up here but don't think I've seen an acquire yet
  • jksjks
    edited April 2018
    v1.177 is out with Galileo support. Not perfect, but good enough for some widespread testing.

    On the admin GPS tab the switch labeled "Plot Galileo?" determines if separate position solutions including Galileo, and not, are computed and displayed. But note that this only works if there are at least 4 sats of each category present (i.e. 4 Galileo, 4 Navstar/QZSS). On the new "Map" display different color pins will be used to show the differences. See the legend at the bottom of the map.

    Sometimes when Galileo sats are used the positions don't agree with Navstar/QZSS (i.e. the green and red/yellow pins will be spaced some distance apart). This may be due to the well known false-peak locking issue with the Galileo waveform. We are still implementing a solution for this issue.

    fractional_n
  • SM2BYCSM2BYC
    Seems to be extremely unstable. Clicking on almost anything on the GPS tab results in restart/reboot.

    Regards Mauritz / SM2BYC
  • fractional_nfractional_n
    Hi john.
    Thank you for your great work.
    I got a reception screen including Galileo.

    However, serious problems are occurring in my environment.
    My server goes down and restarts each time the graph screen is switched on the admin GPS tab.



    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/7e/da8fe030e0122b1a176c7e5d9f422d.jpg
  • jksjks
    Hmm. An interesting timing problem that somehow escaped all my testing.
    I just released v1.178 to fix the problem. Please restart your Kiwi to get the fix right away (won't be hard if it's crashing all the time, lol).

  • SM2BYCSM2BYC
    Thanks, seems to be working fine now with v1.178. It did the restart "automatically".
    Question: as there are now more than 12 satellites available at any time, how are the satellites to be tracked selected? At random, the strongest or those giving best accuracy?

    Regards Mauritz / SM2BYC
    image

    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/dd/b52eb0da3f6aa4920f338615874f53.png
  • G8JNJG8JNJ
    My thanks to John and Christoph for providing this.

    It's a brilliant bit of work.

    Regards,

    Martin - G8JNJ
  • jksjks
    edited April 2018
    Mauritz: The channels are filled randomly as satellites are acquired. There is no special ordering. If there are free channels acquisition continues attempting to find new sats. And of course channels will become free as sats go out-of-range or become obscured by terrain.

    There is currently a restriction. If you look carefully you will note that Galileo sats (those with PRNs "En") only ever appear in channels 1-4. These 4 channels contain the special memory needed to hold the Galileo PRN sequence. Because we are out of memory blocks on the FPGA there were not enough to give Galileo capability to all 12 channels. But there is an optimization we are looking at that may fix this problem.

  • SM2BYCSM2BYC
    Thanks for the clarification.

    I assume that the next step is to have support for a DGPS decoder. The output from DGPS decoder can then be used improve GPS position accuracy so the kiwiSDR can also be used as a surveying instrument...

     Regards Mauritz / SM2BYC
  • bbachmannbbachmann
    Mauritz: Are you thinking of EGNOS / WAAS DGPS or DGPS based on 300 kHz beacons?
    Regards Bjarne / OZ1AEF
  • JohnTJohnT
    Hi John

    A great piece of work from you guys. Many more satellites now being found even though I am still using the supplied aerial by the shack window.

    I have plans to fit an outdoor antenna over the summer which will make a big difference.

    The GPS screen is very busy with lots of information so I wondered if you had considered adding a page/tab to the admin screen explaining what all the various parameters mean. I am aware that this has been covered in various posts but it would be helpful to have it all in one easy to find location.

    Regards  John / G4HPW

  • SM2BYCSM2BYC
    I was thinking on the 300 kHz beacons as there has been requests for decoders for that band.

    Regards Mauritz / SM2BYC
  • fractional_nfractional_n
    Looks good with Galileo support. Thanks.

    On the other hand, by allocating 4 channels to Galileo, GPS(Navstar)/QZSS is competing for the remaining 8 channels, so it's pretty overcrowded.
    In order to make effective use of limited channels, it seems necessary to have a new function to preferentially select satellites with even better quality.

    For example,
    low elevation/SNR/RSSI masking
    kicking undesireble sats
    select/unselect GNSS (Navstar/QZSS/Galileo)
    etc...


    Attachments:
    https://forum.kiwisdr.com/uploads/Uploader/e9/86509847a23b3f0b3fa3b21ceb058e.jpg
  • WA2ZKDWA2ZKD
    elevation masking is used in RTK stuff

  • jksjks
    The simplest solution is to fix the memory problem so call channels can be used for all classes of satellites.

    WA2ZKD
Sign In or Register to comment.