Utilizing the NABU Network Adapter

[Super_Derek]

Proposal for RS422 to RF Transmission Using NABU Network Adapter and Teleview TVB599/LAN Network Modulator
Revision Number: 1.0

So I snagged at NABU Network Adapter and I refuse to consider it a paper weight and thought about creating the NABU network on a small scale. In the 1980s, achieving 6 Mbps data transmission with the NABU Network Adapter was atypical over cable TV networks. Standard technologies and analog transmission protocols, like NTSC and analog modems, operated at lower speeds. The NABU Network Adapter likely utilized a proprietary protocol, using advanced modulation techniques and unused cable TV spectrum portions (that I would like to know more about ).

Theory:
The NABU Network Adapter might have operated within the VHF or UHF frequency ranges common to that era, providing necessary bandwidth for the 6 Mbps data rates. Possible modulation used was most likely Quadrature Amplitude Modulation (QAM) or Phase Modulation.

Introduction:
This project aims to integrate a NABU Network Adapter, a device from the early 1980s known for its high-speed data transmission capabilities with modern telecomm/networking COTS equipment. The focus is on establishing a connection with the NABU network adapter using the Teleview TVB599/LAN Network Modulator and an HF2211A DTU Serial Server for the sole purpose of seeing it function.

COTS Component Overview:
1. HF2211A DTU Serial Server RS232/RS485/RS422 Serial Port to WiFi Ethernet Modbus:
- Converts RS422 serial data to Ethernet.
- Supports RS232, RS485, RS422; WiFi and Ethernet connectivity; Modbus protocol.
- Configuration:
- Set RS422 communication parameters: baud rate, parity, data bits, stop bits.
- Network configuration: Assign IP addresses, subnet masks, gateways for network integration.
https://www.micros.com.pl/mediaserver/i ... hf2211.pdf

2. Teleview TVB599/LAN Network Modulator:
- Converts Ethernet to an F-type RG-6 RF signal compatible with NABU Network Adapter frequencies.
- Frequency Compatibility: Integrated VHF/UHF/L-BAND RF output up-converter.
- Supports transport stream from RTP/UDP over Ethernet.
- Offers various modulation options for flexibility.
https://www.teleview.com/modulators/tvb599lan

3. NABU Network Adapter:
- Converts RF signal back to RS422.
- High-speed (6 Mbps), addressable communications device.
- Ensure compatibility with RF output format of Teleview TVB599/LAN. Crux.

System Diagram:
[PC USB Serial Emulator] --RS422--> [HF2211A DTU Serial Server] --Ethernet--> [Teleview TVB599/LAN Network Modulator] --RG6 Coaxial Cable--> [NABU Network Adapter] --RS422--> [NABU Computer]

Modulation Hypothesis
Quadrature Amplitude Modulation (QAM) could have been utilized to achieve high data transmission rates, such as 6 Mbps, with the NABU Network Adapter in the 1980s, we need to consider the technological context of that era, the inherent characteristics of QAM, and its application in early digital communication systems.

Context of the 1980s:
During the 1980s, the majority of cable TV systems were analog. However, there were significant advancements in digital communication technologies. Digital modulation techniques like QAM were beginning to find application in more advanced communication systems, although their use in consumer-level technology was not widespread.

Basics of QAM:
QAM combines both amplitude and phase modulation to transmit two analog signal streams or two digital bit streams simultaneously. This combination allows for a higher data rate compared to simpler modulation schemes.
In the context of cable TV, QAM would enable the transmission of digital signals over the analog infrastructure.

Potential Application in the NABU Network:
The NABU Network, might have employed an advanced form of QAM to maximize the data transmission capacity of the existing cable TV infrastructure. Given the bandwidth limitations of VHF/UHF channels used in cable TV, QAM could have been implemented to efficiently use this bandwidth. For instance, using a higher-order QAM (like 64-QAM or 128-QAM) could theoretically increase the data rate. However, this would also require more sophisticated error correction and signal processing technologies to mitigate the higher susceptibility to noise and signal distortion, especially in an analog cable system.

Limitations and Challenges:
Achieving 6 Mbps in the 1980s would have been a significant challenge. Cable TV systems of that time were not optimized for such high-speed digital data transmission. The noise and interference inherent in analog cable systems would have posed additional challenges for reliable high-speed data transmission using QAM.

The NABU Network Adapter might have used a proprietary or advanced implementation of QAM, possibly a higher-order variant, which was not standard at the time. To support this, the network infrastructure and the adapter itself would have required advanced signal processing capabilities, likely involving custom-designed hardware and software. This implementation could have been a pioneering effort in pushing the limits of data transmission over cable TV networks, setting an unheard of precedent for later developments in digital cable technology. It is a mystery why the company was not bought out by a government contractor.

Considerations:
1. In-Depth System Testing for data transmission accuracy and reliability.
2. Signal Integrity and Amplification needs along the coaxial cable.
3. Protocol and Data Format Compatibility between NABU Adapter and Teleview TVB599/LAN. Crux.
4. Detailed inspection of all internal components.
5. Consultation with experts in retro comms and software systems.

Integration with Existing Firmware and Software:
- Assess if NABU Adapter's firmware and NABU computer's software negate the need for additional drivers.
- Integration with Teleview TVB599/LAN may require hardware interfacing and software mediation for protocol translation. Crux.

Integrating the Nabu Network Adapter with a modern system like the Teleview TVB599/LAN would require:
- Protocol Translation
- Hardware Interfacing
- Software Mediation: Updating the PC USB serial adapter software to utilize features of the NABU Network Adapter.

While integrating the NABU Network Adapter with modern COTS telecom/network equipment is theoretically possible, it would require a detailed understanding of both old and new systems, along with possible custom hardware and software solutions to bridge the technological gap. It's a stretch, but hey, I find it interesting to think about and maybe it could be scaled up for a better use case.

More to follow after I crack the Adapter open and inspecting all components.

[LeoBinkowski]

Actually it used not QAM, but QPSK modulation. I am 100% positive of this fact.

[Super_Derek]

Interesting, thanks!

[Super_Derek]

Proposal for RS422 to RF Transmission Using NABU Network Adapter and Teleview TVB599/LAN Network Modulator Using QPSK
Revision Number: 1.1


Introduction:
We have acquired a NABU Network Adapter, with a proprietary protocol and QPSK modulation, it reached download speeds of up to 6 Mbps. This project aims to combine this vintage technology with modern telecommunications and networking equipment, particularly the Teleview TVB599/LAN Network Modulator and the HF2211A DTU Serial Server, to resurrect the NABU network on a smaller contemporary scale.

Technical Corrections
Modulation Technique:
Correction: The NABU Network Adapter utilized QPSK modulation, not QAM, to achieve data transmission speeds of up to 6 Mbps over cable TV networks. This revelation significantly alters our technical approach, as QPSK offers distinct advantages in terms of bandwidth efficiency and noise resilience, particularly within the VHF and UHF frequency ranges.
System Design and Component Function:
Updated Analysis: Each component's role within the project has been re-evaluated in the context of QPSK modulation:
The 74LS245 bus transceiver remains vital for bidirectional communication between digital processing units and modulation circuitry.
The 74LS138 decoder/demultiplexer's importance is heightened for signal routing and control signal generation in QPSK modulation.
Logic ICs like the 74LS32 Quad OR gate, 74LS04 Hex inverter, and others are redefined to support the logical operations and signal processing required for QPSK.

Theory
Modulation Hypothesis with QPSK: Leveraging the historical use of QPSK by the NABU Network Adapter, known for its efficient data rate and noise resilience, this project's strategy is to re-implement these features and affirm the adapter's operational capabilities within today's technological landscape.

QPSK is a form of phase modulation technique where the carrier phase changes are used to represent digital information. It employs two signals—In-phase (I) and Quadrature (Q)—each of which can be modulated to carry a bit stream. The phase of the combined signal (I+Q) can take on one of four values: 0°, 90°, 180°, and 270°. Each phase shift represents a two-bit binary code, making QPSK capable of transmitting two bits of digital information per change in phase.

The Python code provided visualizes how the phase of a signal can be manipulated by changing the amplitudes of the I and Q components, a fundamental concept in QPSK modulation. It generates images that illustrate the phasor diagram and the corresponding waveform for various phases, demonstrating how the I and Q components' combination results in a phase-shifted output signal. This visualization helps in understanding how QPSK modulates a carrier signal to encode data by altering its phase according to the I and Q input signals, thereby achieving efficient data transmission in communication systems.

Diagram - Attached
Source: https://en.m.wikipedia.org/wiki/File:Ph ... ulator.gif

1980s Context vs. Modern Integration:
Recreating the adapter's high-speed data transmission ability creates a fascinating fusion of analog and digital technology. Modern integration will likely involve crafting custom hardware interfaces or software modifications to ensure compatibility, utilizing the following identified ICs in the NABU NA for logical processing, control signal generation, and data flow management:

- 74LS245: A bus transceiver fundamental for bidirectional data communication.
- 74LS138: A decoder/demultiplexer instrumental in generating necessary control signals.
- 74LS32: A Quad OR gate integral in logic circuits for operational decision-making.
- 74LS04: A Hex inverter crucial for signal polarity inversion.
- 74LS74: A Flip-flop used for managing sequential logic circuits.
- MC1403P: A Voltage reference IC for precision voltage regulation.
- 74LS08: A Quad AND gate employed for basic digital logic operations.
- 74LS00: A Quad NAND gate applied in a variety of logic functions.
- 74LS20: A Dual 4-input NAND gate designed for complex logic operations.

Integrating the operational principles of the specified digital logic components within a NABU Network Adapter infrastructure to facilitate high-speed data communication at 6 Mbps via QPSK modulation necessitates a understanding of advanced digital signal processing and RF modulation techniques. The execution of such a system involves a sequential operation of these components, each fulfilling a critical role in ensuring the integrity, timing, and modulation of the digital data stream.

Preliminary Data Processing
Serial Communication Establishment: Initially, the 74LS245 bus transceiver is paramount for establishing bidirectional data flow, interfacing the digital processing domain with the modulation circuitry. This transceiver's pivotal role ensures the seamless transfer of digital baseband signals, mitigating potential bottlenecks and facilitating robust interfacing between computational and RF domains.

Address Decoding and Signal Routing: Concurrently, the 74LS138 decoder/demultiplexer undertakes the critical task of signal addressing and routing, selecting specific pathways for the digital signals to navigate through the modulation circuit. This component is instrumental in delineating control signals for the modulation process, optimizing the circuit's operational efficiency and data throughput.

Signal Processing and Modulation Preparation
Logical Operations and Signal Manipulation: The incorporation of logic gates, including the 74LS32 Quad OR gate, the 74LS04 Hex inverter, and the 74LS08 Quad AND gate, performs essential logical operations. These operations facilitate decision-making processes, signal inversion for phase state generation, and synchronization of encoding procedures. The Hex inverter, in particular, is crucial for generating the requisite phase inversions, enabling the accurate representation of the QPSK modulation's four distinct phase states.

Data Timing and Synchronization: The 74LS74 flip-flop is utilized for data storage and synchronization, ensuring the serialized data bits are temporally aligned for modulation. This component's ability to maintain bit state integrity is vital for the precise timing and sequencing of the modulation process.

Analog-to-Digital Conversion and Voltage Stabilization
Reference Voltage Provisioning: The MC1403P voltage reference IC provides a stable reference voltage, an indispensable element for the analog-to-digital and subsequent digital-to-analog conversion processes. This stabilization is critical for preserving signal fidelity and integrity, particularly in the conversion stages where digital signals are prepared for RF modulation.

QPSK Modulation and RF Transmission
Modulation and Phase Shift Keying: The core of the QPSK modulation process is facilitated by a composite operation of the digital logic components. The 74LS138 decoder, in conjunction with the array of logic gates, orchestrates the modulation process by generating precise timing and control signals. These signals are then employed to modulate a carrier wave, utilizing the I/Q components derived from the original data stream, and creating the requisite phase shifts that encode the digital information onto the RF carrier.

High-Speed Data Communication Realization: Through the application of these components, the NABU Network Adapter is capable of modulating and transmitting data at speeds up to 6 Mbps. The QPSK scheme, characterized by its efficient bandwidth utilization and noise resilience, enables the transmission of two bits per symbol, effectively doubling the data capacity over simpler modulation schemes without necessitating additional bandwidth.

In the realm of QPSK data transmission, the components of the NABU Network Adapter are poised to collaborate effectively to achieve the target data rate of 6 Mbps. QPSK, or Quadrature Phase-Shift Keying, is a phase modulation technique where each phase shift represents two bits, offering four distinct states per symbol period by altering the carrier signal's phase. This method is exceptionally suited for high data rates and efficient bandwidth utilization.

The function of the ICs in QPSK modulation includes various roles:
- 74LS Series Logic Gates (74LS00, 74LS04, 74LS08, 74LS20, etc.): These gates perform logical operations essential for digital signal processing. In QPSK, they generate the required I (In-phase) and Q (Quadrature-phase) signals by manipulating the input data stream prior to modulation. This logical encoding is compatible with the QPSK scheme.
- 74LS74 (Flip-flop): This component stores and synchronizes data. For QPSK modulation, flip-flops maintain the bit state, crucial for timing and sequencing the bits so they are modulated at the correct intervals.
- 74LS138 (Decoder/Demultiplexer): It controls different circuit parts by decoding address lines and generating chip select signals, routing data within the system or accessing specific memory parts, vital for data flow management during modulation.
- 74LS245 (Bus Transceiver): Facilitates bidirectional data communication. In a modem, it interfaces the digital processing section with other circuits, such as DACs, necessary for converting the digital QPSK signal into an analog form to be carried over an RF signal.
- MC1403P (Voltage Reference): Provides a stable reference voltage, important for maintaining consistent signal levels during analog-to-digital conversion and throughout the modulation process.

Achieving 6 Mbps:
The combined operation of high-speed logic gates and flip-flops allows the modulation circuit to handle the digital signals rapidly enough to support a data rate of 6 Mbps. The speed of these components directly influences the potential data rate.

Efficient Encoding and Symbol Rate:
QPSK's efficiency comes from transmitting two bits per symbol. To reach 6 Mbps, the symbol rate must be at least 3 Msymbols/s, not accounting for overhead from error correction or other signaling. The actual symbol rate may be higher to accommodate these additional bits.

Bandwidth and Carrier Frequency:
The necessary bandwidth and carrier frequency are also pivotal. The PCB and its components must support operation at frequencies that allow the required bandwidth to transmit at 6 Mbps, meaning RF components (not shown in the images) must handle these frequencies with adequate power and minimal noise.

Integration for Data Transmission:
In a complete QPSK system, these ICs would be part of a larger assembly that includes:

- A Digital Signal Processor (DSP) or microcontroller: Programmed to handle QPSK encoding and decoding.
- Digital-to-Analog Converter (DAC): Converts digital signals into analog for modulation onto an RF carrier.
- RF modulator: Superimposes the baseband QPSK signal onto an RF carrier for transmission.
- Analog-to-Digital Converter (ADC) and demodulator: Converts received RF signals back into digital format.

The collaborative functioning of these ICs, along with other components and under the direction of a DSP or similar processing unit, would enable the system to modulate digital data onto an RF carrier using QPSK and achieve data rates as high as 6 Mbps, provided the system is designed appropriately and the RF conditions are favorable.


Project Aim
Our primary goal is to validate the integration of the NABU Network Adapter with current telecommunications infrastructure, combining historical data transmission techniques with today's networking standards.

COTS Component Overview
1. HF2211A DTU Serial Server RS232/RS485/RS422 Serial Port to WiFi Ethernet Modbus:
- Converts RS422 serial data to Ethernet.
- Supports RS232, RS485, RS422; WiFi and Ethernet connectivity; Modbus protocol.
- Configuration:
- Set RS422 communication parameters: baud rate, parity, data bits, stop bits.
- Network configuration: Assign IP addresses, subnet masks, gateways for network integration.
https://www.micros.com.pl/mediaserver/i ... hf2211.pdf

2. Teleview TVB599/LAN Network Modulator:
- Converts Ethernet to an F-type RG-6 RF signal compatible with NABU Network Adapter frequencies.
- Frequency Compatibility: Integrated VHF/UHF/L-BAND RF output up-converter.
- Supports transport stream from RTP/UDP over Ethernet.
- Offers various modulation options for flexibility.
https://www.teleview.com/modulators/tvb599lan

3. NABU Network Adapter:
- Converts RF signal back to RS422.
- High-speed (6 Mbps), addressable communications device.
- Ensure compatibility with RF output format of Teleview TVB599/LAN. Crux.

Interconnect Block Flow:
From a [PC USB Serial Emulator] via RS422 to [HF2211A DTU Serial Server], then through Ethernet to [Teleview TVB599/LAN Network Modulator], then via RG6 Coaxial Cable to [NABU Network Adapter], and finally connecting through RS422 to [NABU Computer].

Detailed Configuration and Setup
Step 1: Configuring the HF2211A DTU Serial Server
The HF2211A DTU Serial Server bridges RS422 serial communication to Ethernet, allowing the serial data to be transmitted over a network.
Connection to Computer: Use an Ethernet cable to connect the HF2211A to r computer. Alternatively, connect both devices to the same Wi-Fi network.
Web Interface Access: Find the HF2211A’s IP address (consult the manual for default settings and how to find this on r network).
Enter the IP address into a web browser to access the configuration interface.
Serial Configuration: Navigate to the serial port configuration section.
Set the serial parameters to match the NABU Network Adapter: Baud rate (check documentation for the specific rate, often 9600 or 19200 bps), Parity (None, Even, or Odd, typically None), Data bits (usually 8), and Stop bits (1 or 2, typically 1).
Network Configuration: Assign a static IP address or configure DHCP, depending on r network setup.
Ensure the subnet mask and gateway settings match r network’s configuration to facilitate communication with the Teleview TVB599/LAN.

Step 2: Setting Up the Teleview TVB599/LAN Network Modulator
The Teleview TVB599/LAN converts Ethernet data into an RF signal compatible with the NABU Network Adapter.
Network Connection: Connect the modulator to r network using an Ethernet cable.
Accessing the Configuration Interface: Utilize the manual to find how to access the device’s settings, likely through a web interface or a proprietary software tool.
Modulation Configuration: Select QPSK as the modulation scheme.
Configure the RF output settings to align with the NABU Network Adapter’s frequency requirements. This will involve setting the correct VHF/UHF frequency band and ensuring the signal strength (power level) is within the adapter's acceptable range.
Transport Stream Settings: Configure the input settings to accept the transport stream from RTP/UDP over Ethernet. Ensure the packet sizes and stream rates are optimized for r specific data requirements.

Step 3: System Interconnections
Connecting HF2211A to Teleview TVB599/LAN:
This connection is over the network, so ensure both devices are on the same subnet or are otherwise routable to each other.
RF Signal Transmission:
Connect the RF output from the Teleview TVB599/LAN to the NABU Network Adapter using an RG6 coaxial cable. Ensure the connection is tight and secure to prevent signal loss.

Step 4: System Testing and Calibration
Basic Connectivity Test: Verify that each component powers on and that can access their respective configuration interfaces.
Signal Quality Testing: Use an RF signal meter to test the output from the Teleview TVB599/LAN. Adjust the modulator’s power output to match the input requirements of the NABU Network Adapter.
Data Transmission Testing: Send a test data packet from r PC through the HF2211A and Teleview TVB599/LAN to the NABU Adapter. Monitor the transmission using network analysis tools to ensure the data is correctly modulated and received.

Step 5: Performance Optimization
Error Rate Measurement: Measure the Bit Error Rate (BER) to evaluate the quality of the transmission. High BER may indicate issues with signal strength, interference, or incorrect modulation settings.
Adjustments: Based on BER and other performance metrics, adjust the system settings. This may involve fine-tuning the RF output levels, changing the modulation parameters, or optimizing the network configuration for better throughput.
Repeat Testing: Continue testing and adjusting until achieve the desired performance metrics, ensuring the system operates reliably at 6 Mbps using QPSK modulation. Low Data Rates or High Error Rates: Review and optimize the modulation settings, check for network congestion or bottlenecks, and ensure the HF2211A’s serial-to-Ethernet conversion settings are correctly configured. By following these detailed steps and employing thorough testing and optimization, one may have a starting point in which to start testing various configurations.

Tools and equipment

• Hardware Components: NABU Network Adapter: The vintage device 're integrating.
  Teleview TVB599/LAN Network Modulator: For converting Ethernet data into an RF signal.
  HF2211A DTU Serial Server: Converts RS422 serial data to Ethernet.
  PC with USB Serial Emulator: For generating and sending data.
  RS422 Cables: For connections between devices that use RS422 interfaces.
  Ethernet Cables: To connect the HF2211A and the TVB599/LAN to r network.
  RG6 Coaxial Cable: For RF connection between the TVB599/LAN and the NABU Adapter.
  Power Supplies: For each device, according to its power requirements.

Tools for Configuration and Testing

• Computer with Network Access: For configuring devices and monitoring the network.
  Web Browser: For accessing the web interfaces of the HF2211A and the TVB599/LAN.
  Terminal Emulator Software: Such as PuTTY, for configuring the HF2211A via serial connection if necessary.
  Network Analyzer/Protocol Analyzer: For monitoring and analyzing Ethernet traffic.
  RF Signal Meter: To measure the strength and quality of the RF signal output from the TVB599/LAN.
  Oscilloscope: For detailed analysis of electrical signals, especially useful if troubleshooting signal integrity issues.
  Multimeter: For basic electrical tests, including voltage checks and continuity tests.

Miscellaneous Supplies

• Static Wrist Strap: To prevent electrostatic discharge (ESD) damage to sensitive electronics.
  Screwdrivers: For opening any device cases or securing connections.
  Wire Strippers: If any cable customization is necessary.
  Crimp Tools: For attaching connectors to cables, if need to customize cable lengths.
  Label Maker: For marking cables and equipment, aiding in organization.
  Notepad and Pen: For recording configurations, observations, and any changes made during setup.

Software for Configuration and Simulation

• Device Configuration Software: Specific software provided by the manufacturers for setting up and configuring the HF2211A and the TVB599/LAN.
  Network Configuration Software: To assign and manage IP addresses within r network, though much of this can be done through the operating system’s network settings.
  Simulation Software: Such as MATLAB or GNU Radio, if plan to simulate or further analyze QPSK modulation schemes and signal processing.
  Having all these tools and equipment at r disposal will prepare for a smooth setup process and enable to troubleshoot effectively. It’s also a good idea to consult the user manuals for each device for any specific tool recommendations or requirements.

Testing and Challenges
1. Compatibility Assessment
Objective: Determine the compatibility between the NABU Network Adapter, Teleview TVB599/LAN Network Modulator, and other components in terms of both hardware interfaces and communication protocols.
Method:
Research and Documentation Review: Collect detailed documentation for each component, focusing on interface specifications, supported protocols, and modulation capabilities. This includes datasheets, technical manuals, and any available whitepapers.
Expert Consultation: Engage with telecommunications and networking experts familiar with vintage and modern technologies to identify potential pitfalls in integrating components from different eras.
Potential Solution:
If compatibility issues are identified, consider developing custom interface adapters or firmware that can translate between the protocols and signal formats used by the NABU Network Adapter and modern networking equipment.

2. Schematic Development and Simulation
Objective: Develop detailed schematics showing the interconnection of ICs and components for QPSK modulation, and simulate the system to predict its behavior and identify potential issues.
Method:
Circuit Design Software: Utilize electronic design automation (EDA) tools to create schematics and lat diagrams that detail how the ICs and components are interconnected.
System Simulation: Run simulations using the schematics to model the system's performance, focusing on signal integrity, timing synchronization, and error rates.
Potential Solution:
Should the simulation reveal inefficiencies or errors, adjustments to the circuit design may be necessary. This might involve changing component configurations, adding signal conditioning elements, or modifying the logic used for modulation and demodulation.

3. Configuration and Calibration
Objective: Ensure the Teleview TVB599/LAN Network Modulator's output is precisely matched with the NABU Network Adapter's input requirements in terms of frequency, signal strength, and modulation characteristics.
Method:
Technical Specification Review: Compare the output capabilities of the Teleview TVB599/LAN with the input specifications of the NABU Network Adapter, focusing on RF frequency ranges, modulation parameters, and signal levels.
Modulator Configuration: Adjust the settings on the Teleview TVB599/LAN to align with the NABU Adapter's requirements, which may involve customizing the modulation options and RF output levels.
Potential Solution:
If exact matching proves challenging, it may be necessary to use RF signal processing equipment, such as attenuators or amplifiers, to fine-tune the signal strength, or filters to adjust the frequency response.

4. Performance Benchmarking
Objective: Evaluate the revived system's performance against expected data rates and error thresholds to ensure it operates within acceptable parameters.
Method:
Prototype Testing: Build a prototype based on the developed schematics and configured components. Test the prototype in a controlled environment to measure data transmission rates, error rates, and signal integrity.
Benchmark Analysis: Compare the observed performance metrics against the theoretical capabilities of the NABU Network Adapter and industry standards for QPSK modulation.
Potential Solution:
Should performance fall below expected levels, investigate the root causes—be it signal degradation, synchronization issues, or hardware limitations. Solutions might include further hardware tuning, software adjustments, or the introduction of error correction algorithms.

Considerations
To fully validate the hypothesis and refine the project approach, additional information might be necessary, such as:

Historical Technical Documentation: More detailed information on the original NABU Network's architecture and operation could uncover specific requirements or limitations. Environmental Factors: Consider how external factors, such as RF interference in the modern environment, might impact the system's performance. By systematically addressing these aspects and incorporating potential solutions, the project can move forward with a solid foundation for resurrecting the NABU Network Adapter and exploring its practical applications in today's technological landscape.

Step 1: Visual Inspection
Component Identification: We'll start by identifying all visible components, such as ICs, resistors, capacitors, diodes, and connectors. Knowing what components are present can give us clues about the circuit's function. For example, certain ICs are known for specific roles, like amplification, logic operations, or signal processing. Trace Following: To the extent possible, we'll follow the traces between components. This can help identify how components are interconnected, suggesting the flow of signals through the circuit. More high resolution study is needed on internal circuitry

Step 2: Functional Grouping
Circuit Blocks: Based on the identified components and their interconnections, we can group parts of the circuit into functional blocks, such as power supply, signal processing, data conversion, etc. This helps break down the circuit into more manageable sections for analysis.
Signal Path Hypothesis: With functional blocks identified, we can hypothesize the signal paths through the circuit. For instance, where the signal enters, how it's processed, and where it exits or connects to other blocks.

Step 3: Comparative Analysis
Reference Comparisons: Comparing the circuit components and last known reference designs or similar technology from the era can provide additional insights. Sometimes, circuits follow common design patterns that can be recognized.
Historical Research: Looking into patents, technical documents, or forums for discussions about similar technology might reveal additional details or schematics that align with what's visible in the photos.

Step 4: Theoretical Functionality
Educated Guesses on Operation: Based on the above steps, we can make more educated guesses about how the circuit operates. While not definitive, this can offer a theoretical understanding of the technology.
Identification of Key Components for Testing: Identifying which components would be critical to test (e.g., for their output signals or functionality under power) can set the stage for practical experimentation.

Practical Application and Experimentation
Bench Testing: If have the means to safely power up the circuit and measure signals, focusing on key components and paths identified through the visual inspection can validate some of the hypotheses about the circuit's functionality.
Prototyping and Simulation: Where possible, recreating portions of the circuit using breadboards or simulation software could further test the understood signal flows and functionalities.

Documentation and Community Engagement
Sharing Findings: Documenting and sharing r findings, hypotheses, and test results with online communities or experts in the field can invite feedback, corrections, and insights might not have considered.

While this approach one cannot guarantee a complete and accurate reconstruction of the schematic or functionality, it's a constructive path toward understanding and possibly reviving technology for which documentation is scarce or non-existent. More to follow. With the help of GPT4.

[AGMS]

What, no mention of the SC87253P microcontroller? And a lot of AI generated details about generic TTL logic chips and generic task steps? Surely figuring out the firmware that runs the microcontroller would be an important step!

[AGMS]

By the way, in the photos I see a N8X60N large chip (https://www.datasheets.com/part-details ... #datasheet) which is a FIFO address generator (a counter for read address, a counter for write address, a counter for size used) and two 2114 RAM chips (4 bits of data with a 10 bit address https://hardware.speccy.org/datasheet/2114.pdf) located near by. Which suggests a FIFO buffer of 1024 bytes, capable of running at high speed (faster than a software based one) to receive data from the cable TV decoded signal.

So, the largest data packet in the NABU network protocol would be 1024 bytes, including headers.

[Super_Derek]

Yes indeed, though it's more coherenent than that. I'm trying to create a foundation on which to consolidate information and collaborate as no one has much detail or a vision of using the NA until I forced a few hands. My next phase was to work with AI further, unless I had a team of people to help analyze everything. Surely you wouldn't think myself or anyone would try and reverse engineer this on their own lol. Thanks for the input though! Unfortunately, I'm not a strong software guy so there is a lot of room on this mission for others. My background is in electronics, RF, and IT. I did take assembly and C++ many moons ago. I'm open to further input, it would be amazing to be able to get the NA to work in some capcity.

I'm eyeballing this:
http://www.advin.com/eprom-programmer.htm

[AGMS]

One of the pricier programmers. Just need one which can do the NABU EPROM chips. Good discussion about programmers for vintage chips at https://forum.vcfed.org/index.php?threa ... s.1238152/

[AGMS]

Actually, even cheaper, just ask around and see if anyone has already dumped that EPROM chip. It has a NABU part number too, which would be worthwhile searching for.

Then you can find out the details about the microcontroller chip, a Motorola SC87253P, which I assume gets its instructions from that EPROM on the adapter circuit board. Might have to locate a Motorola chips catalog from 1984 to find out the CPU information, since it’s not mentioned online anywhere. Then reverse engineer the code to find out the protocol it used (though that may be documented somewhere). Also need to figure out the hardware connected to it. Quite an undertaking!

[Super_Derek]

@AGMS good catches. I’ve folded both into Rev 1.7 (proposal) and the bench plan (proposal).
SC87253P (proposal): explicitly called out as the demod/framing/FEC/CRC controller. Planned next step is a U5 (800012260) ROM dump to extract scrambler poly, CRC, interleave, and HCCA command IDs, then planned correlation with an RS-422 capture during CP/M2.2 Boot ROM → HCCA handshake → NABU Main Menu. If you or anyone already has a dump, I’ll validate hashes and publish tables (planned).
FIFO (proposal): the N8X60N + 2×2114 adjacent to the MCU are hypothesized to form an 8-bit × 1024 FIFO. Hypothesis: on-adapter transfers are ≤1024 B including header/CRC; larger assets are segmented by the carousel. Planned verification: histogram RS-422 burst sizes and probe N8X60N pointer/2114 CS lines for mod-1024 wrap under sustained transfer.
RF profile (bench-isolated, proposal): QPSK @ 3.200 Msym/s, RRC α=0.25, FEC 3/4 (fallback 2/3→1/2), ~+4 dBmV, MER ≥28 dB, EVM ≤4%. Target (unverified): adapter locks, CP/M2.2, Menu <10 s.
Artifacts I plan to publish (proposal): power-on→title video with timestamps, Teleview config + MER/EVM screenshot, short HCCA trace (~111 kb/s, 8-N-1) showing request/ack bursts, and board photos (SC87253P/TR1863/N8X60N+2114) plus ROM hash and strap map.
If you can point me to a Motorola catalog entry for SC87253P or prior U5 dumps, I’ll align the spec and credit sources. Happy to compare traces if you have captures (all pending execution).

Proposal for RS-422 to RF Transmission Using NABU Network Adapter and Teleview TVB599/LAN Network Modulator

Revision Number: 1.7

I acquired a NABU Network Adapter (NA-2) to recreate a small-scale NABU headend. In the 1980s, delivering ~6.3–6.5 Mb/s to a living-room computer was atypical; NABU achieved it by dedicating a single 6-MHz CATV channel to a continuous digital broadcast decoded in the adaptor and delivered to the PC over RS-422. Bench-only, isolated coax. -Do not inject into a live CATV plant. I’m proposing to rebuild a tiny, safe, bench-top copy of the 1983 NABU cable “headend” so a NABU computer can load CP/M2.2 Boot ROM → HCCA handshake → NABU Main Menu and games straight from a single TV channel, no disks, no tapes. A modern RF box (Teleview TVB599/LAN) would fake that one TV channel, continuously broadcasting the right bits. The gray NABU adapter would be the translator: it would tune the TV channel, turn the radio-style signal into clean bytes, fix errors, and then feed those bytes to the computer over RS-422 (about 111 kb/s). Think “early Netflix over one TV channel, looping programs until the computer grabs what it needs.”

Inside the adapter, a Motorola control chip (SC87253P) is the traffic cop for demodulation, descrambling, error correction, and data integrity checks. A small ROM (U5) holds the exact rules for that process, the secret handshake. I haven’t dumped that ROM yet; the plan is to read it so I know the real scrambler recipe, error-correction details, CRC type, and the serial commands the computer uses. I’ll validate by capturing a short RS-422 session during a cable boot (CP/M2.2 → Main Menu) and matching what I see on the wire to what the ROM says.
There’s also a small buffer made from one N8X60N and two 2114 memory chips, basically a one-kilobyte “bucket.” That strongly suggests the adapter sends data to the computer in ~1 KB chunks; bigger items are split by the always-looping broadcast (“carousel”). I haven’t confirmed that yet; I plan to measure serial burst sizes and watch the buffer lines wrap every ~1024 bytes.

For the fake TV channel, the working recipe is QPSK at roughly 3.2 million symbols per second with standard shaping and forward-error-correction (start 3/4, fall back 2/3 or 1/2 if needed), at modest signal power on a short, isolated coax jumper, never on live cable plant. I’ll judge signal health with MER/EVM and aim for a clean constellation (≈≥28 dB MER, low single-digit EVM). If that profile locks, the adapter should acquire the channel, the PC should load CP/M2.2, the menu should show within a few seconds, and a title should launch, all from the looped broadcast.
When it works, I’ll publish proof, not claims: a power-on-to-title video with timestamps, screenshots of modulator settings and quality readouts, a short RS-422 capture showing request/ack bursts, and sharp board photos with part labels, plus a ROM image hash and a jumper/strap map, so others can reproduce it.

What remains is to nail down the on-air coding details (real scrambler polynomial, interleave depth, CRC flavor) and confirm the modulator truly does the needed QPSK/OQPSK shape in a VHF/UHF-sized channel. The to-do list is straightforward: dump the ROM and publish the tables, capture and histogram the serial bursts to prove the ~1 KB chunk size, sweep signal quality vs. error rate with attenuators, and release a small toolchain (carousel builder, parser, CRC/descrambler library, RS-422 sniffer). Once that’s done, this becomes a repeatable “NABU over one TV channel” demo for labs and museums, plus a clean spec others can build against, or even design a modern drop-in adapter that speaks the same on-air language.


Introduction
Integrate the adaptor with modern COTS RF so CP/M2.2 → Main Menu and titles load exactly as intended. Use a Teleview TVB599/LAN as the RF source and a content server that emits properly framed NABU carousel data. No upstream.

Here’s the scene: a gray box on a bench, one coax jumper, a click, and a 1983 machine boots CP/M2.2 straight off cable. No disks. No tapes. NABU carved a single 6-MHz CATV slot into a continuous digital downlink, QPSK at ~3.200 Msym/s for ~6.3–6.5 Mb/s raw—and treated the home computer as a thin client. The adaptor locks, corrects, frames, and hands bytes over RS-422 HCCA (~111 kb/s, 8-N-1) while a carousel loops software until you request it again.

Open the adaptor and the claim hardens. Two 3.579545 MHz crystals feed HCU04 inverters for timing; LM339s slice symbols; a Motorola SC87253P handles de-scramble, FEC/de-interleave, and CRC; a TR1863 converts dibits to bytes and runs the host link; U5 ROM 800012260 holds framing tables and diagnostics. An N8X60N with two 2114 SRAMs forms an 8-bit×1024 FIFO, a clean hint that on-adapter transfers cap near 1 KB per block with larger assets segmented by the carousel.

Now it’s reproducible. A Teleview TVB599/LAN can synthesize the historical carrier with a profile you can memorize: NABU-QPSK-3.2M, symbol rate 3.200 Msym/s, RRC α=0.25, start near +4 dBmV, FEC 3/4 (fallback 2/3 → 1/2), bench-isolated. Aim for MER ≥ 28 dB and EVM ≤ 4%. Expect lock, CP/M2.2, Main Menu in <10 s, and a title launch with no media. Publish proof, not prose: a power-on-to-title video with timestamps, the Teleview config and MER/EVM screenshot, a short HCCA trace showing request/ack bursts, and sharp board photos of SC87253P / TR1863 / N8X60N+2114, plus ROM hash and strap map. This is the cloud before “cloud,” rendered in a TV channel you can measure, repeat, and show.

Theory
Operate in VHF/UHF using one 6-MHz CATV slot. The downlink uses QPSK at ~3.200 Msym/s (~6.4 Mb/s raw) with FEC and interleave. Content is a continuous carousel so late joiners complete. The plant is downlink-only; the adaptor outputs RS-422 to the PC via the HCCA link (~111 kb/s, 8-N-1, full-duplex). Hardware baseline (this NA-2): logic board 900228801 Rev D, ROM 800012260, 3.579545 MHz reference cans, LM339 comparators, HCU04 unbuffered inverters, TR1863-class serializer/host interface, RS-422 line drivers, linear +5 V/+12 V rails.

COTS Component Overview
HF2211A DTU Serial Server RS232/RS485/RS-422 ↔ Wi-Fi/Ethernet (Optional). Converts RS-422 to IP for captures or future return-path experiments. Configure baud, parity, data bits, stop bits if used; assign IP, subnet, and gateway for network integration. Not required for the one-way demo.
HF2211A datasheet: https://www.micros.com.pl/mediaserver/i ... hf2211.pdf

Teleview TVB599/LAN Network Modulator. Converts RTP/UDP over Ethernet to RF on an F-type RG-6 output with integrated VHF/UHF/L-band up-conversion. Configure QPSK, symbol rate, roll-off, FEC, center frequency, and RF level. Accepts constant-bit-rate transport stream or compatible framed input.
https://www.teleview.com/modulators/tvb599lan

NABU Network Adapter (NNA). Takes the dedicated CATV channel in, demodulates and error-corrects the digital stream, frames NABU blocks, and outputs RS-422 to the NABU Computer. Use carrier/data indicators if present to confirm lock and traffic.

Adapter architecture (from teardown and manuals)
Physical and power. CABLE IN/OUT F-ports; downstream tap with pass-through. Two TO-3 linear pass devices on the rear heatsink provide +5 V (logic) and +12 V (RF/line drivers); a small negative/analog bias rail may exist locally. Target ripple on +5 V < 50 mVpp.

High-speed FIFO buffering. Adjacent to the SC87253P are an N8X60N FIFO address generator and two 2114 SRAMs (4-bit × 1024 each). Paired 2114s yield an 8-bit × 1024 (~1 KB) FIFO while the N8X60N supplies read/write address and fill-level counters. This enables continuous dibit→byte capture at symbol clock without MCU stalls and likely bounds single on-adapter block transfers to ≤ 1024 bytes (incl. header/CRC).

Working hypothesis: the N8X60N + 2×2114 FIFO bounds single on-adapter block size to ≤1024 bytes (incl. header/CRC); confirm via RS-422 burst histogram and N8X60N/2114 pointer wrap under sustained transfer.

RF → baseband front end. Headend injects a single 6-MHz channel carrying a continuous digital stream (QPSK, ~3.2 Msym/s). Inside the adaptor a shielded tuner/IF strip down-converts and AGC-stabilizes the channel to baseband. Two 3.579545 MHz crystals feed HCU04 unbuffered inverters to create low-jitter timing and active filters for symbol/bit-timing loops. LM339 quad comparators slice I/Q (or summed) waveforms into logic-level dibits and provide early/late detector signals for timing control.

Clock and symbol recovery. The timing loop uses the crystal references and LM339 early/late outputs to discipline a ~3.2 MHz symbol clock; HCU04 sections act as narrow BPF/phase-shift elements to reduce jitter before digital decoding.

Digital demod, framing, and FEC. A Motorola-marked SC87253P (mask MCU/ASIC) orchestrates demod state, de-scramble/de-whiten, FEC/de-interleave, and CRC; a Western-Digital-marked TR1863PL-02 handles dibit→byte conversion with clock/framing and services the host RS-422 port (HCCA). 74LS-series glue (’00/’02/’04/’74/’164/’330/’373/’374) provides shift/latch stages, byte assembly, and small FIFOs. ROM U5 (label 800012260) contains framing tables, polynomials, command set, and diagnostics. Output is a byte stream of NABU carousel blocks with valid CRCs for the host-link engine.

Host link (HCCA) over RS-422. RS-422 transceivers (DS9638/9639/AM26LS31/32-class) drive the COMPUTER port. Link is full-duplex ~111 kb/s, 8-N-1. The PC boots ROM, initializes HCCA, and requests blocks by ID; the adaptor asserts “data ready,” the PC reads a buffer, then the adaptor waits for the next carousel occurrence. No per-subscriber addressing on cable; all control is local over RS-422.

Boot and run sequence (on the wire)
1. Headend is carouseling CP/M2.2 → Main Menu → titles continuously.
2. Adaptor locks RF, recovers symbol clock, de-FECs, frames, and verifies CRC.
3. Over HCCA, the PC requests the bootstrap block; the adaptor transfers it across RS-422.
4. The PC executes CP/M2.2 from RAM, then requests the Main Menu and later the selected title images.
5. Because the network is a loop, late joins complete; the adaptor simply waits for the next appearance of the requested block group.

System Diagram
[Content Server (NABU carousel generator)] —Ethernet/RTP→ [Teleview TVB599/LAN: QPSK in 6-MHz CATV slot] —RG-6 (isolated bench)→ [NABU Network Adapter] —RS-422→ [NABU Computer]
(Optional capture path: NNA RS-422 tap → HF2211A → Ethernet → PC logic analyzer.)

Modulation profile
Use QPSK. Start at 3.200 Msym/s, RRC roll-off α=0.25, FEC 3/4, a clean bench channel, and ~+4 dBmV at the adaptor input. If no lock, sweep symbol rate ±10%, try roll-off 0.20–0.35, and step FEC 3/4 → 2/3 → 1/2. Target MER ≥ 28 dB and EVM ≤ 4%. Effective payload is below raw due to FEC/framing; carousel cadence sets perceived speed. Save a reproducible device profile as NABU-QPSK-3.2M.

Content server and carousel
Assemble CP/M2.2, Main Menu, and at least one title into a NABU-framed carousel preserving preambles, IDs, and CRC. Repeat menu blocks within ≤2–4 s and title blocks within ≤10–20 s. Output as a constant-bit-rate TS over RTP/UDP with stable PCR/PTS, or as raw framed bytes if the modulator supports it. Discipline clocks via NTP/PTP or a shared reference with the modulator.

Teleview configuration
Set input to RTP/UDP from the server; modulation QPSK; symbol rate 3.200 Msym/s; roll-off 0.25; FEC 3/4 (fallback 2/3, then 1/2); choose a quiet VHF/UHF slot; RF level +4 dBmV initial (sweep −10 to +12 dBmV if needed); match TS rate to post-FEC payload to avoid buffer under/over-runs.

Power-on and lock
Power the modulator and confirm TS lock, then power the NNA and PC. Watch adaptor indicators. Expect CP/M2.2 → Main Menu within about ten seconds after RF lock; the menu should present within ≤2 s after lock. Launch a title and measure wall-time against carousel period.

Verification and probing plan (non-destructive)
Rails: verify +5 V and +12 V; ripple on +5 V < 50 mVpp.
Clocks: on HCU04 nodes expect clean 3.579545 MHz references and a derived ~3.2 MHz symbol strobe.
Slicer: LM339 outputs square and symbol-correlated under RF.
Framing/FEC: on TR1863/ASIC, identify byte-clock, “byte ready,” and CRC-error pins (CRC-err should idle low during healthy lock).
RS-422: differential swing ±2–3 V at ~111 kb/s, 8-N-1; capture request/ack cycles followed by bulk data bursts.

ROM and protocol tasks
Dump U5 (800012260). Extract scrambler polynomial, CRC (likely CRC-16), and interleave depth. Identify HCCA command IDs (INIT, READ-BLOCK(ID), STATUS, RESET). Document block header format (sync, block-ID, length, CRC). Correlate ROM tables with RS-422 captures during a menu load to confirm carousel cadence and block mapping.

Verify block-size ceiling
Capture RS-422 bursts during CP/M2.2/Menu loads and histogram payload lengths; expect ≤ 1024 B per block incl. header/CRC if FIFO-bounded.
Probe the N8X60N read/write pointer and 2114 chip-selects under sustained transfer; confirm modulo-1024 wrap behavior.
If larger logical assets appear, document multi-block segmentation/reassembly rules in the framing spec.

Test pads and straps
Use TP1…TP8 to label rails, symbol clock, sliced data, byte-ready, CRC-err, and an RS-422 test point while under lock. Record S0A…S0E / P0A…P0E strap positions before any change; these likely encode region/channel plan or diagnostics.

Limitations and challenges
One-way only; no per-subscriber addressing on cable. Keep an isolated bench loop. Exact FEC/interleave/framing must be verified empirically or from ROM/protocol analysis. Maintain RF hygiene: proper terminations, pads, clean connectors, short runs.

Considerations
Validate lock stability and effective payload. Stage gain on RG-6 to avoid overdrive. The primary risk is protocol/framing compatibility between the carousel generator and modulator input. Document the adaptor (PCB photos, ROM labels, RS-422 pinout, straps). When feasible, corroborate with former NABU engineers/archivists.

Integration with existing firmware and software
The NABU PC expects network CP/M2.2/Main Menu; no extra drivers. The content server must emit correctly framed NABU blocks at fixed cadence (menu ≤2–4 s; titles ≤10–20 s). Feed the Teleview with CBR TS over RTP/UDP with stable PCR/PTS, or supported baseband framing at constant rate.

Acceptance table
Menu visible ≤ 2 s after lock; CP/M2.2 → Main Menu sequence ≤ 10 s after lock.
At least one title downloads and runs to completion.
MER ≥ 28 dB, EVM ≤ 4%.
30-minute continuous run with zero visible glitches.

Documentation to produce
Record the exact RF profile (symbol rate, roll-off, center frequency, FEC/interleave, RF level). Capture modulator configuration screens and spectrum/MER/EVM if available. Film power-on → lock → CP/M2.2 → Main Menu → title launch with timestamps. Publish the carousel specification (block order, cadence, CRC handling). Photograph the NNA PCB and ROM labels and publish hashes of ROM and content images.

Closing
This is a faithful, reproducible path to a one-way NABU broadcast using modern gear. The levers are QPSK in a clean 6-MHz channel, correct carousel framing and cadence, and disciplined RF practice. Upstream or return-path trials are separate work.

Use Case
Prove the system. Run the bench profile, capture RF/MER/EVM and RS-422 traces, publish a short validation report with exact params and timing.
Freeze the spec. Write a clean “NABU Link v1” framing/FEC/CRC/HCCA spec from your captures and ROM dump; add test vectors.
Release a toolchain. Carousel builder, block parser, CRC/scrambler libs, HCCA sniffer, ROM dumper, and a Dockerized headend image.
Design a modern adaptor. SDR/FPGA or single-ASIC demod → RS-422 drop-in for NA-2; expose a USB debug port; keep the same on-air profile.
Build a reference headend. Teleview profile + server container + acceptance script; one-button demo for museums and labs.
Do link-budget science. BER vs MER/EVM curves, FEC/interleave sweeps, symbol-rate/roll-off tolerance, level sensitivity, jitter tolerance.
Interoperate with software. Add a virtual HCCA device for emulators; enable “headend over IP” (multicast/RTP) feeding either RF or a soft client.
Preserve content. Ingest, hash, and catalog CP/M2.2/Menu/titles; map block IDs; publish a signed index and provenance notes.
Education/exhibits. Turn the setup into a 10-minute kiosk: spectrum view → lock → CP/M2.2 → Menu → game launch; include anatomy panel of the NA-2.
Monetize responsibly. Offer mini-headend kits, workshops, and on-site installs; include COA, profile file, and video proof.
Explore upstream (isolated). Prototype a return path on a second channel or out-of-band link to study two-way scheduling, then document results.
Standardize variants. Define DVB-C/ATSC-3/IP-multicast carry of NABU blocks while keeping the HCCA interface stable.
Document hardware. Full NA-2 schematic capture from board photos, strap matrix, TP map, PSU rails/ripple, and timing tree.
Publish. A concise whitepaper and repo tying the RF profile, captures, ROM analysis, and reproducible build to the historical record.

Change Log
Replaced all QAM speculation with QPSK at ~3.200 Msym/s ≈ 6.4 Mb/s in a 6-MHz CATV slot.
Added explicit downlink-only model; removed “addressable communications device” claim on cable.
Introduced continuous carousel with FEC/interleave and late-join behavior.
Added bench-only isolation warning; forbid injection into live CATV.
Specified RF profile: RRC α=0.25, start +4 dBmV, search ±10% SR, roll-off 0.20–0.35, FEC 3/4→2/3→1/2.
Added RF quality targets: MER ≥ 28 dB, EVM ≤ 4%.
Detailed adapter internals: TO-3 regulators (+5 V, +12 V, ripple <50 mVpp), shielded tuner/IF with AGC, 3.579545 MHz refs, HCU04 timing, LM339 slicers.
Documented digital core: SC87253P (de-scramble/FEC/CRC) + TR1863 (dibit→byte, HCCA), 74LS glue FIFOs/latches, ROM U5 800012260 roles.
Added host link (HCCA) specifics: RS-422 full-duplex ~111 kb/s, 8-N-1, request/ack and “data ready” flow.
Described boot/run sequence from carousel lock → CP/M2.2→ Main Menu → title load.
Added verification/probing plan: rails, symbol clock ~3.2 MHz, LM339 outputs, byte-ready/CRC-err pins, RS-422 levels ±2–3 V.
Added ROM/protocol tasks: dump U5, extract scrambler, CRC-16, interleave, HCCA command IDs, block header fields; correlate with RS-422 captures.
Listed test pads and straps (TP1…TP8, S0*/P0*) and documentation requirements.
Reworked system diagram to make HF2211A optional (capture/tooling only).
Added content-server requirements: preserve preamble/IDs/CRC; menu repeat ≤2–4 s; titles ≤10–20 s; CBR TS over RTP/UDP or raw framed bytes.
Added Teleview config checklist and saved profile name “NABU-QPSK-3.2M.”
Added power-on/lock procedure and timing expectations (menu visible ≤2 s; CP/M2.2→Menu ≤10 s after lock).
Introduced acceptance criteria and 30-minute stability run.
Normalized terminology/units: RS-422, Mb/s, corrected spelling, consistent TVB599/LAN.
Kept Teleview link; flagged full HF2211A PDF URL insertion (original was truncated).

To Do
Still “working theory”:
FEC specifics (rates/interleave) and scrambler/CRC are hypothesized until the U5 (800012260) ROM is dumped and correlated with captures.
TR1863 role and SC87253P responsibilities look right but need documentation or firmware evidence to lock down.
Modulator assumption. Ensure the Teleview box truly supports OQPSK/QPSK in a 6-MHz VHF/UHF slot with the filter/roll-off settings claimed; many cable modulators default to QAM families. If not, you’ll need a different RF chain or SDR.

Concrete upgrades:
Dump U5 and publish: image hash, scrambler poly, CRC (likely CRC-16), interleave depth, and HCCA command map with annotated disassembly.
Show wire truth: RS-422 logic traces for CP/M2.2→Menu→Title with timestamped burst histograms; confirm the ≤1024 B block ceiling.
Quant data: pre-FEC/post-FEC BER vs MER sweep using attenuators; include spectrum/MER/EVM screenshots at lock.
Photographic evidence: hi-res board photos with reference designators and a minimal schematic capture (PSU, IF, slicer, FIFO, host I/O).
Headend toolchain: release the carousel builder + parser and a Dockerized profile (“NABU-OQPSK-3.2M”) so others can replicate in one click.