<qi-bot>
[commit] Werner Almesberger: atusb.brd: reduced XTAL front ground to shorted "tongue" between pads 24 and 25 http://qi-hw.com/p/ben-wpan/f33b86b
<qi-bot>
[commit] Werner Almesberger: atusb/fw/atusb/Makefile: pass board version to cpp (when determining USB ID) http://qi-hw.com/p/ben-wpan/6a7b2de
<lekernel_27C3>
wpwrak: what workshop? those suckers at the CCC can't even get the room open before the workshops and have no idea where the key is
<lekernel_27C3>
let alone other problems with the schedule (or lack thereof), no videoprojector, etc.
<qwebirc73428>
Hi! Is the qi-hardware wiki having problems with OpenID logins?
<wpwrak>
lekernel_27C3: argh. sounds bad :-( so what did you do ?
<lekernel_27C3>
report that to a less messy event
<lekernel_27C3>
and never submit workshops to CCC again
<czr>
hi all, probably OT, but anyone knows who's the distributor for nanonotes in finland? tried to order via webshop, but no go.
<wpwrak>
lekernel_27C3: yeah, more chaotic that one would expect. well, i hope the hallway demos went well. that often catches more people anyway
<wpwrak>
czr: did you try tuxbrain ? they're in spain, but i think they're the main european distributor. i think pulster in germany may also be an option. don't know if there's one much closer than these two.
<czr>
thanks, will check them out
<czr>
I didn't see any list of distributors anywhere, just a referral to contact sharism, which was more than slightly pita.
<czr>
gah. tuxbrain uses some crappy credit card processor that fails the transaction..
<czr>
curses again..
<wpwrak>
czr: hundreds of people have succeeded so far. it can't be all that bad ;-)
<czr>
that's what I thought, but still :-).
<czr>
also, the shop kind of doesn't handle the transaction failure at all.
<czr>
"Error desconocido (9104) Volver a la tienda".
<wpwrak>
aah, error 9104. but of course ! ;-)
<czr>
yes. it's much more complex than a plain 501 :-)
<czr>
"we how what failed, but we won't tell you, hee hee"
<czr>
know even.
<wpwrak>
well, it could send a register dump ... :)
<czr>
or, to make it more interesting, a partial register dump using randomly selected registers only.
<czr>
with some inverted just for extra fun
<wpwrak>
you sound like the kind of guy who would put  #define while if  in the "exported" header files of his libraries :)
<czr>
I've moved beyond that. I just replace `which cpp` with a custom randomizing version.
<wpwrak>
ah, aiming for the thompson attack, i see
<czr>
heh
<czr>
oddly enough, most of my code is quite readable infact.
<czr>
I guess it's a case of "once you saw off your leg enough times, you learn to do it elegantly"
<czr>
cool. so, being open sores and all, are all the tools that are necessary to synthesize and download the stuff open source too?
<czr>
marvellous
<wolfspraul>
now that we've opened this up of course there are lots of todos...
<czr>
I've been thinking about this for ages really
<wolfspraul>
not all, but that's the point
<czr>
so, what tools are still closed?
<wolfspraul>
but the milkymist one itself works, today
<wolfspraul>
synthesis
<czr>
right. is it available as a non-GUI linux executable then?
<wolfspraul>
although Sebastien (the founder of Milkymist) has recently starting there too, see http://www.milkymist.org/llhdl/
<czr>
damn.
<czr>
drools all over the channel
<wolfspraul>
for the time being you definitely need the closed source (but freely distributed) Xilinx tools, called ISE WebPack
<czr>
hmm. are there any "headers" on the milkyway one available for i/o expansion/bussing?
<czr>
nods
<wolfspraul>
there are 2 headers, but the headers are not the main point of Milkymist One
<wolfspraul>
but... for that we have another projet coming up, Xue :-)
<wolfspraul>
that will be like a mini-milky, plus 50-pin expansion header
<czr>
I've been mostly mucking with altera, didn't get very far though. buttons + and + and blinkenlichts. but that's where I had to start anyway :-)
<wolfspraul>
oh sure
<wolfspraul>
this is far more advanced
<czr>
I ask because I have some other stuff that I might want to interface
<czr>
oh, I know :-)
<wolfspraul>
give us 6 months and we should have this Xue thing ready
<wolfspraul>
but today it's all about Milkymist One
<czr>
nods
<wolfspraul>
we need to polish, make it more useful in the Flickernoise GUI, and most important fix bugs and stability issues all over
<czr>
so, what you're saying is basically that even if I get milkymist one now, the hdl/firmware stuff will still live and be updated in near future?
<wolfspraul>
of course
<wolfspraul>
not just 'near future', I hope we can support and improve it for many years
<wolfspraul>
that's one of the big points of free technology, imho
<kristianpaul>
me grins
<czr>
nods
<kristianpaul>
oops :-)
<czr>
wolfspraul, thanks for the heads up though. I wish I was a student again.. :-).
<wolfspraul>
we slow things down, innovate on freedom, innovate on stability, documentation, understanding, so people can drive the technology into new use cases quickly
<wolfspraul>
be slow so we can be fast
<wolfspraul>
how about that?
<wolfspraul>
:-)
<czr>
I've often said that all hw development should stop for 10 years.
<czr>
to give a breather and time to fix things :-)
<czr>
one thing that really is a problem is that there's only VGA output
<czr>
although using HDMI/DVI might be slightly problematic because of TMDS licensing.
<kristianpaul>
nommu still interesting, one of the things because i'm following osmocom project (besides i have a motorola C139 ;-)) is to see what Real Time OS will come up (from scratch?) or implemented when some GUI appears
<czr>
kristianpaul, how is osmocom coming along?
<kristianpaul>
czr: dunno, i just started reading/playing it (bb.osmocom.org) more seriouslly since yday
<czr>
nods
<kristianpaul>
fflush is really handy
<wpwrak>
kristianpaul: interesting discovery :)
<wpwrak>
rsharpe: ah, you're here as well :) let me paste the conversation here. others may be interested too
<wpwrak>
the status of ben-wpan right now is that i'm still wrestling with part of the hardware. the host interfaces look good, but the RF side still needs work
<wpwrak>
if you have any experience with RF design, a review would be very welcome
<wpwrak>
i haven't touched the software side yet (besides writing a few small tools for testing the hardware)
<wpwrak>
the idea is to use the linux-zigbee code. alas, that project seems to be very slow at the moment
<wpwrak>
people are also using some SLoWPAN (IPv6) code from the contiki OS, so that connection could use some looking into as well
<kristianpaul>
hehe well for me yes :-) is faster than fwrite in some cases (low data)
<wpwrak>
(the general idea for the stack is IPv6 on SLoWPAN on IEEE 802.15.4)
<wpwrak>
kristianpaul: hmm, "fflush faster than fwrite" sounds like an odd comparison.
<wpwrak>
anyway, gotta do some shopping. back in a bit.
<kristianpaul>
wpwrak: no i mean faster in some debugging tasks, the comparition is not fair i know
<Jay7>
btw, ppl, did you know about CELF funding opensource projects?
<wpwrak>
kristianpaul: i'm still not sure what you're comparing :) you're phrasing it as if fwrite and fflush were alternatives for each other, while they're part of the same process. much like saying that making the dough takes longer than the baking of the bread.
<wpwrak>
anyway, off for more shopping ...
<kristianpaul>
hmm
<kristianpaul>
yes you're right
<kristianpaul>
as always :-)
<wpwrak>
hehe :)
<wpwrak>
Jay7: hmm. could be interesting for sw infrastructure projects. it sounds as if you'd have to be careful that nobody out-bids you, though.
<Jay7>
wpwrak: I haven't seen out-bids yet :)
<wpwrak>
Jay7: so it's basically a double lottery - first you have to "win" the proposal, then the bid.
<Jay7>
kexecboot was funded in 2010
<Jay7>
but I'm still on the way..
<wpwrak>
Jay7: i haven't found any public information on the bids
<wpwrak>
Jay7: and they're still funding you ?
<Jay7>
wpwrak: I'm still doing funded work, but I haven't check-outed yet
<Jay7>
I'll finish biggest part of work in new year holidays then will invoice
<wpwrak>
ah, i see
<wpwrak>
so .. it took more than the estimated 65 hours ? :)
<Jay7>
wpwrak: not yet :)
<Jay7>
I've just done almost nothing before this time
<Jay7>
only some parts of UI improvements
<Jay7>
kexecboot development activity looks like wave :)
<wpwrak>
"wavy" projects aren't uncommon ;-)
<wpwrak>
alright. off for some more shopping.
<wpwrak>
ah no, better tomorrow
<kristianpaul>
wpwrak: what's the recommended wait of doing timings in C, ie, i want to measure the frequency of a pulse signal i'm injecting to the Xbusrt, but for that i need to have a know sampling time
<kristianpaul>
do you understand me?
<kristianpaul>
hmm i think you mentioned something about benchmakring gpio at mail list.. i'll look
<wpwrak>
so basically you'd poll a GPIO ?
<kristianpaul>
yes
<wpwrak>
what frequency are you thinking of ?
<kristianpaul>
less than 8mhz
<kristianpaul>
no wait
<kristianpaul>
4Mhz*
<wpwrak>
yes. how much less ? ;-)
<kristianpaul>
Max 4Mhz
<wpwrak>
that's still very fast
<kristianpaul>
min 0hz? .. :p
<kristianpaul>
ahh
<kristianpaul>
what test you did to know the current max IO freq i can poll?
<wpwrak>
perhaps just  for (n = 0; gpio != 1; n++);
<wpwrak>
for (n = 0; n != A_LOT; n++) read_gpio();
<wpwrak>
then see how long it took :)
<wpwrak>
you can get time with nominally us resolution with gettimeofday
<kristianpaul>
just us?..
<wpwrak>
whether the kernel implements this accuracy depends on whether the cpu hardware supports high resolution timing. x86 does. dunno about xburst. if not, you only get something in the 50-1000 Hz range.
<kristianpaul>
hmm :/
<Jay7>
usleep?
<kristianpaul>
btw i'm just a polling a single gpio Uin
<wpwrak>
in software, we call anything with us timing a hardware problem ;-)
<Jay7>
or even nanosleep
<kristianpaul>
sleep != loop ..
<Jay7>
ah.. timing as measure..
<kristianpaul>
yes
<Jay7>
I've misundestood
<kristianpaul>
dunno Xburst ... argg  lets wait i move to MM :-)
<kristianpaul>
no excuses :-)
<kristianpaul>
more work
<wpwrak>
yeah, on mm, you'd just synthesize your custom peripheral. with dma and everything ;-)
<kristianpaul>
*more* *work*
<wpwrak>
better results :)
<kristianpaul>
+1
<wpwrak>
the SIE is not the most friendly platform for doing this in a simple way. the best approach would probably to have a large ring buffer
<kristianpaul>
not friendly, indeed
<wpwrak>
(in the FPGA). then you could read the pointers / size, and do a burst read of as many bytes you have
<kristianpaul>
ring buffer remenber me: pfring  and ntop :-)
<kristianpaul>
the problem is FPGA a *other* device
<kristianpaul>
you cant
<kristianpaul>
is not just other, is  a _FPGA_
<kristianpaul>
you need a dedicated bus i think
<wpwrak>
naw, if you can it access like RAM, that ought to be find
<wpwrak>
finE
<kristianpaul>
well i can now
<kristianpaul>
like ram
<wpwrak>
implement the ring buffer inside the FPGA. it has some SRAM blocks, doesn't it ?
<kristianpaul>
sram, 2048bit
<kristianpaul>
yes
<wpwrak>
that's plenty. can you treat the SRAM as one big memory or is it fragmented ?
<kristianpaul>
fragmented
<kristianpaul>
i have up to 368,640
<kristianpaul>
bits
<wpwrak>
oh, so you have a LOT. the fragments are 2048 bits then ?
<kristianpaul>
in 20 blocks
<wpwrak>
368640/20 = 18432. where do the 2048 come from ?
<wpwrak>
anyway, you have tons of memory. why not use it ? :-)
<wpwrak>
you have already implemented the bit stream -> byte stream engine
<wpwrak>
where "w" is the write pointer, wraps around the block end
<wpwrak>
then implement a read pointer. have a register where the CPU can retrieve the write pointer, one where it can retrieve the read pointer, and one where it can read from the ring buffer.
<wpwrak>
e.g, byte = *r++;
<wpwrak>
have another register that lets you set r = w;
<wpwrak>
done
<kristianpaul>
done i fpga
<kristianpaul>
s/i/in
<wpwrak>
for the luxury edition, check for r == w after writing and if true, set a "buffer overrun" flag
<wpwrak>
yes, in the fpga
<kristianpaul>
why cpu need retrive write pointer?
<wpwrak>
to know when it's done
<wpwrak>
you could also provide r-w or w-r, if that's more convenient
<wpwrak>
also, if that's easier, you could make the whole SRAM block visible to the CPU and let the CPU worry about the read pointer
<wpwrak>
in this case, the operation is less reliable, but probably still okay
<kristianpaul>
thats how it works now (with the 2048 bits)
<wpwrak>
gee. could it get any easier ? :-)
<wpwrak>
you can still have it all working this year :)
<kristianpaul>
i want :-)
<kristianpaul>
i already have implemented  a counter wich address a memory-block-array  (i can make it bigger that 2048), but i was worried about how tell cpu when ram was full
<kristianpaul>
so if follow  you the  better aprouch is a write pointer register?
<kristianpaul>
s/better/best
<wpwrak>
first of all, it should never be full
<wpwrak>
second, you don't even need to tell the cpu when data arrives, because data will be arriving all the time.
<wpwrak>
so the cpu just needs to reset the pointer, wait a bit, find out how much data has arrived, read the data, process it, find out how much new data has arrived, etc.
<wpwrak>
what will be useful is an indication when you have a buffer overflow. that's an abnormal condition. you could signal it with an I/O pin or via a register.
<wpwrak>
your production code would always try to empty the buffer long before it overflows. but for development, you'll need to be able to tell when this happens
<wpwrak>
in case you don't want to implement a proper overflow detection, you can also just make the write pointer larger. e.g., make "w" 16 bits. use only the lower 8 for addressing. the upper 8 are used by the cpu to calculate when you had an overflow
<wpwrak>
your bit clock is 8 MHz. so your byte clock should be 1 MHz. (where did those 4 MHz come from ?) a 16 bit counter will wrap after 65 ms. this should be plenty. if it's still too short, you can make the pointer even larger.
<kristianpaul>
4Mhz <-- some clock division for testing
<wpwrak>
ah, not the real data. okay.
<kristianpaul>
i already was working today i some of what you said (i had previous problems defining ram, anyway..) what i missed was :
<kristianpaul>
so the cpu just needs to reset the pointer <<< bingoo
<kristianpaul>
it should never be full <<<< how i can ever think i should be full :/
<wpwrak>
you may have been thinking of it like the FIFO of a UART or similar
<wpwrak>
they look similar but are actually very different. let's see how many differences we can find:
<wpwrak>
1) you can afford to lose data at the beginning and the end (in fact, you're guaranteed to)
<wpwrak>
2) the incoming data rate is constan
<wpwrak>
t
<wpwrak>
3) in particular, there is little point in "waiting for the first byte" (with an interrupt or such)
<kristianpaul>
he, i was thinking in 3) before start this chat :-)
<kristianpaul>
you could make the whole SRAM block visible to the CPU <--- yes is already done
<wpwrak>
grmbl. even my new and improved boards seem to have that "valley of death" in the middle of the spectrum :-(
<wpwrak>
(at least the first one i'm testing does. let's see about the other one.)
<kristianpaul>
improved = ?
<wpwrak>
improved = much better ground design, with about 3 times the number of vias
<wpwrak>
funny. the more tests i make, the better the results :)
<wpwrak>
i kinda wonder if i'm just chasing some creepy artefact of my test setup
<kristianpaul>
"w" is the write pointer, wraps around the block end <<-- you mean all data is introduced from this point and then is filling up the stream
<kristianpaul>
not to be confused with data is filled from the block end to the block "top", right?
<kristianpaul>
just to be clear (me), if i catch the whole idea
<wpwrak>
there is no "top" in a ring buffer :-)
<wpwrak>
"w" just circles.
<kristianpaul>
but then new data will override old one at some point, right?
<wpwrak>
yes, of course. that's when you have an overrun -> an abnormal condition
<kristianpaul>
got it (finally..)
<wpwrak>
great. now you have 24 hours left to implement it this year ;-))
<wpwrak>
the ugly ones (ng2-*, at the bottom) had a problem with a bypass capacitor
<wpwrak>
the ugly yellow one that also goes very deep is a mystery. power-cycling made it behave again
<wpwrak>
the rest looks a lot more reasonable than anything i had so far
<kristianpaul>
what about ng3-ref2?
<wpwrak>
that's the one that i made disappear with power cycling :)
<wpwrak>
all ng3 are the same board. all ng2 are the same board. ng2 and ng2a differ by the bypass cap rework
<wpwrak>
rsharpe: okay to copy wolfgang on our discussion ? (in fact, it's better if we discuss things that aren't state secrets or of a very personal nature on this public channel)
<kristianpaul>
adamw_: (P2 2x7pins JTAG header) being placed manually for 100boards (ouch..)
<kristianpaul>
how bad is that for SMT line?
<kristianpaul>
(talking about timing)
<adamw_>
kristianpaul,  yes
<adamw_>
haha...i standed at there in line with that girl of operator to fine tune and place P2 about 1 hour. :)
<adamw_>
not bad. we were lucky! Two lessons learnt this time.
<adamw_>
one is the location of optical fiducial mark, the other is the P2.
<adamw_>
well..i already imagined P2 before this run.
<kristianpaul>
very nice report !
<kristianpaul>
(just finished reading it)
<adamw_>
i usually use 8mm with side board for single or panel pcb.
<adamw_>
but this time we changed to a new smt vendor with preasked them what limitation of their width of conveyor of smt machine.
<adamw_>
i got answer with 5mm.
<adamw_>
but I forgot to shift mark nearby toward the single board!!!
<SarahShadow>
hello
<SarahShadow>
would someone be willing to look over some computer parts to make sure the peices are compatable and ok choices?
<adamw_>
if the pod don't have P1 through holes, their smt machine will runs/works as human soldering. man! I almost got failure there.! hahaha.
<wpwrak>
ng2b is the same board, but with the connector removed
<SarahShadow>
im guessing this isn't the right channel for me lol
<wpwrak>
adamw_: "haha...i standed at there in line with that girl of operator to fine tune and place P2 about 1 hour" admit it - you'd have done it in five minutes if the operator hadn't been a girl ;-)
<adamw_>
wpwrak, ha..I actually shaked my fingers to align P2 stands besides her. :)
<kristianpaul>
wpwrak: add 4 pins = detuning.., you need better conectors ;-)
<wpwrak>
kristianpaul: naw, i need more forgiving physics ;-)
<kristianpaul>
hehe
<adamw_>
wpwrak, did you code in python to catch the plot of received signal strength?
<adamw_>
which equipment you measured? would it be captured by auto gpib or rs-232/usb port?
<kristianpaul>
(python) i wonder i wpwrak really code in that kind of languages ;-)
<wpwrak>
adamw_: the code is a mixture of C and shell. i just dump the received signal to a file and then process the file
<adamw_>
if you can illustrate how you do  the connection and how you dump data..it would be awesome!
<wpwrak>
adamw_: the FFT scaling is probably all wrong. but it should be good enough for comparisons.
<adamw_>
yeah..you may need pay more attention the scaling.. you plotted.
<wpwrak>
adamw_: i plug the atusb into the laptop :) well, via a usb-a-to-usb-a cable
<adamw_>
well...the plot shown has already cleared enough..really nice job!
<wpwrak>
adamw_: the usrp2 just connects to my ethernet. the dumping is done by usrp2_rx_cfile.py
<kristianpaul>
wpwrak: nice project, (tmc) i think i'll mirror your repo :-)
<adamw_>
where's the usrp2_rx_cfile.py? I didn't see it.
<wpwrak>
adamw_: it's from gnuradio
<adamw_>
ha...ok
<kristianpaul>
(usrp2_rx_cfile.py) dump the 16 bit I/Q ? isnt
<kristianpaul>
anyway
<wpwrak>
yup
<kristianpaul>
back to the buffer
<wpwrak>
odd. if i add a few more vias between the rf ground planes near the end of the antenna, i get almost the same pattern as when removing the connector. do i trust this result ?
<wpwrak>
distrustfully adds the connector back to check
<wpwrak>
hmm. looks similar to before. not quite identical, though. so it seems that the connector does have that kind of effect.