Hi all,
I have a need to optically couple and control some low frequency (50Hz up to 4KHZ) mosfets. There will be 48 separate, independent mosfets in total that will be some distance from the processor controlling them.
I could run balanced pairs of copper, with say, RS485, but a seemingly neat solution would be to use optical audio SPDIF TX and RX pairs. The component count would be very low, and the tx, rx and cables are very cheap, under $1 each, from AliExpress.
I thought the TX and RX were just an LED and a phototransistor, but I think I am mistaken. The listing says they are TTL compatible. That's great but..... Does the transmitter already modulate the signal by itself?
If I am just clocking the TX data in pin at 50Hz, or even 1Hz, does the receiver just give me a 50Hz/1Hz signal out? Or is it more complicated than that?
Here is the aliexpress listing that I have bought. It says it works up to 16Mhz. I guess I will find out, but prefer to have a think about my approach as I wait 1 or 2 months for delivery.
https://www.aliexpress.com/item/4001159117440.html
I don't know the answer, but I'm really curious to hear what you find. I've long been interested in the idea of using TOSLink parts for simple optical networking, but haven't gone very far down the path of working out how to do it. I got as far as ordering some transceivers and stuff, and doing some reading and that's it.
Based on
this article I'm pretty sure it's possible in principle, but I guess you'd have to read the datasheets for the transceivers or find some other docs / samples to work out the details of how to make it all work.
Note I deleted my previous post as I incorrectly wired up the TX and RX in my tests. Short story is they work just fine from DC to 16Mhz.....
Long story:
Now today I purchased a SPDIF TX and RX pair from Altronics. Part numbers Z1603 and Z1604.
The actual manufacturer parts were labelled DLR1151 and DLT1151. No markings of the actual brand though. And a google search showed a small handful of different pinouts with the same or similar part numbers...... VERY ANNOYING
The DLR is the Receiver, the DLT is the Transmitter.
Firstly, I could not find a good datasheet for the transmitter. I thought it was just an LED. The pic in altronics catalog shows just two pins, but the actual part had 3.....
I connected just two wires..... a battery through resistor and found the led glowed, so I thought all was good.
But, after much testing I found that ACTUALLY, it is a 3 pin "smart" device, that needs +5v, data in, and ground.
The pinout of the TX looking into the hole from left to right is:
data in, 5V, Gnd
The pinout of the RX looking into the hole from left to right is:
5V, Ground, data out
Now that that is settled, the parts work very very well from DC to 1Mhz. I did not bother testing more than 1Mhz.
So I'll leave this here so that I can reference it at a later date. These SPDIF cables will come in very handy for my future projects as well as the current one. They are literally a single part solution to what would otherwise be a lot of head scratching, trying to find EMI sources and earth loops....
If you invert the logic – so that idle and stop bits are LED OFF –, you can trivially push UART through a TOSLINK or two (for a bidirectional link, you obviously need two, since each TOSLINK cable is unidirectional).
You do want to limit the LED duty cycle to under 75%, to keep the dissipated heat to within limits in the transmitter. With 8N1, you have at least the start bit high and stop bit low, so the duty cycle is between 10% and 90%. With 8N2, between 9% and 82%. If you transfer ASCII text, duty cycle will be between 20% and 70% for 8N1, and between 18% and 64% for 8N2.
Here are the original Toshiba TOSLINK transmitters I know of:
TOTX141 and TOTX141P are three-pin devices for 3.3V logic, and the datasheet recommends a 100nF bypass capacitor between VCC and GND.
TOTX1350 is a two-pin device, and seems to require a buffer/driver (like HC04, a hex inverter) and a couple of resistors and capacitors; the LED is driven at 1.5mA to 6mA, with a forward voltage of about 2 V.
TOTX1353 is a three-pin device, and requires a current-limiting resistor to the VCC pin. The forward voltage of the LED is about 2 V, and only needs 1.5mA; so 2.2kOhm at 5V, or a 820 Ohm at 3.3V.
Here are the original Toshiba TOSLINK receivers I know of:
TORX141 and TORX141P are three-pin devices for 3.3V logic, and the datasheet recommends a 100nF bypass capacitor between VCC and GND, as well as a 47µH inductor between supply and VCC.
TORX1350A is a three-pin 5V logic device, and the datasheet recommends a 100nF bypass capacitor between VCC and GND, as well as a 47µH inductor between supply and VCC.
TORX1353 is a three-pin 5V logic device, and the datasheet recommends a 100nF bypass capacitor between VCC and GND.
I do believe most of the devices you'll encounter are clones or compatible to one of these three. (If you discover otherwise, do let me know, please!)
For current 3.3V microcontrollers, it seems to me that to transmit using TOTX1350's, one needs a buffer/inverter and a couple of passives, but the overall current is much less (1.5mA - 6mA, compared to 15-20mA on '141). To receive using TORX135x's, one needs a voltage level translator to 3.3V logic and a 5V supply (SN74LVC1T45 would be my choice), but the overall current is similarly reduced compared to older '141s.
If you invert the logic – so that idle and stop bits are LED OFF –, you can trivially push UART through a TOSLINK or two (for a bidirectional link, you obviously need two, since each TOSLINK cable is unidirectional).
So would it be possible / reasonable then, to connect the data out pin of a TOSLink receiver to the RX pin on an Arduino serial port, and read serial data sent from the other end?
If you invert the logic – so that idle and stop bits are LED OFF –, you can trivially push UART through a TOSLINK or two (for a bidirectional link, you obviously need two, since each TOSLINK cable is unidirectional).
So would it be possible / reasonable then, to connect the data out pin of a TOSLink receiver to the RX pin on an Arduino serial port, and read serial data sent from the other end?
That's exactly what I did with a Teensy. Inverting the logic so the lines idle LED OFF is important, though. (It depends on the microcontroller whether you can do it in software, or whether you need to do it in hardware; and obviously if you use an inverting buffer to drive a two-pin transmitter like TOTX1350, you need to take that inversion into account also.)
Furthermore, if the link is between different microcontrollers, note that not all baud rates are created equal. On original ATmega328, for example, 115,200 baud will be at least 2% off because of its limited baud rate selection, no matter what you do. If both ends are the same MCU running at the same clock rate, you have no issues, as the exact baud rate doesn't matter that much, just that both ends agree; but mixing
actual baud rates is a problem. (There is a margin of error, but I prefer 1% or less; I'm picky.) Better check the actual baud rates you get with your hardware. On ARMs, 2M or even higher should work just fine.
If you invert the logic – so that idle and stop bits are LED OFF –, you can trivially push UART through a TOSLINK or two (for a bidirectional link, you obviously need two, since each TOSLINK cable is unidirectional).
So would it be possible / reasonable then, to connect the data out pin of a TOSLink receiver to the RX pin on an Arduino serial port, and read serial data sent from the other end?
That's exactly what I did with a Teensy. Inverting the logic so the lines idle LED OFF is important, though. (It depends on the microcontroller whether you can do it in software, or whether you need to do it in hardware; and obviously if you use an inverting buffer to drive a two-pin transmitter like TOTX1350, you need to take that inversion into account also.)
Gotcha. That doesn't sound too bad then. I'm definitely going to experiment with this.
Furthermore, if the link is between different microcontrollers, note that not all baud rates are created equal. On original ATmega328, for example, 115,200 baud will be at least 2% off because of its limited baud rate selection, no matter what you do. If both ends are the same MCU running at the same clock rate, you have no issues, as the exact baud rate doesn't matter that much, just that both ends agree; but mixing actual baud rates is a problem. (There is a margin of error, but I prefer 1% or less; I'm picky.) Better check the actual baud rates you get with your hardware. On ARMs, 2M or even higher should work just fine.
OK, yeah, I would have guessed that baud rate matching would be the most likely area for difficulties with this. It will be interesting to see how that works out.
If you invert the logic – so that idle and stop bits are LED OFF –, you can trivially push UART through a TOSLINK or two (for a bidirectional link, you obviously need two, since each TOSLINK cable is unidirectional).
You do want to limit the LED duty cycle to under 75%, to keep the dissipated heat to within limits in the transmitter. With 8N1, you have at least the start bit high and stop bit low, so the duty cycle is between 10% and 90%. With 8N2, between 9% and 82%. If you transfer ASCII text, duty cycle will be between 20% and 70% for 8N1, and between 18% and 64% for 8N2.
Here are the original Toshiba TOSLINK transmitters I know of:
TOTX141 and TOTX141P are three-pin devices for 3.3V logic, and the datasheet recommends a 100nF bypass capacitor between VCC and GND.
TOTX1350 is a two-pin device, and seems to require a buffer/driver (like HC04, a hex inverter) and a couple of resistors and capacitors; the LED is driven at 1.5mA to 6mA, with a forward voltage of about 2 V.
TOTX1353 is a three-pin device, and requires a current-limiting resistor to the VCC pin. The forward voltage of the LED is about 2 V, and only needs 1.5mA; so 2.2kOhm at 5V, or a 820 Ohm at 3.3V.
Here are the original Toshiba TOSLINK receivers I know of:
TORX141 and TORX141P are three-pin devices for 3.3V logic, and the datasheet recommends a 100nF bypass capacitor between VCC and GND, as well as a 47µH inductor between supply and VCC.
TORX1350A is a three-pin 5V logic device, and the datasheet recommends a 100nF bypass capacitor between VCC and GND, as well as a 47µH inductor between supply and VCC.
TORX1353 is a three-pin 5V logic device, and the datasheet recommends a 100nF bypass capacitor between VCC and GND.
I do believe most of the devices you'll encounter are clones or compatible to one of these three. (If you discover otherwise, do let me know, please!)
For current 3.3V microcontrollers, it seems to me that to transmit using TOTX1350's, one needs a buffer/inverter and a couple of passives, but the overall current is much less (1.5mA - 6mA, compared to 15-20mA on '141). To receive using TORX135x's, one needs a voltage level translator to 3.3V logic and a 5V supply (SN74LVC1T45 would be my choice), but the overall current is similarly reduced compared to older '141s.
for inverting the TX on the two wire devices it should be possible to just rewire the LED to be between output and ground instead of output and Vcc
or if the mcus supports it, switch to IrDa mode, the turns 0 into ~1/3 bit pulses
I'm not ashamed to admit I had to experiment to verify I got the TX polarity right; I'm just a hobbyist. This was several years ago, and I do believe I still have some 4 or 5 TOTX141+TORX141 pairs somewhere; the idea was to isolate a continuous monitoring of a 100kV voltage supply, but the team went with a commercial solution instead.
The one issue I (obviously!) had, was the polarity on the RX side as well. I used a Teensy 3.0 for both ends – a Freescale, now NXP, MK20DX128 MCU running at 48 MHz –, and it supports either polarity for UART RX and TX, so it was a trivial matter to flip the polarity bit, recompile, and retest. Fun, too.
I did some additional tests using three-TOSLINK for SPI, but to keep the duty cycle below 75% or so, it needs much more software care. I played with fixed-length (64 and 128 bit) "messages" with checksum and one of a set of predefined bit patterns as a XOR mask, but in the end, good ol' UART was just superior, especially since the max baud rate was 3Mbaud, yielding over 250 kbytes/sec transfer rates –– if I recall correctly; it's been a few years –– without any software massaging of the messages. (I only used 8N1, though, because I'd had to "emulate" 8N2 (two stop bits) via 9N1 with an always-high (thus LED OFF) 8th data bit which is sent last due to being MSB, and only needed to transfer ASCII text, not binary data.)
I don't see any hardware reason to keep duty cycle at 75%. The ones I have say they work from DC to 16Mhz.
I don't see any hardware reason to keep duty cycle at 75%. The ones I have say they work from DC to 16Mhz.
Oh, right! Thanks for pointing it out! TOTX1350 and TOTX1353 datasheets say the same; I completely missed that!
It's only the
TOTX141 datasheet that has that restriction – probably because the current it's LED uses is so much higher (15-20mA compared to 1.5-6mA for TOTX1350/3) – in section 3, note 2:
"LED is on when input signal is high, and off when it is low. The duty factor must be maintained between 25 to 75%."
Furthermore, if the link is between different microcontrollers, note that not all baud rates are created equal. On original ATmega328, for example, 115,200 baud will be at least 2% off because of its limited baud rate selection, no matter what you do. If both ends are the same MCU running at the same clock rate, you have no issues, as the exact baud rate doesn't matter that much, just that both ends agree; but mixing actual baud rates is a problem. (There is a margin of error, but I prefer 1% or less; I'm picky.) Better check the actual baud rates you get with your hardware. On ARMs, 2M or even higher should work just fine.
These issues arise only with long datablocks. If you keep the datablocks short and/or add some short pauses between them,
the receivers clock synchronizes again and there will be no issues.
An RS232-style serial link resynchronises at the start of each byte; that's what the start and stop bits are for.
For 8N1 it can tolerate an error of up to half a bit time in 10 bits = 5%, so it works reliably if both the transmitter and the receiver are within 2.5% of nominal.
Karel, FenTiger, that's all in theory; it assumes the UART signal is always sampled at the exact correct edge of the clock.
In practice, some UART hardware is less than perfect. Some (many ARMs) oversample the RX signal, and can tolerate even larger errors. Some do single samples and have jitter (so the sample is not always taken at the center of the clock cycle), and start having occasional errors even when the baud rate is only off by 2% (compared to what its own actual baud rate is).
My preference, baud rate within 1% of nominal, is just something that seems to work best across the hardware I have.
To test, I like to have each end initialize a pair of Xorshift* pseudo-random number generators of suitable size, initialized to different seeds. One is used to generate the transmitted data, and the other is used to compare to the received data. This way even slower microcontrollers can easily saturate an UART bidirectionally, and detect/count any errors. Faster microcontrollers can saturate higher-bandwidth channels than UARTs, so I use the same approach to measure e.g. the bidirectional bandwidth over USB or Ethernet between a microcontroller and a host computer.
Oftopic: I have been thinking for a while to order some optical components in order to play a bit with it:
optical cable 1mtr. Broadcom HFBR-RNS001Z Digikey: 516-2090-ND
transmitter Broadcom HFBR-1521Z Digikey: 516-2043-ND
receiver Broadcom HFBR-2521Z Digikey: 516-2062-ND
According to the datasheet, they go up to 5Mbd.
To whom it matters: One disadvantage i remember about TOSLINK is the low light level used. TOSLINK is very old and was invented at a time when LEDs were much worse than nowadays. And they had to leave it like that to stay compatible. There are more modern (industrial) parts that use 10x or 100x the light level or more and the link will have less noise and jitter. With digital audio people are always curious about jitter.
Something similar happened with pulse oximetry finger probes. With modern LEDs they use various tricks to reduce the light level - which is nonsense in regard to measurement performance.
Regards, Dieter
Furthermore, if the link is between different microcontrollers, note that not all baud rates are created equal. On original ATmega328, for example, 115,200 baud will be at least 2% off because of its limited baud rate selection, no matter what you do.
Isn't this dependent on CPU clock speed, though? I seem to recall that when running an ATmega at 16 MHz, you can only get within something like 4% of 115200, but if you run it at a different clock speed (12 MHz?), you can hit that baud rate exactly.
Yes, since the UART clock is derived from the main clock the accuracy of the baud rate depends on how close you can get the baud rate divider to the required mathematical ratio for a given combination of clock speed and baud rate, so different clock frequencies will have different sets of baud rates they can support accurately. Having a higher main clock rate helps, provided you have enough range in the baud rate divider, since you end up with finer resolution. Fractional baud rate generators give more flexibility, at the expense of introducing some sampling jitter. Baud rate accuracy also depends on the basic accuracy of the main clock, which is why an external crystal is often recommended when UART is required instead of relying on an internal RC oscillator which is usually not very accurate, although modern MCUs are much better in that respect than older ones. I have on my bench a Cortex M0 running at 48MHz from the internal RC via PLL and the UART works perfectly at 250kbaud--though this is just for config/debugging, I haven't looked at the specs to see if it would be reliable across temperature range etc.
Furthermore, if the link is between different microcontrollers, note that not all baud rates are created equal. On original ATmega328, for example, 115,200 baud will be at least 2% off because of its limited baud rate selection, no matter what you do.
Isn't this dependent on CPU clock speed, though? I seem to recall that when running an ATmega at 16 MHz, you can only get within something like 4% of 115200, but if you run it at a different clock speed (12 MHz?), you can hit that baud rate exactly.
I used to clock my 8051s with 11.059 MHz oscillators so the baud rate would match the usually 115200 exactly.
I get confused with all the different optical connectors.
In the old days there was this 1mm plastic fiber without connectors.
You just used to cut (and strip?) the fiber and insert it into the module with a plastic knurled compression nut.
Did anyone ever make a half duplex transceiver (on a single fiber)?
That would be pretty cute for RS485.