<wolfspraul>
wpwrak: (you are probably sleeping, but I just stack it here...) the component references (last field) in the order list (.ord file) are the references from the original kicad bom, correct?
<nitin_gupta>
need some help with micro SD card
<nitin_gupta>
can anybody help
<wolfspraul>
wpwrak: hmm. another advantage of using the .csv coming out of pcbnew is that I believe one .brd file always exactly equals one board, but multiple .sch pages can lead to one .brd
<wolfspraul>
(all questions actually)
<wolfspraul>
so thinking about automating some things on the server, we could auto-generate the .csv bom more safely for each .brd. for the .sch, we would need to find the root .sch like schhist?
<wolfspraul>
wpwrak: clarification for the parts list documentation (.par), README 240ff. does each reference have to appear only once in the file, or will multiple lines refering to the same reference be merged?
<nitin_gupta>
i want to suppress error message in linux script
<nitin_gupta>
how to do that
<kyak>
nitin_gupta: find out where this error message goes from and solve the root of problem
<wolfspraul>
wpwrak: why is the description file .dsc not included in the inventory file .inv?
<nitin_gupta>
while doing ssh getting "permission denied , publickey gussapi- with -mic password"
<nitin_gupta>
I am not able to login into NN using ssh or scp
<wolfspraul>
wpwrak: in CHARACTERISTICS, line 63, it says "Each catalog entry begins with a part number followed by a part type designator."
<wolfspraul>
I assume the CHARACTERISTICS file is a bit older, and meant to describe the .chr file mentioned in README?
<wolfspraul>
if so, should this be "Each catalog entry begins with a namespace followed by a part-number."?
<wolfspraul>
oh maybe it's namespace followed by part-number followed by part-type-designator? not really sure whether the designator is a must, also CHARACTERISTICS doesn't seem to list all designators
<wpwrak>
wolfspraul: (.par) in the file, each reference for which the system found a suitable entry appears exactly once. (it actually does the full lookup for each, too. there's some potential for optimization)
<wpwrak>
wolfspraul: (.csv vs .lst) yes, you'd have to find the root for eeschema. i don't know if both formats are equivalent, though.
<wpwrak>
wolfspraul: (.ord) yes, these are R123, R124, etc. one example from atusd.ord: DIGI-KEY RMCF0402ZT0R00CT-ND 2 USD 0.04 R1 R2
<wolfspraul>
hey :-) now I need to check back in the logs what my questions were :-)
<wpwrak>
(scrolling back .. ah, there's more :)
<wolfspraul>
I just had another one - do you foresee that there will be a global .sub and .gen, or can they be project specific?
<wpwrak>
(.lst documented) i kinda doubt it ;-)
<wpwrak>
.gen is specific to the manufacturer and maybe even for parts families. maybe some manufacturers can share a gen but that would be somewhat unusual
<wolfspraul>
for .csv vs. lst, after understanding sub and gen I think you will want the flexibility in the custom fields, F1..F8, FN, etc. I believe those things are missing in the .csv generated by pcbnew
<wpwrak>
(maybe if you express something like 74xx via characteristics, you could share it. haven't really thought of this. it's probably very tricky.)
<wpwrak>
a .sub could be shared by all the projects that use a common annotation style
<wolfspraul>
but it looks like there is nothing project-specific in .sub or .gen
<wolfspraul>
at least we could say so and make the system more powerful, of course the projects on the qi-hardware server then have to follow that usage of the fields
<wolfspraul>
wouldn't it make more sense to accumulate site-wide .gen and .sub over time?
<wolfspraul>
I see it more as part of boom than as part of a project.
<wpwrak>
the idea is that .gen can be shared among projects. e.g., all projects can use the same murata parts characteristics. much like everyone uses the same parametric search at digi-key.
<wolfspraul>
but you tell me...
<wolfspraul>
yes exactly
<wolfspraul>
sounds like we should just make site-wide (qi-wide) defaults for those things, I don't see why anybody would want to override them right now since nobody uses the system yet anyway
<wpwrak>
.sub is more subtle. i would think of some sort of style guide that explains exactly how to annotate things. maybe you remember that we spend quite some time in gta02-core to define these details. e.g., 1.2 kOhm vs. 1K2 vs. whatever
<wolfspraul>
yes of course
<wolfspraul>
I followed closely because I think it's quite important.
<wolfspraul>
people can do whatever they want, but I am wondering what we should automate on the qi server
<wolfspraul>
we can just declare a default notation with which boom works best, no?
<wpwrak>
boom is agnostic to what you to in .sub. it's even fairly agnostic to how you specify things in .chr. it's the .sub that brings the two together.
<wolfspraul>
I mean 'default' for Qi
<wolfspraul>
yes I understand, but I'm thinking about running this on the server
<wpwrak>
(default qi style) yes
<wolfspraul>
the notation you defined for gta02-core is perfect for me
<wolfspraul>
I mean I have zero arguments why we shouldn't just use it everywhere.
<wpwrak>
btw, there can be more than one .sub file :) a project may have some "local" quirks. or explore areas the shared policy hasn't touched yet.
<wolfspraul>
it's not about forcing someone into a notation, it's just that maybe at this time, I don't need to think how we can override project-specific .subs when nobody is using them anyway
<wolfspraul>
sure
<wolfspraul>
but it sounds like we can start with a qi/site-wide .sub and .gen system
<wolfspraul>
because the data in these files either has nothing project-specific (.gen), or should not if they follow a well thought through notation (.sub)
<wolfspraul>
well whatever you tell me, I'm just reading and thinking
<wpwrak>
(reuse gta02-core style) depends a bit. the gta02-core style was also influenced by gta02. i tend to prefer things a little more verbose. i also find adam's? carlos'? compact way of adding tolerances interesting.
<wolfspraul>
I think I worked my way through the old svn boom, I continue in the git boom now :-)
<wolfspraul>
yes but we are small now, we can just come up with one notation and make it the default.
<wolfspraul>
I'm not against overrides but it soudns like right now (!) they are not needed, neither for .gen nor for .sub
<wpwrak>
for .chr, you may also have new parts. i like the ability to "test drive" things in a project and to only push them into the common repository once they're sufficiently validated.
<wolfspraul>
did you see my comment about CHARACTERISTICS line 63/64
<wpwrak>
e.g., i do the same with footprints. i keep them in the projects until i'm happy with them. only then may they migrate into kicad-libs.
<wolfspraul>
of course, makes sense
<wpwrak>
(more questions) getting to them ... LIFO order ;-)
<wolfspraul>
correct me if I'm wrong, my impression is that bom2part tries to deal with the technical/electrical aspects, while part2order tries to deal with the business/financial aspects
<wolfspraul>
is that a fair characterization of the design?
<wpwrak>
(comp by value) this one isn't used and it's simply ignored if it's there. if you check comp by value but omit comp by ref, then boom will get confused, because it finds them by position not by any name. (anything that could serve as a designator is cleverly i18n'ed, so there's no way of reliably identifying them. well, i could just parse it and see if one is always Rnnn followed by non Rnnn or such. ugly heuristics, though.)
<wpwrak>
(sub comp) not really sure what this does
<wolfspraul>
[comp by value] ok I will leave comp by value unchecked then, it's not meant to be checked in the context of boom. understood.
<wpwrak>
(CHARACTERISTICS) it's older and possibly inconsistent, like it says at the very beginning ;-) it really ought to become a style guide and not so much a file format description.
<wpwrak>
(CH...) it's actually  names-space part-number field=value tuple(s)
<wolfspraul>
yeah that's what I thought. so what is called 'type designator' in CHARACTERISTICS is just a regular field now
<wpwrak>
(CH...) the part type is no longer special. e.g., you could even have a hierarchy with sub-part-types.
<wpwrak>
(CH...) the part type is now expressed as T=part-type. and i also made the designators shorter, R, C, ... (see the .sub file :)
<wolfspraul>
which .sub file?
<wolfspraul>
I am still exclusively in the old svn boom
<wolfspraul>
I think I am ready for the next level, will move to the git boom now :-)
<wpwrak>
the .chr file format may change even more. e.g., with a better parser, perhaps i could omit the field names and have a more table-like structure instead. the background is that .chr is something a human may occasionally have to write manually, and there, one would want to avoid having lines > 80 characters. so anything that helps keep things short is good.
<wpwrak>
(which .sub) gta02-core/bom/gta02-core.sub, ben-wpan/bom/atrf.sub, eda-tools/boom/test/test.sub, they're all very similar
<wolfspraul>
yes I'm looking at the test.sub now
<wolfspraul>
ok I will move to git boom now and dig around there
<wpwrak>
(.dsc not included in .inv) mainly for parser convenience. BUT ... you could also have different sources of descriptions. and you may even switch among them in the course of processing.
<wpwrak>
e.g., your EE design group could use descriptions conforming to some "local" standard, while the sourcing group may want to look at the supplier's descriptions (which may be of varying quality)
<wolfspraul>
[.dsc not in .inv] yes and I noticed in general you try to keep things in separate files a little, like relational tables in the filesystem. rather than loading things into fewer files. makes perfect sense I was just curious whether there were any special considerations.
<wpwrak>
(gta02 is a good example for when it makes sense to override descriptions. the fic descriptions are almost always more detailed than the ones by digi-key. also, if you have, say, chinese suppliers only providing chinese descriptions, or the same with spanish, then you may want to use an english version for a globally shared project)
<wpwrak>
(relational tables) exactly :) that's what all this really is in the end
<wpwrak>
(quantity field in pcbnew's .csv BOM) the idea is that this BOM would be worked on by human BOM processors. they wouldn't like to do the same part 100 times :)
<wolfspraul>
[quantity field] good point. although the number of comma separated items in the "Designator" field probably always must match the Quantity field. But sure, for humans looking at a number is far better than counting commas.
<wpwrak>
(qty) it also helps to keep the keys in the table (if you consider it as one) unique. boom shouldn't really care. and .par should have a quantity field.
<wolfspraul>
well I think that decision (pcbnew's bom vs. eeschema's bom) is already settled
<wpwrak>
in fact, .par is one file i could imagine getting rid of
<wolfspraul>
you need the custom fields, and afaik they are only in eeschema's bom
<wpwrak>
i don't now yet. all i know is that eeschema's bom works for me :)
<wpwrak>
also, the bom stuff in kicad my change before too long. there's been talk about this.
<wolfspraul>
wpwrak: yes it may change, but given the scope of boom I don't think kicad will attempt something so broad?
<wolfspraul>
which means that whatever changes will just trigger some 'smaller' changes for boom
<wolfspraul>
or no?
<wpwrak>
yes, i don't see any real issues there. just that it doens't make much sense to "optimize towards the current implementation"
<wpwrak>
e.g., the absence of a dialog may not last
<wolfspraul>
wpwrak: would you agree with my characterization of the bom2part/part2order design?
<wpwrak>
hmm, which characterization of these two ?
<wolfspraul>
wpwrak: my impression is that bom2part tries to deal with the technical/electrical aspects, while part2order tries to deal with  the business/financial aspects
<wolfspraul>
how can I help with boom now? in which way can it run on the server?
<wpwrak>
(tech vs. biz) yeah, that's pretty good
<wpwrak>
(run on the server) i think it's a bit premature for this. we first need some more infrastructure.
<wolfspraul>
ok my impression is that bom2part tries to deal with the technical/electrical aspects, while part2order tries to deal with  the business/financial aspects
<wolfspraul>
oops :-)
<wolfspraul>
ok I will try to use it locally a bit then
<wpwrak>
(help) part of the infrastructure would be more parts definitions, be it equivalences or characteristics :)
<wolfspraul>
although right now I'm a little confused because there is so much construction going on
<wolfspraul>
there's the stuff in the svn.openmoko location, then the stuff in git/eda-tools
<wolfspraul>
seems no connection between the two?
<wpwrak>
also, the characteristics need to get fleshed out a bit more. e.g., there my be relevant parameters i'm not including of that i'm not handling well
<wolfspraul>
you talk about C, but I can't see that committed yet?
<wolfspraul>
well that's the hardest part for me to help, lack of competence
<wpwrak>
rome wasn't built in a day :)
<wolfspraul>
I'm very eager to learn, but the best way to do so is probably by following/reading the boom sources, and trying it locally for some small projects
<wpwrak>
the boom "core" is still in svn. the git part is mainly about building a better database for now
<wpwrak>
there's not a single line of C so far. only in my head ;-)
<wolfspraul>
ok next step for me: try to run it locally
<wpwrak>
yup :)
<wpwrak>
regarding schedule, i don't think boom will be ready for general consumption before the end of the year. it's now a t the point where it can do some nice tricks, but you still fall into a hole where you have to provide infrastructure very often.
<wolfspraul>
that's all fine, but I believe the only way to get it over the mountain is to start using it in reality
<wpwrak>
e.g., this weekend's burst of activity was basically just to help me buy a few dozen different resistors.
<wolfspraul>
so I will do my part on that, those discussions here help, and we take it from there
<wolfspraul>
like you said, Rome was not built in a day
<wolfspraul>
I don't expect to do an apt-get install boom and then somehow magically 'everything' works, where we are not even clear what that 'everything' is. no worries.
<wolfspraul>
yes I can imagine :-)
<wolfspraul>
like I said, need-driven, very good
<wolfspraul>
but a goal of getting this to the point of 'general consumption' like you say, or that every KiCad project on the qi server can benefit from it, is a nice goal
<wpwrak>
the problem with people using it now is that all these holes become blockers for them. and uncharted areas may need some improviding (lest they become blockers, too), so a legacy incompatible with future changes may grow there
<wpwrak>
that's why i want to do a bit more trailblazing first
<wolfspraul>
fully agreed
<wpwrak>
right now, the best "use" of boom is to basically play with it. take an existing project, generate the bom, vary things a little. stuff where the basic are known to work and where you can always walk away from things that don't work
<wolfspraul>
yes
<wolfspraul>
so it's perfect for me :-)
<wpwrak>
putting it on the server is the least of my worries :) interactive use is more important if you need to make a real shopping list. the one on the server would likely be more informational.
<wolfspraul>
I can learn more about those pesky parameters and what you call 'characteristics'
<wolfspraul>
well that depends, I can definitely imagine the server being very very useful
<wpwrak>
(or get complex. e.g., how would i include local suppliers ?)
<wolfspraul>
especially if we collect large components databases on the server, and if we slowly improve the .sub and .gen files
<wolfspraul>
yes sure
<wolfspraul>
I would do this step by step
<wolfspraul>
first make it run, with global defaults
<wolfspraul>
people see the results, use them either as-is, or in copy/paste fashion, or they install boom locally
<wpwrak>
i don't like the idea of a web-centric system where people maintain their files (supplier preferences, supplier-specific equivalences, etc.) in some central database
<wolfspraul>
yes I agree
<wolfspraul>
but seeing the results with global defaults, and some strong server-side databases and .sub/.gen sets will make them want more
<wolfspraul>
I am in no way going to implement some account system with uploads of preferences etc.
<wolfspraul>
no time for that :-)
<wpwrak>
a "one size fits all" web interface would have to be simple and would be somewhat limited in what it can provides. maybe you could have a few basic profiles to pick, e.g., "show me US or EU sources", but that would be the most i'd do there
<wolfspraul>
given our projects and people, most actual runs will be < 100 anyway
<wolfspraul>
yes
<wolfspraul>
totally agree
<wolfspraul>
like I said, the key is to show the power, show a good default
<wpwrak>
it's not the run size :) in fact, smaller runs are even more sensitive to things like shipping charges
<wolfspraul>
and to have nice server side databases with parts from the big manufacturers, distributors
<wolfspraul>
I don't even see it like that. I just want to make this bom/shopping experience less mysterious, get some computing power behind it.
<wpwrak>
(show the power) yeah. getting people to migrate to boom (instead of excel-based sourcing or whatever) is good.
<wpwrak>
i hope cpu power won't be the bottleneck :) i'm more concerned about database size and update rate
<wolfspraul>
also like I said, I see big value in large manufacturer/distributor databases on the server, and a slowly optimized global set of good .sub/.gen files
<wolfspraul>
if cpu power is a bottleneck, I'll get bigger servers :-)
<wolfspraul>
that's the whole point, let the servers do some work, show it to people in a browser
<wolfspraul>
at that point they have many options
<wolfspraul>
no accounts, no upload of preferences, definitely no shopping or payment system routed through the qi servers
<wpwrak>
i think you need a local copy of the database. going to the network for each query would be way too slow. running the db on the server would complicate the design.
<wpwrak>
what the server can do is simply answer the FAQ "how much are the parts ?"
<wolfspraul>
why not just run the whole thing on the server? fully automated
<wpwrak>
give people some idea of what a project costs
<wolfspraul>
ah yes, of course
<wolfspraul>
like I said, it should all be fully downloadable
<wolfspraul>
but at any given time, the server can have actual large databases of manufacturers and distributors locally (on the server's hdd)
<wolfspraul>
so it can show what boom can do
<wolfspraul>
that's not a bad thing, and not at all meant against downloading and running things locally
<wpwrak>
(run on the server) doesn't work too well for doing new things. also, given that you already have a large database, you can do more with it, e.g., do a parametric search to select component values.
<wolfspraul>
you mean if you have that database locally?
<wpwrak>
yes
<wolfspraul>
he
<wolfspraul>
yes
<wolfspraul>
I fully agree with you.
<wolfspraul>
I am thinking about another case.
<wpwrak>
fast turn-around times. etc. :)
<wolfspraul>
some newbie comes to our server
<wolfspraul>
totally from outside
<wolfspraul>
he is thinking about taking a project, say xue, and turning it into something different for his customers
<wolfspraul>
by _showing_ him boom in action, live on the server, he can get a better feel for how much time & money he needs to invest from just browing through the project files, to being able to sell stuff to his customers
<wolfspraul>
that's a big black hole right now
<wolfspraul>
of course _you_ can imagine, because you know boom already
<wolfspraul>
but how do we visualize it?
<wolfspraul>
I think by just installing and running it on the server, with global defaults.
<wpwrak>
hmm, seeing boom in action won't tell him that much :)
<wolfspraul>
if you then go ahead and actually do a run (maybe even a customized/derived product), in many cases you will take everything local.
<wolfspraul>
sure he sees how easy it is to create shopping lists
<wolfspraul>
that gives him confidence that the entire project is actually usable in real life
<wpwrak>
what seeing boom in action does tell you is what things will be like for sourcing
<wpwrak>
(well, a little. i currently don't show all the goodies. but that could change)
<wolfspraul>
yes. and that's a great value I think.
<wpwrak>
it will show him that a way to create a shopping list exists, correct
<wpwrak>
then there will be the BIG style guide explaining what rules to follow :)
<wpwrak>
and then a download of a few MB (compressed) worth of database. install BOOM and you're set :)
<wolfspraul>
of course if you make a decision to join, produce the product or derived/customized product, you take things locally and it will still work
<wolfspraul>
yes
<wolfspraul>
and with real life data, real manufacturers, real distributors
<wolfspraul>
so when he decides to take on his project, he has more confidence that those things will work, and he can focus on his customizations
<wolfspraul>
yes
<wpwrak>
btw, one of the reasons why i added a ton of common resistors and caps is to eliminate one such black hole. it's very annoying if even just changing one resistor value means that you have to switch to sourcing mode and play with digi-key for ten minutes to bring the BOM up to date again.
<wolfspraul>
oh sure
<wolfspraul>
I think we see the potential of boom similarly
<wolfspraul>
so: I will first play with it locally, and the goal is to get it to the point that it can automatically run for every KiCad project on the qi projects server
<wolfspraul>
in a few months...
<wolfspraul>
I finished my introductory reading session :-)
<wolfspraul>
and thanks a lot for answering all my questions!
<wpwrak>
as i said, i wouldn't worry much about the server for now. that will be a byproduct. the important use is local.
<wolfspraul>
the server is our advertisement so that there will be more local use
<wpwrak>
and there are still a number of prerequisites before local use is ready for prime time. including rewriting the mess in Perl, and fattening the database
<wpwrak>
yes, it can work as advertizing
<wpwrak>
once prerequisites are done, then we can work on the style guide. this will be a lot of work, also because there are many exotic components to deal with.
<wpwrak>
for now, i just focus on very mainstream parts, but each project needs a few "strange" items
<wpwrak>
also, i completely ignore packaging for now. so all you get are "cut tape" prices and order numbers. no tape and reel. you'd have to do that manually.
<wpwrak>
(it's not too horrible a task, considering that you're probably putting some serious work into it when you start thinking about buying t&r. but of course, if automation can save a day or two in digi-keys' online order system, that's welcome)
<wolfspraul>
all good
<wolfspraul>
step by step
<wolfspraul>
first you have a second user now :-)
<wolfspraul>
and more clueless user, which is a good test...
<wpwrak>
yep :)
<wolfspraul>
oh and it's not just digikey
<wolfspraul>
if it would be a digikey only system I would be far less interested
<wpwrak>
sure, you can add any distributor :) digi-key just have what's probably the nicest database
<wpwrak>
then it goes all the way down until you finally reach those gazillion "call for a quote" shops all around asia
<wpwrak>
(and their sometimes quirky part numbers)
<wpwrak>
i should probably also have a table that shows when a part's record was fetched from the distributor
<wpwrak>
particularly if the process is manual, things can get very old
<wolfspraul>
the system is flexible enough to accomodate more large-scale sources later
<wolfspraul>
and it is strong on characterizing parts (or will be strong :-)) dealing with substitions, equal parts, etc. etc.
<wolfspraul>
if it works well one day, it's a huge difference to make free designs a hardware reality for someone who wants to make money with them, not just look at them in admiration
<wolfspraul>
there are serious sourcing companies in Asia too, of course. and boom will easily accomodate their 'api' later.
<wolfspraul>
good idea
<wpwrak>
sounds good, yes. the idea is that boom is very open. that's also why documenting a good workflow is important. boom will not constrain or guide you much, but the consequences might :)
<wolfspraul>
documentation you have now is not bad
<wolfspraul>
the xfig chart is nice, although some fic parts in there are probably outdated
<wpwrak>
yeah, the chart needs work :) there's also new stuff that's not included
<wolfspraul>
the order the files in README are described is a bit strange, it starts with the 'harder to understand' concepts like .sub and .gen
<wolfspraul>
I read it bottom-up
<wpwrak>
README is more or less in the processing sequence. but yes, bottom-up may work better.
<wpwrak>
i'm not too unhappy with README. but that's the plumber's guide to boom
<wpwrak>
CHARACTERISTICS is what should eventually be the EE's manual
<wolfspraul>
it's nice
<wpwrak>
the EE's manual should also discuss various styles. show how they can be implemented. explain a bit the advantages/drawbacks.
<wpwrak>
maybe have a multiple choice for each style decision. so you can define your project's rules just by checking items :)
<wpwrak>
boom also needs more work on the error reporting. e.g., it's relatively easy to miss it if it doesn't find a part. there's no explicit "what went wrong" report, only what the individual stages print at run time.
<wpwrak>
and it debugging something that went wrong is difficult. particularly if there problem is in .sub (can also happen if you feed it bad input, so you don't have to be writing the .sub yourself)
<wpwrak>
so, still a bit more work. we'll get there, eventually :)
<kyak>
B_Lizzard: hi! how is your luck with nupdf?
<B_Lizzard>
Gave up :D
<B_Lizzard>
For now
<kyak>
he-he
<B_Lizzard>
Some of the stuff needs a lot of work
<kyak>
indeed
<B_Lizzard>
Changes between mupdf 0.5 and 0.6 are very large
<kyak>
i would say that nupdf requires for complete re-write, as it's underlying library, mupdf, was completely re-written
<kyak>
yeah
<kyak>
but you could have more luck with mupdf X11 app itself
<kyak>
cause there is X11 in Jlime
<kyak>
i would like to give a try to fbida (which offers fbgs that can display pdf files with the help of ghostscript)
<kyak>
this, of course, requires gs and fbida :)
<B_Lizzard>
Well, from my experience with the HP Jornada, the only things that will work is mupdf and xpdf, in a lesser degree
<B_Lizzard>
Some of the mupdf keybindings don't help but that can be fixed
<B_Lizzard>
Having an SDL frontend is nice but if it doesn't compile it's useless :D
<kyak>
same to be said about the mupdf lib.. it might be nice and fast, but it's zero documented and developers tend to make major changes in it's design, so it's useless ,t oo
<B_Lizzard>
Oh well...
<B_Lizzard>
:)
<B_Lizzard>
At least it exists
<kyak>
yes, that not so bad :)
<kristianpaul>
xiangfu: there?
<xiangfu>
kristianpaul: yes
<kristianpaul>
nerase 16 512 0 0
<wolfspraul>
qi never sleeps
<kristianpaul>
:)
<kristianpaul>
vs nerase 0 4096 0 0
<kristianpaul>
xiangfu: the nerase in reflash script is suppposed to preserver something?
<kristianpaul>
of data*
<xiangfu>
kristianpaul: no.
<xiangfu>
oh.. yes.
<kristianpaul>
:|
<xiangfu>
the 0 to 16 is u-boot and kernel image.
<xiangfu>
it's nand block 0 ~ 16. which 0 ~ 7 is bootloader (u-boot),  8 ~ 16 is kernel
<xiangfu>
513 ~ END is data partition.
<xiangfu>
16 ~ 512 is rootfs partition.
<kristianpaul>
I'l add to the wiki
<xiangfu>
kristianpaul: seems it's already in  wiki. let me find
<kristianpaul>
u-boot goes to page 0, Linux kernel to page 1024, rootfs to page 2048
<kristianpaul>
but you explain me it now in blocks, is nt?
<kristianpaul>
i'm just flashing my ben again but dont want run nerase 0 4096 0 0
<qbject>
Hey all. I've got a BNN running OWrt as it was when I got it in August. Does switching to a smaller font still require compilation, per the FAQ?
<qbject>
(Hi, zear!)
<zear>
hey qbject
<zear>
i'm not an expert, but you shouldn't need to recompile just to change the font of the terminal. There was a command for that
<zear>
unfortunatelly i don't remember that command
<qbject>
If xdpirate shows up I'll ask him.
<qbject>
zear: So, nethack-newt was a no-go on OWrt, even with additional libs.
<zear>
qbject, this could explain why most of the dingoo binaries don't run on jlime
<zear>
i guess it must be something with the core stuff, i don't know, glibc or something
<qbject>
Is jlime compiled with uClibc?
<zear>
anyway, you could try jlime, it doesn't require flashing, it can boot from sd
<zear>
no idea, but probably yes
<qbject>
Oh! I hadn't thought of that. I'll get a space uSD some time soon and give it a try. Thanks for the suggestion.
<zear>
and how are the dingux libs you've transplanted? Does dingux stuff run on your nanonote now?
<qbject>
Not everything.
<qbject>
OpenTyrian and CDogs are both a bit slow, but run.
<qbject>
There's an interpreter for an old vector-rendered adventure game whose name I'll not utter that runs, if slowly.
<qbject>
(OpenTyrian is actually quite nice at lower detail settings.)
<zear>
the thing is a lot of dingux apps convert the colordepth to 16bpp
<zear>
and nanonote then converts it to 32bpp
<qbject>
Needless overhead.
<zear>
so instead of 8bpp > 32bpp, it is 8bpp > 16bpp > 32bpp, so i guess that can also waste cpu
<qbject>
I've heard that as well.
<qbject>
Without shoulder buttons I haven't found a good keymap for wolf/doom/quake, but they all go to some degree.
<zear>
qbject, you can try m/+, as they're close enough to the arrow keys to be easy to press in fast paced gameplay
<mth>
zear: for 8bpp games, they should just an 8bpp surface from SDL and then SDL can convert it in one step to 16bpp on the Dingoo and to 32 bpp on the NN
<mth>
*just request
<mth>
that doesn't work though on booboo's kernel + rootfs
<mth>
for 16bpp games, it might be useful if the NN kernel also had 16bpp support
<zear>
mth, i know, but most of the games were designed for booboo's kernel
<mth>
afaik the input pixel format and the output pixel format are independent, but I don't know the LCD controller very well
<wpwrak>
ssh root@tuxbrain.com  # let's see if he reuses passwords :)
<bartbes>
:P
<tuxbrain>
heheheheh
<tuxbrain>
not so easy
<wpwrak>
darn :)
<tuxbrain>
well whatever if you success to enter, please I have some manteinance task to do there heheeh
<wpwrak>
tuxbrain: now there's an interesting "honeypot" concept :)
<bartbes>
I think  really need to set up a script to change some passwords on command
<bartbes>
just in case
<qi-bot>
[commit] Werner Almesberger: Avoid leading zeroes in resistance and capacitance values (except 0R) http://qi-hw.com/p/eda-tools/2744057
<wpwrak>
hmm, is anyone around here familiar with the FTDI chips in bit-bang mode, async or sync ? (not MPSSE)
<kristianpaul>
afaik i dont
<roh>
wpwrak not really. why?
<wpwrak>
:-(
<roh>
wpwrak there are some libs for speaking to that stuff
<wpwrak>
i'm trying to send certain bit patterns. but the chip acts very very weird.
<wpwrak>
oh, sure. i'm using libftdi
<roh>
the open one?
<wpwrak>
yup
<roh>
hm.. i think thats the one openocd also used on moko, right?
<wpwrak>
yes, that's the same
<wpwrak>
what i'm trying to do is do the in-circuit programming of c8051f3xx chips
<roh>
the examples worked for you?
<wpwrak>
the examples are kinda simplistic :) one of the things i need is pulse timing control (for negative clock pulses)
<roh>
eh... i dunno how well you can generate reproduceable timings below usb-latency witrh that chip
<wpwrak>
it has a self-clocked async and sync mode. either one should work for this
<wpwrak>
i do get the right pulses. however, not always. even if i put a 1 s delay between packets, which should be more than enough to let usb get the thing out (and, besides, there's a fifo on the other end),
<wpwrak>
i still see pulses that are too long. sometimes by a factor of 2, sometimes much more
<roh>
hm. could it be some usb-packet buffering foobar?
<wpwrak>
data corruption could be a candidate. but then, i should see many completely missing pulses. also, i send on two channels. if there's data corruption, i should see occasionally one channel differ from the other.
<wpwrak>
so it does seem to be the underlying timing that's off
<wpwrak>
the chip has a 256 bytes transmit fifo. i send two bytes every second. worst case, some pulses could get packet back to back. but i can't quite imagine a fifo overrun.
<wpwrak>
besides, also then, i should see this in the timing
<wpwrak>
i mean the time between pulses
<wpwrak>
it could be that usb i/o in general upsets the chip, but that would be pretty weird. oh, and i checked the power supply as well. it's perfect.
<wpwrak>
the chip (ft232rl) has an internal rc oscillator. so there's no crystal or pll to worry about. according to documentation, the internal oscillator is free-running, i.e., not disciplined by the usb clock. (unlike, say, the silabs chips)
<kristianpaul>
arggg
<kristianpaul>
reads " This slide contents is only available to the listeners of courses"
<kristianpaul>
heh seems lot of people is making money now teaching how to decode GPS signals :p
<wpwrak>
kristianpaul: you'll be rich ! :)
<kristianpaul>
lol
<kristianpaul>
:)
<kristianpaul>
wpwrak: not yet, first it need make it work here
<wpwrak>
kristianpaul: small but important detail :)
<kristianpaul>
xiangfu: do you have at hand the rootfs image used in the 65 SIE boards?
<kristianpaul>
i need reflash mine, soemthing is wrong with kernel modules..
<wolfspra1l>
kristianpaul: xiangfu never held a SIE in his hands, just fyi
<kristianpaul>
and adam pointend in the wiki that for my board the specific problem was solved after reflash rootfs
<kristianpaul>
wolfspra1l: oh ok
<kristianpaul>
i wonder if the rootfs image came from Carlos then?
<kristianpaul>
he should i think btw :)
<wolfspra1l>
well we have no boards
<wolfspra1l>
and it's all a matter of priorities
<kristianpaul>
sure sure (MM One RC2)
<wolfspra1l>
I hope there is nothing wrong with your board, but for now I wouldn't think so.
<wolfspra1l>
our testing and quality ensurance is very weak for SIE
<wolfspra1l>
I wouldn't know why 'reflashing twice' should fix anybody's bug, but it did for Adam two or three times among the 65 boards
<kristianpaul>
well i was about simualte some signaling when discover the sound modile in kernel was gone..
<wolfspra1l>
you mean the file in the rootfs is just gone?
<xiangfu>
here is I try to clean up the SIE rootfs. it's only add some fpga command.
<kristianpaul>
what happen if i flahsed nannote uImage...
<kristianpaul>
lets wait this rootfs finish and i'll tell
<xiangfu>
kristianpaul: some kernel panic :)
<kristianpaul>
:/
<kristianpaul>
i think i'll write an email to carlos asking for rescue files ;)
<wolfspra1l>
kristianpaul: NanoNote uImage definitely cannot boot on SIE
<wolfspra1l>
like I said someone needs to cleanup the patches and create a proper OpenWrt target for it
<kristianpaul>
uImage is just kernel isnt?
<wolfspra1l>
yes, without modules
<kristianpaul>
wolfspra1l: indeed this is all a mess (sight)
<kristianpaul>
i wonder how carlos students can survive this ;) (sure they will learn a lot)
<kristianpaul>
heheeh
<kristianpaul>
it booted !
<kristianpaul>
no panic
<kristianpaul>
so far..
<wolfspra1l>
kristianpaul: you mean with Ben NanoNote uImage?
<kristianpaul>
yup
<wolfspra1l>
hmm
<wolfspra1l>
well some things will not work
<kristianpaul>
surelly
<wpwrak>
wow, digi-key are better than i knew. 16:50 (north dakota time): order submitted. 18:32: order ready for shipping. 19:13: data sent to fedex. 15:53: shipment picked up. no i know how they can be so fast. darn time travelers !
<wolfspra1l>
one item may come from fedex, which may use a different timezone that is lost in the transfers somewhere?
<wpwrak>
new, the timezones normally are right. the last two times are from fedex. i guess the pickup truck needs a clock adjustment :)
<brantar>
hello
<wolfspra1l>
hi
<brantar>
is this the right place to ask about rfid?
<wolfspra1l>
brantar: nice to see you, what takes you here?
<wolfspra1l>
he. very remotely. we discussed a project with rfidguardian once but it never went beyond the telephone call stage :-)
<wolfspra1l>
but your time is not wasted at least asking your question here, so go ahead
<brantar>
wolfspra1l: ahh, im looking to connect a Parallax serial rfid reader to my pc for logging in/entering passwords/etc.
<brantar>
wolfspra1l: my first hurdle is the physical connection though... see, i am no electronics guru
<wolfspra1l>
neither am I, but miraculously I ended up in this hardware project...
<brantar>
wolfspra1l: Haha!  i guess were in the same boat, eh?
<wolfspra1l>
I'm afraid I have to pass. Are you talking about normal serial (uart)? Maybe just a level-shifter or usb2serial cable will help you? are you talking about wiring cables or just plugging connectors?
<wolfspra1l>
if we do an rfid project (which I don't see right now), we would try to make it a really open project, along the lines one of our projects called ben-wpan (which is using 802.15.4)
<brantar>
wolfspra1l: well with my limited knowledge i do know i can buy a usb2serial convertor... but i would like to avoid costs if at all possible
<brantar>
wolfspra1l: who is the "we" you speak of?
<wolfspra1l>
anybody who likes copyleft hardware
<wolfspra1l>
as secondary citizens, we also allow people who merely like open hardware
<wolfspra1l>
(that's not serious, just in case... :-))
<brantar>
wolfspra1l: so you're talking about making projects a community thing on here? i'm just looking for a little electronics help
<wolfspra1l>
yes not sure someone can help you, maybe tuxbrain? (he's probably sleeping now)
<lisandropm>
brantar: let me read the backlog
<wolfspra1l>
curious now, what happened to rfidguardian, let me check... :-)
<lisandropm>
brantar: wich kind of interface does the parallax has?
<lisandropm>
brantar: I can't see if the rfid is rs232 or not, but I don't really think so
<brantar>
lisandropm: I have seen people on the forums on there talking about connecting it (through arduino's and such) to an RS232 connector
<brantar>
lisandropm: the problem: my computer has no RS232 ports
<lisandropm>
yes, but I don't know if it needs a traslator or not
<brantar>
lisandropm: where would i find that?  btw, the representative at Parallax said this would work to scan to my pc... but im not sure if he just wanted to push another product or was telling the truth.
<lisandropm>
brantar: do you have a datasheet for ot?
<roh>
brantar looks fine for me
<lisandropm>
for me too
<brantar>
roh: lisandropm: fine as in...?
<lisandropm>
fine as in it should work
<roh>
give the reader power, tie the enable line to ground and the tx to the rx of the usb-thingie, also ground
<lisandropm>
see, the question here is wich voltages does the interface uses
<roh>
see if it works
<roh>
the rfid reader uses cmos/ttl compatible 5V logic levels. as the parallax usb thingie is also compatible to
<brantar>
roh: enable and ground to the grounding of a usbcable or something?
<brantar>
roh: would it need to be plugged in?
<lisandropm>
roh: nothing to add then ;)
<roh>
to the gnd of the power supply and to the gnd of the usb thing
<roh>
the VSS on the usb thingie means ground
<brantar>
roh: again, im slow lol.  so the reader would have the GND going to? and the enable going to?
<roh>
ignore res and the tx
<roh>
you only need rx and the vss.
<roh>
connect rx to the pin3 (sout) of the reader
<roh>
connect vss to pin 4 (gnd) of the reader
<roh>
connect pin2 (_enable) to pin4 (gnd) of the reader
<roh>
connect 5v (from some power supply) to pin 1 (vcc) of the reader and gnd of the supply to the pin4 (gnd) of the reader
<roh>
you could also use another usb port as supply, but then you need to be careful not to generate any shorts
<brantar>
roh: such as a plugged in usb  cable?
<roh>
true. the usb-thing from parallax has only 4 pins and no vcc line as it seems.
<brantar>
roh: so all it does is transmit data, but not grounding or power?
<roh>
i'd just use my lab psu or cut a second usb cable. isolate the 2 datalines and use red and black for power
<roh>
brantar the usb thingie recieves data from the reader
<brantar>
roh: and that is all it does?
<roh>
jap.
<roh>
its also quite easy to hack rfid stuff (125khz transponder tags)
<roh>
easy to clone/emulate
<brantar>
roh:Â Â ok, so i need to draw a diagram to see if i got it right.
<roh>
not good for security stuff ;)
<brantar>
roh: how so?
<roh>
its uncrypted tags.
<roh>
everybody could read them out and clone a card or emulate one.
<brantar>
roh: but someone would have to have physical access to my tag to do any damage right?
<roh>
or be near you at some point (stand next to you in an elevator or so)
<brantar>
roh: im not withholding state secrets with this tag haha.  im just looking to keep a blank tag on me that can log me in to  my pc and such
<roh>
sometimes even some distance can be circumvented
<roh>
(using better antennas)
<brantar>
roh: but for the average high school student i shouldnt worry too much?  :D
<roh>
i wouldnt use it instead of my pw.
<roh>
and it depends... on what kind of school you are on. on some you find quite whitty people;)
<brantar>
roh: ok, ill keep that in mind.  how far of a distance do u think would be readable for an implanted tag?
<roh>
dunno.. i only know of card-stuff
<brantar>
roh: how about for card then?
<roh>
it depends on the power used to read.
<brantar>
roh: ok.
<roh>
one thing it reading it with another reader, another is eavesdropping on your reader
<roh>
the first one means generating the power-field yourself, the second is completely passive (no tx), and only listening
<brantar>
roh: ok, well ill probably just ue it for automating stuff then, maybe starting my common programs or something
<brantar>
roh: thanks for the immense help, im going to draw a diagram to make sure i got all you said correct.
<wpwrak>
wolfspra1l: btw, are there any schematics/layout of the breakout board ?
<wolfspra1l>
hmm. if at all then in ben-blinkenlights?
<wpwrak>
nope, nothing there
<wpwrak>
i mean the board that connects to a cable etc. you said that you're already producing it ?
<brantar>
roh: SORRY, im slow as molasses, almost done with the schematic
<wolfspraul>
he, not really a controlled 'production', just a street job in Shenzhen I need to follow up on it... don't know where it stands.
<wolfspraul>
I think I will try to produce some mmone-jtag-cables in a more controlled way, that could be a nice test for boom too, for example
<wpwrak>
(street job) oh :) well, let's see what comes out of this ;-)
<wpwrak>
(mm1-jtab) yeah, that should be nice and simple