PR to address https://github.com/osqzss/gps-sdr-sim/issues/268

[pistoletpierre]

Updated README to include instructions for automatic download of RINEX nav files from urs.earthdata.nasa.gov as requested in https://github.com/osqzss/gps-sdr-sim/issues/268

[lenhart]

Hey, first: I am not the maintainer of this repository, but having an interest to get your PR accepted :-)

The bash script unfortunately does not work for me. Curl fails with an ssl error. I get the same error with all attempts I made with python (including all variations nasa suggests

Does it work for you at the moment?

Also I think the last target from the Makefile could be removed (ftp access to the brdc files). That would do a bit of cleanup as well.. What do you think?

Cheers!

[pistoletpierre]

Huh...I just tried it again & it went fine. Can you paste this into your terminal & paste the output back in this thread?

day=$(date +%j)
year=$(date +%Y)
yr=$(date +%y)
RINEX_NAV_FILE="brdc${day}0.${yr}n"
curl \
    --cookie-jar /tmp/cookie \
    --netrc \
    --location \
    --output "${RINEX_NAV_FILE}.gz" "https://cddis.nasa.gov/archive/gnss/data/daily/${year}/brdc/${RINEX_NAV_FILE}.gz"
ls ${RINEX_NAV_FILE}

[lenhart]

Hi, thanks for your help! That is good to know that it works for you... what happens for me is

https://cddis.nasa.gov/archive/gnss/data/daily/2021/brdc/brdc0220.21n.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
ls: cannot access 'brdc0220.21n': No such file or directory

I modified the script so that it prints the url first. If I copy it to a browser I can download the file alright though.. curl, wget and 3 python variations all have issues with the ssl handshake. I thought it might be problems with my computer, but another one and a raspberry pi behaves the same..

Edit: I have OpenSSL 1.1.1f 31 Mar 2020, I think that might be the real issue here... (and 1.1.1d on the pi)

[pistoletpierre]

Edit: I have OpenSSL 1.1.1f 31 Mar 2020, I think that might be the real issue here... (and 1.1.1d on the pi)

Hmm yes, and based on info from the following thread, it seems like the problem in this case may be on the server for only offering sha1 signatures (https://stackoverflow.com/questions/58342699/php-curl-curl-error-35-error1414d172ssl-routinestls12-check-peer-sigalgwr).

Rather than reduce openssl's SECLEVEL system-wide by editing the file mentioned in the linked stackoverflow thread, you can tack this on to your curl command if eager to get it working before the server fixes things on their end:

--ciphers DEFAULT@SECLEVEL=1 

Now I'm trying to figure out how concerned I should be that I'm not seeing the same error you are :P. Glad you brought it to my attention.

[lenhart]

yes, however testing their server with the ssllabs scanner shows more options available if I looked correctly..

I saw similar threads on SO, but the systemwide seclevel option is no longer in the ssl config. Appending it to curl directly fixes the handshake error but in only downloads the first 27 bytes for whatever reason..

Think I'll send NASA a mail and try the linked update procedure for ubuntu openssl in your linked SO thread first apparently it should work again with newer openssl versions..

thanks for your help! it was already driving me mad to spend so much time on such a trivial issue..

[lenhart]

Ok, enough, I'll write NASA tomorrow.. updating openssl fixes the handshake issue as well, but curl still only gets 27 bytes of junk. python and wget cannot validate their certificate locally, and wget with --no-check-certificate downloads 12kb of something..

[lenhart]

Another update: just when I wanted to write to them I found one version which works for me (when having updated openssl from 1.1.1f to 1.1.1i

curl -O -b .urs_cookies -c .urs_cookies -L -n https://cddis.nasa.gov/archive/gnss/data/daily/2021/brdc/brdc0310.21n.gz

don't know why the others fail, maybe NASA has an idea.. Cheers!

[lenhart]

So, (hopefully) last update: I received a quick answer by NASA, they suggest in point 17 in their faq what was already pointed out by you earlier, adding --ciphers DEFAULT@SECLEVEL=1 is required for certain older and newer versions of curl. And suddenly the exact command you posted earlier works for me :D (with updated openssl even w/o the extra parameter). I have no idea what changed in the meantime, a bit frustrating but at least now I have a working version w/o updating openssl.

The issue apparently lies with their server's load balancers and is not yet fixed. If I may suggest: it might be good to add a link to the faq or the added parameter to the script or so, as it apparently affects modern versions of curl/openssl too? cheers!

[GorgiAstro]

Hi all,

The CDDIS FTP (with TLS) still allows anonymous connections, for instance the following works:

wget ftps://gdc.cddis.eosdis.nasa.gov/pub/gps/data/daily/2021/brdc/brdc0620.21n.gz

I am also able to get BRDC files via Filezilla or via a Python script I wrote.

[atchyuth-rao]

I have tested GPS-SDR-SIM code with ADALM PLUTO SDR Hardware(with 2.6MHz sampling Frequency), I have followed the procedure which is mentioned in this site except for TCXO Modification of ADALM PLUTO SDR, GPS Signal spectrum is observed in the spectrum analyzer, but when I am testing with GPS receiver Satellite C/N ratios are changing abruptly(SatelliteS are visible in GPS Receiver but their C/N Ratios are not stable), I am not getting a position fix

can anyone suggest to me what modifications should I do for getting the position fix