On 08/31, Marcelo Schmitt wrote:
> On 08/31, Luca Weiss wrote:
> > Hi Jorijn,
> > 
> > On Sun Aug 30, 2026 at 10:19 PM CEST, Jorijn van der Graaf wrote:
> > > On Sun, Aug 30, 2026 at 12:03:29PM -0300, Marcelo Schmitt wrote:
> > >> Having a closer look at the data sheet I found for STK36C61, I noticed 
> > >> registers
> > >> 0x13 and 0x14 are not listed. Does the newer part has ambient light 
> > >> sensing
> > >> besides the clear channel?
> > >
> > > That looks to be the "STK36C61-A Preliminary Datasheet v0.9" hosted by
> > > LCSC [1], which I hadn't found before, so the cover letter's "There is
> > > no public datasheet" is wrong. It documents the -A variant, however,
> > > and gives PDT_ID as 0x93, while the part in the Fairphone 6 reports
> > > 0x95. It does agree with the device on the colour-engine layout: RGBC
> 
> The data sheets I was comparing were from
> https://datasheet4u.com/datasheets/Sensortek/STK3310/836592
> https://jlcpcb.com/partdetail/SENSORTEK-STK36C61A/C49230205
> which were the first links that appeared to me on an online search.
> 
> > 
> > Just to chime in, the datasheet I have access to (STK36C61-A Preliminary
> > Datasheet Version - 0.9.2) there are a few changes compared with the one
> > from LCSC but nothing too interesting:
> > 
> > * On the overview page LED current 228.75 changed to 218.75 mA
> > * ALSCTRL1 register (0x02) has different values for BIT[6:4]
> >   (17.92 -> 143.36; 8.96 -> 35.84; 4.48 -> 8.96)
> > * PDT_ID is indeed 0x95 - maybe the previous version just had wrong
> >   copy-pasted info?
> > 
> 
> Hmm, I was initially thinking about the added STK3310_PROXIMITY_CHANNEL for
> stk36c61. If STK36C61 has ambient light sensing (similar to STK3310 light
> sensing read from registers 0x13 and 0x14) then it makes sense to have that
> channel for STK36C61 too. Otherwise, that specific ambient light channel
> shouldn't belong to stk36c61_channels.
> 
> I didn't find a data sheet for the part with PDT_ID 0x95, though, that sounds
> like another thing to tidy up. Update the naming from STK36C61 to STK36C61A.
> So, if STK36C61 (without the A) is ever added, there will be no naming 
> conflict.
> Unless STK36C61 is never going to be released (which doesn't seem to be the 
> case
> cause I can find a data sheet for that).

Never mind, I completely missed the point of it having a preliminary datasheet.
It might be sensible to try to estimate if the final version will keep the same
name and PDT_ID.

Reply via email to