Illuminance values incorrect

[HartD92]

Using Zibee build, connected to Home Assistant via ZHA. One Sensor has never reported anything but 1 lux, and another cycles between exactly 1 lux, 17 lux, and 41 lux, with no other values ever reported.

I confirmed that the luminance sensor was correctly positioned on the pick/place order, and the programming with bluepill seemed to work correctly. All other values report back roughly what I'd expect.

[rbaron]

I only have two b-parasites running the Zigbee firmware, but they seem to be okay for illuminance. Here's a recent 3-day sammple:

But I also have a board with a known faulty phototransistor (whose orientation-correcting surgery I botched, destroying it) that curiously outputs the a similar set of values in {1, 17, 41, 59}, independent of actual light shining on it:

This data suggests that you have a fault/wrongly orientated phototransistor. Did you follow the Q4 orientation guide in the Wiki? For 1.2.0 boards the analogy remains: collector goes by the silkscreen dot.

Here's what it looks like upclose in a 1.2.0 board:

[HartD92]

This was the confirmed production file, showing the Collector oriented on the left of the PCB, as noted in Issue #42

And this is the output I get on the device that outputs 1,17,41:

[rbaron]

The nRF52 footprint seems different from the one in the repo, but that shouldn't matter. Which nRF52 module are you using? Did you solder them yourself? It could be a hardware issue. I would 1. double check the solder joints, specially these two pads:

and 2. Run the ble sample with:

CONFIG_PRST_SLEEP_DURATION_SEC=1
CONFIG_PRSTLIB_LOG_LEVEL_DBG=y

And watch the debugging messages. You should see stuff like this in the RTT terminal:

[00:03:00.023,620] <dbg> adc: prst_adc_photo_read: Read phototransistor: 225 lx | 0.04 V

[HartD92]

I used the E73-2G4M08S1CX, which I saw others had used. Afaik it's the same module, just with an antenna port instead of a built-in ceramic antenna. I had it placed/soldered by JLCPBC, I didn't do it myself. The solder joints all look fine. I need to pick up some more CR2032s, but I'll do that and follow up with the results of the BLE w/ debug.

[rbaron]

Meanwhile you can also double check the orientation by comparing your board with the pic I sent in https://github.com/rbaron/b-parasite/issues/106#issuecomment-1427042467. The inner darker square should be slightly shifted do the left in your case:

[HartD92]

Yeah, I checked, it looks correct like the picture you sent.

[HartD92]

I put batteries in two more, and those are reporting correct illuminance values. I will reflash one of the ones that's having trouble with the BLE fw with debug still, to see what exactly it's reporting with that firmware still, to see what it reports back, but at least it's definitely not a problem with the part placement/circuits.

One interesting thing that DID turn up here, one of these devices is reporting that it's battery powered, and with a battery % diagnostic: All of the rest of them report back that they are mains powered, and therefore have no battery %: Which one is working as intended?

[rbaron]

it's definitely not a problem with the part placement/circuits

If 2 out of 3 boards work with the exact same firmware, I stand by my original guess that it's a hardware issue. The analog pin sampling the phototransistor is likely just reading ground through R10. It's unlikely that logging will print something other than ~0 V. Could be a bad solder joint (the two joints around Q4 and between Q4 and the nRF module are the bigger suspects), or a faulty phototransistor.

Which one is working as intended?

We configure our power config cluster with a 1-battery cell, so I'd expect to see that.