<qi-bot>
[commit] Werner Almesberger: Tools for making a browseable graphical revision history of schematics. http://qi-hw.com/p/ben-wpan/c10d643
<wpwrak>
and here are the tools :)
<wolfspraul>
ah OK, the three columns are 3 pages of the schematics
<wpwrak>
they go though git, extract the repository for each revision, run eeschema to "plot" the postscript, convert it with gs to PPM, then cache it
<wpwrak>
then i go through the cached PPMs and compare them. if there's a difference, it's marked and output
<wpwrak>
there are two parallel styles: the "full-sized" style, which is what you get when you click on one of the thumbnails,
<wolfspraul>
will it stay at that url /misc/ben/demo?
<wpwrak>
and the thumbnail style where lines are fatter, the yellow boxes are more intense and bigger. that's why they sometimes look a bit different.
<wpwrak>
ideally, it would move to a less obscure place :)
<wolfspraul>
I am very interested in this, will definitely try to get it onto the projects server.
<wolfspraul>
but I need some time (yesterday and today I'm somewhat sick actually, but that should get better soon)
<wolfspraul>
so I will add it to my todo list, where else :-)
<wolfspraul>
for schematics with a lot of pages it will get quite wide
<wpwrak>
the cahcing is still a but crude. it keeps tons of useless stuff around, to turn the cache on and off, you need to edit the script, and it doesn't know how to do incremental updates
<wolfspraul>
but even at 5-10 pages it should still be fine, and we can first see which projects we actually have with that many pages
<wpwrak>
(lots of pages) perhaps you can shrink it a little more
<wolfspraul>
I like to start with the projects that we actually have today, rather than preparing for the 100+ pages schematics now, that we will never have anyway...
<wpwrak>
Airbus3000-all-schematics.zip ? ;-)
<wpwrak>
(known limitations) there are also fencepost errors. e.g., it doesn't properly introduce the first commit. and i haven't tested whether it marks deleted or new pages correctly.
<wpwrak>
it also doesn't track name changes other than changes of the top-level schematics file
<wpwrak>
it should also do a bit more linking. e.g., to the commit and maybe to a postscript or pdf file with a zoomable version of the schematics
<wpwrak>
but all that's relatively easy. the hard part was to get the graphical diffs.
<wpwrak>
let's see how it likes xue ..
<wpwrak>
to save space, one could collapse empty columns. but i kinda like the way it is now. it's easy to see where a given sheet changed.
<wpwrak>
aha, xue had a name change too ;-)
<wpwrak>
phew. and for a while some libraries or the profile weren't committed, making kicad bring up a clickable complaint for each revision :-(
<wpwrak>
that could be a problem for automated schematics. of course, it's also instant qa ;-)
<wolfspraul>
no I like it, the look is good
<wolfspraul>
no collapse
<wolfspraul>
sure of course, as long as the script itself is stable, if the output is not good that also means the kicad project files may not be committed well etc.
<wpwrak>
then something is missing, kicad pops up a dialog. so the batch stops until you click it away. not sure if i can just suppress dialogs. if all else fails, i could add a timeout.
<wpwrak>
(and skip the corresponding commit(s). changes would then show up at the next valid commit. not very nice, though.)
<wolfspraul>
asks for a --quiet option, that will also not be accepted upstream :-)
<wpwrak>
yeah. well, the dialogs showing up is of course a sign that my --plot hack is indeed not quite kosher :)
<wolfspraul>
ah, you can just attach it to that patch - suppress dialogs
<wpwrak>
grmbl. seems that each new components in xue takes 2-10 commits before it's in properly :-(
<wolfspraul>
over time people will have better discipline in checking in small but autonomous changes
<wpwrak>
so far, it's just the libraries dialog. shouldn't be too hard. pcbnew has a few more annoyance dialogs. i also haven't quite figured out how to make pcbnew plot without running a lot of the code.
<wolfspraul>
but what about commits that don't impact schematics at all?
<wolfspraul>
layout? documentation?
<wpwrak>
i still extract everything and generate images. since they don't produce a diff, i ignore them later. not particularly efficient, i admit.
<wolfspraul>
ah OK
<wpwrak>
aha ! now it threw up my syntax somewhere
<wpwrak>
silly bug of mine
<wpwrak>
and a formatting problem ... and then we have the good old A4 vs. A3 issue ...
<wpwrak>
hmm. many of the sheets are either empty or my script is borked
<wpwrak>
and xue needs better renaming compensation. so far, i track renames that move the project around in the directory hierarchy. xue had a major renaming of chie-* to xue-*, which my scripts miss.
<wpwrak>
hmm, the symbols with yellow background don't plot well in monochrome. (e.g., in xue-rnc-PSU)
<wpwrak>
yup. the already come out of kicad as big black blocks.
<wpwrak>
and the "empty" sheets aren't. maybe one of those fencepost errors in my script.
<wpwrak>
and eeschema is very unhappy if i run it without a display to show its complaints on. well, i expected that.
<wolfspraul>
wpwrak: nice!
<wolfspraul>
maybe the commit text should be on the left?
<wolfspraul>
13 pages, it's pushing the layout
<wpwrak>
i think the commit text could get wide
<wolfspraul>
but then a lot of that depends on screen size, I think it's OK
<wolfspraul>
oh I see
<wolfspraul>
but it's a table you can just set a width
<wpwrak>
half of the pages are just renames. once i track them properly, they disappear
<wolfspraul>
hmm
<wpwrak>
right now, my script is just good at tracking the quirks of wpan-atrf :)
<wolfspraul>
it's a great start
<wpwrak>
i wonder if i should just also show sheets that haven't changed. the highlighting should make them easy enough to ignore. might make the overall appearance a bit less scattered.
<wolfspraul>
could be crowded
<unclouded>
kyak: could you please try building from the latest nightsky ( 20100827)?  I think the 20100823 version of nightsky had a bug in the Makefile that would involve /usr/lib from the host in the build, which I think might be why the version you built didn't run.  xiangfu had the exact same problem as you did ( hang on getpwuid()) and his build works with the latest upstream
<wpwrak>
(crowded) hmm, and it can hide changes that show up in the full-sized view but not in the thumbnail. e.g., the 3rd commit on http://www.almesberger.net/misc/ben/demo/
<wpwrak>
there, an N changed to M. with the thick lines in the thumbnails, this change isn't visible and thus there is no marking. in the full-sized view, it is detected, though. something like one pixel :)
<wolfspraul>
good point
<wpwrak>
should be pretty rate, though. i could also teach ppmdiff to read a different set of files for the changes. that way, it could "see" changes it doesn't even show.
<wpwrak>
s/rate/rare/
<qi-bot>
[commit] Werner Almesberger: Allow markup to be synchronized with other (better resolution) pair of http://qi-hw.com/p/ben-wpan/0d53761
<rejon>
heya, can someone help me create these pages?
<zear>
rejon, you should start it with "Ben NanoNote is a device manufactured by.." or something like that
<rejon>
yes
<rejon>
please help edit it!
<rejon>
:)
<zear>
well, i think i lack the right knowledge about ben nanonote ;)
<zear>
i think people from dev team should write this article
<kyak>
i say, people from sales team should write it :)
<kyak>
for all technical details users should refer to qi's wiki pages
<zear>
+1
<wolfspraul>
I'm from the sales team, and I won't write it
<wolfspraul>
not because I'm lazy or because I don't like Wikipedia, but because I think it's too early
<wolfspraul>
the Ben NanoNote does not have 'encyclopedic' quality yet
<wolfspraul>
imho
<wolfspraul>
maybe I'm a bit German on that, he he. I think the German Wikipedia is leading in deleting articles for irrelevance :-)
<bartbes>
yeah
<bartbes>
that sucks
<bartbes>
"you need references"
<zear>
bartbes, qi wiki should be fine for the references
<bartbes>
and then I was like "it's a freaking FOSS project, how are we going to provide references?"
<bartbes>
can't
<bartbes>
zear: fail
<zear>
i think they only don't accept forum posts for references
<bartbes>
*multiple* *known* sources
<bartbes>
who are *unbiased*
<bartbes>
it's *that* sucky
<rejon>
i'm not from the sales team
<bartbes>
they prefer freaking newspapers
<rejon>
and i wrote it
<zear>
bartbes, no, the official specification/other info from the qi wiki is a valid reference
<rejon>
there are many articles already linking to it as a red link
<rejon>
its worthy
<rejon>
plus, i can pay off the wikipedia admins
<bartbes>
zear: not what I was told
<bartbes>
actually
<bartbes>
I'm pretty sure it's not
<rejon>
(that was a joke, btw)
<wolfspraul>
rejon: I was just going to report it somewhere.
<zear>
wolfspraul, i think it's the right time to make a wiki article about the nanonote
<zear>
the device exists for a few good months already
<wolfspraul>
this is off-topic, and I haven't thought about it long, but I do think any project that looses focus will eventually die. So Wikipedia does have to be a little careful to continue their success story.
<wolfspraul>
the number of people volunteering time on Wikipedia seems to not grow anymore. so if the flood of junk keeps growing, at some point it will become unmanageable.
<wolfspraul>
what is junk or not is up to the people to define that are volunteering their time to keep it all clean
<wolfspraul>
well this was not about the famous company in Hong Kong anyway
<wolfspraul>
no tears here, sorry
<rejon>
wolfspraul i didn't think you could make them?
<wpwrak>
aah, nothing like a good morning of sleep ! now that it's noon, what shall i do before my afternoon siesta ? :)
<kyak>
guys, i have a question.. i have this device "tengu usb" (just google it). It uses USB port as a power supply
<kyak>
is there any way to connect it to Ben and to get those 5V?
<wpwrak>
kyak doesn't look too good. perhaps if you either want to add an external voltage converter or open the device and see if it runs on 3.3 V inside ...
<kyak>
wpwrak: so, Ben itself runs on 3.3V? no source of 5V inside?
<wpwrak>
don't remember seeing any. it's all 3.3 V or less. (battery is a little more, but you'd still need a boost converter)
<kyak>
i see..
<kyak>
i'm just thinking about some way to demonstrate this Tengu thing outside
<kyak>
Ben would've been very handy
<wpwrak>
put three AAA batteries together and see if the ~4.5 V you get are enough ?
<kyak>
that's a good idea
<wpwrak>
or just take a laptop with you, as portable power source :)
<kyak>
yeah, laptop is the first obvious thing i came up with, but because we are going to drink i'd prefer not to take it with me :)
<wpwrak>
maybe get a usb wall charger then ? they're cheap.
<kyak>
that's what i'm looking for in my table right now
<kyak>
i don't remember, did Ben have one in package?
<wpwrak>
and, regarding drinking and carrying fancy tech, remember what happed with the iphone ;-)
<kyak>
lol
<wpwrak>
no, ben comes without items that could incur the wrath of watchful customs
<kyak>
next day, we'll see reviews in IT articles about some never-seen-before device called "Ben" left in cafeteria :)
<wpwrak>
then wolfgang has to start a wordwide manhunt via interpol and marketing can rest for this year :)
<kyak>
no usb wall charger -\ got nokia phone charger, i think i can adapt that
<kyak>
output 5.7V/800 mA
<wpwrak>
a bit high, but may work
<kyak>
yeah, but, on the second thought, it is hard to connect it to usb port.. i'll have to cut some usb<->mini usb wire
<kyak>
use the mini-usb part of it
<kyak>
and the question at the end - is it worth it? :)
<wpwrak>
no hacker should ever have to ask this question :)
<kyak>
seems that i'm no hacker :) ok. let's see how it'll work
<kyak>
i think it doesn't like 5.7 V
<kyak>
getting crazy :)
<kyak>
LEDs are blinking randomly and very strange
<kyak>
when i plug it back into USB port, it works fine
<wpwrak>
could be worse :)
<kyak>
yeah
<kyak>
i was afraid, a little bit
<qi-bot>
[commit] Werner Almesberger: ben-kbd-bottom-100um is not pretty but it's done. (Data files and Web index.) http://qi-hw.com/p/ben-scans/a939369
<qi-bot>
[commit] Werner Almesberger: schhist2web: use a cache by default and give the user control over it. http://qi-hw.com/p/ben-wpan/099b626
<qi-bot>
[commit] Werner Almesberger: ppmdiff detects lack of changes more quickly. Improved cache robustness. http://qi-hw.com/p/ben-wpan/94dc35e
<qi-bot>
[commit] Werner Almesberger: Only use commits that change anything we care about. Accelerates full build http://qi-hw.com/p/ben-wpan/43d512c
<qi-bot>
[commit] Werner Almesberger: Run eeschema only once (not twice) per commit. 20% speed improvement. http://qi-hw.com/p/ben-wpan/a241265
<qi-bot>
[commit] Werner Almesberger: Add links to project page and commit. Put placeholder if sheet doesn't change. http://qi-hw.com/p/ben-wpan/627d7d7
<johnny0>
hi i need choosing sata cable for my sata hard drive
<johnny0>
i building pc for first time
<johnny0>
there are 3 cables can someone tell me the right one > (1)Plexus Serial ATA 2.0 SATA 7-pin Cable (Red) 61cm / 24", (2) Startech Serial ATA Cable (1 End Right Angled) 18"
<johnny0>
(3)Plexus SATA 2.0 to right angle SATA 7-pin Cable (Red) 46cm / 18"
<wejp>
wrong channel, johnny0
<johnny0>
if u know the answer then just tell me
<johnny0>
u only have to pick from the 3
<johnny0>
i made the question very easy for u guys
<wejp>
this is still the wrong channel, and nobody can tell you which cable to choose, if they can't see the case you are using
<wejp>
this is not a pc hardware channel
<johnny0>
i m using Casecom 6630 Black Midi Tower Case
<johnny0>
for MSI GF615M-P33 motherboard
<wpwrak>
we should just rename this to #wrong-channel :)
<wpwrak>
or, pronouncing "qi" in a german way, extend it to #queer-hardware. might at least get us more interesting off-topic questions :)
<unclouded>
I suppose we could have referred him to an on-line guide to IRC etiquette
<wpwrak>
or have qi-bot every newcomer show a FAQ :)
<wpwrak>
hmm, s/show/read/ or move the "show". i shouldn't multitask :(
<roh>
hm. any ubifs specialist there?
<roh>
hm. this is interresting.
<roh>
got his hands on ar6k hw... which seems to load firmware from userspace with some tool
<wpwrak>
roh: the full firmware ? or just some binary patches ?
<roh>
dunno
<roh>
it uses bmiloader to manipulate the running one and loads multiple files in there
<roh>
looks like calibration data, custom eeprom data and such
<roh>
and one can set the PC of the arm inside the module it seems from the comments
<qi-bot>
[commit] Werner Almesberger: Allow schhist2web and friends to run from a directory outside the working tree. http://qi-hw.com/p/ben-wpan/d7d95ff
<qi-bot>
[commit] Werner Almesberger: New script sanitize-profile to remove glitches from a KiCad profile. http://qi-hw.com/p/ben-wpan/2921bce
<roh>
well.. if i find a sane way to dump  this fw already...
<wolfspraul>
the wifi firmwares I have seen are 80-300 KB binary
<roh>
any idea how to dump a ubi device from userspace without extra tools?
<wolfspraul>
the proprietary hostage we are trying to free :-)
<roh>
there is no mtdblock anymore
<roh>
wolfspraul hehe... in the end hardmac would be ok, if we can load our own fw
<roh>
i dont really care who builds the hw as long as there are specs and documentation and free code to use it.
<wpwrak>
roh: ah, lemme guess ... ar6002, not ar6001, right ?
<wolfspraul>
wpwrak: I think the diffs are awesome! I showed it to Andres and he loved it too. I need to get it integrated into the projects server.
<wpwrak>
wolfspraul: kewl :) sorry for crowding your to do list :)
<roh>
wpwrak jap
<roh>
wpwrak /lib/firmware/AR6002/
<wpwrak>
roh: makes sense then. the 6002 is "flash-less"
<wolfspraul>
roh: what are you trying to achieve exactly?
<roh>
wolfspraul nothing exactly (with the ar6k) .. just stubled over that
<wolfspraul>
wpwrak: not at all. Seriously, this is extremely important.
<roh>
got a device on the table which i need to dump the fw from
<wolfspraul>
there are many ways we can 'open up' kicad files and the development process, also on the more commercial side later, bom data, etc.
<wolfspraul>
but step by step
<wpwrak>
wolfspraul: yes, the next challenge will be diffs for the layout. perhaps even more interesting than schematics. with the schematics you can guess from the text diff at least what some of the changes do. with the layout, it's pretty hopeless.
<wolfspraul>
wpwrak: if the commit message is good that should work for the layout too, no?
<wolfspraul>
the only thing I am always careful about is to not create a process that is so perfect that it overwhelms the people that are supposed to use it
<wolfspraul>
so those wiki pages with documentation about layout changes of course are a lot of manual work, but it's also fairly easy and can be created and amended over time
<wolfspraul>
but let's see.
<wpwrak>
wolfspraul: (layout) the difficulty is in generating the images. not sure if it even makes sense to hack a --plot into pcbnew. might be as easy to just parse the .brd file.
<wolfspraul>
definitely trying to automate doesn't hurt. as long as the automation is too difficult to use we can still have redundant documentation elsewhere, and slowly everybody adapts to the automated process.
<wpwrak>
wolfspraul: (overwhelm) i have to admit that it is a little complex. running it is relatively easy, though.
<roh>
automated processes are ok if they are well documented and that documentation is linked from the the right points on
<wpwrak>
wolfspraul: (wiki) the problem with manual processes is that you can never be sure if what they show is really what happened. also, since it's a lot of work, people tend to get sloppy after a while.
<wolfspraul>
agreed, we are on the same page. just _sometimes_ (ahem) your scripts are a bit scary to me... :-) they assume a lot of very conceptual understanding and not everybody may be able to follow, not today, and not ever.
<wpwrak>
the sloppiness is basically a HR problem - a person who's good at doing new things is often weak at boring repetitive things. so you'd need someone else to take over this task. basically replace the "pioneer" with a "maintainer". sometimes, you can find people who are good in both roles and don't mind doing that for a while, but you have to be extremely lucky.
<wolfspraul>
but if we can make something work automatically behind the scenes, and then you can click on things throug your browser, that's another story. people can adapt their behavior until what they can click on looks right :-)
<wpwrak>
wolfspraul: (complex scripts) heh :) one issue is of course that such scripts always tie together lots of different things. so they deal with quirks from kicad, ghostscript, your web browser, and even individual projects all at the same time. plus, they try to be reasonably robust, which, particularly in the shell, means lots of subtle quoting.
<wolfspraul>
btw, Andres says he has mostly finished even the layout for Xue already
<wpwrak>
whee ! that's great ! how did he do it ? all in kicad ?
<wolfspraul>
that sounds quite scary to me given that there has been little review yet, and also that I am slow in providing him with some datasheets and reference schematics I promised. but still... it's good news
<wolfspraul>
yes, all in kicad
<wolfspraul>
well, I am just relaying his words
<wolfspraul>
he said he thinks there is not much missing in kicad to make it a really good tool
<wpwrak>
nice :)
<wpwrak>
(review) generally seems to be a bit of a problem in the qi-hw projects. there's a bit of review activity on the software side, little on hardware. well, there's carlos vs adam on SIE, but that's pretty much all that's happening visibly.
<wolfspraul>
if it's not visible it doesn't exist :-)
<wolfspraul>
I would probably agree, it seems hard to motivate people for really systematic and thorough review.
<wolfspraul>
you were quite successful in gta02-core I think :-)
<wpwrak>
hmm, not sure. are there project groups at the various sites ? some members may be "invisible".
<wolfspraul>
but of course you also spent quite a bit of time to make a review checklist, ask people to take on certain parts, etc.
<wpwrak>
(gta02-core) at least for a while :)
<wpwrak>
yeah, cheerleading is important :)
<wolfspraul>
of course there are people like DocScrutinizer and others, but I feel bad directly poking them for unpaid stuff
<wolfspraul>
also emeb, he said he might be interested in reviewing Xue, I need to ping him again...
<wpwrak>
one problem with reviews may also be that some of the projects just aren't of interest for a lot of people. multiply with community size. if the number is too small, you get no review.
<wolfspraul>
for the Xue layout, I am thinking about asking the layout house that did the Milkymist One layout for a review, if that is possible
<wolfspraul>
of course we can only give them GERBER files which they would need to import into whatever works
<wolfspraul>
not sure that makes much sense or not, but if they can spot something and give us feedback, I would be willing to try
<wolfspraul>
wpwrak: true, definitely
<wpwrak>
you can visit them with kicad on your laptop and tell them where they can download it, if they want to :)
<wolfspraul>
I think giving them gerbers and letting them import those files into a software they are comfortable with will yield better results.
<wolfspraul>
anyway, I will ask
<wolfspraul>
it would probably only cost a few hundred USD
<wolfspraul>
if the chance is even only 5% that they will find something, it's already worth it
<wolfspraul>
meanwhile we try to crank up things on our side, another reason why I like your schdiff scripts (schematics I know, but still, right direction)
<wpwrak>
(review by layout house) yeah, can't hurt. knowledge transfer out of china for once ;-)
<wolfspraul>
for the first xue run, my #1 worry is that the boards work
<wolfspraul>
obviously
<wolfspraul>
we achieved that with milkymist one, so that's the goal
<wpwrak>
hmm, 6 layers. medium routing complexity. most of the board is uncrowded, which helps.
<emeb>
wolfspraul: saw you mentioned me
<emeb>
still lurking on the list & irc - checking the xue git periodically
<emeb>
,
<wpwrak>
pretty thin traces. only 3.9 mil.
<emeb>
3.9mil is pretty thin - is that necessary to route out of the BGA?
<wolfspraul>
emeb: hey, nice you read this... so I don't need to email
<wolfspraul>
yes, it seems Xue is making good progress, Werner has worked on a nice visualization of schematics changes
<emeb>
I saw that visualization just now - cool stuff!
<wolfspraul>
yes! :-) it's fantastic
<emeb>
that's the kind of thing you could sell...
<wolfspraul>
I need to integrate this into the projects server so every kicad project automatically has it
<wolfspraul>
no we will freely share it :-)
<emeb>
understood - just noting the value is >>0
<wolfspraul>
so Andres says even the layout is mostly finished? I cannot verify this, neither in completion status nor quality
<wolfspraul>
but maybe you can?
<wolfspraul>
if you like, any review you could do would be more than appreciated
<wolfspraul>
if anything blocks you, let us know what it is
<emeb>
I'll check it out over the weekend. Soon enough?
<wolfspraul>
he he. of course! :-)
<emeb>
OK.
<wolfspraul>
do you have KiCad installed?
<emeb>
Need to come up to speed on some of the system issues.
<emeb>
Yes - already have Kicad
<wolfspraul>
unfortunately many Linux distros ship with very outdated versions of it
<wolfspraul>
which version?
<emeb>
just need to do a git pull & load it up
<wolfspraul>
ok great
<wpwrak>
emeb: (thin traces) not sure. he did power traces on the bga with 8 mil, signal traces 4 mil. well, if the pcb house is happy with it ...
<emeb>
v 2010-05-09
<wolfspraul>
Andres may even use a KiCad with some of Werner's improvements, like fped (footprint editor). But I am not sure whether it's needed for review.
<roh>
wolfspraul i found a ppa for kicad with more recent ones. still not with your patchsets of course
<emeb>
8 mil power traces is pretty thin too, but if he's got planes then it's not a big deal
<wolfspraul>
emeb: note that Xue is a derivative project of Milkymist One, for which we have Altium files
<wpwrak>
you don't need fped for review. you need my kicad patches if you want to generate the schematics diffs, though
<wolfspraul>
and those Altium files have already been used to produce working boards
<emeb>
Eh - altium shovelware
<roh>
you could ask that guy if he could add the patches
<wolfspraul>
emeb: can you open Altium files? I think the plain gerbers and PDF schematics should also be somewhere...
<emeb>
gerbers & pdfs OK - altium not
<wolfspraul>
emeb: I just wanted to tell you that that is basically Xue's parent. And it is known to work. So a good reference point for some questions in Xue.
<wolfspraul>
that's the great thing about xue - first time we move this to a free tool
<wpwrak>
xue did all the big chips with fped. good ;-)
<wolfspraul>
it's all linked from that top-level Milkymist_One page
<emeb>
just pulled the latest xue
<emeb>
looks like there are still a few components hanging off the outside of the board...
<wolfspraul>
so since Xue is basically a derivative, or 'reduced' version of Milkymist One, we have a really good baseline to compare against, with all that data from the Milkymist One RC1 run, which, again, resulted in working boards :-)
<wolfspraul>
wpwrak: does emeb need a KiCad that includes fped to do review?
<emeb>
wolfspraul: something useful to do with a new schematic when using FPGAs is this:
<wpwrak>
fped is completely separate. it generates the kind of module files kicad can read. i'd recommend building fped if he wants to examine the footprints. much easier to do it there than poking around in the gerbers or the layout.
<emeb>
create a .UCF file for all the FPGA I/O as defined by the board and a top-level stub of the FPGA design.
<emeb>
compile that with the Xilinx tools & check for errors before committing to a board.
<wolfspraul>
I think I've heard .ucf before, could it be that it is in the Milkymist repository?
<emeb>
That can help find lots of I/O bugs
<emeb>
is the xue fpga pinout identical to milkymist?
<emeb>
if not then the mm .ucf is of little use
<emeb>
(good starting point though)
<wolfspraul>
hmm
<wolfspraul>
it's a derivative, it should be the same, as much as possible
<emeb>
I'll check.
<wolfspraul>
there are many things removed on Xue (compared to Milkymist One)
<wpwrak>
the footprints look decent enough, using fped properly. the measurements are almost complete.
<wolfspraul>
DMX, MIDI, video in, VGA, etc.
<emeb>
I'd be surprised if it's identical - FPGAs give you flexibility and it's good to use it.
<wolfspraul>
then a CMOS image sensor was added, that's new
<wolfspraul>
well we want to keep it as compatible as possible
<wolfspraul>
also one of the design goals of Xue is low power consumption, which was not a design goal for Milkymist One
<wolfspraul>
so I believe the power supply is very different, but that shouldn't affect the FPGA
<wolfspraul>
but since it's new (compared to Milkymist One), probably a good point for review too
<emeb>
power supplies can change a lot w/o affecting the logic
<emeb>
yep - looks like the pinouts are completely different
<emeb>
not surprising... Board layout is new
<emeb>
and FPGA pinout should be optimized for layout
<emeb>
Would be wise to create new .ucf & compile against top-level stub.
<wolfspraul>
emeb: andres_calderon just joined :-)
<emeb>
cool
<emeb>
andres_calderon: looks like the FPGA pinout for xue is different from milkymist - correct?
<andres_calderon>
correct, but just need a new ucf
<wpwrak>
hey andres_calderon ! nice work ! you'll be the one who finally convinces wolfgang that doing serious projects with kicad is feasible :)
<emeb>
andres_calderon: have you made the new .ucf yet?
<andres_calderon>
kicad is a good software
<andres_calderon>
emeb,  the layout is not over ...
<wolfspraul>
wpwrak: so you consider fped to be a totally separate package from kicad? is there a debian package for it? should I create one to make it easier distributable?
<andres_calderon>
We hope to finish the layout the next week
<wpwrak>
wolfspraul: fped and kicad don't share any code. they only share the same file format for modules. you can build and use fped without having kicad at all, and vice versa.
<wpwrak>
wolfspraul: you can use fped also for tasks not related to kicad. e.g., i used it to design furniture ;-)
<wolfspraul>
understood, but where do you see it from a packaging standpoint. I mean KiCad already includes several utilities, couldn't it also include fped? Would you want that? Or do you think a separate package is better?
<emeb>
andres_calderon: understood. When you are near completion of the FPGA pin assignments try this:
<wpwrak>
wolfspraul: (debian) dunno. maybe it helps. fped is easy to build but has a number of prerequisites that may be surprising, e.g., transfig.
<emeb>
create the .ucf and an empty top level verilog stub for the design
<emeb>
run these through ISE to check that all the I/O assignments are valid.
<wpwrak>
wolfspraul: a separate package is better
<emeb>
I've found some errors this way in the past - things like input-only pins,
<wpwrak>
andres_calderon: the main script is schhist2web. companions are gitsch2ppm, gitenealogy, ppmdiff/, and sanitize-profile. the Makefile shows a few typical invocations.
<wpwrak>
andres_calderon: zigbee is layered on top of ieee 802.15.4. so each zb uses ieee 802.15.4, but you can have ieee 802.15.4 without zigbee.
<wpwrak>
emeb: heh :) of course, my ben-wpan design currently is just a usb stick (with an mcu that then translates to spi). connects to any pc :)
<emeb>
wpwrak: cute design - I've looked at it already.
<emeb>
where did you get the antenna layout?
<andres_calderon>
emeb, I had not really thought of that before.... but it can work.
<wpwrak>
what i really have to make is a firmware flash programmer for the c8051f32x chips that doesn't need flash programming itself. that kind of bootstrap always sucks. my current process involves a freerunner with debug board, not the most ubiquitous platform.
<emeb>
I use Atmel AT91SAM7S64 ARM processors that can be fully reflashed via USB...
<wpwrak>
emeb: yup. that's the issue. i've solved it for myself, but it makes things hard to reproduce for others if they need to some exotic hardware, some expensive proprietary programmer (windows-only and such), or design their own kit.
<wpwrak>
emeb: (full reflash via usb) unfortunately, silabs didn't do something as nice as that. well, it's a small chip and even a tiny bit of usb code in a rom takes space ...
<emeb>
wpwrak: yes - the ARM chips are bigger & more expensive.
<andres_calderon>
we use the OpenOCD to program  AT91SAM7xx chips
<emeb>
andres_calderon: yes - I use that too w/ an Olimex USB-TINY
<emeb>
used to work fine on my Fedora 11 system
<emeb>
now on Fedora 13 it no longer works.
<emeb>
I'm baffled
<wpwrak>
(contiki) looks nice
<emeb>
andres_calderon: which JTAG & OpenOCD do you use?
<wpwrak>
people on the linux-zigbee list are working on getting ieee 802.15.4 into linux. don't have ipv6 quite working yet, though
<emeb>
wpwrak: 802.15.4 requires IPV6?
<andres_calderon>
OpenOCD plus custom board based in FTDI IC
<wpwrak>
emeb: no, ipv6 (6LoWPAN) is one of several choices for protocols to run on top of ieee 802.15.4
<emeb>
andres_calderon: Oh - probably not something I can buy  to fix my problem...
<wpwrak>
emeb: others are zigbee, and so on
<emeb>
wpwrak: I see. so it's higher layer issues right now...
<andres_calderon>
ieee 802.15.4 define only the PHY layer
<wpwrak>
emeb: not sure what exactly zigbee can do. according to wikipedia, it may have IP issues.
<wpwrak>
andres_calderon: PHY and also a bit of MAC
<wpwrak>
(worming my way through the IEEE 802.15.4 standard these days)
<wolfspraul>
wpwrak: last I know the problem is that the ZigBee documentation costs money, and the terms it comes under not explicitly make it clear that one can develop GPL licensed software based on that documentation
<andres_calderon>
  a friend of mine in (my partner in emQbit) developed this little node, I can open the project  http://www.emqbit.com/image/mote1.png
<wolfspraul>
the fact that the documentation costs money, even if it's not that much, is already a GPL violation per se afaik
<wolfspraul>
the ZigBee Alliance was approached several times in clarifying the situation, but so far hasn't
<wolfspraul>
I don't even think there is a great business model that blocks it, it's just organization inertia and the inability to answer to or resolve any complex issue that comes up
<roh>
guess why nobody likes it? ;)
<wpwrak>
wolfspraul: docs for money per se shouldn't be a problem. we even have plenty of drivers with docs under NDA. not being able to use the knowledge gained from it is, though.
<wolfspraul>
unfortunate situation. So the GPL purists stay away from ZigBee for now, even though some others are happily hacking on codes they license under the GPL :-)
<roh>
wpwrak drivers and protocol-documentation are 2 different things.
<wolfspraul>
well I hope the ZigBee alliance gets their act together one time, enough people who understand the situation and have voting power or whatever is needed to make an official statement are in the room, and they can move this blocker out of the way.
<roh>
usb was successful due to no royalties for specs and cheap ones for the rest.
<wpwrak>
roh: driver = implementation of protocol to talk to the hardware :)
<roh>
wpwrak yes. but its not a vendor-interop. protocol.
<roh>
anything on the wire/the air needs public documentation or it needs to die.
<wolfspraul>
zigbee by all means was meant to be open, I really think it's just bureaucracy and inertia that keeps this blocker in the room. unfortunate.
<wpwrak>
roh: so i don't think restricted-distribution documentation would be a problem. but if they'd also restrict its application (which would of course include writing your own book), that's a problem.
<wpwrak>
roh: lots of protocols are non-Open. e.g., atm.
<wpwrak>
roh: i agree that non-Open is stupid, of course
<wolfspraul>
but 6lowpan is very cool anyway, I think it's the right choice
<roh>
wpwrak restricted protocl documentation is a gurantee for fail. been proven before.
<wpwrak>
roh: hah, try SNA. big cash-cow for IBM :)
<wolfspraul>
zigbee was meant to be and is open. to the best of my knowledge the situation is that some people found some fine print they are not happy with, and nobody picks up the phone or gives any meaningful answers on the other side.
<wolfspraul>
but still, the fine print is there, and it's not right, and as long as nobody cares on the other side I can see why some people are reluctant to move forward still.
<wpwrak>
wolfspraul: i don't have an opinion on its technical merits yet. but strategically, i see it as a perfect fit, too. i like the "ip over anything" paradigm. just forget about the layers underneath.
<roh>
wpwrak dunno about sna. doesnt seem to matter for the generic public.
<roh>
wpwrak but you can go back from now till the 80s and check. closed vs public documented protocols on air or wire interfaces. nearly every closed one failed completely. the public ones succeeded with >70%
<wpwrak>
andres_calderon: (e-mote) aah ! so you're the guys making that one. i've seen it mentioned on the linux-zigbee list
<wolfspraul>
he he. maybe the zigbee alliance is so non-profit that they don't even have the means to meet and decide on things? :-)
<wpwrak>
wolfspraul: that would be a first ...
<roh>
ip and everything in the 'regular' networking world is a good example for the public side of things. nobody really 'owns' a proto. there is a public RFC, thet gets discussed and in the end some paper gets decided to be the release.
<wpwrak>
wolfspraul: usually, those standards groups try very hard to keep up with medical conferences in the caribbean and such ...
<wpwrak>
wolfspraul: i went to ietf for a while. it's not a bad life :)
<wpwrak>
roh: (public protocols) IP really changed that, yes. the telco world love its little secrets. x.25. isdn, atm, gsm, utms, whatever, they all non-open.
<wpwrak>
roh: of course, this creates a big aftermarket for books that essentially rephrase the standards, and cost a fraction of the original stuff
<wpwrak>
sometimes, other standards bodies pick up those things and put them into "open" documents. but they rarely "open up" the original thing though. instead they basically provide deltas.
<roh>
wpwrak in the end  the closed stuff needs loads more 'brute force' to be successful. thats what i am saying. if you want something to succeed, make sure its freely avail. for everybody.
<wpwrak>
roh: (q.931) wow, impressive ! things have moved in the last years :)
<roh>
even most of gsm is avail afaik
<wpwrak>
roh: (the benefits of free and open) you don't need to convince me :)
<emeb>
wpwrak: do you have a link to your ben-wpan project somewhere on the qi site?
<wolfspraul>
looks quite similar to ben-wpan :-) I will try to find out more about it, can never learn enough even if ben-wpan is already on a more interesting track for us...
<wpwrak>
kewl. even q.2931 is freely downloadable now. of course, it's almost obsolete now, but still impressive. that was a pain for a looong time.
<roh>
wpwrak obsolte? what do you think is the basis for international telco interconn?
<roh>
thats ss7, which bases on isdn, so i am sure there is quite a lot of q931 in it.
<roh>
same goes for gsm.
<wpwrak>
wolfspraul: hmm, fsk/gfak. not compatible to ieee 802.15.4 :-(
<wpwrak>
nice little antenna, though
<nibbler>
did i hear isdn? ss7? itu? standards? :)
<wolfspraul>
wpwrak: oh I love the direction of ben-wpan already, with 6lowpan etc.
<roh>
.oO(why dont we use dect on the air-interface?)
<wolfspraul>
wpwrak: so 6lowpan cannot be run over the hoperf rfm70 module?
<emeb>
wolfspraul: thanks - didn't know the project title to find it. Now I do...
<wpwrak>
tiny fifos. 32 bytes. that means small frames or very narrow timing.
<wolfspraul>
emeb: the homepage of projects.qi-hardware.com gives you an overview
<emeb>
wolfspraul: yep - see that now
<wpwrak>
roh: q.2931 is atm. ss7 is something else.
<wpwrak>
roh: of course, they're all related
<wpwrak>
wolfspraul: not sure if 6lowpan makes assumptions about the mac/phy the module cannot fulfill. but you will at least not be compatible with what people usually call ieee 802.15.4
<wolfspraul>
wpwrak: do you have any idea what IC could be on that RFM70 module?
<wpwrak>
wolfspraul: ieee 802.15.4 defines something like 10 phys, so there can always be some niche where you're compatible :)
<andres_calderon>
6lowpan is IPv6 over IEEE 802.15.4? and ONLY over IEEE 802.15.4 ?
<wpwrak>
wolfspraul: if you ask them, will they tell you ? :)
<roh>
wpwrak other way round. its so incompatible with itself that interop is not archievable even if trying hard ;)
<wpwrak>
wolfspraul: ther are a number of 2.4 GHz non-ieee 802.15.4 chips. many major manufacturers have one. but i haven't looked at them enough to be able to make a useful guess.
<roh>
nordic semi has some really small ones
<wpwrak>
roh: naw, everybody just uses 2.4 GHz and ignores regional special bands (like 346 MHz for china and such)
<roh>
wpwrak thats why it doesnt work anymore
<roh>
2.4g is so crowded that i hardly can hardly see the diff of tx and not tx in the same room
<roh>
dunno how its in south america, but there is a reason even the crappy 'av-link' thingies to send video and audio from a stb to the tv is available cheaply in 5.8ghz variants now
<wpwrak>
wolfspraul: (ben-wpan) for now, my main obstacle is getting the RF right. need to get some hands-on experience with my usrp2. it's not really made for this sort of measurements, but it should at least give me some ideas of where theproblems are.
<roh>
wpwrak 2.4ghz wifi went so bad that we only set up accesspoints for devices which cant do 5ghz yet (phones, etc, legacy stuff). most people use cables again
<wpwrak>
the bulge at the end is generated by myself
<wolfspraul>
sure I understand. but the direction is right and you are digging up the right knowledge we need for a complete solution later.
<roh>
heh.. wouldnt get that anywhere in the city.
<roh>
wpwrak thats really 'empty'
<wolfspraul>
I will see whether they tell me where the IC is from.
<wpwrak>
roh: a quiet night in buenos aires :)
<roh>
wpwrak i can get more wifi networks than regular firwmares support. so the list changes on every second 'scan' from userspace due to it overflowing
<wolfspraul>
I am more interested in ben-wpan now, maybe hoperf is even interested in it :-) I don't know...
<roh>
sometimes >30 networks
<wpwrak>
roh: i get 22 at the moment
<wpwrak>
..25 ...
<wpwrak>
wolfspraul: the at86rf230 is pretty common. it's also supported by linux-zigbee. they don't have the cc2520 yet. they say it's hard to find hardware with it. bah. who needs to wait for that if you can make your own ? :)
<wpwrak>
roh: now i have 30 too :)
<wpwrak>
roh: most of them far away, though. -90 dBm or less. only a few closer.
<roh>
wpwrak well.. german buildings from a hundred years ago.. altbau... means they are all strong and near.
<roh>
i would guess every second flat here has dsl and atleast every 3rd wifi
<roh>
ofcourse every shop and cafe
<wpwrak>
wolfspraul: one problem with modules is that they don't fit into the display case. you only have a few mm of pcb space there. and it's probably the nicest spot for putting an antenna.
<wpwrak>
i wonder if < 10 mm of mismatched transmission like make a big difference or not. e.g., the lines connecting the two parts of the antenna matching circuit and the circuit with the antenna on
<wpwrak>
should be 50 Ohm. of course, they're not. (far too narrow)
<wolfspraul>
wpwrak: yes of course, if we have the necessary know-how, testing etc. we can do what is typically called 'chipset design'
<wpwrak>
they're more like Z=110 Ohm. but i wonder if that actually matters, since they're almost as short as traces interconnecting adjacent components
<wolfspraul>
of course that is better, for many reasons
<wolfspraul>
the question is whether we can take it on now, but since you became so active with ben-wpan maybe we can
<wolfspraul>
we can put ben-wpan right into and on top of the pcb behind the lcm, for example
<wolfspraul>
we'll see
<wpwrak>
wolfspraul: the know-how is indeed the question. however, it seems that you can't quite avoid the issue anyway. even if you buy a module, you need the system's total emissions for conformance testing.
<wpwrak>
the place i have in mind would be on the front side, between lcm and case
<roh>
is there a rf expert somewhere in the community in the meantime?
<roh>
or 'do you have a guy hidden somewhere else' ?
<wpwrak>
if i make the matching circuit a bit smaller and get rid of the crystal, it should fit nicely
<wolfspraul>
wpwrak: what do you mean with 'front side'?
<wolfspraul>
you mean next to the LCM?
<wpwrak>
wolfspraul: the side facing the user. where there are already components
<wpwrak>
the left-hand side. there's quite a bit of empty pcb. that should be good enough.
<DocScrutinizer>
wpwrak: mismatch on RF traces always is a severe problem. Length of trace is virtually irrelevant, as the mismatch takes effect on start/end of trace only, and spoils the SWR
<wpwrak>
the antenna will not radiate well towards the right side, with the lcm being in the way, but it is designed for having ground there anyway.
<wolfspraul>
DocScrutinizer: hey good to see you!
<DocScrutinizer>
hi wolfspraul
<wpwrak>
DocScrutinizer: so 3 mm or 4 mm are already enough to make trouble ?
<wpwrak>
(he lives ! ;-)
<DocScrutinizer>
yes
<wpwrak>
is there a "safe distance" ? e.g., it's hard to get traces connecting adjacent components below 1mm.
<wpwrak>
(and a few years ago, it would even have been hard to find components small enough for that ;-)
<DocScrutinizer>
for RF there's no length issues. It's the wavelength in medium that determines if the line Z actually is determined by usual rules for 'infinte' length 'cables' or if there are more complex calculations for 'cable' length < wavelangth
<DocScrutinizer>
(grob gesagt)
<DocScrutinizer>
I.E, it's not a length minimum under which a mismatch doesn't matter. The mismatch always is a problem, but the Z calculation looks different for very short trace length
<wpwrak>
hmm. what i'm trying to wrap my head around is that there are areas where it clearly matters (feed lines) and areas where it doesn't seem to be important (interconnects). how to tell the difference ?
<wpwrak>
ah,okay. what would be "short enough" for a "nice Z calculation" then ?