--- Log for 09.04.121  Server: weber.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 14 days and 10 hours ago

00.03.04 #       <speachy> dconrad: check out g#3312
00.03.06 #       <fs-bluebot> Gerrit review #3312 at https://gerrit.rockbox.org/r/c/rockbox/+/3312 : erosq:  Switch to 32-bit PCM output, and do volume scaling in driver by Solomon Peachy
00.04.19 #       <dconrad> holy cow that was a fast change
00.04.55 #       <speachy> I'm thinking it probably makes the most sense to just use the master volume to control both line and hp output due to the overdrive issue
00.05.56 Quit    kakaka (Remote host closed the connection)
00.05.57 #       <speachy> since we probably need to cap headphone output too because it's surely overdriving the HP amp in this thing
00.06.30 Join    kakaka [0] (~koniu@gateway/tor-sasl/koniu)
00.06.45 ***     Saving seen data "./dancer.seen"
00.07.22 #       <dconrad> so I should be able to pull and build this?
00.07.35 #       <speachy> it's not committed yet so you'd need to cherry-pick it out of gerrit
00.07.58 #       <dconrad> sure
00.08.12 #       <speachy> I should measure the x3 and x3ii's line out to see what they're like
00.09.53 #       <speachy> not tonight though
00.15.37 #       <speachy> let me know how it works for you
00.15.40 #       <speachy> and now, bed.
00.15.49 #       <dconrad> haha, thanks for the quick turnaround
00.16.05 #       <dconrad> ...still building...
00.20.55 #       <dconrad> I'll have to play with it more tomorrow but holy cow, I think it might be completely fixed?
00.23.36 #       <dconrad> the numerical scaling is different/off, but the same track at very quiet volumes doesn't have any glitching at all?
00.23.50 #       <dconrad> (dB number displayed)
00.28.12 Quit    chris_s (Quit: Ping timeout (120 seconds))
00.39.42 Quit    dconrad ()
01.44.35 Quit    Rower (Read error: Connection reset by peer)
02.06.46 ***     Saving seen data "./dancer.seen"
02.30.20 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
03.40.00 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:793b:87ec:38af:f44a)
04.02.17 Quit    ChanServ (*.net *.split)
04.02.18 Quit    tomato (*.net *.split)
04.02.18 Quit    atsampson (*.net *.split)
04.02.18 Quit    Acou_Bass (*.net *.split)
04.02.18 Quit    hook54321 (*.net *.split)
04.02.18 Quit    JanC (*.net *.split)
04.02.18 Quit    emacsomancer (*.net *.split)
04.02.18 Quit    speachy (*.net *.split)
04.02.18 Quit    ZincAlloy (*.net *.split)
04.02.19 Quit    St3ak (*.net *.split)
04.02.19 Quit    plum (*.net *.split)
04.02.19 Quit    bluebrother (*.net *.split)
04.02.19 Quit    Rower (*.net *.split)
04.02.19 Quit    CR0W (*.net *.split)
04.02.19 Quit    amiconn (*.net *.split)
04.02.19 Quit    bzed (*.net *.split)
04.02.20 Quit    RafiX (*.net *.split)
04.02.21 Quit    ccf-100 (*.net *.split)
04.02.21 Quit    kakaka (*.net *.split)
04.02.22 Quit    mud (*.net *.split)
04.02.22 Quit    toruvinn (*.net *.split)
04.02.22 Quit    rasher (*.net *.split)
04.02.23 Quit    vup (*.net *.split)
04.02.23 Quit    edhelas (*.net *.split)
04.02.24 Quit    blbro[m] (*.net *.split)
04.02.24 Quit    michaelni (*.net *.split)
04.02.24 Quit    shrizza (*.net *.split)
04.02.24 Quit    asaba (*.net *.split)
04.02.25 Quit    fs-bluebot (*.net *.split)
04.02.25 Quit    ps-auxw (*.net *.split)
04.02.25 Quit    bertrik (*.net *.split)
04.02.25 Quit    xcin (*.net *.split)
04.02.25 Quit    WakiMiko (*.net *.split)
04.02.25 Quit    Slasheri (*.net *.split)
04.02.26 Quit    danielp3344 (*.net *.split)
04.02.26 Quit    ecs (*.net *.split)
04.02.26 Quit    TorC (*.net *.split)
04.02.26 Quit    funman (*.net *.split)
04.02.26 Quit    advcomp2019 (*.net *.split)
04.02.27 Quit    rogeliodh (*.net *.split)
04.02.27 Quit    Huntereb (*.net *.split)
04.02.27 Quit    tchan (*.net *.split)
04.02.27 Quit    spectrumanalyst (*.net *.split)
04.02.27 Quit    gsora (*.net *.split)
04.02.27 Quit    ParkerR (*.net *.split)
04.02.27 Quit    benedikt93 (*.net *.split)
04.02.27 Quit    bleb (*.net *.split)
04.02.27 Quit    prg3 (*.net *.split)
04.02.27 Quit    paulk-leonov (*.net *.split)
04.02.27 Quit    Tsesarevich (*.net *.split)
04.02.28 Quit    XDjackieXD (*.net *.split)
04.02.28 Quit    rudi_s (*.net *.split)
04.02.28 Quit    jschwart (*.net *.split)
04.02.28 Quit    skrzyp (*.net *.split)
04.02.28 Quit    galaxy_knuckles (*.net *.split)
04.02.28 Quit    SovietShaman_ (*.net *.split)
04.02.28 Quit    ender| (*.net *.split)
04.02.28 Quit    igitoor (*.net *.split)
04.02.29 Quit    berber (*.net *.split)
04.02.29 Quit    Ckat (*.net *.split)
04.02.29 Quit    daswf852 (*.net *.split)
04.02.29 Quit    bonfire (*.net *.split)
04.02.29 Quit    jdarnley (*.net *.split)
04.02.29 Quit    yosafbridge (*.net *.split)
04.02.29 Quit    beencubed (*.net *.split)
04.02.29 Quit    _bilgus (*.net *.split)
04.02.29 Quit    olspookishmagus (*.net *.split)
04.02.29 Quit    user890104 (*.net *.split)
04.02.29 Quit    braewoods (*.net *.split)
04.02.30 Quit    ArsenArsen (*.net *.split)
04.02.30 Quit    GeekShadow (*.net *.split)
04.02.30 Quit    Galois (*.net *.split)
04.02.30 Quit    __builtin (*.net *.split)
04.02.30 Quit    mikroflops (*.net *.split)
04.02.30 Quit    blucifer22 (*.net *.split)
04.02.31 Quit    pixelma (*.net *.split)
04.02.31 Quit    Soap_ (*.net *.split)
04.02.31 Quit    SammysHP (*.net *.split)
04.02.31 Quit    Natch (*.net *.split)
04.02.31 Quit    copper (*.net *.split)
04.02.31 Quit    Xeha (*.net *.split)
04.02.31 Quit    aevin (*.net *.split)
04.02.31 Quit    kugel (*.net *.split)
04.02.31 Quit    kadoban (*.net *.split)
04.02.31 Quit    APLU (*.net *.split)
04.02.31 Quit    klock (*.net *.split)
04.02.32 Quit    lemon_jesus (*.net *.split)
04.02.32 Quit    trfl (*.net *.split)
04.02.32 Quit    f1refly (*.net *.split)
04.02.32 Quit    Barlow (*.net *.split)
04.02.32 Quit    Moarc (*.net *.split)
04.02.32 Quit    Strife89 (*.net *.split)
04.02.32 Quit    Topy44 (*.net *.split)
04.02.32 Quit    Romster (*.net *.split)
04.02.32 Quit    gevaerts (*.net *.split)
04.02.32 Quit    kirvesAxe (*.net *.split)
04.02.33 Quit    ufdm (*.net *.split)
04.02.33 Quit    fauweh (*.net *.split)
04.02.33 Quit    jerwin (*.net *.split)
04.02.33 Quit    alexbobp (*.net *.split)
04.02.33 Quit    KalBot (*.net *.split)
04.06.49 ***     Saving seen data "./dancer.seen"
04.06.57 Join    trfl [0] (~ed@static.59.110.40.188.clients.your-server.de)
04.06.57 Join    lemon_jesus [0] (~lemon_jes@208.59.79.137)
04.06.57 Join    klock [0] (~freeklock@unaffiliated/klock)
04.06.57 Join    APLU [0] (~mulx@2a03:7220:8081:2900::1)
04.06.57 Join    speachy [0] (~speachy@209.2.65.77)
04.06.57 Join    emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net)
04.06.57 Join    hook54321 [0] (sid149355@gateway/web/irccloud.com/x-yowuzbrikpmmzknf)
04.06.57 Join    Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
04.06.57 Join    atsampson [0] (~ats@cartman.offog.org)
04.06.57 Join    tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
04.06.57 Join    blucifer22 [0] (~quassel@204.48.30.120)
04.06.57 Join    mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se)
04.06.57 Join    __builtin [0] (~quassel@rockbox/developer/builtin)
04.06.57 Join    Galois [0] (djao@efnet.math.uwaterloo.ca)
04.06.57 Join    ChanServ [0] (ChanServ@services.)
04.06.57 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
04.06.57 Join    CR0W [0] (~narf@unaffiliated/em64t)
04.06.57 Join    amiconn [0] (jens@rockbox/developer/amiconn)
04.06.57 Join    bzed [0] (~bzed@shell.bzed.at)
04.06.57 Join    vup [0] (~~~~@46.101.193.235)
04.06.57 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:793b:87ec:38af:f44a)
04.06.57 Join    St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
04.06.57 Join    plum [0] (~plum@unaffiliated/plum)
04.06.57 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
04.06.57 Join    asaba [0] (~asaba@103.113.159.184)
04.06.57 Join    fs-bluebot [0] (~fs-bluebo@55d48c6a.access.ecotel.net)
04.06.57 Join    ps-auxw [0] (~arneb@p548d5577.dip0.t-ipconnect.de)
04.06.57 Join    bertrik [0] (~bertrik@rockbox/developer/bertrik)
04.06.57 Join    xcin [0] (~x@159.203.132.140)
04.06.57 Join    ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
04.06.57 Join    fauweh [0] (~root@ithaqua.unzane.com)
04.06.57 Join    KalBot [0] (~matrixirc@connolly.tech)
04.06.57 Join    jerwin [0] (~flippy-fl@unaffiliated/flippy)
04.06.57 Join    alexbobp [0] (~alex@meowface.org)
04.06.57 Join    edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257)
04.06.57 Join    michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at)
04.06.57 Join    shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net)
04.06.57 Join    f1refly [0] (~f1refly@dynamic-077-008-223-115.77.8.pool.telefonica.de)
04.06.57 Join    Barlow [0] (~barlow@unaffiliated/barlow)
04.06.57 Join    Moarc [0] (~chujko@a105.net128.okay.pl)
04.06.57 Join    Strife89 [0] (~quassel@adsl-74-250-151-186.ags.bellsouth.net)
04.06.57 Join    Topy44 [0] (YwgdD0qBv9@bellatrix.uberspace.de)
04.06.57 Join    Romster [0] (~romster@unaffiliated/romster)
04.06.57 Join    gevaerts [0] (~fg@rockbox/developer/gevaerts)
04.06.57 Join    kirvesAxe [0] (kirvesaxe@aulis.sange.fi)
04.06.57 Join    Slasheri [0] (~miipekk@rockbox/developer/Slasheri)
04.06.57 Mode    "#rockbox +o ChanServ   " by weber.freenode.net
04.06.57 Join    WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
04.06.57 Join    funman [0] (~fun@rockbox/developer/funman)
04.06.57 Join    TorC [0] (~Tor@fsf/member/TorC)
04.06.57 Join    ecs [0] (esawady@sourcehut/interns/ecs)
04.06.57 Join    GeekShadow [0] (~antoine@unaffiliated/geekshadow)
04.06.57 Join    ArsenArsen [0] (~Arsen@managarm/dev/ArsenArsen)
04.06.57 Join    braewoods [0] (~braewoods@learnprogramming/staff/braewoods)
04.06.57 Join    user890104 [0] (~Venci@freemyipod.org)
04.06.57 Join    olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr)
04.06.57 Join    _bilgus [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com)
04.06.57 Join    beencubed [0] (~beencubed@209.131.238.248)
04.06.57 Join    yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de)
04.06.57 Join    jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
04.06.57 Join    bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net)
04.06.57 Join    daswf852 [0] (~daswf852@unaffiliated/dwf)
04.06.57 Join    RafiX [0] (rafix@junkcc.net)
04.06.57 Join    ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3)
04.06.57 Join    igitoor [0] (igitur@unaffiliated/contempt)
04.06.57 Join    SovietShaman_ [0] (quassel@024-217-039-226.res.spectrum.com)
04.06.57 Join    galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549)
04.06.57 Join    skrzyp [0] (~skrzyp@skrzyp.net)
04.06.57 Join    jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567)
04.06.57 Join    rudi_s [0] (~simon@bmi.informatik.uni-erlangen.de)
04.06.57 Join    XDjackieXD [0] (~jackie@irc.chaosfield.at)
04.06.57 Join    paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr)
04.06.57 Join    prg3 [0] (~prg@deadcodersociety/prg318)
04.06.57 Join    bleb [0] (~cm@unaffiliated/bleb)
04.06.57 Join    benedikt93 [0] (~quassel@unaffiliated/benedikt93)
04.06.57 Join    ParkerR [0] (~ParkerR@unaffiliated/parkerr)
04.06.57 Join    gsora [0] (~gsora@unaffiliated/gsora)
04.06.57 Join    spectrumanalyst [0] (~admin@198.46.152.45)
04.06.57 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
04.06.57 Join    Huntereb [0] (~Huntereb@142-196-011-243.res.spectrum.com)
04.06.57 Join    rogeliodh [0] (~rogeliodh@rogeliodh.dev)
04.06.57 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
04.06.57 Join    Ckat [0] (~Ckat@xn--z7x.xn--6frz82g)
04.06.57 Join    berber [0] (~berber@v2202101107577140883.nicesrv.de)
04.07.06 Quit    dweeber (Max SendQ exceeded)
04.07.06 Join    rasher [0] (~rasher@rockbox/developer/rasher)
04.07.06 Join    toruvinn [0] (~toruvinn@77-255-90-179.adsl.inetia.pl)
04.07.07 Join    JanC [0] (~janc@lugwv/member/JanC)
04.07.34 Join    dweeber [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net)
04.08.16 Join    kakaka [0] (~koniu@gateway/tor-sasl/koniu)
04.08.57 Join    Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx)
04.09.19 Quit    paulk-leonov (Ping timeout: 250 seconds)
04.09.43 Quit    hook54321 (Ping timeout: 260 seconds)
04.09.49 Quit    Tsesarevich (Excess Flood)
04.10.10 Join    Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx)
04.12.22 Join    hook54321 [0] (sid149355@gateway/web/irccloud.com/session)
04.20.05 Quit    hook54321 (Changing host)
04.20.05 Join    hook54321 [0] (sid149355@gateway/web/irccloud.com/x-mxonnkmjnhseenax)
04.23.40 Join    paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr)
04.49.08 Join    pixelma [0] (marianne@rockbox/staff/pixelma)
04.49.08 Join    Soap_ [0] (~Soap@rockbox/staff/soap)
04.49.08 Join    SammysHP [0] (~SammysHP@faol.sammyshp.de)
04.49.08 Join    Natch [0] (~natch@c-b471e255.014-297-73746f25.bbcust.telenor.se)
04.49.08 Join    copper [0] (~copper@unaffiliated/copper)
04.49.08 Join    Xeha [0] (~Xeha@unaffiliated/xeha)
04.49.08 Join    aevin [0] (eivindsy@unaffiliated/aevin)
04.49.08 Join    kugel [0] (~kugel@rockbox/developer/kugel)
04.56.41 Join    ccf-100 [0] (ccf-100mat@gateway/shell/matrix.org/x-iomocwibultsdvpp)
04.56.41 Join    mud [0] (kadobanmat@gateway/shell/matrix.org/x-zgbmebmtuhdubutk)
04.56.41 Join    danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-mvlxwbiddmyjmqzj)
04.56.41 Join    kadoban [0] (kadobanemp@gateway/shell/matrix.org/x-zbemkkpthikwihsa)
04.56.48 Join    blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-tlbkackcydjojpba)
05.03.29 Quit    igitoor (Ping timeout: 250 seconds)
05.04.33 Join    igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648)
05.15.21 Quit    igitoor (Changing host)
05.15.21 Join    igitoor [0] (igitur@unaffiliated/contempt)
05.38.58 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
06.06.51 ***     Saving seen data "./dancer.seen"
06.17.07 Quit    JanC (Ping timeout: 260 seconds)
06.19.09 #       <speachy> dconrad:  I didn't check to see if the unity line out is the same.  but yeah, the scale is different.  due to how the math works, anything under -43 is effecively muted so there's no point in claiming to go lower than that.
06.21.15 #       <speachy> the other targets that use this 16->32-bit skullduggery have some control of analog gain so it's possible to be more nuanced but not here.
06.23.17 Quit    tomato (Read error: Connection reset by peer)
06.23.54 #       <braewoods> speachy: what xduoos do we support? i just saw an X2 for sale.
06.24.40 #       <braewoods> https://www.newegg.com/xduoo-x2-mp3-player/p/N82E16855455001
06.24.43 #       <braewoods> newegg no less
06.25.10 #       <speachy> braewoods: check the web page?  :D
06.25.27 #       <speachy> (but x3, x3ii, x20)
06.25.38 #       <braewoods> oh
06.25.40 #       <braewoods> not supported
06.25.42 #       <braewoods> ofc
06.25.59 #       <braewoods> https://forums.rockbox.org/index.php?topic=50788.0
06.26.09 #       <speachy> x2 is a cut-down chip along the lines of the atj212x  x2s is about the same.
06.26.14 #       <speachy> (presumably)
06.26.27 #       <speachy> d3 is a rknano-D
06.27.40 #       <braewoods> it's kinda weird seeing as how PP was so high end compared to a lot of modern players
06.27.55 #       <braewoods> don't even compare in terms of the average ram PP had
06.28.24 #       <braewoods> too bad rockbox doesn't have a company like gl.inet like openwrt does
06.28.32 #       <speachy> the funny thing is that the newer SoCs have faster CPUs in them, plus real HW acceleration blocks.  where they fall down is system RAM.
06.28.40 #       <braewoods> gl.inet sells hardware with their own openwrt derivatives
06.29.44 #       <braewoods> speachy: probably is, an armv7 or newer would probably smoke a PP
06.30.13 #       <braewoods> which makes me wonder...
06.30.53 #       <braewoods> would be funny to find a SoC that is just perfect for Rockbox porting
06.31.18 #       <braewoods> that we could make custom hardware out of
06.31.31 #       <braewoods> but eh
06.32.16 Join    tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
06.32.35 #       <speachy> dconrad:  also discovered that how I have the scrollwheel set up it doesn't prevent the disply from going to sleep.  oops.
06.33.25 #       <speachy> the ingenic X1000/X2000 series, and the allwinner V3/V3s are about perfect.  (also the FC series, but there's not much point in those unless the price is _very_ right...)
06.33.44 Join    JanC [0] (~janc@lugwv/member/JanC)
06.34.08 #       <speachy> the V3/FC series also have full upstream uboot/linux support and complete [enough] docs.
06.34.41 #       <braewoods> and more cores than we can shake a stick at
06.35.01 #       <braewoods> we're kinda SMP ready due to PP
06.35.03 #       <speachy> braewoods: they aren't v7s, they're Cortex-M, but clocked high enough to make a real difference.
06.35.05 #       <braewoods> though how much I can't say
06.35.18 #       <braewoods> oh, the allwinners lack a FPU?
06.35.33 #       <speachy> braewoods: I was talking about the cut-down stuff in more modern players
06.35.36 #       <braewoods> i thought most modern ARM chips had them now
06.35.38 #       <braewoods> Oh
06.35.40 #       <speachy> the allwinners are a proper armv7, yes
06.35.57 #       <speachy> the FC series is an armv6 (ARM11 core IIRC)
06.35.59 #       <braewoods> we don't need armv8
06.36.22 #       <braewoods> if we did have a cpu though we'd have access to 64 bit
06.36.35 #       <speachy> eh, we dont' need 64-bit but all else being equal the same code on armv8 vs v7 should run faster.
06.37.02 #       <speachy> (not unlike how x86_64 is faaster than ol' x86)
06.37.12 #       <braewoods> mostly due to more registers
06.37.29 #       <speachy> yep.
06.37.30 #       <braewoods> there were ABIs that were a hybrid of the old and new ABIs
06.37.35 #       <braewoods> x32 i believe
06.37.48 #       <braewoods> stayed 32 bit in some ways but leveraged the new 64 bit ISA
06.38.05 #       <speachy> x32 wasn't "better enough" to warrantt requiring a third binary format
06.38.18 #       <braewoods> good riddance
06.43.40 #       <fs-bluebot> Build Server message: New build round started. Revision 1e2a9a651c, 298 builds, 10 clients.
06.46.13 #       <braewoods> huh. so that's why AMD skybridge never came to be.
06.46.44 #       <braewoods> i wonder if they'll ever revisit that idea. being able to switch to ARM cores during idle would probably help energy usage.
06.54.42 #       <fs-bluebot> Build Server message: Build round completed after 662 seconds.
06.54.45 #       <fs-bluebot> Build Server message: Revision 1e2a9a651c result: All green
06.54.54 #       <fs-bluebot> Build Server message: New build round started. Revision 54b8e9131c, 298 builds, 10 clients.
06.58.28 #       <braewoods> speachy: looking for more xduoo x3? i just saw a good condition one up for auction
06.58.40 #       <braewoods> https://www.ebay.com/itm/XDUOO-X3-DIGITAL-AUDIO-PLAYER/184746255083
06.58.44 #       <speachy> I have my beater and a NIB spare
06.58.55 #       <braewoods> ah. ok.
06.59.10 #       <speachy> but someone else should buy it so they can enjoy its awesomeness
06.59.22 #       <braewoods> lol
06.59.49 #       <braewoods> the gigabeat F felt pretty good when I handled it earlier
06.59.59 #       <braewoods> it's mostly aluminum shell.
07.00.09 #       <braewoods> may be old but it's well built
07.02.39 #       <braewoods> well that was a productive night
07.02.53 #       <braewoods> i spent some time updating ungoogled chromium scripts for submitting stuff to OBS
07.06.41 #       <braewoods> speachy: what do you use for editting source code these days?
07.06.54 #       <speachy> emacs
07.06.59 #       <braewoods> i've grown fond of sublime text myself due to some features i'd never seen in an editor before
07.07.24 #       <braewoods> sessions mainly, it even remembers stuff i haven't officially saved yet
07.07.31 #       <braewoods> i was surprised
07.07.37 #       <braewoods> it has saved me from losing work a few times
07.09.53 #       <braewoods> i hate vim with a passion, only use it when i have to
07.10.09 #       <braewoods> it seems far too easy to accidently do the wrong thing and find your whole line replaced with garbage
07.10.12 #       <braewoods> or something
07.10.33 #       <speachy> the only vi command one really needs to know is how to quit without saving.  :)
07.13.26 #       <fs-bluebot> Build Server message: Build round completed after 1112 seconds.
07.13.29 #       <fs-bluebot> Build Server message: Revision 54b8e9131c result: All green
07.13.30 #       <fs-bluebot> Build Server message: New build round started. Revision 9847f9c85e, 298 builds, 10 clients.
07.28.27 #       <fs-bluebot> Build Server message: Build round completed after 897 seconds.
07.28.29 #       <fs-bluebot> Build Server message: Revision 9847f9c85e result: All green
07.28.31 #       <fs-bluebot> Build Server message: New build round started. Revision 10facef17b, 298 builds, 10 clients.
07.44.57 #       <fs-bluebot> Build Server message: Build round completed after 987 seconds.
07.44.59 #       <fs-bluebot> Build Server message: Revision 10facef17b result: All green
07.56.19 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
08.04.57 #       <braewoods> _bilgus: ok so i got a functional hdd6330 now i can test with...
08.05.16 #       <braewoods> so far i've observed GPIO changes when i connect to the dock
08.05.18 #       <braewoods> or disconnect
08.05.29 #       <braewoods> so must be some kind of indication of presence of the dock
08.05.41 #       <braewoods> but nothing for remote input
08.05.51 #       <braewoods> hm.
08.06.34 #       <braewoods> i also noted how the schematic shows that the "cradle remote" pin is connected directly to one of the chip pins labeled as PWM
08.06.43 #       <braewoods> the other PWM is for the LCD backlight
08.06.52 #       <braewoods> which i looked into... it's an output pin for sure
08.06.53 ***     Saving seen data "./dancer.seen"
08.07.01 #       <braewoods> the code does some stuff with a variable
08.07.21 #       <braewoods> i'm going to assume that the remote stuff i'm looking for isn't too different from how the backlight is controled
08.07.30 #       <braewoods> since it's right next to the other PWM pin
08.07.59 #       <braewoods> question is, how do I enable input on it so I can try to test my theory?
08.09.07 #       <braewoods> the LCD code uses outl to write to some address I believe.
08.09.36 #       <braewoods> also does something with GPO32_ENABLE and GPO32_VAL
08.10.15 #       <braewoods> _bilgus: there's only so many bits i can set so, any advice of what these do?
08.13.08 Join    Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-6c7b-cc55-d26f-2c7f.res6.spectrum.com)
08.21.46 #       <_bilgus> being that the pimns are right next door it should pretty straight forward to enable that GPIO as well
08.22.06 #       <_bilgus> that PWN signal is also ->out according to the schematic
08.22.50 #       <_bilgus> my assumption is that they are using the pwm and reading resistor ladders on the acd
08.22.54 #       <_bilgus> ADC
08.24.51 #       <_bilgus> doesn't means thats true though -- being that they have an ADC probably not BUT they could even be doing a cap charge on the pwm the buttons bleed it off or even something capacitive but I doubt it
08.25.53 #       <_bilgus> ALSO IIRC it appears they just piggy back off the inbuilt buttons so in theory you should be able to see them on the adc pin when you press buttons on the player
08.27.12 #       <_bilgus> if you have a DVM digital being key it should have high enough impedance that you should be able to probe the line
08.31.16 #       <_bilgus> I think that adc is always enabled so on the pin going back to it I'd just try placing a few resistors like this as a volatage divider between PWM and ground don't choose anything lower than about 1k
08.32.24 #       <_bilgus> so its going to go like this ---PWM ---v^v^v^-----ADC----v^v^v^-------GND
08.32.39 #       <_bilgus> -v^v^v- is a resistor :p
08.33.14 #       <braewoods> _bilgus: well there's only 2 connected ADC lines.
08.33.26 #       <braewoods> one is for the battery. the other is a mystery but appears to connect to the FM chip.
08.33.27 #       <_bilgus> so the one between PWM and ADC would be varied by buttons and would have a fixed one in parallel to hold the line
08.33.58 #       <_bilgus> it looks to me that the buttons on the player and the player buttons share that one
08.34.12 #       <_bilgus> but its also been like a week since I looked at it
08.34.24 #       <braewoods> this isn't the H10, the hdd6330
08.34.39 #       <braewoods> i'm just trying to figure out where it's connected in software right now
08.34.45 #       <braewoods> i thought PWM was an input here
08.34.52 #       <braewoods> since remote would be an input
08.34.56 #       <_bilgus> oh you are doing this blind
08.35.01 #       <braewoods> currently yes
08.35.14 #       <braewoods> i just thought you might have some ideas
08.35.23 #       <braewoods> i don't have the fancy hardware probes
08.35.32 #       <_bilgus> you don't need them
08.35.47 #       <braewoods> this seems simple enough that i shouldn't need them
08.35.50 #       <_bilgus> a DMM DVM will do fine unless its high speed stuff
08.36.15 #       <_bilgus> then even that high impedance can change the circuit
08.36.47 #       <_bilgus> so first I'd probably see if you can find the gpio triggering for the inbuilt buttons
08.37.01 #       <braewoods> that's probably easy
08.37.15 #       <braewoods> i also noted there's an interrupt line for the remote
08.37.20 #       <braewoods> but probably irrelevant for now
08.37.20 #       <_bilgus> they would probably do a similar scheme for the remote unless they were constrained
08.37.47 #       <_bilgus> if you have an interrupt then i'd assume a shift register holding button states
08.37.58 #       <braewoods> it appears PWM1 and the AIN1 are connected
08.38.13 #       <braewoods> is that what the red dot means?
08.38.27 #       <braewoods> err blue dot
08.38.43 #       <_bilgus> might be shared but IDK
08.39.01 Quit    akaWolf (Ping timeout: 260 seconds)
08.39.15 #       <braewoods> the fact it has a separate interrupt makes me think the input is on a different input
08.39.32 #       <braewoods> otherwise it'd probably use the same interrupt as the regular buttons
08.39.48 #       <_bilgus> if they are sending an interrupt then there is data stored somewhere
08.40.07 #       <braewoods> i think GPO32 is a good place to look
08.40.21 #       <_bilgus> so you do or don't have a remote?
08.40.25 #       <braewoods> i do
08.40.38 #       <_bilgus> oh well that makes this much easier start there lol
08.40.48 #       <braewoods> yea, i wouldn't be talking about it if i didn't
08.41.06 #       <_bilgus> I figured you were trying to RE it without a remote
08.41.18 #       <braewoods> why would i bother without the hardware?
08.41.22 #       <braewoods> i can't test it if i don't have it
08.41.26 #       <_bilgus> to make a remote
08.41.31 #       <braewoods> oh
08.41.33 #       <braewoods> lol
08.41.42 #       <braewoods> nah
08.41.53 #       <_bilgus> you need a scope even a $50 will get you somewhere
08.42.06 #       <braewoods> that still won't tell me where to poke around in software
08.42.25 #       <braewoods> address wise
08.42.26 #       <_bilgus> oh sure it will
08.42.31 #       <_bilgus> no not address
08.42.55 #       <braewoods> still i find it weird
08.42.58 #       <_bilgus> once you know the protocol that will narrow down where to look
08.42.58 #       <braewoods> in this schematic
08.43.06 #       <braewoods> why is the remote circled?
08.43.11 #       <braewoods> nothing else is
08.43.33 #       <_bilgus> but if you have a remote and code running then I'd dump the pin states and do some anaylasis
08.43.44 #       <_bilgus> analysis
08.43.46 #       <_bilgus> lol
08.43.49 #       <braewoods> i tried some of that already
08.44.00 #       <braewoods> nothing changes when i press buttons in the view i/o ports debug
08.44.06 #       <braewoods> for the remote
08.44.07 #       <braewoods> anyway
08.44.19 #       <braewoods> do i need to enable something?
08.44.28 #       <braewoods> i'm not used to embedded development
08.44.42 #       <_bilgus> probably its not looking at the right ones?
08.45.23 #       <_bilgus> but see if its using the ADC then you won't see GPIO data
08.45.37 #       <braewoods> the I/O ports also had ADC output
08.45.47 #       <_bilgus> ADC doesn't output
08.45.50 #       <braewoods> err
08.45.52 #       <braewoods> input
08.45.55 #       <_bilgus> its a GPIO then
08.45.55 #       <braewoods> it had the inputs
08.46.11 #       <braewoods> the schematic doesn't suggest it has anything to do with the connected ADC
08.46.13 #       <_bilgus> ah ok ADC inputs though need to be read
08.46.35 #       <_bilgus> So first look at the in states in software
08.46.45 #       <braewoods> truth is _bilgus most of the buttons here are implemented in a touchpad
08.46.45 #       <_bilgus> they are sometimes 00 01 10 11
08.46.53 #       <braewoods> save for the side buttons
08.46.55 #       <braewoods> which are gpios or so
08.47.07 #       <_bilgus> PIN states*
08.47.23 #       <_bilgus> so find the bits controlling the port directions
08.47.44 #       <_bilgus> and read out that then compare to known pin ststes
08.48.42 #       <_bilgus> if you have 32 pin states its probably in several INTS
08.49.22 #       <_bilgus> so one set will be 0 for in 1 for out (or even flipped!) and another set might be special functions
08.50.06 #       <braewoods> since nothing is happening I need to try flipping unused bits
08.50.30 #       <_bilgus> the remote is doing something no?
08.50.36 #       <braewoods> yes, in the OF it works
08.50.41 #       <_bilgus> ok good
08.50.51 #       <_bilgus> don't go flipping bits this aint that deep
08.50.51 #       <braewoods> i wouldn't be trying this without a reference point
08.50.55 Quit    Saijin_Naib (Ping timeout: 258 seconds)
08.51.14 #       <braewoods> I thought GPO32 would be a good place to start looking for inputs
08.51.24 #       <braewoods> where should I look then?
08.51.28 #       <_bilgus> go into the current button code and see if the adc puts out a different level first if you haven't already
08.51.41 #       <braewoods> ok i'll try it
08.51.46 #       <braewoods> actually...
08.51.53 #       <braewoods> i know for a fact it won't but i'll confirm it
08.52.09 #       <_bilgus> next i think i'd try finding that interrupt line
08.52.50 #       <_bilgus> it might be the to signal the adc is ready and I'd watch it in HARDWARE
08.53.40 #       <_bilgus> or if you can find other interrupt sources then you might be able to flip that bit
08.54.26 #       <braewoods> the only buttons triggering GPIOs are the physical ones
08.54.32 #       <braewoods> remote does nothing there
08.54.42 #       <_bilgus> ah ok I get what you are thinking flip the gpios to input to see if they toggle
08.54.59 Quit    massiveH (Quit: Leaving)
08.55.06 #       <braewoods> yes.. try to enable ones that are currently not used to see if anything changes when the remote is used
08.55.24 #       <braewoods> the ADC doesn't have anything to do with regular input
08.55.29 #       <braewoods> on this unit
08.55.32 #       <_bilgus> as long as you don't switch them to output then I think you'll be ok
08.55.46 #       <braewoods> oh that sounds bad
08.56.48 #       <_bilgus> fiugure most pins start in input so I don't see why they wouldn't already be enabled
08.57.12 Join    akaWolf [0] (~akaWolf@unaffiliated/akawolf)
08.57.38 #       <_bilgus> unless that remote has > 6 wires my guess would be reading the adc
08.57.52 #       <_bilgus> so lets enable the adc and do our own read of it
08.58.26 #       <braewoods> wouldn't the ADC be connected to the remote in some way if it was use?
08.59.07 #       <_bilgus> now you will have to figure out its input state so maybe you could hook up the remote and boot and read the imnitial memory setup
08.59.25 #       <_bilgus> well to a pin that the adc can be told to read
09.00.05 #       <_bilgus> if its disconnected though then no way to do that
09.00.26 #       <braewoods> U16 is connected to the battery ADC
09.00.33 #       <_bilgus> this is why I said start in the remote and figure out what it does for a button
09.00.33 #       <braewoods> no way it's used for this
09.00.38 #       <braewoods> Oh
09.01.53 #       <braewoods> huh i just had a weird idea
09.02.09 #       <braewoods> let me check what PM3 is
09.02.35 #       <_bilgus> so i figure you have several options... a. ADC b. GPIO directly c. processing and sending a packet (I2c, shift register, etc)
09.02.39 #       <braewoods> no indication
09.02.53 #       <braewoods> if I2C was used, the manual would probably give me the address for it
09.03.06 #       <braewoods> it does for the rest of the stuff
09.03.29 #       <braewoods> i was just thinking though bilgus
09.03.32 #       <braewoods> what if..
09.03.37 #       <braewoods> no wait
09.03.42 #       <braewoods> the backlight line is an output one
09.03.58 #       <_bilgus> how many wires go to the remote and what do they connect to in the remote?
09.04.16 #       <braewoods> _bilgus: well i looked at the dock since that's what is exposed to the player
09.04.47 #       <_bilgus> if the remote has a processor then it might be sending serial data
09.05.32 #       <_bilgus> acting as a shift register basically
09.05.58 #       <_bilgus> its too broad a search area ATM
09.06.14 #       <braewoods> there's only one remote
09.06.16 #       <braewoods> pin
09.06.48 #       <braewoods> _bilgus: what do these arrows mean anyway?
09.06.56 #       <braewoods> video out points away from the cradle
09.07.00 #       <braewoods> line out points towards it
09.07.18 #       <_bilgus> I'd assume the direction of data
09.07.31 #       <_bilgus> do yu have a pic of this schematic
09.07.38 #       <braewoods> i showed it to you before
09.07.42 #       <braewoods> https://www.rockbox.org/wiki/pub/Main/GoGearHDD6330/Philips_HDD6320_HDD6330_Service_Manual.pdf
09.07.53 #       <braewoods> it's at the back of the service manual
09.08.28 #       <braewoods> 30 pin cradle connector
09.08.33 #       <braewoods> i wonder if it's ipod compatible
09.10.16 #       <_bilgus> REMOTE control power on off
09.10.30 #       <braewoods> _bilgus: meaning what?
09.10.37 #       <braewoods> the cradle_remote is something else?
09.10.43 #       <_bilgus> it shows an opamp that leads to the interrupt pin
09.11.45 #       <_bilgus> so that tells me at least the power button uses a resistor ladder
09.12.12 #       <_bilgus> over on the left see the voltage divider
09.12.19 #       <_bilgus> between 3v3 and gnd
09.12.26 #       <_bilgus> thats the reference
09.12.42 #       <braewoods> to trigger an interrupt?
09.12.48 #       <_bilgus> so that op amp signals an interrupt when those levels differ
09.12.59 #       <_bilgus> according to the schematic
09.13.12 #       <braewoods> which happens when there's input on the remote jack or cradle remote
09.13.18 #       <_bilgus> mioght be REMOTE_INTERNAL
09.13.39 #       <_bilgus> the lines show that they both connect to this op amp
09.13.52 #       <braewoods> makes sense if they're related
09.13.53 #       <_bilgus> but the op amp can't tell you what button was pressed
09.14.09 #       <braewoods> of course not, since they share the same interrupt
09.14.19 #       <_bilgus> so it raises an interrupt and someone has to go read it
09.14.19 #       <braewoods> the rest must be diagnosed from software values
09.14.33 #       <_bilgus> lets see if we can intuit that
09.14.56 #       <braewoods> well let's start by seeing what those 2 inputs are connected to
09.15.03 #       <braewoods>  they also need to be connected to the CPU somehow
09.15.33 #       <braewoods> cradle_remote just goes to a pin labeled as PWM
09.15.38 #       <braewoods> are PWM inputs a thing?
09.15.45 #       <braewoods> i thought it was mainly an output
09.17.04 #       <braewoods> huh
09.17.13 #       <braewoods> remote_jack is connected to the unknown ADC
09.18.16 #       <_bilgus> ADC AIN1
09.18.30 #       <braewoods> that's an odd one
09.18.36 #       <braewoods> when it's disconnected from the dock
09.18.37 #       <_bilgus> that is enough info to do this
09.18.41 #       <braewoods> or connected even
09.18.59 #       <_bilgus> so what tou need to do is set up ADC AIN1 for a read
09.19.13 #       <braewoods> isn't that already happening from the debug menu?
09.19.14 #       <_bilgus> and instead of waiting for interrupt read it in a loop
09.19.22 #       <_bilgus> doubtful
09.19.40 #       <braewoods> adc_read ?
09.19.44 #       <braewoods> is called from debug_pp.c
09.19.50 #       <braewoods> debug-pp.c*
09.20.06 #       <_bilgus> you need to push bits in to set up wait for setup ready (udelay 250 work FN) and trigger it
09.20.19 #       <_bilgus> possibly but you need to set it up
09.20.35 #       <_bilgus> and then toggle the trigger bit
09.21.13 #       <braewoods> so it won't show up in debug then
09.21.45 #       <_bilgus> copy adc AIN0 (the battery)
09.22.05 #       <_bilgus> use its code and tweak to the proper ADC
09.22.43 #       <_bilgus> why would anyone show debug for an unconnected peripheral?
09.23.07 Ctcp    Ignored 2 channel CTCP requests in 1 day and 7 hours at the last flood
09.23.07 #       * braewoods shrugs
09.26.44 #       <_bilgus> laer once you get that then you should be able to use the interrupt or just poll it
09.27.57 #       <braewoods> _bilgus: so how would I "trigger" it?
09.30.27 #       <braewoods> hm
09.30.34 #       <braewoods> first thing i'll try... find the interrupt line
09.30.40 #       <braewoods> that should be pretty harmless
09.32.52 #       <_bilgus> no just load the bits
09.33.03 #       <_bilgus> same way the battery loop does it
09.33.26 #       <braewoods> _bilgus: the debug menu's io ports thing was already triggering reads of ADC1
09.33.34 #       <braewoods> so didn't i already do that?
09.33.40 #       <_bilgus> you just need to send it to the proper register for ADC1 instead of ADC0
09.34.28 #       <braewoods> line 177 of debug-pp.c
09.34.30 #       <_bilgus> is it actually ADC1 and then the question becomes the setup
09.34.40 #       <braewoods> adc_read(ADC_BATTERY), adc_read(ADC_UNKNOWN_1));
09.34.49 #       <_bilgus> so we have an external source
09.35.06 #       <_bilgus> we probably need to set the bits brb
09.35.11 #       <braewoods> ok
09.35.28 #       <braewoods> ADC1 has all the bits turned on (it is 10 bits)
09.35.30 #       <braewoods> so 0x3ff
09.35.37 #       <braewoods> thought it will vary a small amunt
09.35.41 #       <braewoods> regardless of what i do
09.35.48 #       <braewoods> something 0x3fd or something
09.35.52 #       <braewoods> let me confirm that
09.37.18 #       <braewoods> 3ff
09.37.24 #       <braewoods> 3fe
09.37.30 #       <braewoods> 3fd
09.40.32 #       <_bilgus> I don't see adc scan being called
09.40.42 #       <braewoods> it's just using adc_read
09.40.46 #       <_bilgus> you are just reading static data presumably
09.40.53 #       <braewoods> it changes so it is being updated
09.41.07 #       <_bilgus> looking at the source (hopefully the 5020)
09.41.13 #       <braewoods> it is a 5020 chip
09.42.00 #       <braewoods> i just assumed it would be just as good
09.42.09 #       <braewoods> but..
09.42.16 #       <_bilgus> nm it does it in a tick task
09.42.26 #       <_bilgus> still looking for the cfg bits
09.42.58 #       <_bilgus> adc_init
09.43.06 #       <_bilgus> thats where we need to look
09.43.12 #       <braewoods> ADC1 is connected to 2 things according to the schematic
09.43.49 #       <braewoods> REMOTE_JACK... what's the 6,7 mean?
09.44.05 #       <braewoods> and a resistor inline with a 3.3V power supply
09.44.19 #       <_bilgus> yep
09.44.21 #       <_bilgus> ADC_STATUS
09.44.29 #       <_bilgus> play with that register
09.44.35 #       <_bilgus> under unknown1
09.44.49 #       <_bilgus> try 0x20 like the battery try values like the other players
09.45.01 #       <_bilgus> or guess from similar processors
09.45.24 #       <_bilgus> but we need to set the threshold and the source
09.45.47 #       <braewoods> first i need to find input corresponding to the remote events
09.46.05 #       <braewoods> i should get something even if it doesn't make sense initially
09.47.25 #       <_bilgus> guessing it needs a thresh of 2.5v by the 10k resistor holding it high
09.48.29 #       <braewoods> going by the logic in this ADC
09.48.31 #       <_bilgus> so it may also have internal pull up and down we need that disabled but you should still see stuff
09.48.35 #       <braewoods> ADC_STATUS must be 8 bits per channel
09.48.58 #       <braewoods> it shifts over 8 bits for each channel enabled
09.49.02 #       <_bilgus> no they have 0x200000 inthere right?
09.49.10 #       <_bilgus> possible
09.49.18 #       <braewoods> well
09.49.23 #       <braewoods> the first for battery is
09.49.27 #       <braewoods> ADC_STATUS |= 0x20;
09.49.32 #       <braewoods> next one for unknown is
09.49.35 #       <braewoods> ADC_STATUS |= 0x2000;
09.49.50 #       <braewoods> it's setting the...
09.49.53 #       <braewoods> 6th bit?
09.49.57 #       <_bilgus> Id say your assumption is correct
09.49.59 #       <braewoods> then the 14th bit
09.50.16 #       <braewoods> in any case i wonder what the extra bits do
09.50.29 #       <_bilgus> nope I should have pointed you at init
09.51.07 #       <_bilgus> OR we are missing the cfg code
09.51.16 #       <_bilgus> the register rather
09.54.21 #       <braewoods> i'm getting the feeling the remote_jack indicates the presence of the remote
09.54.26 #       <braewoods> from the schematic
09.54.46 #       <braewoods> meaning whether the remote feature is available or not
09.55.05 #       <braewoods> (or connected to a remote compatible dock)
09.58.48 #       <_bilgus> try this
09.59.01 #       <braewoods> ?
09.59.02 #       <_bilgus> #define ADC_CFG          (*(volatile unsigned long*)(0x7000ad0C))
09.59.19 #       <_bilgus> then do that same thing they did of writing to the upper
10.00.17 #       <_bilgus> hold on let me math for a moment
10.00.23 #       <braewoods> Ok
10.01.24 #       <_bilgus> yeah I think thas right
10.01.31 #       <_bilgus> 4+ 16 would b 20
10.01.44 #       <_bilgus> so thats two 8 bytes registers
10.01.50 #       <_bilgus> I think cfg is missing
10.02.09 #       <braewoods> can you give me a patch to try?
10.02.20 #       <braewoods> at least for this first one
10.02.23 #       <_bilgus> I can pastebin it
10.02.32 #       <braewoods> sure
10.02.39 #       <braewoods> if we still are having trouble...
10.03.22 #       <braewoods> i can mail you a set of units, i'm going to end up with 2 complete sets anyway
10.03.35 #       <braewoods> but i want to see if we can find it over the net instead
10.05.55 #       <_bilgus> https://pastebin.com/fayuaEcY
10.06.25 #       <_bilgus> we can given enough screwing around
10.06.42 #       <_bilgus> the next thing to try is to dump the registers from the bootloader
10.06.54 ***     Saving seen data "./dancer.seen"
10.07.11 #       <_bilgus> if we can just get the cfg right
10.07.22 #       <_bilgus> we won't need to
10.08.03 #       <_bilgus> anyways you see the scheme they are using before I did so there is going to be a bit that seys it to the proper level atm its probably saturated
10.08.42 #       <_bilgus> so try setting them all might check what the initial values are too
10.08.46 #       <_bilgus> read that address
10.10.09 #       <_bilgus> anyways I goota head look forward to progress might also try messing with the battery one to see if you can make it read wrong
10.16.41 #       <braewoods> _bilgus: that did change the range of random inputs from the ADC1
10.17.04 #       <braewoods> but nothing else that i can tell
10.39.23 #       <braewoods> maybe i should try disassembling the OF
10.40.09 #       <braewoods> one idea i have
10.40.28 #       <braewoods> the volume controls are simple enough and appear in both GPIO and the remote control
10.40.42 #       <braewoods> so in theory they should lead to the same code that causes the volume to chnage
10.40.52 #       <braewoods> and then backtrace from there
11.02.45 Quit    paulk-leonov (Read error: Connection reset by peer)
11.03.10 Join    paulk-leonov [0] (~paulk-leo@leonov.paulk.fr)
11.47.56 #       <braewoods> _bilgus: the hdd1630 and hdd6330 are very similar schematics wise so I thought i'd compare them
11.48.19 #       <braewoods> _bilgus: pin 17, the cradle remote pin? it's labeled GPIO4 in thhe hdd1630.
11.48.35 #       <braewoods> _bilgus: and both connect to the same labeled pin on the PP cpu
11.48.46 #       <braewoods> no idea what the difference is as of ye
11.48.48 #       <braewoods> yet
11.49.28 #       <braewoods> ADC_AIN1 is connected to remote jack in this one
11.51.00 #       <braewoods> so my theory is...
11.51.14 #       <braewoods> the same method for accessing the remote is the same in both
11.51.16 #       <braewoods> or close enough
12.00.45 #       <braewoods> i suspect AIN1 is used for some kind of wakeup feature?
12.00.50 #       <braewoods> hard to say
12.01.09 #       <braewoods> it appears to basically be a voltage reading of some kind. it's connected to the battery voltage.
12.02.34 #       <braewoods> yep think that's confirmed
12.02.36 #       <braewoods> DC-DC_START#
12.02.46 #       <braewoods> also connected to the power switch
12.06.57 ***     Saving seen data "./dancer.seen"
12.10.19 #       <braewoods> _bilgus: though i'm puzzled... why does the cradle even have an I2C connector?
12.10.35 #       <braewoods> that only makes sense if there's I2C chips inside.
12.10.48 #       <braewoods> otherwise there's no point to having that.
12.11.12 #       <braewoods> the remote only sends an IR signal
12.11.27 #       <braewoods> i wonder if the remote pin is just a red hearing
12.11.37 #       <braewoods> maybe it only exists to trip the interrupt linee
12.12.02 #       <braewoods> if so...
12.12.16 #       <braewoods> the most likely answer is inside the dock
12.12.25 #       <braewoods> what is on the dock side of the connector?
12.12.33 #       <braewoods> the I2C bridge exists for a reason
12.12.35 #       <braewoods> but what?
12.12.52 #       <braewoods> it might have been for something planned but never used
12.13.01 #       <braewoods> or it could be for communicating with an IR cihp
12.13.02 #       <braewoods> chip
12.15.18 #       <braewoods> most likely explaination why it's there
12.15.56 #       <braewoods> my theory, the chip sends a GPIO signal of some kind to let it know there's I2C data to read
12.16.10 #       <braewoods> in any case
12.16.24 #       <braewoods> i will have to disassemble one of these docks to find out
12.18.12 #       <braewoods> i'll do it later
12.18.26 #       <braewoods> disconnected dock from power
12.18.31 #       <braewoods> i'll let it sit awhile
12.18.33 #       <braewoods> tired
12.18.35 #       <braewoods> bbl
12.31.41 #       <_bilgus> braewoods, I'm 99% sure just getting the proper bits on the ADC will make it work
12.32.15 #       <_bilgus> I'd just start flipping a bit at a time in a loop
12.32.58 #       <_bilgus> then pairs
12.34.37 Quit    ArsenArsen (Quit: bye)
12.34.42 #       <braewoods> _bilgus: so you think it'd be a waste of time to open up the cradle?
12.34.59 #       <braewoods> i just don't understand why the cradle has an I2C switch
12.45.06 #       <_bilgus>     /* Enable channel 1 (unknown) */
12.45.06 #       <_bilgus>     DEV_INIT1  &=~30;
12.45.07 #       <_bilgus>     DEV_INIT1  |=~10;
12.45.07 DBUG    Enqueued KICK _bilgus
12.45.07 #       <_bilgus>     //DEV_INIT1  |=~20;
12.45.07 #       <_bilgus>     ADC_ADDR   |= 0x2000000;
12.45.07 ***     Alert Mode level 1
12.45.07 #       <_bilgus>     ADC_STATUS |= 0x2000;
12.45.11 #       <_bilgus>     //ADC_CFG    |= 0x2000; //??
12.45.19 #       <_bilgus> try that the init of the others sets bits back
12.45.30 #       <_bilgus> so get rid of the new cfg one for now
12.46.17 #       <_bilgus> and maybe even |= 0x30
12.47.36 #       <_bilgus> hard to say but if its I2c then you should be able to ground the address line through a resistor and stop the remote
12.48.42 #       <_bilgus> at the very least it shoudl change that adc reading
12.50.24 #       <_bilgus> still that schematic clearly shows the adc
12.51.34 #       <braewoods> doesn't |= ~10 turn on a ton of bits?
12.51.44 #       <_bilgus> sorry no not
12.51.58 #       <_bilgus> | =10 then try |= 20 then |=30
12.52.02 #       <bertrik> braewoods: yes I think so
12.52.06 #       <_bilgus> it should be 00 01 10 11
12.52.31 #       <_bilgus> sorry I missed the tilde
12.52.38 #       <braewoods> it looked strange
12.52.52 #       <_bilgus> I couldnt even see it till I got up on the screen lol
12.55.08 ***     Alert Mode OFF
12.57.37 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13.03.17 #       <braewoods> nadda with that
13.04.07 Join    TheSphinX^ [0] (~briehl@srv001.nosupamu.de)
13.04.27 Join    TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
13.04.45 #       <_bilgus> ugh without a datasheet this is annoting
13.04.53 #       <_bilgus> annoying
13.05.49 #       <_bilgus> ok so a loop to flip all the uppr bits of those registers?
13.06.43 #       <_bilgus> the other thing to do is to dump that address range from the bootloader before it starts setting bits
13.07.15 #       <_bilgus> or disable the init in the bootloader and be first to read on it in the booted FW
13.08.40 #       <_bilgus> I think it was the clip+ we were doing that with or no clip zip?
13.09.47 #       <_bilgus> bu ttere we load the OF init so this might be harder for you
13.10.33 #       <_bilgus> more like run the OF and reset the line and hope it sticks
13.10.42 #       <braewoods> _bilgus: h320.
13.11.04 #       <_bilgus> ?
13.11.16 #       <braewoods> "I think it was the clip+ we were doing that with or no clip zip?"
13.11.29 #       <_bilgus> no long time ago
13.11.32 #       <braewoods> oh
13.11.45 #       <_bilgus> dumping the cfg bits that the OF set
13.12.42 #       <braewoods> wait a minute... this makes no sense
13.13.01 #       <braewoods> i think i find a bug in ADC
13.13.28 #       <_bilgus> in our code? the whole ranging thing?
13.13.55 #       <braewoods> https://github.com/Rockbox/rockbox/blob/master/firmware/target/arm/pp/adc-pp5020.c#L149
13.14.00 #       <braewoods> ~30
13.14.06 #       <braewoods> notice there's no hexadecimal PREFIX
13.14.20 #       <braewoods> it's 30 base 10
13.14.25 #       <braewoods> yet the others use hexadecimal
13.14.28 #       <braewoods> something is amiss here
13.14.56 #       <braewoods> i'll try changing that
13.15.37 #       <_bilgus> oh nice catch
13.15.54 #       <braewoods> i can't imagine that's not a mistake
13.16.08 #       <braewoods> since everything else is using hexadecimal
13.16.18 #       <_bilgus> itd set most of the bits in the lower register though?
13.16.47 #       <_bilgus> so maybe its unintended sideffect is infact setting bits for ADC0 to work
13.17.09 #       <braewoods> no idea
13.17.29 #       <_bilgus> you will shortly
13.17.33 #       <braewoods> actually &= can't turn bits on
13.17.42 #       <braewoods> only off or leave them as is
13.18.41 #       <_bilgus> yep still its a mask
13.19.39 #       <_bilgus> its wiping bit0 out so that first cfg stays the ame
13.19.45 #       <_bilgus> same the 0x3
13.19.56 #       <_bilgus> not(0x3)
13.20.16 #       <_bilgus> lol
13.21.02 #       <braewoods> seems to behave the same
13.21.51 #       <_bilgus> well now try oring 0x10 0x20 0x30
13.22.11 #       <braewoods> would it be unwise to do them all at once?
13.22.42 #       <braewoods> 0x60
13.22.51 #       <braewoods> not wait
13.22.53 #       <braewoods> no wait
13.22.55 #       <braewoods> that's 0xf0
13.22.57 #       <braewoods> LOL
13.23.07 #       <_bilgus> its not gonna blow up
13.23.14 #       <_bilgus> it just won't work
13.23.50 #       <_bilgus> but you might wanna get rid of that ranging thing
13.24.45 #       <braewoods> ranging thing?
13.25.13 #       <_bilgus>     /* ADC values read low if PLL is enabled */
13.25.26 Quit    lebellium (Ping timeout: 240 seconds)
13.25.27 Join    lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13.25.52 #       <braewoods> that doesn't apply to this unit
13.25.55 #       <braewoods> check the macro
13.26.05 #       <braewoods> Or?
13.26.12 #       <braewoods> it's gated by a macro
13.26.27 #       <_bilgus> oh I see the !
13.26.43 #       <_bilgus> nm then I figured that might cover up high readings
13.28.07 Join    ArsenArsen [0] (~arsen@managarm/dev/ArsenArsen)
13.29.21 #       <braewoods> this ADC is high under normal circumstances
13.29.36 #       <braewoods> for it to give anything meaningful it would have to dip low and do consistently
13.30.06 #       <braewoods> instead it seems to be tied to the fluctations in the power supply
13.30.40 #       <_bilgus> ok so 0x1000000 is 24 bits
13.30.52 #       <_bilgus> there are 3 longs for each adc
13.30.57 #       <_bilgus> in theory
13.32.45 #       <_bilgus> they step everything by 4 though so that would be 6 shorts
13.34.46 #       <_bilgus> but since it has 0x80000000 I'd say we assume the former
13.41.58 #       <_bilgus> something is a bit off here
13.46.56 #       <braewoods> _bilgus: ya think?
13.46.59 #       <_bilgus> if 2c is the init and they put 0x8000 0000 at ad2c then that would make it 48 + 52 bytes
13.47.13 #       <_bilgus> 48 + 8 = 52 bytes
13.47.55 #       <braewoods> it was just a thought since i don't know what else it would be used fr
13.48.11 #       <braewoods> if i2c is involved i would have to find the address and datasheet
13.48.30 #       <braewoods> one way to find out
13.48.41 #       <braewoods> see if there's any unfamiliar i2c addresses in the OF
13.50.23 #       <braewoods> i've never heard of an i2c irda chip but they may exist
13.50.30 #       <braewoods> the dock
13.50.41 #       <braewoods> the dock's datasheet refers to it as IRDA
13.50.48 #       <braewoods> so
13.50.59 #       <braewoods> i'm guessing it has to have an IRDA chip in the dock
13.51.07 #       <braewoods> but how it sends the data is still a mystery
13.51.16 #       <braewoods> we still haven't uncovered the entry point for it
13.51.35 #       <braewoods> i think some hardware level analysis is in order
13.51.47 #       <braewoods> finding out what's in the dock would probably help
13.52.28 #       <braewoods> i mean IRDA is a bit involved so it has to have something to translate it to a different kind of signal
13.52.44 #       <braewoods> unless...
13.59.12 #       <braewoods> _bilgus: what convinces you that AIN1 has the remote control bits?
13.59.22 #       <braewoods> it appears to be tied to the remote jack
13.59.32 #       <braewoods> though not sure what that does exactly other than being tied to power on
14.07.00 ***     Saving seen data "./dancer.seen"
14.09.48 #       <_bilgus> the schematics pull up resistor
14.10.04 #       <_bilgus> hope thi shows properly
14.10.10 #       <_bilgus>  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
14.10.10 #       <_bilgus> |__ADDRESS__|________________STATUS_____________________________________________________________|___DATA0___|___DATA1___|________INIT___________|
14.10.15 #       <_bilgus> yes!
14.10.37 #       <braewoods> ...?
14.10.41 #       <braewoods> so what's you find?
14.10.58 #       <_bilgus> well look at status versus what we set to it
14.11.22 #       <braewoods> these are...
14.11.27 #       <braewoods> each 0 is 4 bits?
14.11.40 #       <braewoods> or?
14.11.44 #       <braewoods> 1 bit
14.11.52 #       <braewoods> this is kinda confusing as it is shown on irc
14.12.27 #       <_bilgus> 80000000 says its 4 bytes
14.12.40 #       <_bilgus> yes each 0 is a byte
14.12.46 #       <_bilgus> no 00 is a byte
14.12.55 #       <_bilgus> laid out like in a hex editor
14.13.25 #       <_bilgus> sorry lets regroup
14.13.47 #       <_bilgus> 32 bits or 8 bytes
14.13.49 #       <braewoods> so apparently we only read the frst 4 bytes
14.13.53 #       <braewoods> for status
14.14.13 #       <braewoods> the reminaing 12 are unused
14.14.30 #       <_bilgus> point being that there is a missing range inthere
14.14.53 #       <_bilgus> 20 extra bits
14.16.42 #       <_bilgus> you should set up a loop to fill from that cfg address to the base of data 0
14.17.14 #       <_bilgus> and basically go through the init for that adc
14.17.19 #       <_bilgus> each time
14.17.25 #       <braewoods> so set them all to 1s
14.17.55 #       <_bilgus> or all zero and count up
14.18.35 #       <braewoods> there's also 8 bytes between data and init
14.18.41 #       <_bilgus> so in your loop all you need to do is write if adc < ad0 or w/e you get and let it do the work
14.18.42 Join    Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-110d-8f45-d887-ee78.res6.spectrum.com)
14.18.42 #       <braewoods> yet we only use the first 4
14.19.10 #       <_bilgus> maybe its 12 each chunk
14.19.43 #       <braewoods> could be unused padding or somethin
14.20.10 #       <_bilgus> possibly but generally adcs have setup bits and source compare bits
14.20.10 #       <braewoods> i'm going to take a nap now so tired lol
14.20.22 #       <_bilgus> ciao
14.20.34 #       <braewoods> _bilgus: it would help if we had an actual datasheet for the cpu
14.20.37 #       <braewoods> ._.
14.20.41 #       <_bilgus> ALWAYS!
14.20.46 #       <_bilgus> lol
14.20.59 #       <_bilgus> even a similar one but ??
14.21.01 #       <braewoods> can you believe no PP datasheets leaked even though they stopp making chips?
14.21.13 #       <_bilgus> yes
14.21.19 #       <braewoods> lol
14.23.19 #       <_bilgus> ^ that was supposed to be 0x80000000 = 8 bytes 32 bitsd
14.23.39 #       <_bilgus> so no one thinks I can count in binary lol
14.27.43 #       <speachy> given who provided most of PP's revenue, and who ultimately acquired them, yes...
14.34.51 #       <_bilgus> braewoods, https://pastebin.com/nA1LjinE
14.34.59 #       <_bilgus> that should get you started
14.35.18 #       <_bilgus> you might not be able to do the splash there either
14.35.31 #       <_bilgus> depending on when it does its first reads
14.36.08 #       <_bilgus> so we just go throught and count up and hopefully change those status bits till it changes the adc value
14.36.12 #       <_bilgus> cfg
14.36.15 #       <_bilgus> not status
14.37.32 #       <_bilgus> if that fails we might need to reinit the adc or somethign or maybe block out the 64 bytes I think it encompasses and start randomly flipping bits on and off till it does
15.08.24 Quit    TheLemonMan (Quit: "It's now safe to turn off your computer.")
15.28.03 Quit    Saijin_Naib (Ping timeout: 258 seconds)
15.33.10 #       <speachy> dconrad:  the original X3 has about a 4.3Vpp.  A bit on the hot side still
15.40.10 Join    ats_ [0] (~ats@cartman.offog.org)
15.41.19 Quit    atsampson (Ping timeout: 260 seconds)
15.55.36 #       <fs-bluebot> Build Server message: New build round started. Revision cd64aa2b10, 298 builds, 9 clients.
16.06.03 #       <speachy> I'll get to the X3ii eventually.  :)
16.07.04 ***     Saving seen data "./dancer.seen"
16.07.08 Join    Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-14ba-5001-4fff-7f89.res6.spectrum.com)
16.07.16 #       <fs-bluebot> Build Server message: Build round completed after 700 seconds.
16.07.18 #       <fs-bluebot> Build Server message: Revision cd64aa2b10 result: All green
17.21.32 Join    b0hoon [0] (57cd8bb1@87-205-139-177.adsl.inetia.pl)
17.25.06 #       <b0hoon> braewoods: Hi. Do you own the YH-925 by accident?
17.32.30 #       <b0hoon> braewoods: I'm asking because of my radio patch.
17.37.02 Quit    ZincAlloy (Quit: Leaving.)
17.38.08 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:793b:87ec:38af:f44a)
17.53.12 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
17.57.35 Quit    ats_ (Ping timeout: 260 seconds)
18.00.00 Join    atsampson [0] (~ats@cartman.offog.org)
18.07.05 ***     Saving seen data "./dancer.seen"
18.13.05 Quit    lebellium_ (Quit: Leaving)
18.13.28 #       <braewoods> b0hoon: i tried to make one work but i never did get it to work.
18.13.34 #       <braewoods> i no longer have it.
18.13.45 #       <braewoods> it wouldn't really boot RB or anything
18.13.55 #       <braewoods> i blame that fickle HDD ribbon cable mysel
18.17.43 #       <braewoods> practically nothing to keep it from popping out whenever it felt like it
18.21.33 #       <b0hoon> Oh... It's a pity. Do you know if it had a radio module soldered in?
18.22.32 #       <b0hoon> I have a patch for the radio, but it's not tested for DAP's without the module.
18.26.22 #       <b0hoon> braewoods: Regarding the scrollstrip for the HDD6330, you may want to look at this: https://gerrit.rockbox.org/r/c/rockbox/+/786.
18.31.11 Quit    pamaury (Ping timeout: 260 seconds)
18.36.06 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
18.37.54 #       <b0hoon> braewoods: and yeah this ribbon cable in this player is very fishy. I have an adapter for CF card inserted, and it's connected for the word.
18.38.58 #       <braewoods> b0hoon: pretty sure it didn't.
18.39.48 #       <braewoods> if you can test your radio patch we can probably enable it as a build option for that target
18.40.02 #       <braewoods> it won't be an official build and will require people to build it themselves but it will be in tree
18.41.54 #       <braewoods> b0hoon: the funny thing is if they opted for a regular ZIF cable that would have solved most of the issues with it disconnecting
18.42.10 #       <braewoods> because you can lock the connector down
18.42.32 #       <b0hoon> it's tested for DAP's with the radio, but it's not a good idea to aply it when we don't know if it can detect lack of it, imo there is no sense to do that
18.43.01 #       <braewoods> b0hoon: are you familiar with the H120 rtc mod?
18.43.04 #       <b0hoon> yep, i don't know who designed this thing
18.43.08 #       <braewoods> that's the kind of thing i was thinking about.
18.43.13 #       <braewoods> source wise
18.43.34 #       <braewoods> it's a build option you have to choose for the H120 to even use it
18.44.01 #       <braewoods> that would be the best option until a way to configure it at runtime can be found.
18.44.19 #       <braewoods> you can probably pickup a yh-925 on ebay for not much
18.44.30 #       <b0hoon> no,  sorry i never had the h120
18.44.31 #       <braewoods> chances are it won't have the chip
18.44.42 #       <braewoods> i read about it in passing
18.45.29 #       <braewoods> see tools/configure
18.45.52 #       <braewoods> have_rtc_alarm
18.45.57 #       <braewoods> that's where it is enabled
18.46.14 #       <b0hoon> yeah but the shipping is expensive, twice the price of the DAP for me
18.46.22 #       <braewoods> oh, you live somewhere remote
18.46.25 #       <braewoods> ok
18.47.00 #       <b0hoon> yes, but you have to solder a RTC chip additionally
18.47.06 #       <braewoods> indeed
18.47.11 #       <braewoods> but i'm just saying
18.47.16 #       <braewoods> it's similar to this.
18.47.21 #       <braewoods> some units have it a lot don't
18.47.21 #       <b0hoon> there is something on the wiki about it
18.47.43 #       <b0hoon> didn't know that
18.47.54 #       <braewoods> if you want to add your patch to current GIT
18.47.57 #       <braewoods> that's a good way to do it for now
18.48.14 #       <braewoods> conditionally include it for custom builds that request it
18.48.47 #       <braewoods> then maybe you can find a way to do it better at runtime so it can be enabled for all units
18.49.34 #       <braewoods> i think the main reason it never got implemented was lack of any indication of which ones had FM radio and which did not.
18.49.43 #       <braewoods> it made getting testing units harder
18.50.41 Quit    pamaury (Ping timeout: 240 seconds)
18.50.53 #       <b0hoon> i'm not convinced without a full test, well. this patch implements detection. Basically you can see it in the OF
18.51.08 #       <braewoods> I see.
18.51.16 #       <braewoods> ask on the forums. I think some people own the unit.
18.51.32 #       <braewoods> otherwise one of the regulars here might have one.
18.51.35 Join    dconrad [0] (~dconrad@208.38.228.17)
18.52.06 #       <b0hoon> I think i did it years ago but the main problem is these DAP's are dinosaurs
18.52.36 #       <braewoods> aren't they all
18.52.40 Quit    ac_laptop (Ping timeout: 252 seconds)
18.52.55 #       <braewoods> the bleeding edge ports are still too immature to be all that useful
18.53.08 #       <braewoods> i think the most feature complete port is the iriver h120
18.53.10 #       <b0hoon> yeah PP is relict
18.53.51 #       <braewoods> i did a major favor to the users of the H100 and H300 series by taking on some risks to update the bootloader
18.53.57 #       <braewoods> it fixed some really nasty issues
18.54.29 #       <braewoods> mostly CF card compatibility issues
18.54.36 #       <b0hoon> i saw that, amazing job!
18.55.00 #       <braewoods> i also do an overhaul of the H300 bootloader so it could leverage the new H100 features
18.55.04 #       <braewoods> like boot from ROM
18.55.27 #       <braewoods> most of the features for that were already implemented in the main firmware
18.55.39 #       <braewoods> the eeprom settings store at least was 100% complete that i could tell
18.55.49 #       <braewoods> but they never finished the bootloader redux to use it
18.56.13 #       <braewoods> probably because they couldn't figure out what broke the bootloader
18.56.37 #       <braewoods> I found a trick to allow me to flash bad bootloaders until I finally found the culprit
18.56.57 #       <braewoods> turns out the bootloader's emergency boot into OF mode still worked
18.57.09 #       <braewoods> so I used the OF to restore the last known good bootloader
18.57.18 #       <braewoods> lather rinse repeat
18.57.28 #       <braewoods> i traced it to and LCD optimization that broke the bootloader
18.58.17 #       <bertrik> wow
18.59.43 #       <braewoods> i also had to totally refactor the iriver_flash plugin in order to allow flashing stuff from the h300
19.00.04 #       <braewoods> i broke it down and rebuilt it based on the original but removed bits that were no longer relevant
19.00.25 #       <braewoods> since i had to understand it in order to extend its support
19.00.51 #       <braewoods> but now both units can go OF free if they want to
19.01.02 #       <braewoods> the OF is useless anyway if you perform the CF mod
19.01.12 #       <braewoods> there's no known way to make it work with CF cards
19.01.31 #       <braewoods> i tried using one that claimed to be a fixed disk IDE thing
19.01.38 #       <braewoods> and still didn't work so
19.01.44 #       <braewoods> i dunno what makes the OF reject CF cards
19.01.51 #       <braewoods> I just thought maybe it was being too picky
19.02.03 #       <braewoods> and could work with CF cards that fully emulate a HDD
19.08.39 #       <braewoods> bertrik: if you're bored, i added code to the disk info in debug menu that reports the 3 bits related to this.
19.08.48 #       <braewoods> removeable, fixed, and CF compatible bits
19.09.03 #       <braewoods> only for ATA targets though but i thought it might be helpful for CF modders
19.09.17 #       <braewoods> in the event some obscure port cares about these bit
19.09.19 #       <braewoods> we sure don't
19.09.55 #       <braewoods> but CF cards report different values even in true IDE mode
19.10.10 #       <braewoods> i had some surprisingly reported fixed disk when i didn't expect it
19.13.49 #       <braewoods> _bilgus: should we patch the code in the ADC for PP to be 0x30 instead of 30? it's clearly not intended that way
19.15.45 Quit    Saijin_Naib (Ping timeout: 258 seconds)
19.30.17 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
19.30.42 #       <braewoods> ugh anyway when i get a chance i need to open up my dock so i can find out what hardware is inside
19.30.51 #       <braewoods> might shed some light on what I need to do to get remotes to work
19.33.57 Join    chris_s [0] (5fdf48b5@ip-95-223-72-181.hsi16.unitymediagroup.de)
19.36.14 Quit    chris_s (Client Quit)
19.37.10 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
19.44.27 Quit    pamaury (Ping timeout: 260 seconds)
19.49.04 #       <b0hoon> i have a dock station for HHD's but it's simple passthrough interface with the line out/in and some ir diode connected
19.50.39 #       <b0hoon> from what i recall hdd6330 has an hardware issue with the i2c interface, so it won't work anyway on dock
19.51.23 #       <b0hoon> it's more or less described on the wiki
19.52.34 #       <b0hoon> but you can try to play with it of course
19.57.21 #       <braewoods> b0hoon: it does work? i can use the remote in the OF
19.57.23 #       <braewoods> and such
19.57.54 #       <braewoods> b0hoon: and, IR diode?
19.58.04 #       <braewoods> i thought it was some IRDA chip
19.58.09 #       <b0hoon> by remote you mean ir remote?
19.58.12 #       <braewoods> yes
19.59.09 #       <b0hoon> yes that may work, probably this is the Cradle_REMOTE pin from the service manual, the OF has some code to interpret it iirc
19.59.37 #       <braewoods> i know
19.59.49 #       <braewoods> i wanted to disassemble my dock to see how it's generating said signal
19.59.58 #       <braewoods> i thought it might give me some clue of where to look
20.00.19 #       <braewoods> i'm starting to think though the cradle remote pin just signals an interrupt line
20.00.47 #       <b0hoon> i'm afraid you will have to disassemble the OF
20.00.47 #       <braewoods> but there's 5 possible inputs from the key pad
20.01.18 #       <braewoods> so there's nothing useful in the dock?
20.01.31 #       <braewoods> is that what you're telling me?
20.01.33 #       <braewoods> for the hdd gogears?
20.01.55 #       <braewoods> so then why does the cradle have an I2C bus switch?
20.02.02 #       <braewoods> it doesn't make sense to me
20.02.18 #       <b0hoon> yes
20.02.37 #       <b0hoon> i may be wrong but the i2c is for something else
20.02.51 #       <braewoods> it's not specified so i can't be sure
20.02.59 #       <fs-bluebot> Build Server message: New build round started. Revision 13dbcab6c0, 298 builds, 10 clients.
20.03.12 #       <braewoods> only logical reason is they expected to interface with external I2C chips
20.03.16 #       <b0hoon> i can dissaemble my dock again and tell you what's inside if you want
20.03.33 #       <braewoods> b0hoon: that would help. it's the one with the video out, audio out, dock connector, ?
20.03.48 #       <braewoods> i also have another version that came with my HDD1635s
20.03.53 #       <b0hoon> wait a sec i don't remember really :D
20.04.06 #       <braewoods> it should have 3 ports on the back
20.04.12 #       <braewoods> including the dock connector in the middle
20.04.14 #       <braewoods> err
20.04.16 #       <braewoods> not including
20.04.33 #       <braewoods> i also noticed the dock consumes 0 power when connected to DC power in the back
20.04.48 #       <braewoods> so it doesn't get its power from that
20.05.00 #       <braewoods> must get any power from the docked unit
20.05.37 #       <braewoods> either that or the dock's power consumption is less than 0.01A
20.05.46 #       <braewoods> in which case it probably wouldn't register
20.07.08 ***     Saving seen data "./dancer.seen"
20.07.39 #       <b0hoon> god...sorry i can't find it.
20.07.54 #       <braewoods> b0hoon: it's ok
20.08.22 #       <braewoods> but i need to know for myself how the cradle works to have any hope of knowing where it could possibly be sending the signal
20.08.33 #       <braewoods> the schematic doesn't tell me much
20.08.57 #       <braewoods> you know the pin 17 is labeled differently in both HDD schemaics
20.09.03 #       <braewoods> cradle remote for one
20.09.06 #       <braewoods> gpio4 for another
20.09.08 #       <b0hoon> but i'm 99% sure it had nothing but one resistor some ir diode and the rest was just connections of connectors
20.09.09 #       <braewoods> both connect to same pin
20.09.25 #       <braewoods> so you think it just sends a pulse signal?
20.09.30 #       <braewoods> that the diode sends?
20.09.38 #       <b0hoon> maybe this was a cheap fake
20.09.45 #       <braewoods> i see
20.09.49 #       <braewoods> well i'll see what i dig up
20.09.56 #       <braewoods> i have originals
20.10.02 #       <braewoods> that i can tell anyway
20.10.10 #       <braewoods> one came with the gogear i bought
20.10.18 #       <braewoods> the other is new old stock i haven't received yet
20.10.24 #       <braewoods> b0hoon: do you remember how it opens?
20.10.29 #       <braewoods> just need to gently pry it out from above?
20.10.34 #       <b0hoon> yes, i think it send a pulse signal
20.10.41 #       <b0hoon> sent
20.10.45 #       <braewoods> that would explain the PWM
20.10.55 #       <braewoods> but
20.11.01 #       <braewoods> it's connected to a pin i don't know how to read
20.11.45 #       <b0hoon> there were two screws i think from the bottom
20.12.07 #       <b0hoon> that's why you will have to dig into OF disasm
20.12.10 #       <b0hoon> :)
20.12.28 #       <braewoods> any tips? all i got was gibberish
20.12.48 #       <braewoods> lol
20.14.31 #       <b0hoon> well no real tips, OF is written with some high level language for sure, 99% c++, so it's really even hard to find what you are looking for
20.15.25 #       <b0hoon> IDA and fire...
20.16.33 #       <fs-bluebot> Build Server message: Build round completed after 814 seconds.
20.16.37 #       <fs-bluebot> Build Server message: Revision 13dbcab6c0 result: All green
20.23.29 #       <braewoods> that's expensive
20.23.31 #       <braewoods> IDA
20.23.42 #       <speachy> go for ghidra
20.24.07 #       <speachy> can't comment on the relative feature set vs IDA but I've put to good use over the past couple of years
20.24.09 #       <b0hoon> i can send you my ida file from like 5 years ago, maybe you can find something useful in it
20.24.41 #       <speachy> https://ghidra-sre.org/
20.25.51 #       <braewoods> speachy: if there's a PWM input on a PP how might one read it?
20.26.02 #       <braewoods> it might help me narrow down what i'm looking for
20.26.07 #       <braewoods> the OF is like 7MB
20.26.12 #       <braewoods> that's a fair amount of data to go through
20.26.36 #       <speachy> I guess it depends on what sort of input wizardry the PP has to offer on those pins
20.26.36 #       <braewoods> but that's what the schematic appears to be saying
20.26.45 #       <braewoods> which we have no datasheet for
20.27.00 #       <braewoods> so there's no way to know what the PWM pin does
20.27.14 #       <speachy> the naive approach is to use the input to trigger an interrupt on an edge
20.27.38 #       <speachy> (well, really naive approach is to tightly poll the pin to see what's going on...)
20.27.41 #       <braewoods> speachy: that seems to be what they do here. the remote control pin is connected to the remote_int line
20.27.56 #       <braewoods> you want to read the schematic too?
20.28.08 #       <braewoods> https://www.rockbox.org/wiki/pub/Main/GoGearHDD6330/Philips_HDD6320_HDD6330_Service_Manual.pdf
20.28.11 #       <braewoods> back of the manual
20.28.30 #       <speachy> looking at the PWM signal with a logic analyzer would be a good idea
20.29.00 #       <braewoods> i would need to be able to poke the pins...
20.29.08 #       <braewoods> which means i'd probably need a unit open to do that
20.29.20 #       <speachy> c'est la vie
20.29.55 #       <braewoods> that still won't tell me how to read it from software
20.29.59 #       <braewoods> but
20.30.09 #       <braewoods> given that it is connected to PWM
20.30.13 #       <braewoods> it's probably a pulse
20.30.16 #       <speachy> one trick I've used in the past is to look for a UI string in the firmware dump, and backtrace from that -- find referencs to that string, and work backwards until you find the code that triggers it.
20.30.30 #       <braewoods> it probably uses ASCII
20.30.33 #       <speachy> there's not much point in worrying how to read it until you know what "it" is
20.30.54 #       <braewoods> the unit has two PWM lines
20.30.58 #       <speachy> it might be a single pulse.  it might be a timed sequence.  who knows...
20.31.01 #       <braewoods> one is already in use to control the LCD backlight
20.31.24 #       <speachy> PWM output, sure.  but _input_ is another matter.
20.31.28 #       <b0hoon> braewoods: yes, that's a lot of code , i have some functions marked as dock code in it, so if you want let me know
20.31.40 #       <braewoods> can ghidra even use it?
20.31.44 #       <braewoods> o.O
20.31.57 #       <speachy> often one ends up using decidated hw timer peripherals to measure the pulses
20.31.57 #       <b0hoon> don't know :O
20.32.19 #       <speachy> if the image is compessed/encrypyed, no.
20.32.32 #       <braewoods> right, i need to decrypt the raw binary first
20.32.35 #       <braewoods> i already figured out how to do that
20.32.43 #       <braewoods> assuming mi4code is the right tool
20.32.51 #       <braewoods> i found the key in our existing rockbox code
20.33.38 #       <speachy> but if it's a straight dump of what the CPU would be reading, then sure, ghidra can work with it.  you'll need to tell it it's a raw ARMv4T (little endian) image, maybe point at the enry point (reset vector is one of the first words in the image; #2 maybe?) to get things started
20.34.02 #       <speachy> but this sort of stuff has a _very_ steep learning curve.
20.34.32 #       <speachy> even with IDA or ghidra one has to know a lot about the low-level architecture
20.35.42 #       <speachy> but with either you can look for static accesses to certain address ranges (eg gpio control/status) and work back from there..
20.38.41 #       <b0hoon> braewoods: the code is so messed up by the compiler that you will probably walk for a beer
20.39.18 #       <b0hoon> ;)
20.41.16 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
20.42.23 #       <braewoods> speachy: what would you recommend if i wanted to check the signals?
20.42.56 #       <braewoods> i could disassembly the cradle and see what it does on the pins
20.43.12 #       <braewoods> probably easiest way to access the raw pins
20.44.14 #       <speachy> I mean, there are cheapie logic analyzers to be had
20.45.18 #       <braewoods> ok..
20.46.54 #       <b0hoon> yeah logic analyzer would be the simplest solution.
20.47.39 #       <braewoods> i'll look into it later, i think i'm going to have to see what it's doing
20.48.02 #       <braewoods> but yea, I2C would be overkill for something this simple
20.52.00 #       <speachy> but yeah, you're at the point where you're going to need more specialized tools
20.54.49 #       <braewoods> i'll looked into it when i get paid again
20.54.52 #       <braewoods> i'm tapped out for now
20.55.02 #       <braewoods> until then i see no harm in looking through the OF
20.55.45 #       <braewoods> objdump seems to do a terrible job for disassembling raw binary
20.55.47 #       <braewoods> though
20.57.22 #       <braewoods> i tried that first
20.57.22 #       <braewoods> speachy: i'll try what bilgus said if my other efforts don't go anywhere
20.57.22 #       <braewoods> pocket oscilloscope
20.57.22 DBUG    Enqueued KICK braewoods
20.57.22 #       <braewoods> but hm
20.57.22 #       <braewoods> to decode a PWM signal...
20.57.24 #       <braewoods> yea... the ADC may be involved
20.57.28 #       <braewoods> but in what way?
20.57.39 #       <braewoods> a pulse is an analog signal
20.57.57 Quit    daswf852 (Quit: Ping timeout (120 seconds))
20.58.27 #       <braewoods> just didn't seem likely to me originally since the ADC isn't even connected other than to the remote jack line
20.58.40 #       <braewoods> it's constantly pulled high according to the ADC readout
20.58.43 #       <braewoods> and schematic
20.59.08 #       <braewoods> but the ADC1 line has no known use otherwise so
20.59.19 #       <braewoods> there should be no harm in tinkering with it
20.59.24 #       <braewoods> i'll investigate ADC first
20.59.32 #       <braewoods> using the known one we use for battery reding
20.59.40 #       <braewoods> that one is super simple so it should be easy to find in the OF
20.59.59 #       <speachy> objdump does disam just fine, but what it won't do is give a stripped raw binary structure
21.00.53 #       <b0hoon> bear in mind that this schematic may be not even the production one, this is leak
21.01.14 #       <braewoods> indeed but it's better than nothing
21.01.24 #       <b0hoon> sure
21.02.23 #       <braewoods> i also plan to look into supporting TV out in rockbox, basically mirroring the LCD like we do for remotes
21.02.35 #       <braewoods> i have 2 different ports that support it
21.02.39 #       <braewoods> not ipods even
21.02.40 #       <speachy> it's also highly doubtable that Philips has this information any more
21.02.55 #       <braewoods> and even if they did they wouldn't help me i'm sure
21.03.14 #       <braewoods> so i'm not even going to ask
21.03.26 #       <speachy> assuming it was actually directly made by a division of Philips instead of just licensing the brand
21.03.35 #       <speachy> (though I suppose given the age it progbably was)
21.03.49 #       <speachy> (in any case, that division hasn't existed for a _long_ time)
21.04.00 #       <b0hoon> i've asked for it once.. or twice...
21.04.24 #       <braewoods> we generally can't expect help from the people we're trying to reverse engineer
21.04.31 #       <braewoods> lol
21.06.27 #       <b0hoon> i've asked NVIDIA for documentation, nicely ... I've received some response even. NOPE
21.06.42 #       <speachy> (I actually work for Philips now.  So I can't really say all that much one way or another.  But if anyone has a name I can use as a starting point I can do some internal inquiries)
21.07.12 #       <speachy> nVidia is infamously awful when it comes to documentation.
21.08.52 #       <braewoods> speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/3316/
21.08.56 #       <braewoods> can you approve this?
21.09.04 #       <braewoods> i found a logic error or one that looks awfully like one
21.09.44 #       <braewoods> i found it earlier when bilgus was trying to help me
21.09.51 #       <speachy> braewoods: 10d might actually be correct
21.10.11 #       <braewoods> really? why does the rest of it use 0x?
21.10.30 #       <speachy> ok, looking at the other context, I see that
21.10.44 #       <speachy> (I've seen a lot of wierd crap over the years...)
21.10.50 #       <speachy> (I've been responsible for some of it)
21.10.52 #       <braewoods> i looked at the pattern of the surrounding code
21.10.57 #       <braewoods> so i assumed it was a mistake
21.11.12 #       <braewoods> 0x3
21.11.14 #       <braewoods> then 30
21.11.18 #       <braewoods> then 0x300
21.11.20 #       <braewoods> 0x3000
21.11.22 #       <braewoods> so
21.11.25 #       <braewoods> yea
21.11.28 #       <braewoods> i assume it works the same
21.11.30 #       <speachy> so, has this been smoke tested to ensure it doesn't cause a regression?
21.11.43 #       <braewoods> well i tested it with my hdd6330
21.11.52 #       <braewoods> but i honestly can't test them all
21.12.50 #       <speachy> given that it's unknown it's possible it could trigger a sideeffect somewhere else, etc etc.. but you've shown that it doesn't immediately set your device on fire so that's a good sign.
21.13.06 #       <braewoods> but if it causes problems it'd probably be with the battery stuff
21.13.16 #       <fs-bluebot> Build Server message: New build round started. Revision 448f98d9c0, 298 builds, 10 clients.
21.13.24 #       <braewoods> 30 is...
21.13.38 #       <braewoods> 0b11110
21.13.46 #       <braewoods> 0x1e
21.13.47 #       <speachy> 0x1e
21.14.00 #       <braewoods> it overlaps mostly with the battery
21.14.03 #       <braewoods> and partialy with itself
21.14.17 #       <speachy> coudl explain some of the wonky battery stuff reported.
21.14.36 #       <speachy> (that's never really reproducible on known-sane hardware...)
21.14.56 #       <braewoods> old batteries could cause weird issues too
21.15.02 #       <braewoods> i've seen it a few times
21.15.41 #       <braewoods> but if it does cause issues we'll hear complaints about battery reporting
21.15.51 #       <braewoods> but that's the only thing i can see happening
21.16.03 #       <braewoods> the old bit pattern only overlapped with the battery low bits
21.20.41 Quit    ZincAlloy (Quit: Leaving.)
21.21.20 #       <speachy> I'm more concerned with something different; eg the ADC is suddently "working" and triggering a code path that clearly hasn't ever actually worked before
21.21.55 #       <braewoods> oh
21.21.59 #       <braewoods> i see
21.22.07 #       <braewoods> i'll test it on my H10 once I get it back from bilgus
21.22.34 #       <speachy> "correct" != "works"
21.22.42 #       <braewoods> lmao
21.22.50 #       <braewoods> i know, mostly due to hardware bugs
21.23.07 #       <braewoods> but we should try the correct way whenever possible
21.23.10 #       <speachy> or a decade's worth of incorrect assumptions.
21.23.52 #       <braewoods> in all honestly it looked like it should be this way. if they really meant to use the base 10 bit pattern they shoulda used a different one
21.24.32 #       <speachy> I agree
21.24.59 Part    b0hoon
21.25.02 #       <braewoods> our PP ports work quite well in spite of having no data sheets for the main cpu
21.25.09 #       <fs-bluebot> Build Server message: Build round completed after 713 seconds.
21.25.11 #       <fs-bluebot> Build Server message: Revision 448f98d9c0 result: All green
21.25.29 #       <braewoods> speachy: is there a reason the mi4code utility isn't in our git tree?
21.25.44 #       <braewoods> i think we should add it to tools so we don't lose it
21.25.54 #       <braewoods> would you accept it if I added it?
21.26.19 #       <braewoods> we already have part of it in our code anyway
21.26.22 #       <braewoods> this is just the complete tool
21.26.28 #       <speachy> license?
21.27.07 #       <braewoods> just a copyright notice in the source file...
21.27.09 #       <braewoods> let me look elsewhere
21.27.25 #       <braewoods> no license given
21.27.39 #       <speachy> which means we can't accept it.
21.27.46 #       <braewoods> https://daniel.haxx.se/sansa/mi4code.c
21.27.50 #       <braewoods> fair enough
21.27.55 #       <braewoods> I guess i can just keep a private copy
21.29.57 #       <speachy> bagder might be able to provide more info on this, but it's ultimately in MrH's hands.
21.30.24 #       <braewoods> is that Daniel Stenberg?
21.30.29 #       <braewoods> seems to own the domain
21.31.53 #       <braewoods> I'll email him and see if he knows anything.
21.31.56 #       <speachy> yep
21.32.07 #       <braewoods> I want to ask if we can get an official license so we can include it.
21.32.20 #       <braewoods> we'd like to archive it in case we need it for something
21.32.35 #       <braewoods> and maintain it to a lesser degree
21.32.38 #       <speachy> his whole site should be archived
21.53.30 #       <braewoods> found something in the strings
21.53.39 #       <braewoods> startmainui: registerKey: remoteVolUpKey
21.53.48 #       <braewoods> that seems promising
21.53.52 #       <braewoods> a debug thing probably
21.54.24 #       <braewoods> i decided to run strings on the dump first
21.54.29 #       <braewoods> see if i found anything interesting
22.06.03 #       <braewoods> this reminds me of when i used to dig into linux source code to see if hardware was supported
22.06.31 Quit    dconrad ()
22.07.10 ***     Saving seen data "./dancer.seen"
22.17.40 #       <_bilgus> braewoods, did you try that pastebin code that dtps through the unknown bits?
22.18.00 #       <_bilgus> steps*
22.18.34 #       <braewoods> _bilgus: erm. that only set it once?
22.18.42 #       <braewoods> _bilgus: i don't recall you giving me anything else
22.18.48 #       <_bilgus> oh
22.19.13 #       <braewoods> in any case i've been trying to examine the decrypted OF
22.19.24 #       <braewoods> you want a copy?
22.19.34 #       <_bilgus> https://pastebin.com/nA1LjinE
22.19.56 #       <_bilgus> the OF won't help yet I want a dump of the memory of those registers
22.20.13 #       <_bilgus> like when the OF has been working
22.20.54 #       <braewoods> i see
22.22.03 #       <_bilgus> actually with some careful sleuthing you can intuit some things watching the registers switch, I see it has a jtag on that schema
22.22.36 #       <braewoods> indeed but i have no way to access it
22.23.09 #       <_bilgus> opening the device will get you closer
22.23.38 #       <_bilgus> at least then you might narrow down the mechanism
22.24.43 #       <braewoods> https://dpaste.com/8E9Z7XES4
22.27.17 #       <_bilgus> just add ;
22.28.13 #       <_bilgus> the splash might be too early to not crash the player
22.28.28 #       <_bilgus> in that case i'll re-work it a bit
22.29.57 #       <_bilgus> hmm I wonder if those PWM pins are actually the other two ADCs the other devices have
22.30.06 #       <_bilgus> maybe we are chasing the wrong ones
22.30.47 #       <_bilgus> doesn't seem like theyd multiplex those two functions on a single pin path
22.31.12 #       <braewoods> one problem with that theory
22.31.25 #       <braewoods> one of them is connected to the LCD backlight which we do have code for
22.31.29 #       <braewoods> but it's an output
22.31.42 #       <braewoods> aren't ADCs always inputs?
22.31.48 #       <_bilgus> well you have the address so go up or down 32 bits
22.32.10 #       <_bilgus> and PWMs are *almost* always outs
22.32.46 #       <_bilgus> I can't see why you'd do some weird stuff with reading PWM levels when you can just use an adc
22.33.09 #       <braewoods> anyway i'll run the code you asked me to
22.33.23 #       <_bilgus> and I'm not sure its even possible I've never seen one that wasn't std gpio when an input
22.33.41 #       <_bilgus> but...
22.35.24 Join    f1reflyylmao [0] (~f1refly@dynamic-077-003-043-006.77.3.pool.telefonica.de)
22.36.09 #       <braewoods> btw you used splash instead of splashf
22.36.45 #       <braewoods> anyway
22.36.52 #       <braewoods> time to run this
22.37.41 Quit    f1refly (Ping timeout: 240 seconds)
22.37.42 Nick    f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-003-043-006.77.3.pool.telefonica.de)
22.43.56 #       <braewoods> _bilgus: nothing that i can tell
22.45.08 #       <braewoods> 80000000?
22.45.17 #       <braewoods> was it meant to be 0x80000000?
22.49.59 #       <_bilgus> it stops at 0x8000000
22.50.04 #       <_bilgus> did it splash
22.50.07 #       <braewoods> no
22.50.30 #       <_bilgus> then the adc never changed i assume you went to the debug menu
22.50.36 #       <braewoods> yea
22.50.40 #       <braewoods> i waited a bit
22.50.45 #       <braewoods> it changed but stayed about 3f0
22.51.03 #       <_bilgus> oh you need to hold the remote button
22.51.11 #       <braewoods> i just tapped it
22.51.13 #       <_bilgus> like the vol up something that repeats
22.51.14 #       <braewoods> is that the problem?
22.51.32 #       <braewoods> ok i'll try that instead
22.51.36 #       <_bilgus> yeah just hold it incase you miss it while it scans
22.54.18 #       <braewoods> i held the button but nothing
22.54.25 #       <_bilgus> and probably from the time it boots it will take a bit like probably 1 minute
22.54.45 #       <braewoods> you want me to boot it up again and wait longer?
22.54.49 #       <_bilgus> oh well I'm out of ideas then
22.55.01 #       <_bilgus> maybe its something weird
22.55.55 #       <braewoods> i'll wait a bit then
22.56.50 #       <_bilgus> idk I think a pocket oscope would probably do ya some good like 50-100 mhz is ok..
23.02.03 #       <_bilgus> mine is a 'portable' from 1980ish
23.02.18 #       <_bilgus> it weighs 35 lbs so its portable lol
23.02.55 #       <_bilgus> its 100 MHZ and I can count maybe 2x that it wasn't adequate
23.03.12 #       <_bilgus> though it is a 4 chan scope
23.03.47 #       <_bilgus> but i've been eyeing those pocket scopes itd come in handy in the garage
23.04.59 #       <_bilgus> like the missing shielding on a CPS sensor causing spurious signals lol I caught that one with the scope strapped to the hood with a power inverter
23.26.10 Join    daswf852 [0] (~daswf852@unaffiliated/dwf)
23.30.59 #       <braewoods> _bilgus: i decided to try enabling all the AIN lines
23.31.02 #       <braewoods> interesting results
23.31.07 #       <braewoods> the 4th channel is always 0
23.31.14 #       <braewoods> the 3rd channel is jumping around
23.36.18 Join    Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-14ba-5001-4fff-7f89.res6.spectrum.com)
23.56.33 Quit    prg3 (Quit: ZNC 1.8.2 - https://znc.in)