[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.

[gkasprow]

USB-C can lock, depends on which connector you use.
With USB-C we can provide both SPI and analog output.
I assume the gain is programmable. DIP-SWITCH or software? The same with BW.
The EEM would be just like the RJ-45 but with USB-C connectors

[gkasprow]

What ADC resolution and sampling rate would do the job?
What diode configuration? As a source of the current followed by TIA or with polarisation?
Do we need some temperature compensation/ measurement?
Some noise specs would help
How many channels for EEM?

[hartytp]

@airwoodix can you summarize the use cases you have for this? Where will it fit into your experiments? Is the prime purpose just to be cheaper than Thorlabs, or is it more driven by other considerations (noise/bandwidth/space/etc).

Does it need to be synchronous hence likely hooked up to Kasli or just asynchronous/infrequent polling (e.g. pushing laser powers into influx db every now and again to monitor beam alignment) say via Humpback. If synchronous, what timing resolution?

Open loop or closed loop? What bandwidth?

Does it need an enclosure? Mounting/space constraints (lens tube mounting for filters?)?

Dynamic range? Programmable gain (if so, digital or DIP). Remember that if cost is your main consideration then you're going to have to squeeze every BOM line so it's important not to over specify.

In terms of interface, does it make sense for these to be digital or analogue? Are you relying on a digital interface fore noise immunity/breaking ground loops (beyond what you'd achieve with a differential ADC interface and decent cabling)? If you go for a digital interface, I you may want something like the I2C/SPI hub that @jordens proposed a while back. If you go for an analog interface then we could build a new DAQ EEM with lots of channels and a much simpler interface (e.g. just a passive filter + diodes and an ADI multi-channel DAQ chip gives a very cheap solution if it meets your other requirements). If you did develop these boards, would they be useful in other places in your labs?

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

That seems hard to me. If that's a strict requirement then it's the thing that should be the prime focus. For context, last time we bought the passive IDC<->BNC adapter from Creotech in quantity of 5, it cost more than three times that. Maybe I'm overly pessimistic, but I think it will be hard to produce these that cheaply unless the production volume is large.

As a general point, I personally don't think that that projects whose prime focus is being cheaper than Thorlabs is the best aim for Sinara. IMO our best successes have come when we've focused on providing unique features that people want rather than just competing on price... Once you factor in NRE, I'd guess the development costs will exceed your lifetimes supply of Thorlabs PDs, so the incentives for anyone to push this forward are small. Beyond that, if you really want to hit 50EUR per PD then the supplier won't make much profit from it, so it may be hard to get people to bother keeping stock etc so it becomes more of a hobby product than a professional one (A significant advantage of Thorlabs goods is that you can always buy more next day, they come with a warranty and a data sheet, etc)

[dtcallcock]

Note that the Thorlabs S120C requires a ~$500 interface box too, so $800/ch is a fairer cost.

This USB-C EEM sounds like it could have enough other uses to spread the NRE out. For the device side, what's the rough cost and footprint for interface gubbins (STM32 etc.) @gkasprow?

[jordens]

For monitoring (and even transient recording and ms-synchronized sampling), I'd rather go full IoT and scatter dozens of little wifi/ble devices with the most convenient powering solution (battery, shared battery, shared 5V USB mini/micro/c). The RF doesn't matter (there are already dozens of bluetooth/wireless/gsm/lte devices in labs). The cabling is simpler and doesn't need to be that centralized. The middlebox doesn't need to be developed. The electrical data layer is eliminated.

[jordens]

That would definitely be a significant technological step beyond what Thorlabs offers. And it really doesn't seem to be any more expensive or complicated.
With 50€ per channel, it sounds like you could easily cover that functionality plus much more (local temperature, remote SPI, remote anything).

[dtcallcock]

That would definitely be a significant technological step beyond what Thorlabs offers.

Isn't what you are describing basically the Thorlabs PM160 bluetooth power meter?

It seems to be a cost issue again (well that and not having to deal with crappy Thorlabs firmware). At $1.2 ea, nobody is scattering these around. By removing the buttons/screen and taking advantage of newer comedy cheap BLE chips, one might hope to get something that's a couple hundred dollars though?

[gkasprow]

If you connect the photodiode with cheap JFET opamp to ESP8266 chip, the BOM won't exceed 10$.

[dtcallcock]

See also https://www.gentec-eo.com/products/blu#

[jordens]

The existing bluetooth power meters aren't something you'd want to use in this case.

• Frequently not BLE thus draining battery rather quickly.
• They work with the app on your phone or with dedicated display devices. That typically doesn't scale to more than one meter. And it doesn't help with monitoring your experiment over longer times.
• They don't work well in continuous operation modes.
• Are about 120 times as expensive as the easy and obvious solution.
• They don't integrate into IoT style telemetry applications at all. Don't discover themselves or their broker. Don't speak any useful protocol.
• If you get 20 of them, how do you provision them all quickly to work in your network and with your setup?

[jordens]

Or some simple nrf52-based device, the JFET opamp or the logarithmic TIA. Same BOM cost around 10$, more battery-friendly.

[gkasprow]

if sb wants BLE and Wifi, ESP32 is an option. It would cost similar.

[jordens]

My dream device for about a decade now is such a photodetector with 6lowpan or ble and energy-harvesting (either light, thermal, or that laser beam you measure) for power.

[gkasprow]

well, some time ago I developed BLE device that powered itself from RFID and was emulating the RFID tag after discovering mobile phones in its range. It required 90uW of power to wakeup. The solar cell in the quantum lab seems to be not optimal solution.

[jordens]

There are lots of high power rf and microwave sources around that can be tapped...

[gkasprow]

Yes, but it also means that you need a large wideband antenna or tune one to a certain band.
There were successful attempts of using WIFi signals to supply electronics, but it is true in the case of IoT devices that can sleep 99,99% of the time.
In the case of the photodiode detector, we want to measure the optical signal on request. Can we wait a few seconds for BLE to connect?
I had a similar issue with RF powering of wireless implants in the animal brain. I designed tiny subcutaneous implants (~100 components on 1x1cm PCB) that were capturing brain signals and also turning LED on (it was an optogenetic experiment). The biologists wanted to have fast LED control that was dependent on animal action in the cage. They accepted a few ms of delay. I solved it in the following way:
I found an AM receiver chip that consumes 1uA in Rx state and is able to wakeup external CPU on request when a certain sequence gets received. It is working on 135kHz and one transmitting coil is enough for the entire lab. When I want to turn the LED on or off I switch on the AM transmitter. It wakes up the CPU which turns on its ISM radio (2.4GHz). In this way, I got both low latency and very low power. I'm writing this in case somebody was looking for a similar solution in the future.

[gkasprow]

the other issue with RF access is that you cannot guarantee that it always delivers data within the specified time.

[dtcallcock]

What about adding a solar cell, battery, and USB-C? That gives you 3 ways of powering and at least 4 ways of getting the data out (wireless, USB, and the analog & digital via the extra USB-C wires). Is there a reasonable SoC that can handle all that?

[gkasprow]

there are ones from Nordic, Microchip, TI, etc. Depends on accuracy you need.

[jordens]

The harvesting is probably a bigger project even though it would be a major step forward. The potential sources are just to heterogeneous. I'd go with USB-C (or maybe there is something simpler) plus a hub (16 ports, middle of the optical table, either battery or wall wart) for power distribution. It doesn't need to be locking IMO. You'd expect your monitoring system to alert you if a device is down.
BLE would be pretty flexible in terms of variable data rate, beacon-style operation vs client-server, and on-request sampling. This does in practice allow sleeping for 99.9% of the time or even longer (just look at these old beacons, there should still be some around at NIST unless someone threw them away). It's also a bit of a hassle to get going smoothly and robustly. At least it was 5 years ago. Nowadays there is a lot of long-term oriented development activity nowadays with the nrf52 platform for example. And one could even try the more recent technologies like UWB. I'm undecided whether wifi or ble/uwb is better here and I would decide and focus on one (wired + wif or ble or uwb) and not do multiple.

[gkasprow]

If we go for USB as a supply, why we would need any other interface? Isn't the USB good enough?

[jordens]

For power interface it's certainly sufficient. Just that the the connector may be larger than the device, the cable has way to many pins and is pretty rigid. But I see that there may be no obvious widely available alternative cheap connector solution.

[dtcallcock]

why we would need any other interface? Isn't the USB good enough?

I really hate USB for anything that has to work reliably in an experiment. It always falls over at some point under windows and the drivers are usually a trash fire. Also, the EMI and ground loops are terrible unless you scatter fancy hubs and isolators everywhere.

Could you stick ethernet/SPI/RS458 down the 4 extra pairs USB-C gives you as a second interface? Then people still have the USB if they want something fast & dirty and don't want to buy the breakout card/hub that would be needed.

[sbourdeauducq]

It always falls over at some point under windows and the drivers are usually a trash fire.

It would be easier if physics labs would stop using Windows...

Also, the EMI and ground loops are terrible unless you scatter fancy hubs and isolators everywhere.
Could you stick ethernet/SPI/RS458 down the 4 extra pairs USB-C gives you as a second interface?

SPI and RS485 still have a ground loop problem. I don't think ground loops are a big issue for bus-powered photodiodes, but they might become one with other equipment. What exactly do you mean by EMI? With good cables I don't see why USB would be particularly bad, but maybe there are things I don't know about.

What about PoE? Might be a bit expensive but it has power + data on a single cable, galvanic isolation, and no driver problems.

[gkasprow]

If we can live with PoE without galvanic isolation, then it would be easy and small.

[dtcallcock]

It always falls over at some point under windows and the drivers are usually a trash fire.
It would be easier if physics labs would stop using Windows...

Is USB super bullet-proof with no driver issues under Linux? I always got the impression it's not much better but willing to stand corrected.

What exactly do you mean by EMI? With good cables I don't see why USB would be particularly bad, but maybe there are things I don't know about.

It's true that good cables help a lot. One issue is that you can't really turn the thing off. With SPI, the thing only runs when you need it. The other is that there isn't a simple chip that does USB isolation beyond 12Mbps, so if you need USB2.0 High Speed (a lot of FDTI stuff insists) you have to use exotic and expensive FPGA-based isolators.

RS485 still have a ground loop problem.

Isolated transceivers are super-standard. Ground loops are also much more tractable if it's a few photodiodes connected to some power/ethernet hub instead of a PC and whatever else is plugged into it.

The more I think about it, isn't this exactly the kind of thing RS485 was designed for? There are a ton of cheap conversion/servers for Ethernet/USB/RS232 etc. with/without isolation.

If we can live with PoE without galvanic isolation, then it would be easy and small.

Or this. What are the downsides of PoE without galvanic isolation? Also, if you stick Ethernet/PoE down the Tx1/2 and Rx1/2 pairs of a USB-C, how do you deal with the connector getting flipped and switching 1-2?

[sbourdeauducq]

Is USB super bullet-proof with no driver issues under Linux?

If you use some exotic peripheral or host chipset there may be crappy drivers as well, but the mainline drivers are pretty stable IME. Many issues are caused by low quality cables or plugs.

One issue is that you can't really turn the thing off.

Yes, the way USB works requires the host to constantly poll the device.
Ethernet also has constant activity on the wires.

The other is that there isn't a simple chip that does USB isolation beyond 12Mbps, so if you need USB2.0 High Speed (a lot of FDTI stuff insists) you have to use exotic and expensive FPGA-based isolators.

Does inserting an old 12Mbps USB hub force the FTDI chip to behave? And if you were using Linux: http://lists.en.qi-hardware.com/pipermail/discussion/2011-August/008508.html (doesn't work with recent XHCI USB3 ports)

[gkasprow]

IN RS485 (Modbus) world, 4-pin M8 connector is kind-of standard. It is used in various sensors. RS485 can work up to several Mbit/s. Even 100Mbit/s. With single M8 we have both power and data. Data can be sent on request or streamed continuously, depending on the protocol. Ready to use cables can be purchased easily. There are both low cost plastic M8 connectors, as well as bullet-proof IP68 ones. They are usually mechanically compatible. We can implement both RS485 and USB using low-cost Cortex M0 MCU. For example STM32F072. It has 12-bit ADC so it could be sufficient for some applications. It has also two 12-bit DACs which can be used for bias/gain control. This MCU has also CAN, which is similar to RS485 but has several interesting features like built-in addressing, and discovery. I use MCU's unique ID as the CAN address and then scan the bus and discover all connected devices. One advantage is that RS485/CAN doesn't need any hubs. One can connect tens of sensors with a single cable. In the case of M8 connectors, one can use two of them and connect the sensors in daisy-chain mode. It's also easier to provide correct automatic termination in such a case.

[jordens]

For the IoT approach with zero wires, connectors, hubs, or power distribution, we'd be looking at chips like this one.

[gkasprow]

Interesting chip.
I'm not sure if relying on harvested power is a good approach in a typical lab, placed often underground where GSM access is limited. It would give more frustration than real benefits.
I'd go with cabling.

[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.

[gkasprow]

The only difference between standard PoE and passive PoE is the lack of a power negotiation mechanism. Voltage is a secondary thing, standard PoE modules can sometimes work with voltages down to 12V, but it is usually 48V.

[pm-daniel]

Ok. Thanks for that clarification.
By proper PoE converter on that adapter PCB you mean Active PoE compatible with 802.3af/at or just DC/DC converter with max Vin >=48V?
And as I understand, power would run from the adapter PCB to DiPho via VCC/GND pins on USB-C connectors, because PoE conversion will happen on the adapter PCB. But then eth transformer should also be located on that adapter PCB, am I right?
So in the end adapter PCB, will have similar functionality (+external power input) to this PoE splitter, but RJ45 and USB cables will be merged into one cable?

[gkasprow]

Yes, I mean using for exampel Silvertel converter + RJ45 connector. Look how it is done in Thermostat design.

[pm-daniel]

@gkasprow I've just pushed the first revision/draft schematics of afe and mcu boards.

[gkasprow]

@pm-daniel please use the master branch. My files were just templates.
Did you do some simulations of the AFE?
Why this particular opamp was used?

[gkasprow]

It's a bad idea to use both SSTX pairs for Ethernet signals - you will get stubs. That's why we use Auto MIDIX to enable automatic pair detection. Just use SSTX 1 and SSTX2.

[gkasprow]

try to use a standard SWD connector, of course, if that fits

[gkasprow]

please use ports only for multi-page projects. for local signals use nets. See how other Sinara projects are organized

[pm-daniel]

@gkasprow

pm-daniel please use the master branch. My files were just templates.
Did you do some simulations of the AFE?
Why this particular opamp was used?

• Of course - I pushed to the default git branch (which now happens to be "main" instead of master), I will rearrange it and push the next commits to "master"
• Not yet, If I manage I will do some simulations this weekend. I understand that I should use the current source as a stimulus?
• I choose OPA141 because it has significantly smaller input noise and input bias current, is available in a smaller package than TL071 f.e. and its price is not horrible IMO.

[pm-daniel]

try to use a standard SWD connector, of course, if that fits

I'll try to fit it

[pm-daniel]

@gkasprow it looks like the default branch for this repo is main - could we do something about it? Or maybe I should move all files to the main branch

[gkasprow]

Just make sure the file you push is listed on Github.

I understand that I should use the current source as a stimulus?

yes, but please add photodiode mode.

I choose OPA141 because it has significantly smaller input noise and input bias current, is available in a smaller package than TL071 f.e. and its price is not horrible IMO.

right. But in our case, you have to prove you need low voltage input noise. We are working with high-value feedback resistor so the current noise may be dominating. Low input bias current is not that critical since you can easily compensate for it. But be careful because you can add some noise! Here is an online tool to play with TIA. Essentially, you have to show that you know what you are doing :)

[pm-daniel]

@gkasprow sure.
It's a busy time right now but I'll try to do some simulations (and documents) in the following week or two

[pm-daniel]

@gkasprow After doing a few simulations it became obvious that OPA141 may not be the best pick (TL071 either). Because of the pretty bad output voltage swing characteristic - I totally forget about it (for TL071 it's +-1.5V from the supply voltage and +-0.3V from the supply voltage for OPA14). I've tried a few different opamps (AD8541, AD8539, ADA4891) and ADA4891 looks most promising and it has a very low input bias current, very good swing characteristic, and a similar price to OPA141. All those conclusions are based on transient simulations that I conducted in LTspice.
I used the current source with parallel capacitance as stimulus and now I'm struggling with noise simulation as it looks like LTspice expects voltage source to be selected as a noise source. Is there a better way of simulating photodiode input in the LTspice? I've spent some time on research and it looks like everyone uses just the current source with capacitance (just like I did).
Once I complete the noise and bandwidth simulation I will publish results on GitHub. Maybe you have any other recommendations regarding opamp choice?

Sorry for such a delay but I'm really busy finishing the current semester.

[dnadlinger]

A command like .noise V(OUT) I1 dec 1000 10 10Meg (where OUT is the output node, and I1 is the current source) should work fine in LTspice.

[pm-daniel]

@dnadlinger thank you! After seeing your reply I've checked my simulation command again and it turns out that I had IN and OUT nodes defined in the wrong order. It works just fine now.

[gkasprow]

@pm-daniel can you open a new issue and post your noise simulations?

[pm-daniel]

@gkasprow done #3

[airwoodix]

@pm-daniel Do you have an update on this project? How did the testing of the first boards go? Thanks!

[pm-daniel]

@airwoodix Tests are not finished yet - they will be ready by the end of the month (hopefully next week). I'll publish the results on GitHub. Sorry for the delays but in the meantime, I'm writing my BEng thesis. Working a full-time job at Creotech (on non-related projects) also doesn't help. I hope you understand!

[airwoodix]

Of course! 🙂 Thanks a lot for the update. I'm looking forward to the testing results.

[gkasprow]

@pm-daniel can you post some photos of the PCBs?

[pm-daniel]

It's mounted in measurement fixture for now so those are the best photos I can take at the moment

I'll upload better ones if needed after finishing the measurements