Context

I am working on a Free Space Optical Communication (FSOC) project (sending data through lasers turning on/off through line of sight). Compute nodes will connect through ethernet to a media converter which will have a custom Small Form-factor Pluggable (SFP). This bidirectional SFP will send 1550nm wavelength data through free space to a receiving custom SFP. The receiving SFP will interface with a media converter that is connected by ethernet to another compute node. The compute nodes should be able to communicate as if they were connected by ethernet. End target is communication at 1km at 1gb/s with total cost of bidirectional communication node under $1000 and under 1 kg. Constraints may turn out to be impossible and need tuning. Goal is to put these on drones to make a mesh network.

Week 1 Goals

Getting up to speed with power electronics and understanding methodology for things like breakout boards, oscilloscopes, I2C comms, multimeters.

Will be using the SFP MSA to understand expected behavior and see if I can observe it using the SFP breakout board.

1. Ensure that the set up of compute node to media converter to SFP to fiber optic cable to SFP to media converter to compute node works as a sanity check. Ensure all the components are in working condition. Should behave as if the two compute nodes were connect by ethernet cable.
2. Want to be comfortable reading I2C signals through the Siglent Oscilloscope I2C reading capacity. Also want to be comfortable with measuring voltages through multimeter. Will need to eventually understand eye diagrams for signal transmissions. Goals are to observe expected activity defined in MSA when:
   • Powering SFP breakout board
   • Connecting SFP to SFP breakout board
   • Connecting fiber optic cable that is connected to compute node system to SFP breakout board with SFP plugged in

Materials

SFP breakout board v1 kit
SFP experimenter board v2 kit
Siglent Technologies SDS1104X-E 100Mhz Digital Oscilloscope 4 Channels Standard Decoder
SFP to RJ45 100Base-FX Single-Mode LC Module
Gigabit SFP to RJ45 Fiber Media Converter | Fiber to Ethernet Converter
LC to LC Fiber Patch Cable OM3 10M/33ft
Fluke 101 Digital Multimeter

Week 1 Results

When deciding on how to create a Free Space Optical Communication (FSOC) mesh network I initially thought of going with a custom protocol for taking compute node data and through some USB system serializing it for transmission across the FSOC communication system.

I thought I would need to:

1. Design some kind of application layer that lives on the compute nodes that can receive/transmit data (FSOC mesh app, put file here to send to a connected node).
2. Build some kind of USB interface/driver with the OS/application layer that ingests data/outputs data (app takes in-memory data reference and communicates with OS to send to USB in expected format).
3. Some kind of hardware that will take the data from the USB output and then prepare it for transmission or receives it as electric signal (hardware connected to usb converts data to transmittable format or electrical signals).
4. The FSOC system that takes the electric signal and actually do the communication (take electrical signals and turn on/off lasers).
5. Design some kind of a protocol for indicating connectivity, transmitting packets, error correction, etc (assume failures and need for error correcting code and health checks etc).

This would means there would be a large integration process for any platforms that would want to use this communication network. Also, the project becomes orders of magnitude more complex that it already is.

What currently allows for a Local Area Network to exist and has already handled serialization/packet routing/errors/negotiation? Ethernet connectivity.

Turns out that the internet runs on things called “Media Converters” and “Small Form-Factor Pluggables” that do exactly the process desired but are currently used for fiber optic cables.

Communication Education Simulator

To wrap my head around direct Ethernet communication and Ethernet communication through media converters/sfp/fiber works I created a lightweight educational tool to help me understand the different layers and communication. Repo here. Hit the “play” button to get an animation and log of what happens in different scenarios in the dropdown.

I got a good grip on the purpose of each layer and what drives communication. You can select 4 different scenarios to see the different type of communication expected when on Ethernet vs. fiber vs. breakout board.

Key insights is “what is in charge” for ending electrical signals when. NICs start negotiation first and only then signal an interrupt.

This exercise highlighted how much I get “out of the box” by moving forward with using custom SFPs with FSOC instead of having to make everything custom. By substituting FSOC for fiber optics, everything else will “just work” instead of needing rebuilding. Apps and OS will just treat this as a “socket” that can be communicated with the hardware layers taking care of the rest.

Key scenario for physical testing this week is the 4th scenario (“breakout”) that provides expected signals/I2C messaging when SFP breakout board is connected. Key insights is that SFP A will be sending optical signals even if there is not a connection to SFP B. This means when connected to SFP B (breakout) I should be able to see signals on the Rx pins.

I can use this tool as a blue print for examining the breakout communication. Will update if I need more clarification and assistance as I work through signal analysis. I believe in the future most education materials will come with these type of simple demos to show different states and coordination between different layers/interfaces. This type of information is not well presented in plain text and now with LLMs these type of tools are easy to make. This tool took a few hours of prompting and now I have an asset I can refer to when working through this project.

1. Initial Host <> Host Connection through Ethernet

Direct Ethernet With No Manual IP Assignment

My desktop and laptop were connected directly by an Ethernet cable. As described by the simulation tool above, without manual IP addresses these hosts have no way to communicate with each other.

From the tool’s log:

Let’s see if this is what happens.

1. Connected my laptop with Ethernet

2. Connect the other end to my dekstop

Expected Results – Negotiation between NICs on communication speed and then and attempts to retrieve response from DHCP server.

Actual Results –

As expected! The Linux desktop is constantly in “Connecting” but it has negotiated the proper rates.

Both the laptop and the desktop have 2500 mb/s abilities, which is what has been communicated.

So although the NIC’s negotiate how they will communicate once the Ethernet is plugged in, there is no idea of IP Addresses or MAC addresses yet.

The desktop is Linux and was set to Automatic and it kept staying in “Connecting” state as expected. This is the DHCP packet being sent for discovery. Host B PHY is not a DHCP server like a router is, so it times out and does not receive an expected reply.

Direct Ethernet With Manual IP Assignment

1. Once set to manual on desktop:

2. As well as the laptop:

From the simulation tool we know this is what we should expect.

Expected Results –

The IP assignment is not on the NIC level, but is actually on the OS Kernel level. This should cause the profile to be marked ‘active’.

Actual Results –

Success! The manager marks the profile “activated”: carrier is up (L1/L2) an address/subnet is present (L3), and required routes exist.

The Windows machine additionally needs to get a Firewall rule to allow ICMPv4 echos in. Prior to this command the ping from Linux would not receive a reply.

$> New-NetFirewallRule -DisplayName "Allow ICMPv4 Echo In" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow -Profile Any

Sending a ‘ping’ from Host A to host B or Host B to Host A works:

2. Host <> Host Connection through Media Converter/SFP/Fiber

Connected through Fiber Optics (1000BASE SFPs)

These are 1,000 mb/s media converters with 1 gb/s SFPs plugged in.

As expected from NIC negotiation from Host A and Host B and between the SFPs and the Media Converters, the communication speed has been changed to 1,000 mb/s.

Sending a ping from each machine works and we are able to transmit data.

When I swapped for 100BASE SFPs, the connectivity still read 1,000 mb/s. There must be some issue with negotiation.

3. Host A Connected to SFP Breakout Board

The other scenarios were sanity checks to make sure the hardware is able to communicate. This scenario is meant to educate me on how to use dev boards and equipment like I2C readers and multi meters.

The simulation tool be used as a guide for measurement and expected behavior:

Will be focusing on analyzing these scenarios:

1. SFP breakout being powered on.
2. SFP breakout having SFP plugged in.
3. SFP breakout with SFP plugged in having fiber optic connectivity.

SFP Breakout Being Powered On

Small Form-Factor pluggables have a MultiSource Agreement (MSA) that is used to define the interface. They are basically governed by the 20 pins and the physical/thermal constraints defined in the pdf. This is good news.

As long as you follow the MSA for your SFP (even if it is custom) it should ‘just work’ with any Media Converter. This means that our custom SFP we will design for this project, as long as it adheres to those 20 pin connectors, can be used for Free Space Optical Communication (FSOC).

We have the API spec needed for the interface to our service. This makes implementation more straight forward.

Based on the MSA we have expectations on how SFPs should behave and therefore can predict expected behavior of the SFP breakout board that we are testing. We used the breakout board schematics and the SFP MSA to power the content in our simulation tool. The tool will guide me in using the multimeter for voltages and the oscilloscopes I2C reading capability. The motivation to do this is to dip a toe in the power electronics pool. The project does not move forward due to this work.

The simulation tool in the breakout scenario directs me to confirm the following::

[4:11:16 PM] SFP Breakout Board Powered (B side).

• Power rails: Vcc (3.3V) stable; measure ~3.30V at VCC pins (per MSA).
  • Pins: VccR = pin 14, VccT = pin 15; grounds: VeeR/VeeT on pins 1,9,10,11,16,19,20.
  • Why 3.3V? SFP MSA specifies 3.3V rails for module logic and optics.
  • Ripple tolerance: Keep ripple small (≈ <50 mV p‑p). Excess ripple can either trip TX_FAULT or degrade RX sensitivity.
• Pull-ups: SDA/SCL have ~2.2–10k pull-ups to 3.3V on the breakout; expect ~3.3V idle on both lines.
  • Open‑drain bus: Devices only pull LOW; resistors pull HIGH. This allows multiple devices to share SDA/SCL.
  • Idle level: SDA=HIGH, SCL=HIGH at rest.
  • Probe note: Use high‑impedance LA probes; do not drive the lines.
• Status pins (no module yet):
  • MOD_DEF0 (6): HIGH (no ground) → indicates no module present.
  • TX_DISABLE (3): HIGH ≈ 3.3V (laser OFF by default).
  • TX_FAULT (2): HIGH via pull‑up (open‑drain) → idle/high when not faulting.
  • RX_LOS (8): HIGH (no light).
• LEDs (if provided): Power LED ON, TX/RX status LEDs off.
  • Power LED tracks the 3.3V rail; TX/RX LEDs are vendor‑specific and may mirror TX_ENABLE and RX_LOS.
• No host copper on B: There is no NIC B; this board exposes pins for measurement only.
  • Implication: You can observe optics/I2C but no Ethernet frames are decoded/forwarded.
  • Safety: Do not force TX on; follow laser safety.
• I2C primer (master/slave & transactions):
  • Master: Media converter/host generates SCL and START/STOP.
  • Slave: SFP module at 7‑bit addresses 0x50 (A0h) and 0x51 (A2h).
  • Start: SDA↓ while SCL HIGH; Stop: SDA↑ while SCL HIGH.
  • ACK/NACK: Receiver pulls SDA LOW on the 9th clock; master NACKs last byte of a read.
  • Clock stretching: Slave can hold SCL LOW to pause the master when needed.
• Where to probe (DMM/LA):
  • DMM ground: Any Vee pin (1,9,10,11,16,19,20).
  • Vcc: VccR (14)/VccT (15) ≈ 3.30V.
  • Logic idle: SDA (4) ≈ 3.3V, SCL (5) ≈ 3.3V.
  • Status idle: TX_DISABLE (3) ≈ 3.3V, TX_FAULT (2) ≈ 3.3V, RX_LOS (8) ≈ 3.3V.
  • LA hookup: SCL→5, SDA→4, GND→Vee; expect ~100 kHz, START/STOP semantics.

Results

Using my multimeter I put the black end on GND whole near DC input, and then the red pin on what I was testing.

Initial check on power in:

• Vin = ~5 which is what the DC power provides (good)
• 3V3 = 2.987 (seems close for a cheap DC power adapter)

• You can see the Tx_FAULT LED lit up and the LOS
  • Both were measured at ~2V
  • SFP’s RX_LOS pin (active high). HIGH = no sufficient optical power at the receiver; LOW = light present and above threshold. Makes sense, we don’t have any receiver connected
  • TX_FAULT (active high). HIGH = Protection/fault conditions: laser bias out of range, TX power out of range, over‑temperature, under/over‑voltage on TX rail, laser safety trip, internal TX driver fault. (not transmitting) LOW = Can transmit fine

The Tx_FAULT pin on “HIGH” (as expected with no chassis for transmission.

Then I wanted to do a small test so I put the multimeter pin to touch both the Tx_FAULT pin and GND (ground) pin at the same time.

This caused the Tx_FAULT pin to go to “LOW” which disabled the LED for Tx_FAULT (expected!). Then I connected the SFP plug into the breakout board.

SFP breakout having SFP plugged in

When plugging in the SFP chassis with the fiber optic plugged in the Tx_FAULT is powered low. It is interesting that the chassis was not enough, the actual fiber optic had to be plugged into the SFP. I then measured the Rx pin at the bottom of the board.

It read ~0V as expected.

SFP breakout with SFP plugged in having fiber optic connectivity

When plugging in the fiber optic cable to the plugged in SFP in the media converter the LOS finally goes to “LOW”.

It does not go to “LOW” state if the media converter is not powered on. That makes sense, from SFP MSA it requires light detection.

I then checked out the Rx line again and saw a reading of 1.542V which drifted up and down.

Wondering if that is because this reading is an average of values. Maybe there are on and off and so this is the average value of going from 0V to 3.3V. It being lower than 1.65V means it is more “OFF” than “ON”?

Then I measured the Tx pins.

It read 0.053V. Maybe it must send a certain amount of signal to allow the other to know it is connected. This may be the voltage that signals on but not sending data.

After doing some ChatGPT research learned about why the 3 pads are used. It is to help with high speed signaling. So if there is noise that affects the signal, it will affect both voltages equally. So the differential amplitude is still the same. ChatGPT

1. The easy way: one wire + ground

[ Transmitter ] ────── Signal ──────[ Receiver ]
                 |                     |
                GND                   GND

• We put 0 V = “0” and 5 V = “1” on the signal wire.
• The receiver measures the voltage difference between the signal and ground.

Why this is fragile at high speed

When you send slow signals (like flipping a light switch), nothing bad happens. But when you send fast edges (billions of flips per second), physics kicks in:

1. Electromagnetic radiation (antenna effect)
   • A long wire with rapidly changing current radiates radio waves (like an antenna).
   • That radiated energy is “lost” from your signal → receiver sees a distorted version.
2. Inductance & capacitance
   • A wire has inductance: rapid changes in current cause opposing voltages (L · di/dt).
   • A wire has capacitance to its surroundings: fast voltage swings leak current into nearby circuits.
   • Together, they smear out sharp edges, making 1s and 0s harder to detect.
3. Crosstalk & interference
   • Nearby electronics (motors, Wi-Fi, DC-DC converters) can induce noise currents into your wire.
   • Your single-ended receiver can’t tell “is this 2.5 V because of data, or because of noise?”

👉 At low speed this is tolerable. At 1–10 Gbps, it’s catastrophic.

---

2. The better way: differential signaling (two wires)

[ Transmitter ]───Signal+───┐
                           [ Receiver measures ( +  –  ) ]
[ Transmitter ]───Signal–───┘

• We send the same data, but as two opposite signals:
  • “1” = +0.2 V on Signal+, –0.2 V on Signal– (relative to bias).
  • “0” = the opposite.
• The receiver ignores absolute voltage and looks only at the difference.

Why this is robust

1. Common-mode noise rejection
   • If a nearby source couples +0.05 V of noise into both wires, the difference stays the same. Noise cancels.
2. Lower voltage swings
   • Instead of swinging 0–5 V, you only swing a few hundred millivolts.
   • Faster transitions, less radiation, lower power.
3. Balanced currents
   • Current going out on Signal+ returns on Signal–.
   • Their electromagnetic fields mostly cancel → little radiation, no “antenna.”

---

3. Why the 3 pads (Signal+, Ground, Signal–)

On your breakout board, each differential pair is exposed like this:

   [ Pad: Signal+ ]   [ Pad: GND ]   [ Pad: Signal– ]

This Ground–Signal–Ground (GSG) geometry solves the physics problems of high speed:

1. Tight return path
   • The ground pad (and plane underneath) provides an immediate “highway” for return current.
   • That keeps the electromagnetic field loop small → less radiation, more controlled impedance.
2. Field containment (“walls”)
   • Imagine the fields around a wire as soap bubbles.
   • With ground planes/walls nearby, the bubble is squeezed in and can’t spread into space.
   • Result: no accidental antenna, less crosstalk to neighbors.
3. Probe-friendly
   • Engineers can clip a differential probe across Signal+ and Signal– while the ground pad provides stable reference.

---

4. Visual: why single-ended is noisy vs differential+ground

Single wire + ground far away

Signal  ───────────────────────────────►
   |                                    (large loop area radiates)
  GND──────────────────────────────────►

• Big loop area → radiates like an antenna.
• Noise can couple in easily.

---

Differential pair, no ground nearby

Signal+ ─────────►
Signal– ─────────►   (fields cancel somewhat, but still spread out)

• Better (balanced currents), but fields still spill out → EMI risk.

---

Differential pair with ground in middle (GSG)

Signal+ ─► || GND || ◄─ Signal–
              ^
              | tight field return

• Fields are squeezed between signal and ground.
• Energy stays in a confined “waveguide.”
• Minimal radiation, minimal noise pickup.

---

✅ In plain words:
High-speed single wires fail because fast current changes create radiation, noise, and distortion. Differential pairs fix most of this by canceling noise and containing fields. Adding ground close to them (your 3-pad layout) “puts up walls” that keep the signals clean, stable, and measurable at gigabit speeds.

So from that we now know that voltage isn’t it going up and down from 0V to 3.3V and that is why we have that reading. That is actually the common bias that it is operating at, and the signal is actually the difference FROM that bias. But that changing too fast for the multimeter to pick up.

The Fluke (multimeter) reports the voltage at the red probe minus the black probe. If black is on the “reference” pad and the red pad happens to be at a lower potential (or your “ground” pad isn’t actually ground), it shows a negative number. The magnitude (~1.49 V) tells the story: you’re reading the common-mode bias, which is exactly what we expect on CML lines.

So from ground to the middle pad it is ~+1.5V. And then from that middle pad to the left pad and right pad it is ~-1.5V. The signal is the difference from that bias!

I then thought about why the Tx bias was much lower.

Some ChatGPT research:

. What the bias voltages are for

• RX pair (RD+/RD–):
  These are outputs from the SFP module. Inside the module is a transimpedance amplifier (TIA) converting the photodiode current into a high-speed differential electrical signal. That amplifier biases the lines at a common-mode DC level (~1.2–2.0 V) so the host board can AC-couple into its SERDES input.
  → That’s why you measure ~1.5 V. The module itself is driving it.
• TX pair (TD+/TD–):
  These are inputs to the SFP module. The host board is supposed to provide the high-speed differential signals from its SERDES. The SFP spec requires the host to AC-couple its transmitter into these pins.
  → On a breakout board with no SERDES driving TX, the lines just sit near 0 V, or whatever leakage/termination resistors pull them to.

---

2. Why you’re seeing ~0.05 V on TX pads

• Since your board is an experimenter breakout, there’s no active transmitter chip driving TD+/TD–.
• The SFP module expects to see a high-speed AC-coupled drive coming in from the host.
• In the absence of that, the pins float close to ground through bias resistors. The ~0.05 V you see is just leakage or default bias — not an error, just an idle input.

---

3. Why RX vs TX is asymmetric

• RX lines → SFP outputs → have a bias voltage (so they can drive the host).
• TX lines → SFP inputs → need the host to provide bias and signal swing (through coupling capacitors).

This is spelled out in the SFP MSA:

• RX outputs: “CML, AC-coupled internally, biased at ~2 V common-mode.”
• TX inputs: “CML, must be AC-coupled from host, 100 Ω differential termination inside module.”

---

4. How to test this yourself

• With no SERDES chip on your breakout, TX will sit near 0 V (like you measured).
• If you hooked up an FPGA/PHY to the TX lines and drove data, you’d measure a DC offset closer to the host’s bias point (after coupling caps).
• An oscilloscope would then show the high-speed swings around that bias.

---

✅ Summary:

• Your ~1.5 V on RX = normal → the SFP module’s internal RX circuitry is providing bias.
• Your ~0.05 V on TX = also normal → those are inputs, so without a host SERDES driving them, they just sit near ground.
• Nothing’s wrong with your breakout — it’s simply not sourcing the TX bias because the design assumes the host system provides it.

That makes sense. Just adding a bias isn’t sending data. Needs to set an offset on both the Tx- and Tx+ to send bits.

Research also made me realize that the I2C needs to be “driven”. So my goal of being able to read I2C using the Siglent Oscilloscope will not work. There is no media converter driving the SFP to tell it about itself.

In retrospect that is obvious. What is the SFP supposed to do, just announce itself on I2C over and over without anyone asking? The SFP is meant to take in electrical signals and push them out with lasers. It is meant to be “dumb”.

With some research it is clear that the SDA and SCL wires must be “driven”. Which is pretty interesting. There is an ability that is just “latent”. It is like someone sleeping and you can shake them awake and they will reveal their secrets.

I opened up a media converter and it has a big chip in it. That is what is doing a lot of the “thinking” it seems like.

Thoughts

Wasn’t sure if this would be a good use of time, it is just proving obvious things, but turns out that actually seeing all the signals does seem to make the information “stickier”.

Going to find a device to drive I2C communication with the breakout board so I can get a better feel for I2C communication. It seems to run everything so I should wrap my head around it.

Also need to come up with some analysis if this FSOC is even feasible. Going to make a system design for the FSOC system and see if physics will allow it to exist.