Isomorphic cloud data transfer from locator

Abstract

According to some embodiments, an underground pipeline locator system is presented. According to some embodiments, a subterranean pipeline locator system comprises: a locator comprising an array of spaced apart low frequency magnetic sensors that receive signals, the signals comprising magnetic signals emanating from a subterranean cable or pipeline; and a communication system providing communication with a cloud-based platform that receives and stores data including signals, where the data transmission is an isomorphic data transmission. In some embodiments, the communication system is a WiFi system.

Description

[0001] Related applications

[0002] This application claims the benefits of U.S. non-provisional application 18 / 632,649, filed April 11, 2024, and U.S. provisional application 63 / 496,164, filed April 14, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] Embodiments of the present invention relate to the location of underground pipelines, and more specifically, to an underground locator having network-based homogeneous cloud data transmission. Background Technology

[0004] The process of locating underground utilities (pipes and cables) using low-frequency signals is well-known and widely adopted as operational practice. Pipeline locators typically consist of an array of spaced-apart antennas that receive time-varying magnetic field signals generated by the underground utility itself. These signals can be the result of a current coupled to the underground utility by a separate transmitter, or they can be inherent to the utility (e.g., from power lines). The array of spaced-apart antennas in the pipeline locator receiver receives the magnetic fields from the underground pipeline, which typically have a specific frequency. Processing electronics in the pipeline locator receiver determine the relative position of the utility to the pipeline locator system based on the signals associated with the magnetic field, including depth, signal current, and other information. For example, the horizontal position and depth of the underground utility relative to the pipeline locator receiver can then be displayed to the user, and in some systems, the position relative to the pipeline locator receiver can also be recorded.

[0005] Recent developments in the utility industry place a great emphasis on recording data to cloud-based network servers and databases. Such data can be used for a variety of collaborative reasons and made available for analysis by multiple users. These reasons can include, for example, the creation of digital maps of underground utilities, post-mapping analysis, due diligence proofing, and evaluation of positioning process data for training purposes. The creation of digital maps includes the creation of maps showing the location of underground utilities relative to a defined geospatial grid reference. The current standard for geographically-based mapping is WGS84, a geocentric coordinate system used in geocentric navigation. Recent developments in satellite positioning systems (Global Navigation Satellite Systems (GNSS)) have helped to bring Global Positioning Satellite (GPS) receivers to a positional accuracy of just a few centimetres. Such receivers can be fixed to underground pipeline positioning receivers to help with the geolocation of the underground pipeline locators. Enhanced positioning (e.g. Real Time Kinematic (RTK)) can be used in conjunction with geospatial information and enhance the positional accuracy of underground pipeline positioning receivers in real time - truly "kinematic" positioning with horizontal accuracy of ±10 cm RMS or lower (e.g. ±1 cm RMS), and thus locate underground pipelines.

[0006] Once a digital map of underground utilities is uploaded, post-mapping analysis can be performed to evaluate and improve the map data. In some cases, such analysis can suggest further site investigation to improve the digital map, or suggest that further data be acquired to better determine the location of underground utilities.

[0007] Another reason for uploading map data is that it provides proof of due diligence. Typically, a work order system will be implemented that instructs an operator to locate underground pipelines within a particular geographic area. The uploaded map data can be used to determine whether the work order has been properly completed. Thus, map data can be used to determine whether the correct type and procedure of investigation has been performed at the defined geographic location of the work order.

[0008] Additionally, map data can also be used for evaluation purposes for training. An evaluation of the locator's inertial sensor data can be performed that checks that the locator is held and moved within the best recommended set of parameters. This data can be used to provide feedback to the operator to improve the positioning process, or to reject data acquired when the positioning receiver was not properly operated.

[0009] In any of these purposes, it is necessary to perform the uploading of data from the positioning receiver to the cloud-based server in a timely manner. Thus, there is a need to develop a system for transmitting methods for sending data to or exchanging data with cloud-based network servers and databases. SUMMARY

[0010] According to some embodiments, a subsurface pipeline locator system is presented. According to some embodiments, the subsurface pipeline locator system comprises a locator comprising an array of spaced-apart low-frequency magnetic sensors that receive a signal comprising a magnetic signal from a subsurface cable or pipeline, and a communication system that provides communication with a cloud-based platform that receives and stores data including the signal, wherein the data transmission is a homogeneous data transmission. In some embodiments, the communication system is a WiFi system. In some embodiments, the communication system comprises a mobile device that communicates with the locator and provides WiFi connectivity to the cloud-based platform. In some embodiments, the locator comprises a real-time kinematic GNSS system for position location of the earth's surface. In some embodiments, the locator receives RTK correction data from a ground-based station, or alternatively GNSS corrections. In some embodiments, the locator communicates with a cloud network server comprising an Internet of Things (IOT) platform. In some embodiments, the communication system uses an attribute-value pair format for data exchange. In some embodiments, the communication system can comprise a smartphone that communicates with the locator.

[0011] In some embodiments, a method of transmitting data from a pipeline location receiver comprises acquiring data, determining a location vector from the data, determining homogeneous data from the location vector, and transmitting the homogeneous data. In some embodiments, transmitting the homogeneous data comprises transmitting the homogeneous data using WiFi. In some embodiments, transmitting the homogeneous data comprises transmitting the homogeneous data to a mobile device. In some embodiments, acquiring the data comprises acquiring location data, operational data, and geographic position data.

[0012] In some embodiments, a location receiver is presented comprising a magnetic sensor array, a processing circuit coupled to the magnetic sensor array, a GPS antenna coupled to the processing circuit, a communication interface coupled to the processing circuit, and a memory coupled to the processing circuit storing instructions executable by the processing circuit to acquire data from the magnetic sensor array and the GPS antenna, determine a location vector from the data, determine homogeneous data from the location vector, and transmit the homogeneous data through the communication interface. In some embodiments, the location receiver comprises an inertial sensor, and wherein the instructions to acquire data further comprise instructions to acquire data from the operational sensor. In some embodiments, the communication interface comprises a WiFi interface. In some embodiments, the communication interface comprises a Bluetooth interface that homogenously transmits data to a mobile device.

[0013] These and other embodiments are discussed below with respect to the following drawings. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 A location receiver is shown in communication with a cloud-based data system.

[0015] Figure 2 An example of a positioning receiver equipped with an RTK GNSS system is shown.

[0016] Figure 3 A positioning receiver in communication with a cloud-based Internet of Things (IoT) platform is shown.

[0017] Figure 4 An implementation of providing location data to a cloud-based system according to some embodiments of the disclosure is shown.

[0018] Figure 5 A WiFi implementation of enabling TCP / IP sockets to a cloud-based IoT platform according to some embodiments of the disclosure is shown.

[0019] Figure 6 A Bluetooth-enabled complete system functionality and connectivity according to some embodiments of the disclosure is shown.

[0020] Figure 7 A positioning receiver according to some embodiments of the disclosure is shown.

[0021] Figure 8 A method of operating a positioning receiver according to some embodiments of the disclosure is shown. Figure 7

[0022] These figures and other embodiments will be discussed further below. DETAILED DESCRIPTION

[0023] In the following description, specific details are set forth to describe some embodiments of the application. However, it will be apparent to those skilled in the art that some embodiments can be practiced without some or all of these specific details. The specific embodiments disclosed herein are intended to be illustrative and not restrictive. Other elements, although not specifically described herein, can be implemented by those skilled in the art without departing from the scope and spirit of the disclosure.

[0024] This description illustrates aspects of the invention, but the embodiments should not be construed as limiting the invention as defined by the claims. Various changes can be made without departing from the spirit and scope of the description and claims. In some instances, details have not been shown or described in order not to obscure the application in unnecessary details.

[0025] ​Embodiments of the present disclosure include an overlay cloud-based data connection system that can include RTK GNSS for use with a utility cable locator (e.g., a subsurface pipeline locating receiver). Embodiments utilize one or more radio frequency (RF) communication methods, including but not limited to WiFi, Bluetooth, and cellular networks (LTE, 5G or other standard), as well as isomorphic data transfer. Embodiments include automatic data synchronization with a cloud-based network server and database. By allowing for offline data logging, issues of self-noise (which would otherwise degrade the quality of position measurements) can be managed while maintaining a cloud-based database.

[0026] Figure 1 A system 100 is shown in which a subsurface pipeline locating receiver 102 is in communication with a cloud-based network server 108. As shown, the locating receiver 102 can include a plurality of low frequency magnetic sensors 112 for the actual locating task, a standard precision GPS device, and a Bluetooth transceiver can be included in the electronics 114 of the locating receiver 102. Thus, the locating receiver 102 can communicate via Bluetooth 104 with a mobile device 106 to provide data to the cloud-based network server 108. Thus, the system 100 communicates via the mobile device 106 with the cloud-based network server 108. The mobile device 106 may, for example, operate a proprietary application that has been installed (e.g., “VMMAP” available from Vivax-Metrotech Corp). The mobile device 106 may, for example, be a cellular phone, tablet, laptop, or any other mobile communication device configured to perform the described functions.

[0027] As Figure 1 shown, the locator 102 includes magnetic sensors 112 and electronics 114. The magnetic sensors 112 can include a plurality of independent coils oriented to detect magnetic fields in particular directions. For example, the magnetic sensors 112 can include one or more 3D (or triad) coils configured to measure magnetic fields in a plurality of directions around a common point (e.g., three orthogonal axes). The electronics 114 can include all of the electronics that receive signals from the magnetic sensors 112 and process those signals. The electronics 114 can also include a user interface as well as a communication interface configured so that the locating receiver 102 can communicate with other devices as discussed. The locating receiver 102 can then detect magnetic fields emanating from subsurface pipelines and analyze those magnetic field signals to determine the location of the subsurface pipelines relative to the locating receiver 102.

[0028] Positioning data (e.g., data that can be used to locate underground utilities relative to the positioning receiver 102) as well as data related to the operation of the positioning receiver 102 (e.g., inertial data, environmental data, etc.) are generated by the positioning receiver 102. However, GNSS data can be generated from the mobile device 106 or from an internal GPS receiver that is part of the electronics 114 in the positioning receiver 102. The advantage of using a GPS receiver included in the electronics 114 of the positioning receiver 102 is that it can define the true position of the positioning receiver 102, rather than the true position of the mobile device 106.

[0029] In Figure 1 In the illustrated example, the data log with the positioning data, operational data, and GNSS data is transmitted to the mobile device 106 using the open-loop Bluetooth protocol 104. In the mobile device 106, the data is formatted and subsequently transmitted to the cloud-based web server 108. In some examples, the cloud-based web server 108 can include the Microsoft Azure flexible cloud computing platform, although other suitable computing platforms can also be used. The data recorded in the cloud-based web server 108 can be downloaded for further processing in the computer 110.

[0030] The data record generated and transmitted to the cloud-based web server 108 can be initiated by various events (e.g., user-initiated events). In some examples, an operator of the pipeline positioning receiver 102 selects a true position on the ground by pointing the tip of the positioning receiver 102 at a point directly above an underground utility. The user can then initiate the data transfer to the cloud-based server 108.

[0031] Many positioning receivers, including the positioning receiver according to embodiments of the present disclosure, transfer various types of data to a cloud-based server. Although any data format can generally be used, one useful format for data transfer and the types of data transferred are described below.

[0032] The data transferred between the positioning receiver and the cloud-based server can be formatted as a set of positioning vectors that are generated by the positioning receiver and pushed to the cloud-based server. The positioning vectors are an array of location-based data that characterizes and locates an underground utility. The positioning vectors can include, but are not limited to, a timestamp, a measured depth of the underground utility, a determination of a signal current in the measured underground pipeline, and a determined geolocation position (longitude and latitude). In some examples, the timestamp can be a data word in UNIX-style UTC format.

[0033] In addition, the localization vector can include an event log. The event log is generated by the environment, physical conditions, or physical characteristics of the operation of the localization receiver that can be detected using sensors included in the localization receiver. For example, the event log of the localization vector can include the signal-to-noise ratio of the measured magnetic signal, which gives a good indication of the quality of the accompanying data set in the localization vector. These event logs can also include, for example, information related to the motion of the localization receiver during localization (e.g., inertial sensing data), an indication of the cable position relative to the localization receiver, or problems with the received signal. Further information can include environmental conditions (temperature, humidity, etc.) that can be detected by the localization receiver.

[0034] The event log can also include data related to the motion of the localization receiver to assess the quality of the localization procedure being used. Specifically, the localization receiver can detect whether it is moving too fast, which can result in a warning that the localization receiver is operating outside of normal recommended parameters. In addition, the localization receiver can detect whether it is being held at the wrong angle, which can result in the depth and current information being affected. Additionally, the localization receiver can detect whether there is excessive swinging in the motion. Ideally, the localization receiver should move through the localization point, rather than swing through the localization point like a pendulum.

[0035] Additionally, the event log can also include information related to localized cables or other disturbances in the localization area. For example, the localization receiver can detect a shallow buried cable (i.e., a cable detected at a depth below a threshold value) and generate a warning. Overhead cables can also be detected and a warning can be generated to the user. The localization receiver can also detect signal overload, which typically occurs when the localization receiver is too close to a power transformer causing the magnetic field sensors to overload and become non-linear.

[0036] The localization vector can also include status information. The status information can be automatically generated by the localization receiver each time a new survey is started, and each time the localization receiver operating mode is changed. The status information can be used to check whether the user is following defined working practices. The status information can include, for example, the localizer operating mode, calibration verification, timing data log, or other operational information.

[0037] In many examples, the localization receiver can have multiple operating modes. For example, the localization operating modes can include a survey type mode, a power supply mode localization type, a long wave radio localization type, and an active mode localization type. The multiple operating modes can also include a calibration status indicating whether the localization receiver is within a predefined calibration period for the mode in which it is operating.

[0038] In some examples, the positioning receiver can perform calibration verification, an integrated self-test that checks the calibration accuracy of its analog and digital measurement circuitry. The raw measurements for calibration verification, along with acceptable limits, can be transmitted to a cloud-based server within the positioning vector.

[0039] Furthermore, the positioning receiver can implement timed data logging. Timed data logging can be a continuous data stream generated at a predetermined data rate (e.g., once per second). The data content can include a subset of the data defined or selected above.

[0040] Figure 2 and Figure 3 A more complex positioning system 200 is shown, which can also acquire data as described above. Figure 2 In the example shown, the location receiver 202 may be equipped with six (6) low-frequency magnetic sensors 212, a real-time kinematic (RTK) GNSS receiver 218, and a cellular LTE mobile device. The LTE device of the location receiver 202 can use the LTE device in the location receiver 202 to transmit data with the LTE cell tower 216 via the LTE protocol 204 to a cloud-based network server 222 ( Figure 3 The system transmits and receives data from the network, and simultaneously receives RTK correction data from the Maritime Service Radio Technical Committee (RTCM) network transmitted from the NTRIP broadcaster network service 206 via the Internet Protocol (NTRIP) GNSS base station 208. The LTE protocol 204 can, for example, use a TCP / IP RTCM3 (binary) stream. As shown, the NTRIP base station 208, communicating with the NTRIP network server 206, and the positioning receiver 202 (via RTK receiver 218) both communicate with the GNSS satellite array 210 to provide location information.

[0041] like Figure 3 As shown, in this application, all data logs are initially stored in a mass storage device 224 coupled to receive data from the location receiver 202. Examples of storage device 224 may include an SD card or an eMMC device. For example, the LTE network 204 may deploy a protocol buffer that allows data stored on the cloud-based server 222 and the locator data stored on the storage device 224 to be synchronized whenever the TCP / IP socket is open (i.e., when an LTE signal from tower 216 204 is present). The protocol buffer is highly scalable, allowing other data features (e.g., Firmware Over-the-Air (FOTA)) to be available and downloaded to update the location receiver 202. Other exchange formats (e.g., JavaScript Object Notation (JSON)) or any property-value pairing mechanism can also be used.

[0042] In some examples, the cloud-based server 222 can implement a Microsoft Azure Internet of Things (IoT) platform, which is a set of managed cloud services that connect, monitor, and control IoT assets. In this case, interactive communication can be conducted with the cloud-based server 222. For example, the cloud-based server 222 can use TLS 1.2 TCP / IP (HTTPS) protobuf (binary) payloads over LTE networks. Existing systems also allow for firmware over-the-air transmission (FOTA) of positioning system firmware on the positioning receiver 202.

[0043] In other applications, the data stored in the cloud-based server 222 can be used to perform subsequent surveys. For example, “backtracking” latitude and longitude coordinates can be pre-defined in a data structure stored in the cloud-based server 222, and the positioning system can be programmed to give directional guidance to return to the exact point in the digital map where previous data was acquired. Likewise, the computer 220 can be used to further process data records recorded to the cloud-based server 222.

[0044] However, Figures 1-3 The illustrated system has several identified problems as shown below. As the desire for ubiquitous data connectivity continues to grow and increase, various problems are faced. While cellular LTE networks can simultaneously and synergistically manage data corrections for RTK GNSS, as well as cloud-based data exchange using TCP / IP, this is not the case for bandwidth-limited Bluetooth devices connected to UARTs. Furthermore, existing data transfer mechanisms (e.g., NMEA strings used in GPS decoding) are not suitable for automatic synchronization with cloud-based data - and this is an identified problem for many users.

[0045] Additionally, existing electromagnetic utility locators with wireless data interfaces are subject to noise interference on the signals received from underground utilities by way of integrated sensor and signal processing subsystems. Typical sensitivity is detection of 1 mA signal current at 1 m depth. Thus, small disturbances close to the sensor can corrupt the measurement, as well as increase the difficulty for the operator to locate deep utilities or utilities with weak signals.

[0046] Furthermore, the pulsed nature of the wireless RF transmission results in pulsed current draw from the power supply. The wiring environment of the power supply and battery, the source of these pulsed currents, creates a corresponding pulsed magnetic field, and typically contains frequency components that fall into the detection bandwidth - the primary function of the locator. As an example, it has been noted that real-time cellular LTE data streams result in a 25 dB loss of signal-to-noise ratio of the locator signal at 1024 Hz (with reference to a 5 Hz detection bandwidth).

[0047] Embodiments of the present disclosure address many of these problems, and as suchFigures 4-6 In particular, embodiments of the present disclosure provide an isomorphic data transfer mechanism that allows a variety of possibilities for the exchange of data between a positioning receiver instrument and a cloud-based server. In some embodiments, the use of protocol buffers provides a language and platform neutral mechanism that allows for the automatic synchronization of serialized data structures. Such data structures are highly extensible, and can allow for applications that leverage remote offline data analysis.

[0048] Isomorphic data transfer allows the same data transaction to operate independently of the communication mechanism. In this context, a data transaction can be the transfer of any structured data, such as the positioning vectors discussed above. The communication mechanism can be any wave-based medium; Wifi, Bluetooth, and cellular networks are relevant examples. Isomorphic data transfer allows for communication method superposition, such that a data transaction can be initiated in one medium, and continued or completed in a variety of different mediums. For example, a data transaction can be initiated via a cellular network, then disconnected, continued over Wifi, and finally completed via Bluetooth. Thus, the communication method can allow for any combination of superposition, as well as any number of interruptions, fragmentation, or information expansion. Accordingly, embodiments of the present disclosure can take the form of “method superposition,” which is facilitated by the inherent isomorphic nature of serialized data. A variety of wireless communication mediums are suitable for these embodiments. For example, Figure 4 and Figure 5 An example of a WiFi implementation is shown, working in place of or in conjunction with an LTE cellular network. The cellular network is not limited to LTE, and can be configured to use any of the following available RF technologies: GSM, EDGE, UMTS, HSDPA / HSUPA.

[0049] For example, Figure 4 A system 400 using a WiFi implementation is shown. For example, as Figure 4 shown, a positioning receiver 402 receives GNSS data from a NTRIP source 408 via a WiFi network 404 through a NTRIP caster 406. As before, the positioner 402 and the NTRIP source 408 are in communication with a GNSS satellite array 410.

[0050] As Figure 4 shown, the positioning receiver 402 includes a magnetic sensor 412, electronics 414 that receive and process signals from the magnetic sensor 412, and a GPS receiver 416. In the example shown, the GPS receiver 416 can be an RTK receiver, and the positioning receiver 402 receives signals from a NTRIP source 408 via a WiFi network 404 through a NTRIP caster 406. Figure 4

[0051] ​As discussed previously, the positioning receiver 402 can then receive the magnetic field from the underground pipeline with the magnetic field sensors 412, which can be an array of spatially separated sensors. The array of magnetic field sensors 412 can include one or more 3D sensors that detect the magnetic field in three orthogonal directions. The data from the magnetic field sensors 412, as well as data from other sensors on the positioning receiver 402 (e.g., inertial sensors and environmental sensors), are then analyzed in the electronic device 414. The RTK receiver 416 receives data from the array of GNSS satellites 410, as well as from the NTRIP source 408, to accurately determine the geographic position of the positioning receiver 402.

[0052] Figure 5 Other aspects of the system 400 are shown. As Figure 5 shown, the positioner 402 can store data on the storage device 518 and communicate with a cloud-based server 506 via the WiFi 404. For example, the cloud-based server 506 can execute Microsoft Azure to store the data in a database. The computer 420 can retrieve data from the cloud-based server 506 for further analysis.

[0053] As discussed above, the positioning receiver 402 utilizes isomorphic data transfer to transmit the above-described positioning vector. As discussed above, isomorphic superposition can likewise be used for a variety of wireless data transfer protocols. Isomorphic superposition, such as the above-described isomorphic superposition, can likewise be used with Bluetooth, although the lower inherent bandwidth for Bluetooth Low Energy (BLE).

[0054] In Figure 4 and Figure 5 the illustrated example, the cloud connection can be performed by an application on the positioning receiver 402 (e.g., via the VMMAP App), but the method of data system superposition remains applicable.

[0055] In some embodiments, a mobile device, such as a smartphone, can provide a direct access point to the cloud, thus bypassing the requirement for an IoT platform hosted by Microsoft Azure. For example, Figure 6 These data transactions are shown, in this instance, isomorphic is implemented in the application executing on the mobile device that acts as an NTRIP client and manages the cloud connection.

[0056] As Figure 6As shown, the positioning receiver 402 can communicate with the mobile device 606 through Bluetooth 604. As described above, the mobile device 606 runs an application (e.g., VMMAP App) and communicates with a cloud server 608. The cloud server 608 can include cloud storage (e.g., Microsoft Azure) and an NTRIP caster. The NTRIP source 408, which communicates with the GNSS satellite array 410, can provide data to the cloud-based server 608 for communication with the positioning receiver 402 through the mobile device 606. The positioning receiver 402 can also communicate with the GNSS satellite array 410. The positioning receiver 402 can also include a data storage 518, where data stored in the cloud-based server 608 can be periodically synchronized when the mobile device 606 communicates with the cloud-based server 608, for example, through WiFi.

[0057] The isomorphic data overlay helps to solve the problem of RF-induced interference by allowing offline and online operations to coexist. The log files can be synchronized at any time after the positioning survey, with the only requirement being having an LTE cellular option, a WiFi-enabled option, or Bluetooth, and the mobile device operating an application. Using the Bluetooth or WiFi options has shown to reduce the overall interference compared to using the LTE cellular option for RTK streaming RTCM correction data.

[0058] Figure 7 A positioning receiver 700 according to some embodiments of the present disclosure is shown. As Figure 7 shown, the positioning receiver 700 includes a processor 704. The processor 704 can be any processing device capable of executing instructions to perform the functions described herein.

[0059] The processor 704 is coupled to a memory 702. The memory 702 can be any combination of volatile and non-volatile memory. The memory 702 stores programming instructions for execution by the processor 704 as well as data. As described above, the programming instructions stored in the memory 702 can be periodically updated with new instructions received by the positioning receiver 700.

[0060] The processor 704 also receives digitized signals related to the location of the underground utility or the operation of the positioning receiver 700. As Figure 7 shown, the processor 704 is coupled to receive digitized data (including analog-to-digital conversion) from an analog processing circuit 706. The analog processing 706 receives signals from one or more sensors. For example, the one or more sensors can include magnetic field detectors, inertial sensors, and environmental sensors.

[0061] As shown in the example positioning receiver 700, the analog processing 706 can be configured to receive and process signals from the magnetic antenna array 720. As previously discussed, the magnetic antenna array 720 can include one or more antennas capable of measuring a magnetic field in a defined direction relative to the positioning receiver 700. In particular, the magnetic antenna array 720 can include one or more 3D coil arrangements spatially separated to provide data to the processor 704 allowing for precise positioning of the underground utility relative to the positioning receiver 700.

[0062] As Figure 7 Further shown, the analog processing 706 can be configured to receive signals from the inertial sensors 718. The inertial sensors 718 can include an array of accelerometers, for example, that can measure motion of the positioning receiver 700.

[0063] Additionally, the analog processing 706 can be configured to receive signals from the sensors 716. The sensors 716 can include one or more environmental sensors. For example, the environmental sensors can measure parameters related to the state of the positioning receiver 700. These sensors can include, for example, temperature, power source state, or other state measurements.

[0064] The analog processing 706 receives signals from the sensors 716, the inertial sensors 718, and the magnetic antenna array 720 and provides corresponding digital signals to the processor 704. Accordingly, the analog processing 706 can include filters, amplifiers, integrators, and other analog circuitry suitable for processing signals received from the sensors in the sensors 716, the inertial sensors 718, and the magnetic antenna array 720.

[0065] The processor 704 is also coupled to receive geolocation data from the GPS antenna 708. As discussed above, the GPS antenna 708 can be a conventional GPS antenna, or for greater accuracy, an RTK antenna. As an RTK antenna, further data is received by the positioning receiver 700 to correct the position signal received from the GPS antenna 708.

[0066] In some embodiments, the processor 704 can be coupled to a data logger 714 or other storage device. As discussed above, positioning data including data from the GPS antenna 708, the magnetic antenna array 720, the inertial sensors 718, and the sensors 716 can be stored in the data logger 714. The data stored in the data logger 714 can be stored and transmitted to a cloud-based server at a later time, or the data logger 714 can be used as a buffer during continuous transfer of data from the positioning receiver 700 to the cloud-based server.

[0067] The processor 704 is also coupled to a communication interface 712. The communication interface 712 includes an antenna and other electronics to send and receive digital data. The communication interface 712 can be compatible with one or more of the WiFi standards or Bluetooth standards, for example. In some cases, a cellular telephone RF standard can be implemented. As discussed above, the processor 704 can transmit the localization data to a cloud-based server, either continuously or by reading data from the data logger 714. As discussed above, the processor 704 transmits the isomorphic data. As shown in Figure 4 and Figure 5 The communication interface 712 can communicate with the cloud servers 406 and 506 through WiFi, as shown. In this case, the processor 704 can execute a program such as the VMMAP, as discussed above. In some embodiments, the communication interface 712 can communicate with the mobile device 606, which then transmits the data to the cloud-based server 608, as shown in Figure 6

[0068] As further shown in Figure 7 The processor 704 is coupled to a user interface 710. The localization data, as well as messaging and other information, can be communicated to a user through the user interface 710.

[0069] The localization receiver 700 can be any of a variety of locator platforms configured to execute instructions according to embodiments of the present disclosure. Locators that can be used include the Vscan and Vscan Pro devices produced by Vivax-Metrotech.

[0070] Figure 8 A method 800 that can be executed on the localization receiver 700, as shown in Figure 7 The method 800 is executed with the processor 704 executing instructions stored in the memory 702.

[0071] As shown in Figure 8 The method 800 begins in step 802. In step 802, the localization receiver 700 receives and analyzes data including localization data, GNSS data, and operational data, as discussed above. In step 804, the localization receiver 700 compiles the data into a localization vector, as discussed above. In step 806, the localization receiver 700 determines isomorphic data from the localization vector. In step 808, the isomorphic data is transmitted as discussed above Figures 4-6 The method 800 can be repeated until all data is transmitted to the cloud-based platform.

[0072] The above detailed description is provided to illustrate specific embodiments of the application and not meant to limit. Numerous variations and modifications are possible within the scope of the present application. The present application is set forth in the appended claims.​

Claims

1. An underground pipeline locator system, comprising: The locator includes an array of spaced-apart low-frequency magnetic sensors that receive signals, including magnetic signals emitted from underground cables or pipes. as well as A communication system that provides communication with a cloud-based platform, the cloud-based platform receiving and storing data including the signals. Among them, data transmission is homogeneous data transmission.

2. The pipeline locator system according to claim 1, wherein, The communication system is a WiFi system.

3. The pipeline locator system according to claim 1, wherein, The communication system includes a mobile device that communicates with the locator and provides WiFi connectivity to the cloud-based platform.

4. The pipeline locator system according to claim 1, wherein, The locator includes a real-time dynamic GNSS system for positioning on the Earth's surface.

5. The pipeline locator system according to claim 4, wherein, The locator receives RTK correction data from a ground base station, or alternatively, GNSS correction.

6. The pipeline locator system according to claim 1, wherein, The locator communicates with a cloud network server, including an Internet of Things (IoT) platform.

7. The pipeline locator system according to claim 1, wherein, The communication system uses an attribute-value pairing format for data exchange.

8. The pipeline locator system according to claim 1, wherein, The communication system can include a smartphone that communicates with the locator.

9. A method for transmitting data from a pipeline positioning receiver, comprising: Acquire data; Determine the positioning vector based on the data; Isomorphic data is determined based on the positioning vector; as well as Transmit the homogeneous data.

10. The method according to claim 9, wherein, Transmitting the homogeneous data includes: transmitting the homogeneous data using WiFi.

11. The method according to claim 9, wherein, Transmitting the homogeneous data includes transmitting the homogeneous data to a mobile device.

12. The method according to claim 9, wherein, The data acquired includes: location data, operational data, and geographic location data.

13. A positioning receiver, comprising: Magnetic sensor array; The processing circuit is coupled to the magnetic sensor array; The GPS antenna is coupled to the processing circuit. The communication interface is coupled to the processing circuit. as well as A memory, coupled to the processing circuitry, stores instructions executable by the processing circuitry to: Data is acquired from the magnetic sensor array and the GPS antenna. The positioning vector is determined based on the data. Isomorphic data is determined based on the location vector, and The homogeneous data is transmitted through the communication interface.

14. The positioning receiver of claim 13, further comprising an operation sensor, said operation sensor including an inertial sensor, and wherein, The instructions for acquiring data also include instructions for acquiring data from the operating sensor.

15. The positioning receiver according to claim 13, wherein, The communication interface includes a WiFi interface.

16. The positioning receiver according to claim 13, wherein, The communication interface includes a Bluetooth interface that transmits data isomorphically to the mobile device.

Images