Search result for:  id10=WA 0859 3970 0884 [[Hatiga WaterHeater]] Layanan Hot Water System Apartemen Tanon Sragen

The MFAM Magnetometer samples at 1000 Hz, which in turns captures a lot of unique waveforms. When viewing the data raw, it can therefore appear to be a bit noisy. But a closer examination of the data will reveal a real variation of the magnetic field which is caused caused by the power distribution network. Proper filtering is required to reduce the power line caused variations and reveal the strong signal of interest. It is not obvious that 60 or 50 hertz electromagnetic radiation is real, since in ordinary experience any power line “noise” is electrostatically coupled into a System (think 60 hertz hum on a stereo System) and is a fault that needs to be fixed. In this case however the variation in the magnetic field is induced by the power grid and is real. The magnetometer is simply and dutifully reporting the variation. These power line variations are to some extent present everywhere – even miles from the nearest power line. But obviously being close to power lines will increase the amplitude of the variations a lot. Often on a MagArrow survey the power line variations will be larger at one end of the survey area than the other. Poking in the GPS coordinates at the survey area nearest the larger variations into Google Earth will usually reveal the power lines from an aerial view – even if they are not visible on the ground. After applying a Fourier Frequency Transform on the MFAM data to identify the noise sources, 50 and 60 Hz noise amplitudes are easily observed. Also observable is the likely to be 20.8 Hz Schumann resonance of the third node and some other ultra-low frequency electro magnetic radiation produced naturally by the Earth. Harmonics of 60 Hz are also present. Another common question is “Why is the power line variations not a sine wave like the power line voltage?” Remember that voltages do not make magnetic fields. Only current generates magnetic fields, and the current being drawn is not a sine wave at all. Many loads, for example, only draw current at the voltage peaks. This makes for a non-sinusoidal magnetic field that is rich in harmonics. Also note that most power distribution System use a 3 phase topology. The ripple current in such a System will be 150 or 180 Hz. Thus you will often see large peaks in the power spectrum at these frequencies and their harmonics.

The MFAM Magnetometer samples at 1000 Hz, which in turns captures a lot of unique waveforms. When viewing the data raw, it can therefore appear to be a bit noisy. But a closer examination of the data will reveal a real variation of the magnetic field which is caused caused by the power distribution network. Proper filtering is required to reduce the power line caused variations and reveal the strong signal of interest. It is not obvious that 60 or 50 hertz electromagnetic radiation is real, since in ordinary experience any power line “noise” is electrostatically coupled into a System (think 60 hertz hum on a stereo System) and is a fault that needs to be fixed. In this case however the variation in the magnetic field is induced by the power grid and is real. The magnetometer is simply and dutifully reporting the variation. These power line variations are to some extent present everywhere – even miles from the nearest power line. But obviously being close to power lines will increase the amplitude of the variations a lot. Often on a MagArrow survey the power line variations will be larger at one end of the survey area than the other. Poking in the GPS coordinates at the survey area nearest the larger variations into Google Earth will usually reveal the power lines from an aerial view – even if they are not visible on the ground. After applying a Fourier Frequency Transform on the MFAM data to identify the noise sources, 50 and 60 Hz noise amplitudes are easily observed. Also observable is the likely to be 20.8 Hz Schumann resonance of the third node and some other ultra-low frequency electro magnetic radiation produced naturally by the Earth. Harmonics of 60 Hz are also present. Another common question is “Why is the power line variations not a sine wave like the power line voltage?” Remember that voltages do not make magnetic fields. Only current generates magnetic fields, and the current being drawn is not a sine wave at all. Many loads, for example, only draw current at the voltage peaks. This makes for a non-sinusoidal magnetic field that is rich in harmonics. Also note that most power distribution System use a 3 phase topology. The ripple current in such a System will be 150 or 180 Hz. Thus you will often see large peaks in the power spectrum at these frequencies and their harmonics.

Hello, I wanted to try our MagEditor software, but it didn't accept any of the files I converted to 10 Hz, 20 Hz, 50 Hz, 100 Hz, and 1000 Hz CSV formats from Survey Manager. What's the reason and how can I fix it? My operating System is Windows 11 Home Single, and my computer specifications are:Processor: Intel(R) Core(TM) i9-14900HX (2.20 GHz)Installed RAM: 32.0 GB (usable: 31.6 GB)System type: 64-bit operating System, x64-based processor.

Our seismographs do not require periodic calibrations in that they do not have any adjustable parameters. With that being said, we do recommend that they are checked for performance and routine maintenance to include intensive analog tests of the acquisition circuitry. A reasonable interval would be around every 5 years for normal usage. During these tests we verify that the seismograph analog performance meets our specifications by using a seismic test System. This System incorporates a standard reference oscillator and precision resistor networks to inject known signals into the seismograph. We then use algorithms in our software to calculate the response and performance of the analog circuits. This "performance test" is run whenever we receive an instrument in for repair or evaluation. Some of our customers do prefer to have the performance of their instrument checked on a periodic basis especially if they are required by their clients, for example the NRC. We offer these nontraceable recertification’s to include a calibration certificate and test results for a fee of $300. If you would like us to perform performance verifications and a System evaluation please reserve an RMA and obtain shipping instructions.

If the System has a large amount of survey data, it may affect the data transfer rate. Sometimes a very slow SD card makes the System unresponsive; to the user this can look like a slow/bad network connection. Therefore, it might be useful to clean up the SD card and USB drive. Delete the Geometrics.log file on the USB drive. Clean up the survey data on the SD card: First, make sure that you have all the data that you need off of the SD card. Either download all survey data that you want to keep, or copy all of the contents of the SD card to another drive (perhaps to a PC). Delete all of the data on the SD card, doing one of the following: Use the UI to delete all of the surveys, then use the "Clean old files" button on the Admin page to empty the recycle bin on the SD card. This can be VERY slow, and because the MagArrow has a very simple web interface, the user will get no useful feedback. On a very full SD card, this process might take 30 minutes or so. Or.... Remove the SD card from the MagArrow and after copying any data that the user still hasn't saved to a PC, format it or delete everything on it, then re-insert it. Be careful not to lose the SD card or to let it drop into the inaccessible spaces in the instrument. If you format the SD card, the ExFAT format is preferable. If the customer can't get the data downloaded from the instrument (takes too long or stops), the data can be imported into a survey in Survey Manager, directly from the SD card (or from the PC hard drive to which the SD card data has been copied). Then the SD card can be cleaned up or formatted. With the new version of Survey Manager (you need to update that also, not just the instrument software), the user can import a large survey, including all of the files in subdirectories, by selecting the "acquinfo.txt" file in the root directory of the survey, from the SD card. More details about how to import/export SD card files using Survey Manager can be found in the post below: SD card files conversion

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.

Altitude refers to Meters Above Mean Sea Level. For both MagArrow I and II, the altitude is ellipsoidal and the earth model is WGS84. For additional information: Overview Reported elevations from MagArrow (and G-864 and MagEx) are the unedited values from the elevation field in the GNSS's GGA NMEA string. That value is the GNSS's calculated height above geoid; height above geoid is the standard meaning of the elevation field in the GGA NMEA string. But what does calculated height above geoid mean? Definitions GNSS - Global Navigation Satellite System GPS - The GNSS operated by the United States. Other Systems include GLONASS(Russia), Galileo (Europe), BeiDou (China), QZSS (Japan), IRNSS (India). Ellipsoid - A comparatively simple or abstract geometric model of Earth's surface. Geoid - A more complex model of Earth's surface that takes the place of what was previously called Mean Sea Level. At any particular latitude or longitude, the geoid's surface may be above or below the ellipsoid's by as much as a few hundred meters, depending on regional and local geography and geology. Reference datum - A specific model of Earth's shape (such as WGS84, EGM96...), including references to specific landmarks. Calculations A particular GNSS, for example the GPS System run by the United States, provides timing data to a receiver to calculate the receiver's position above or below a particular latitude and longitude on the surface of the ellipsoid. The GNSS receiver first uses that timing data to calculate its height over the ellipsoid, and then subtracts from it the local height of the geoid over the ellipsoid (or HAE), to arrive at the local height of the receiver over the geoid (or in old-fashioned terms, elevation over mean sea level): h - calculated height above geoid. This is the value reported in the GGA elevation field. H - height of the receiver over the ellipsoid (calculated from GNSS timing signals) N - local height of geoid over the ellipsoid, or HAE, per a lookup table or other local reference. h = H - N      Because the local height of the geoid over the ellipsoid is not provided by the GNSS, it must be provided locally, i.e. by the GNSS receiver, which may contain an internal database from which the local geoid height over ellipsoid (or HAE) can be found, based on the receiver's latitude and longitude. Small GNSS receivers contain small HAE databases, so the HAE value will not be exact. Some small receivers contain no HAE table at all; in this case HAE is deemed to be zero, so that the reported elevation is the uncorrected height over ellipsoid.​​​​​​​ A user of elevation data from Geometrics' MagArrow, G-864, and MagEx magnetometers may evaluate or adjust the reported values of the GGA elevation field and the GGA HAE field, by comparing the GGA HAE values to another source of local HAE data; this may particularly be useful for GNSSes that report a HAE equal to zero. Geometrics magnetometers do not currently record the values of a VDOP calculation, which offers an additional statistical estimate of the accuracy of the GNSS elevation measurement.

The only difference between the standard and SX version is the sensitivity is 4pT/rt-Hz and 20 pT/rt-Hz respectively. Here is an expected response with the magnetometer moving past a generic magnetic projectile: In this case the amplitude is about 1nT in total from peak to peak. The feature itself is quite distinguishable. This is assuming there is no noise in the System. Here is what the data looks like with 4pT/rt-Hz noise: You can see the general structure is still there but there is a little more wiggle on the trace that is associated with the noise of the System. Here is the data with 20 pT/rt-Hz noise: Again, here the structure is clearly visible but the data looks a bit noisier. With some signal processing technique, such as low pass filtering, noises can be further reduced. Please note that in real surveys, detecting 1nT peak-peak anomalies is always a big challenge even with the most sensitive magnetometers due to other noise sources, such as motion noises and environmental noises. Therefore, SX version is in general NOT the limiting factor for conducting surveys. To understand this concept better, you can use the magnetic gradient tool developed by our partner in the UK, Geomatrix Earth Science.

The only difference between the standard and SX version is the sensitivity is 4pT/rt-Hz and 20 pT/rt-Hz respectively. Here is an expected response with the magnetometer moving past a generic magnetic projectile: In this case the amplitude is about 2nT in total from peak to peak. The feature itself is quite distinguishable. This is assuming there is no noise in the System. Here is what the data looks like with 4pT/rt-Hz noise: You can see the general structure is still there but there is a little more wiggle on the trace that is associated with the noise of the System. Here is the data with 20 pT/rt-Hz noise: Again, here the structure is generally there but the data looks quite a bit noisier. So for smaller targets or more subtle anomalies they can be obscured or missed entirely. To understand this concept better, you can use the magnetic gradient tool developed by our partner in the UK, Geomatrix Earth Science.

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); } } }

hello Im having problems with MagArrow II data recording, and i'd love some help or advice.The issue definatly is a problem with the SD connection. Im having no troble connecting to the sensor's WIFI, but when heading to the "Data" page I get the massage "Unable to load servays. Verify that the SD card is insrted correctly. [...]" Indeed in Systemtest page i get a "SD card: Failed" test. Im aware of the SD's spring load mechanism, and tried many times in different configurations, including trying with different SD cards, updating the MagArrow software, but to no avail. The System just wont recognise any SD 🙁 Anyone had a similare problem? Any tips or suggestions?I'd love to get the sensor working again

Some of the Geometrics magnetometers include a feature, called the "File Cleanup Utility", that removes files that are no longer useful from storage on the instrument. The feature's accessible from the "Support" link in the Settings page in MagNav. You might be reading this post because that page directed you to read this post before using the utility. [This feature is not the same as the feature in MagNav to delete all of a survey's data. That feature removes information only from the database on the Android tablet, and doesn't remove any data in the instrument]. How do I use this feature? If this is the first time you've used this feature, please read the rest of this post before proceeding. Make sure that you're connected via WiFi to the instrument Go to the Settings page in MagNav Select the "Support" link. If your instrument supports this feature, the support page will include a link to "Delete project storage". Tap it. You should see a list of projects, with a name and a "Delete project" button for each project. This feature cleans up the data for all of the surveys in a project. Delete any projects for which you don't want to keep the in-instrument data. You can delete the data for all of the projects that you see, but there's no harm in leaving the files for projects that you're still using. Some projects will show a name similar to this: [c3bd]. These are early projects, in which the user-assigned name was not used in the instrument storage. It's OK to remove the data for these projects. Why do I need to do this? The magnetometers that use MagNav first store data on the instrument, and then sync (or download) the data to MagNav. Some instruments, for which this technical approach makes the instrument more reliable - MagEx, e.g. - do this automatically. Other instruments, such as those that allow disconnected acquisition (e.g. MagStation), store the data until the user re-connects to the instrument and manually starts the sync process. The data stored in the instrument is not of any use once it's been downloaded, but because deletion is slow and for other technical reasons, it's left on the file System in the instrument. As it accumulates, it could eventually interfere with the performance of the instrument and should therefore be deleted. Will this delete any data in the database in MagNav? No, this feature doesn't remove or change any data in the database in MagNav. When should I use this feature? Here are a few guidelines: Run this utility after deleting an entire project. Run this utility after completing a long field survey. Run this utility while doing other instrument maintenance. Run this utility after you've collected "a lot" of data. Run this utility when you have the impression that the instrument is unresponsive or is behaving sluggishly. Will anything bad happen if I forget to do this? Probably not any time soon; the storage Systems on the instrument are large and quite efficient. Geometrics tests instruments with amounts of data consistent with several years of regular use, and which show no performance issues relating to file storage performance. But don't let it go forever; follow the guidelines above. Can I delete data for projects that I'm still using? Yes, you can, as long as the data has already been synced to the instrument (that happens manually with MagStation and automatically with the other instruments). Once the data has been synced and is visible in MagNav, its presence in the instrument storage is no longer needed.

I have set up a G-882 System here at Geometrics and am receiving data and sending commands using TeraTerm (any terminal emulation program should work). When in normal use mode the Digital add on board sits in front of the G-882 and parses and acts on all commands coming in. There are two versions of the Digital Add On board, which are the GP120 and the GP140. The GP140 is a newer version of the Digital Add ON board. It is the GP140 Digital board that outputs all S/N (and other) information. I first set up with the GP140 board (the newer version). I find that the ""RESET" command does work - i.e. it goes into BYPASS mode for a couple seconds, then output the S/N and configuration information, and reverts to normal operation with the digital depth and altimeter information. But it only works every other time I send it. The first time nothing happens. Then I send it again and it works. This appears to be a bug in the GP140. For some commands the first command after power up or reset are ignored. The second time (and subsequent commands) are executed. The work around seems to be sending the RESET command twice. I also tried an older G-882 with the GP120 Digital board. The Reset (and other commands worked first time and every time. BTW, the Digital Board version is in the second line with the S/N information that is sent on power up or Reset. Some questions: 1) My configuration is one G-882 connected to a PC through the white junction box. Is this your configuration, or do you have concatenated G-882's? 2) Can you get the G-882 to accept any commands (like going into Bypass Mode)? I'm wondering if there is a open link in the command line from the PC to the Digital board.

Hello all, I'm currently working on a software project to integrate some Maggy's more effectively into our System. I see that when the magnetometer starts up it outputs it's serial number as well as some other useful information. I'd like to know if there is a serial command I can send that will initiate that information? A reset command for instance. I've read the manual and it suggests that I can simply send 'Reset' via a serial console but have tried it multiple times and have not been able to receive that initial startup string when I try it. Am I missing something? Or is there a terminator that I'm missing? I know it's possible as the digital console software can live reset the Maggy while it's sending data (same as what I want to achieve) so any help you could offer would be very gratefully accepted. For your information I've used multiple serial console softwares none of which have worked

Hello, guys.I need to ask some questions about grounding technique for Geode seismographs. Current territory that we need to investigate has strong electromagnetic pollution from nearbuy high voltage power line. When using 48 to 96 geophones many channels experiencing strong EMI interference in wide spectrum. So I want to ask the forum society for some advices on the grounding technique of Geode modules. Because in documentation there is only a mention of "grounding plug" on the side of boxes. But there is no advices on how to properly ground 4 or more modules, distanced 240 meters from one another. Even more when soil has different properties along streamer line (moisture etc). On geometrics.com could not find any instructions on rightful grounding technique. Maybe there is exist some sort of special grounding schemes for large number of modules in use. As I understand the better way is to have star topology for grounding (with one common rode point for several devices) when using spreaded device System. Because in other cases ground potential for different modules will vary. Maybe I asking a silly quastion but EMI problem anyway exist on long receivers arrays. That ruins noise/signal ratio and etc. Thanks.