2011-09-12 02:46 <kristianpaul> wpwrak: what serial console client are you using with your M1?
2011-09-12 02:48 <kristianpaul> since gtkterm and flterms for me seems to be then only ones wich display new line right way when bios is booting
2011-09-12 02:51 <wpwrak> flterm (for then i need serialboot) and neocon (the rest of the time, because i know exactly what it does :)
2011-09-12 02:52 <kristianpaul> ah flterm still !
2011-09-12 02:52 <wpwrak> s/then/when/
2011-09-12 02:53 <wpwrak> i don't know what protocol is used for serialboot. so it's flterm for these things.
2011-09-12 02:53 <kristianpaul> sure make perfect sense
2011-09-12 02:54 <kristianpaul> i was asking more because i still need bios console for some debug, but i guess is jsut matter move all to rtems
2011-09-12 02:55 <kristianpaul> and is inposible to have sane interaction with m1 bios from screen 
2011-09-12 02:56 <wpwrak> more convenient to do it from the pc :)
2011-09-12 02:56 <kristianpaul> sure, i just thinking how to access remotelly
2011-09-12 02:57 <kristianpaul> and from your lastest discoring about jtag to replace push buttons, well i'm quite done :-)
2011-09-12 02:57 <wpwrak> "discoring" ?
2011-09-12 02:58 <kristianpaul> discovering***
2011-09-12 02:58 <kristianpaul> sorry sorry
2011-09-12 02:58 <kristianpaul> quickly looks what discoring means
2011-09-12 02:59 <wpwrak> i don;t think the word exists :)
2011-09-12 02:59 <kristianpaul> phew
2011-09-12 02:59 <wpwrak> (yet :)
2011-09-12 03:00 <kristianpaul> wtf you use perl for mkboot? and is quite readable code :-)
2011-09-12 03:00 <kristianpaul> ah okay, hacked
2011-09-12 03:00 <kristianpaul> make sense
2011-09-12 03:02 <wpwrak> i used perl because of the "pack" function. makes constructing binary strings quite convenient
2011-09-12 03:02 <kristianpaul> yeah, looks prety handy i admit
2011-09-12 03:03 <kristianpaul> i have a excuse for using perl from now :)
2011-09-12 03:05 <kristianpaul> great ! now i can do make boot and make stanby :-D
2011-09-12 03:06 <kristianpaul> may be a labsw will be usefull for secure power cut, but i can ignore that now
2011-09-12 03:09 <wpwrak> i need to make labsw globally reproducible. should be useful to have this as a standard tool for qi-hw projects.
2011-09-12 03:14 <kristianpaul> a small patch for stanby, http://pastebin.com/TXtnzAQL
2011-09-12 03:14 <kristianpaul> now i can operate the m1 with no need to move my fingers from keyboard :)
2011-09-12 03:19 <wpwrak> added. thanks !
2011-09-12 03:19 <qi-bot> [commit] Werner Almesberger: m1/jtag-boot/: added "standby" (by Cristian Paul Penaranda Rojas) (master) http://qi-hw.com/p/wernermisc/cc2b07b
2011-09-12 03:20 <wpwrak> some day, i need to offer the full set of targets. e.g., also rescue
2011-09-12 03:21 <wpwrak> and retrieve/decode the configuration status
2011-09-12 03:22 <kristianpaul> I still not get fully understand the boundary scan, is like reading TPs with logic states?
2011-09-12 03:23 <kristianpaul> so you can confirm a exspected series of values?
2011-09-12 03:26 <wolfspra1l> yes this boundary scan sounds interesting - I also don't fully understand what it does
2011-09-12 03:26 <wolfspra1l> but is it some test we can run on each m1 board to better test the board?
2011-09-12 03:27 <kristianpaul> hum !! also icap support for multi bit stream boot from jtag commands
2011-09-12 03:28 <kristianpaul> s/boot/load
2011-09-12 03:29 <wpwrak> a boundary scan is basically access to all the i/o pins. but it seems you have to control them all at once. so you can't just pick one and change it (apparently) while the rest of the system keeps running
2011-09-12 03:30 <wolfspra1l> ok but what is being tested?
2011-09-12 03:30 <kristianpaul> ah just i/o..
2011-09-12 03:30 <wpwrak> wolfspra1l: seems that boundary scan doesn't support pull-ups (or pull-downs, not sure if the fpga has both)
2011-09-12 03:30 <kristianpaul> all at once sounds "dangerous"
2011-09-12 03:30 <wpwrak> kristianpaul: jtag is often used for other things as well. that's when things get murky :)
2011-09-12 03:30 <kristianpaul> for the porpuse of the test i mean
2011-09-12 03:31 <wpwrak> wolfspra1l: basically the communication between the chip and its surroundings
2011-09-12 03:31 <wpwrak> of course, you could load a purpose-built bitstream that does whatever you want. loading a bitstream via jtag is one of those extensions that go beyond the traditional boundary scan
2011-09-12 03:32 <kristianpaul> but thats mean you need still need to feed surrounding signal, wich of course make sense
2011-09-12 03:32 <wolfspra1l> our current test goes through all peripherals
2011-09-12 03:32 <wolfspra1l> and specifically tries to send data through every wire and verify that it arrived
2011-09-12 03:32 <wolfspra1l> what does the bounday scan add?
2011-09-12 03:32 <wpwrak> so the traditional boundary scan may lack flexibility. but we could certainly make use something similar for board testing
2011-09-12 03:32 <wolfspra1l> some pins of the fpga are unconnected - what can be tested there?
2011-09-12 03:33 <wolfspra1l> the only thing we don't test now is the expansion header
2011-09-12 03:33 <wpwrak> wolfspra1l: you could test for shorts and such that wouldn't normally show up. e.g., because one line overrides the other
2011-09-12 03:33 <wolfspra1l> hmm
2011-09-12 03:34 <wolfspra1l> sounds like very few additional cases could be caught
2011-09-12 03:34 <wolfspra1l> if there is a short, whatever test we have now will also fail
2011-09-12 03:34 <wpwrak> not all invalid conditions will yield invalid results all of the time :)
2011-09-12 03:34 <wpwrak> you may also have pins that you can short only for a certain amount of time, before this causes damage
2011-09-12 03:36 <wpwrak> so one test would be to pull all the pins high (except for those where this would upset peripherals). then walk though them, drive one at a time low, then read back the rest. see if any of the others has gone from high to low. (again, except cases where peripherals affect this)
2011-09-12 03:36 <wpwrak> repeat for pull-low and drive high, if possible
2011-09-12 03:37 <wolfspra1l> testing all peripherals and all i/o whether it works looks a little more targeted to me :-)
2011-09-12 03:37 <wolfspra1l> yes I can see how some rare cases can be caught like that, but those cases are not very clear to me now, neither their likelihood, nor whether the existing tests would already catch them
2011-09-12 03:37 <GitHub198> [softgpsreceiver] kristianpaul pushed 1 new commit to gps-sdr: https://github.com/kristianpaul/softgpsreceiver/commit/affd896b0d7b369d3fef9406f7994aa350e94509
2011-09-12 03:37 <GitHub198> [softgpsreceiver/gps-sdr] yafss new api - Cristian Paul Peñaranda Rojas
2011-09-12 03:38 <wpwrak> if you do it right, you can even auto-identify what external components are on a chip, without telling your test system about your circuit ;-)
2011-09-12 03:40 <wpwrak> see also m8cutils from http://m8cutils.sourceforge.net/ , directory bscan/ :)
2011-09-12 03:40 <kristianpaul> so a pcb layout should be tought very well if you want to take fully advantage of this bscan it seems
2011-09-12 03:40 <kristianpaul> or no?
2011-09-12 03:41 <wpwrak> that things was more a proof of concept than anything else. so it's kinda messy to use.
2011-09-12 03:42 <wolfspra1l> kristianpaul: what do you mean with "take full advantage"
2011-09-12 03:42 <wolfspra1l> I still don't get it
2011-09-12 03:42 <wolfspra1l> some test is cool because it's cool :-) like a roller coaster ride?
2011-09-12 03:42 <wpwrak> bscan/README and bscan/example/README would be the thing to look at. i would expect that similar but more advanced tools exist elsewhere
2011-09-12 03:43 <wolfspra1l> if you have to design a pcb to "take full advantage" of a test, that sounds scary :-)
2011-09-12 03:43 <wolfspra1l> we are testing all peripherals
2011-09-12 03:43 <wpwrak> you don;t really need to design the PCB for it
2011-09-12 03:43 <wolfspra1l> the tests are thought out in such a way to catch every conceivable error
2011-09-12 03:43 <wpwrak> ;-)))
2011-09-12 03:43 <kristianpaul> well i guess that for some test you need to inject a signal some how
2011-09-12 03:43 <wolfspra1l> like the dram tests write and read all sorts of patterns to rule out problems with the wires etc.
2011-09-12 03:44 <wolfspra1l> I would first like to understand which additional (!) error case can be caught with a 'boundary scan'
2011-09-12 03:44 <wolfspra1l> not needed now, just saying
2011-09-12 03:44 <wolfspra1l> some tests we could add are temperature cycles, but most likely only for design verification, not for each board
2011-09-12 03:45 <wolfspra1l> the magic boundary scan can most likely not replace those tests :-)
2011-09-12 03:45 <kristianpaul> wpwrak: not going depth this bscan sounds to me for focused on PCB and verify traces etc, thats was i wondering how i can really try to test as much as i can with it ;)
2011-09-12 03:45 <wpwrak> things like shorts or other abnormal current paths. e.g., those weird suspected ESD damages (the NOR oscillation) ought to show up on such a test
2011-09-12 03:45 <wolfspra1l> kristianpaul: we are verifying traces
2011-09-12 03:45 <wolfspra1l> that's why we go through _all_ peripherals, and put a load on each that will demonstrably verify each trace
2011-09-12 03:46 <wpwrak> you can of course do a boundary scan without using anything that's labeled boundary scan
2011-09-12 03:47 <wpwrak> but a purely functional test that doesn't probe for effects that affect the principal function may not catch all the cases
2011-09-12 03:47 <kristianpaul> he, i want sat that for chipscope ;)
2011-09-12 03:48 <wpwrak> a boundary scan basically takes everything one level lower. you don' think about chip functions but about pins instead
2011-09-12 03:48 <kristianpaul> s/sat/said that
2011-09-12 03:49 <wpwrak> a device may appear to function on the outside but it's still defective
2011-09-12 03:50 <wolfspra1l> still sounds theoretical
2011-09-12 03:50 <wolfspra1l> we are testing every peripheral, every i/o
2011-09-12 03:50 <wpwrak> e.g., parasitic effects can drive signals. if you're (un)lucky, they just produce the level your functional test expects
2011-09-12 03:50 <wolfspra1l> the purpose is to make sure that each peripheral/device works as expected
2011-09-12 03:51 <GitHub13> [softgpsreceiver] kristianpaul pushed 4 new commits to gps-sdr: https://github.com/kristianpaul/softgpsreceiver/compare/affd896...4404f09
2011-09-12 03:51 <GitHub13> [softgpsreceiver/gps-sdr] yafss new api - Cristian Paul Peñaranda Rojas
2011-09-12 03:51 <GitHub13> [softgpsreceiver/gps-sdr] namuru debug commands now on rtems shell - Cristian Paul Peñaranda Rojas
2011-09-12 03:51 <wolfspra1l> once that is the case by definition it's not 'defective' :-)
2011-09-12 03:51 <wpwrak> do you also test current consumption in relation to the system state ?
2011-09-12 03:51 <wolfspra1l> additional tests are great, but they need to be targeted and catch something the other tests don't catch
2011-09-12 03:51 <wolfspra1l> oh sure, Adam is very picky about current consumption as you can imagine
2011-09-12 03:52 <wpwrak> so for each configuration state, you have a precise system-wide current consumption ?
2011-09-12 03:53 <kristianpaul> each could be a loooong list i think :)
2011-09-12 03:53 <wpwrak> e.g., base state = xxx.xxx mA. turn MIDI on = xxx.xxx mA. turn MIDI off but audio codec's oscillator on = xxx.xxx mA. send a 0 on NOR D0 = xxx.xxx mA. send a 1 instead = xxx.xxx mA ? etc.
2011-09-12 03:53 <wpwrak> very very very long :)
2011-09-12 03:54 <kristianpaul> of course computers are fast those days :)
2011-09-12 03:55 <wpwrak> but you need to do such things to find shorts. e.g., if two pins are, by accident, driving the same signal with conflicting values, one may always "win". so if the one is the pin you actually expect to drive this signal, you don't see anything abnormal.
2011-09-12 03:56 <wpwrak> except that the system will consume more current
2011-09-12 03:57 <wpwrak> and maybe this will reduce the system's lifespan. or have other effects, e.g., on a system condition the functional test didn't include. (i highly doubt the functional tests test every corner case)
2011-09-12 03:59 <wpwrak> i'm sure DocScrutinizer has a nice collection of horror stories for what can happen if you short a chip's output to something else :)
2011-09-12 03:59 <roh> i also think that measuring current is a good 'catchall' test
2011-09-12 04:02 <kristianpaul> sure we agree, but not get mad with a not end number of combinations
2011-09-12 04:02 <wpwrak> current measurement can also replace a lot of other tests. e.g., if you have a LED, a current test can tell you if it's open, shorted, or working :)
2011-09-12 04:03 <wpwrak> kristianpaul: you basically want to have a model of the device. then generate the test patterns from this.
2011-09-12 04:03 <kristianpaul> you can do current test by bscan?
2011-09-12 04:03 <kristianpaul> i mean current measurement
2011-09-12 04:03 <wpwrak> you need a measurement instrument for this
2011-09-12 04:03 <wpwrak> the boundary scan itself doesn't contain any such things
2011-09-12 04:04 <kristianpaul> but bscan can help you to open/close some gates and path current to the righ intruments i guess
2011-09-12 04:04 <DocScrutinizer> my words since 2008
2011-09-12 04:04 <wpwrak> but you can set up your system to a quiescent state where, say, the LED is off, measure system current, then turn on the LED and measure again. if the current doesn't change, something is broken.
2011-09-12 04:05 <wpwrak> if it goes up by, say, 10 mA (exact value depends on design), the LED is lit. if it's considerably more, something is shorted.
2011-09-12 04:05 <wpwrak> kristianpaul: exactly
2011-09-12 04:06 <DocScrutinizer> you can't even "test each peripheral for correct function" as supposed above. There are LOTS of functions that are hard to impossible to test. Think overcurrent signals, IRQs that usually don't fire, RTS/CTS etc pp
2011-09-12 04:06 <wpwrak> yup. lots of things that are very hard to trigger :)
2011-09-12 04:07 <wpwrak> it's more like driving a car around the block and then declaring it to be in good working order :)
2011-09-12 04:07 <wpwrak> it's more a test of the absence of obvious fatal flaws
2011-09-12 04:08 <roh> well.. i am not saying that all boards need to be in a 10mA window to be 'good' ... just that something which draws >150mA more than everything else working might be 'fishy'
2011-09-12 04:08 <DocScrutinizer> you usually do A|B tests with DUT and reference, and probe and compare as many parameters as possible
2011-09-12 04:08 <DocScrutinizer> also drive VDD to and beyond the limits
2011-09-12 04:09 <DocScrutinizer> etc pp
2011-09-12 04:09 <wpwrak> of course, it's nice as a sanity check. prevent "missed the burning forest but all the trees looked good" kind of mishaps :)
2011-09-12 04:10 <wpwrak> roh: an absolute 10 mA window is unrealistic, already due to component tolerances. but a relative 10 mA window, e.g., board X with LED off vs. board X with LED on, that is quite realistic
2011-09-12 04:11 <wpwrak> and of course, of you have a board Y that's 10% higher in general than board X, you may have a problem there :)
2011-09-12 04:11 <DocScrutinizer> then you design a special test program that intentionally triggers as many of those fringe cases that usually never happen, like FIFO overflows and whatnot
2011-09-12 04:12 <DocScrutinizer> setting those 10% margins is pretty simple, after 10 DUT's runs you have a god statistic base what'S ok and what's fishy
2011-09-12 04:13 <wpwrak> wolfspra1l: these things don't have to be a nightmare to do. if you automate them properly, they're not any worse than extensive functional tests
2011-09-12 04:13 <DocScrutinizer> exactly
2011-09-12 04:13 <DocScrutinizer> my words since 2007
2011-09-12 04:13 <kristianpaul> wasnt 2008?
2011-09-12 04:14 <DocScrutinizer> but OM never been interested in *decent* QA tests in fab :-/
2011-09-12 04:14 <wpwrak> my code since 2006 ;-) (well, somewhat)
2011-09-12 04:14 <wpwrak> DocScrutinizer: don't test for bugs you're not prepared to handle (-:C
2011-09-12 04:15 <kristianpaul> hum??
2011-09-12 04:15 <roh> *g*
2011-09-12 04:17 <kristianpaul> i dont think we looks for bugs, i wonder who find who first ;)
2011-09-12 04:17 <wpwrak> the somewhat difficult business relationship between OM and the factory may also have played into this to some extent
2011-09-12 04:18 <wpwrak> not that i would have had high hopes for actually getting such things right, but this situation may have prevented them from even being considered
2011-09-12 04:20 <wpwrak> after all, any board that fails is a yield problem. now, who gets the blame ? and whoever gets blamed is still convinced it's the other side's fault, so they'll hold a grudge. and so on.
2011-09-12 04:20 <wpwrak> not the ideal climate for being good at detecting defects :)
2011-09-12 04:21 <wpwrak> the less you find, the fewer incident on the home front :)
2011-09-12 04:21 <wpwrak> the customers are far away. and maybe they don't notice either :)
2011-09-12 04:22 <roh> pfff.. blame problems
2011-09-12 04:22 <wpwrak> of course, that's generally a problem. good QA will invariably run into situations where any bad news they may have will be extremely unwelcome
2011-09-12 04:23 <roh> i have heard from people working inside a big german industrial hw manuf, which do proper testing how that goes
2011-09-12 04:23 <roh> these guys even do real clima-chamber tests etc
2011-09-12 04:23 <roh> at one time we got switches from their lab with temperature sensor wires still hanging from some holes, taped to the top with gaffa
2011-09-12 04:24 <wpwrak> roh: but i bet that wasn't a "the three stooged make a smartphone" kind of setting
2011-09-12 04:25 <roh> naah. they build stuff.. as well as switches spec-ed to be used in railway and underground tunnels etc.
2011-09-12 04:25 <roh> they even got ip67 proof switches.. nice stuff... tricky connectors ;)
2011-09-12 04:26 <wpwrak> rubber seals ?
2011-09-12 04:26 <roh> from regular vendors we get sometimes stuff with loose smt caps inside... *sigh* .. how many times we soldered such stuff on before using equipment on a ccc event ;)
2011-09-12 04:27 <wpwrak> the tragedy of the lowest bidder :)
2011-09-12 04:27 <roh> wpwrak: not only.. pressure-cast aluminium cases with seals and plugs with seals etc. but their ip67 line is afaik still 100mbit.. no gbit connectors avail in pressure proof or so
2011-09-12 04:29 <wpwrak> just make little sealed enclosure around it ? like a barrel, rubber seal at the front, a thread on the outside and a nut to hold it all down ?
2011-09-12 04:29 <roh> heh.. i bet that will never be ip6x ;
2011-09-12 04:30 <wpwrak> dust and water. doesn't sound *that* difficult
2011-09-12 04:31 <roh> ip67 is 1meter deep immersion
2011-09-12 04:31 <wpwrak> yes. rubber seal :)
2011-09-12 04:32 <roh> pressure is your issue. all connectors need to go through fittings. just a 'clamp style seal' doesnt work
2011-09-12 04:33 <wpwrak> i would screw it in place. or maybe have a bayonet or such
2011-09-12 04:33 <wpwrak> of course, that would be a special-purpose item, even if relatively simple. so it won't be cheap
2011-09-12 04:35 <wpwrak> basically the way how you'd connect ethernet in docked space stations - you just leave the door open and run the wire across. maintaining the docked and sealed state is a problem someone else has already solved for you :)
2011-09-12 04:43 <kristianpaul> any other way of automate ftp transaction besides using expect ?
2011-09-12 04:46 <roh> hm. ncftp?
2011-09-12 04:47 <wolfspra1l> kristianpaul: curl
2011-09-12 05:00 <kristianpaul> nice curl support telnet as well 
2011-09-12 07:08 <DocScrutinizer> D-Link those suckers! Thanks to "Error! End time needs to be later than start time" for daily periods I can't define a 1 minute downtime for DSL at 6:30 in the morning :-(
2011-09-12 07:56 <roh> DocScrutinizer: get a real modem
2011-09-12 07:56 <roh> can recommend these 4E adsl2+ ones from pollin (congster type)
2011-09-12 07:57 <roh> http://www.pollin.de/shop/dt/NTM4ODgyOTk-/Computer_und_Zubehoer/Netzwerktechnik/Modems_Netzwerkkarten/DSL_Modem_CONGSTAR_DSL_Box_Zwei_ADSL2_.html
2011-09-12 07:57 <roh> no it cannot do anything besides bridging, but it does that very well :)
2011-09-12 07:59 <roh> and they are so cheap you can get a pack an have some spares for the next shitty-weather-event
2011-09-12 08:03 <wolfspra1l> 4 EUR, and 3 EUR if you buy three
2011-09-12 08:04 <wolfspra1l> in China you probably buy the entire box for 1 USD
2011-09-12 08:04 <wolfspra1l> maybe 1.50 :-)
2011-09-12 08:07 <roh> naah.
2011-09-12 08:08 <roh> afaik they are some oem variant for congster (german telecom cheap prices brand).. dunno why. maybe because they have no switchmode-psu
2011-09-12 08:08 <roh> its a broadcom cpu, minimal flash and ram (thats why openwrt isnt possible). .. bcm63xx series cpu. quite fast
2011-09-12 08:09 <wolfspra1l> naah what? you think it's not sourced in China and sells here for 1.50 USD?
2011-09-12 08:10 <wolfspra1l> those kind of prices are pretty much only possible if you have companies that can operate on super thin margins, and have high volume, i.e. serve the world
2011-09-12 08:11 <roh> wolfspra1l: as far as i understand it that price is 'written off hw' .. only sold because its better than scrapping
2011-09-12 08:12 <roh> usually modems of that spec still are 10-20Euro
2011-09-12 08:13 <roh> my best guess still is the psu.. its a ac-ac heavy old transformer type. surely not latest EU-power-saving-regulation compliant
2011-09-12 08:13 <wolfspra1l> "written off" - hmm. dunno.
2011-09-12 08:13 <wolfspra1l> I'm not surprised about the price.
2011-09-12 08:13 <roh> pollin is known as 'resterampe' 'grabbelkiste'
2011-09-12 08:13 <wolfspra1l> if it's new, it's from China and made for the world, sells as 100 different brands here and there
2011-09-12 08:14 <wolfspra1l> if it's a one-off thing, ok, that's different
2011-09-12 08:14 <roh> i would be surprised if you can buy the bom even in big numbers for the used chips for these 4E
2011-09-12 08:14 <wolfspra1l> why not
2011-09-12 08:15 <roh> really fresh soc. its faster than the nanonote afaik
2011-09-12 08:15 <wolfspra1l> so?
2011-09-12 08:16 <wolfspra1l> we don't know the story behind this product, so it's just speculation
2011-09-12 08:16 <wolfspra1l> but in high volume chip prices come down, and become more a factor of die size
2011-09-12 08:17 <roh> ah.. no.. sorry.. misplaced it.. its slower.. 250mhz
2011-09-12 08:18 <wolfspra1l> the chinese manufacturer probably can pick from a number of silicon vendors to make a 'dsl modem box'
2011-09-12 08:18 <wolfspra1l> so if broadcom wants to get a little volume into their system, they need to make a price based on die size + x%
2011-09-12 08:19 <wolfspra1l> if their die size is uncompetitive, that's their problem. that's why you typically do another tape-out once you have achieved a 20-30% die size reduction
2011-09-12 08:19 <wolfspra1l> then you will make back the tape-out costs over time (depends on volume of course)
2011-09-12 08:19 <wolfspra1l> this is all assuming it's a new price, not some one-off
2011-09-12 08:19 <roh> i think in that market its not so much choice anymore..
2011-09-12 08:20 <wolfspra1l> don't say that :-)
2011-09-12 08:20 <wolfspra1l> you don't think some Chinese foundry can clone Broadcom chips?
2011-09-12 08:20 <roh> not so many soc i know which can handle the big telecoms here in europe. (its the tcom who makes the spec which the modem then is made to fulfill)
2011-09-12 08:21 <wolfspra1l> if the soc is produced at 90nm or higher, it can definitely be cloned
2011-09-12 08:21 <wolfspra1l> that brings prices down quickly :-)
2011-09-12 08:21 <roh> i think they can clone it. but the german telecom wouldnt buy it. they can get brcm to do their bidding as dictated
2011-09-12 08:21 <wolfspra1l> in your dreams
2011-09-12 08:22 <wolfspra1l> the reason the price comes down is because Broadcom (in this scenario) understands that it makes no sense to fight mother nature
2011-09-12 08:22 <wolfspra1l> so yes, Broadcom can charge die size + 20%
2011-09-12 08:22 <wolfspra1l> because it's 'original'
2011-09-12 08:22 <wolfspra1l> whereas the no-name foundry would charge die size + 5%
2011-09-12 08:23 <wolfspra1l> they rather take those 20% than be 'right' but out of business
2011-09-12 08:24 <wolfspra1l> if it's indeed a new price, would be interesting to look at the chips
2011-09-12 08:24 <wolfspra1l> at 4 EUR, it's getting tight
2011-09-12 08:24 <wolfspra1l> that's minus VAT etc.
2011-09-12 08:24 <wolfspra1l> amazing
2011-09-12 08:24 <roh> its unused, original packaged
2011-09-12 08:24 <wolfspra1l> but I've seen similar amazing things here, like the silicone keyboards we include with m1 that we source for 2.50 USD or so
2011-09-12 08:24 <wolfspra1l> 2.50 USD!
2011-09-12 08:25 <wolfspra1l> I took one apart
2011-09-12 08:25 <wolfspra1l> so many parts, so many pieces
2011-09-12 08:25 <wolfspra1l> pcb
2011-09-12 08:25 <wolfspra1l> cable
2011-09-12 08:25 <wolfspra1l> usb connector
2011-09-12 08:25 <roh> the recommended price was 99E
2011-09-12 08:25 <wolfspra1l> three plastic layers to form connecting pad
2011-09-12 08:25 <wolfspra1l> a chip on the pcb, some passive parts
2011-09-12 08:25 <wolfspra1l> a led
2011-09-12 08:25 <wolfspra1l> silicone
2011-09-12 08:25 <wolfspra1l> plastic case, even a 1-page manual
2011-09-12 08:25 <wolfspra1l> and it retails for 2.50 USD
2011-09-12 08:26 <wolfspra1l> everybody in the supply chain operates on a few cents
2011-09-12 08:27 <wolfspra1l> it does say 'out of stock', so our speculation may be pointless
2011-09-12 08:34 <DocScrutinizer> roh: I need a router, not a modem
2011-09-12 08:34 <roh> eh. i see
2011-09-12 08:34 <DocScrutinizer> DIR-615 here. Is this POS openWRT capable?
2011-09-12 08:35 <roh> cheapest i know.. 24euro thingie from km-electronic. some tp-link
2011-09-12 08:36 <roh> 841 or 741 or so.. would need to check again
2011-09-12 08:36 <roh> uh.. the dlink.. which revision do you have?
2011-09-12 08:37 <roh> http://wiki.openwrt.org/toh/d-link/dir-615
2011-09-12 08:37 <DocScrutinizer> H/W Ver.: D3
2011-09-12 08:40 <roh> hm. small flash but the page says possible. no usb also
2011-09-12 08:40 <DocScrutinizer> D3E even
2011-09-12 08:40 <DocScrutinizer> yeah, no USB obviously :-D
2011-09-12 08:40 <roh> Ralink?
2011-09-12 08:41 <roh> hm.. D1 and 4 seem supported.. but i dont see D3.. weird
2011-09-12 08:48 <DocScrutinizer> yeah
2011-09-12 08:52 <wolfspra1l> roh: do you know much about developments in routers?
2011-09-12 08:52 <wolfspra1l> more or less Linux?
2011-09-12 08:52 <wolfspra1l> integrated dsl or cable modem? integrated wifi?
2011-09-12 08:52 <wolfspra1l> is it becoming harder or easier to install something like openwrt?
2011-09-12 08:53 <wolfspra1l> I don't follow routers closely, unfortunately. too little time...
2011-09-12 09:15 <roh> wolfspra1l: i prefer to keep those seperated
2011-09-12 09:15 <wolfspra1l> so it's just a black-box to you?
2011-09-12 09:15 <roh> there isnt really any vendor free complete atm implementation atm
2011-09-12 09:15 <wolfspra1l> oh I see. you keep the dsl modem separate.
2011-09-12 09:16 <roh> yes.. the wan phy. because its cheap and can be seen as a transparent bridge usually.
2011-09-12 09:16 <roh> e.g. we have cable and nat-ed dsl here.. i can just move the 'wan' ethernet cable from one to the other to switch from cable to vdsl
2011-09-12 09:18 <roh> stuff breaks and it makes replacements easier/more practical for us
2011-09-12 09:20 <roh> wolfspra1l: the most important development from my pov is 'shorter lifespan' as well product-cycle wise as well as cheaper entry hw
2011-09-12 09:20 <roh> i think larsc or nbd know details there much better than i am
2011-09-12 09:21 <roh> what i would wish for is a more decent amount of ram and flash and better performance.. then i would do more on these small machines
2011-09-12 09:22 <roh> also to seperate from the market a bit. one cannot compete with 24E devices if its about supporting sw development
2011-09-12 09:23 <roh> people paid insane amount of money for the 'good' old routers with minipci slots and 32mb ram for some time
2011-09-12 09:24 <roh> i can be wrong but afail there is no 'mainline supported' platform atm..  atleast not intended by the vendor
2011-09-12 09:25 <roh> wolfspra1l: what are you thinking about?
2011-09-12 09:25 <wolfspra1l> nah, just following
2011-09-12 09:25 <wolfspra1l> I think prices will continue to fal
2011-09-12 09:25 <wolfspra1l> fall
2011-09-12 09:26 <wolfspra1l> more integration, higher volume, etc.
2011-09-12 09:26 <wolfspra1l> but I don't know, so I'm curious. And you gave me some good answers already - thanks!
2011-09-12 09:48 <roh> k
2011-09-12 11:00 <DocScrutinizer> in the old days that's been called MAU iirc
2011-09-12 11:00 <DocScrutinizer> media attachment unit
2011-09-12 11:01 <DocScrutinizer> just nowadays it's not yellow cable but TV cable, or DSL
2011-09-12 11:03 <DocScrutinizer> wolfspra1l: keep an eye on AVM
2011-09-12 11:04 <DocScrutinizer> if there's such a thing like a "standard" here then it's FritzBox
2011-09-12 11:07 <wpwrak> (EUR 4 bridge) you could probably make some money by trowing away bridge and power supply and just selling the ethernet cables individually ;-)
2011-09-12 11:13 <DocScrutinizer> you can also make money here by copying EAN barcodes and stick them to arbitrary plastc bottles, then insert to return machines and get a coupon about 15ct per bottle
2011-09-12 11:14 <DocScrutinizer> less efort than making money on selling crappy ethernet patchcables
2011-09-12 11:28 <qi-bot> [commit] Werner Almesberger: labsw/web/: added visual indication of test loop (master) http://qi-hw.com/p/wernermisc/5085080
2011-09-12 11:28 <wpwrak> sounds like a plan :)
2011-09-12 11:30 <wpwrak> hmm, EAN ... that was the European Academic Network. some nightmare in X.400. Europe's proud stand against the wild hordes of the Internet :)
2011-09-12 23:18 <qi-bot> [commit] Werner Almesberger: labsw/: removed copper from mounting holes (master) http://qi-hw.com/p/wernermisc/5ef4f4a
2011-09-12 23:18 <qi-bot> [commit] Werner Almesberger: labsw/: corrected size of 2512 footprints (master) http://qi-hw.com/p/wernermisc/a48f34a
2011-09-12 23:18 <qi-bot> [commit] Werner Almesberger: m1rc3/norruption/LOG: still trying to reproduce the NOR corruption ... (master) http://qi-hw.com/p/wernermisc/50d66bf
2011-09-12 23:55 <qi-bot> [commit] Werner Almesberger: fped/gnuplot.c (gnuplot_arc): implemented drawing of arcs (master) http://qi-hw.com/p/fped/6dfbb51