Custom Query (104 matches)
Results (22 - 24 of 104)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#9 | worksforme | Ntripcaster reset ntrip server connection immediately after authentication | ||
Description |
This may be related to issue #6. This is found in ntripcaster 2.0.15.
Below is from my log file: [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Building request out of [POST /jshih HTTP/1.1] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Building request from jshih [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: req->path = jshih, req->port = 80, protocol = 3 [27/May/2011:21:28:38] [66576:Connection Handler] get_ntrip_method: name POST [27/May/2011:21:28:38] [66576:Connection Handler] get_ntrip_method: found method [POST] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Host] == [hera.novatel.ca] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Ntrip-Version] == [Ntrip/2.0] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [User-Agent] == [Ntrip NovAtelServer/1.0] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Transfer-Encoding] == [chunked] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Connection] == [close] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Authorization] == [Basic anNoaWg6anNoaWg=] [27/May/2011:21:28:38] [66576:Connection Handler] read header: Ntripversion 2.0 Cseq -1 Session -1 Transferencoding chunked [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: HTTP Encoder logging in with path jshih [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: authenticate_source_request(): NTRIP2.0: checking source user [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: con_get_user() decoding: [anNoaWg6anNoaWg=] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: con_get_user() decoded: [jshih:jshih] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Checking need for authentication on mount /jshih [27/May/2011:21:28:38] [66576:Connection Handler] ntrip_write_message: OK: connection 66570 from [10.4.44.132] written: [HTTP/1.1 200 OK Ntrip-Version: Ntrip/2.0 Server: NTRIP Caster/2.0.15 Date: Fri, 27 May 2011 21:28:38 GMT Cache-Control: no-store,no-cache,max-age=0 Pragma: no-cache Connection: close Transfer-Encoding: chunked ] [27/May/2011:21:28:38] [66576:Connection Handler] Accepted encoder on mountpoint /jshih from 10.4.44.132. 6 sources connected [27/May/2011:21:28:38] [66576:Source Thread] Setting fd 9 to nonblocking [27/May/2011:21:28:40] [66576:Source Thread] Didn't receive data from source after 1600 milliseconds, assuming it died... [27/May/2011:21:28:40] [66576:Source Thread] Kicking source 66570 [10.4.44.132] [Source died] [http source], connected for 2 seconds on mountpoint jshih, 0 bytes transfered. 5 sources connected [27/May/2011:21:28:40] [66576:Source Thread] DEBUG: Closing fd 9 [27/May/2011:21:28:40] [66576:Source Thread] DEBUG: Removing connection 66570 of type 1 [27/May/2011:21:28:40] [66576:Source Thread] Removing source 66570 (0xb7a00bc8) from sourcetree of (0x85b2820) [27/May/2011:21:28:40] [66576:Source Thread] DEBUG: Removing thread 66576 started at [main.c:807], reason: 'Thread Exited' |
|||
#24 | fixed | Error description regarding GLONASS clocks sent by Loukis Agrotis | ||
Description |
First message from Loukis:
My suspicion is that there is a problem in using the GLONASS brdc drift term (or a misunderstanding on my part). In any case I am attaching extracts of the BNC decoded CLK files, the batch clock files that are submitted by the ACs, the reconstructed clock files that I generated and the brdc file for the relevant epoch (from CDDIS). Please note that the results I generated (gma, bka, cna, dla) are in exact agreement with the manual reconstruction in the spreadsheet. Also, the GPS results are very close, showing that the GPS satellites are properly encoded and decoded.
Files attached
Test results from Andrè Hauschild:
I conclude from these findings, that your way and my way of converting from RTCM-SSR to SP3 are consistent.
|
|||
#25 | fixed | message from Loukis regarding GLONASS MSM | ||
Description |
I have a suspicion that the degradation of the GLONASS ephemeris may have been corrupting the RTCM MSM GLONASS measurements and would like to ask if this is something you are aware of. The reason I am asking is because I had problems with solutions involving MGEX GLONASS observations but the solutions based on IGS-sourced RINEX files and conventional RTCM streams from the RTS appeared to behave well. Is there a reliance on the GLONASS ephemeris within the RTCM MSM encoding software that could be affected by the corrupted messages? |