DESC:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION

(See Section 10 and Rule 13)

Title of invention:
A SYSTEM AND METHOD FOR DATA VALIDATION

APPLICANT:
AARAV UNMANNED SYSTEMS PRIVATE LIMITED
An Indian entity having address as:
#3, 80 Feet Main Road, MCHS Layout,
Jakkur, Bangalore - 560064

The following specification describes the invention and the manner in which it is to be performed.
CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
The present application claims priority from Indian from the Indian patent application, having application number 202241069279, filed on 01st Decemeber 2022, incorporated herein by a reference.
TECHNICAL FIELD
The present disclosure relates to a system and a method for data validation. More specifically, the present disclosure relates to validating the quality of observed data through an observation quality check (OBS QC) tool.
BACKGROUND
The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to implementations of the claimed technology.
At present, the means for positioning or tracking of an object is known in the market. The most known tracking or positioning system is a GPS tracking system which utilizes the Global Navigation Satellite System (GNSS) network to locate or track stationary or movable objects. The GPS receiver generally receives signals from multiple satellites orbiting the earth to calculate distance between the satellites and the GPS receiver. Based on the distance calculated, the GPS locates the position of stationary object, or direction, time, and speed in case of a movable object.
Further, the distance calculation for positioning or tracking of the object done by GPS receiver, requires massive volumes of data to be processed. However, processing large amounts of data may lead to some erroneous results. Due to erroneous results, there might be the possibility of wrong positioning or tracking of the object by the GPS receiver. Also, in the case of Unmanned Aerial Vehicles (UAVs), where conventional GPS are not used due to battery draining limitations, the GNSS receiver module retrieves large amounts of data from the satellites for tracking the UAV. However, processing large amounts of data without validation may lead to improper positioning or tracking of the UAV/object.
Therefore, there exists a long felt need for the positioning or tracking system to process the data along with its validation, to overcome the above-mentioned problems.
SUMMARY
The present disclosure overcomes one or more shortcomings of the prior art and provides additional advantages discussed throughout the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure. The present disclosure has been made to solve the problems, and it is an object of the present disclosure to provide a system and method for data validation.
In one non-limiting embodiment of the present disclosure, a system for data validation is disclosed. The system may comprise a global navigation satellite system (GNSS) module, a control and storage unit and an observation quality check (OBS QC) tool. The GNSS module may be configured for receiving a plurality of signals from a plurality of satellites to form one or more raw data packets. Further, the control and storage unit may be configured for receiving and storing the plurality of raw data packets. Further, the control and storage unit may be configured for converting the plurality of raw data packets into a raw data file. Furthermore, the OBS QC tool may be configured to receive the raw data file from the control and storage unit. Additionally, the OBS QC tool may be adapted to receive a plurality of configuration parameters from a user associated with the OBS QC tool. Also, the OBS QC tool may process the raw data file to determine the validity of one or more raw data packets based on the plurality of configuration parameters. In addition, the OBS QC tool may provide an output based on the validity of the one or more raw data packets.
In another non-limiting embodiment of the present disclosure, a method for data validation is disclosed. The method for data validation may comprise the steps of receiving, via a global navigation satellite system (GNSS) module, a plurality of signal from a plurality of satellites to form one or more raw data packets. The method may further comprise the step of receiving and storing, via a control and storage unit, the one or more raw data packets to convert the one or more raw data packets into a raw data file. Further, the method may comprise the step of receiving, via an observation quality check (OBS QC) tool, the raw data file. Furthermore, the method may comprise the step of receiving, via the OBS QC tool, a plurality of configuration parameter from a user associated with the OBS QC tool. Additionally, the method may further comprise the step of processing, via the OBS QC tool, the raw data file for determining a validity of the one or more raw data packets based on the plurality of configuration parameters. In addition, the method may further comprise the step of providing, via the OBS QC tool, an output based on the validity of the one or more raw data packets.
The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.
BRIEF DESCRIPTION OF DRAWINGS
The features, nature, and advantages of the present disclosure will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:
Figure 1 illustrates, a system (100) for data validation, in accordance with an embodiment of the present disclosure.
Figure 2 illustrates, an OBS QC tool (104) and components of the OBS QC tool (104), in accordance with an embodiment of the present disclosure.
Figure 3 illustrates, a method (300) for data validation using the system (100), in accordance with the embodiment of the present disclosure.
Figure 4 illustrates the satellite count using representation of data points available from each satellite for multiple time instances, in accordance with the embodiment of the present disclosure.
Figure 5 illustrates, the skip data point available from each satellite for multiple time instances, in accordance with the embodiment of the present disclosure.
Figure 6 illustrates, the graphical representation of Quality check (QC) Data Quantity, in accordance with the embodiment of the present disclosure.
Figure 7 illustrates, representation (700) of Carrier phase measurement as the data quality indicator parameter, in accordance with the embodiment of the present disclosure.
Figure 8 illustrates, representation (800) of Data Gap as the data quality indicator, in accordance with the embodiment of the present disclosure.
It should be appreciated by those skilled in the art that any block diagram herein represents conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION
The terms “comprise”, “comprising”, “include(s)”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, system or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or system or method. In other words, one or more elements in a system or apparatus preceded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or apparatus.
Reference throughout the specification to “various embodiments,” “some embodiments,” “one embodiment,” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrases “in various embodiments,” “in some embodiments,” “in one embodiment,” or “in an embodiment” in places throughout the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Referring to figure 1, a system (100) for data validation is illustrated, in accordance with an embodiment of the present subject matter.
In one non-limiting embodiment of the present disclosure, the system (100) for data validation may comprise a global navigation satellite system (GNSS) module, a control and storage unit and an observation quality check (OBS QC) tool.
In one embodiment, the GNSS module (101) may be configured to track a plurality of satellites (102a, 102b, 102c, 102d, 102e) in its field of vision and to receive a plurality of signal from the plurality of satellites (102a, 102b, 102c, 102d, 102e). In yet another embodiment, the GNSS module (101) may be connected to the plurality of satellites (102a, 102b, 102c, 102d, 102e) via a network (105). In one implementation, the GNSS module (101) may be referred to as a GNSS receiver.
Although the present subject matter is explained considering that the GNSS module (101) is communicatively coupled with the plurality satellites (102a, 102b, 102c, 102d, 102e), it may be understood that the GNSS module (101) is communicatively coupled with the plurality of satellites (102a, 102b, 102c, 102d, 102e), via a network (105).
In one implementation, the network (105) may be a wireless network, a wired network or a combination thereof. The network (105) can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network (105) may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further, the network (105) may include a variety of network devices, including routers, switches, bridges, servers, computing devices, storage devices, and the like.
In one embodiment, the GNSS module (101) may be configured to decode each signal from the plurality of signals. The GNSS module (101) may be adapted to compute the distance between the GNSS module (101) and each satellite from the plurality of satellites (102a, 102b, 102c, 102d, 102e), by decoding of the plurality of signals. Furthermore, the GNSS module (101) may use the said computed distance to further compute its position on the globe. Further, the GNSS module (101) may be configured to form one or more raw data packets using the plurality of signals. The one or more raw data packets may comprise the distance between the GNSS module (101) and the plurality of GNSS satellite (101), and the plurality of data quality indicator of each satellite of the plurality of satellite.
In another embodiment, the distance computing by the GNSS module (101) may be influenced by external obstructions or internal signal decoders, leading to errors in distance determination and consequently affecting the positional accuracy. The GNSS module (101) may detect these errors and may report such errors as a data quality indicator.
In yet another embodiment, the GNSS module (101) may be stationary or moving. In one exemplary embodiment, the GNSS module (101) may be implemented on the Unmanned Aerial vehicle (UAV) or drone. Further, the raw data packet of stationary GNSS module may comprise a first data packet. In one embodiment, the first data packet may be a UBX-RXM-RAWX data packet. Furthermore, the raw data packet of moving GNSS module may comprise a first data packet and a second data packet. In one implementation, the first data packet may be a UBX-RXM-RAWX data packet, and the second data packet may be a UBX-NAV-POSLLH data packet.
In one embodiment, the control and storage unit (103) may be configured to receive and store the one or more raw data packets from the GNSS module (101). Further, the control and storage unit (103) may be configured to continuously receive the raw data packet from the one or more raw data packets at predefined intervals. Furthermore, the control and storage unit (103) may be configured to convert the one or more raw data packets into a raw data file.
In another embodiment, the OBS QC tool (104) may be configured to receive the raw data file from the control and storage unit (103). The OBS QC tool (104) may be equipped for checking quality of the raw data file. In one implementation, the OBS QC tool (104) may be configured to examine the plurality data quality indicators simultaneously, such concurrent assessment enhances confidence in determining whether the quality of the data is good (or satisfactory) or bad (or unsatisfactory).
In another implementation, each data quality indicator of the plurality of data quality indicators, may be checked/examined for each satellite from the plurality of satellites (102a, 102b, 102c, 102d, 102e). In one implementation, the data from the said satellite may be marked as good data if all the data quality indicators of that particular satellite points are validated as good data, otherwise it may be marked as bad data. In yet another implementation, based on the assessment, the OBS QC tool (104) discerns the overall data quality and communicates/informs the acceptability of the data to a user. The user may be associated with the system (100).
In another embodiment, the OBS QC tool (104) may be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, cloud infrastructure and the like.
In yet another implementation, the said raw data file may be retrieved from an Unmanned Aerial vehicle (UAV). In another implementation, the system (100) may be configured to check the quality of an Observational (OBS) file from the UAV.
Referring to figure 2, the OBS QC tool (104) and components of the OBS QC tool (104) is illustrated, in accordance with an embodiment of the present subject matter.
In one embodiment, the OBS QC tool (104) may include at least one processor (201), an input/output (I/O) interface (202), and a memory (203). The at least one processor (201) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions or the like. Among other capabilities, at least one processor (201) is configured to fetch and execute computer-readable instructions stored in the memory (203).
In another embodiment, the I/O interface (202) may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface (202) may allow the OBS QC tool (104) to interact with a user directly. Further, the I/O interface (202) may enable the OBS QC tool (104) to communicate with other computing devices, such as web servers and external data servers (not shown), cloud. The I/O interface (202) can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface (202) may include one or more ports for connecting a number of devices to one another or to another server.
In yet another embodiment, the memory (203) may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, magnetic tapes, and the like. The memory (203) may include modules (204) and data (206).
In one embodiment, the data (206), comprises repository (207) and other data (208). In another embodiment, the data (206) amongst other things, serves as a repository for storing data unprocessed, partially processed, processed, received, or generated by one or more modules (204) and data received through I/O interface (202). In further embodiment, the other data (208) may include data generated as a result of the execution of one or more modules (204).
In another embodiment, the modules (204) include routines, programs, objects, components, data structures, etc., which performs particular task, functions or implement particular abstract data types. In one implementation, the modules (204) may include a processing module (205). The processing module (205) may be configured to receive a plurality of user configuration parameters from the user associated with the OBS QC tool (104).
In one embodiment, the OBS QC tool (104) may be configured to receive a plurality of configuration parameters from the user associated with the OBS QC tool (104). In another implementation, the plurality of configuration parameters may be used as a threshold to validate the plurality of data quality indicators of the raw data file.
In another embodiment, the processing module (205) may be configured to process the data (206) for performing validation of the data (206) based on the plurality of the user configuration parameters. Furthermore, the processing module (205) may be configured to provide an output based on the validation of the data (206) based on the plurality of data quality indicators and/or the plurality of user configuration parameters.
In yet another embodiment, the plurality of user configuration parameters may comprise of Satellite Count, Signal to Noise Ratio (SNR), Skip data point, QC Data Quantity, Flying Height, Data Interval, and the like as a configuration parameter.
In one embodiment, the user configuration parameter is satellite count. The satellite count is indicative of the minimum number of satellites with the good data required by the GNSS module (101) to estimate position of the GNSS module (101).
Referring to figure 4, the satellite count using representation of data points available from each satellite for multiple time instances is illustrated, in accordance with the embodiment of the present disclosure. A y- axis (401) represents a plurality of satellites (401a, 401b, 401c, 401d, 401e, 401f) and a x- axis represents time instances (t1, t2, t3, t4, t5, t6, t7). In one embodiment, good data point and bad points may be indicated in different colours. In figure 4, good data points are indicated in “gray” colour and bad data points are indicated in “black” colour. Ideally, GNSS module/receiver may require atleast 4 satellites to estimate its position. In one exemplary embodiment, if the user receives good data from more than 4 satellites, then the computed position is improved. If the user wants to increase or decrease the satellite count, then it can be configured and an OBS QC tool will use this to perform quality check (QC). At any time instance, if there are minimum ‘n’ satellites with good data points then time instant is marked as good or else it is marked as bad.
The figure 4 shows the data points available from each satellite. Each satellite (401a, 401b, 401c, 401d, 401e, 401f) may provide 7 data points in which both good data point indicated in “gray” color and bad point indicated in “black” color, respectively. The user may set threshold value for number of satellites with good points. In one case scenario, if the user requires, at any instance of time, threshold value for number of satellites “five satellites” with good data points. Then, the OBS QC tool (104) may be configured to mark time instant t1 and time instant t5 as bad as t1 and t5 having less than five satellites with good data points. The same process is followed for the entire data set. Further, the input file is marked acceptable if the number of good time instant is above the set threshold or else the file is marked rejected.
In one embodiment, user configuration parameter is signal to noise ratio (SNR). The Signal to Noise Ratio (SNR) is indicative of the quality of signal measured by the GNSS module (101) for a satellite of the plurality of the satellites. The quality of signal is measured by the GNSS module (101) for each satellite of the plurality of satellites. High SNR indicates better data quality. Low SNR indicates more noise in the signal. Noise introduced in the signal may lead to position inaccuracies. The user may set the threshold value of the SNR in the OBS QC tool and if the SNR of any satellite is below the set threshold value, then the data point may be marked as bad data point.
In another embodiment, user configuration parameter is skip data point. The skip data point is indicative of number of satellite data points to be skipped by the OBS QC tool (104) from the point a bad data is detected.
Referring to figure 5, the skip data point available from each satellite for multiple time instances is illustrated, in accordance with the embodiment of the present disclosure. The x-axis represents time in msec (t0, t0+200, t0+400, t0+600, t0+800, t0+1000, t0+1200) which presents periodic data, at 5Hz, from a satellite. A total of ‘n’ number of satellite data points can be skipped by the OBS QC tool, from the point a bad data is detected in the data set. The user provides the “time” for which the data points should not be considered or skipped. In one exemplary embodiment, the user wants to skip data point for one second from the time a bad data is detected, the OBS QC tool then skip one second data. When a bad data is encountered at point (t0), the five data points for time (t0+200, t0+400, t0+600, t0+800, t0+1000) received within the data point (t0) are not considered for QC. From data point (t0+1200), data is considered for Quality Check. If the data point number (t0+1200) is also marked bad then again, the next 5 data points will not be skipped.
In yet another embodiment, the user configuration parameter is QC Data Quantity. The QC Data Quantity is indicative of a start and stop the QC process. The OBS QC tool (104) is configured for receiving a message comprising the Latitude, Longitude and Height information along with the vertical and horizontal accuracy values which are estimated by the GNSS module (101). The OBS QC tool (104) is further configured for identifying a valid data packet using the vertical and horizontal accuracy values. The OBS QC tool (104) is further configured for detecting the ground based on the valid data packet. The OBS QC tool (104) is further configured for checking for change in height parameter to start the QC process. The OBS QC tool (104) is further configured for starting of QC process from a predetermined distance until the drone is about to land. The said QC process comprises landing using current height and latitude and longitude recorded on the ground before the take-of. If latitude-longitude determined for current and the ground has a difference of less than a threshold value and height is below a predefined value then detecting of landing and stopping of the QC process.
Referring to figure 6, the graphical representation of QC Data Quantity is illustrated, in accordance with the embodiment of the present disclosure. In an exemplary embodiment, the x-axis represents height and horizontal axis represents time. Figure 6, illustrates start point and stop point of the moving object such as drone. The GNSS module may be mounted on a stationary or moving object, like a drone. For this configuration, the raw data file provided by the user may contain UBX-NAV-POSLLH packet. In one exemplary embodiment, the drone may be configured to follow the flying pattern as represented in figure 6. At initial step, the drone was at the ground. Then it took-off and attained a height at which it flew and later landed back at the same point from where it took-off. The start point and stop point represent the points where the quality check will start and stop. Further, the UBX-NAV-POSLLH packet message contains the Latitude Longitude-Height information along with the vertical and horizontal accuracies which are estimated by the GNSS module. Firstly, the OBS QC tool may be configured to detect the ground by a valid data packet. Vertical and horizontal accuracy values may be used to identify the valid packet. Once ground is detected, the tool may record the Latitude-Longitude-Height of that instant. After this the tool may check for change in height parameter to start the QC process. Once the drone reaches ‘x’ meters from the ground, the QC process may start until the drone is about to land. To detect the landing, the OBS QC tool may use the current drone height along with the latitude-longitude which was recorded on the ground before take-off. If the current and the ground recorded latitude-longitude has a difference of less than 20 meters and the drone height is below ‘x’ meter than tool will detect landing and stop the QC.
In one embodiment, user configuration parameter is the flying height. The Flying Height is indicative of the height at which the QC starts and stops. If the drone data quality check (QC) must be done, the user may provide a flying height from where the quality check must start and stop.
In another embodiment, user configuration parameter is data interval. The Data Interval is indicative of the reference rate for configuration of data received from the GNSS module (101), logging the data in the raw file, and identifying the presence of any missing packet. Data Interval may be defined as the rate at which the GNSS module provides data can be configured. Based on the rate the data may be logged in the raw file. The user may provide this rate to the tool to use it as reference. The OBS QC tool may use this value to know if all messages are received at the configured rate. It may also identify if there is any missing packet or not.
The OBS QC tool (104) may be configured to receive the above-mentioned user configuration parameter fed by the user. The parameters may act as a threshold for comparing the raw data packets during validation process. If the data captured by the GNSS module/ receiver is not in the range of these parameters, then the data at that instant is marked bad.
In one embodiment, the plurality of data quality indicators may comprise of Carrier Phase Validity and Lock Time, Half-Cycle Validity, Half-Cycle Subtracted from Phase, Carrier Signal to Noise Ratio (SNR), Data Gap, and the like as a data quality indicators.
In another embodiment, carrier Phase Validity and Lock Time is the data quality indicator. The Carrier Phase Validity and Lock Time is indicative of lock status of GNSS module (101) to the satellite. The GNSS module (101) is configured for determining distance between the satellite and GNSS module (101). The GNSS module (101) is further configured for locking or unlocking of the GNSS module (101) to the satellite. The OBS QC tool (104) is configured for checking a cycle slip, and marking the data points based on presence or absence of the cycle slip. The OBS QC tool (104) is configured for marking the data point as bad data point when carrier phase validity is set to “0” and lock time is equal to “0” mSec based on the presence of cycle slip. The OBS QC tool (104) is also configured for marking the data point as good data point when carrier phase validity is set to “1” and lock time is greater than “0” mSec based on the absence of cycle slip.
In an exemplary embodiment, the GNSS module (101) may estimate its position based on the distance between the plurality of satellites and the GNSS module/receiver. The distance may be expressed as an integer number of carrier cycles between the GNSS module and the satellite. It is called the carrier phase measurement.
Referring to figure 7, a representation (700) of Carrier Phase measurement as the data quality indicator is illustrated, in accordance with the embodiment of the present disclosure. The distance (703) between the satellite (701) and the GNSS module/receiver (702) is called carrier phase measurement. Further, the GNSS module may be configured to know the signal frequency. Further GNSS module may calculate the wavelength of each cycle and multiply it with the number of cycles between the satellite and the module to get the distance. Further, the module may get locked to a satellite once it measures the number of carrier phase cycles. The module may further indicate the lock status using the carrier phase validity bit (set to 1) and lock time (greater than 0 m-Sec) available in the data packet. Further, the GNSS module/receiver may lose lock with a satellite if it is not able to measure the carrier phase cycles. This is also called cycle slip. The OBS QC tool may check for a cycle slip and mark the data points as bad if carrier phase validity bit is set to 0 and lock time is equal to 0 m-Sec.
In another embodiment, half-cycle-validity is the data quality indicator. The Half-Cycle-Validity data quality indicator is indicative of presence or absence of half-Carrier phase cycle, via the OBS QC tool (104). The OBS QC tool (104) marks the data point as good data point when the Half-Cycle-Validity bit is 1. The Half-Cycle-Validity is set to '1' when the half cycle ambiguity is resolved. The OBS QC tool (104) marks the data point as bad when the Half-Cycle-Validity is '0', signifying that the receiver was unable to half-cycle the carrier.
In yet another embodiment, half-cycle-subtracted from Phase is the data quality indicator. The Half-Cycle-Subtracted from Phase is indicative of the altered measurement of the carrier phase cycle by a half-cycle. The GNSS module is configured for setting a flag of the half-Cycle-Subtracted from phase bit to ‘1’ when issue is fixed or corrected. The OBS QC tool (104) is configured for detecting the occurrence of cycle slip based on the set flag.
In an exemplary embodiment, the half-cycle-subtracted from Phase indicates the GNSS module/receiver has altered the measurement by a half-cycle to reflect that the tracking engine knows it's looking at the anti-phase. It only flags that it has fixed/corrected the issue. The receiver information that it has fixed/corrected this issue in the data packet message by setting the half-Cycle-Subtracted from phase bit to ‘1’. The OBS QC tool may use this flag to detect the occurrence of cycle slip.
In yet another embodiment, Carrier Signal-to-Noise Ratio (SNR) is the data quality indicator. The Carrier Signal to Noise Ratio (SNR) is indicative of the noise present in the carrier signal. The GNSS module (101) is configured for tracking the satellite. The GNSS module (101) is further configured for providing the carrier signal power of the tracked satellite. The OBS QC tool (104) is configured for receiving the carrier signal power from GNSS module (101). The OBS QC tool (104) is further configured for comparing the carrier signal power with a threshold value of Signal to noise ratio (SNR). The OBS QC tool (104) is further configured for marking the data points based on the comparison. If the carrier signal power is above the threshold value, then marking the data point as good data point. If the carrier signal power is below the threshold value, then marking the data point as bad data point.
In an exemplary embodiment, the GNSS module/receiver provides the signal power of the tracked satellite. Low SNR indicates more noise in the carrier signal. Since a carrier signal is used to estimate the distance between the receiver and the satellite through carrier phase measurement, noise introduced in the signal will lead to position inaccuracies. Users can set the minimum required SNR in the tool and if the SNR of any satellite is below the set limit, then the data point is marked bad.
In yet another embodiment, data gap is the data quality indicator. The Data Gap quality indicator is indicative presence or absence of the data gap in the raw data file. The GNSS module (101) is configured for tracking the plurality of satellites. The GNSS module (101) is further configured for providing messages or the raw data file, comprising data of the plurality of satellites, to the OBS QC tool (104). The OBS QC tool (104) is configured for receiving messages from the GNSS module (101). The OBS QC tool (104) is further configured for determining the message rate using data interval parameter. The OBS QC tool (104) is further configured for determining the time difference between each message or raw data packet of the raw data file using time parameter. The OBS QC tool (104) is further configured for identifying the presence or absence of the data gap based upon message rate and the time difference between each message or raw packet of the raw data file.
Referring to figure 8, a representation of Data Gap as the data quality indicator is illustrated, in accordance with the embodiment of the present disclosure. The y- axis (801) indicates the point (801a, 801b, 801c, 801d, 801e, 801f) that represents the plurality of satellites and x- axis (802) indicates the time instances (T0, T1, T3, T4, T5, T6, T7). The data point (803a) represents good data point, the data point (803b) represents bad data point and the data point (803c) represent the point with no data availability.
In an exemplary embodiment, the UBX-RXM-RAWX raw data packet message provides data of all the satellites which it tracks. If, in case, the receiver does not provide the message or the message is delayed or message is not saved, no data will be available for that instant. If, for the time instant (T3-T6) no data is available from any satellite. Then, the OBS QC tool may be configured to use the data interval parameter to know the message rate and based on that it identifies if there is a data gap present or not. The time parameter in the UBX-RXM-RAWX raw data packet is used to know the time difference between each packet.
In one embodiment, the OBS QC tool (104) may provide a text file as output. The output comprises of individual satellite name, overall good and bad data points, overall good and bad data percentage, reason for accepting or rejecting, flying data of the moving GNSS module and cumulative data gap of the raw data file.
In another embodiment, the flying data of the moving GNSS module comprises of ground time, the ground time is indicative of time the GNSS module was on ground before flying. The flying data of the moving GNSS module further comprises of data points recorded on the ground. The flying data of the moving GNSS module further comprises of flight time, the flight time is indicative of duration of GNSS module flight. The flying data of the moving GNSS module further comprises of data points recorded during flight. The flying data of the moving GNSS module further comprises of land time, the land time is indicative of time elapsed after GNSS module landing before data recording stopped. The flying data of the moving GNSS module further comprises of data points recorded after landing.
In another non-limiting embodiment of the present disclosure, a method (300) for data validation has been disclosed.
Referring to figure 3, a method (300) for data validation is illustrated, in accordance with an embodiment of the present subject matter.
At step (301), the global navigation satellite system (GNSS) module (101) may receive a plurality of signal from a plurality of satellites to form one or more raw data packets. The one or more raw data packets may comprise the distance between the GNSS module (101) and the plurality of satellites (102a, 102b, 102c, 102 d, 102 e), and the plurality of data quality indicators of each satellite of the plurality of satellites.
At step (302), the control and storage unit (103) may be configured for receiving and storing the one or more raw data packets and convert the plurality of raw data packets into a raw data file. The control and storage unit (103) may be configured to store the one or more raw data packets received from the GNSS module (101) till the time it is turned off.
At step (303), the observation quality check (OBS QC) tool (104) may be configured for receiving the raw data file.
At step (304), the (OBS QC) tool (104) may be configured for receiving a plurality of configuration parameter from a user associated with the OBS QC tool (104).
At step (305), the (OBS QC) tool (104) may be configured for processing (305) the raw data file for performing validation of the one or more raw data packets based on the plurality of configuration parameters.
At step (306), the (OBS QC) tool (104) may be configured for providing an output based on the validity of the one or more raw data packets.
In one embodiment, the raw file may contain the UBX-RXM-RAWX and the UBX-NAV-POSLLH raw data package message. In one embodiment, the UBX-RXM-RAWX and the UBX-NAV-POSLLH raw data packet message may be used to perform the quality check (QC). The UBX-RXM-RAWX packet contains a data quality indicator along with the user configuration to mark the data point as good or bad. In an exemplary embodiment, the raw data file may contain the UAV flight data files.
In one exemplary embodiment, if there are at least 4 satellites which provide good quality data then, that time instant may be marked good (accepted) else it may be marked bad (rejected). The same process may be followed for the entire data set. Further, the raw data file may be marked acceptable if the number of good time instant is above the set threshold else, the file may be marked as rejected. Furthermore, the output may be generated in the form of a result file, in which the entire data summary may be mentioned and also the reason for bad data if the file is rejected.
In one embodiment, if the GNSS module (101) is a moving GNSS module then the output may comprise of ground time (time for which the drone was on the ground before flying), data points recorded on ground, Flight time(how long was the drone flying), data points recorded during flight, Land time(after how much time the data recording was stopped after drone landed) and data points recorded after landing, and cumulative data gap, if any.
The presently disclosed system and method for data validation may have the following advantageous functionalities on the conventional art:
? Provides data accuracy, data cleanness, and data completeness by eliminating data errors and ensuring the data is not corrupted.
? Adjustable user configuration parameters.
? Provides precise data at any instance.
? Provides an efficient workflow.
? The quality of data is assured good.
Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure is not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
The foregoing description shall be interpreted as illustrative and not in any limiting sense. A person of ordinary skill in the art would understand that certain modifications could come within the scope of this disclosure.
The embodiments, examples and alternatives of the preceding paragraphs or the description and drawings, including any of their various aspects or respective individual features, may be taken independently or in any combination. Features described in connection with one embodiment are applicable to all embodiments unless such features are incompatible.
,CLAIMS:WE CLAIM:
1. A system (100) for data validation comprising:
a global navigation satellite system (GNSS) module (101) configured to receive a plurality of signals from a plurality of satellites to form one or more raw data packets,
a control and storage unit (103) configured to receive and store the plurality of raw data packets, and to convert the plurality of raw data packets into a raw data file;
an observation quality check (OBS QC) tool (104) configured for:
receiving the raw data file from the control and storage unit (103);
receiving a plurality of configuration parameters from a user associated with the OBS QC tool (104);
processing the raw data file for determining a validity of one or more raw data packets based on the plurality of configuration parameters;
providing an output based on the validity of the one or more raw data packets.
2. The system (100) as claimed in claim 1, wherein each raw data packet of one or more raw data packets comprises a plurality of data quality indicators of each satellite from the plurality of satellites.
3. The system (100) as claimed in claim 1, wherein the plurality of data quality indicators comprises an error in the distance between each satellite of the plurality of satellites and the GNSS module (101).
4. The system (100) as claimed in claim 1, wherein the GNSS module (101) is at least one of a stationary GNSS module or a moving GNSS module.
5. The system (100) as claimed in claim 4, wherein the raw data file of the stationary GNSS module comprises of a first data packet.
6. The system (100) as claimed in claim 4, wherein the raw data file of the moving GNSS module comprises of the first data packet and a second data packet.
7. The system (100) as claimed in claim 1, wherein the OBS QC tool (104) is configured to set the plurality of configuration parameters as a threshold to validate the plurality of data quality indicators.
8. The system (100) as claimed in claim 2, wherein the plurality of data quality indicators comprises Carrier Phase Validity and Lock Time, Half-Cycle Validity, Half-Cycle Subtracted from Phase, Carrier Signal to Noise Ratio (SNR), and Data Gap.
9. The system (100) as claimed in claim 8, wherein the Carrier Phase Validity and Lock Time is indicative of lock status of GNSS module (101) to the satellite,
wherein the GNSS module (101) is configured for:
determining distance between the satellite and GNSS module (101),
locking or unlocking of the GNSS module (101) to the satellite;
wherein the OBS QC tool (104) is configured for:
checking a cycle slip, and
marking the data points based on presence or absence of the cycle slip.
10. The system as claimed in claim 9, wherein the OBS QC tool is configured for:
marking the data point as bad data point when carrier phase validity bit is set to “0” and lock time is equal to “0” mSec based on the presence of cycle slip; or
marking the data point as good data point when carrier phase validity bit is set to “1” and lock time is greater than “0” mSec based on the absence of cycle slip.
11. The system (100) as claimed in claim 8, wherein the Half-Cycle-Validity data quality indicator is indicative of presence or absence of half-Carrier phase cycle, wherein the OBS QC tool (104) configured for:
marking the data point as good data point when the half cycle validity bit received from the GNSS module (101) is '1', or
marking the data point as bad data point when the Half-Cycle-Validity bit received from the GNSS module (101) is '0'.
12. The system (100) as claimed in claim 8, wherein Half-Cycle-Subtracted from Phase is indicative of the altered measurement of the carrier phase cycle by a half-cycle,
wherein the GNSS module (101) is configured for:
setting a flag of the half-Cycle-Subtracted from phase bit to ‘1’ when issue is fixed or corrected;
wherein the OBS QC tool (104) is configured for:
detecting the occurrence of cycle slip based on the set flag.
13. The system (100) as claimed in claim 8, wherein the Carrier Signal to Noise Ratio (SNR) is indicative of the noise present in the carrier signal,
wherein the GNSS module (101) is configured for:
tracking the satellite;
providing the carrier signal power of the tracked satellite;
wherein the OBS QC tool (104) is configured for:
receiving the carrier signal power from GNSS module (101),
comparing the carrier signal power with a threshold value of Signal to noise ratio (SNR);
marking the data points based on the comparison.
14. The system (100) as claimed in claim 13, wherein the OBS QC tool (104) is configured for:
marking the data point as good data point if the carrier signal power is above the threshold value; or
marking the data point as bad data point when the carrier signal power is below the threshold value.
15. The system (100) as claimed in claim 8, wherein the Data Gap quality indicator is indicative of presence or absence of a data gap in the raw data file,
wherein the GNSS module (101) is configured for:
tracking the plurality of satellites;
providing messages or the raw data file, comprising data of the plurality of satellites, to the OBS QC tool (104);
wherein the OBS QC tool (104) is configured for:
receiving messages from the GNSS module (101);
determining the message rate using data interval parameter;
determining the time difference between each message or raw packet of the raw data file using time parameter;
identifying the presence or absence of the data gap based upon message rate and the time difference between each message or raw packet of the raw data file.
16. The system (100) as claimed in claim 1, wherein the plurality of configuration parameters comprises Satellite Count, Signal to Noise Ratio (SNR), Skip data point, QC Data Quantity, Flying Height, and Data Interval.
17. The system (100) as claimed in claim 16, wherein the Satellite Count is indicative of the minimum number of satellites with the good data points required by the GNSS module (101) to estimate position of the GNSS module (101).
18. The system (100) as claimed in claim 16, wherein the Signal to Noise Ratio (SNR) is indicative of the quality of signal measured by the GNSS module (101) for a satellite of the plurality of the satellites.
19. The system (100) as claimed in claim 16, wherein the skip data point is indicative of number of satellite data points to be skipped by the OBS QC tool (104) from the point a bad data is detected.
20. The system (100) as claimed in claim 16, wherein the QC Data Quantity is indicative of a start and stop the QC process, wherein OBS QC tool (104) is configured for:
receiving a message comprising the Latitude, Longitude and Height information along with the vertical and horizontal accuracy values which are estimated by the GNSS module (101);
identifying a valid data packet using the vertical and horizontal accuracy values;
detecting the ground based on the valid data packet;
checking for change in height parameter to start the QC process;
starting of QC process when the moving GNSS module (101) reaches on a predetermined distance above the ground.
21. The system as claimed in claim 20, wherein the QC process comprises landing using current height and latitude and longitude recorded on the ground before the take-off of the GNSS module (101);
wherein if latitude-longitude determined for current and the ground has a difference of less than a threshold value and height is below a predefined value then detecting of landing and stopping of the QC process.
22. The system (100) as claimed in claim 16, wherein the Data Interval is indicative of the reference rate for configuration of data received from the GNSS module (101), logging the data in the raw file, and identifying the presence of any missing packet.
23. The system (100) as claimed in claim 16, wherein the Flying Height is indicative of the height at which the QC process starts and stops.
24. The system (100) as claimed in claim 1, wherein the output comprises of individual satellite name, overall good and bad data points, overall good and bad data percentage, reason for accepting or rejecting, flying data of the moving GNSS module (101) and cumulative data gap of the raw data file.
25. A method (300) for data validation, wherein the method (300) comprising:
receiving (301), via a global navigation satellite system (GNSS) module (101), a plurality of signal from a plurality of satellites to form one or more raw data packets;
receiving and storing (302), via a control and storage unit (103), the one or more raw data packets to convert the one or more raw data packets into a raw data file;
receiving (303), via an observation quality check (OBS QC) tool (104), the raw data file;
receiving (304), via the OBS QC tool (104), a plurality of configuration parameter from a user associated with the OBS QC tool (104);
processing (305), via an OBS QC tool (104), the raw data file for determining a validity of the one or more raw data packets based on the plurality of configuration parameters;
providing (306), via the OBS QC tool (104), an output based on the validity of the one or more raw data packets.
26. The method (300) as claimed in claim 25, wherein each raw data packet of one or more raw data packets comprises a plurality of data quality indicators of each satellite from the plurality of satellites.
27. The method (300) as claimed in claim 25, wherein the plurality of raw data quality indicators comprises an error in the distance between each satellite of the plurality of satellites and the GNSS module (101).
28. The method (300) as claimed in claim 25, comprises a step for setting, via the OBS QC tool, the plurality of configuration parameters as a threshold to validate the plurality of data quality indicators.
29. The method (300) as claimed in claim 25, wherein the plurality of data quality indicators comprises Carrier Phase Validity and Lock Time, Half-Cycle Validity, Half-Cycle Subtracted from Phase, Carrier Signal to Noise Ratio (SNR), and Data Gap.
30. The method (100) as claimed in claim 29, wherein the Carrier Phase Validity and Lock Time is indicative of lock status of GNSS module (101) to the satellite, wherein
determining, via the GNSS module (101), distance between the satellite and the GNSS module (101),
locking or unlocking, via the GNSS module (101), the GNSS module (101) to the satellite;;
checking, via OBS QC tool (104); and
marking, via the OBS QC tool (104), the data points based on presence or absence of the cycle slip.
31. The method (100) as claimed in claim 30, comprising:
marking, via the OBS QC tool (104), the data point as bad data point when carrier phase validity is set to “0” and lock time is equal to “0” mSec based on the presence of cycle slip; or
marking, via the OBS QC tool (104), the data point as good data point when carrier phase validity is set to “1” and lock time is greater than “0” mSec based on the absence of cycle slip.
32. The method (300) as claimed in claim 29, wherein the Half-Cycle-Validity data quality indicator is indicative of presence or absence of half-Carrier phase cycle, wherein
marking, via the OBS QC tool (104), the data point as good data point when the half cycle validity bit received from the GNSS module (101) is 1; or
marking, via the OBS QC tool (104), the data point as bad when the Half-Cycle-Validity bit received from the GNSS module (101) is '0'.
33. The method (300) as claimed in claim 29, wherein Half-Cycle-Subtracted from Phase is indicative of the altered measurement of the carrier phase cycle by a half-cycle, wherein
setting, via the GNSS module (101), a flag of the half-Cycle-Subtracted from phase bit to ‘1’when issue is fixed or corrected;
detecting, via the OBS QC tool (104), the occurrence of cycle slip based on the set flag.
34. The method (300) as claimed in claim 29, wherein the Carrier Signal to Noise Ratio (SNR) is indicative of the noise present in the carrier signal, wherein
tracking, via the GNSS module (101), the satellite;
providing, via the GNSS module (101), the carrier signal power of the tracked satellite;
receiving, via the OBS QC tool (104), the carrier signal power from GNSS module (101);
comparing, via the OBS QC tool (104), the carrier signal power with a threshold value of Signal to noise ratio (SNR);
35. The method (300) as claimed in claim 34, wherein
marking, via the OBS QC tool (104), the data points as a good data point when the carrier signal power is above the threshold value;
marking, via the OBS QC tool (104), the data point as bad data point when the carrier signal power is below the threshold value.
36. The method (300) as claimed in claim 29, wherein the Data Gap quality indicator is indicative of presence or absence of a data gap in the raw data file, wherein
tracking, via the GNSS module (101), the plurality of satellites;
providing, via the GNSS module (101), messages or the raw data file comprising data of the plurality of satellites to the OBS QC tool (104);
receiving, via the OBS QC tool (104), messages or the raw data file from the GNSS module (101);
determining, via the OBS QC tool (104), the message rate using data interval parameter;
determining, via the OBS QC tool (104), the time difference between each message or raw data packet of the raw data file using time parameter;
identifying, via the OBS QC tool (104), the presence or absence of the data gap based upon message rate and the time difference between each message or raw data packet of the raw data file.
37. The method (300) as claimed in claim 25, wherein the plurality of configuration parameter comprises Satellite Count, Signal to Noise Ratio (SNR), Skip data point, QC Data Quantity, Flying Height, and Data Interval.
38. The method (300) as claimed in claim 37, wherein the Satellite Count is indicative of the minimum number of satellites with the good data required by the GNSS module (101) to estimate position of the GNSS module (101).
39. The method (300) as claimed in claim 37, wherein the Signal to Noise Ratio (SNR) is indicative of the quality of signal measured by the GNSS module (101) for a satellite of the plurality of the satellites.
40. The method (300) as claimed in claim 37, wherein the skip data point is indicative of number of satellite data points to be skipped by the OBS QC tool (104) from the point a bad data is detected.
41. The method (300) as claimed in claim 37, wherein the QC Data Quantity is indicative of a start and stop the QC process, wherein
receiving, via the OBS QC tool (104), a message comprising the Latitude, Longitude and Height information along with the vertical and horizontal accuracy values which are estimated by the GNSS module (101);
identifying, via the OBS QC tool (104), a valid data packet using the vertical and horizontal accuracy values;
Detecting, via the OBS QC tool (104), the ground based on the valid data packet;
Checking, via the OBS QC tool (104), change in height parameter to start the QC process;
Starting, via the OBS QC tool (104), QC process when the moving GNSS module (101) reaches on a predetermined distance above the ground.
42. The method as claimed in claim 41, wherein
landing, via the OBS QC tool (104), using current height and latitude and longitude recorded on the ground before the take-off of the GNSS module (101);
wherein if latitude-longitude determined for current and the ground has a difference of less than a threshold value and height is below a predefined value then detecting landing; and
stopping, via the OBS QC tool (104), the QC process.
43. The method (300) as claimed in claim 37, wherein the Data Interval is indicative of the reference rate for configuration of data received from the GNSS module (101), logging the data in the raw file, and identifying the presence of any missing packet.
44. The method (100) as claimed in claim 37, wherein the Flying Height is indicative of the height at which the QC starts and stops.
45. The method (300) as claimed in claim 25, wherein the output comprises of individual satellite name, overall good and bad data points, overall good and bad data percentage, reason for accepting or rejecting, flying data of moving GNSS module, and cumulative data gap of the raw data file.
Dated this 01st Day of December 2022

Priyank Gupta
Agent for the Applicant
IN/PA-1454