<wpwrak>
tuxbrain: yeah, great ! nice army of boards :)
<tuxbrain>
I have just finished to grind 135 atben and 120 atusb.... my thumb is aching like hel
<tuxbrain>
hell
<wpwrak>
;-))
<wpwrak>
tomorrow the testing ?
<tuxbrain>
tomorrow early morning I will flash all the atusb first
<tuxbrain>
and then round of testing
<wpwrak>
perfect. note that the boot.hex i mentioned yesterday in irc wasn't correct (that file doesn't exist). so please get the version mentioned in my mail to the list.
<tuxbrain>
yes
<wpwrak>
also,please pull the latest version of the scripts in ben-wpan/prod/. then there should be no more problems with the gpio test. unless i messed up something else ;-)
<tuxbrain>
:) , gostbuster!!!!
<wpwrak>
yeah, sorry about the P_ON test. that's what i get for not reading the manual carefully enough :-(
<wpwrak>
at least you're now ready for the turing test :)
<tuxbrain>
don't worry dude, that's is what test are for ,even to detect mistakes in the test :)
<wpwrak>
or, in case the machines take over, the AI test ;-))
<tuxbrain>
HmozHmmmmHhztaboluse
<wpwrak>
(mistakes in the test) yeah,that's the hidden cost of not having a prototype run before "mass production"
<wpwrak>
killer robot: "are you a carbon-based lifeform ?"
<wpwrak>
tuxbrain: "HHHHoHxH.HxHxHxHh.ohzoHoHH"
<wpwrak>
killer robot: "hail, brother !" (walks away, to kill your neighbours)
<tuxbrain>
common you and me know this is just a prototype run :) the mass prod will come when we pass the 10.000 units month :)
<wpwrak>
hehe ;-)
<wpwrak>
got any pre-orders yet ?
<tuxbrain>
killer robot: "are you a carbon-based lifeform ?" 02:25
<wpwrak>
even better !now you can safe the world ;-))
<tuxbrain>
Yes our fan of the Check republic (Jiri I love you) has order a two pair of each
<wpwrak>
in fact, this one should be a "killer sequence": atrf-gpio HHHH1H0.HHHHHHHHZ.z1HHHHHH delay=1000
<wpwrak>
(puts the transceiver into sleep mode. this means that it stops the clock. then the MCU is stopped too. power-cycle time ;-)
<tuxbrain>
but I have not anounce it any place yet, until at least I have a yield of 50 units of each I will not start annoy anyone but you
<wpwrak>
(jiri) yeah !! :)
<wpwrak>
hehe :)
<wpwrak>
got atrf-xtal, you'll need your dual core. hope that works for your logistics.
<wpwrak>
s/got/for/
<tuxbrain>
I have come back home, I have  arrived an pair of hours ago (the time I have used to grind atusb) I will go to sleep now to have enough estamina to wake in a four hours or so to start flashing
<wpwrak>
oh great. then you have everything you need at hand
<tuxbrain>
atusb were easy to grind than atben, but my (poor) thumb will hate me for a week, I think he is on strike of sms
<tuxbrain>
there must be a better non harming way to grind the boards ....
<wpwrak>
yeah, atusb are comparably large and have a simple shape. atben has none of this ;-)
<tuxbrain>
I can't imagine me doing so for 500 units of each....
<wpwrak>
i think the proper process is to have a kind of "guillotine"
<tuxbrain>
ops my thumb has start running out of my hand on read the avobe sentence
<wpwrak>
but maybe laser-cutting could be an option, too
<tuxbrain>
and a dremel?
<tuxbrain>
maybe too dangerouse due it can acidentally reshape the board , isn't it?
<wpwrak>
uh sure, that'll work too
<wpwrak>
you have a little bit of tolerance in case you cut into the board
<tuxbrain>
guillotine mabe ok with atusb, but totally no go for atben
<tuxbrain>
so laser cutting or dremel
<wpwrak>
dunno. these guillotines may be shaped for the board they cut
<wpwrak>
dremel should be quite okay for this sort of work, if you get the flexible axis, it's also easy to handle.
<tuxbrain>
but .. making a mould or so not sound too cheap,even laser cutting don't sound cheap either
<wpwrak>
laser cutting should be cheap if you have the infrastructure. otherwise, you have to pay someone to convert things for their machine, s&h overhead, and so on.
<tuxbrain>
well dudes time to some sleep, enjoy the pics of the wireless revolution just a few steps away, you have asked for it, tuxbrain will bring it to you, small, beauty and above all this  tons of freedom, WPAN is here to stay, enjoy and happy hacking. Good night
<wpwrak>
happy dreams ! ;-)
<kristianpaul>
nite
<kristianpaul>
xiangfu: hi
<kristianpaul>
xiangfu: the fix you did in rtems about the c heap or something, will now allow me to use the rtems fs as if were a ramdisk?
<kristianpaul>
i'll just create just one file
<kristianpaul>
so i dont need a full capable fs
<kristianpaul>
s/file/big file (90Mb)
<roh>
tuxbrain_away: nice documentation on your blog (arduino)
<xiangfu>
kristianpaul:one thing I am not sure is do we really have a RAMDISK in flickernoise?
<xiangfu>
kristianpaul: seems there is just IMFS, no ramdisk.
<roh>
wow. these efika seem nice. wannatry
<xiangfu>
kristianpaul: but we do have >100MB in IMFS.
<kristianpaul>
xiangfu: (>100MB in IMFS) sounds great !
<kristianpaul>
xiangfu: did you already tested?
<kristianpaul>
too lazy now to re-compile rtems again..
<kristianpaul>
at least i have a good reason for :-)
<kristianpaul>
xiangfu: because as you may remenber last time i tried to save a file <4Mb in the IMFS rtems just crashed..
<kristianpaul>
xiangfu: (real ramdisk) nope just the /ramdisk folder name ;)
<xiangfu>
kristianpaul: just tried copy file by FTP, failed with "netout: Broken pipe"
<kristianpaul>
xiangfu: how big was the file?
<xiangfu>
tested with 5MB and 40MB. all failed.
<xiangfu>
now I am testing with memcards.
<kristianpaul>
but there is memcard write support already?
<kristianpaul>
but anyway, seems implement ramdisk is the way to go
<xiangfu>
kristianpaul: "./4.6MB.AVI: No space left on device"
<xiangfu>
kristianpaul: I am copy file from memcard to /ramdisk.
<kristianpaul>
i see
<xiangfu>
after error, the target file size is 4325376
<xiangfu>
4.125MB
<xiangfu>
kristianpaul: (implement ramdisk is the way to go) yes.
<antoni`>
hi, how long the battery last in nanonote?
<kristianpaul>
antoni`: it may varie
<kristianpaul>
ie, i had listen to music upto 3 hours
<antoni`>
also it has Emacs Advanced Desk Calculator
<antoni`>
built in Gnu Emacs
<wolfspraul>
you mean the NanoNote?
<wolfspraul>
I don't even know, but yes, David did a lot of work to get emacs going well
<kristianpaul>
as and off-topic to this chat, we need an alarm clock feature that uses the build-n buzzer ! :-)
<kristianpaul>
s/feature/app
<wolfspraul>
definitely
<wolfspraul>
that's a big 'leap of faith' for me to trust a device to be my alarm clock :-)
<kristianpaul>
:D
<wolfspraul>
most of the time I sleep until I wake up, but if I do need an alarm it's typically serious, like an early morning flight or so
<wolfspraul>
right now I'm not sure whether I would trust my little Nano :-)
<wolfspraul>
maybe
<wolfspraul>
he he
<wolfspraul>
maybe not
<wolfspraul>
but it's a very worthy goal to go after
<wpwrak>
wolfspraul: maybe it's time to get serious and stop selling unreliable crap then ;-))
<wolfspraul>
nah I'm just very protective of the quality of my sleep
<wolfspraul>
you would probably want a rock-solid suspend too for this
<wolfspraul>
then wakeup from suspend on the alarm
<wpwrak>
with wpan, we could make the ben send out a heartbeat. other stations could listen and raise an alarm in the ben stops sending. that ought the be bullet-proof ;-)
<wolfspraul>
last I heard there were still some issues being in suspend for hours, sometimes it wouldn't wake up anymore. Not sure whether that's fixed or not.
<wpwrak>
s/the be/to be/
<wpwrak>
yeah, the mystery suspend failure. wonder what it is. seems that there's a work-around for it, though.
<DocScrutinizer>
hey, we had that on GTA02 as well
<DocScrutinizer>
bets on spurious IRQ that confuse things
<wpwrak>
sigh. when will people ever learn how to do locking ...
<wpwrak>
is cleaning up the at86rf230 kernel driver. it's quite competently done, but still ...
<DocScrutinizer>
locking? useless cruft! WFM without ;-P
<wpwrak>
yeah. some under-do it some over-do it ... a spinlock plus a flag to protect a sequence that's already guaranteed by the general flow of execution ...
<DocScrutinizer>
hehe
<DocScrutinizer>
sppinlock the kernel, so you're on the safe side of fence :->
<wpwrak>
the  only problem with such things is that you can't help but wonder what demons the author did intend to banish.
<wpwrak>
(spinlock = safe) well, sometimes ... ;-)
<DocScrutinizer>
:-x
<DocScrutinizer>
if ever devel would learn to handle IRQs correctly, they'd not need so many mutex and locks and semaphors and whatnot
<DocScrutinizer>
but for that you need to understand how your hw and CPU is handling IRQ
<DocScrutinizer>
still giggling about that "I changed it from edge to level and it caused kernel freezes" OWTTE
<DocScrutinizer>
the S3C24xx generic IRQ handler is abysmal
<DocScrutinizer>
a chimera of edge triggered and polling the GPIO - omfg :-O
<DocScrutinizer>
I really wonder what's so difficult to get this right
<DocScrutinizer>
level triggered is for "intelligent" and possibly IRQ-sharing peripherals, while you use edge (and only *one* of rising/falling edge) for dumb peripherals that mustn't share IRQ line and can't get told to reset their own IRQ output
<DocScrutinizer>
so for those dumb periph you don't have to wait until the IRQ goes down again, after you serviced the rising edge
<DocScrutinizer>
for smart periph you poll all those that share the IRQ line and tell the one (or two, or many) that admits to have triggered the IRQ that they may reset it now please. When you exit IRQ-handler you got either all periph serviced, or there's again a new one and you re-enter the irq-handler as soon as you leave it and enable level-triggered IRQ again on leaving
<DocScrutinizer>
there's definitely no use in triggering on both edges and then in handler poll the IRQ line to find out about the level
<DocScrutinizer>
nevertheless that's exactly what's done on GTA02
<qi-bot>
The build has FAILED, \
<DocScrutinizer>
and I bet it is like this to this very day
<DocScrutinizer>
qi-bot: say hi kyak
<DocScrutinizer>
oops
<kyak>
heh :)
<DocScrutinizer>
ahh, just in case it wasn't clear: all this obviously doesn't need any locks as far as it goes, as the CPU will disable IRQ when they shoot (otherwise the IRQ handler never got beyond first opcode) and you usually got a proper IRQ hierarchy where it's clearly defined which higher-prio IRQ may interrupt the handler of lower-prio IRQs, so there's no issue with re-entrance or circle calls either
<DocScrutinizer>
depending on CPU architecture there's either a dedicated reti opcode that re-enables IRQ while same moment leaving the handler (pop pc), or you got clear advice how to use a sequence of opcodes to achive same purpose (as e.g the re-enabling of IRQ only takes effect 2 opcode fetches after execution)
<DocScrutinizer>
another theoretically possible architecture of CPU would set a "breakpoint" to the opcode addr following the one where the IRQ happened (i.E to the location which return addr pushed on stack points at), and would enable IRQ on execution of this addr&opcode. I'm not aware of such architecture though
<DocScrutinizer>
wpwrak: what's the mechanism that signals activatio from a handler to a worker thread, and how is it handled to get the reset of that semaphore(?) conflict-free from interference by the handler? do you block the IRQ-handler (or the IRQ itself) for that short moment?
<wpwrak>
DocScrutinizer: within the irq handler, the infrastructure protects you. then you can disable the interrupt, schedule the worker, then re-enable when done in the worker.
<DocScrutinizer>
what? you re-enable the IRQ-handler in the worker-thread?
<wpwrak>
yup. clean and easy
<DocScrutinizer>
ouch
<DocScrutinizer>
sloooooow
<wpwrak>
if that's not fast enough, you have to process at least part of it in the irq handler. maybe not have a worker at all.
<DocScrutinizer>
nah, you have a disabled IRQ-handler for arbitrary eternities
<wpwrak>
you also have tasklets as an intermediate solution. or bottom-half handlers, if you want.
<wpwrak>
(but you need a pretty good reason for the latter :)
<DocScrutinizer>
NFC about that, always thought bottom-half == worker-thread
<DocScrutinizer>
for the semaphore thing: you probably get a clean problem-free interface with a fifo
<DocScrutinizer>
as the IRQ handler doesn't need to know about worker thread usually
<DocScrutinizer>
so if you get a ringbuffer (e.g. of timestamps) then you IRQ-handler can run ahead of worker-thead as many events as size of that ringbuffer
<wpwrak>
BH are similar to tasklets. neither can sleep. workers can.
<DocScrutinizer>
aaah
<wpwrak>
err, what semaphore thing ? i did't understand the issue
<DocScrutinizer>
that's what's my concern: your handler is deactivated to service next IRQ until worker is eventually awaking again and completing its thing
<DocScrutinizer>
(issue) probably there's been none first instance
<DocScrutinizer>
if there's anything the handler needs to know about from timeshare-land, then it probably better done that task itself instead of waiting fro worker to accomplish it
<wpwrak>
the handler is disabled but you already know that you have to do some work. if you didn't do everything, then you get another interrupt when re-enabling, if level-triggered. if edge-triggered, you re-enable before checking the status. if you can't check the status, well ... to be honest, burn that hardware and its designer with it ;-)
<DocScrutinizer>
what is "check status"?
<wpwrak>
if an interrupt handler/BH/tasklet needs to call anything that can sleep, it is in trouble. that's why we have workqueues. if the standard workqueue is too slow, you're free to create your own and tweak with scheduler settings. and yes, you can give it real-time priority.
<wpwrak>
usually the "interrupts pending" register
<DocScrutinizer>
sure
<wpwrak>
or whatever you have in your hardware
<DocScrutinizer>
hmm, you typically don't check that at all
<wpwrak>
you also have atomic operations, which can help to avoid spinlocks
<DocScrutinizer>
yes
<DocScrutinizer>
that's my point
<wpwrak>
most drivers to, because many devices have multiple internal interrupt sources
<DocScrutinizer>
RETI is such an atomic operation
<DocScrutinizer>
that's what I call servicing the smart peripheral
<wpwrak>
i means atomic increment, decrement, increment if non-zero, etc.
<wpwrak>
err. decrement if non-zero. don't think we have increment if NZ :)
<DocScrutinizer>
if multiple such smart periphs share an IRQ line, then you need to use level IRQ trigger, and service all periph that share this IRQ hw line
<DocScrutinizer>
hehe
<wpwrak>
some of them also return a status. so you can have an atomic if (non-zero) decrement; else do something;
<DocScrutinizer>
that's even better than my suggested ringbuffer
<DocScrutinizer>
and basically exactly my "semaphore(?)"
<wpwrak>
yes, if you have multiple peripherals sharing a single line, then too. but also many peripherals share the device's single external interrupt among many internal sources.
<DocScrutinizer>
sure, but the scheme is unaffected the same nevertheless
<wpwrak>
and don't forget SMP. you don't only have preemption but real concurrency to worry about. for SMP, you get a bunch of additional concepts. e.g., per-cpu variables, etc.
<DocScrutinizer>
on a logical interrupt you need to service (check) all the possible sources
<wpwrak>
correct
<DocScrutinizer>
you do this in the IRQ-handler
<wpwrak>
at least the ones that can contribute to the interrupt. if you mask them, you may not need to check them :)
<wpwrak>
that's optional
<DocScrutinizer>
for each detected periph asking for service the handler schedules some worker or similr
<DocScrutinizer>
that's why I said "possible"
<wpwrak>
usually too complex. just gets you races.
<DocScrutinizer>
possible like in "enabled"
<wpwrak>
do one thread and handle one after the other. try to do everything in that thread. voila - no sharing.
<DocScrutinizer>
aaah sure, you simply exit handler after first periph serviced, if there's another you'll catch it on re-IRQ
<wpwrak>
you may even be faster than with a horde of concurrently scheduled threads fighting for shared resources :)
<wpwrak>
you're also allowed to use a loop ;-)
<wpwrak>
if you feel really bad about looping, yield() :)
<DocScrutinizer>
you're talking bout the workers
<wpwrak>
yes
<DocScrutinizer>
yeah, that's baring topic right now for me
<DocScrutinizer>
boring
<DocScrutinizer>
;-)
<wpwrak>
yeah. it's all pretty basic :)
<DocScrutinizer>
I'm sparring the handlers ATM
<DocScrutinizer>
I don't get the weird stuff I seen for gta02 quite some time back
<DocScrutinizer>
I could imagine it all works on mere incidence there, just because timings are lucky etc
<DocScrutinizer>
that's why I was about to sort my own thoughts first
<DocScrutinizer>
and my own knowledge always been you git to re-enable the IRQ on leaving the IRQ handler
<DocScrutinizer>
got*
<DocScrutinizer>
as any worker might get delayed, stopped or even canceled for arbitrary reasons
<wpwrak>
grmbl. ^W does not delete a word ...
<DocScrutinizer>
only in shell
<DocScrutinizer>
;-)
<wpwrak>
enable on return is what the hw usually does
<DocScrutinizer>
even only in some shells, with some particular configs
<wpwrak>
what you can do is disable_irq_nosync in the irq handler, then enable_irq when you've handled it
<DocScrutinizer>
RETI, exactly
<wpwrak>
if something kills your worker, you're in trouble anyway :)
<DocScrutinizer>
not always
<DocScrutinizer>
there might be cases
<wpwrak>
well, if you insist of firing downward, move your feet away ;-)
<DocScrutinizer>
if you don't mess with re-enabling the IRQ in worker, you can restart it anyway
<DocScrutinizer>
the handler won't mind
<wpwrak>
this disable/enable split is a common and simple arrangement. if you need something more complex, you have to figure out a logic that works for you.
<DocScrutinizer>
the logic is RETI, as you said a few lines up
<wpwrak>
hint: whenever i see a complex synchronization/locking/etc. arrangement, there's usually a more simple and considerably more correct one that can replace it ;-)
<DocScrutinizer>
and it's not more complex but rather more clean and simple
<wpwrak>
enable_irq != reti
<wpwrak>
enable_irq enables a specific interrupt. not to be confused with disabling interrupts globally or on your core.
<DocScrutinizer>
well, the basic setup&enabling of the IRQ at large is sth usually only done once
<wpwrak>
setup yes. enabling/disabling not necessarily. see above :)
<DocScrutinizer>
disabling IRQ-handling on a global scale is sth you better not even think about
<DocScrutinizer>
aah well, you mean I service the periph from worker. Yes then you probably might want to disable that particular IRQ on a sw level until your worker serviced the periph and git the hw line reset
<wpwrak>
yup
<DocScrutinizer>
ok, now we're on same page again
<DocScrutinizer>
:-)
<DocScrutinizer>
all only applicable for level triggering though
<DocScrutinizer>
for edge you run into endless amount of trouble on several points of this scheme
<wpwrak>
why ?
<DocScrutinizer>
that's another argument why I got goose pimples when reading the gta02 IRQ src
<DocScrutinizer>
(why?) because you can miss IRQs
<wpwrak>
as long as you can find out what needs servicing, you can lose edges. you just need to re-enable _before_ checking what needs serviving
<DocScrutinizer>
you can miss handler calls on "expired" IRQs
<wpwrak>
worst-case, you get an edge, schedule the worker again while the worker is still running and processing the event that was just signaled. usually not a problem.
<wpwrak>
you only run into a problem if handling the event itself has a deadline you're missing. but that doesn't depend on edge vs. level. and in such cases, you probably don't want to use a worker.
<DocScrutinizer>
nope, worst case you service the periph, it triggers again, and only then you re-enable the IRQ, which will leave your IRQ unnoticed (as it's edge) and thus periph unserviced and you never again get a new IRQ
<wpwrak>
again, your general design must be suitable for handling the problem. edge vs. level and all this is secondary.
<wpwrak>
read what i wrote above: you re-enable before you check what needs handling
<DocScrutinizer>
but... wasn't there a reason we didn't want to do that and moved the enabling of IRQ to worker for this reason
<DocScrutinizer>
when you said "IRQ enabled in worker" then I got "at end of worker, after servicing periph"
<DocScrutinizer>
now you say you enable it prior to servicing periph
<DocScrutinizer>
NB servicing periph and resetting the IRQ in periph is usually atomic
<DocScrutinizer>
maybe not usually but often
<wpwrak>
at end of worker for level-triggered. before checking what's pending for edge-triggered.
<DocScrutinizer>
I.E. often readin a register gives indication if IRQ been set and also resets it same time
<wpwrak>
if you really want to, you can also enable before checking for level. it's just less efficient.
<DocScrutinizer>
yes, that makes sense, as for edge triggered you got no way to reset the periph
<DocScrutinizer>
if you enable before servicing the periph for level, you'll get the above quoted "kernel freeze"
<DocScrutinizer>
aka endless loop
<wpwrak>
as usual, that depends :) besides, nowadays, i don't seem to see a lot of edge-triggered anyway
<DocScrutinizer>
edge is out since 1984
<DocScrutinizer>
only gta02 using it
<wpwrak>
(enable before servicing) no, you would call the handler, the handler would schedule you again, but you wouldn't enter the handler yet another time, because you'll have serviced the interrupt eventually
<DocScrutinizer>
you're using edge *maybe* for dumb IRQ sources like clocks etc, that can not get reset. And even then mainly for efficiency/performance reasons
<DocScrutinizer>
(ena beore) yeah that's where devels stert to plaster their code with spinlocks/mutex/whatnot ;-D
<wpwrak>
naw, they do this for many other wrong reasons already ;-)
<DocScrutinizer>
thanks for the nice chat, have to take a nap
<wpwrak>
you just have to be careful that you enable as many times as you disable
<wpwrak>
uninterrupted dreams ! :)
<DocScrutinizer>
:-D
<DocScrutinizer>
hmmm
<DocScrutinizer>
btw you can not share IRQ line for edge, for obvious reasons
<DocScrutinizer>
so there are no multiple sources for edge that would need time consuming talk to periph
<DocScrutinizer>
so handler can do the "check" - no need to do it in worker
<DocScrutinizer>
also you obvviously don't need and can not disabled IRQ for edge. At least in a sense we used that term above and for the purpose assumed
<DocScrutinizer>
so the whole discussion is moot when it comes to using edge with that complex scheme
<DocScrutinizer>
go for level and all ok, re-enable IRQ at end of perip-servicing demuxing worker
<DocScrutinizer>
use edge and you're doomed
<DocScrutinizer>
unless it's a 1000Hz clock generator that needs a handler to count up a longint and thus has a execution time <<< the IRQ period
<DocScrutinizer>
those typically don't need any workers at all
<DocScrutinizer>
also don't need IRQ disabling in sw then, RETI wil do to avoid reentrance when clock is faster than CPU
<DocScrutinizer>
back to bed
<LunaFrizzle>
Hi all !
<vladkorotnev>
hello everyone :)
<vladkorotnev>
is it possible to install Milkymist's Flickernoise program on a usual Linux computer?
<vladkorotnev>
With re-building of course :P
<kristianpaul>
vladkorotnev: i think yes, but you can ask in #milkymist too
<kristianpaul>
vladkorotnev: rtems is ported to i386, so thats no the problem
<vladkorotnev>
kristianpaul: I asked @Milkymist on twitter and got a reply: @vladkorotnev yes, JFDI.
<vladkorotnev>
What is JFDI?
<vladkorotnev>
and btw, will it work on Debian without X?
<dvdk>
kyak: ok, so why is allegro built in trunk?  when it's not in config.full_system?
<dvdk>
s/trunk/master
<dvdk>
i.e. backfire
<dvdk>
if there are no future releases of nanonote sw for backfire, let's just kick out allegro from backfire, if it makes problem??
<kyak>
dvdk: liballegro builds in backfire (i.e. master) because there is CONFIG_ALL
<dvdk>
kyak: is there any need to continue building for backfire at all?
<kyak>
to avoid this (because backfire not tested/not maintained anymore) you should commit to trunk only
<kyak>
not to master
<dvdk>
kyak: i _am_ only committing to trunk anyway.  just bits of allegro are in backfire, because i started that port, a few days before the trunk transition
<kyak>
as xiangfu said, that was the last backfire image, so i guess no
<dvdk>
ok
<dvdk>
wrt plplot, will have to look at the build log.  it builds fine here.
<dvdk>
kyak: you committed some 'keyboard mouse' stuff a while back. Â
<dvdk>
how much work is required to make this work?
<kyak>
/etc/init.d/keymouse start should be enough
<kyak>
(it's not autostarted because most of the times i find it annoyying)
<dvdk>
kyak: not bad
<dvdk>
it does work for ASE (drawing program, just committed), HOWEVER:
<dvdk>
it does not remove the fn+keys from the keys that ASE sees, so i have duplicate key actions: mouse moves, still direction keys are pressed, so menu focus moves around.  hmm
<kyak>
yes
<kyak>
exactly the thing that annoys me
<dvdk>
looks like it always presses the button?
<dvdk>
uups, segmentation failt (ase).
<kyak>
keyboard/mouse actions intersect
<dvdk>
hmm, then maybe just hack ase to implement its own kbd mouse  suppor-?
<kyak>
always presses the button? what do you mean?
<dvdk>
how do i click?
<kyak>
red+arrow -> move
<kyak>
fn+voldown -> left click
<kyak>
fn+volup -> right click
<dvdk>
how does red change the keycode of arrow keys, i.e. what keys does it generate?
<dvdk>
pgup/down?
<kyak>
as far as i know, it doesn't change the code of arrow keys, it's a modifier
<kyak>
you can see a keycode with "showkeys"
<dvdk>
maybe just make ase ignore these
<dvdk>
it does not seem to modify the arrow keys at all
<kyak>
if ase has it's own bindings, maybe they can be altered
<dvdk>
kyak: but direction keys are so generic, we'd have to manually filter for !red
<dvdk>
or just ignore any key events if red?
<kyak>
dvdk: i'm going to try it now :) and alex4, too
<vladkorotnev>
could anyone please send me Flickernoise kernel?
<kyak>
dvdk: any chance to disable sound in alex4?
<kyak>
ase works unbelievably fast
<kyak>
menus are much fast than in qt/gtk
<kyak>
uh, segfault :)
<dvdk>
kyak: happy debugging :)
<dvdk>
kyak: yeah, using a game library as drawing backend definitely speeds things up
<dvdk>
kyak: what's the problem with sound?  think we can change the volume in alex4.cfg
<kyak>
everything is find with the sound, i just want to disable it :)
<dvdk>
look for the config file
<dvdk>
may also try allegro-setup to change volume globally for allegro games, not sure though whether alex4 honours /etc/allegrorc
<dvdk>
usually plugs in headphones to shut up the sound
<kyak>
dvdk: can't find alex4.conf
<kyak>
dvdk: heh, it's a little bit problematic to move cursor while pressed with keymouse :)
<kyak>
away
<dvdk>
question about debugging: what's the right .config flag to set to compile programs with debug information, but not keep that debug information on the target (i.e. for remote debugging)
<dvdk>
?
<dvdk>
config_debug?
<xMff>
I usually do that on a case-by-case basis
<xMff>
adding  TARGET_CFLAGS += -ggdb3
<xMff>
to the corresponding makefile
<dvdk>
xMff: set config_debug, now recompiling a single package, i now have -g3 set in cflags by default.  maybe that's going to do it.
<xMff>
binaries are stripped shortly before they're put into the .ipk
<xMff>
so they should be unstripped in both build_dir and staging_dir/target-*/
<dvdk>
hmm, i also set config_gdb, however looks like that change isn't picked up (i.e. no gdb executable in the toolchain dir)
<dvdk>
do i have to to toolchain/{clean,compile}?
<dvdk>
ah, maybe make world is going to help
<xMff>
toolchain/gdb/{compile,install} V=99
<tuxbrain_away>
wpwrak: are your there?
<tuxbrain>
all atusb flashed, just two present problems, ones was unable to flash, the other even reflashing several times fails on enumeration
<wpwrak>
pretty good !
<tuxbrain>
I was starting test with a fresh prod and tools installed but when generate the profiles the stucked black window issue starts again :(
<tuxbrain>
make spectrum
<wpwrak>
hmm. that would be "no interrupt"
<tuxbrain>
it not shows nothing but a ben.profile has been created
<tuxbrain>
the window doesn't show nothing, the ben.profiles is filled up to 26 lines
<wpwrak>
has the spectrum worked before ?
<tuxbrain>
no sorry my fauls was filled from channel 11 to 26
<wpwrak>
grmbl. my last remaining prototype is acting up :-( just let off some smoke. that can't be good ...
<tuxbrain>
ouch
<wolfspraul>
cool tuxbrain is in the midst of the beauty of manufacturing
<wolfspraul>
is it worth to track down that problem or not?
<wolfspraul>
:-)
<wolfspraul>
that's the hardest decision to make, because behind something that looks small now, something much larger may lurk later
<wolfspraul>
on the other hand you need huge volumes to justify digging into any last weird thing that you see when you make something in the hundreds or more. it may be more economical to throw those beasts away and forget that you ever saw them :-)
<tuxbrain>
wpwrak: yes spectrum has worked on previous version of the tools/prod, but no I have redone all from scratch to be sure I'm using the lastest one
<wpwrak>
tuxbrain: good. does this happen with multiple boards ?
<tuxbrain>
wolfspraul: for now just two of 120 :) I will go forward, I will send the faulty ones to werner to take a look
<wolfspraul>
yes but that is exactly my point
<wolfspraul>
you will have this all the time in manufacturing
<wolfspraul>
with every 200 nanos I make, I have one case that is just so off-chart it's mind boggling
<wolfspraul>
in most cases right now I decide to just discard them
<wolfspraul>
need to be very practical in manufacturing
<wolfspraul>
I'm sure there are some very interesting discoveries to make with those units, but who cares... the world keeps turning.
<wolfspraul>
the root cause will never be found, so what
<tuxbrain>
this work ok:
<wolfspraul>
as long as the other 199 work, seriously nobody will care much. that's just how it is, and it's only natural. perfect is the enemy of good.
<tuxbrain>
atrf-path -g net:ben usb 10 | \
<tuxbrain>
                                            ../tools/atrf-path/genpathprof +5 +5 >usb.profile
<tuxbrain>
but this not
<tuxbrain>
atrf-path -g usb net:ben 10 | \
<tuxbrain>
  ../tools/atrf-path/genpathprof +5 +5 >ben.profile
<wpwrak>
hmm. that atusb board passed the gpio test, right ?
<tuxbrain>
wpwrak: yes
<wpwrak>
and did you try another atusb as well, to see if it's just an unlucky board ?
<wpwrak>
(meanwhile, i'm trying to salvage my last prototype. seems that i shorted VBUS to GND. but i don't quite see how.)
<tuxbrain>
it fails on show the spectrum on make ben , and make spectrum in the atben part, sure is the atusb that is annoying
<tuxbrain>
_
<tuxbrain>
?
<wpwrak>
(that board was last reworked for current measurement, which didn't go very well (the rework, not the measurements). so it's been quite fragile since.)
<wpwrak>
yes, i think it's atusb. the "ben" part has an atusb sender an an atben receiver. the receiver seems to be okay, the sender not. it's the sender that has the ability to hang (while waiting for an interrupt)
<wpwrak>
maybe power-cycle the board before trying the "make spectrum". could be that the gpio test leaves some confusion behind. it shouldn't, but ...
<tuxbrain>
tested 5 more atusb all hangs make spectrum
<tuxbrain>
all pass the other tests
<wpwrak>
if you comment out the spectrum test. do they pass ? (i.e., do they also pass receive/transmit ?)
<tuxbrain>
ok gonna try
<tuxbrain>
nop receive fail :(
<tuxbrain>
hep this one pass :)
<tuxbrain>
I gonna try if it was the powercicling thing
<tuxbrain>
no even pasing the send/recive test the spectrum fails the same.
<wpwrak>
at least it's consistent :)
<wpwrak>
what if you comment-out the gpio test and power-cycle ?
<tuxbrain>
I have run make spectrum , with the board just replugged, and it fails too
<tuxbrain>
but pass the send/recieve test
<wpwrak>
that's after disabling the gpio test ?
<tuxbrain>
no with gpio test enabled
<tuxbrain>
I will disable the gpio test but "make spectrum" dont mess with gpios isn't?
<wpwrak>
make spectum messes with darker things than gpios :-)
<wpwrak>
but if receive/transmit is okay with the gpio test, that's encouraging
<tuxbrain>
my guess is something wrong with the make spectrum soft not with the hard (more than a guess is a hope :P)
<tuxbrain>
ok what exactly do you want I do
<wpwrak>
yeah, both tests use more or less the same pins
<dvdk>
hmm, aseprite crashes with SIGUSR1 (according to gdb), and i cannot even backtrace once that signal was received.  what can cause such a result?
<wpwrak>
first, let me try to salvage my board. then i can see if i can reproduce the problem here.
<tuxbrain>
ok sit down a wait, I can do that :) but please hurry , I want to sleep at least two hours this night , I have some mambo jambo with financial people tomorrow and what to be as less asleep as I can
<tuxbrain>
what-> want
<wpwrak>
board is up again ;-)
<wpwrak>
now it has a cute little loop crossing the area of destruction where a large capacitor and some traces used to be. the traces overheated and separated from the board (probably due to too much rework) and the capacitor may have produced short and smoke (not quite sure how. maybe there was a short underneath it and it just got cooked)
<mstevens>
hey! what's going on? this isn't my zsh window!
<tuxbrain>
#0Â Â 0x00007ffff7483197 in ioctl () from /lib/libc.so.6
<tuxbrain>
#1Â Â 0x00007ffff7bd75b0 in usb_control_msg () from /lib/libusb-0.1.so.4
<tuxbrain>
#2Â Â 0x000000000040689a in atusb_interrupt (handle=0x612b40) at atusb.c:300
<tuxbrain>
#3Â Â 0x0000000000404205 in atrf_interrupt (dsc=0x6128d0) at atrf.c:323
<tuxbrain>
#4Â Â 0x00000000004051c1 in wait_for_interrupt (dsc=0x6128d0, wait_for=1 '\001', ignore=1 '\001', sleep_us=10, timeout=0)
<tuxbrain>
    at misctxrx.c:47
<tuxbrain>
#5Â Â 0x00000000004059ae in start_test_mode_231 (dsc=0x6128d0) at cwtest.c:95
<tuxbrain>
#6Â Â 0x0000000000405a7e in cw_test_resume (dsc=0x6128d0) at cwtest.c:125
<tuxbrain>
#7Â Â 0x0000000000402112 in sample (sweep=0x7fffffffe410, cont_tx=128, res=0x7fffffffe110, first=0) at atrf-path.c:89
<tuxbrain>
#8Â Â 0x00000000004022a6 in do_half_sweep (sweep=0x7fffffffe410, cont_tx=128, res=0x7fffffffe110) at atrf-path.c:128
<tuxbrain>
#9Â Â 0x000000000040234e in do_sweep (sweep=0x7fffffffe410, res=0x7fffffffe0e0) at atrf-path.c:145
<tuxbrain>
#10 0x00000000004024d2 in do_sweeps (sweep=0x7fffffffe410, sweeps=1) at atrf-path.c:190
<tuxbrain>
#11 0x0000000000402dcd in main (argc=4, argv=0x7fffffffe678) at atrf-path.c:407
<tuxbrain>
opps large than expected I will use pastebin next time
<wpwrak>
hmm .. the PLL lock ...
<mstevens>
tuxbrain: ooh, you've got new stuff
<wpwrak>
this is in fact a questionable part of the tool, because one can imagine that the PLL is already locked, in which case there would be no interrupt
<wpwrak>
ths only odd thing is that it seems to work fine for me but not for you. but well, that's murphy's perogative :)
<tuxbrain>
mstevens: yep and more to come :)
<mstevens>
tuxbrain: what are those efika things like?
<wpwrak>
tuxbrain: as a temporary work-around, you could change tools/lib/cwtest.c line 93 from  wait_for_interrupt(dsc, IRQ_PLL_LOCK, IRQ_PLL_LOCK, 10, 0);
<wpwrak>
to ... 10, 20);
<wpwrak>
then  cd tools; make clean install
<wpwrak>
meanwhile, i'm thinking of a way to do this properly
<tuxbrain>
mstevens: I have some things to improve but the overall result is quite good, due the durantion of batt, and it's weight I have replaced my toshiba by one efika smartbook, I can navigate, use 3G dongle, read docs on the go (screen is quite readable on bright sun) and use some emergency gimp/openoffice/inkscape, so for me feets my need quite well, also the genesi team is very compromised with foss and his community is quite active... and are quite aff
<tuxbrain>
ordable , so the only thing they fail is that is not copyleft hardware :)
<tuxbrain>
wpwrak: so I can change this line and take the result of the tests as valids?
<mstevens>
tuxbrain: what's the OS support like? Can I use debian?
<wpwrak>
and for this i shall withdraw to my hall of contemplation, and purge myself ... in other words, afk for a little while
<tuxbrain>
mstevens: I know a guy that was actively porting debian to it, I don't know the status, I'm confortable with the ubuntu it has by default.
<mstevens>
there seem to be lots of interesting little arm devices at the moment
<wpwrak>
tuxbrain: probably. but let's first see if this solves the problem
<tuxbrain>
it doesn't hang now :)
<tuxbrain>
wpwrak: are you still there?
<tuxbrain>
running make spectrum
<tuxbrain>
and after it make ben
<tuxbrain>
still giving me the red arrow and I cannot give the test as passed, also there are not red lines to define the max min
<tuxbrain>
ok solved I forget to press D in spectrum now is ok :)
<tuxbrain>
time to test a lot of boards
<wpwrak>
back
<wpwrak>
hehe ;)
<tuxbrain>
21 test done (100% pased :) )
<wpwrak>
whee !
<wpwrak>
wolfspraul: what was our final score with gta02 MP ?
<wolfspraul>
bah, we defied basic math, impossible to tell
<wolfspraul>
archimedes would have cried hard
<wolfspraul>
I'm sure we passed at least 100%, if not more...
<wpwrak>
;-)))
<wpwrak>
i still remember your return from the fab, with all the glorious plans for remote process monitoring ;-)
<wpwrak>
thinking of it, evil me could sneak a little spy feature into tuxbrain's test script. then i'd have all the results ;-)
<tuxbrain>
wpwrak: do also an robotic arm and let me sleep motherf&%(r+
<wpwrak>
(((-:C
<wpwrak>
i think you'll get that robotic arm when the natural one you currently use wears out. which should be around the time when you make the next batch ;-)
<tuxbrain>
a robotic left arm and a dremel in my right thumb , oh yeah all controlled by an interface made of arduino and a fpga with milkymist soc embedded in my brain , oh yeah
<wpwrak>
btw, i contemplated that PLL lock situation for a bit. i haven't found the path that would make you end up with the PLL locked before it's supposed to (in which case you wouldn't get an interrupt), but there are a few candidates for this.
<wpwrak>
in any case, the best we can do is just assume the PLL does indeed lock. the change i suggested does give it plenty of time - much more than it needs even under worst-case conditions.
<wpwrak>
plus, there is no plausible failure mode where the PLL would never lock yet still pass all the tests. so i think it's safe to not insist on getting that interrupt.
<tuxbrain>
all the avobe means that I have to redo the test I have already done or not? (those enginers allways with his eternal xitxat about bits and .. things.... and so...)
<wpwrak>
maybe i can tighten the test when i have the production boards. my sickish prototype with its broken reset line isn't the most reliable reference for all this
<wpwrak>
nope. the tests you did after changing the , 0); to , 20); should be valid
<tuxbrain>
moving rotating doen't varies the line singificatly, it rise a little when they are next to each other but the line form is barelly the same, tested with difernte atusb
<wpwrak>
tuxbrain: yes. the first data point seems okay. all the others aren't
<tuxbrain>
let me test with one of your prototipes
<tuxbrain>
same form with your prototipes
<tuxbrain>
you are using openwrt or jlime
<tuxbrain>
just for discart things
<tuxbrain>
i gonna change nn
<wpwrak>
rjeffries: hmm. no board thickness mentioned. presumably only 1.6 mm. but that's okay for many DIY projects.
<wpwrak>
tuxbrain: that's with a ben running openwrt. but the distibution shouldn't matter.
<tuxbrain>
yes but I want to have the same scenario as you as possible
<tuxbrain>
ifconfig
<antoni`>
is it possible to use a wifi usb stick in nanonote?
<wpwrak>
hmm, i have a hack that should make it work better. BUT ... it makes the whole test unstable. in the sense that you get spurious loss of USB, causing test failure.
<rjeffries>
antoni' bo, nanonote only has USB device, nor USB host
<wpwrak>
(what it does is that it briefly suspends the transceiver. unfortunately, this also stops the USB clock.)
<rjeffries>
s/bo/no
<wpwrak>
(and all this looks like another case of my reset problem masking a bug. grmbl, i should have kept more prototypes for myself ...)
<tuxbrain>
you thing that ben low signal is coused by usb bad reception?
<wpwrak>
i think it's caused by the sending transceiver in an incorrect configuration
<tuxbrain>
on atben or on atusb?
<tuxbrain>
also more important those that mean are not sellable?
<tuxbrain>
make sense I also test another usb?
<tuxbrain>
sorry on another NN?
<wpwrak>
the boards are probably fine. it's the test itself that has a problem.
<wpwrak>
i need to rearrange the test a bit ...
<tuxbrain>
ok I will continue performing test as is , when you recieve the fab boards surelly we can definitive fine tune the whole thing
<wpwrak>
better work on the sugru for now, while i ponder the spectrum test :)
<wpwrak>
for sugru, it should be sufficient to use the ben->usb test (i.e., the one with a "straight" profile)
<wpwrak>
tuxbrain: okay, i understand now where the test is wrong. will be a bit of work to fix it, though.
<rjeffries>
tuxbrain here's an idea. go ahead and ship 2 ea of atben and atUSB to werner wpwrak TODAY so that we overlap shipping elapsed time with the obgoing testing and debugging
<tuxbrain>
the units for wpwrak are assured, just today is hollidays here, I will ship to him tommorow, that was decided once I got them in my hands
<wpwrak>
rjeffries: he should have done that last week :) if he sends them now, i'll have them around friday or maybe even next tuesday (monday is a holiday). i don't think he'll have the patience to delay selling them so long ;-)
<tuxbrain>
wpwrak: get out of my mind :P
<wpwrak>
but i think i can solve that little problem with the boards i have here, plus some remote verification by tuxbrain. in fact, i either have to find a way to make the USB connection survive briefly putting the transceiver to sleep, or treat the board like an at86rf230, which has a different test mode configuration. i have several at86rf230 boards and they all work beautifully. well, they'll probably start failing as soon as i actually ha
<wpwrak>
ve a use for them ;-)
<tuxbrain>
so no big announce yet? :(
<wpwrak>
i think you still have to do your sugru homework anyway, don't you ? :)
<wpwrak>
meanwhile, i'll fix that test ...
<tuxbrain>
I will sell this first hundred without any cover
<tuxbrain>
I have to perform the sugru test but not for selling this ones
<wpwrak>
oh :-(
<wpwrak>
how come ? don't you have enough sugru ?
<dvdk>
kyak:Â Â alex4 config file is /etc/alex4.ini
<tuxbrain>
that's one reason, but the main reason I have to recive reponse on the CE normative of what I have to translate of the sugru advices and how I have to stick on it
<tuxbrain>
is a chemical that has to follow some rules on advices, the sugru team advice me of that, and I'm on the path to be sure to not being cached in so silly thing of form defect
<wpwrak>
oh, sound tricky
<wpwrak>
soundS
<tuxbrain>
yeah, that's why I decide to not include it in that batch
<tuxbrain>
but I will perform the test and I will stop no body to buy sugru in the sugru shop :)
<wpwrak>
don't they already come with all the necessary declarations ? afaik, they're in the UK, so they ought to have CE.
<wpwrak>
(parallel channel) hehe ;-)
<wpwrak>
maybe dvdk can act as your unofficial channel merger then ;-)
<tuxbrain>
yeah but in english , but due I will sell it in spain I have to have all that in spanish too
<kyak>
dvdk: thanks!
<wpwrak>
(spanish) gah
<tuxbrain>
yeah silly due I can sell all over the world but as my origin is spain I have to include it in spanish, the thing is how, his sached don't have enough clear space to put a sticker without covering the english advices , so I'm looking for if just including a leaftlet in spanish is eanough
<tuxbrain>
but I don't want to delay the atben/atusb launch for this
<wpwrak>
yeah, i understand. but anyway, it would be good if you could do the technical verification, namely:
<wpwrak>
- does it affect the signal significantly ?
<tuxbrain>
due almost the target of this first wave has also manifest their will to have it nude :)
<wpwrak>
- which quantity is sufficient ?
<wpwrak>
- can you still see the LED ?
<wpwrak>
(this may affect the color choice. e.g., black sugru may be more of a problem than, say, white sugru)
<dvdk>
kyak: having a hard time with 'keymouse'  for me the volume keys are still mapped to the F14/F15 or something?  Given that 'red' maps to RALT, that's a no-go for use for clicking
<dvdk>
(and no wonder I see SIGUSR1 signal, maybe that's how a console-switch looks like)
<kristianpaul>
can you still remove it later? (suguru)
<wpwrak>
kristianpaul: one more good question for tuxbrain :)
<kyak>
dvdk: i can only advise to have a look at showkey (to see what are the keycodes) and dumpkeys (to see how they are mapped)
<tuxbrain>
not easyly... maybe is you do a some kind of "calcetin" ... that will be sure is that will not be reutilizable
<dvdk>
kyak: there were some changes recently with the volume keys.  is it right that they are mapped to F-keys?  because F+ALT is console-switch.
<dvdk>
and wrt keymouse: would be best if the keymouse modifiers were 'sticky', i.e. press red once -> arrow keys behave as mouse, press again -> arrow keys back to normal
<dvdk>
kyak: even better if we changed the kernel's key map to do the translation, i.e. red+arrow emits special key-codes that no app is going to use.  then applications would mostly ignore the mouse keys without duplicate actions.
<dvdk>
also i can't reproduce the segfault :(
<dvdk>
uh, asprite  consumes the Fn key itself, so we can't use it as mouse-click modifier :/
<tuxbrain>
one sached of sugru is enough to cover an atusb, you will need to thin it with some roll but it's clear enough, due atben is a lot thiner and small than usb I think another with a sugru sached you can cover two atben. first cusstion solved
<tuxbrain>
led no way even with a thin amount doesnt see any bright
<tuxbrain>
wooow, totally no go the spectrum goes down a lot!!!!
<kristianpaul>
hehe
<lekernel>
isn't sugru quite expensive anyway?
<wpwrak>
(spectrum) :-(
<wpwrak>
lekernel: per kilo yes. per smallest available package it's not to bad
<kristianpaul>
it looked like tat result will happen
<kristianpaul>
silicon, pla, abs... hdpe, wood?
<wpwrak>
kristianpaul: you seen murphy smile in anticipation all weekend long, haven't you ? ;-)
<kristianpaul>
wpwrak: :)
<wpwrak>
tuxbrain: dont' scrape it off yet. maybe its characteristics change when it dries
<kristianpaul>
s/silicon/silicone
<tuxbrain>
it also start failing in the gpio test, don't they say it was a no conductor????
<wpwrak>
the magic and the mystery is in the "Si", which both have
<wpwrak>
tuxbrain: let it cure
<kristianpaul>
(dries) hum i wonder if will boot after that :)
<kristianpaul>
hopefully it dint shirnk?
<wpwrak>
tuxbrain: a lot of things are excellent conductors when wet
<kristianpaul>
thats true
<wpwrak>
kristianpaul: (shrinkage) hmm, silicone vs. FR4 fiberglass ? i think i know the winner of that fight ;-)
<tuxbrain>
ok I will let it cure (24h) and retry again, but that will be sure is the no led
<wpwrak>
tuxbrain: which color did you use ?
<kristianpaul>
tuxbrain: what shape it have?
<tuxbrain>
even in the most dark room doen't see any bright comming from the sugrued atusb
<wpwrak>
we need deeper, darker caves
<tuxbrain>
kristianpaul: mmm usb green thing?
<kristianpaul>
:-)
<wpwrak>
tuxbrain: ah, for labeling, you could just call it "desiccant". lots of electronics come with that. nobody gives it a second look ;-)
<tuxbrain>
yeah not even tageted costumers :P
<wpwrak>
tuxbrain: if you have white sugru, you may want to give that one a try, that's probably the most likely to be at least somewhat translucent
<wpwrak>
hihi ;-)
<tuxbrain>
sorry no white sugru, I has to be buyed apart, not part of the multicolor bag.
<tuxbrain>
picture of the sugrued atusb
<wpwrak>
hmm yes, i suspected you didn't get that one
<wpwrak>
well, let's see whether the spectrum still sucks in 24 hours. if it's alright, you may try the white one. if not, a few euros saved :)
<kristianpaul>
0_o
<wpwrak>
tuxbrain needs masking tape ;-)
<kristianpaul>
okay, custom suguru cases :-)
<tuxbrain>
masking tape?
<wpwrak>
you could probably imprint your name, a little face, or give it horns :)
<wpwrak>
tuxbrain: (masking tape) to have clean edges. well, if it's very rubbery, a knife will do
<wpwrak>
and yes, it seems you put a lot of it. no surprise the LED is invisible.
<tuxbrain>
wpwrak kristianpaul, this was my first atempt on sugru, and "the beauty" was not in mind
<wpwrak>
sure. first see if it works at all. perfection later :)
<tuxbrain>
wpwrak: dont guet confused, I put a very thin layer, in the top, yes it has some in the "tail" due I have plege it , but avove the led there will be 0.2/0.3 mm
<wpwrak>
i imagine that you could probably just push down on it over the led. or would it have ruptured ?
<tuxbrain>
I don't want to press a lot to try to recover it after the test if sugru mask the rf
<qi-bot>
[commit] Werner Almesberger: tools/: rearranged cwtest/atrf-path to be more clear about reset and do re-init http://qi-hw.com/p/ben-wpan/9ef4478
<tuxbrain>
so that's why I have not pressed over the electronnics
<wpwrak>
ah, but you have a LOT of board to experiment with ;-))
<tuxbrain>
you want to see the closed by bankrupt in my web page isn't it?
<wpwrak>
tuxbrain: new commit, new luck. cd ben-wpan/tools; make clean all install  (the ben side doesn't change)
<wpwrak>
tuxbrain: let me find you a nice picture of a vulture ... :)
<tuxbrain>
for you or for me son of a ...
<wpwrak>
to see how things are, atrf-path -g usb net:ben
<tuxbrain>
cd,..
<tuxbrain>
the change of cwtest.c I did before doesn't allo to do git pull what I should do to force overwrite?
<wpwrak>
git stash
<wpwrak>
then proceed as usual
<tuxbrain>
hey this is the same as make ben? it looks pretty nicer now!
<wpwrak>
very good :)
<wpwrak>
now, you need to redo the profile. the one that was good before should look the same. the other one ... better ;-)
<wpwrak>
(the two should look roughly the same)
<wpwrak>
when you have them, please mail
<wpwrak>
btw, it's enough if you mail to werner@almesberger.net
<tuxbrain>
ok :)
<tuxbrain>
sended
<wpwrak>
examining ...
<wpwrak>
both drop a bit towards higher frequencies. interesting. does this change if you rotate/move them a bit ?
<Jay7>
tuxbrain: hi, I see you are official Genesi distibutor now ;)
<wpwrak>
(or if you remove metal objects from their vicinity. and/or move yourself away from them ;-)
<wpwrak>
(if you're relatively close (<= 1 m) to the boards, you'll notice that your body has quite an influence on the signal)
<tuxbrain>
yes hehehe my head is causing some interference as you said my head is causing some distruption but not enough to afect +5 -5 db, and really man I can't setup things better, my head will reamain :P
<wpwrak>
just don't move a lot during the tests ;-)
<wpwrak>
does the line get horizontal when you rotate/move ben/pc/tuxbrain ?
<wpwrak>
(that is, in some cases. you should also be able to create pretty weird patterns)
<tuxbrain>
yes if I move away (after shuttindown a lamp that seems also to affect when on) and in straight line at 1m with antenas pointing to each other, the line is barelly straight for moments, there is a little variance but mustly stright Â
<wpwrak>
perfect
<wpwrak>
i think you're all set to do the full test run now
<tuxbrain>
fine :)
<wpwrak>
i thought you'd like that ;-)
<tuxbrain>
ok at least 10 of them has pased the new test, I quite confident the 50 atusb I have tested will also pass too
<tuxbrain>
yield >0% for sure wheeeeeee
<wpwrak>
excellent :) the atben should be even easier. there's very little that can go wrong there.
<tuxbrain>
wpwrak: just one fails the test the spectrum was too low the rest seems pretty ok, after some ingest of food I will go with atben
<wpwrak>
tuxbrain: excellent so far
<tuxbrain>
setup reordered for atben testing, re profiled and ready to burn after dinner
<DocScrutinizer>
congrats
<DocScrutinizer>
you also learned a lot about RF voodoo it seems ;-D
<tuxbrain>
DocScrutinizer: yeah I totally feel like playing with Necronomicon, I don't understand anything but a mistake can be fatal :P
<DocScrutinizer>
:-D
<DocScrutinizer>
welcome to the wonderful world of analog and UHF design
<zear>
whitequark, i wonder how many clicked on the picture of the can thinking it's a flash video ;)
<DocScrutinizer>
AD can - awesome!
<DocScrutinizer>
those guys been pretty good at what they do 30 years ago, and seems they are today still
<DocScrutinizer>
a bit like HP
<tuxbrain>
the test of atben is also a stress test of the 8:10 slot :P
<DocScrutinizer>
good, excellent
<DocScrutinizer>
stress tests are really necessary
<DocScrutinizer>
I never got it how ME can get away with next to zero testing
<DocScrutinizer>
:-)
<DocScrutinizer>
open/close screen at least 5000 times, then closely analyze. operate keys of kbd at least 100k times
<DocScrutinizer>
mate/unmate cycle all plugs at least 1000 times
<DocScrutinizer>
well, we got some drop tests, but that's been it usually
<DocScrutinizer>
even those are done once, and only a second time when first time they failed as DUT missed to drop in best angle
<DocScrutinizer>
(seems common practice on some cheap manufacturers)
<DocScrutinizer>
wpwrak: how's about production test sw to facilitate THOSE tests? ;-)
<DocScrutinizer>
I realy don't think we EE should ignore our colleagues from ME
<DocScrutinizer>
it's bad enough we usually get ignored by ID
<wpwrak>
DocScrutinizer: all you need is a robotic arm with a few degrees of freedom. i've head tuxbrain is getting one soon. then he'll also be able to do ME stress testing ;-)
<DocScrutinizer>
yeah, alas it seems those robotized stress tests usually are all about how to build the test contraption in such a way it doesn't ruin the DUT, not about what a DUT encounters in RL
<DocScrutinizer>
e.g it's completely useless to operate a kbd key 100k times with a electromagnetic actor that applies always same force in same angle axectly to the center of the key cap
<DocScrutinizer>
mating connectors is even much worse in that respect
<wpwrak>
well, you do what you can ;) you will certainly catch some kinds of material fatigue that way
<whitequark>
huh... ME? ID? RL? (DUT must me Device Under Test, probably.)
<DocScrutinizer>
you can easily tell robotic mating cycles are useless by the number of USB-comes-off fatalities on N900
<whitequark>
ah yes. always thought the latter is a gamer-only acronym...
<DocScrutinizer>
well, it's for sure no accepted acronym in EE
<wpwrak>
DocScrutinizer:Â Â N900 were probably per-component mating cycles, not system cycles :)
<wpwrak>
whitequark: (RL) for a broad sense of "gamer" ;)
<DocScrutinizer>
nah, they just didn't take into account the human shortcomings when trying to apply an exactly strictly axial pulling force
<whitequark>
wpwrak: so we're talking about that kind of people who think they live in a CAD system
<wpwrak>
DocScrutinizer: well, i've heard that they fixed the problem now and removed all the faulty customers ;-)
<DocScrutinizer>
RL == Random Level (unsolicited deviation from what you planned things to be like)
<wpwrak>
whitequark: not too different from the premise of "tron", if you think of it :)
<DocScrutinizer>
wpwrak: indeed
<DocScrutinizer>
wpwrak: they even did the complete step and removed their own maemo division
<wpwrak>
DocScrutinizer: finally a company that pays attention to its customers ;-))
<DocScrutinizer>
yo :-/ :-((
<DocScrutinizer>
do you think they could've profited from showing a proto incl schem to me? ;-)
<whitequark>
DocScrutinizer: just curious, how are you related to maemo? I know you worked for openmoko, but not about nokia
<DocScrutinizer>
for their friggin N9(50)/RM-680 whatever I offered to do this *for free* and even sign their friggin NDA. Reaction: "I'm acting erratically on IRC sometimes" IDIOTS (<--- see, did it again :-P)
<DocScrutinizer>
whitequark: I'm strictly an educated user not shy to disassemble and analyze his own friggin expensive N900
<whitequark>
DocScrutinizer: have you found something horrific?
<DocScrutinizer>
I'm also the guy that made USB hostmode work despite Nokia telling "that's impossible" for ~100 times
<DocScrutinizer>
I pointed at some 2 .. 3 minor hw design flaws
<DocScrutinizer>
plus a few big ones
<DocScrutinizer>
but that's useless as N900 won't ever come in a N900-I JR edition
<DocScrutinizer>
there are some poor designs in kbd matrix that don't allow some 2-qualifier-key+CHAR 3key-combinations, for no good reason
<DocScrutinizer>
there's also an almost selfdistruct design around SoC I/O level vs LP5523 LED driver
<DocScrutinizer>
this could've been avoided by using a resistor. Other system immanent selfdistruct methods are designed to never vanish (e.g. CPU core voltage programmable), so I don't consider this particular one anything special or particularly concerning
<DocScrutinizer>
esp since it's rather hard to activate this operation mode in LP5523 and destructive effect is questionable, though it looks scary to feed 4.2V to a 1.8V GPIO
<wpwrak>
tuxbrain: btw, if you still have counterweights left, you may offer to include then in any ben+wpan bundles people are ordering. a special goodie for those not afraid of using a screwdriver :)
<DocScrutinizer>
design of the USB receptacle has been discussed all over the place ad nauseum - not really anything more to add to this topic, except my very own favourite solution to use some solder free spring contacted component like they did for AV-receptacle (and 2mm barrel power on N8x0)
<lekernel>
should say more times that things are impossible on M1 as it seems to be a strong motivator
<tuxbrain>
wpwrak: good idea :)
<wpwrak>
lekernel: HDTV ? :)
<lekernel>
HD?! impossible!
<lekernel>
fpga are too slows
<wpwrak>
lekernel: i think you're doing it right ;-)
<wpwrak>
lekernel: maybe add "it would take years of work from a team of top-notch engineers". usually, that will wake up that 12 year old kid who does it in an afternoon ;-)
<DocScrutinizer>
haha
<DocScrutinizer>
needs to google for that dude that made N900(?) output DVB signals :-)
<DocScrutinizer>
or was it ... ah now... the "transmit music from your CRT"
<wpwrak>
DocScrutinizer: does N900 include an FM transmitter yet ? :)
<DocScrutinizer>
of course it got FMTX
<DocScrutinizer>
didn't you know?
<wpwrak>
DocScrutinizer: by design or by freak ?
<DocScrutinizer>
by design and nicely integrated into maemo GUI
<wpwrak>
pity. that doesn't count then.
<wpwrak>
how about GPS sender ? that should be a worthy challenge
<DocScrutinizer>
FMRX OTOH been an "easter egg"
<DocScrutinizer>
nah, proper RDS to make cars leave the highway, that's a worthy goal for a hack ;-)
<DocScrutinizer>
FMTX knows to do basic RDS
<DocScrutinizer>
GPS jammers are hard to implement in sw ;-)
<wpwrak>
RDS sender sounds useful, yes. of course it would be most useful for the cars ahead of you ...
<DocScrutinizer>
also there's a whole class of weapons that have highly evolved aiming gear to target you with an accuracy of +-3m as soon as you start to operate such a GPS jammer ;-P
<wpwrak>
DocScrutinizer: so, if you depend on your GPS, always carry a few of these
<DocScrutinizer>
I've heard in Russia there's also a class of weapons that does same for WLAN freq that aren't allowed over there X-D
<whitequark>
GLONASS FTW!
<wpwrak>
DocScrutinizer: friend-foe identification, version 2 ;-)
<DocScrutinizer>
(russia WLAN) you'd have to ask Paul about it
<DocScrutinizer>
GLONASS seems a bit useless, for reasons I can't recall right now
<DocScrutinizer>
I'm quite interested in future european positioning system, forgot the name
<whitequark>
(glonass) with the new underwater satellite group, you can navigate submarines quite precisely
<Jay7>
hehe
<DocScrutinizer>
it should have better accuracy and availability than US GPS
<Jay7>
DocScrutinizer: freqs about 5GHz iirc
<wpwrak>
whitequark: had some bad luck with the rockets ?
<Jay7>
but looks like things are changing slowly
<DocScrutinizer>
Jay7: sounds about right, yeah. 802.11a
<whitequark>
wpwrak: I don't quite recall the details
<Jay7>
was working in ISP before 2005
<wpwrak>
DocScrutinizer: I think you misunderstand the purpose of Galileo. it's not about building a navigation system. it's about having an excuse for putting large amounts of money into the pockets of needy large companies for a decade or two.
<Jay7>
we have tried to get that freqs
<DocScrutinizer>
switch on in Moscow and wait for miltary to send someone/something to visit you
<Jay7>
but declined
<Jay7>
DocScrutinizer: I'm sure they didn't note this even :)
<DocScrutinizer>
Jay7: sure, just kidding. But that's basically what they tell you, I guess
<Jay7>
they inspecting freqs only when something starting to bother their devices :)
<DocScrutinizer>
some sidewinder class rockets work at this 5GHz freq
<DocScrutinizer>
so a large number of 802.11a APs down there would mess up those rockets' radar, that's what I've been told
<DocScrutinizer>
and it's *theoretically* possible the sidewinder aims at you rather than the intended target ;-P
<Jay7>
;)
<DocScrutinizer>
in fact it's rather simple to use a certain freq for your radar and simply aim at the strongest "echo" -quite effectively defeats all CM gear the opponent's aircraft might use
<DocScrutinizer>
but makes the missile prone to hit 802.11a APs instead of the opponent's aircraft
<DocScrutinizer>
I don't buy it, as the missile's radar needs to filter out ground reflections anyway
<DocScrutinizer>
funny detail though: you allegedly still can ground jetfighters by using a simple magnetron in a parabolic dish, to jamm all their electronic gear on board
<DocScrutinizer>
I prefer my MTHELs, also they look rather decorative out there in my garden. And the H3F exhaust fumes nicely kill off the neighbour's weed X-P
<tuxbrain>
soo boooring almost 80% atben test done and all pass
<DocScrutinizer>
aaaw ;-)
<DocScrutinizer>
scp's some of the electronic gremlins from his zoo over to tuxbrain
<wpwrak>
tuxbrain: still plan to do a range test with every single board ?
<tuxbrain>
no
<tuxbrain>
definitively no
<wpwrak>
i didn't think so ;-))))
<tuxbrain>
DocScrutinizer's gremlins also pass
<DocScrutinizer>
not after midnight in Aegypt
<tuxbrain>
midnight in Aegypt also pass
<mth>
midnight is not a problem as long as you don't feed them
<tuxbrain>
make gremlin
<tuxbrain>
PASS Midnight
<wpwrak>
;-)
<tuxbrain>
PASS GPIO Food
<mth>
always wondered when "after midnight" ends, because there has to be a time when it is ok to feed them or they'll starve
<tuxbrain>
PASS pass waterresistance
<tuxbrain>
PASS spectrum... gizmo song ok
<tuxbrain>
PASS bright light
<tuxbrain>
bah, another gremlin made by tuxbrain
<wpwrak>
one failed ?
<wpwrak>
100% pass would mean that i'd have to make nastier tests :)
<tuxbrain>
well they not pass the sugru test :P
<wpwrak>
let's wait with that verdict until 24 hours have passed. curing may still make a difference.
<DocScrutinizer>
mth: I always claim to never drink before noon - it's always after noon somewhere. It's also per definition always and everywhere after last noon
<tuxbrain>
so another PASS? PASS sugru
<tuxbrain>
I don't know if I can resist
<DocScrutinizer>
indeed 100% yield is a bad sign
<tuxbrain>
DocScrutinizer: can you elaborate please?
<DocScrutinizer>
no kidding
<DocScrutinizer>
100% yield indicates the tests may be ineffective
<DocScrutinizer>
of course only applies to sufficiently large sample sizes
<wpwrak>
now that's funny. the baluns have an operating temperature of -40 to +85 C, but a storage temperature of only 15-35 C. you don't see such a thing often :) presumably, this is to avoid accumulation of humidity before SMT. while afterwards, you don't care.
<DocScrutinizer>
exactly
<tuxbrain>
well I must say that some of the atbens has some tendency to have more signal making the spectrum make some yellow arrow for a moment , so the most mistake is that some (mabe a 5 or 6 works slightly better than the others
<DocScrutinizer>
also "storage" may mean "unlimited stashing without degradation" while "operation" means "works for the designed lifetime"
<DocScrutinizer>
tuxbrain: good enough to prove effectiveness of tests, I guess
<wpwrak>
tuxbrain: maybe you picked a weak one as the reference
<tuxbrain>
that fits in the 95% of the rest?
<tuxbrain>
just in the middle of the red lines
<wpwrak>
if the difference is small, that may still happen (and it's good that it's small)
<DocScrutinizer>
95% inside "standard deviation limits" is what you'd expect anyway
<wpwrak>
how did my reference board perform ? or was that the one you used to generate the profile ?
<DocScrutinizer>
if one or some of the 5% are too bad to pass QA depends on size of sample, as mentioned above
<tuxbrain>
reference board you mean your prototipe?
<wpwrak>
yes
<DocScrutinizer>
as well as some other parameters of the whole equation
<tuxbrain>
I have used fab one as ref
<tuxbrain>
do you want I perform the test with yours? wait
<DocScrutinizer>
100% inside standards would indicate your standards are poorly defined, or the testbed is yielding bogus results
<wpwrak>
DocScrutinizer: the spectrum test isn't particularly tight. the goal is to find severe flaws, such as a component missing, one output grounded, or such. a few dB more or less is something we can't control with our amateurish setups anyway.
<DocScrutinizer>
I agree, but I'm sure you got my basic idea
<tuxbrain>
wpwrak: the prototipe,  inside the margins tending to the low band but green anyway
<wpwrak>
tuxbrain: (test with mine) yup :) if it's way out, that would be a little worring. i may a bit out [...]
<DocScrutinizer>
gooood
<wpwrak>
tuxbrain: perfect. that's exactly what should happen ;-)
<DocScrutinizer>
I'm confident the tests are effective and you did an awesome job at assembly
<wpwrak>
tuxbrain: i expect the factory-made ones to be better overall than my DIY work. so it makes sense that the prototypes perform "low" when compared to an MP board.
<tuxbrain>
only 10 left
<wpwrak>
yield is already > 92%, no matter what happens next ;-)