I am trying to change a design that I have on a PCB (Raspberry Pi 4/5) HAT from a photoresistor to a phototransistor. The RPi has only digital Input and no ADC inputs. So I need to transform the values from analog to a timed based system that I can detect.

I am using a capacitor as a "battery" that I fill with a GPIO signal (3.3V) and then time how long it takes to "deplete" (technically to 1.6V) and this gives me a very usable value for the light intensity. I don't need anything more precise than that (It's used to dim the screen gradually in low light conditions and so not an on/off switch). It works very well with the Photoresistor, but it's not an SMD component and can't easily (cheaply) be mass produced.

I am tying to move to a phototransistor. However, those give a variable amount of current and not resistance.. I am trying to find a suitable circuit that translates that to a similar design (hard to redesign the whole layout) and I don't want to use another IC for A/D conversion as it's still hard to read with a single digit pin.

Here's a circuit I came up with, but I'm not sure it will work. The idea is that once the capacitor is filled, the rate of decrease is changed by how much current the phototransistor emits. As there are significant costs to make test PCBs to see it the design is correct, I would love some expert advice on this design or anything similar using only passive components.



My main concern is knowing if this circuit will "drain" the capacitor correctly once the GPIO pin goes to input mode (like my photoresistor design)

If you know a better design, I'm also all ears

 

Transistors change CE resistance (not all resistances are ohmic), you can model them as current controlled devices for operating parameters.


It's not easy putting those tiny guys and girls in there.

The circuit seems pretty simple to breadboard for testing and tweaking.

 

Transistors change CE resistance (not all resistances are ohmic), you can model them as current controlled devices for operating parameters.
...
It's not easy putting those tiny guys in there.

The circuit seems pretty simple to breadboard for testing and tweaking.

Not PHOTOTransistors. This one in particular:

Ambient Light Sensor
Surface - Mount
ALS-PT19-315C/L177/TR8
Features
‧Close responsively to the human eye spectrum
‧Light to Current, analog output

This is an very small SMD circuit and can't be easily breadboarded, as there are multiple devices involved on multiple PCBs (RPi/HAT/side panel).

I just want a theoretical confirmation. Not sure if I need a parallel resistor to the capacitor also.

 

Not PHOTOTransistors. This one in particular:

Ambient Light Sensor
Surface - Mount
ALS-PT19-315C/L177/TR8
Features
‧Close responsively to the human eye spectrum
‧Light to Current, analog output

This is an very small SMD circuit and can't be easily breadboarded, as there are multiple devices involved on multiple PCBs (RPi/HAT/side panel).

I just want a theoretical confirmation. Not sure if I need a parallel resistor to the capacitor also.

How to you think the CE current changes with changes in light intensity on the exposed base? The CE path doesn't generate current, it controls current.

I mean just breadboard the photosensor circuit part for the existing pads currently used for a photoresistor. Do you have actual experience with circuit level electronics?

 

Yes, your circuit will work, same as the one below.
You will have to experiment with the values of R1, R2, and C1, and the time interval.
I don't know if R2 is required.

You will measure the frequency of oscillations as follows:

Configure the GPIO pin as output. Send logic LOW to the output in order to discharge C1.
Switch the GPIO to input. Trigger an interrupt when GPIO goes high.
Repeat this sequence for a timed duration and count the number of interrupts that occurred.

 

You mentioned the uP doesn’t have an integrated ADC? Use an external one, driven by I2C or SPI.
Or consider a voltage to frequency IC.

BUT…. Why not use a light sensor which has those communications protocols already built in? There are many devices, I particularly like the I2C ones.
I can get you the part number later.

 

Yes, your circuit will work, same as the one below.
You will have to experiment with the values of R1, R2, and C1, and the time interval.
I don't know if R2 is required.

You will measure the frequency of oscillations as follows:

Configure the GPIO pin as output. Send logic LOW to the output in order to discharge C1.
Switch the GPIO to input. Trigger an interrupt when GPIO goes high.
Repeat this sequence for a timed duration and count the number of interrupts that occurred.

View attachment 339642

I've read that the resistor AFTER the phototransistor will actually limit functionality, because of decreased current.
So I put it before.
The circuit you are proposing is actually in the datasheet, used to measure voltage instead of current. I can try.
It will definitely give a path for the capacitor to drain

 

You mentioned the uP doesn’t have an integrated ADC? Use an external one, driven by I2C or SPI.
Or consider a voltage to frequency IC.

BUT…. Why not use a light sensor which has those communications protocols already built in? There are many devices, I particularly like the I2C ones.
I can get you the part number later.

The design is actually a 3 part circuit (rpi / HAT / side panel with detector attached with 2 wires)
Adding i2c will add 3 more wires and (maybe just 2). But I already have an audio codec and an OLED display on i2c. Trying to keep the HAT modifications to a minimum for this feature
It *is* a good idea in general

 

The series resistor can go before or after the sensor. It makes no difference.

The resistor in parallel with the capacitor is there for a different reason. It is not to drain the capacitor. RL in the datasheet is the load resistor., a path for the current to flow. CL serves as an integrator, i.e. a low-pass filter.

 

Do you have actual experience with circuit level electronics?

Yes, this is a fully functional HAT that I have designed and manufactured going on 3 years. I'm just considering if I should change the side panel to a phototransistor without redesigning too much. Photoresistor works great. Have rust code that works with my display and side OLED. But it's bulky and not SMD.

 

Yes, this is a fully functional HAT that I have designed and manufactured going on 3 years. I'm just considering if I should change the side panel to a phototransistor without redesigning too much. Photoresistor works great. Have rust code that works with my display and side OLED. But it's bulky and not SMD.

I asked because of the things you've said about resistor placement and transistor operation. These are types of things people believe (in good faith) from reading about things instead of actually understanding things.

Old Engineering saying. Why change something that's working great. Do you need the extra space? Is there a high manufacturing cost for the through-hole component or is it just not elegant and looks, old school. (like comparing C to rust)

 

I asked because of the things you've said about resistor placement and transistor operation. These are types of things people believe (in good faith) from reading about things instead of actually understanding things.

Old Engineering saying. Why change something that's working great. Do you need the extra space? Is there a high manufacturing cost for the through-hole component or is it just not elegant and looks, old school. (like comparing C to rust)

The photoresistor is NOT a standard part I can source from Mouser or DigiKey. I have to buy separately and drop ship to PCB Manufacturing.
Every purchase ends up with a different version ... Like when they ship a 2mm footprint instead of 3mm ... Or change the min/Max R values.

As for the transistor, it's a more elaborate one with built in amplifier and the reasoning that V source can have a resistor but the output is hindered "seemed" logical ...

Not saying I'm good at it, but I happen to be an electronic and software engineer. Just that hardware had taken a back seat to software for the last 20-30 years or so. (Yes I'm older!)
Just a pain.

 

From DigiKey:

https://www.digikey.com/en/products...tronics-co-ltd/ALS-PT19-315C-L177-TR8/2675735

 

From DigiKey:

https://www.digikey.com/en/products...tronics-co-ltd/ALS-PT19-315C-L177-TR8/2675735

I'm confused as why you posted this. I was talking about the photoresistor which is a through hole part which is obsoleted more or less now and hard to order. I did use this exact phototransistor as an example to use going forward.

 

Configure the GPIO pin as output. Send logic LOW to the output in order to discharge C1.
Switch the GPIO to input. Trigger an interrupt when GPIO goes high.
Repeat this sequence for a timed duration and count the number of interrupts that occurred.

BTW, this is the correct algorithm I'm using currently. I explained the low and high features wrong in the main post.

FYI: Using rust RPi GPIO code. I set low and just wait for one single interrupt to detect switch to high. Measure time. For more smooth response, average over a few cycles every 5 seconds to get a very usable result. Also handles differences between each version of the detection hardware which varies highly with min and max times. I do need to make the curve linear using log functions. Anyways. The code works perfectly as a background thread.

Hoping to use same code for phototransistor

 

Don't use log functions. Measure frequency and the relationship is linear.

 

The photoresistor is NOT a standard part I can source from Mouser or DigiKey. I have to buy separately and drop ship to PCB Manufacturing.
Every purchase ends up with a different version ... Like when they ship a 2mm footprint instead of 3mm ... Or change the min/Max R values.

As for the transistor, it's a more elaborate one with built in amplifier and the reasoning that V source can have a resistor but the output is hindered "seemed" logical ...

Not saying I'm good at it, but I happen to be an electronic and software engineer. Just that hardware had taken a back seat to software for the last 20-30 years or so. (Yes I'm older!)
Just a pain.

One day I will get off my duff and take another look at rust for some Linux embedded projects. The first time I looked at it a few years ago I didn't like the software engineering design of low-level aspects of the language being too abstracted from hardware.

 

One day I will get off my duff and take another look at rust for some Linux embedded projects. The first time I looked at it a few years ago I didn't like the software engineering design of low-level aspects of the language being too abstracted from hardware.

I have a total love/hate relationship with rust. Years of experience are completely wasted on unimaginable syntax for simple stuff and undocumented voodoo for complex libraries. RTFM is more like RTFC ...

But honestly, once you get past that, ... It's freaking fast and at least memory handling is clean.

My previous codes in other languages talking to I2C and handling background tasks are now barely noticable in system resources

Still would never consider rust for front end even if my life depends on it.

Did I mention love/hate???

 

I have a total love/hate relationship with rust. Years of experience are completely wasted on unimaginable syntax for simple stuff and undocumented voodoo for complex libraries. RTFM is more like RTFC ...

But honestly, once you get past that, ... It's freaking fast and at least memory handling is clean.

My previous codes in other languages talking to I2C and handling background tasks are now barely noticable in system resources

Still would never consider rust for front end even if my life depends on it.

Did I mention love/hate???

I started doing HLL systems programming in Modula-2 (my first love as a high level programming language) on the 68000 after many years of ASM on the Z80 and 8080 -> 8086, then C because my programming domain is mainly bare-metal controller programming and a C compiler is usually all that's supported. With modern IDE's the syntax is less of an issue but the mindset of making the rust compiler happy as opposed to thinking as a machine slinging bits (with the decades of years of experience) is not natural for me as rust grinds thought checks a rookie makes and old experts that know better slipup on. I'm a beginner and The Rule is "don't fight the compiler" and do things in a safe way. But the world of interfacing with hardware is not safe (something that rust lets you override checks for) because hardware can be nondeterministic and out of the realm of computable and software compile checks, so it sort of IMO defeats the rationale for using rust for 'safer' programming at some levels. Many times programs are throwaway tests or proof of concepts that you don't care about memory safety or other 'bad' stuff.

The rust language computer science concepts are pretty old (same era as OOP) and are not revolutionary ideas but the ability to write decent compilers on fast computers is what's happening to make rust usable today IMO.

Still, it seems fun to learn new things as learning rust will likely make me better at X other language.

Sounds to me your photoresistor issue is mainly a supply driven event but that's pretty common today.

 

Ok.. I gave up trying to make this work with passive devices.

I took the expert advice and chose an I2C ADC chip that takes very low currents from a simple phototransistor on a separate PCB and measures it and send out the result on the I2C bus when requested. It's way overkill for what I want to do, but simpler in electronics and software. I already have a bunch of devices on the I2C bus and my rust code seems to handle it pretty well. (It's a TI chip - ADC081C027CIMK/NOPB) I've ordered a new PCB and should receive it soon (with extra costs with the new tariffs).
If anybody is interested, let me know and I'll put the outcome and the circuitry here