Return-Path: Received: (qmail 27119 invoked from network); 21 Mar 2001 10:08:08 -0000 Received: from unknown (HELO warrior-inbound.servers.plus.net) (212.159.14.227) by excalibur.plus.net with SMTP; 21 Mar 2001 10:08:08 -0000 Received: (qmail 19893 invoked from network); 21 Mar 2001 10:08:05 -0000 Content-Transfer-Encoding: 8bit Received: from unknown (HELO post.thorcom.com) (212.172.148.70) by warrior with SMTP; 21 Mar 2001 10:08:05 -0000 Received: from majordom by post.thorcom.com with local (Exim 3.16 #2) id 14ffRL-0001a8-00 for rsgb_lf_group-outgoing@blacksheep.org; Wed, 21 Mar 2001 10:02:03 +0000 X-Priority: 3 X-MSMail-Priority: Normal Received: from fm215.facility.pipex.com ([194.131.104.225]) by post.thorcom.com with esmtp (Exim 3.16 #2) id 14ffRK-0001a3-00 for rsgb_lf_group@blacksheep.org; Wed, 21 Mar 2001 10:02:02 +0000 Received: from 233.pncl.co.uk (237.235.35.212.in-addr.arpa.ip-pool.cix.co.uk [212.35.235.237]) by fm215.facility.pipex.com (8.9.3/8.9.3) with ESMTP id JAA28942 for ; Wed, 21 Mar 2001 09:55:50 GMT X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <5.0.2.1.2.20010321095259.00ab8940@mail.pncl.co.uk> X-Sender: blanch@mail.pncl.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 21 Mar 2001 10:00:42 +0000 To: rsgb_lf_group@blacksheep.org From: "Walter Blanchard" Subject: LF: Loran In-reply-to: <018401c0b1df$afe68f40$687a37c0@w2ksn> References: <57.132cfa73.27e951ff@aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group Sender: Markus et al, There is a data transmission superimposed on Sylt (and now on the other EU Loran tx). which may explain your unknown lines. This extract from a paper given by TU Delft at the US PLANS 98 conference explains it a bit (I have full tech data if you really want it but it's too long to put on here) Quote: LORAN-C DATA TRANSMISSION As Loran-C is a navigation system in itself, its navigation requirements and parameters restricts the use of the signals for transmission of information. The additional data modulation onto the Loran-C signal shall not influence normal Loran-C operation. Therefore, the following restrictions are imposed on the use of the Eurofix datalink: - The blinking service must be preserved, which excludes the first two pulses of each Loran-C group from Eurofix modulation. - The modulation is not allowed to induce tracking biases, which requires a balanced type of modulation. - The modulation index must be kept small in order to prevent an undesirable loss in tracking signal power. Based on these requirements, a pulse position modulation with a 1 uS modulation index is chosen. Only 6 out of 8 pulses per group will be modulated and the modulation is always balanced on a per GRI basis. The application of 3-level modulation (a 1 uS advance, a prompt, or a 1 uS delay) leaves a possible 7 bit of information per GRI. With Loran-C GRI's varying between 40 ms and 100 ms, the raw bit rate available for data transmission ranges from 175 to 70 bps. Normal Loran-C users only experience a slight signal loss of 0.79 dB. Future Loran-C receivers, which have knowledge of the Eurofix modulation, can easily compensate for the applied modulation, once the pulses are demodulated. This will cancel the signal loss completely. Note that the influences of Cross-Rate interference and blanking, phenomena inherent to the choice of the Loran-C signal structure, cause larger signal degradation. DGNSS message format The differential information is sent to the user in an asynchronous message format. The use of standard RTCM type-1 messages requires too much time to transmit a complete set of corrections. To keep data latency within acceptable limits, a minimum RTCM type-9 compatible message of 56 bits is applied, Table 1. Unfortunately, the simple parity schemes used in the RTCM messages do not suffice in the Loran-C signal environment of Cross-Rate interference and high ambient noise levels. Therefore. a different error correcting strategy is chosen. However, as standard and commercially available DGNSS receivers must be facilitated, the received Eurofix data is converted into a standard RTCM type-9 message. Forward Error Correction To ensure reliable broadcast data communication through Loran-C. Forward Error Correcting codes are applied. These codes provide an effective means to correct occasional errors (improved datalink availability) and validate the decoded data (integrity) at the cost of an increased message overhead. Figure 1 shows the modulation and encoding currently used to transmit data via Loran-C. In Eurofix a Reed-Solomon code ensures datalink availability for stations up to 1,000 km. Each 56-bit message (8 GRI's of 7 bits) is protected by additional Reed-Solomon parity GRI's. In recent experiments messages contained in 20 and 30 GRI's have been tested. Depending on the Group Repetition Interval (40-100 ms) of the Loran-C station the effective datarate of these schemes will be 70-28 bps and 47-19 bps, respectively. Message integrity is protected in three steps: 1. Before demodulation a received pulse is first compared with a stored reference pulse, built up by integration of the first 2 unmodulated pulses (Receiver Autonomous Signal Integrity Monitoring, RASIM). This way, the quality of the demodulated pulses is preserved [6]. 2. The Reed-Solomon code inherently adds integrity to the messages. The Probability of Undetected Error. Pue for a 10-error correcting Reed-Solomon code (30-GRI Eurofix message) is 1/10! = 2.7*10-7. 3. As a final safety net a 14-bit Cyclic Redundancy Check (CRC) ensures a lower bound on the Pue of better than 2(-14)=6.1*10-5. The final message integrity will be a combination (probably product) of the above three mechanisms. This level of message integrity outperforms the level of the standard RTCM messages without further integrity improvements. IMPLEMENTATION OF DGPS SERVICE AT THE SYLT LORAN-C STATION On February 5th, 1997, Delft University installed a DGPS reference station at the Sylt Loran-C transmitter site (Germany) on an experimental basis. From that date on differential corrections have been broadcast throughout Europe on the Sylt Secondary rate 8940. Corrections for all satellites in view are broadcast in RTCM type-9 compatible messages with one satellite correction per message. The update rate for a 30-GRI message at the Sylt's GRI is once every 2.7 seconds per satellite (30*89.40 ms). Since September 23"', 1997, Sylt operates as a Secondary in the new French chain 6731. The slightly lower GRI number increased the update rate to once every 2.0 seconds. When also the Master rate of Sylt (7499) will be used for data transmission the correction update rate will be even further improved. End quote.