Open airwoodix opened 4 years ago
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.
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.
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.
@jordens makes sense. It will consist of two small PCBs so it will be easy to swap the CPU
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.
Yes, the idea is to have a compatible front-end module with Photodiode_Amplifier which will have much higher BW.
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:
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 :)
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.
true, at the WUT we don't use 2.4GHz WiFi at all. You can get 10Mbit/s at most :)
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.
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
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.
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.
@jordens do you have the mechanical files for your SM1 design?
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?
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.
We could use a low-cost CPU like STM32F072CBU6 which has a USB and the package is tiny.
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.
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.
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
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.
@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.
The wireless connectivity can be easily provided using RPI0 and USB cable.
two-board version
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.
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?
12 Bit is plenty.
M8 is much bigger than SMA. here is the comparison
USB is free, for M8 you have to pay.
We have 50$ budget including mechanics and assembly. M8 is 15$ or so.
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.
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.
USB-C cable can be built in a few minutes using a piece of RJ45 patchcord and the plug
the KSZ8851 MAC+PHY over SPI has Auto-MDIX so we don't care about Ethernet Rx/Tx pair swapping
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.
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.
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:
And some hints on TIA optimization: https://www.analog.com/en/technical-articles/optimizing-precision-photodiode-sensor-circuit-design.html
thanks, looks like I have some "homework" to do
I've created the first version of a simple block diagram for DiPho DiPho_block_diagram.pdf
@pm-daniel
@pm-daniel when can I expect the first version of schematics?
@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
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...
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.
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.