modified: Sunday 29 January 2023
Project: RJtoner, a multiway network cable toner/tracer (plus open source STC micro stuff)
Multiway cable tracer or “toner”. Each board does 4 cables, so you add more with unique sound clips and piggy-back power across:
I once worked for a site with nightmarish network and PBX cabling. Most of the RJ45 wallplates were labelled, but only some worked and many labels were completely wrong. The wiring was a hydra that each previous tech had only touched the minimum on (death by a thousand cuts). I wasn’t a registered cabler (so I couldn’t fix in-wall wiring) but even being able to correctly re-label RJ45 wallplates and tape over the bad ones was a godsend.
Cable toners were expensive, especially those with more than one send channel. I thought that was stupid and made my own.
Obligatory: this design is unsafe, no warranty whatsoever, you MUST obtain expert advice on how to fix the safety shortcomings of this design (of which I have identified SOME below) before making and building it. I’m publishing this design because I think it’s worth discussing the design. I’ve intentionally removed the gerbers to reinforce this.
- rj toner numerical.tar.xz - Kicad schematics, PCB and STC source code.
- rjtoner_v2_dac.pdf - PDF schematic
- voicedac3b.c - Main sourcecode for STC micro
How it works
Each board has 4 outputs. An audio recording of my voice saying a number is sent out over each ethernet port (centre pair only). There is some additional complexity in terms of safety & protection (see below). That’s mostly it.
I set it up at the rackmount patch panel cupboard and plugged it into as many ports/cables as possible. I then walked around with a protected speaker+amplifier, plugging that into wall ports until I heard my voice saying a number.
The photos above only show one corner of the hydra — you might even notice that many of these cables are NOT terminated into a patch panel but instead have RJ45’s crimped directly onto them. Length differences were massive too, some cables hung meters out of the cupboard but others could barely make it to the panel within the cupboard itself. This is what I meant by “death by 1000 cuts”: I suspect every tech that has been in here didn’t have the resources to tackle this (nor would they expect turning a 2 hour job into a 2 day job to agree with the customer), so they just snipped and tested cables until one worked well enough for what they wanted and left.
The speaker box is just a speaker, amplifier, batteries, RJ-45 keystone and some protection circuits (similar to the mainboard). I’m not posting a schematic here, you can make your own by modifying some cheap 2nd hand speakers, just make sure to duplicate the same protection circuitry as the toner itself.
Audio output circuitry & protection
Ethernet and PBX wiring can hide all sorts of nasties that can blow up your toner or zap you. Actual ethernet signalling is mostly harmless, but PBX systems can output 12-48VDC over the wires, external POTS (telephone lines) can do 100VAC whilst ringing and if you’re really unlucky then 240V mains might also be on the wires (because why not). You need to be able to safely survive all of that and also notify the user that something is seriously wrong.
Legal sidenote: you’re not allowed to plug uncertified equipment into POTS lines in many countries. The POTS lines in this cupboard were (thankfully) very separate and easy to identify. But that doesn’t mean you shouldn’t be prepared for mistakes.
Here is a relevant snippet of the schematic:
On the left we start with the DAC chips. These get a digital stream of bits from the microcontroller and turn them into actual analog audio waveforms. This particular chip has a very simple interface (I2S) and was cheap at the time, but shortly went out of stock so I had to wait for some greymarket samples. An annoying reminder to buy your parts before you order your PCBs.
Next is an opamp configured as a 2nd order Sallen-Key lowpass filter (OKAWA electric design has a nice calculator for these ). DACs like this output lots of harmonics above their operating frequency (which sound bad), this filter cuts most of it out.
We now get to the protection circuitry. LEDs are used to clamp the voltages being fed back into the opamp, so (in this case) no more than 2V is possible. This, combined with the resistors and capacitors, prevents you from frying the circuit if you somehow end up with 240VAC on the ethernet jack. I sized and specced the resistors and capacitors to be able to handle 240V continuous, but it would be wise not to trust me.
(1) Can’t handle lightning. In my application this wasn’t strictly necessary (all wiring was internal within one small building) but it becomes important when you deal with bigger buildings, sites with wiring between buildings and wires that go out into the street (like POTS lines).
I don’t have experience here, reading some application notes and reverse engineering some existing tools would be good starting points. I believe gas discharge tubes are useful, but they may have to be augmented with other components.
(2) Doesn’t identify DC. I had originally arranged the parts so that the LEDs would light when DC was applied (eg 48V phantom power from a PBX or POTS). In the end I stuffed this up by capacitively coupling everything.
h3. Protection shortcoming 3: Needs a proper voltage-rated plastic case
(3) Needs a sealed plastic case. Protects against shock and explosion (designing cases isn’t neccesarily simple). Plastic choice is also complex, some plastics are conductive due to eg carbon black.
The four horses of IT. Bringers of destruction and packet loss.
Four Horses Rescue was an experimental business name idea. The logo makes it look like a veternarian. Needs more printers.
(If you do have horses: take them for a visit to your local IT shop! The staff will love the distraction and they can help with RMAs. Don’t worry, the staff are already used to shit being walked in and dumped.)
Jay Carlson’s $1 Microcontroller comparison got me interested in STC 8051 microcontrollers. When I discovered that you could use a fully open source toolchain on them I was in love: they looked like AVRs but with (at the time) more memory and peripherals for the money.
General praises to sing:
- The 8051 arch has standardardised peripherals and and addresses. This means one codebase and one compiler can targets lots of chips without headache. Compared to the ARM ecosystem this is a masterwork.
- Programming STCs requires nothing more than a USB serial adapter. Everything is done over that. Cheap and generic, no special tools required.
- Open source toolchains for micros are almost universally better than vendor-provided ones. Trust me, broken bloated multi-gigabyte IDEs written by hardware designers are not peaceful nor stable over the long term
- Internal clocksource that works by default.
- Minimal “fuses” compared to AVRs. ie you modify setting registers at run-time, not programming-time.
- 8051 ISA is horseshit. Too many types of RAM and memory. You can avoid most of this by coding in C instead of assembly, but…
- NEVER EVER use pointers in SDCC without the extra keywords to specify what memory type they point at. Otherwise SDCC implements them as generic pointers with lots of code branches and complexity. The SDCC manual is useful here.
Compiling and uploading
I used the small device C compiler (SDCC) for compilation and stcgal for uploading my code to the board.
SDCC generates some junky intermediate files and you have to convert the output format before using stcgal. A little annoying, but not unsolvable. Checkout voicedac_stc/build.sh in the source archive.
Getting the STC micro headers
If you only use standard 8051 peripherals: no wakkas. Sadly some standard peripherals are missing from STC chips and instead replaced by nonstandard ones, so your hand gets forced even for simple stuff sometimes.
The only source of the STC headers is the official STC ISP software which contains a GUI exe that generates them.
Problem 1: The character set encoding is weird (GB2312). It took me lots of trial and error to work out what it was.
Problem 2: It’s in keil (not SDCC) format.
Solution: sdcheaderconvert.sh. I’m not sure if it still works but it should help.
Getting started with STC chips
Not much is needed: a USB UART, a protoboard, a cap and some wires are usually enough. No crystal needed.
Here is a shot of an earlier design where I made my own 8-bit resistor DACs:
The STC chips don’t have enough flash memory for all of the audio samples. Each chip only holds the 4 it needs for its board.
In audacity I downsampled the recordings to 8000Hz mono. I then used ffmpeg to crush them to 8 bits per sample raw PCM files. Finally I used xxd to convert them to header files, because #embed is not a thing in C yet