<wolfspraul>
so the idea is that components/INFO describes the components that work in this design, not the reasons or selection criteria that led to this component
<kristianpaul>
juan64bits: ok, what about uSD linux module, is it working?
<wpwrak>
wolfspraul: components/* shouldn't be project-specific. i keep it in projects while testing. once things are stable, they can go to, say, kicad-libs
<wolfspraul>
including components/INFO ?
<wpwrak>
that would be merged, yes
<wolfspraul>
give that components/INFO is totally separate from KiCad I'm not sure it's a good idea to move it to kicad-libs
<wpwrak>
maybe with some editing, depends on how much junk ended up there
<wolfspraul>
it will create a barrier for people to edit/update it
<wpwrak>
components/INFO documents the content on components/*
<juan64bits>
yes, the module is the same of ben.... we only change some parameters for the GPIOs
<wpwrak>
where else would you keep this ? in the wiki ? :)
<wolfspraul>
hmm
<wolfspraul>
I just thought I understood components/INFO :-)
<juan64bits>
you can see the patch in the SIE repository
<wolfspraul>
maybe the user fields would actually be better then
<wpwrak>
i don't particularly like those invisible fields
<nitin_gupta>
gettine error while refalshing the kernel. Can anybody help me
<wolfspraul>
in ben-wpan, components/INFO has exactly one actual piece of data - it connects the crystal to a part number
<wolfspraul>
then there are some comments above the symbols
<wolfspraul>
the symbols are just the ones from the .libs, but need to be manually kept up to date
<wpwrak>
you'll find more detailed INFO files in gta02-core. those in ben-wpan are more or less for my own entertainment, and fairly sloppy :)
<wolfspraul>
how is the connection of the generic crystal to a part number not project specific?
<wolfspraul>
ok maybe I ignore components/INFO for now, will watch what happens
<wpwrak>
(crystal) it's an example for one possible such crystal. and yes, that's not really clean. the correct approach would be to write a document that defines this class of crystals, with references to real parts
<wolfspraul>
I got the BOOKSHELF idea now, I think
<wolfspraul>
it's just what it says - a separate 'bookshelf' :-)
<wpwrak>
yup :)
<wolfspraul>
and nice script to download and open docs
<kristianpaul>
juan64bits: k
<wolfspraul>
but not overly, or in fact in any way, linked to symbols or references in the schematics
<wolfspraul>
hence also the 'nice' aliases etc.
<wolfspraul>
so that one is clear
<kristianpaul>
juan64bits: other isolated question, did you have issue with the usb connector in SIE,
<wpwrak>
it also has things like application notes, design guides, etc.
<wolfspraul>
wpwrak: where would that document that defines a class of crystals and references it to real parts be? wouldn't that be in boom/.sub files?
<wpwrak>
so it's a place other things may link to but it's not a place that links out (except to the data sheet, of course)
<kristianpaul>
juan64bits: like some pin just dont make good contact with the usb cable by then power fails when feeding from usb?
<wpwrak>
(document) no no, that would be a real document. like that guy's kicad missing feature list
<kristianpaul>
may be just happened to me, i just want it to mak public :)
<kristianpaul>
and sure i can solve it soldering a new usb conector
<wolfspraul>
for those few lines it could be just comment lines in a .sub file, no?
<rafa>
kristianpaul: juan64bits : what is the sie reposiroty? where is it? what does it cointain? (kernel? bootloader? rootfs?).. sorry if many questions :)
<juan64bits>
mm yes, something similar happened to a student
<wpwrak>
few lines = definition of crystal ? well, depends
<kristianpaul>
rafa: all our answer are in there in the patchs and rootfs ;)
<juan64bits>
yes, that is...
<wpwrak>
.sub shouldn't really be a source anyway. the underlying design and conventions ought to be documented elsewhere
<nitin_gupta>
kristian, can you solve my prob
<kristianpaul>
may be juan64bits  can tell more about its particular folder hierarchy :)
<kristianpaul>
(sie repo and var stuff?..)
<kristianpaul>
nitin_gupta: hello
<nitin_gupta>
hi whats up
<kristianpaul>
just write and oher people can read you too :)
<wpwrak>
also, .sub has no idea what schematics symbols you're using, so it wouldn't really make sense to document them there
<nitin_gupta>
kristian, iam trying to reflash the kernel of NN but getting error
<juan64bits>
sie repository contains many examples for SIE
<nitin_gupta>
Error : "cant get kernel image"
<juan64bits>
like logics for the FPGA, comunication CPU-FPGA
<kristianpaul>
juan64bits: for example production SIE board were based on kicad ? i just noticed some labels do not correpond in the kicad project in the repo, wich ones?, the one the conector for uart and i2c
<rafa>
juan64bits: is it okey for sakc (previous sie boards) as well? is it the official software repository? (I mean, if you use just the software on that repository for your boards without extra software from other places)
<kristianpaul>
nitin_gupta: how you the boot process?
<juan64bits>
some binaries, the rootfs (that is merge with the ben in basic configuration)
<kristianpaul>
nitin_gupta: what steps you followed?
<kristianpaul>
nitin_gupta: are you using regflash script?
<nitin_gupta>
after flashing the kernel and rootfs, I just remove the usb cable and plug in the battery back and power on.
<nitin_gupta>
no I am not using reflash script
<kristianpaul>
it seems the uImge is not there
<nitin_gupta>
I tried it but it was not working some how
<kristianpaul>
whar instructions you followed?
<juan64bits>
mmm the kicad board are a copy of previous orcad design, and never has been made
<kristianpaul>
what*
<kristianpaul>
juan64bits: aha !!!!
<nitin_gupta>
firstly bring NN in usb mode
<kristianpaul>
**never has been made**
<wolfspraul>
kristianpaul: neither the avt2 nor sie kicad files were used for actual pcb or smt
<wolfspraul>
nobody dared to do that yet :-)
<kristianpaul>
:/
<nitin_gupta>
then usbboot -c "boot", then usbboot -c "nprog 1024 kernel_image 0 0 -n" and last usbboot -c "nprog 2048 rootfs image 0 0 -n"
<wolfspraul>
but it looks like we finally will with Xue
<juan64bits>
but we are thinking use this design in the next revision
<wolfspraul>
yes, and in SIE v3
<kristianpaul>
i hope is not same for xue.. but thats other talk
<wolfspraul>
kristianpaul: we are getting there, there were always specific reasons, this and that.
<kristianpaul>
nitin_gupta: nerase?..
<nitin_gupta>
nope
<kristianpaul>
sure
<kristianpaul>
time , run run run !!
<nitin_gupta>
I havent used it
<kristianpaul>
nitin_gupta: you need for rootfs
<kristianpaul>
wait a min
<nitin_gupta>
no such cmd is written in the booklet
<kristianpaul>
nitin_gupta: i guess you compiled you're own images isnt?
<kristianpaul>
wolfspraul: smt and kicad dont go well, i really dont know what data is required in that process besides i know gerber is for making PCBs..
<kristianpaul>
?
<nitin_gupta>
yes
<wolfspraul>
you can check the Milkymist One runs as a reference, all files that were necessary for SMT are documented there
<kristianpaul>
k
<kristianpaul>
so guess answer is no
<kristianpaul>
:p
<wolfspraul>
yes we need to document the entire process from Kicad to PCB making to SMT (pick & place), and how to generate all supporting files
<wolfspraul>
the entire workflo
<wolfspraul>
workflow
<wolfspraul>
I think it's doable, definitely. Just a lot of little pieces and it all needs to be documented well. The various projects are getting us closer there, for sure.
<wolfspraul>
maybe we need a few runs until the process and documentation is really good and easily reusable for anybody.
<juan64bits>
yes, for now We tested a card, like arduino, for pcb making
<juan64bits>
But the assembly was done manually :)
<kristianpaul>
wolfspraul: remenber the board a guy introduced by andres in cparty gave you, the board name is miulin
<kristianpaul>
was made all in kicad
<kristianpaul>
sadly no public sources yet :(
<wolfspraul>
sure I remember
<kristianpaul>
but SMT was done manually if i remenber well, so no complete workflow
<wolfspraul>
I think we are ahead of this, the point is to open up all files, the process, etc.
<kristianpaul>
but at least the board is prove is posible
<kristianpaul>
probe*
<wolfspraul>
not dump a zip at the end somewhere
<kristianpaul>
sure
<wolfspraul>
git/svn is important, KiCad, things like schhist, boom, wiki to document some things
<kristianpaul>
agree
<wolfspraul>
also those little things I keep pinging Werner about, like BOOKSHELF, how to document component selection criteria, design choices, etc.
<wolfspraul>
the problem is that a) it's not enough if one person just declares the perfect process, it has to be thought through and used by multiple people over time and
<wolfspraul>
b) it needs to be rested and refined by real manufacturing, be it at home/diy style, or with services/companies
<wolfspraul>
needs to be tested
<wolfspraul>
maybe Xue can become our masterpiece, he he
<wolfspraul>
let's see
<wolfspraul>
maybe a lot of things will come together there
<wolfspraul>
wpwrak: about the crystal we talked about earlier. the current C1/C3 is 27pF, the crystal on the current board has a load capacitance of 12pF.
<wolfspraul>
2*12=24, so a little lower than 27pF but I guess it should work? I mean I saw boards working so it must work...
<wpwrak>
wolfspraul: the chip probably isn't that sensitive to clock inaccuracy.
<wpwrak>
wolfspraul: it gets nastier when you do RF :)
<wolfspraul>
if I go to a 18pF crystal I guess I will just increase C1/C3 to 33pF as you suggested
<wpwrak>
yup, that should work nicely. your pins will add a few pF too, so you'll end up more or less exactly with 36 pF
<wolfspraul>
wpwrak: in this case, how would you name the 'value' in eeschema? it's 'crystal_smd' right now
<wolfspraul>
would you encode the 12mhz and/or load capacitance?
<wolfspraul>
if the footprint is in mm (3.2mm x 2.5mm here), any standard format for that?
<wolfspraul>
which of those things would you encode in the value, footprint or user defined fields (in eeschema)?
<wpwrak>
(value) good question :) the frequency for sure. the load cap is rarely mentioned, yet it does matter
<wolfspraul>
well it seems it does. the crystals I find are between 8 and 18pF, and it sounds like without changing other capacitors, you wouldn't want to just ignore this value.
<wpwrak>
afaik, crystal footprints can have a lot of sizes.
<wolfspraul>
digikey for example has the load capacitance in the description field
<wolfspraul>
but not the frequency stability and tolerance
<wolfspraul>
so the load capacitance does seem to stand out somewhat as something you will want to get right/matching in your design
<wpwrak>
not the tolerance ? i think they do
<wolfspraul>
"CRYSTAL 12.000000 MHZ 8PF SMD"
<wpwrak>
aah, description field, right. well, the digi-key description field can be odd at times :)
<wolfspraul>
maybe the value should be CRYSTAL_SMD_12MHZ_18PF ? (in our design)
<wolfspraul>
or is that too much?
<wolfspraul>
just trying to understand what you would move to which place...
<wpwrak>
well, ->I<- would have 12MHz in the value and 18pF in another (visible) field
<wpwrak>
but you can pick a different style :) you need to adapt the .sub then, though
<wolfspraul>
which fields are visible?
<wolfspraul>
you mean visible in the plotted schematics I guess
<wpwrak>
because my .subs don't know about the param/other_param format
<wpwrak>
you can choose in eeschema whether a field's value is shown in the schematics or not
<wolfspraul>
ah OK
<wolfspraul>
looks ugly, not enough space for the "18pF" right smack in the middle of the crystal symbol
<wolfspraul>
btw, the Value is "12MHz" right now, the Footprint is "CRYSTAL_SMD"
<wolfspraul>
should the footprint include an attempt to encode the size in it? 3.2mm x 2.5mm. Or rather not?
<wolfspraul>
I think I leave the additional Load_Capacitance field invisible for now, it's too ugly
<wolfspraul>
field names can have spaces in eeschema, is that supported (or encouraged) by boom?
<wpwrak>
hmm, boom in general doens't like spaces so much. you can wildcard-jump over them, though
<wolfspraul>
no problem, I understand that as 'don't use spaces in eeschema field names'
<wpwrak>
(in the middle) you can move fields around in eeschema
<nitin_gupta>
kristian NN doesnt wake up after that
<nitin_gupta>
i have reflashed uboot, kernel and rootfs and all get done successfully
<wpwrak>
the footprint should identify the physical size somehow. this can be a standard package name (DIP-10, SSOP-20, etc.), an explicit size, or whatever else works.
<wpwrak>
now, crystals are one kind of components where i'm not sure if there are any standard sizes or not
<wolfspraul>
yes I think there are, but a lot, maybe 20 or so
<wpwrak>
"the nice thing about standards is that there are so many to choose from" ;-)
<wolfspraul>
the ones I've seen (digikey only) can be either in diameter, or xy
<wolfspraul>
ok so I will encode 3.2mm x 2.5mm in the footprint
<wolfspraul>
thanks for the hint about moving fields, I moved the new Load_Capacitance down and it looks good now
<wpwrak>
great :)
<nitin_gupta>
kristaian u there ?
<kristianpaul>
still
<nitin_gupta>
NN is not booting up ?
<kristianpaul>
i heard that before ;)
<kristianpaul>
nitin_gupta: if you tell us we can give more focused responses
<nitin_gupta>
ok
<nitin_gupta>
now tell me what to do in order to get NN up ?
<kristianpaul>
i'mm off
<kristianpaul>
chao !
<wolfspraul>
wpwrak: it seems the first letter in a KiCad schematic reference is standardized somewaht
<wolfspraul>
C = capacitors, R = resistors
<wolfspraul>
U = ICs?
<wolfspraul>
X = crystals
<wolfspraul>
where is this documented?
<wpwrak>
wolfspraul: are you sure it's documented somewhere ? ;-)
<qi-bot>
[commit] Wolfgang Spraul: changed to cheaper 18pF crystal (was 12pF before), clarified X1 fields, changed C1/C3 to 33pF to match the crystal http://qi-hw.com/p/mmone-jtag-serial-cable/7f56822
<nitin_gupta>
wolfspraul can u help me
<wolfspraul>
I just commited the crystal stuff we talked about. if you have a minute you can check whether you see a style problem.
<wpwrak>
wolfspraul: looks good. now, filter parameters and led color (or, in both cases, just the part name, if you have something specific in mind) :)
<wolfspraul>
ah good point
<wolfspraul>
another comment (should be to KiCad though not you) - the silent creation of -cache.lib is really nasty
<wolfspraul>
I think what that means is that it's safer to just make the -cache.lib file part of what is being committed/tracked in the vcs
<wolfspraul>
I have also seen components only end up in that file (93c46), so I guess it is somehow possible in the KiCad GUI to have original components end up there.
<wolfspraul>
another serious bug
<wolfspraul>
so until KiCad fixes those serious bugs in how it creates, links to, and allows original data to creep into the -cache.lib file, we are better off always committing it
<nitin_gupta>
and after it only NN is not booting up
<nitin_gupta>
now when i am issuing lsusb command then its vendor id is not coming up
<wpwrak>
wolfspraul: dunno. i don't have such a file. maybe you want to find out what caused yours to get created ?
<wolfspraul>
wpwrak: for the filters, they are beads and current rating should be >= 500mA. Should I make a new field 'Type' and say "bead 1A"?
<wolfspraul>
well if you think we don't need to commit -cache.lib it's OK for me, I can manually delete it before commits.
<wolfspraul>
I'm just worried about the general usability of our tools. Yet another fairly specific thing to watch out for.
<wolfspraul>
in general, my understanding is we should leave all parameters that are not really hard requirement unspecified, to not overly restrict the part matching process later, in other words - all unspecified parameters can be chosen simply on price of component.
<wolfspraul>
maybe there are some borderline cases, say the color of the leds. could be different on each run :-) (theoretically)
<wolfspraul>
maybe also other values that _should_ be higher or lower for whatever reason, but don't totally have to
<wolfspraul>
so it's up to the design to make those decisions, which will then trickle into boom
<wolfspraul>
or to not make them, which means lower costs beats everything else
<wolfspraul>
correct me if I misunderstood something
<wolfspraul>
do you think KiCad schematics fields should always be upper-case? "BEAD 1A"?
<nitin_gupta>
kristian I am not abel to get any hint for this case
<wolfspraul>
wpwrak: in ben-wpan/bom/Makefile, do you want to take out the dk/ references and targets (and delete the entire ben-wpan/bom/dk folder maybe?). My understanding is that it has moved to eda-tools/boom/dist/dk and I get duplicate errors in ben-wpan unless I remove those references.
<wolfspraul>
I think boom-config is now taking care of it, again if I get this all right...
<wolfspraul>
do you have any future plans for ben-wpan/bom/lib/{captol.inc,e12.inc}?
<wolfspraul>
wpwrak: in ben-wpan/bom/Makefile, line 24 and line 29, I think there is an unneeded -r recursive flag in rm -rf
<nitin_gupta>
no one can solve my prob ?
<wpwrak>
wolfspraul: i don't have all the parts atusd needs in eda-tools/boom/
<wpwrak>
(yet)
<wolfspraul>
wpwrak: did you see the other two -r I found? I think they are not needed. Seems you have a trigger finger, when in doubt, rm -rf :-) Or are they needed there?
<wolfspraul>
ben-wpan/bom/Makefile, line 24 and 29
<wolfspraul>
ah, another question. the parameters for bom2part and part2order, equ/inv/chr files, do they have to be in a particular order? or are you always looking at the first line anyway?
<wpwrak>
(params) you mean the file names ? different kinds of files can be in any order. files of the same kind may have an (undocumented :-) order dependency
<wpwrak>
plans for ben-wpan/bom/lib/: yes, deletion :)
<wpwrak>
but please heed the warning in boom/UNDER-CONSTRUCTION :) all the stuff is unfinished and, particularly where it spans projects, full of design inconsistencies. what you can do is set up things so that boom will make a nice shopping list for you, but whatever you do, it won't be "right" for long, since things will change.
<wpwrak>
(change) also simply by considering more user input. but again, it's not quite ready for throwing it at everyone in qi-hw
<wpwrak>
(duplicates in ben-wpan) hmm, i don't get any. did you git pull everything to the latest version ? ben-wpan used to have things that conflicted, but i removed them several days ago.
<wpwrak>
(migrated them over to eda-tools/boom)
<wolfspraul>
wpwrak: maybe I got the duplicates because I ran the queries against digikey later than you?
<wolfspraul>
I am fully aware of the state of boom.
<wolfspraul>
I thought that is precisely why I dive in now:
<wolfspraul>
a) to give you feedback (which I am doing already)
<wolfspraul>
b) to learn about the system myself, early on, so that I can use it for some small test projects, and later will be in a good position to hook it up for 'demo' use on the server too
<wolfspraul>
so far everything is great, I'm totally excited about it!
<wolfspraul>
if you find my feedback too unnerving, I slow down until you tell me it's ready. But I try to give feedback mostly on small details that are bugs or inconsistencies today, and will likely be carried over.
<wolfspraul>
or to confirm some design decisions with you, and maybe encourage you to document them somewhere because (at least to me) they were non-obvious at the beginning
<wolfspraul>
and you only get these types of impressions once, after a while the whole system looks naturally to you, even though it isn't from the outside...
<wolfspraul>
I think it works amzingly well already. I am generating my parts list now :-)
<wpwrak>
(see things only once) this is unfortunately very true ...
<wpwrak>
(parts list now) wow ! did you also modify the .sub for the value/value fields ?
<wpwrak>
(feedback) yup, feedback is good. it's just that you're quickly entering known bug territory when you look for things now strictly part of what boom touches. e.g., the connection via INFO files. that's something that's never been exercised. all the INFOs do for now is provide a place to put comments and references in a semi-formal way. until there's a script somewhere that actually checks for referential integrity or - even better - ac
<wpwrak>
tually does something with the data, they're completely unreliable.
<wolfspraul>
wpwrak: I'm slow, just beginning with .sub now
<wpwrak>
you'll find more problems e.g., in module naming. anything that's not in kicad-libs is to be treated with a great deal of suspicion
<wpwrak>
.sub is where the fun lies :-)
<wolfspraul>
ah yes, no worries. I won't bug you further on BOOKSHELF and components/INFO. It's all clear to me now.
<wolfspraul>
yes of course
<wolfspraul>
I will probably start with BOOKSHELF first.
<wpwrak>
a BOOKSHELF is a nice thing to have around :)
<wpwrak>
btw, dsv can work with a hierarchy. so you could have things for project/ and more specific things for project/subproject/
<wolfspraul>
I'm in no way worried about this deep-linking nonsense. If someone really comes forward with this, we will gladly remove deep-linking to their sites, and all their component characteristics and databases right with it. No problem.
<wpwrak>
e.g., if your project has two different mcus, you could have an alias "mcu" in project/foo/ and another one in project/bar/
<wpwrak>
not sure if it's really useful, but at least it's there :)
<wolfspraul>
I don't need that right now.
<wolfspraul>
my needs are very modest
<wolfspraul>
:-)
<wpwrak>
yeah, i think the deep-linking thing is excessive
<wolfspraul>
in fact I may even hard-wire many things, and bring in the logic later
<wolfspraul>
I just want to exercise the system, understand where it's going, etc.
<wolfspraul>
not run into all sorts of weird bugs now when it's not fully stable yet.
<wolfspraul>
btw I ran the queries against digikey, it took a few hours but it all worked. have over 11,000 parts locally now :-)
<wpwrak>
it may also have troubles in court, if it should come to that. most of the rulings that went very far in favour of the side being linked to are old, from times when judges didn't quite understand that internet thing yet
<wpwrak>
and then there are deep linking decisions in cases where there was clearly an abuse. such as pretending the data belonged to the linker. but we don't even remotely do such things
<wpwrak>
(digi-key queries) kewl :) when things have matured a bit more, it would make sense to provide database snapshots for easy download. if you bzip2 the database, is shrinks to only about 10%
<wpwrak>
you can see a very very early version of that idea in the "tar" target of eda-tools/boom/Makefile. but the file name doesn't make much sense yet, of course
<wpwrak>
ah, and to fully bring up boom, you also need to  cd manu; for n in *; do make -C $n; done
<wpwrak>
another one of these construction sites :)
<wolfspraul>
wpwrak: yes sure over time we should include multiple distributors, multiple manufacturers. and make it downloadable, definitely.
<wolfspraul>
one by one
<wolfspraul>
no need to get stuck on this now and let it bloat. using it for real projects is the best growth medicine.
<wpwrak>
yup. something you don't use has a very high risk of being wrong anyway :)
<wolfspraul>
wpwrak: ahh, did you see my older questions when you were asleep?
<wolfspraul>
about the fields for filters, whether I should say "BEAD 1A"
<wolfspraul>
and for the LED, similar, which fields you would use to record the color, or the Vf Typ (if at all)
<wpwrak>
oh, there were more :) checking ...
<rafa>
tuxbrain: I have news for you
<rafa>
tuxbrain: tuxbrain tuxbrain tuxbrain
<wpwrak>
(fields) the field name isn't exported to the .lst file, so boom doesn't care what you put there :) (and yes, i'd rather wish this was different)
<wolfspraul>
[field name] oh good point, I didn't think about that. So I can just use spaces then.
<wpwrak>
(led color) there's indeed a tricky issue here. what do you do with parts that change after the schematics ? you could have a per-production run .sub or .equ file, of course. not sure on which side of the fine line between relative sanity and raving madness this lies, though
<wolfspraul>
in my mind the design files, including .sub/.equ, express the full idea of the designer, including priorities
<wolfspraul>
so if people favor stability/quality, it will be expressed there
<wolfspraul>
and if they favor price, same
<wpwrak>
(specify as little as possible in general) yes, letting the price decide is usually a good idea :) if you over-specify, you may lead boom to exotic parts, either because they're at the end of the range of available values or just because the combination of values is rare
<wolfspraul>
what would you put in for the beads, specifically? (and the leds)
<wpwrak>
(-cache.lib) for some reason, i don't get this at all (in recent designs - i've seen it before, though). maybe i'm just lucky ;-)
<wpwrak>
(bead current) it's not the type of the bead. it's its maximum current :) i'd associate "type" more with the materials and physical structure of the bead.
<tuxbrain>
rafa: what hapens!!
<tuxbrain>
sorry I was little out
<wolfspraul>
I see you have some in ben-wpan, I will just follow what you did there.
<wpwrak>
the maximum current could be called something like I or Imax
<wolfspraul>
yes just saw it
<wolfspraul>
I will follow ben-wpan
<rafa>
tuxbrain: can you test something and tell me if you are a bit happier?
<rafa>
tuxbrain: (on nn)
<tuxbrain>
uff not until Wensday
<rafa>
tuxbrain: okey.. I will try to record a video
<wpwrak>
the ones in ben-wpan probably don't help much. there it's just size and inductance. they're inductors, not beads. (but don't ask me what exactly the difference is ;-)
<rafa>
tuxbrain:Â Â I need your opinion/suggestions to continue
<tuxbrain>
ok
<rafa>
tuxbrain: it is theora video ;)
<tuxbrain>
take for sure I will get it to it ASAP but I must end somthing with a dead line
<rafa>
tuxbrain: no problem.. but I think that these are good news.. so I will try to record something
<rafa>
tuxbrain: so you can check
<tuxbrain>
btw I love you rafa :****
<rafa>
ssshhh.. no our love here
<rafa>
it is logged, public, the whole world will know
<kristianpaul>
rafa: are you playing theora in ben mplayer with no slowness??
<rafa>
kristianpaul: yes.. but i did not do much.. it is almost working out of the box.. just that we are lazy and blind
<kristianpaul>
rafa: how is posible??
<kristianpaul>
(blind) indeed
<kristianpaul>
you finded better use for SIMD instructioons?
<kristianpaul>
you changed the way to encode ogg?
<wolfspraul>
wpwrak: are you sure? in atrf.sub, I have a D* TYPE=FILTER M=BEAD
<wolfspraul>
"BEAD" means inductor?
<rafa>
kristianpaul: yes, I was playing with mencoder and ffmpeg encode options
<rafa>
kristianpaul: and trying the theora player example which comes with libtheora
<rafa>
kristianpaul: but I realized that mplayer also is okey, or better than example
<wpwrak>
wolfspraul: ah .. right. i have something there. that's still untouched from gta02-core. as i said, i'm not entirely sure how to classify beads. my understanding is that they're basically inductors, but they're not specified in terms of inductance.
<wpwrak>
wolfspraul: rather, they're specified in terms of their filtering properties. so this would need someone with a bit more EE background than me to figure out.
<wpwrak>
wolfspraul: the current stuff is very pragmatic - i just map it in terms of use, even if this may not be "correct".
<wolfspraul>
wpwrak: k got it.
<wolfspraul>
so beads are not included in the current dist or manu databases yet
<wpwrak>
no, only smt ceramic caps and smt resistors
<wpwrak>
no inductors, no beads, no semiconductors, no non-ceramic caps, no though-hole, no connectors, etc.
<wpwrak>
that's why you still need those project-specific dk/ :)
<wolfspraul>
wpwrak: how does bom2part determine the namespace if the characteristics matching failed?
<wolfspraul>
for example in ben-wpan, there is ATRF meander
<wolfspraul>
in the .sub file, it only says FP=meander -> VAL=meander
<wolfspraul>
then there is an .inv file that gives virtual inventory for ATRF meander 999999 ...
<wolfspraul>
but how does it go from the VAL=meander to ATRF meander?
<wpwrak>
before characteristics mathcing, it tries value matching. if there's a part with part number == value, it takes that one
<wpwrak>
(irrespective of name space)
<wolfspraul>
oh
<wpwrak>
(see also my reply to adam ;-)
<wolfspraul>
I read that one, but it must have slipped my attention.
<wolfspraul>
I don't think this is mentioned in README.
<wpwrak>
(.inv) yup, that's what it usses
<wolfspraul>
sure I just didn't know where the translation from VAL=meander to namespace + part-number was made
<wolfspraul>
so if the VAL matches a part-number, no matter in which namespace, that always trumps everything else
<wpwrak>
yes
<wolfspraul>
got it
<wolfspraul>
I think this is not mentioned in README. Or under-represented.
<wpwrak>
README is very incomplete ...
<wolfspraul>
I think it's pretty good, I can recommend it to anyone else, definitely.
<wolfspraul>
like I said, I would only change the order of the sections.
<wolfspraul>
and this little missing 'jump' I found now, from value to part-number.
<wpwrak>
i'm also not sure if i really like this matching algorithm. it works well for small databases, but it may cause problems (i.e., false matches) if the database grows.
<wolfspraul>
you mean the one using characteristics?
<wpwrak>
perhaps boom should complain if there's more than one part number hit, and have some means for also specifying a name space
<wolfspraul>
or the one that turns a value into a part-number?
<wpwrak>
the latter
<wolfspraul>
ah yes
<wolfspraul>
it's a little risky :-)
<wpwrak>
i hope characteristics matching is relatively safe :)
<wpwrak>
to make characteristics matching even better, there should be a means to interactively query the database, like the parametric search in digi-key
<wolfspraul>
maybe a specific 'catch' in a characteristics file would be better?
<wolfspraul>
well sure, one by one. there are many ways to query and work with this data.
<wpwrak>
how would the catch work ?
<wolfspraul>
the catch catches a specific value, and maps it to namespace/part-number
<wpwrak>
(interactive) that way, one could poke around before committing to a set of parameters. e.g., if a part is under-specified, one would probably notice. likewise, if it's over-specified.
<wolfspraul>
actually I was looking for a atrf.chr file to do just that, because I didn't know how the VAL=meander would make it directly to the .inv file
<wpwrak>
ah, that's not a role for .chr files
<wolfspraul>
well yeah, so you just have an invisible direct bypass instead :-)
<wpwrak>
but you have the project-specific .equ and you can also do mappings in .sub (gta02-core has a lot of the latter. i don't like them so much anymore, though)
<wolfspraul>
yes but in the .sub you always stay 'behind' the characteristics barrier
<wolfspraul>
you are setting fields, but you cannot specify a namespace/part-number, or can you?
<wpwrak>
the sequence is: VAL -> PN match. if unsuccessful, do the substitutions, then
<wpwrak>
try VAL -> PN again. (.sub may substitute VAL). if you still don't have a hit,
<wpwrak>
do the characteristics search
<wpwrak>
.sub currently can't specify a name space. it can mess with the value, though
<wolfspraul>
yes I saw that already
<wolfspraul>
I see it like a .chr bypass
<wolfspraul>
set the val to a known part-number and you bypass the .chr
<wpwrak>
in a way, yes. there are basically two kinds of parts - the ones you identify by characteristics and the ones you identify by part number
<wpwrak>
e.g., there's little reason to try to select the Jz4720 by characteristics, for there are way too many that have to be exactly right (and they're heavily redundant, too)
<wpwrak>
but for things like reistors and the like, this works well. so characteristics are mainly for "simple" parts
<wpwrak>
for more complex ones, you'll always want just the part number
<wpwrak>
note that you can have a 1:n mapping by introducing your own PNs. e.g., you can have an equivalence QIHW BEN-CPU INGENIC JZ4720
<wpwrak>
if the make a JZ4721 some day that differs in some details but is sufficiently compatible, you could add an equivalence QIHW BEN-CPU INGENIC JZ4721. then boom could pick either.
<wolfspraul>
yes sure
<wolfspraul>
all fine, I just didn't know the VAL -> PN jump
<wolfspraul>
but now I do - thanks!
<wpwrak>
the schematics wouldn't change for this. of course, there's also the question to what extent this would affect the value of the schematics as documentation. if all the parts just have some "generic" value, you've just hidden all the useful information.
<wolfspraul>
yes of course
<wolfspraul>
the idea is to express in generic characteristics as much as possible
<wolfspraul>
keeping time contraints and short-term practical goals in mind
<wolfspraul>
so you start with ceramic capacitors and resistors - great!
<wolfspraul>
then we can add more, one by one
<wolfspraul>
I want to get my jtag-serial daughterboard made, 35 of them
<wolfspraul>
that's all
<wolfspraul>
after that don't know yet, maybe xue already? xue would be cool
<wolfspraul>
xue sourcing with boom :-)
<wolfspraul>
but then I'm pretty useless on adding new types to the characterized parts. I know too little about the electrical parameters. so I have to wait until you add some more groups of components.
<wolfspraul>
no rush though, the system is cleanly designed imo and should grow well
<wolfspraul>
and if it grows, the older, 'directly' specified parts could slowly become more generally characterized parts
<wpwrak>
for anything that isn't there, you can just go ahead, pick a part manually from a distributor, and add it to a project-specific .equ
<wpwrak>
yes, that too
<wpwrak>
that's what happened with the resistors and capcitors in atusd
<wolfspraul>
wpwrak: boom/READE says that the field-names are case insensitive, are the field contents also case insensitive?
<wolfspraul>
(I mean in .sub matching)
<wolfspraul>
so for example R* val=test -> ...
<wolfspraul>
will it also match if val is upper-case "TEST"?
<wolfspraul>
in my tests it seems to match, but isn't that somewhat risky in the field contents? shouldn't the field contents be matched case sensitive?
<wolfspraul>
the subsequent (direct) value to part-number matching seems to be case insensitive as well
<wpwrak>
hmm, yes, i upper-case the pattern
<wpwrak>
no, wait .. the field
<wpwrak>
the pattern should be "as is"
<wpwrak>
grmbl. xchat make it easy to clone a window by accident, but hard to close just the "bad" window ...
<wpwrak>
i need to examine this. for now, just don't count on it being case-insensitive.
<rafa>
wpwrak: clone a window chat?.. for what? I do not know how useful would be that
<wpwrak>
rafa: don't know either. but something i types cloned the window and when i tried to close one of them, the other had only useless tabs, so i had to exit xchat completely
<rafa>
argh
<rafa>
wpwrak: I did a script a lot faster than opkg using swap (script does not need swap so far).. But no idea if it is okey or if there are important bugs that I am not seeing.. because I can not believe that a script would be more useful/faster than opkg itself. I would like to have the enough time to learn opkg/ipkg/dpkg to debug/improve
<kristianpaul>
irsii !
<rafa>
wpwrak: currently, opkg using swap sucks.. and without swap it does not work. SO okey, I give opkg swap. But then, if you want to install, for example, tangogps.. opkg takes..... a looooong time.. maybe 20minutes, yes
<rafa>
script takes around 4min or less
<wpwrak>
rafa: opkg probably does something extremely inefficient. i can't imagine you really need all that many resources for such a task
<rafa>
wpwrak: (opkg) it is happening because the repositoy is huge. If you have a small repo, like openwrt you do not need swap with opkg and it is fast.
<rafa>
wpwrak: yes, I guess that.. because the script is a shit and it works without swap to do the task
<kristianpaul>
rafa: you can drop some stuff in the repo, no?
<wpwrak>
(huge repository) still ... how many packages ? and how big is the typical meta-data in a package ?
<kristianpaul>
i dont need all the repo for my Ben
<kristianpaul>
just popular and suguested packages
<kristianpaul>
may be an alternative light repo
<rafa>
kristianpaul: you can do that :).. I mean, I do not have idea how to do the repo smaller properly. We can modify the "packages" files which tells opkg which packages are available. You can modify that to have just a small thing, and opkg will be happy
<rafa>
kristianpaul: but anyway, why would we like to have a small repo?.. is not openwrt small? we could use openwrt if we just need a small one
<kristianpaul>
small is relative ;)
<rafa>
wpwrak: around 15.000 packages. metadata? what do you mean?.. the data which tells opkg which is the name of package, version, files, dependences?
<wpwrak>
rafa: yes, that sort of information
<rafa>
wpwrak: then that metadata is into some text files.. you can have just one if you want.. Currently, there is just one huge of those text files.. :
<rafa>
Jlime$ du -sh /var/lib/opkg/packages-mipsel
<rafa>
11.0MÂ Â /var/lib/opkg/packages-mipsel
<rafa>
wpwrak: and opkg, if I read well some forums or posts a time ago does a dependes tree on memory.. but then also when it downloads the packages it tries to unpackage and process the package on memory, so that tasks also fails
<wpwrak>
oh. i see ... so ... 11 MB. probably with a lot of redundancy. shouldn't take more than ~5 MB of RAM.
<wpwrak>
(unpack in memory) maybe that's the problem then
<rafa>
wpwrak: yes, that is a problem, but before to download the packages opkg also fails to decide which packages to download
<rafa>
wpwrak: so there is another problem before to know which packages to download as well.
<logictheo>
I've put the battery in the Ben Nanonote and I connected the usb cable afterwards. There is a red light(which I think means it is charging or connected). Is it charging?
<logictheo>
If it is charging will the red light change to something else when it is charged?(if it is being charged)
<logictheo>
I'm looking in the irc logs (which are helpful, searched for 'red light' and I find lots of info)
<logictheo>
I found this "the red led should turn on if it charges the battery"
<logictheo>
Wonderful search feature for the irc logs. I also like the colors that are used.
<mth>
does anyone have experience with SDIO bluetooth cards?
<logictheo>
this which I found in the irclogs will also help me I think "remember to charge the battery for a while first time :P (it's an urband legend?)"
<wolfspraul>
logictheo: you speak good about the irclogs - thanks! :-)
<wolfspraul>
one thing that bugs me is that somehow utf-8 is broken somewhere, accented and foreign characters are garbled. need to look into it one day, maybe something simple...
<logictheo>
:)
<B_Lizzard>
Hi, larsc, any update on the kernel?
<larsc>
B_Lizzard: nope
<B_Lizzard>
OK
<zear>
B_Lizzard, you mind to try commander genius?
<wpwrak>
logictheo: (charge batt) i think it's an urban legend in this case :) you needed the long initial charge with older battery chemistries, and everyone copied these instructions ever since, even for lithium batteries. however, there can be lithium batteries that do need a full cycle before their control logic will be fully initialized.
<wpwrak>
logictheo: but the ben's battery doesn't have this sort of fancy internals :)
<wpwrak>
rafa: (package dependencies) okay, but if you have /var/lib/opkg/packages-mipsel/*, you could calculate the dependencies from this file, correct ?
<rafa>
wpwrak: yes.. the exact file is /var/lib/opkg/packages-mipsel .. and you can calculate the dependencies from there. In fact the script reads that file
<rafa>
and opkg as well
<wpwrak>
so it all should be easy :)
<wpwrak>
is there a /var/lib/opkg/packages-mipsel somewhere where i could easily download it ?
<kristianpaul>
wee now i have my own 3D printer coneyor :D
<wpwrak>
kristianpaul: now we can close down china and move all the mass production to you :)
<kristianpaul>
wpwrak: wich is the folder in your wpan with the sofware that goes to the ben?
<kristianpaul>
atrf?
<kristianpaul>
ah
<kristianpaul>
the TODO is really informative
<wpwrak>
kristianpaul: tools/
<wpwrak>
TODO is scary :) still so much to do ...
<kristianpaul>
i realiced that
<wpwrak>
rafa: whee, that should compress down to almost nothing :-)
<wpwrak>
rafa: especially if you read it twice. in the first run, you just collect package names and version, in the second run, you resolve the references. so references directly become pointers.
<wpwrak>
or, if you want to make it really small, use 16 bites for the package index and maybe 8 bits for the version ;-)
<viric>
I'd like to reverse engineer a simple usb device
<viric>
Any advises? I have a windows program that can talk with it.
<viric>
It's a temperature sensor.
<wpwrak>
if it's so simple, it may be quicker to make your own, open hardware, naturally ;-)
<viric>
hehe
<viric>
well, it's more about the case and all that.
<wpwrak>
okay, it is memory. an EEPROM. that make sense then. the c8051f32x don't have an EEPROM.
<viric>
aha
<wpwrak>
now you just need to reverse-engineer the sensors and then you can make your own firmware. sdcc supports the c8051f32x series. and there's an in-circuit flash programmer for them in the qi-hardware project f32xbase
<viric>
ah, wow. what a coincidence.
<wpwrak>
(added it ... almost two days ago :)
<viric>
really?
<viric>
I own this thing since years.
<wpwrak>
yup. before i used the openmoko freerunner plus a debug board for programming.
<viric>
it's an i8051 architecutre?
<wpwrak>
i use the chip in a number of designs, idbg, atusb, and cntr
<wpwrak>
yup
<viric>
I did a project on ds5000 loooong a go
<viric>
ago
<wpwrak>
with built-in usb
<viric>
It should have a very good sleep power consumption
<viric>
because this thing has a battery that lasts very long
<wpwrak>
it seems to have very little leakage, yes. alas, the minimum voltage is relatively high. so you can't use a CR2032 or such under load.
<viric>
it has a 3,6V battery
<wpwrak>
well, at least that's what i conclude from the data sheet. maybe it runs well far outside the specs.
<wpwrak>
okay, that helps :_
<viric>
cr2032 is 3V, is it?
<wpwrak>
yup
<viric>
It has another chip: IR1C / P728L
<viric>
it looks fat, and with a band at a side, like a diode
<viric>
two pin
<viric>
(maybe I should not call it a 'chip')
<wpwrak>
and minimum voltage is around 2.7 V. 300 mV isn't much, particularly for batteries with a high resistance.