<zrafa>
wolfspraul: yes, I lost the web page of the fatfingershell. And the web page had a copy of the sources as well IIRC
<wolfspraul>
saw it :-)
<wolfspraul>
oh well
<wolfspraul>
those servers are really maintenance heavy, and except for empty promises there is no support to kick them alive and keep them running
<wolfspraul>
if you really have no copy, it might be hard to make it through to the backups, even though they exist of course
<wolfspraul>
how about google cache? internet archives?
<wolfspraul>
I think they are trying to restructure the virtual machines a little right now, if you are lucky then maybe it might reappear after a little while :-)
<zrafa>
internet archives did not find
<wolfspraul>
wpwrak: ah, hey. I just committed the --fill-all-zones patch
<zrafa>
my backup is a little old, maybe I can survive with that
<wolfspraul>
yeah, sorry about that but I also cannot help.
<wolfspraul>
I also made the checking a bit stricter, I only allow one major command now, and hopefully the problem with stale lock files is also gone.
<wolfspraul>
I guess I will go back to eeschema soon
<wolfspraul>
let me know if you need more in pcbnew
<wpwrak>
wolfspraul: (fill-all-zones) yipee ! and you saw that i had added kicad-patches to eda-tools. perfect !
<wolfspraul>
yes sure, I saw it. great. I committed there (just before you came back)
<wpwrak>
wolfspraul: (more) for now i'm very happy, thanks ! ;-)
<wolfspraul>
Adam posted a great mail about jtag-serial sourcing and production process. I need to read it in detail...
<wolfspraul>
when I'm finished with the cmdline options in eeschema and pcbnew, I will definitely bring it live on the server and auto-generate a lot of these files upon commits
<wolfspraul>
I think just the latest version, not as sophisticated as schhist
<wolfspraul>
maybe something like projects.qi-hardware.com/plots/xue/...
<wolfspraul>
'plots' may not be the best name
<wpwrak>
i gues i should give "brdhist" a spin. should be a bit easier than "schhist", because there aren
<wpwrak>
t so many names to track
<wolfspraul>
I think there will be plots, drc/erc reports, visualizations (png/svg)
<wpwrak>
one problem are more external dependencies, especially the .mod files derived from .fpd
<wolfspraul>
ah, also bom files, modules position
<wolfspraul>
any good idea for a url name?
<wolfspraul>
we have /schhist/project right now
<wolfspraul>
maybe /brdhist/project later
<wolfspraul>
maybe just /files/project ?
<wolfspraul>
maybe files is better than plots?
<wolfspraul>
or 'auto' to indicate that they are a bit in flux
<wolfspraul>
so if you link to a .drc file in that url, the file you are linking to may be different 2 months later
<wolfspraul>
so maybe projects.qi-hardware.com/auto/project/...
<wpwrak>
hmm, dunno.
<wolfspraul>
or of course we forget about wasting storage bits, and just create the files for each commit, and keep them in a subfolder with the commit guid/revision
<wolfspraul>
and a 'latest' symlink
<wpwrak>
plus the overview page ?
<wolfspraul>
that's probably cleaner in terms of linking, but I'm a little worried people will be overwhelmed
<wolfspraul>
of course we can just point to the latest symlink
<wolfspraul>
yeah maybe that's better. keep the auto-generated files for each revision.
<wpwrak>
i'm not sure you really need to generate all the production files there. at some point, the person making the production run will probably have to touch kicad anyway. then it's more important to have a good set of local tools (e.g., a Makefile)
<wolfspraul>
I agree, but I want to create those files to lower the barrier of entry into the project in general.
<wolfspraul>
and since I don't know the starting point of the person on the other side, I just create the files as a first step towards them
<wpwrak>
ah, one snap with auto-generated files: name changes. right now, the name in revision X depends also on the file's history
<wolfspraul>
also I don't want to create 'all' files
<wpwrak>
(in schhist)
<wolfspraul>
either we understand what it's good for, and can recommend/document them, or not generate at all
<wolfspraul>
generating junk is no service to anybody, no worries
<wolfspraul>
I will not generate all files only because we have so many command line options now :-)
<wolfspraul>
well, first decision is whether to generate them only for the latest commit, or for every revision with 'latest' symlink
<wolfspraul>
then the url name, I'm torn between 'files' and 'auto'. Maybe I still like 'auto' the best.
<wolfspraul>
also like you said to indicate that those files are not really meant as a stable source for production.
<wpwrak>
i think schhist covers pretty much everything you'd want on the schematics side
<wpwrak>
now something similar for the layout, and perhaps svg for "pretty" overviews. maybe DRC/ERC reports.
<wolfspraul>
also bom & modules position, people may want to peek in there
<wolfspraul>
you have no idea how often I get stupid questions like "where is the bom?"
<wolfspraul>
"if you have no bom you are not open"
<wolfspraul>
bla bla bla
<wolfspraul>
:-)
<wolfspraul>
not that I am really thinking those people will ever produce anything, but the word 'bom' has made quite the rounds...
<wpwrak>
okay, the bom too, yes :)
<wolfspraul>
what I want at the beginning is erc/drc, then some svgs
<wpwrak>
bom is nice to have - gives you a rough idea of what's in this circuit and how expensive it may be.
<wolfspraul>
what do you think about creating them (and saving) for each revision, versus only for the latest one?
<wpwrak>
i'm not so sure about module positions per se. perhaps a searchable PDF ...
<wolfspraul>
that's one thing we need to decide
<wolfspraul>
yes correct, searchable is good, also searchable placement PDF
<wolfspraul>
gotta run
<wolfspraul>
(I read the irclogs)
<wpwrak>
hmm, per version could be useful if you want a URL to "pin" a version
<wpwrak>
beyond that, it's probably not very useful without a proper history mechanism
<mth>
it seems to use Google for the actual translation, but it gets the text from the PDF automatically
<kristianpaul>
wolfspraul: How was the workshop?
<wolfspraul>
kristianpaul: I didn't go there :-)
<kristianpaul>
oh ok
<wolfspraul>
I should have, but I stumbled around the building on 3 different things and plain and simple missed it.
<wolfspraul>
I'm focusing on the cases...
<kristianpaul>
sure :-)
<wolfspraul>
kristianpaul: you don't know how creative (chaotic) this is here...
<kristianpaul>
:-)
<kristianpaul>
as chaotic as the streaming i hope ;-)
<wolfspraul>
andres-calderon: I was wondering the other day - why does the Aptina sensor need a separate power supply?
<wolfspraul>
can't we get the power from the main board power supply and/or from the fpga?
<andres-calderon>
The sensor does not need a separate PSU. But  is better to place some regulators in the sensor board. Different sensors have different voltages
<wolfspraul>
andres-calderon: different sensor?
<wolfspraul>
that sounds like we should first make the simplest possible solution just for the mt9m033, get that to work, then think about other sensors
<wolfspraul>
whatever we can remove that still leaves us with a camera, I'm voting for removing it
<andres-calderon>
wolfspraul:  Putting the LDOs in the second board is the simplest solution, I have  problems with the space.
<wolfspraul>
ok I cannot judge whether they logically belong to the Aptina daughterboard, or to the base board
<wolfspraul>
or whether they can be used by other daughterboards in the future, or not
<wolfspraul>
I just wondered about the separate psu...
<wpwrak>
wolfspraul, andres-calderon: one possible approach for simplifying power supplies would be to provide the regulated voltages of the mainboard also to the daughterboard. this assumes that 1) there are enough free pins in the connector(s) and 2) that the regulators on the mainboard aren't already maxed out
<wolfspraul>
yes, that's what I thought
<wolfspraul>
although the Aptina sensor needs a number of different voltages, and also analog and digital vdd, or something like that
<andres-calderon>
wpwrak: i agree
<wolfspraul>
andres-calderon: great! :-)
<wpwrak>
wolfspraul: i wonder where the concept of needing separate regulators with the same voltage for analog and digital comes from. e.g., why not simply have an inductor to block current surges and an adequate silo capacitor on the load side of the inductor ?
<andres-calderon>
wpwrak: i agree too. We only cut/paste de reference design
<wolfspraul>
wpwrak: don't ask me.
<wolfspraul>
:-)
<wolfspraul>
wpwrak: sorry it's a bit chaotic here. I forgot whether you confirmed that the --fill-all-zones works for you?
<wolfspraul>
I'm back in eeschema now, I want to finish this kicad cmdline stuff asap...
<wpwrak>
hmm. when I run  pcbnew --plot=ps_a4 --ps-pads-drill-opt=none -l Front --mirror atusb.brd
<wpwrak>
it seems to produce the file well enough, but then i get an exit code of 255, which make doens't like
<wpwrak>
doesn't print any error or such
<wpwrak>
this seems to be new behaviour
<wpwrak>
--fill-all-zones looks good
<wpwrak>
(exit status 255) also happens with something as simple as  pcbnew --plot=ps atusb.brd
<qi-bot>
[commit] Werner Almesberger: atusb/Makefile: move common plot command parts to variable $(PLOT_BRD) http://qi-hw.com/p/ben-wpan/aae86ca
<qi-bot>
[commit] Werner Almesberger: atusb/Makefile: add --fill-all-zones to PLOT_BRD, to make sure zones are filled http://qi-hw.com/p/ben-wpan/228eb20
<zrafa>
M_Rojas: let me do some introductions.. wpwrak is werner if you did not realize. kristianpaul is from Colombia and he is hacking gps on nn
<M_Rojas>
great!
<M_Rojas>
I will keep reading, and try to learn :-)
<zrafa>
M_Rojas: wolfspraul is not here, but he is the guy making the nns in China.. xiangfu is in charge of the nn software, and other guys like me are doing mess :)
<M_Rojas>
:-)
<M_Rojas>
yesterday I was reading the logs ...
<kristianpaul>
And there is more people around hacking openwrt, i just cant remenber name and nick equivalent :S
<kristianpaul>
lija?
<kristianpaul>
mejor ni pregunta ;-)
<M_Rojas>
lija = hunger
<kristianpaul>
M_Rojas: larsc is kernel hacker for the nn
<M_Rojas>
:-)
<M_Rojas>
ok, great
<kristianpaul>
M_Rojas: i guess you from argetina as well? :-)
<kristianpaul>
argentina*
<M_Rojas>
now I know some of the characters ...
<Jay7>
morning
<wpwrak>
phew. ups is charging. i'm trying my luck again. had 4 brown-outs within 24 hours yesterday. enough is enough.
<larsc>
suschman: depends on which mirko you are looking for
<zrafa>
kristianpaul: yes, he is
<zrafa>
wpwrak: you will be with the people on rivadavia street reclaiming :)
<wpwrak>
zrafa: naw, ->I<- will sit happily at my PC, with the UPS gracefully covering the interruptions :)
<wpwrak>
zrafa: the interruptions are all brown-outs. just long enough to reset some of my PCs (not all of them), some of my lab instruments, and sometimes the CNC mill.
<M_Rojas>
mmm another brown-out
<M_Rojas>
I hope it does not extend to the entire city ...
<wpwrak>
naw, this was just the cablemodem needing a restart. it does that every few weeks or so.
<M_Rojas>
well come back :-)
<kristianpaul>
wpwrak: how much power you need i your lab?
<wpwrak>
kristianpaul: don't remember :) i once added all the maximum values - and the result was that the apartment's fuse would barely hold :)
<wpwrak>
kristianpaul: of course, real-life consumption is a bit lower :)
<kristianpaul>
i just saying because you mentioned UPS is not enougt for brown-outs?
<wpwrak>
kristianpaul: the one i had made them only worse. now i'm trying a different and hopefully better one.
<wpwrak>
kristianpaul: well, i will try as soon as the next brownout hits. (which should be within a few hours) no point in cutting power unnecessarily ;-)
<kristianpaul>
try as google UPS-like arrange per each server ;-)
<wpwrak>
kristianpaul: i thought of it ... but that would just add some 5+ systems that each add a bit more consumption, that each have their own failure mode, and that each can just break. if you seek reliability, complexity is bad :)
<larsc>
lekernel_27C3: where exactly are you hiding at the c3?
<lekernel_27C3>
saal 2
<lekernel_27C3>
just in front of the door
<wpwrak>
lekernel_27C3: surrounded by fans, i hope :-)
<lekernel_27C3>
i gave up the milkymist stuff in the lounge for a while. the video camera working perfectly in one room and extremely unstably in the lounge was too hard on my nerves
<wpwrak>
and groupies ;-)
<lekernel_27C3>
I should change the project's slogan to "bugs that blow your mind"
<kristianpaul>
haha :-)
<lekernel_27C3>
maybe it was just that all this equipment the lounge soundsystem is made of was sending some kind of interference
<wpwrak>
MurphyMist :)
<lekernel_27C3>
tried changing cables, power supplies, milkymist boards, that crap persisted
<lekernel_27C3>
it's the first time such a thing happens
<lekernel_27C3>
i've used the video input and this camera for quite a while before, and it worked perfectly
<kristianpaul>
(interference) good ! you are good for FCC and related certifications :-)
<lekernel_27C3>
no idea
<kristianpaul>
s/good for/good to go
<lekernel_27C3>
maybe it was the camera
<lekernel_27C3>
maybe not
<lekernel_27C3>
who knows
<kristianpaul>
murphy?
<lekernel_27C3>
go to the c3 and debug it yourself, but that crap wants to make me smash a dozen milkymist boards on the floor
<kristianpaul>
lekernel_27C3: how was workshop btw?
<wpwrak>
DocScrutinizer: so you have wlan now. congratulations ! :)
<DocScrutinizer>
LOL
<DocScrutinizer>
wl1251 has monitor mode and packet injection now
<DocScrutinizer>
thought you might be somewhat interested
<DocScrutinizer>
though I'm aware it's been Andy who wrote some drivers for Aircrack or something similar
<DocScrutinizer>
iirc
<wpwrak>
ah, to be honest, just so-so at the moment. what i'd *really* like to know is why the USB design that i've already used something like seven times without a flaw all of a sudden falls apart.
<DocScrutinizer>
eh?
<DocScrutinizer>
please elaborate
<DocScrutinizer>
(btw was smiling when I seen your name bottom of fsck.vfat manpage :-)Â Â )
<wpwrak>
the atusb board. the board resets quite often - sometimes not for something like half an hour, but sometimes continuously
<DocScrutinizer>
hmmmmmm, is there a cummulative comprehensive pdf somewhere?
<wpwrak>
(fsck, diag printout) ah ? i back when i wrote it (called dosfsck), it actually ran circles around M$'s chkdsk (sp ?). fixed quite a lot of things where chkdsk would just deliver the "coup de grace"
<DocScrutinizer>
ahh the second link?
<wpwrak>
yup
<DocScrutinizer>
what *is* it?
<wpwrak>
;-))
<DocScrutinizer>
i.e whats at other end of USB?
<DocScrutinizer>
of PCB
<wpwrak>
it's an ieee 802.15.4 usb dongle
<DocScrutinizer>
k
<wpwrak>
plus into a pc/laptop/whatever
<wpwrak>
pluGs
<DocScrutinizer>
I see
<wpwrak>
NB: the usb side is basically identical to idbg-gta02, idbg-ben, cntr old, cntr new, a previous atusb design, and some more boards i made. all of them work great.
<DocScrutinizer>
which part resets? the USB controller?
<wpwrak>
(in some i had to change the varistors, though. once tried bigger ones but their capacitance was too high)
<wpwrak>
yes, the usb controller
<DocScrutinizer>
RF feedback?
<DocScrutinizer>
what's TX power?
<wpwrak>
RF should be quite asleep at that tome
<wpwrak>
tIme
<DocScrutinizer>
hmmm
<wpwrak>
maximum tx power would be 3 dBm
<wpwrak>
but the rails are eerily quiet. no weird noise. no glitch in sight.
<DocScrutinizer>
F326 datasheet? PCB layout?
<wpwrak>
best if you check out the project. then everything is very easy to access.
<DocScrutinizer>
maybe even a photo of a^HTHE prototype?
<DocScrutinizer>
also seems silabs suggests 4.7u + 0.1u for VDD buffer
<DocScrutinizer>
p16
<DocScrutinizer>
fig 1.4
<wpwrak>
ah, interesting. let's try this :)
<DocScrutinizer>
:-D
<DocScrutinizer>
you're welcome
<DocScrutinizer>
o/
<wpwrak>
page 60, section 7.3 says "maybe". but that could of course be one of the "be" cases ...
<wpwrak>
this of course still leaves the mystery why the other board wouldn't even reliably get to the end of flashing. (the reset pin is driven in this case) but maybe they're beset by different problems.
<DocScrutinizer>
another spook in my mind is clock
<wpwrak>
mcu clock comes from usb.
<DocScrutinizer>
mech coupling from 16MHz xtal. Or instabilities arise from sth else
<wpwrak>
the rf clock runs too, and it's stable
<DocScrutinizer>
mcu clk comes from USB??
<wpwrak>
(well, stable on the scope. didn't torture-test it)
<wpwrak>
well, internal rc osc that's synchronized with usb
<DocScrutinizer>
you're sure it's an RC osc?
<DocScrutinizer>
not some mechanical tuned element
<DocScrutinizer>
aka resonator
<DocScrutinizer>
sorry too short a time to digest all 140 pp
<DocScrutinizer>
anyway I see [26] XTAL2 at very least. NC on your circuit
<wpwrak>
hmm. data sheet doesn't specify the physics of the internal oscillator.
<DocScrutinizer>
if that is actually a xtal driver IO, then it could catch up noise
<DocScrutinizer>
I'd suggest you have a second look into silab's word on that one
<wpwrak>
"Unused port pins should be left floating", fig 1.3 or 1.4
<wpwrak>
and this appears to include the xtal pins
<DocScrutinizer>
if that's also a "may (need GND/foo)" then consider that
<DocScrutinizer>
hmm
<DocScrutinizer>
k
<wpwrak>
the chip is designed to not need a crystal, so i don't think they's miss that one
<DocScrutinizer>
nah, but a random bogus signal catched by the floating pin might confuse hell out of clock generation
<DocScrutinizer>
I'd need to study the § about that optional external xtal
<DocScrutinizer>
I'm afk now though. Feel free to ping me with results or further questions :-) always appreciate that
<wpwrak>
thanks a lot ! it's at least a place i hadn't considered yet. let's see how it turns out ...