Does the 49 USD Ubiquiti SFP Wizard recode third-party optics or only Ubiquiti modules
Small homelab, two second-hand switches and a drawer of optics collected over the years, most of which the hosts refuse because of the vendor code. Recoding has always been the blocker: a proper programmer sits around 369 USD, which is more than I paid for the switches, and the Ubiquiti SFP Wizard at 49 USD suddenly makes the idea look affordable.
- hosts I need to satisfy: Huawei S5731 and S6730, plus an HP 6120XG
- programmer under consideration: UACC-SFP-WIZARD
- what is in the drawer:
FTLX8571D3BCV
FTLX8574D3BCV
SNR-SFP+W73-3
SNR-SFP+W37-3
J9150AWhat I have gathered so far is that it reads EEPROM, reads DDM, can teest a module, and copies EEPROM content from one module onto another. What I cannot work out is which module ends up being written: does the target have to be a Ubiquiti one, and is there a field where I simply type in the vendor name and part number I want?
So, plainly: can this thing recode the modules I already own so the Huawei and the HP accept them, or does it only program Ubiquiti optics? If it is the latter, is there any point in it for a lab like mine?
Comments 2
Only Ubiquiti optics on the write side, and the direction is the mirror image of what you want. You insert a third-party module, it reads that module's EEPROM, and it writes that data onto a Ubiquiti SFP or QSFP module so the Ubiquiti part mimics the vendor your switch expects. Reading DDM, testing a module and pulling updates over the air are all in the box too, but there is no free-form field for an arbitrary vendor code, and the thing being programmed is a Ubiquiti module. Same model as the FS box: cheap programmer, tied to that vendor's own optics.
For your drawer that means the Finisar, SNR and HP parts stay exactly as they are. What they can be is the source: read the code off a module the Huawei already accepts, write it onto a Ubiquiti optic, run that. Whether it pays off depends on how many Ubiquiti modules you are prepared to buy on top of the programmer.
Two details from the early release notes: there was a file-naming bug in the suppotr dumps, and recovery of the UF-RJ45-10G was not supported yet. Neither is fatal, but do not buy it as a rescue tool for that part specifically.
If the goal is recoding modules you already own, you are back to a general-purpose programmer. SNR SFP Writer, the SFPTotal Plus series, or a CH341-based board if you do not mind wiring things up yourself. They write what you tell them, within limits.
The limits are the interesting part. Not every module behaves like a plain EEPROM. Some have a microcontroller pretending to be the A0/A2 pages, and a chip like that can ask for a password or expect a vendor challenge instead of simply handing over bytes: the Medick SFP-10G-BX with a C8051F392 is the stock example. HP and Aruba parts with an interactive EEPROM and keys are the hardest case anyone has described, so I would not assume the J9150A is trivially rewritable.
There is also the blunt route for when the cage gets in the way: solder to pins 4 and 7 of the module, the I2C SDA and SCL lines, and talk to it outside the socket. People report successful writes that way for Huawei and HP hosts, though you are on your own if you cook a module. If you build an adapter instead, mind the rest of the SFP+ pinout, TX_Disable on 3, Mod_Abs on 6, VeeR on 9, or the module sits there disabled and you blame the programmer.