<freemangordon>
DocScrutinizer05: re devuan - where is n900 image? :)
<DocScrutinizer05>
I guess it takes a while till they build it
<DocScrutinizer05>
parazyd said he's happily running Devuan on N900
<DocScrutinizer05>
and Wizzup doing great success with call audio
<freemangordon>
I wonder if BB black image is usable
<freemangordon>
oh, really?
<freemangordon>
do you have any links?
<DocScrutinizer05>
that's what he told me
<freemangordon>
ah
<DocScrutinizer05>
he's a tad busy, I already asked him to provide the complete build. He remarked that user still needs to install uBoot from maemo
<freemangordon>
well, that's expected
<DocScrutinizer05>
yep, indeed :-D
<DocScrutinizer05>
though I suggested to make a fiasco image
<freemangordon>
though, we can flash kernel and initrd
<freemangordon>
but still, until legacy boot is removed (which should happen soon), zImage won't fit into kernel flash area
<freemangordon>
DocScrutinizer05: oh, and BTW I was able to use IR TX with pierogi on linux 4.6
<freemangordon>
what is strange, it contols my TV from some 5m distance
<freemangordon>
I think stock kernel limit is ~2m
jonsger has joined #neo900
<DocScrutinizer05>
hmmm
<DocScrutinizer05>
interesting
<freemangordon>
yes
<freemangordon>
though it might be because of the physical devices differences
<freemangordon>
s/physical/particular
* freemangordon
is having his first coffee for the day :)
<DocScrutinizer05>
I see the bipolar transistors are just driven high by SoC GPIO output
<DocScrutinizer05>
:-o
<freemangordon>
yes
<freemangordon>
but carrier and packet timings should make difference
* DocScrutinizer05
ponders pushpull vs OC with weak/strong pullup
<DocScrutinizer05>
GPIO config
<DocScrutinizer05>
I *think* you could configure the GPIO output to either do pushpull aka totem-pole, or open-collector with weak (500kR?) or strong (1/10 of that) pullup R
<DocScrutinizer05>
pushpull of course will work much much better that OC with 500k pullup
<DocScrutinizer05>
s/that/than/
<DocScrutinizer05>
please refer me when you send the patch to CSSU ;-)
<DocScrutinizer05>
timing makes a difference, a lot. Nevertheless I played with timing ad nauseum with IRreco and Lirc backend
<DocScrutinizer05>
I'm pretty sure I found the optimum carrier frequency
<freemangordon>
DocScrutinizer05: hmm, not sure I got the idea, we have a GPIO-controlled bipolars in parallel, in OE schematic, which, IIRC doesnt care that much about input current
<DocScrutinizer05>
huh?
<DocScrutinizer05>
of course a bipolar transistor cares about basis input current
<DocScrutinizer05>
the collector current is proportional to basis current * Beta aka gain
<freemangordon>
:)
<freemangordon>
see, I know how that works. The questions is - what is the driving current of that IR LED?
<freemangordon>
5 mA? 10 mA?
<DocScrutinizer05>
that's determined by the R1361-4
<DocScrutinizer05>
that circuit assumes you're driving the transistor into saturation
<freemangordon>
~4/50
<infobot>
0.08
<freemangordon>
~80mA
<freemangordon>
well, not exactly
<DocScrutinizer05>
rather (4.2-1.8)/(220/4)
<freemangordon>
because we should account for diode forward bias(?)
<DocScrutinizer05>
yes
<freemangordon>
is that the correct english term?
<DocScrutinizer05>
and even the transistor Vce-sat
<DocScrutinizer05>
yes
<DocScrutinizer05>
Vfwd
<DocScrutinizer05>
for LED
<freemangordon>
so, a safe bet is ~20 mA, ok?
<DocScrutinizer05>
~(4.2-1.8)/(220/4)
<infobot>
0.043636363636
<DocScrutinizer05>
rather 40
<freemangordon>
hmm, can't remember bipolar saturation bias, going to check
<DocScrutinizer05>
you could test by continuously operating the LED at carrier freq, assuming it has a 50% duty cycle
<DocScrutinizer05>
depends on transistor, Vce-sat might be in the range of 0.3 to 0.7V maybe, iirc
<freemangordon>
my point was that - if we assume 40mA through diode, then we need 40/h21 input current, correct?
<DocScrutinizer05>
yep
<freemangordon>
ok, the internal pull-up is 10k iirc
<DocScrutinizer05>
when h21 is the gain
<freemangordon>
VIO is 1.8V
<freemangordon>
~(1.8-0.7)/10000
<infobot>
0.00011
<DocScrutinizer05>
well, you have 2 parallel 4k7 series
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
make that 15000
<freemangordon>
even if we ignore the level shifters
<freemangordon>
the point I am trying to make is that enabling internal pull-up won't make much if any difference
<DocScrutinizer05>
or even 12400/2
<DocScrutinizer05>
err
* freemangordon
check the TRM
<DocScrutinizer05>
sure there's a big difference between feeding pushpull full 1V8 to the transistors, or doing same via a 10k (I doubt it's as small as 10k)
<DocScrutinizer05>
and look, we got 2 transistors in parallel, that means for each the pullup looks like 20k when in fact it's 10
<DocScrutinizer05>
so each transistor has a voltage device at basis of 24700/47000
<DocScrutinizer05>
voltage devider
<DocScrutinizer05>
now check if that can deliver a 20/h21 at 0.7V
<DocScrutinizer05>
20 since we got two transistors
<DocScrutinizer05>
for h21 (I call it beta) you're safe to assume 100
<freemangordon>
can't find pull-up value in the TRM :(
<DocScrutinizer05>
it should use pullpush
<Wizzup>
09:18 <+DocScrutinizer05> and Wizzup doing great success with call audio
<Wizzup>
I didn't say that :)
<DocScrutinizer05>
parazyd told me
<Wizzup>
I have not attempted to make calls just yet
<Wizzup>
I managed to get the modem and gprs up with pavel's help
<DocScrutinizer05>
ooh, he didn't: [2016-04-30 Sat 01:22:21] <parazyd> wizzup is making great progress on the modem btw
<DocScrutinizer05>
soory, my bad
<Wizzup>
making progress on getting it to work for myself* I haven't done much/any kernel work here
<freemangordon>
Wizzup: if you're fed with audio, there are a couple of other systems that need love, recently we're making great progress with cameras
<Wizzup>
How could I help? Just testing? Or do you mean kernel hacking? Or both? ;)
paulk-collins has joined #neo900
<freemangordon>
Wizzup: lots of patches need clean-up
<DocScrutinizer05>
freemangordon: can you configure McSPI2_SIMO Y2 GPT9_PWM to pushpull mode?
<freemangordon>
DocScrutinizer05: have to run now, will check later
Pali has joined #neo900
jonsger1 has joined #neo900
jonsger has quit [Ping timeout: 276 seconds]
jonsger1 is now known as jonsger
<DocScrutinizer05>
no worries, this one is pending since 6 years ;-)
<DocScrutinizer05>
I always wondered how the heck it could be so damn weak
betheynyx has joined #neo900
jonsger has quit [Ping timeout: 276 seconds]
bredebid has joined #neo900
Zero_Chaos has quit [Read error: Connection reset by peer]
SylvieLorxu has joined #neo900
lobito has quit [Ping timeout: 260 seconds]
jonsger has joined #neo900
xman has quit [Quit: Leaving.]
jonsger has quit [Ping timeout: 276 seconds]
modem_ has joined #neo900
betheynyx has quit [Max SendQ exceeded]
sixwheeledbeast^ has joined #neo900
freemangordon has quit [*.net *.split]
sixwheeledbeast has quit [*.net *.split]
freemangordon has joined #neo900
<freemangordon>
DocScrutinizer05: I don't see push-pull supported on anything besides mmc card pins
<DocScrutinizer05>
dang
<freemangordon>
also, pull-ups (and pull-downs) are auto disabled when a gpio is configured as an output
<freemangordon>
DocScrutinizer05: however, I don;t really think the problem is with the output power, it is rather with carrier frequency stability, packet delays, etc
<DocScrutinizer05>
hmm there must be a pushpull mode, otherwise this >>High-level output voltage, driver enabled, pullup or pulldown disabled<< wouldn't make any sense. If there's no pullup enabled, there can't be high output voltage unless it's pushpull
<freemangordon>
well then, it is not OC :)
<DocScrutinizer05>
IO = IOH or IO = –2 mA
<DocScrutinizer05>
vdds – 0.45
<freemangordon>
DocScrutinizer05: hmm, look at page 772
<DocScrutinizer05>
so Vdds is 1.8V, no? then the output voltage is 1.35V @ 2mA aiui
<freemangordon>
yes, VIO is 1.8 V
<DocScrutinizer05>
there is no page 772 in this document (OMAP3525-HiRel, OMAP3530-HiRel SPRS599D)
<freemangordon>
come-on, use the TRM I gave you
<freemangordon>
SWPU223M
<DocScrutinizer05>
so what's on 772?
<freemangordon>
gpio pins schematic
<DocScrutinizer05>
I see, still I dunno what to do with that
<freemangordon>
iiuc, this is not OC, but push-pull
<DocScrutinizer05>
do you mean it suggests there's no OC mode?
<freemangordon>
yes
<DocScrutinizer05>
ack
<DocScrutinizer05>
it *suggests* that
<DocScrutinizer05>
dunno, I never looked into the GPIO details of that SoC
<DocScrutinizer05>
pushpull usually is just fine, except for buses
<freemangordon>
IOW, there is no "PP mode enable" as this is the only supported mode
<DocScrutinizer05>
hmm, you could easily doo OC mode by simply applying the output signal to the enable pin of the putput driver with input tied to GND
<DocScrutinizer05>
output*
<freemangordon>
hmm? you can;t enable both input and output at the same time
<DocScrutinizer05>
INPUTENABLE = 1: Input Enable. Pin is configured in bidirectional mode.
<freemangordon>
yeah, correct
<DocScrutinizer05>
anyway we'll only know for sure when we look into the CIR driver used in maemo
<DocScrutinizer05>
I mean it could do all sorts of weird things
<DocScrutinizer05>
even with just one GPIO
<freemangordon>
it is the same one used in upstream, and no, it does not do anything weird
<DocScrutinizer05>
when it's the same as used upstream, then how can upstream differ from maemo?
<freemangordon>
can't parse
<freemangordon>
I fixed and underlying driver so the IRTX driver to function correctly
<freemangordon>
*an
<DocScrutinizer05>
when both upstream driver and maemo driver are same code, the device behavior must be identical too
<freemangordon>
well, yes, but both kernels may differ in latency, for example. also, I checked GPT9 gpio config in both stock kernel and upstream and they are identical
<freemangordon>
also, the device I use to test is 2204, that may make a difference as well
<DocScrutinizer05>
I have a hard time with assuming that timing issues are relevant for *range*
<freemangordon>
well, later I'll test the same device with stock kernel.
betheynyx has joined #neo900
<DocScrutinizer05>
I suggest you grab a photodiode and clamp it to your scope, then record signal at a defined distance and orientation from same N900, with stock maemo and your kernel, with the supposedly same signal sequence sent
<freemangordon>
my scope cannot record :)
<DocScrutinizer05>
:-/
<DocScrutinizer05>
should still suffice to see amplitude and possibly also signal shape, particularly on/off duty cycle
<DocScrutinizer05>
if you wanna go fancy, use your PC soundcard instead, at 96ksamples/s, ideally with disabled filters
<freemangordon>
:)
<freemangordon>
I don't think I have time to play with that right now, too many code to be cleaned-up
<DocScrutinizer05>
:-)
<DocScrutinizer05>
when you checked that upstream driver is same like maemo genuine one, we're basically already done. Nothing to investigate really
<DocScrutinizer05>
anyway just for funn let's complete this little game
<DocScrutinizer05>
1.4V Voh, 0.7Vbe_sat, so a 0.7V (1.4-0.7) on the 4.7k series in basis
<DocScrutinizer05>
~0.7/4700
<infobot>
0.00014893617
<DocScrutinizer05>
~0.7/4700*1000
<infobot>
0.148936170213
<DocScrutinizer05>
mA
<DocScrutinizer05>
0.14*100
<DocScrutinizer05>
for a beta of 100
<DocScrutinizer05>
is 14mA Ic
<DocScrutinizer05>
not good
<DocScrutinizer05>
if we knew the transistor(s) type, we could guess if they have a beta of 50, 100, or even 500
<DocScrutinizer05>
200 would already suffice
<freemangordon>
looking in the camera preview of my other n900, it looks really bright