search

sinara-hw / DiPho

Digital photodiode with wired and wireless interfaces
5 stars 0 forks source link

[RFC] Digital monitoring photodiodes #1

Open airwoodix opened 4 years ago

airwoodix commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

dtcallcock commented 4 years ago

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

jordens commented 4 years ago

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

jordens commented 4 years ago

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

gkasprow commented 4 years ago

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

jordens commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

gkasprow commented 4 years ago

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 commented 4 years ago

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

dtcallcock commented 4 years ago

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 commented 4 years ago

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

jordens commented 4 years ago

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 commented 4 years ago

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

jordens commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

dtcallcock commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

gkasprow commented 4 years ago

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.

jordens commented 4 years ago

There are antennae blasting into steel vacuum enclosures, microwave wires on trap chips, RF drives for traps, RF/microwave knifes for cooling neutrals, AOM and EOMs around. I'd suspect more average field strength than from ISM/GSM. That rectifier won't be very picky about the frequency. It should be measured. And a temperature gradient is another source typically available. Photovoltaics and piezoelectrics do appear to be problematic.

gkasprow commented 4 years ago

Yes, but it is a lot of RnD and verification in the various lab conditions. And limits the use of more advanced signal conditioning due to power constraints. How often do you need to measure the light intensity? If it's once per a few minutes than harvesting may work, if it is once a few seconds, we won't fit the power budget.

gkasprow commented 3 years ago

I have a student who wants to do this project. He needs the specification to start with.

airwoodix commented 3 years ago

@hartytp Thanks for the detailed review!

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

The main purpose would be roughly what @jordens described: cheap and easy to interface such that we can install as many as reasonable. The obvious commercial alternative (I didn't do a full market search) is Thorlabs S120 + meter which, as @dtcallcock mentions, costs > 700 €/channel. There're surely more price effective products but I still expect every AMO lab to have a more or less advanced homebrewed project to address this issue and this may be the opportunity to provide an easily sourceable and hopefully affordable solution.

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?

IMO synchronous applications would be better off with a nice TIA design (e.g. Photodiode_amplifier?) and Sampler. The main application here would be periodically logging laser powers (period tens of seconds) but also, if possible, being able to switch to few 10 kHz streaming for general purpose debugging (do I have AM on my light?, what's the rise time of my shutter?, etc.).

Open loop or closed loop? What bandwidth?

Open loop. Bandwidth DC - 50 kHz.

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

Ideally fitted with a SM1 thread such that it can be mounted on lens tubes, lens mounts (e.g. LM1(/M)) etc. Best case would be the same dimensions as the S120 series powermeter head mentioned above. Case dimensions up to around 40x40x40 mm would work though.

Dynamic range? Programmable gain (if so, digital or DIP).

Selectable gain, fully digital. Dynamic range: I'd expect few 100 nA to 1 mA photocurrent to cover most use cases (that's roughly 1 µW to few mW of laser power depending on detector and wavelength).

In terms of interface, does it make sense for these to be digital or analogue?

I'd say digital, reserving the analogue signals for the synchronous applications through Sampler. With the deployment of Stabilizer, labs will increasingly have MQTT brokers so I could very well imagine going the MQTT route as well, similarly to what's discussed around Stabilizer.

This would essentially mean a photodiode (e.g. BPW34) in photovoltaic mode, a gain-selectable TIA (or log amplifier), an ADC (target resolution would be 10 nA photocurrent) and a microcontroller with a MQTT client (publisher). Nice extras would be a < 1°C inaccuracy thermometer and relative hygrometer (e.g. BME280, which also has a barometer but this gets tricky with enclosures).

Our labs have very poor wifi coverage which, on top, would be on the wrong network so require VPN & co (deploying an own wifi network is no option). BLE is probably cool but sounds like a hassle, I'd be way happier with short RJ45 cables with fake PoE without galvanic isolation as mentioned by @gkasprow (e.g. 5V DC like what's used on the OrangePis, with a passive splitter).

I agree that full wireless (BLE + energy harvesting) would be great, but it also seems like the resulting solution could be less versatile (what happens if you want to deploy on harsher / more controlled environments e.g. a free fall simulator or a sounding rocket?).

gkasprow commented 3 years ago

what about using switched integrator instead of TIA? By selecting the integration gate, one selects the range. Of course, that solution won't output an analog signal.

We can use the ESP32 module - it's very low cost and has Eth, BLE and WiFi, Arduino support, and a lot of examples including web services and over air upgrade. If we hide all the functionality as an Arduino library, the end-users can easily modify the firmware to enable/disable services and do much more than that. As a default configuration, it would act as a MQTT client over Ethernet. We can also use Micropython which would be even more user-friendly.

gkasprow commented 3 years ago

From a mechanical point of view, one can make it compatible with a single-board camera (27x27mm), so it would fit existing camera enclosures with a C thread. One can buy such ones in many places, and after fitting C to SM1 adapter, use it in a lab. We would need also a USB to upgrade the ESP32, and possibly also supply it. One could also interface it over a virtual COM port for free. All these features above, except for TIA and photodiode are already well supported

gkasprow commented 3 years ago

I mean such enclosure from Ali obraz

gkasprow commented 3 years ago

Another 2$ aluminium enclosure obraz

gkasprow commented 3 years ago

Just type CCTV camera enclosure or board camera enclosure This is cool

jordens commented 3 years ago

I'd try to use a SM1 as the enclosure directly: Fit it into 13 mm or 25 mm tube, fix it with a retaining ring against a "panel" for the power supply connector (or the battery, like in that old thorlabs design). If a round SM1 disc isn't enough space, put it axially into the tube with the same mechanics.

gkasprow commented 3 years ago

We can even make it more versatile. Two 2-layer boards:

  1. PCB with a sensor, TIA, 5V connector, and analog output. It can be used stand-alone, gain is selectable with dip switches.
  2. PCB with ADC, CPU, PoE, USB. It can be used together with sensor PCB and supports all digital interfaces.
gkasprow commented 3 years ago

I'd try to use a SM1 as the enclosure directly: Fit it into 13 mm or 25 mm tube, fix it with a retaining ring against a "panel" for the power supply connector (or the battery, like in that old thorlabs design). If a round SM1 disc isn't enough space, put it axially into the tube with the same mechanics.

true, then we are independent of Chinese enclosures

dtcallcock commented 3 years ago
  1. PCB with a sensor, TIA, 5V connector, and analog output. It can be used stand-alone, gain is selectable with dip switches.

There could be two versions of this board. One with a switched-gain linear TIA and one with a log amp on. @jordens log amp PD based on AD5304 worked pretty nicely.

sbourdeauducq commented 3 years ago

We can use the ESP32 module

Toolchain support seems quite poor. https://mabez.dev/blog/posts/esp32-rust/

dtcallcock commented 3 years ago

Toolchain support seems quite poor. https://mabez.dev/blog/posts/esp32-rust/

That blog post is >1yr old. Looks like there has been some activity since at https://github.com/esp-rs.

Do you have a sense of how much progress they've made compared to what you'd need?

sbourdeauducq commented 3 years ago

There's progress but nevertheless it's not upstream llvm/rust so there will be pain, especially if we want new features like async-await.

dhslichter commented 3 years ago

+1 to analog output. It would let you use the same detector both for logging purposes and in e.g. analog feedback loops. I like the idea of having two boards that stack together (with a pin header probably), one simple analog, one giving ADC, CPU, etc., with the analog also passed through the CPU PCB so it can be accessed even if there is an ADC/CPU PCB in place.

gkasprow commented 3 years ago

Do we care so much about RUST? The idea is that everybody could modify the design easily using uPython. We can also use STM32 but it will cost much more because we would need an additional wireless module. However, if you need some real-time features, then RUST is right choice. The initial idea was to have simple off-line monitoring capability. MQTT is not a real-time protocol :)

sbourdeauducq commented 3 years ago

What applications do you have in mind for the embedded Python interpreter? We've been reusing some code from https://github.com/RustPython/RustPython for the next (much faster) ARTIQ-Python compiler and it's looking like a pretty neat codebase. Maybe we can have Rust and Python at the same time :)

For STM32 there are integrated solutions: https://www.st.com/en/wireless-transceivers-mcus-and-modules/wi-fi.html For people who like software written by hardware companies, a similar Micropython stack is advertised. Not sure about Rust support for the peripherals but at least the CPU core will be supported by upstream compilers.

gkasprow commented 3 years ago

I meant Micropython. I use it for ESP32 + FPGA board already in a few projects. Is the wireless MCU from STM supported by RUST? I already designed Thermostat with an expensive TI MCU and then we switched to STM32. I'd like to avoid expensive and exotic platforms. ESP32 is well known, every student can set up an MQTT client, Wifi AP, or whatever in a few minutes. If somebody doesn't like Micropython, Arduino works as well. ESP32 module is 2$.