Feature Request: Advanced Hex Transmit Tool (Raw Binary Uplink)

[Tane10]

1. Overview

I am proposing a new diagnostic and operational feature for the TinyGS Local Web Dashboard: the Advanced Hex Transmit tool. It will enable station operators to safely transmit raw binary payloads by inputting a hexadecimal string directly into the local UI.

2. The Problem

Currently, sending payloads via the console or MQTT treats inputs as 8-bit ASCII. This corrupts the byte-alignment required for precise binary packets, meaning users cannot accurately transmit:

• Compiled C-structs for satellite commanding.
• Custom protocol headers (like CCSDS or AX.25) containing non-printable bytes (e.g., 0x00).

3. Proposed Solution (Phase 1)

I have spec'd out a memory-safe, legally compliant "Fire and Forget" tool.

• Zero-Heap Backend: String-to-byte conversion uses a static buffer on the ESP32 to prevent memory fragmentation.
• Compliance Gatekeeper: Includes a mandatory T&C checkbox and a Callsign-to-Hex converter to help operators ID their stations.
• Audit Logging: Implements a browser-side localStorage transaction log (100-entry limit) with JSON export to satisfy regulatory auditing without using ESP32 resources.

4. Interactive Prototype for Review

To make reviewing this proposal as painless as possible, I have built a fully functional frontend prototype of the UI. It runs entirely in the browser (no hardware needed):
👉 Interactive Prototype

5. Full Technical Specifications

I have documented the exact constraints, CCSDS usage examples, and planned C++ architecture in a draft README on my fork here:
👉 Document

I am ready to write the C++ backend (RadioTxManager) and submit the PR, but I wanted to get the maintainers' and community's thoughts on this approach first to ensure it aligns with the project's goals. Let me know what you think!

[G4lile0]

First of all, welcome to the tinyGS community! It’s great to have you here, and I want to sincerely thank you for the effort you’ve put into this proposal. The documentation in your README and the JSFiddle prototype are excellent and show a high level of commitment to the project.

However, I believe there is a fundamental misunderstanding regarding how the platform handles data, which makes this specific implementation unnecessary and potentially problematic for the network.

1. Data Encoding: Base64 vs. ASCII

The core premise of the "ASCII limitation" is actually incorrect. TinyGS does not treat payloads as ASCII text.

• The Reality: All packets, whether received or sent via the console/MQTT, are handled using Base64 encoding.
• Binary Integrity: Because we use Base64, there is no corruption of byte-alignment. You can already send compiled C-structs, custom CCSDS headers, or any raw binary data with 100% integrity.
• Hex Support: Sending messages in HEX is already supported through the web interface without issues.

2. Why "Local" Transmission is Counterproductive

While a local transmit tool seems like a shortcut, moving the TX logic from the server to the local station's dashboard creates several critical issues:

• Collision & Noise: The server acts as a "traffic controller." It manages a transmission queue to ensure packets are sent sequentially. If stations transmit locally and independently, messages will overlap, creating radio interference (noise) that the satellite cannot decode.
• Network Ghosting: When the server handles the TX, it "knows" what is being sent and can filter that signal out from nearby stations. If you transmit locally, other stations will report your signal as a "new" packet, cluttering the database with ghost receptions.
• Satellite Safety: Most satellites have a maximum uplink rate. The server enforces these limits. Local bursts could easily overwhelm a satellite's buffer or violate its operational constraints.

Summary Comparison

Feature	Proposed Local Hex Tool	Current tinyGS Architecture
Data Handling	Raw Hex	Base64 (Full binary support)
Coordination	None (Risk of collisions)	Centralized Queuing
Network Health	Causes "Ghost" packets	Automatic Filtering
Flow Control	Unregulated	Rate-limited/Managed

Conclusion

While we appreciate the UI work, the transmission logic must remain centralized to ensure the stability of the satellite links and the integrity of the global station network.

I suggest diving deeper into the current Base64 implementation; you'll find that the "byte-perfect" control you’re looking for is already there!