[RFC] Digital monitoring photodiodes

[airwoodix]

Continuing the discussion in sinara-hw/meta#52 (comment) on cheap monitoring photodiodes for Sinara.

• Something like Thorlabs S120C
• form factor: max 1"-ish diameter, 20 mm deep (see Thorlabs link above)
• photodetector: Si photodiode, area > 2x2 mm², e.g. BPW34
• bandwidth: tens of Hz to few kHz, more not relevant
• photocurrent: 10 µA to 10 mA
• gain: if possible linear, selectable in decades, if not, log amplifier
• interface: digital, SPI-like, ideally single cable for power and data to logging board in Sinara crate. RJ45 is too bulky, USB-C sounds cool but doesn't lock
• cable length: around 2 meters would be convenient

Does this cover enough use cases?

I only see opportunities if this can be around 10 times cheaper than the Thorlabs product, so max 50 €/$ per channel.

[sbourdeauducq]

TM4C on Thermostat isn't very expensive and it worked. In terms of exoticity, ESP32 and its Xtensa CPU instruction set is certainly worse than STM32 which is ARM-based.

If somebody doesn't like Micropython, Arduino works as well.

Hmm, these stacks on ESP32 didn't look too good under the hood last time I checked. They are more for hobby/maker projects.

Anyway I'm sure that many students can also get ESP32 wifi to work with a proper software stack, it's just more expensive and time-consuming. (Wifi stacks aren't that complicated, I wrote one in 2005 that got deployed on >300k consumer devices. BLE may be harder.)

I don't know which platform is best here, but "ESP32 because it has Micropython and Arduino and it costs $2" isn't a very good answer.

[gkasprow]

If the clients want to pay 20$ more for a "proper" CPU, let's go for STM32 and an external WiFi module. This student who will build it, won't have time to learn RUST. So let's choose something that will make the project feasible.

[jordens]

I would really keep this entire thing simple first. Get a MVP going with basic TIA and a ESP with wifi and a student. Only then (1) replace the TIA with a log TIA or the switched integrator TIA or the multiple ranges, (2) replace the ESP with a higher quality ARM with integrated wifi or BLE or lora and write proper firmware, (3) if desired make it generic with a good analog output, (4) look at low power operation and/or harvesting.

[gkasprow]

@jordens makes sense. It will consist of two small PCBs so it will be easy to swap the CPU

[airwoodix]

Does it really need to have wireless communications (in the first iteration)? In my lab, the only decent wifi network is eduroam, for which clients are annoying to configure and where I'd need to use my own credentials (I highly doubt that I'd get new ones for such applications). Bluetooth is IMHO in the same situation of lacking infrastructure (how would I concretely connect tens of such photodiodes to the experiment's monitoring system?). On the contrary, ethernet networking is much more widely deployed in labs. Agreed however that RJ45 sockets are unfortunately bulky.

Is there overlap between this project and Photodiode_Amplifier? Would the latter be an option for applications where analog output is wanted, such that this project can focus on being simple and as compact as possible? (it would still be great if everything could fit inside a 25 mm long 1" lens tube, with a side-looking RJ45 socket for power and communication)

Without wireless communications, sticking to a single CPU family with good embedded-rust support within Sinara (STM32) would make a lot of sense to me. Be it if ethernet needs to be controlled over SPI by e.g. ENC424J600 or similar. I nevertheless see the advantages of ESP32 for fast development.

[gkasprow]

Yes, the idea is to have a compatible front-end module with Photodiode_Amplifier which will have much higher BW.

[dnadlinger]

Yes, the idea is to have a compatible front-end module with Photodiode_Amplifier which will have much higher BW.

I'm not sure what the design goals of Photodiode_Amplifier are, but a high-bandwidth, high-gain, low-noise frontend will look radically different than a design targeting 10s of kHz of bandwidth with low power consumption for potential battery/power harvesting use. Fitting a MHz at MΩ-class frontend with a single power supply into a short section of SM1 tube (a neat idea!) will likely require at least a two-board sandwich with shielding in between to keep DC/DC switching transients away from the frontend nodes. It is probably also going to burn at least ~100 mW, while you can do a slow frontend at a fraction of the power draw, and without needing access to a medium-voltage rail for photodiode bias.

In other words, some though on performance specs for the other project is probably a good idea before investing much energy into laying the ostensible groundwork for combine them.

On an entirely unrelated note, two component suggestions for whoever is going to work on this to be aware of:

• Osram now makes some large-ish SMD-mountable photodiodes, e.g. SFH 2201. Pretty much the largest sensor sizes apart from Hamamatsu and other annoying-to-obtain vendors. I've been wanting to try these out for a while now.
• TI have recently added some very nice analogue switches to their portfolio, e.g. TMUX1511 – definitely worth a look for range switching/…, although the low supply voltages might require some gymnastics.

[gkasprow]

We will focus on a low-BW solution, and later on, try to combine it with a high-speed amplifier. At least we will keep the enclosure :)

[sbourdeauducq]

Does it really need to have wireless communications (in the first iteration)? In my lab, the only decent wifi network is eduroam, for which clients are annoying to configure and where I'd need to use my own credentials (I highly doubt that I'd get new ones for such applications). Bluetooth is IMHO in the same situation of lacking infrastructure

A more serious problem is the 2.4GHz band being overcrowded and unreliable in most large cities.

[gkasprow]

true, at the WUT we don't use 2.4GHz WiFi at all. You can get 10Mbit/s at most :)

[jordens]

There is single pair ethernet which looks promising (good mechanics, PHY, PoDL) and is very much en vogue now (which should never count). If I were to build a modern wired sensor network I'd probably go SPE. The other fieldbuses (CAN, 422/485, xFIP) seem a bit inflexible, low level and island solutions.

[gkasprow]

I saw it. I like the idea. TI has PHY chips. But in a real-life scenario, it would be hard because you need a dedicated switch. Standard Ethernet is just two pairs, one can use a smaller RJ45 connector or even M8

[jordens]

You can just slap two phys together to get a complete media converter: https://github.com/ehntoo/100base-t1-converter/ Yes. The switch is a bit annoying but for any other fieldbus solution there would also need to be a special switch node. The industrial ethernet connector with plain old ethernet would also be ok as an initial MVP.

[gkasprow]

Good to know. I found a few COTS media converters (300$/pc) and only one switch that looks expensive :) It would be easier to attach some cable adapter with an RJ45 socket and USB socket for passive PoE.

[gkasprow]

@jordens do you have the mechanical files for your SM1 design?

[jordens]

logpd.gerber.zip logpd.view.pdf logpd.sch.pdf

[pm-daniel]

Hi, I'm a student who will be doing that project. I'd prefer sticking to the STM32 platform as an MCU cause I've far more experience working on them rather than ESP32 or other platforms. If there is a necessity for that sensor to have wireless communication of some flavor then I would opt for STM32 + wifi/bt module. As far as wired communication goes, I understand that there should be an M8 connector (ethernet, MQTT protocol) and USB-C for console (configuration/setup?; straight forward TX/RX pair or USB VCP?). What about RS-485? Are we ditching that idea? In terms of mechanical design, I understand that project should fit on two circular PCB's (~24mm dia) - am I right ? Are there any other things that I should take into consideration?

[gkasprow]

Once we have the Ethernet, RS485 makes not much sense. Yes, we can use USB VCP. The design should be cheap, so before we freeze some decision, the budget must be made. The design should fit in the enclosure. Since we want analog output, it would be probably easier to use two rectangular boards.

[gkasprow]

We could use a low-cost CPU like STM32F072CBU6 which has a USB and the package is tiny.

[dhslichter]

not sure why analog output means that rectangular boards are better? The point of circular boards is to make it possible to fit them inside a 1" lens tube for the photodiode application -- this makes the mounting mechanics simple and easy.

[gkasprow]

You have to somehow expose the coax connector. It can of course protrude through the rear digital board, but it occupies some space. If we place the board along the sensor axis we have access to rear connectors but have issues with sensor fixing (must use THT) and smaller board area. Anyway, after the selection of enclosure and connectors and initial placement, we need to make some mockups to see what fits and what doesn't.

[gkasprow]

I did a quick mockup. It looks like we can easily fit the entire functionality on a single PCB. M8 connectors are far too big. But we can use a USB-C connector. It has normally unused high-speed lanes that can be adapted for Ethernet. In such a way if we connect it to a standard USB hub, the circuit will enumerate as a serial port of whatever we implement and will be supplied over USB If we plug it into a dummy 5V power injector, using either USBC-RJ45 cable or a dedicated passive adapter, it will work as an MQTT client. We can even skip the LAN transformer because we don't need isolation. It will always be one on the switch side. Here are some mockups version with LAN trafo

Thormalbs S120C-like enclosure

ADC, Logamp, diode, STM32, ENC424J600 PHY

If we want to add analog output, there are problems with such high SMA connectors - I found only one (AMP 132291) that fits somehow. If we skip the LAN trafo, we can fit the SMA connector. There are also super-small LAN trafos avaialble

and the possible final effect

[gkasprow]

Of course, we can make a dedicated sensor board, but the supply and SMA would have to go from the rear board. SMA can also protrude through the digital board, but the analog board would need another connector with a cable for the power supply. It's easier to leave the SMA and USB on the digital board and if someone wants a cheap solution, simply don't mount the CPU, LAN PHY, and ADC and treat the digital board as power delivery. To connect the two boards one can use 1.27mm gold pin connectors or i.e. Molex SlimStack™ B2B connectors.

[gkasprow]

@pm-daniel the PHY circuit is here https://github.com/sinara-hw/Booster/tree/master/PCB/Booster_User_Interface_ENC424J600 the CPU is here https://github.com/elhep/SiPM_AFE I published the mockup files on the repo. This will give you a kick-start.

[gkasprow]

The wireless connectivity can be easily provided using RPI0 and USB cable.

[gkasprow]

two-board version

[gkasprow]

[gkasprow]

Do we need more than 12Bit ADC? If not, then one from STM32 can be used. We also have two 12b-bit DACs that can be used for offset correction.

[pm-daniel]

the two-board design seems more versatile and should be easier to design. If we decide to go with two boards then we should be able to fit M8 connector which footprint is actually smaller than the footprint of SMA connector (12.5x10mm vs 13x13mm). In my mind another benefit of the two-board design is better separation between analog and digital sections, am I right?

[jordens]

12 Bit is plenty.

[gkasprow]

M8 is much bigger than SMA. here is the comparison

[gkasprow]

USB is free, for M8 you have to pay.

[gkasprow]

We have 50$ budget including mechanics and assembly. M8 is 15$ or so.

[gkasprow]

And we can make a simple USBC to RJ45 adapter placed in a more convenient place if somebody doesn't want to make a cable. Such an adapter would fan out the USBC to USBC for supply/USB and RJ45 for Ethernet. That would be super-cheap.

[gkasprow]

we can try to use TL061 opamp - they are super-cheap. The offset can be canceled using MCU DAC. We don't need external ADC so we can make it very simple from an HW point of view. Gain can be switched using a low-cost 4051mux. All gain corrections would be made in SW. You can also find a lower-cost B2B connector.

[gkasprow]

USB-C cable can be built in a few minutes using a piece of RJ45 patchcord and the plug

[gkasprow]

the KSZ8851 MAC+PHY over SPI has Auto-MDIX so we don't care about Ethernet Rx/Tx pair swapping

[gkasprow]

Since we have a dedicated AFE board, let's place both TIA and log amp and use the assembly option to connect one or another to the photodiode. We have enough ADC inputs to connect both outputs.

[gkasprow]

KSZ8851 is also much smaller than the ENC chip, so we have more place on the digital board. This particular MCU has also a CAN controller but I'm not sure if it's worth it to place a 0.5$ transceiver and use the remaining USB-C pins for such connectivity.

[pm-daniel]

fair point about M8 being larger than SMA - I forgot about that bulky mechanical part of the connector and made that statement based on the inner part drawing only:

[gkasprow]

Here is an article on making the programmable gain TIA.

[gkasprow]

And some hints on TIA optimization: https://www.analog.com/en/technical-articles/optimizing-precision-photodiode-sensor-circuit-design.html

[pm-daniel]

thanks, looks like I have some "homework" to do

[pm-daniel]

I've created the first version of a simple block diagram for DiPho DiPho_block_diagram.pdf

[gkasprow]

@pm-daniel

• STM32G4 is nearly 2x more expensive and overkill for this application. For differential ADC, you need a differential driver. It may be not worth the circuit complication. The TIA will be spaced by 1..2cm from ADC, I don't see a clear advantage of differential signalling here.
• I'd avoid any DC/DC converters here, especially PoE flyback converters as they are bulky and it's difficult to filter EMI they create.
• PoE can be entirely passive. Active one can be without isolation but would create ground loop issues. Isolated one is bulky.
• I would use transformer-less Ethernet and make a power supply injector as a tiny PCB with USB-C (DiPho), USB-C(power brick) and RJ45. One can make one with USB-C, RJ45 and proper isolated PoE and use when needed. In this way we have 3 usage scenarios - first with cheap USB-C to RJ45 cable. Supply can be delivered using cheap POE injector or directly from the power suply. More elegant solution is an adapter where you plug the USB charger and RJ45 cable. Third one is 802.11af compliant power solution. The advantage is that the basic configuration is simple and cheap but requires custom cable which can be easily made by soldering USB-C and RJ45 cables.

[gkasprow]

@pm-daniel when can I expect the first version of schematics?

[pm-daniel]

@gkasprow

• ok, then I will use STM32F072C8U and skip adc diff driver step.
• I like the approach with custom cable with tiny PCB - it basically means that we can provide power to DiPho via USB power lines, so what's the point in using PoE? Maybe I misunderstood something?
• I will try to finish a schematic draft by the end of march

[gkasprow]

I like the approach with custom cable with tiny PCB - it basically means that we can provide power to DiPho via USB power lines, so what's the point in using PoE? Maybe I misunderstood something?

PoE is popular in some labs. Think about scalability. Many USB chargers are not elegant and scalable as the Ethernet switch

[pm-daniel]

But are there any standardized voltage/current values for passive PoE? I found some info about 24V/48V but it seems pretty high with no DC/DC converter onboard...

[gkasprow]

Passive PoE is always custom. There is no standard behind it. People are using usually 12V but there are also 5V versions. You simply use free RJ45 lines or transformer taps to transfer DC. Some are using the bridge rectifiers to make it slightly more robust. In our case we have a way to supply 5V via USB, so let's add a proper PoE converter to the adapter PCB. If someone needs PoE, will simply install such a converter. We are using Silvertel converters, but there are also lower-cost ones used in Arduino clones.