diff --git a/CONTRIBUTE.md b/CONTRIBUTE.md
index c937f4a..1477f23 100644
--- a/CONTRIBUTE.md
+++ b/CONTRIBUTE.md
@@ -1,27 +1,302 @@
-# mnemolink
+# Contributing to MNemoLink
 
-Great to have you here. Here are a few ways you can help make this project better!
+Thank you for your interest in contributing to MNemoLink! This guide will help you understand the project structure, development workflow, and contribution process.
 
-## Learn & listen
+## Project Overview
 
-This section includes ways to get started with our open source project.
+MNemoLink is a Flutter desktop application that interfaces with MNemo v2 cave surveying devices. The application handles device communication, data transfer, processing, and export to various cave surveying formats.
 
-* Discord: TBA
+## Getting Started
 
-## Adding new features
+### Prerequisites
 
-This section includes advice on how to build new features for the project & what kind of process it includes. 
+- **Flutter SDK 3.5.4+**: [Installation Guide](https://docs.flutter.dev/get-started/install)
+- **Git**: Version control system
+- **Platform-specific tools**: See [README.md](README.md) for platform requirements
 
-* This is how we like people to add new features: TBA        
-* Here are some specifics on the coding style we prefer: TBA
-* This is how you send your pull request: TBA
-* You should include the following tests: TBA          
-* These are the updates we hope you make to the changelog: TBA
+### Development Environment Setup
 
-Don’t get discouraged!
+1. **Clone the repository**:
+   ```bash
+   git clone https://github.com/SebKister/MNemoLink.git
+   cd MNemoLink
+   ```
 
-# Documentation
+2. **Install dependencies**:
+   ```bash
+   make install  # Or flutter pub get
+   ```
 
-This section includes any help you need with the documentation and where it can be found. Code needs explanation, and sometimes those who know the code well have trouble explaining it to someone just getting into it. 
+3. **Verify setup**:
+   ```bash
+   flutter doctor
+   flutter analyze
+   ```
 
-~ Feel free to help us with documentation ~
\ No newline at end of file
+4. **Run the application**:
+   ```bash
+   make run  # Or flutter run
+   ```
+
+## Code Organization
+
+### Directory Structure
+
+```
+lib/
+├── main.dart                 # Application entry point
+├── models/                   # Data models
+│   ├── shot.dart            # Individual survey measurement
+│   ├── section.dart         # Survey section containing shots
+│   ├── section_list.dart    # Collection of sections
+│   ├── survey_quality.dart  # Survey quality assessment
+│   └── enums.dart           # Shared enumerations
+├── services/                # Business logic layer
+│   ├── device_communication_service.dart  # Serial device communication
+│   ├── network_service.dart               # Network-based communication
+│   ├── data_processing_service.dart       # DMP data parsing
+│   ├── file_service.dart                  # File I/O operations
+│   └── firmware_update_service.dart       # Update management
+├── widgets/                 # UI components
+│   ├── cli_interface.dart   # Command line interface
+│   ├── connection_status_bar.dart         # Device status display
+│   ├── data_toolbar.dart    # Data manipulation tools
+│   └── sectioncard.dart     # Survey section visualization
+└── exporters/               # Format-specific export modules
+    ├── excelexport.dart     # Excel spreadsheet export
+    ├── survexporter.dart    # Survex format export
+    └── thexporter.dart      # Therion format export
+```
+
+### Architecture Principles
+
+1. **Service-Oriented Architecture**: Business logic is separated into focused services
+2. **Model-View Separation**: UI widgets consume data through well-defined models
+3. **Platform Abstraction**: Device communication abstracts platform differences
+4. **Export Modularity**: Each surveying format has its own export module
+
+## Development Workflow
+
+### 1. Issue Creation
+
+- Check existing issues before creating new ones
+- Use issue templates when available
+- Provide clear reproduction steps for bugs
+- Include system information (OS, Flutter version, device model)
+
+### 2. Branch Strategy
+
+- **Base branches**: Work from `master` or current development branch
+- **Feature branches**: Use descriptive names: `feature/survey-quality-scoring`
+- **Bug fixes**: Use format: `fix/depth-calculation-precision`
+- **Documentation**: Use format: `docs/api-documentation-update`
+
+### 3. Development Process
+
+1. **Create feature branch**:
+   ```bash
+   git checkout -b feature/your-feature-name
+   ```
+
+2. **Make changes following our guidelines** (see sections below)
+
+3. **Test thoroughly**:
+   ```bash
+   flutter test
+   flutter analyze
+   ```
+
+4. **Commit with descriptive messages**:
+   ```bash
+   git commit -m "Add survey quality scoring algorithm
+   
+   - Implement depth consistency validation
+   - Add LRUD measurement quality checks
+   - Include shot angle variance analysis"
+   ```
+
+## Coding Standards
+
+### Dart/Flutter Guidelines
+
+1. **Follow Flutter style guide**: Use `flutter analyze` and address all warnings
+2. **Documentation**: Document all public APIs with dartdoc comments
+3. **Null safety**: Leverage Dart's null safety features consistently
+4. **Error handling**: Use proper exception handling and user feedback
+
+### Code Style
+
+```dart
+// ✅ Good: Clear class documentation
+/// Service for processing MNemo binary data and converting to survey models
+class DataProcessingService {
+  /// Process raw binary transfer buffer into survey sections
+  Future<DataProcessingResult> processTransferBuffer(
+    List<int> transferBuffer, 
+    UnitType unitType
+  ) async {
+    // Implementation...
+  }
+}
+
+// ✅ Good: Descriptive variable names
+final conversionFactor = unitType == UnitType.metric ? 1.0 : 3.28084;
+final sectionResult = await _processSection(transferBuffer, cursor, conversionFactor);
+
+// ❌ Avoid: Unclear abbreviations
+final cf = unitType == UnitType.metric ? 1.0 : 3.28084;
+final sr = await _processSection(tb, c, cf);
+```
+
+### File Organization
+
+1. **Imports**: Group and order imports (Dart, Flutter, external packages, local)
+2. **Class structure**: Constants, fields, constructors, public methods, private methods
+3. **Method length**: Keep methods focused and under 50 lines when possible
+4. **Single responsibility**: Each class should have one clear purpose
+
+### Testing Guidelines
+
+1. **Unit tests**: Test business logic in services and models
+2. **Widget tests**: Test UI components in isolation
+3. **Integration tests**: Test complete workflows (device communication, data processing)
+4. **Test naming**: Use descriptive test names that explain the scenario
+
+```dart
+// ✅ Good test naming
+test('should convert centimeters to meters when processing DMP data', () {
+  // Test implementation
+});
+
+test('should detect corrupted shot data when magic bytes are invalid', () {
+  // Test implementation  
+});
+```
+
+### Performance Considerations
+
+1. **Async operations**: Use async/await properly for I/O operations
+2. **Memory management**: Dispose of resources (streams, controllers) properly
+3. **Large data sets**: Handle large DMP files efficiently with streaming
+4. **UI responsiveness**: Keep heavy processing off the main thread
+
+## Pull Request Process
+
+### Before Submitting
+
+1. **Run all checks locally**:
+   ```bash
+   flutter analyze     # Static analysis
+   flutter test        # Run test suite
+   make build_linux    # Test build process
+   ```
+
+2. **Update documentation**:
+   - Update relevant documentation files
+   - Add dartdoc comments for new public APIs
+
+3. **Verify CI requirements**:
+   - All GitHub Actions checks must pass
+   - No breaking changes without discussion
+
+## GitHub Actions Workflow
+
+Our CI/CD pipeline includes several checks that must pass:
+
+### 1. Linter (Required)
+- Runs `flutter analyze` for static code analysis
+- Must pass before builds can run
+- Enforces code style and catches potential issues
+
+### 2. Build Matrix (Required)
+- **Linux**: Ubuntu with GTK dependencies
+- **macOS**: Latest macOS with Xcode
+- **Windows**: Latest Windows with MSVC
+- **iOS**: macOS with Xcode 16.4+
+- **Android**: Ubuntu with Java 17
+
+### 3. Build Requirements
+- All platforms must build successfully
+- No compilation errors or warnings
+- Dependencies must resolve correctly
+
+### Common CI Failures
+
+| Issue | Solution |
+|-------|----------|
+| `flutter analyze` warnings | Fix all static analysis warnings |
+| Missing dependencies | Update `pubspec.yaml` and run `flutter pub get` |
+| Platform build failure | Test locally with `make build_[platform]` |
+| Test failures | Run `flutter test` locally and fix failing tests |
+
+## Contributing Guidelines
+
+### Issue Reporting
+
+**Bug Reports** should include:
+- MNemoLink version
+- Operating system and version
+- Connected MNemo device model and firmware
+- Steps to reproduce
+- Expected vs actual behavior
+- Relevant log output or error messages
+
+**Feature Requests** should include:
+- Clear use case description
+- Proposed implementation approach
+- Impact on existing functionality
+- Cave surveying context and standards
+
+### Code Contributions
+
+1. **Start small**: Begin with documentation fixes or small bug fixes
+2. **Discuss first**: Open an issue for significant changes before implementation
+3. **Follow patterns**: Study existing code to understand established patterns
+4. **Test thoroughly**: Include comprehensive tests for new functionality
+5. **Document changes**: Update relevant documentation and comments
+
+### Communication
+
+- **Be respectful**: Maintain professional and inclusive communication
+- **Be specific**: Provide concrete examples and clear explanations
+- **Be patient**: Reviews and responses may take time
+- **Ask questions**: Don't hesitate to ask for clarification or help
+
+## Cave Surveying Context
+
+Understanding cave surveying helps in making informed contributions:
+
+### Core Concepts
+
+- **Stations**: Survey points connected by shots
+- **Shots**: Measurements between stations (distance, bearing, inclination)
+- **LRUD**: Passage dimensions (Left, Right, Up, Down) from survey line
+
+### Data Quality
+
+- **Accuracy**: Cave surveys require high precision for mapping
+- **Validation**: Check for measurement inconsistencies and errors
+- **Standards**: Follow cave surveying conventions for data formats
+
+### Export Formats
+
+- **Survex (.svx)**: Open source cave surveying software format
+- **Therion (.th)**: Cave mapping and 3D modeling software
+- **Excel (.xlsx)**: General data analysis and visualization
+
+## Resources
+
+- **Flutter Documentation**: https://docs.flutter.dev/
+- **Dart Style Guide**: https://dart.dev/guides/language/effective-dart/style
+- **Cave Surveying**: https://caves.org/section/survey/
+- **Project Issues**: https://github.com/SebKister/MNemoLink/issues
+- **MNemo v2 Documentation**: https://github.com/SebKister/MNemoV2-Documentation
+
+## Getting Help
+
+- **Questions**: Open a GitHub issue with the "question" label
+- **Bugs**: Follow the bug report template
+- **Feature ideas**: Open a discussion or feature request issue
+- **Code review**: Request review from maintainers in pull requests
+
+Thank you for contributing to MNemoLink and supporting the cave surveying community!
\ No newline at end of file
diff --git a/README.md b/README.md
index 3103152..f7c4141 100644
--- a/README.md
+++ b/README.md
@@ -1,64 +1,167 @@
-# mnemolink
+# MNemoLink
 
-Computer interface software for MNemo v2
+MNemoLink is a Flutter desktop application that interfaces with MNemo v2 cave surveying devices. It handles device communication, data transfer, processing, and export to various cave surveying formats.
+
+## Features
+
+- **Device Communication**: Connect to MNemo devices via USB serial or WiFi network
+- **Data Processing**: Parse and validate DMP (Data Memory Package) files from MNemo devices
+- **Multiple Export Formats**: Export survey data to Excel (.xlsx), Survex (.svx), and Therion (.th) formats
+- **Real-time CLI Interface**: Direct command-line interface for device control and data retrieval
+- **Cross-platform Support**: Full functionality on Windows, Linux, and macOS; limited functionality on Android and iOS
+- **Firmware Updates**: Manage MNemo device firmware updates directly from the application
+
+## Architecture Overview
+
+The application follows a service-oriented architecture with clear separation between UI, business logic, and device communication:
+
+### Core Components
+
+- **models/** - Data models (Shot, Section, SectionList, SurveyQuality, Enums)
+- **services/** - Business logic services for device communication, networking, data processing, file operations, and firmware updates
+- **widgets/** - UI components including CLI interface, connection status, network panels, and data visualization
+
+### Key Services
+
+1. **DeviceCommunicationService** - Handles serial communication with MNemo devices
+2. **NetworkService** - Manages network-based device discovery and data transfer
+3. **DataProcessingService** - Processes raw survey data into structured sections
+4. **FileService** - Handles DMP file operations and exports to Excel/Survex/Therion formats
+5. **FirmwareUpdateService** - Manages firmware and software update operations
+
+### Data Flow
+
+1. Device connection via serial or network
+2. Raw data transfer from MNemo device (DMP format)
+3. Data processing into survey sections with shots
+4. Export to various cave surveying formats
 
 ## Getting Started
 
-This project is a Flutter application.
+### Prerequisites
+
+- **Flutter SDK 3.5.4+**: [Installation Guide](https://docs.flutter.dev/get-started/install)
+- **Platform-specific tools**: See platform sections below for detailed requirements
+
+### Quick Start
 
-A few resources to get you started if this is your first Flutter project:
+1. **Clone the repository**:
+   ```bash
+   git clone https://github.com/SebKister/MNemoLink.git
+   cd MNemoLink
+   ```
 
-- [Lab: Write your first Flutter app](https://docs.flutter.dev/get-started/codelab)
-- [Cookbook: Useful Flutter samples](https://docs.flutter.dev/cookbook)
+2. **Install dependencies**:
+   ```bash
+   make install  # Or flutter pub get
+   ```
 
-For help getting started with Flutter development, view the
-[online documentation](https://docs.flutter.dev/), which offers tutorials,
-samples, guidance on mobile development, and a full API reference.
+3. **Run the application**:
+   ```bash
+   make run      # Or flutter run
+   ```
 
 
-## BUILD AND DEBUG
+## Platform-Specific Setup
 
 ### Windows
 
-On Windows, you can find precise indication on installation requirements [here](https://docs.flutter.dev/get-started/install/windows/desktop).
+Follow the [Flutter Windows installation guide](https://docs.flutter.dev/get-started/install/windows/desktop) for desktop development.
+
+For Android development, follow [this guide](https://docs.flutter.dev/get-started/install/windows/mobile?tab=vscode).
+
+**Build Commands:**
+```bash
+make build_windows       # Build Windows release
+make build_androidFatAPK # Build Android fat APK
+make build_androidAPK    # Build Android split APKs
+make build_appBundle     # Build Android app bundle
+```
+
+### Linux / Windows 11 + WSL2
+
+We provide a VS Code devcontainer for consistent development environments. Requirements:
+- VS Code
+- Docker
+- Devcontainer Extension (`ms-vscode-remote.remote-containers`)
+
+**Setup:**
+```bash
+git clone https://github.com/SebKister/MNemoLink.git
+cd MNemoLink
+code -n $(pwd)  # Open in VSCode
+```
+
+Then `Ctrl+P` → "Dev Containers: Rebuild and Reopen in Container"
+
+**Build Commands:**
+```bash
+make build_linux    # Build Linux release
+```
+
+### macOS
 
-Following those steps and getting a `flutter doctor` result similar to the one shown is enough to build and run the MNemoLink project.
+Follow the [Flutter macOS installation guide](https://docs.flutter.dev/get-started/install/macos/desktop) for desktop development.
 
-To build the Android app you'll additionally need to follow [this guide](https://docs.flutter.dev/get-started/install/windows/mobile?tab=vscode)
+For mobile development:
+- [Android guide](https://docs.flutter.dev/get-started/install/macos/mobile-android?tab=vscode)
+- [iOS guide](https://docs.flutter.dev/get-started/install/macos/mobile-ios)
 
-### Linux or Windows 11 + WSL2
-On Linux and Windows 11 + WSL2, we offer a `VS CODE` devcontainer https://code.visualstudio.com/docs/devcontainers/containers to improve the speed and portability of the development environment.
+**Build Commands:**
+```bash
+make build_macos     # Build macOS release
+make build_iosRelease # Build iOS release
+```
 
-It requires `VS Code`, Docker and Devcontainer Extension (`ms-vscode-remote.remote-containers`) installed.
+## Development Commands
 
-Then follow the instructions:
+### Setup and Dependencies
+```bash
+make install         # Install Flutter dependencies and perform cleanup
+make clean          # Remove build artifacts and Flutter cache
+```
 
+### Code Quality
 ```bash
-`git clone https://github.com/SebKister/MNemoLink.git`
-cd MnemoLink
-code -n $(pwd)  # Open current directory in VSCode
+flutter analyze     # Run static analysis (uses flutter_lints)
+flutter test        # Run tests
 ```
 
-Then `CTRL + P` and select `Dev Containers: Rebuild and Reopen in Container`
+## Testing
 
-This operation will take some time to build and launch a new environment. Once the environment is started, open a new terminal and type:
+Tests are located in the `test/` directory.
 
+Run tests with:
 ```bash
-make install  # install all dependencies
-make run      # run the application in debug mode
+flutter test
 ```
 
-### MAC OS
-On Mac, you can find precise indication on installation requirements [here](https://docs.flutter.dev/get-started/install/macos/desktop).
+## Device Communication
+
+The application communicates with MNemo devices through:
+- **Serial communication** (USB connection)
+- **Network communication** (WiFi connection via IP address)
+- **CLI command interface** for device control and data retrieval
+
+## Export Formats
 
-Following those steps and getting a `flutter doctor` result similar to the one shown is enough to build and run the MNemoLink project.
+The application supports multiple cave surveying export formats:
+- **DMP** - Native MNemo format
+- **Excel (.xlsx)** - Spreadsheet format for data analysis
+- **Survex (.svx)** - Open source cave surveying software format
+- **Therion (.th)** - Cave mapping and 3D modeling software format
 
-To build the Android app you'll additionally need to follow [this guide](https://docs.flutter.dev/get-started/install/macos/mobile-android?tab=vscode)
+## Contributing
 
-To build the iOS app you'll additionally need to follow [this guide](https://docs.flutter.dev/get-started/install/macos/mobile-ios)
+Please read [CONTRIBUTE.md](CONTRIBUTE.md) for detailed guidelines on:
+- Code organization and architecture
+- Development workflow and standards
+- Pull request process
+- GitHub Actions CI/CD pipeline
 
-## DOCUMENTATION
-There's no separate documentation existing for MNemolink.
+## Documentation
 
-Features requiring documentation should be added to the [MNemo V2 Documenation](https://github.com/SebKister/MNemoV2-Documentation) repository.
+- **Project Documentation**: See [CONTRIBUTE.md](CONTRIBUTE.md) for comprehensive development guidelines
+- **DMP File Format**: See `doc/MNemo DMP File Format - Complete Documentation.md` for technical specification
+- **MNemo v2 Hardware**: [MNemo V2 Documentation](https://github.com/SebKister/MNemoV2-Documentation)
 
diff --git a/doc/MNemo DMP File Format - Complete Documentation.md b/doc/MNemo DMP File Format - Complete Documentation.md
new file mode 100644
index 0000000..4ac99ae
--- /dev/null
+++ b/doc/MNemo DMP File Format - Complete Documentation.md	
@@ -0,0 +1,224 @@
+# MNemo v2 DMP File Format - Complete Documentation
+
+## Overview
+
+The DMP (Data Memory Package) file format is the native binary format used by MNemo v2 cave surveying instruments to store survey data. This document provides complete technical specification of the file format, including all versions and implementation details.
+
+## File Format Evolution
+
+The DMP format has evolved through several versions:
+- **Version 2**: Basic format with core measurements
+- **Version 3**: Added temperature and timestamp data
+- **Version 4**: Added LRUD (Left/Right/Up/Down) passage measurements  
+- **Version 5**: Added magic byte validation for data integrity (firmware 2.6.0+)
+
+## File Structure
+
+DMP files have **NO GLOBAL HEADER** and consist of multiple sections, each containing:
+1. Section Header (13 bytes)
+2. Variable number of Shot Records (35 bytes each)
+3. Section Terminator (35 bytes with EOC shot type)
+
+### Endianness and Data Types
+- **Byte Order**: Little-endian for multi-byte values
+- **Integers**: 16-bit signed integers (2 bytes)
+- **Measurements**: Stored as integers * 100 (e.g., 1.25m stored as 125)
+- **Angles**: Stored as degrees * 10 (e.g., 45.6° stored as 456)
+
+## Section Header Format (13 bytes)
+
+| Offset | Size | Field | Description |
+|--------|------|-------|-------------|
+| 0 | 1 | File Version | Format version (2, 3, 4, or 5) |
+| 1 | 1 | Magic Byte A | 68 (0x44) - Version 5+ only |
+| 2 | 1 | Magic Byte B | 89 (0x59) - Version 5+ only |
+| 3 | 1 | Magic Byte C | 101 (0x65) - Version 5+ only |
+| 4 | 1 | Year | Year offset from 2000 (e.g., 24 = 2024) |
+| 5 | 1 | Month | Month (1-12) |
+| 6 | 1 | Day | Day of month (1-31) |
+| 7 | 1 | Hour | Hour (0-23) |
+| 8 | 1 | Minute | Minute (0-59) |
+| 9 | 1 | Name Char 1 | First character of section name |
+| 10 | 1 | Name Char 2 | Second character of section name |
+| 11 | 1 | Name Char 3 | Third character of section name |
+| 12 | 1 | Direction | Survey direction: 0=IN, 1=OUT |
+
+**Notes:**
+- Magic bytes (68, 89, 101) provide data integrity validation in version 5+
+- Section names are exactly 3 ASCII characters
+- Direction indicates survey flow: IN=going into cave, OUT=coming out
+
+## Shot Record Format (35 bytes)
+
+### Magic Bytes and Shot Type (4 bytes)
+| Offset | Size | Field | Description |
+|--------|------|-------|-------------|
+| 0 | 1 | Magic Byte A | 57 (0x39) - Version 5+ only |
+| 1 | 1 | Magic Byte B | 67 (0x43) - Version 5+ only |
+| 2 | 1 | Magic Byte C | 77 (0x4D) - Version 5+ only |
+| 3 | 1 | Shot Type | 0=CSA, 1=CSB, 2=STD, 3=EOC |
+
+### Core Measurements (14 bytes)
+| Offset | Size | Field | Description |
+|--------|------|-------|-------------|
+| 4 | 2 | Heading IN | Compass bearing entering station (degrees * 10) |
+| 6 | 2 | Heading OUT | Compass bearing leaving station (degrees * 10) |
+| 8 | 2 | Length | Shot length in cm |
+| 10 | 2 | Depth IN | Depth at entering station in cm |
+| 12 | 2 | Depth OUT | Depth at leaving station in cm |
+| 14 | 2 | Pitch IN | Inclination entering station (degrees * 10) |
+| 16 | 2 | Pitch OUT | Inclination leaving station (degrees * 10) |
+
+### LRUD Data (8 bytes) - Version 4+ only
+| Offset | Size | Field | Description |
+|--------|------|-------|-------------|
+| 18 | 2 | Left | Passage width to left in cm |
+| 20 | 2 | Right | Passage width to right in cm |
+| 22 | 2 | Up | Passage height up in cm |
+| 24 | 2 | Down | Passage height down in cm |
+
+### Environmental & Time Data (5 bytes) - Version 3+ only
+| Offset | Size | Field | Description |
+|--------|------|-------|-------------|
+| 26 | 2 | Temperature | Temperature reading (device units) |
+| 28 | 1 | Hour | Hour when shot was taken (0-23) |
+| 29 | 1 | Minute | Minute when shot was taken (0-59) |
+| 30 | 1 | Second | Second when shot was taken (0-59) |
+
+### Metadata (4 bytes)
+| Offset | Size | Field | Description |
+|--------|------|-------|-------------|
+| 31 | 1 | Marker Index | Station marker identifier |
+| 32 | 1 | End Magic A | 95 (0x5F) - Version 5+ only |
+| 33 | 1 | End Magic B | 25 (0x19) - Version 5+ only |
+| 34 | 1 | End Magic C | 35 (0x23) - Version 5+ only |
+
+## Shot Types
+
+| Value | Enum | Description |
+|-------|------|-------------|
+| 0 | CSA | Compass Shot A - First reading of measurement |
+| 1 | CSB | Compass Shot B - Second reading of measurement |
+| 2 | STD | Standard Shot - Normal survey measurement |
+| 3 | EOC | End of Cave/Section - Marks section termination |
+
+## Section Termination
+
+Each section ends with a special shot record containing:
+- Shot type = 3 (EOC)
+- All measurement fields = 0
+- Proper magic bytes for version 5+
+- Format: `57 67 77 3 [28 bytes of zeros] 95 25 35`
+
+## Data Conversion
+
+### Distance Measurements
+- **Storage**: Integer centimeters
+- **Conversion**: divide by 100 for meters
+- **Imperial**: multiply by 3.28084/100 for feet
+
+### Angular Measurements  
+- **Storage**: Integer degrees * 10
+- **Conversion**: divide by 10 for degrees
+- **Range**: 0-3599 (0.0° to 359.9°)
+
+### Temperature
+- **Storage**: Raw device units
+- **Conversion**: Device-specific calibration required
+
+## File Processing Algorithm
+
+1. **Start at file beginning** (no global header)
+2. **For each section:**
+   - Scan for valid file version byte (2, 3, 4, or 5)
+   - Validate magic bytes if version 5+
+   - Read section metadata (date, name, direction)
+   - Process shots until EOC type found
+   - Validate shot magic bytes if version 5+
+3. **Continue until end of file**
+
+## Error Handling
+
+### Broken Segments
+- Invalid magic bytes indicate data corruption
+- Parser should attempt recovery by scanning for next valid section
+- Sections with broken segments should be flagged for user review
+
+### Data Validation
+- Shot lengths must be positive and reasonable
+- Angles must be within valid ranges (0-3599)
+- Depth changes should correlate with shot lengths and inclinations
+
+### Problematic Shots
+A shot is considered problematic if:
+- Length < |depth_out - depth_in| 
+- This indicates measurement errors or data corruption
+- MNemoLink can calculate corrected lengths using trigonometry
+
+## Version Compatibility
+
+| Feature | Version 2 | Version 3 | Version 4 | Version 5 |
+|---------|-----------|-----------|-----------|-----------|
+| Core measurements | ✓ | ✓ | ✓ | ✓ |
+| Temperature/Time | ✗ | ✓ | ✓ | ✓ |
+| LRUD data | ✗ | ✗ | ✓ | ✓ |
+| Magic byte validation | ✗ | ✗ | ✗ | ✓ |
+
+## Implementation Notes
+
+### Parser Considerations
+- Always validate buffer bounds before reading
+- Handle corrupted data gracefully
+- Support version detection and appropriate field parsing
+- Implement little-endian integer reading
+- Preserve original data for re-export
+
+### Memory Layout
+- File data is stored sequentially without padding
+- Multi-byte values use little-endian byte order
+- No alignment requirements for field boundaries
+
+### Export Compatibility
+The DMP format can be converted to standard cave surveying formats:
+- **Survex (.svx)**: Station-to-station measurements
+- **Therion (.th)**: Complete cave map data
+- **Excel (.xlsx)**: Tabular data for analysis
+
+## Example Binary Data
+
+### Section Header (Version 5)
+```
+05 44 59 65 18 0C 0F 0E 1E 41 42 43 00
+│  │  │  │  │  │  │  │  │  │  │  │  └─ Direction: IN
+│  │  │  │  │  │  │  │  │  │  │  └─ Name: 'C'  
+│  │  │  │  │  │  │  │  │  │  └─ Name: 'B'
+│  │  │  │  │  │  │  │  │  └─ Name: 'A'
+│  │  │  │  │  │  │  │  └─ Minute: 30
+│  │  │  │  │  │  │  └─ Hour: 14
+│  │  │  │  │  │  └─ Day: 15
+│  │  │  │  │  └─ Month: 12
+│  │  │  │  └─ Year: 24 (2024)
+│  │  │  └─ Magic C: 101
+│  │  └─ Magic B: 89  
+│  └─ Magic A: 68
+└─ Version: 5
+```
+
+### Standard Shot Record (Version 5)
+```
+39 43 4D 02 68 01 70 01 2C 01 90 01 94 01 F4 00 E8 00
+│  │  │  │  │     │     │     │     │     │     │     └─ LRUD data...
+│  │  │  │  │     │     │     │     │     │     └─ Pitch OUT: 40.0°
+│  │  │  │  │     │     │     │     │     └─ Pitch IN: 40.4°  
+│  │  │  │  │     │     │     │     └─ Depth OUT: 4.00m
+│  │  │  │  │     │     │     └─ Depth IN: 3.68m
+│  │  │  │  │     │     └─ Length: 3.00m
+│  │  │  │  │     └─ Heading OUT: 36.8°
+│  │  │  │  └─ Heading IN: 36.0°
+│  │  │  └─ Shot Type: STD
+│  │  └─ Magic C: 77
+│  └─ Magic B: 67
+└─ Magic A: 57
+```
+
+This documentation provides complete technical details for implementing DMP file parsers and ensuring compatibility with MNemo v2 devices across all firmware versions.
\ No newline at end of file