Search result for:  id10=WA 0859 3970 0884 [[HATIGA]] Biaya Buat Neon Box 100 X 50 Berpengalaman Musuk Boyolali

Channel Remapping Channel remapping allows you to change: the order of channels on each analog spread cable that connects to the Geode reorder the Geode Boxes. You would use this option if your cables were wired opposite to the default order normally used in Geometrics wiring, if you wished to turn your line around to have the low channels at the opposite end, or if your cables had a wiring error. Channel remapping is also often necessary when using more that a single network cable. Default cable wiring of Geometrics seismographs Default order is defined as the natural electrical order in which channels are oriented when the system first powers up before remapping. Refer to Section 3 under Connector Wiring that discusses standard wiring configurations. You may have requested a custom wiring configuration from Geometrics. If you are confused about your wiring, contact the factory and refer to the serial number and job number. Geode cables are typically wired in a ‘high-side configuration’, meaning that the Geode connects closest to the highest numbered channel on the analog cable. The 149 figure above shows this configuration for a single Box system, with 24 channels. Multiple Geodes The following diagram shows a default single digital line (one network card) system with 3 Geodes. Note that Geode one is always closest to the controller in a default configuration. Multiple Network Lines The next diagram below shows a default configuration with two digital lines (two network cards) with the controller positioned in the middle. Line 1 is on the left and line 2 is on the right. One might use two lines to increase data throughput to reduce time between shots. Like the configuration above, the Geodes are numbered starting closest to the controller. The seismic controller software labels all of the channels contiguously even though they are on two separate digital lines. However, if the lines are collinear, the first line will have the channels ordered backwards. This can be easily rectified with the remapping feature. There are two ways of remapping channels: automatic mode and manual mode. Automatic mode settings are listed on the top of the remapping dialog Box, and manual mode on the bottom. Automatic Channel Remapping Automatic channel remapping allows you to reverse either the order of the Geodes on the line, or reverse the order of the channels on the spread cable. The above diagram shows the result after both channels and Geodes have been reversed, renumbering the line so that low channels start on the left hand side and increase towards the right. In the dialog Box, the automatic remapping Boxes referencing line 2 remain unchecked, since the default orientation on line two was correct. Manual Channel Remapping Channels can be remapped on an individual basis using the Manual Map Mode. Select the appropriate check Box, and enter the order in which you would like the channels that differs from the default order. You can specify individual channels separated by a comma (1, 3, 4, 6 etc) or a range of channels (1-13, 24-14 etc). For example, if you wanted the channels ordered backwards on a 24-channel system, you would enter 24-1. If you wished to reverse the order of channels 1- 12 in a 24 channel system, you would type 12-1, 13-24. Other examples are shown opposite, and are available by pressing the See Examples button on the remapping menu.

I was doing a survey, and the tablet lost connection with the sensor, with no data being saved to the tablet. So I took the SD card of the sensor Box, hoping that the data was kept there at least as a backup before the survey ended and data was completely transferred to the tablet. But there is nothing on the SD card. It is empty instead of having a LOST.DIR folder that is also empty.So, my question is, what is the sensor Box SD card for?Second, is there a way to prevent tablet disconnection from the sensor WIFI (which happens frequently) and backup data when this happens?

Geodes do have an option to have a factory installed oscillator board at extra cost that is used to test the electronics in the Geode. These are not normally installed for most of our users. Users do have the option to run geophone tests using the standard equipped Geode Seismograph that can run line continuity and geophone tests. This can be accessed from the system->tests->Run Geophone/Line tests. Oscillator boards are typically installed during purchase. Fewer than 5% of the customers purchase that option, that level of QC is typically not necessary. For more information please read the test Box manual. We no longer supply the Test Box to external customers. A description of how to run the tests if you use the test Box or if you use the internal oscillators is described in Section 2.11.3.1 RUN INSTRUMENT TESTS (OPTIONAL ADD-ON FEATURE) of the manual. The latest standard Geode Operations Manual has more information. You can run the tests outlined in the Geode Operations Manual to detect the bad geophones and spread cables. If you require a calibration certificate for your Geode please consult our Support Note. All Geophysical surveys require interpretation given limited understanding of the site, data from equipment, and ground truthing. Any interpretation provided is the best that can be provided according to the geophysical expertise and experience of the geophysicist.

Thank you. No, I am asking about the micro SD card on the Box board.

The cables between the sensors and the MFAM module are flexible circuit boards, and the length is limited to 20 inches. It is possible to remove the MFAM module from the Development kit Box and then reconnect it using a ribbon cable. That would allow you to extend the MFAM module and sensors away from the Dev Kit Box. Our engineers have tested it to 4 meters. Below are some details about the ribbon cable. The connector on the MFAM unit is Samtec FSH-110-04-F-DH. Its mating connector is Samtec SFMH-110-02-L-D-WT. The easiest option for an extender cable between the MFAM and the Dev Kit is a pair of cable assemblies from Samtec www.samtec.com which has male/female mass terminate connectors put onto a ribbon cable.  These connectors plug directly into the MFAM I/O connector and also into the Development Kit.  We are comfortable with lengths to 10 feet total.  The samtec P/N for this cable is:  FFMD-10-T-60.00-01-F-N The ‘60.00’ number specifies the cable length in inches (which equals 5 feet).  We have found that there is generally a 2-4 week lead, time since they are made to order and not an off-the-shelf part. (There is another solution as well if you want to make adapter boards at each end (Dev Kit and MFAM).  The exact Samtec mates for the MFAM / Dev Kit connectors are made in PCB mount connectors only, so if you make simple small adapter board to adapt the samtec connector to another connector of your choice.  We've done this with ExpressPCB which is fast and inexpensive.  A board set from ExpressPCB is about $70 including shipping.  Our Engineering Team has a design and parts list they can send you if you're interested in going this route.)

General information The most common symptoms of intermittent connection issues are shown below: D_CY shows a background decay signal is either much higher than normal, and/or C_CY is a flat line (doesn’t decay). Figure 1 Intermittent connection issue. Where is the failure occurring? The two most common places where intermittent issues occur are at the two ends of the Rx cable: the joint between the Rx cable and the Cart and the joint between the Rx cable and the EDA Box (orange Box). Now we need to identify which joint has the intermittent issue. Set up the MM2x2 in DAM mode. Collect DAM data while keeping the Cart stationary but tapping one joint. Collect another DAM data while tapping the other joint. Analyze the DAM data by plotting the “Monostatic_5” for all 12 Rx channels in Geosoft. The channels having intermittent issues will appear much noisier. If you have MatLab software, you can download the MatLab code to analyze the DAM data. Example plots are shown below. It is obvious that “ZA” channel has the intermittent issue in Figure 2 and “XB” channel is open in Figure 3 (very flat line, no noise at all). Click here to download the code: Attachment : Intermittent_noise_full.zip . If both DAM and IVS data have the same problematic channel(s), we are confident that the intermittent issues observed in IVS data are repeated in DAM data, and by tapping at that location, we are able to identify the intermittent joint. Figure 2 Intermittent "ZA" channel. Figure 3 Open "XB" channel. What to do next? Disconnect the problematic joint and clean the connectors on both sides thoroughly (using an acid brush and a can of compressed air). Reconnect and try the tapping method again. If the problem goes away (no more noisy channels), the intermittent issue is likely caused by dust. If cleaning doesn’t fix the problem, swap out the Rx cable and repeat the tapping method. If the problem goes away, it is likely caused by a bad Rx cable. If there is another set of EDA and Cart available, swap out the EDA and the Cart to identify the problematic part. If not, use the tapping location to identify the problematic part. Fill out the RMA form at . If it is the Cart, send in the whole system for inspection/repair. You can contact Geometrics for MM2x2 rental if you need to continue your work during the down time. If it is the EDA, we recommend sending in the EDA only. It will save your repair time since it is much faster to unpack/pack/ship the EDA than the whole system. You can contact Geometrics for EDA rental if you need to continue your work during the down time. Warning Please note that this tapping method should ONLY be tried when intermittent issues have been observed in IVS tests. It is NOT recommended to use it as a daily QC test because it does put extra stress on connectors and likely leads to a shortened connector lifetime if applied too often.

The time associated with each data point in a SEG-2 data file generated by a Geode is related to the time of the “trigger” event which was instrumental in the production of the file and its content. The Trigger Master and Trigger Distribution The trigger event occurs at the Geode designated within the Controller software as the Trigger Master. Although all Geodes are capable of being Trigger Masters, there must be one and only one Trigger Master in any properly functioning Geode system. The Controller automatically takes care of this requirement when the designation is made by a user, and when the system is established at the time of Controller start-up based on a previous designation (or a default setting in the case of a “new survey”). All other Geodes in the system will have their Trigger Master circuit disabled. A trigger event can be initiated by an external electrical pulse provided to the trigger input connector of the Trigger Master Geode, or by a command sent via Ethernet from the Controller to the Trigger Master (usually for test purposes), but only when all conditions are satisfied to allow data recording. There is also a special trigger initiation situation, called “self-triggering” which will not be discussed further here. Upon acceptance of a trigger event, the Trigger Master will distribute the trigger signal to all Geodes in the system, itself included, via an RS-485 network that resides within the digital interconnect cabling. (Proper termination of this RS-485 network is automatically taken care of by the Controller.) The trigger signal is propagated through the cabling and Geodes at the nominal speed of 70% of the speed of light, or approximately 2.1x10^8 m/sec. The maximum distance of successful propagation depends on a number of factors such as the number of Geodes involved, the noise environment, the quality of the cables, and the acceptable amount of timing uncertainty for the particular application. Distances approaching or exceeding 1km should be given careful attention in this regard. In a 3-D Geode system involving LTUs, each LTU, unlike a Geode, will reconstruct the trigger signal before sending it on, effectively confining the maximum distance issue to each sub-network separated by LTUs. The penalty is an additional delay of about 100nS for each LTU in the route. The External Trigger Circuit The external trigger input is capacitively coupled, with a 2mS time constant, to the midpoint of a resistive voltage divider. The voltage difference between the two ends of the divider constitute a voltage "window", which size is set by the trigger sensitivity parameter and can range from essentially zero at the highest sensitivity, to about +/- 2.5V at the lowest sensitivity. The Geode will trigger (if enabled) if and when the coupled signal exceeds the window, in either direction (i.e., positive or negative going). The signal, after the capacitor, is clamped by diodes to the range between the trigger signal ground and +5VDC. The trigger detector output is disabled when the system is disarmed, during a parameter change, and during a shot, up to the trigger hold-off time after the end of the shot. The trigger hold-off time is a parameter set by the user. Preceding the coupling capacitor (i.e., essentially the node accessible at pin A of the external connector), there is a 3.3K-Ohm pull-up resistor to +5VDC (relative to pin B). Also a fast transient suppressor clamps the input at about +/-14VDC. It is advised that the DC + AC level of any voltage applied to pin A relative to pin B be kept within the range of +/-7V, giving some margin of safety. If a DC voltage somewhat less than +5VDC is applied when the connector is first mated, the instrument may trigger at that moment. But, subsequently, because of the capacitive coupling, it will trigger on the next positive or negative going pulse that exceeds the window level. If the duration of the applied voltage pulse is less than the record length + delay time + hold-off time, then the Geode will effectively be ready to trigger on the same edge of another similar pulse. Sub-sample Synchronization The Geode supports a sub-sample timing synchronization feature used for synchronizing the data acquisition after a trigger event to the distributed trigger signal, so that subsequent time points will be known to within 1/32 (~1/20 at the fastest two sampling rates) sample interval. It does this by increasing the sample interval at the trigger time by 0 to 31/32 of a sample interval in increments of 1/32, so that the first sample after the trigger would represent a time of one sample interval after the trigger event, with a tolerance within 1/32 of a sample interval. The following samples continue from there at the expected intervals. For example, with a selected sampling interval of ¼ mS and a recording delay of 0mS, the first sample in the recorded file for each channel would represent data at 250 to 258uS after the trigger event. This of course potentially introduces a small discontinuity at the time of the trigger, observable depending on the nature of the channel waveform(s). (The zero-phase anti-alias filter will smear the discontinuity into the nearby samples both before and after, consistent with the bandwidth of the filter.) Sub-sample synchronization can be disabled if it is deemed to be detrimental for the particular application, at the expense of losing the 1/32 interval timing accuracy. Timing Errors The principal errors in Geode timing are of two types: those associated with the trigger mechanism and which are static over the duration of the record, and those associated with the time base and which change over the duration of the record. Excluding the trigger propagation delay mentioned above, the trigger timing uncertainty is about 1uS. The known fixed errors have been lumped together and are reported in the SEG-2 file trace headers as channel SKEW. (The actual channel skew is zero, since all channels are effectively sampled simultaneously, but the SKEW value in the header is used as the only place permitting small timing corrections. Note that the SKEW value for every channel is identical.) If the size of this correction is important to the application, the SKEW value should be added to the calculated time points when the data is being processed. The Geode time base has a +/-15ppm stability over temperature (-20C to +70C) and component variations. Thus time drift relative to absolute time and relative to other Geodes is possible. (However, all channels within any Geode enclosure use the same time base, so there is no relative drift between channels in the same enclosure.) Therefore timing uncertainty increases from that existing at the time of the trigger until the time of the next trigger (or end of record). Special Timing Issues Involved with “Continuous” Recording “Continuous” recording is a method that allows unending 100% time coverage with recorded Geode data. It produces a series of time-overlapped records created by the use of a negative time delay set equal to the record length such that each record consists of completed history at the time of the trigger event. This technique circumvents the problem of data transmission overrunning data acquisition. The principle constraint is that the cycle time from trigger to trigger must always be less than the chosen record length. Otherwise, gaps rather than overlap would result. Commonly it is used with GPSderived triggering in order to provide time-stamping of each trigger event. Upon consideration of the above, it will become clear that the time-stamp associated with a particular trigger event will pertain to the data in the following record, not to the data in the record in which the time-stamp is written. This comes about because the trigger event ends the record. Because there is data overlap between records, the precise trigger point in the following record at which the time-stamp applies can be found by comparison of the data values at the end of the former record with those near the beginning of the subsequent record. The overlapping data will be exactly identical in both records (since they are read from the same memory location, twice). The earliest data in the subsequent record that goes beyond the data of the previous record is the data that is one sample interval (assuming sub-sample synchronization is enabled) past the time-stamp. Note well that this comparison must be made independently for at least one channel of each 8-channel Geode board set, because the discrete time at which data values are written to the memory buffer, relative to the trigger event, is a function of each individual board set in the Geode system. Correct GPS Time-Stamping There are differences between various GPS models that can affect accurate time stamping. The 1PPS signal from a GPS has a “timing edge” and return edge, of which only the former is the true whole-second edge. Some models use a rising edge as the timing edge, some the falling edge, and some have it selectable. Consult the GPS manual to determine the definition of its timing edge. As indicated earlier, the Geode can be triggered on either a rising or falling edge. It is important to insure that the Geode is being triggered on the proper edge in order to avoid timing that may be a fraction of a second off. This is expanded upon below. Some GPS units provide a very narrow timing pulse, others one that has a nearly 50/50 duty cycle. For the narrow pulse units, almost certainly it is the leading edge (rising or falling) that is the “timing edge”. This case can be easily handled by using the Geode Trigger Hold-off feature. If a 10-second cycle time is desired, set the Trigger Hold-off time to about 9.5 seconds. In this case, there is a very small chance that the very first trigger could occur on the wrong (trailing) edge, but from then on the leading edge will be used as the triggering edge. If the GPS provides a 50/50 duty cycle edge, and it is not alterable, then the Geode by itself could as easily start on the wrong edge as on the correct timing edge, and continue thusly until restarted. For this case, Geometrics can provide a Trigger Timing Interface Box (TTIB) that will correct the situation. The TTIB can be programmed to respond only to the correct edge (rising or falling), change the polarity if needed, and gate through only one of every N 1PPS pulses, where N is programmable. (The TTIB also incorporates an alarm system that can provide a remote alert if a record is missed.) Another potential issue comes from the variations between GPS models of the time that the serial time string (containing the time value of the associated 1PPS) is issued relative to the 1PPS itself. The Geode Controller attempts to pick the correct serial string based on a calculation involving the known record length, the PC times, and the trigger notification message from the Geodes. But if the GPS issues the serial string at an unusual time (and the time has been seen to vary somewhat with a given GPS unit) then it could pick up the incorrect time, off by 1 second. If rare, it can be subsequently detected and corrected during data processing, but if consistent it may not be easily detected. Again, the TTIB can accommodate the situation by only gating through to the Controller PC the string belonging to the gated-through 1PPS pulse. The Controller Serial Input Time Window can then safely be widened to 2 seconds (assuming the cycle time is more than 2 seconds) if need be, to expand the Controller’s search for the string around the calculated trigger time.

@aldsantos I see. Please try it anyway next time in the field. Let us know if loss of connection still occurs after you have selected to stay connected to the G-864 WIFI. Thanks!

@aldsantos For the current version of the embedded software, some raw data was first stored in the microSD and then transferred to the tablet. Data logging stops once the WIFI connection is lost. In the future, if we have an easier way to access the microSD, we may use it as a backup.

Regarding the loss of connection, I was in the middle of the field, far away from internet/WIFI connection. Indeed, it stopped collecting data.

Regarding your SD card question, you must mean the USB drive, right? The drive is not for storing mag data but for running the embedded software.

The reason why the tablet lost connection with the sensor is because the G-864 WIFI has no internet access. The tablet will try to switch to another WIFI with internet access and disconnect from the G-864. To prevent this from happening, in the warning window of the tablet, select "don't ask again for this network" and click "Yes". Please remember to do this after you have used the tablet to access the internet.

Hi All,   We are using the Teensy 4.1 as a logger (Adafruit GPS is linked with the Teensy) for the MFAM SX. Below is the code for the Arduino IDE (Teensy), for people who might find it useful, Roi   #include <NativeEthernet.h> #include <SD.h> // ---- NETWORK CONFIGURATION ---- byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; IPAddress ip(192, 168, 2, 10); IPAddress mfamIP(192, 168, 2, 2); uint16_t mfamPort = 1000; EthernetClient client; // ---- PACKET STRUCTURE ---- const int PACKET_SIZE = 1380; const int SAMPLE_SIZE = 32; const int HEADER_SIZE = 16; const int NUM_SAMPLES = 40; const int SD_CHIP_SELECT = BUILTIN_SDCARD; uint8_t buffer[PACKET_SIZE]; int bufferPos = 0; // ---- SD CARD ---- File logFile; bool sdReady = false; unsigned long sampleCount = 0; unsigned long fileStartTime = 0; char filename[32]; // ---- AUXILIARY CHANNEL STORAGE ---- double gyroX = 0, gyroY = 0, gyroZ = 0, gyroT = 0; double accelX = 0, accelY = 0, accelZ = 0, accelT = 0; double compassX = 0, compassY = 0, compassZ = 0, compassT = 0; // ---- GPS FROM ADAFRUIT MODULE ON SERIAL1 (Pin 0 = RX) ---- char gpsBuffer[256]; int gpsBufferPos = 0; char gpsString[128] = ""; char gpsDate[12] = "00/00/00"; char gpsTime[16] = "00:00:00.000"; bool gpsFix = false; uint8_t tsStatus = 0; // ---- OUTPUT CONTROL ---- // Set to 1 to log every sample, 10 for 100Hz, 20 for 50Hz, etc. const int DOWNSAMPLE_FACTOR = 1; // 50 Hz output int downsampleCounter = 0; // How many minutes per file. Set to 10, 20, 60, etc. const int FILE_MINUTES = 10; // ---- LED INDICATOR ---- // Off = starting up // Very slow blink (every 3 sec) = connected and logging // Fast blink (4/sec) = connected but no data arriving // Solid on = no SD card // 3 quick flashes then pause = cannot connect to MFAM const int LED_PIN = 13; unsigned long lastBlinkTime = 0; bool ledState = false; unsigned long lastDataTime = 0; // ---- FUNCTION PROTOTYPES ---- void createNewFile(); void parsePacket(uint8_t* pkt); void parseAuxChannels(uint8_t* sample, uint16_t frameID); void readGPS(); void parseGPRMC(char* sentence); void writeSample(unsigned long timestamp, uint16_t fiducial, double mag1, uint16_t mag1s, double mag2, uint16_t mag2s, uint16_t sysStatus); int16_t toSigned16(uint16_t val); void createNewFile() { static int fileNumber = 0; // On first call, find the next available file number if (fileNumber == 0) { char testName[32]; for (int i = 1; i <= 99999; i++) { snprintf(testName, sizeof(testName), "MFAM_%05d.txt", i); if (!SD.exists(testName)) { fileNumber = i - 1; // Will be incremented below break; } } } fileNumber++; snprintf(filename, sizeof(filename), "MFAM_%05d.txt", fileNumber); logFile = SD.open(filename, FILE_WRITE); if (logFile) { logFile.println("Mag 1,Mag 2,Fid,SysS,Mg1S,Mg2S,Gyro X,Gyro Y,Gyro Z,Gyro T,Accel X,Accel Y,Accel Z,Accel T,CompassX,CompassY,CompassZ,Comp T,Date,Time,TS Status,GPS"); logFile.flush(); fileStartTime = millis(); Serial.print("Logging to: "); Serial.println(filename); } else { Serial.print("ERROR: Could not create "); Serial.println(filename); } } void setup() { Serial.begin(115200); delay(2000); // Start GPS serial port (Adafruit Ultimate GPS defaults to 9600 baud) Serial1.begin(9600); pinMode(LED_PIN, OUTPUT); digitalWrite(LED_PIN, LOW); memset(gpsString, 0, sizeof(gpsString)); // Initialize SD card if (SD.begin(SD_CHIP_SELECT)) { sdReady = true; Serial.println("SD card ready."); } else { Serial.println("WARNING: No SD card found. Serial output only."); digitalWrite(LED_PIN, HIGH); } // Initialize Ethernet Ethernet.begin(mac, ip); if (Ethernet.hardwareStatus() == EthernetNoHardware) { Serial.println("ERROR: No Ethernet hardware found!"); while (true) {} } Serial.print("Teensy IP: "); Serial.println(Ethernet.localIP()); Serial.print("Connecting to MFAM at "); Serial.print(mfamIP); Serial.print(":"); Serial.println(mfamPort); if (client.connect(mfamIP, mfamPort)) { Serial.println("Connected to MFAM!"); } else { Serial.println("Connection failed!"); } Serial.println("Waiting for GPS fix..."); if (sdReady) { createNewFile(); } Serial.println("Mag 1,Mag 2,Fid,SysS,Mg1S,Mg2S,Gyro X,Gyro Y,Gyro Z,Gyro T,Accel X,Accel Y,Accel Z,Accel T,CompassX,CompassY,CompassZ,Comp T,Date,Time,TS Status,GPS"); } void loop() { // Always read GPS data from Serial1 readGPS(); if (!client.connected()) { Serial.println("Disconnected. Reconnecting..."); if (sdReady && logFile) { logFile.flush(); } for (int i = 0; i < 3; i++) { digitalWrite(LED_PIN, HIGH); delay(100); digitalWrite(LED_PIN, LOW); delay(100); } delay(1400); client.connect(mfamIP, mfamPort); if (client.connected()) { lastDataTime = millis(); } return; } while (client.available()) { buffer[bufferPos] = client.read(); bufferPos++; if (bufferPos >= PACKET_SIZE) { parsePacket(buffer); bufferPos = 0; lastDataTime = millis(); } } // LED patterns if (sdReady) { if (millis() - lastDataTime > 3000) { if (millis() - lastBlinkTime > 125) { ledState = !ledState; digitalWrite(LED_PIN, ledState ? HIGH : LOW); lastBlinkTime = millis(); } } else { if (millis() - lastBlinkTime > 1500) { ledState = !ledState; digitalWrite(LED_PIN, ledState ? HIGH : LOW); lastBlinkTime = millis(); } } } // New file every FILE_MINUTES minutes if (sdReady && logFile && (millis() - fileStartTime > (unsigned long)FILE_MINUTES * 60UL * 1000UL)) { logFile.close(); createNewFile(); } } // ---- GPS READING FROM ADAFRUIT MODULE ON SERIAL1 ---- void readGPS() { while (Serial1.available()) { char c = Serial1.read(); if (c == '$') { gpsBufferPos = 0; } if (gpsBufferPos < (int)sizeof(gpsBuffer) - 1) { gpsBuffer[gpsBufferPos] = c; gpsBufferPos++; } if (c == '\n' || c == '\r') { gpsBuffer[gpsBufferPos] = '\0'; if (strncmp(gpsBuffer, "$GPRMC", 6) == 0 || strncmp(gpsBuffer, "$GNRMC", 6) == 0) { // Save full sentence for logging strncpy(gpsString, gpsBuffer, sizeof(gpsString) - 1); gpsString[sizeof(gpsString) - 1] = '\0'; // Remove trailing newline/carriage return int slen = strlen(gpsString); while (slen > 0 && (gpsString[slen - 1] == '\n' || gpsString[slen - 1] == '\r')) { gpsString[slen - 1] = '\0'; slen--; } parseGPRMC(gpsBuffer); } gpsBufferPos = 0; } } } void parseGPRMC(char* sentence) { // $GPRMC,HHMMSS.sss,A,lat,N,lon,W,speed,course,DDMMYY,... char copy[256]; strncpy(copy, sentence, sizeof(copy) - 1); copy[sizeof(copy) - 1] = '\0'; char* token = strtok(copy, ","); int field = 0; while (token != NULL && field < 10) { switch (field) { case 1: // Time if (strlen(token) >= 6) { snprintf(gpsTime, sizeof(gpsTime), "%c%c:%c%c:%s", token[0], token[1], token[2], token[3], token + 4); } break; case 2: // Fix status gpsFix = (token[0] == 'A'); break; case 9: // Date if (strlen(token) >= 6) { snprintf(gpsDate, sizeof(gpsDate), "%c%c/%c%c/%c%c", token[0], token[1], token[2], token[3], token[4], token[5]); } break; } token = strtok(NULL, ","); field++; } // Update GPS bits of tsStatus tsStatus = (tsStatus & 0x0C); // Keep MFAM PPS bits (3,2) tsStatus |= 0x01; // Bit 0: RMC sentence received if (gpsFix) { tsStatus |= 0x02; // Bit 1: GPS fix valid } } // ---- MFAM DATA PARSING ---- int16_t toSigned16(uint16_t val) { if (val > 32767) return (int16_t)(val - 65536); return (int16_t)val; } void parseAuxChannels(uint8_t* sample, uint16_t frameID) { uint8_t auxID = (frameID >> 11) & 0x07; uint16_t aux0 = sample[16] | (sample[17] << 8); uint16_t aux1 = sample[18] | (sample[19] << 8); uint16_t aux2 = sample[20] | (sample[21] << 8); uint16_t aux3 = sample[22] | (sample[23] << 8); switch (auxID) { case 1: compassX = toSigned16(aux0) / 0.01333333; compassY = toSigned16(aux1) / 0.01333333; compassZ = toSigned16(aux2) / 0.01333333; compassT = toSigned16(aux3) / 128.0 + 25.0; break; case 2: gyroX = toSigned16(aux0) / 16.384; gyroY = toSigned16(aux1) / 16.384; gyroZ = toSigned16(aux2) / 16.384; gyroT = toSigned16(aux3) / 512.0 + 23.0; break; case 4: accelX = toSigned16(aux0) / 16384.0; accelY = toSigned16(aux1) / 16384.0; accelZ = toSigned16(aux2) / 16384.0; accelT = toSigned16(aux3) / 512.0 + 23.0; break; default: break; } } void writeSample(unsigned long timestamp, uint16_t fiducial, double mag1, uint16_t mag1s, double mag2, uint16_t mag2s, uint16_t sysStatus) { char tsStr[12]; snprintf(tsStr, sizeof(tsStr), "%d%d%d%d%d%d%d%d", (tsStatus >> 7) & 1, (tsStatus >> 6) & 1, (tsStatus >> 5) & 1, (tsStatus >> 4) & 1, (tsStatus >> 3) & 1, (tsStatus >> 2) & 1, (tsStatus >> 1) & 1, tsStatus & 1); char sysHex[8], m1sHex[8], m2sHex[8]; snprintf(sysHex, sizeof(sysHex), "%04X", sysStatus); snprintf(m1sHex, sizeof(m1sHex), "%04X", mag1s); snprintf(m2sHex, sizeof(m2sHex), "%04X", mag2s); char line[512]; snprintf(line, sizeof(line), "%10.4f,%10.4f,%4d,%s,%s,%s,%10.2f,%10.2f,%10.2f,%5.1f,%8.5f,%8.5f,%8.5f,%5.1f,%8.1f,%8.1f,%8.1f,%5.1f,%s,%s,%s,%s", mag1, mag2, fiducial, sysHex, m1sHex, m2sHex, gyroX, gyroY, gyroZ, gyroT, accelX, accelY, accelZ, accelT, compassX, compassY, compassZ, compassT, gpsDate, gpsTime, tsStr, gpsString); if (sdReady && logFile) { logFile.println(line); if (sampleCount % 1000 == 0) { logFile.flush(); } } if (sampleCount % 500 == 0) { Serial.println(line); } } void parsePacket(uint8_t* pkt) { // Get PPS bits from MFAM system status uint16_t firstSysStatus = pkt[HEADER_SIZE + 2] | (pkt[HEADER_SIZE + 3] << 8); uint8_t mfamPPSbits = (firstSysStatus >> 12) & 0x0C; tsStatus = (tsStatus & 0x03) | mfamPPSbits; for (int i = 0; i < NUM_SAMPLES; i++) { int offset = HEADER_SIZE + (i * SAMPLE_SIZE); uint16_t frameID = pkt[offset] | (pkt[offset + 1] << 8); uint16_t fiducial = frameID & 0x07FF; uint16_t sysStatus = pkt[offset + 2] | (pkt[offset + 3] << 8); uint32_t mag1raw = pkt[offset + 4] | (pkt[offset + 5] << 8) | ((uint32_t)pkt[offset + 6] << 16) | ((uint32_t)pkt[offset + 7] << 24); double mag1 = mag1raw * 0.05 / 1000.0; uint16_t mag1status = pkt[offset + 8] | (pkt[offset + 9] << 8); uint32_t mag2raw = pkt[offset + 10] | (pkt[offset + 11] << 8) | ((uint32_t)pkt[offset + 12] << 16) | ((uint32_t)pkt[offset + 13] << 24); double mag2 = mag2raw * 0.05 / 1000.0; uint16_t mag2status = pkt[offset + 14] | (pkt[offset + 15] << 8); parseAuxChannels(pkt + offset, frameID); sampleCount++; downsampleCounter++; if (downsampleCounter >= DOWNSAMPLE_FACTOR) { downsampleCounter = 0; writeSample(millis(), fiducial, mag1, mag1status, mag2, mag2status, sysStatus); } } }

🧭 How to Import Geophone Elevation Data into Plotrefa If you have measured relative or absolute geophone elevations, you can incorporate these into your velocity model in Plotrefa to produce more geologically realistic results. 📄 Step 1: Prepare the Elevation File Create an ASCII text file with two columns: The left column contains geophone horizontal positions (in meters or feet). The right column contains the corresponding elevation values. Example: 0.0 100.0 5.0 101.2 10.0 101.5 ... 100.0 89.0 ✅ Tip: While it’s recommended to have an elevation for each geophone, it’s not strictly required. Plotrefa will interpolate missing elevations as needed. 📥 Step 2: Import the Elevation Data Open Plotrefa. From the top menu, go to:Velocity model > Import elevation data file Navigate to your file and double-click it to import.📌 Note: There is no default file extension, so ensure your file is visible in the dialog. The elevation profile will now display alongside your data. 🎯 Step 3: Interpret Your Data Once your elevation profile is imported: Proceed with your velocity modeling or time-term inversion. The resulting velocity model will be drawn relative to the elevation profile, accounting for topography. Example Outputs: Attachment : seismic_velocity_profile.png

Geometrics instruments, such as G-864, MagEx, MagArrow, MagStation et al, communicate with a mobile device via WIFI. But because the instrument WIFI has NO internet access, some Android device, after connecting to the instrument for a while, will automatically start searching for another WIFI access point. To prevent this from happening, when the No Internet Access warning window pops up after first WiFi connection, choose "Tap for options". On the following window, check the “Don’t ask again for this network” Box and press “Yes” .