Differences

This shows you the differences between two versions of the page.

--- rnd:projects:aft [2022-12-20 22:58] – [Data entry] asdf
+++ rnd:projects:aft [2023-05-07 02:54] (current) – asdf
@@ Line 1: / Line 1: @@
-====== AFT: A fiber tracer ======
+====== AFT fiber tracer ======
 ---- dataentry projects ----
 status_ : active
-oneline : A tool for tracing fiber lines
+oneline : a tool for tracing fiber optic lines
 ----
 I have on occasion required a tool for identifying fiber optic lines at work. While it isn't often enough to justify the expense of a proper fiber test device, it might be within my capabilities to construct a basic fiber "toner" set.
-The project's working title is AFT (Arduino Fiber Tracer or Adequate Fiber Tracer).
+The project's working title is AFT (Arduino Fiber Tracer or Adequate Fiber Tracer or AFT Fiber Tracer).
 ===== Background =====
@@ Line 14: / Line 13: @@
 ==== SFP modules ====
-SFPs (small form-factor pluggable) are compact IR transceivers designed for fiber optic networking. There are two major advantages to using an SFP in this device. First, it puts the tester on equal footing with the devices in the live environment. We don't have to worry about propagation distances; if the tester can't transmit over the entire fiber run, then neither will a switch be able to. Second, it allows the tester to check the SFP itself using DDM/DOM [(ddm_dom)] or I2C [(sfp_i2c)]. In the future, we may also be able to program the tester to talk to live network devices to help determine where the other end of the cable goes((It seems likely that an Arduino Uno is not fast enough to process Ethernet frames. One of the beefier boards may, but this feature is not essential for the tester as described.)).
+SFPs (small form-factor pluggable) are compact IR transceivers designed for fiber optic networking. There are two major advantages to using an SFP in this device. First, it puts the tester on equal footing with the devices in the live environment. We don't have to worry about propagation distances; if the SFP-equipped tester can't transmit over the entire fiber run, then neither will a switch be able to. Second, it allows the tester to check the SFP itself using DDM/DOM [(ddm_dom)] or I2C [(sfp_i2c)]. In the future, we may also be able to program the tester to talk to live network devices to help determine where the other end of the cable goes((It seems likely that an Arduino Uno is not fast enough to process Ethernet frames. One of the beefier boards may, but this feature is not essential for the tester as described.)).
 The electrical pinout is shown in {{ref>tab_sfp_pinout}}.
@@ Line 24: / Line 23: @@
 | 2 | Tx_Fault | Transmitter fault indication |
 | 3 | Tx_Disable | Optical output disabled when high |
-| 4 | SDA | 2-wire serial interface data line (using the CMOS EEPROM protocol defined for the ATMEL AT24C01A/02/04 family) |
+| 4 | SDA | 2-wire serial interface data line (using the CMOS EEPROM protocol defined for the ATMEL AT24C01A/02/04 family [(twi_protocol)]) |
 | 5 | SCL | 2-wire serial interface clock |
 | 6 | Mod_ABS | Module absent, connection to VeeT or VeeR in the module indicates module presence to host ((This is a prime target for connecting to a falling interrupt.)) |
@@ Line 43: / Line 42: @@
 </table>
-For the prototypes, we will be using the Osmocom SFP Experimenter board. This breakout contains all support circuitry required to send single-ended signals through an SFP. No restriction is made on the input data, so we need not send valid Ethernet frames. That opens up the question of how we are to encode the data for transmission [(data_encoding)]. Of course, instead of sending arbitrary bits, we could instead transmit a clock.
+<WRAP center round tip 60%>
+The ''Tx_disable'' pin is connected to an internal pull-up resistor inside the module. This pin must be pulled low to enable the transmit laser.
+</WRAP>
+==== Osmocom SPF experimenter ====
+For the prototypes, we will be using the Osmocom SFP Experimenter board. This breakout contains all support circuitry required to send single-ended signals through an SFP. No restriction is made on the input data, so we need not send valid Ethernet frames. <del>That opens up the question of how we are to encode the data for transmission [(data_encoding)]. Of course, instead of sending arbitrary bits, we could instead transmit a clock.</del> There's no need to encode the data ourselves---just use hardware UART pins.
 For whatever reason, the SFP Experimenter board is designed to accept I/O connections through SMA connectors (one per stream). The units ship without the connectors soldered to the board, so we can add whatever kind of interface we want---simple wires will do.
+The I2C bus on the board already includes pull-up resistors, so no external pull-ups are required.
 ==== SFP data registers ====
-SFP modules expose a great deal of data detailing their internal status, all accessible through I2C at one of two addresses (''0xA0'', ''0xA2'').
+SFP modules expose a great deal of data detailing their internal status, all accessible through I2C at one of two addresses (''0xA0'', ''0xA2''). Before data can be read, the EEPROM address must be loaded in by performing a dummy write containing the 8-bit EEPROM address to retrieve. For example, the device vendor name is stored in 16 bytes at I2C address ''0xA0'', EEPROM address 20. The following snippet demonstrates this procedure.
+<code cpp>
+// load in the EEPROM address
+Wire.beginTransmission(0x50);
+Wire.write(20);
+Wire.endTransmission();
+// request the data
+Wire.requestFrom(0x50, 16);
+// data is now ready for read(), see docs
+</code>
+After each read, the internal address register is incremented so it points to the next byte. Given the way we're most likely to access this table, this fact is of relatively little use to us.
+<table |tab_sfpreg_50>
+<caption>Registers of interest at I2C address 0x50</caption>
+<datatables paging="false">
+^ Value ^ Address (dec) ^ Data length ^
+| Manufacturer name (ASCII) | 20 | 16 |
+| Compliance code | 3 | 8 |
+| Nominal signalling rate (100s Mbd) | 12 | 1 |
+| Supported optional DDM features | 93 | 1 |
+</datatables>
+</table>
+<table |tab_sfpreg_51>
+<caption>Registers of interest at I2C address 0x51</caption>
+<datatables paging="false">
+^ Value ^ Address (dec) ^ Data length ^
+</datatables>
+</table>
+==== Serial data transmission ====
 ===== Design =====
-The idea is to have a pair of Arduino-based devices. For a given test session, one (designated the sender) is connected the the line under test and begins transmitting a particular signal. The other (designated the receiver) watches for this signal. Once it finds the signal, it can send a reply back to confirm that the sender is indeed on the other end. Each device should be equipped with a display and a handful of buttons for communicating with the user.
+The idea is to have a pair of Arduino-based devices. For a given test session, one (designated the toner) is connected the the line under test and begins transmitting a particular signal. The other (designated the probe) watches for this signal. Once it finds the signal, it can send a reply back to confirm that the toner is indeed on the other end. Each device should be equipped with a display and some kind of controls for communicating with the user.
 ==== User interface ====
@@ Line 78: / Line 120: @@
 ===== Prototyping =====
-  * 2x [[https://store-usa.arduino.cc/collections/boards/products/arduino-uno-rev3|Arduino Uno Rev3 (\$28)]]
+  * 2x <del>[[https://store-usa.arduino.cc/collections/boards/products/arduino-uno-rev3|Arduino Uno Rev3 (\$28)]]</del> Arduino Leonardo
   * 2x [[https://shop.sysmocom.de/SFP-experimenter-board-v2-kit/sfp-exp-v2-kit|Osmocom SFP experimenter (€65.45)]]
   * 2x [[https://www.adafruit.com/product/498|20x4 LCD with RGB backlight (\$25)]]
@@ Line 87: / Line 129: @@
 We don't want to rely on the Osmocom SFP Experimenter board for the final product, but it has the major advantage of a built-in differential transmitter and receiver((If sending differential signals, must they be of the same magnitude? Can I send a clock into one side and the actual data into the other? Need to read more and possibly simulate this.)).
-{{ref>tab_pin_usage}} indicates proposed pin connections. Items in bold are ideally suited for interrupts.
+{{ref>tab_pin_usage}} indicates proposed pin connections. Underlined items are ideally suited for interrupts((Since the controls will be operated at human speed, interrupts probably aren't necessary for the encoder.)).
 <table |tab_pin_usage>
@@ Line 93: / Line 135: @@
 | ^ Device pin ^ ^ Arduino pin ^
 ^ LCD ||||
-| | RX |  <-  | D8 |
+| | RX |  <-  | D8 (''SoftwareSerial'') |
 | | +5V |  <-  | +5V |
 | | GND |  <-  | GND |
@@ Line 99: / Line 141: @@
 | | +3.3V |  <-  | +3.3V |
 | | GND |  <-  | GND |
-| | **RX** |  ->  | |
+| | __RX__ |  ->  | D0 (''Serial1'') |
-| | TX |  <-  | |
+| | TX |  <-  | D1 (''Serial1'') |
-| | SDA |  <->  | SDA |
+| | SDA |  <->  | SDA/D2 |
-| | SCL |  <->  | SCL |
+| | SCL |  <->  | SCL/D3 |
-| | TX_FAULT |  ->  | |
+| | TX_FAULT |  ->  | D5 |
-| | MOD_ABS |  ->  | |
+| | MOD_ABS |  ->  | D4 |
 ^ Rotary encoder ||||
-| | **Enc A** |  ->  | |
+| | __Enc A__ |  ->  | D18 |
-| | **Enc B** |  ->  | |
+| | __Enc B__ |  ->  | D19 |
 | | GND |  <-  | GND |
-| | **Sw A** | | |
+| | __Sw A__ |  ->  | D17 (''INPUT_PULLUP'') |
-| | Sw B | | |
+| | Sw B | | GND |
 </table>
+==== Communication ====
+UART transmission is not looking terribly promising at this time.
+Different SFP models appear to produce different signals when the output is open. The SMF unit (unknown vendor) outputs nothing, while the Veloso units send (noisy) pulse trains (see {{ref>fig_idle}}). They also respond differently to inputs, with the former producing an inverted replica of the input and the latter outputting what might be PWM ({{ref>fig_k}}).
+<figure center|fig_idle>
+ <subfigure |fig_smf_idle>
+ {{ :rnd:projects:smf-idle.png?400 |}}
+<caption>SMF</caption>
+ </subfigure>
+ <subfigure |fig_veloso_idle>
+ {{ :rnd:projects:veloso-idle.png?400 |}}
+<caption>Veloso</caption>
+ </subfigure>
+<caption>Idle responses from signal loopback</caption>
+</figure>
+<figure center|fig_k>
+ <subfigure |fig_smf_k>
+ {{ :rnd:projects:smf-k.png?400 |}}
+<caption>SMF</caption>
+ </subfigure>
+ <subfigure |fig_veloso_k>
+ {{ :rnd:projects:veloso-k.png?400 |}}
+<caption>Veloso</caption>
+ </subfigure>
+<caption>Responses to UART ''k'' at 115200 baud, 8N1</caption>
+</figure>
 ==== Power considerations ====
 Portable operation is a must for this tester.
@@ Line 118: / Line 188: @@
 ===== Relevant links =====
-  * [[https://learn.adafruit.com/using-an-infrared-library|using an IR Arduino library]]
-  * [[https://learn.adafruit.com/adafruit-pirkey-python-programmable-infrared-usb-adapter|Python-programmable IR USB receiver]]
-  * [[https://learn.adafruit.com/ir-sensor|IR sensor tutorial]]
-  * [[https://learn.sparkfun.com/tutorials/industrial-fiber-optics-hookup-guide/all|some fiber transceiver boards]]
-  * [[https://www.sparkfun.com/products/17508?_ga=2.165010367.1034260917.1665095188-110848090.1665095188|serial fiber duplex modem]]
-  * [[https://www.sparkfun.com/products/17510?_ga=2.165010367.1034260917.1665095188-110848090.1665095188|fiber duplex breakout]]
   * [[https://www.adafruit.com/product/714|I2C LCD shield kit with keypad]] (LCD not included)
-  * [[https://www.adafruit.com/product/4167|1W fiber optic light source]]
   * [[https://osmocom.org/projects/misc-hardware/wiki/Sfp-experimenter|Osmocom SFP experimenter]]
   * [[https://cotsworks.com/support-documents/single-ended-vs-differential/|single-ended vs differential signals]]
@@ Line 131: / Line 194: @@
   * [[https://www.mouser.com/ProductDetail/TE-Connectivity/5-5530843-0?qs=sGAEpiMZZMtWxQ3D3EXBN0Ey9L8xlYZ5WRp665TwrBg%3D|a card edge connector that might actually work]]; [[https://edac.net/series/395|the EDAC 395 series]] (specifically 395-020-558-xxx models or 395-020-520-201) are also promising
   * [[https://www.adafruit.com/product/781|Adafruit Serial+USB LCD backpack]]
-  * the [[https://learn.adafruit.com/adafruit-feather/overview|Feather]] platform might also be a viable brain for this project; the [[[[https://www.adafruit.com/product/2771|32u4 model]] is software/pin compatible with Arduino and features built-in battery connections and monitoring
+  * the [[https://learn.adafruit.com/adafruit-feather/overview|Feather]] platform might also be a viable brain for this project; the [[https://www.adafruit.com/product/2771|32u4 model]] is software/pin compatible with Arduino and features built-in battery connections and monitoring
+  * the [[https://www.pjrc.com/store/teensy41.html|Teensy 4.1]] may also be a good production brain; it's also compatible with Arduino, has many more interrupt pins; if we use the model with Ethernet header and connect [[https://www.pjrc.com/store/ethernet_kit.html|a matching jack]], we might be able to use it to tone out copper lines as well (as long as they're **not** energized)
   * [[https://www.adafruit.com/product/2078|Adafruit PowerBoost 500 rechargeable shield]]
-  * [[https://www.adafruit.com/product/326]]
+  * [[https://www.adafruit.com/product/326|Adafruit 0.96" 128x64 monochrome OLED display]]
   * [[https://lastminuteengineers.com/rotary-encoder-arduino-tutorial/]]
+  * [[https://www.instructables.com/Improved-Arduino-Rotary-Encoder-Reading/]]
+  * [[https://github.com/Stutchbury/EncoderButton]]
+  * [[https://www.instructables.com/Manchester-Code-Library-for-Arduino/]], [[https://github.com/mdeudon/Manchester]], [[wp>manchester code]]
+  * https://www.ti.com/lit/ug/tidu366/tidu366.pdf
+  * https://cdn.hackaday.io/files/21599924091616/AN_2030_DDMI_for_SFP_Rev_E2.pdf
+  * https://gitea.osmocom.org/electronics/osmo-small-hardware/raw/branch/master/sfp-breakout/sfp-experimenter.pdf
+  * https://www.ti.com/lit/ds/symlink/sn65lvds1.pdf?ts=1672100269172&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FSN65LVDS1%252Fpart-details%252FSN65LVDS1D%253Futm_source%253Dgoogle%2526utm_medium%253Dcpc%2526utm_campaign%253Docb-tistore-promo-asc_opn_en-cpc-storeic-google-wwe%2526utm_content%253DDevice%2526ds_k%253DSN65LVDS1D%2526DCM%253Dyes%2526%2526utm_source%253Dgoogle%2526utm_medium%253Dcpc%2526utm_campaign%253D%2526utm_content%253D%2526ds_k%253Dsn65lvds1d%2526DCM%253Dyes%2526gclid%253DCjwKCAiAqaWdBhAvEiwAGAQltruYrSedpQ0uALxXlAq5xiuhmzbVhkdHlCKyi0L3cz9s1VCdN4uf8xoCVpwQAvD_BwE%2526gclsrc%253Daw.ds
+  * https://hackaday.com/2020/05/11/new-teensy-4-1-arrives-with-100-mbps-ethernet-high-speed-usb-8-mb-flash/
+  * https://twitter.com/PA4DAN/status/1108517564005695491/photo/1
+  * https://www.fluxlight.com/content/Tech-Docs/AdTran%2012004800%20Datasheet.pdf
+  * https://hackaday.com/2021/02/13/experiment-with-sfp-modules-with-this-handy-breakout/
 ===== References =====
@@ Line 142: / Line 217: @@
 [(sfp_i2c>[[https://members.snia.org/document/dl/25916|SFF-8472]])]
 [(pwm_read>[[https://www.benripley.com/diy/arduino/three-ways-to-read-a-pwm-signal-with-arduino/]], [[https://create.arduino.cc/projecthub/kelvineyeone/read-pwm-decode-rc-receiver-input-and-apply-fail-safe-6b90eb]])]
+[(sparkfun_serialcomm>https://learn.sparkfun.com/tutorials/serial-communication)]
+[(twi_protocol>https://ww1.microchip.com/downloads/en/devicedoc/doc0180.pdf)]
+{{tag>electronics}}