Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<lindi-_> and yeah, schedule does not seem to be called ever
<lindi-_> I wish openocd supported single stepping...
* DocScrutinizer would toss a Lauterbach over to lindi, if it wasn't such an incredibly expensive and closed and dongled tool that lindi-_ wouldn't like it anyway
<DocScrutinizer> it's really convenient to click the "load" button which implicitly resets the attached DUT, and a few moments later you see the first opcode of ROM-BL highlighted in the listing window, and a "stopped" in the status line
<DocScrutinizer> even more convenient is to set a breakpoint to the interesting line of your patched code, and when it stops again, click on the two parameters to strcmp() to find you passed a pointer to "LLDEBUG" while the compared item in the list is "LLDebug"
<DocScrutinizer> probably saved me like 2h of code analysis today
<DocScrutinizer> now you could say "duh, use printf() - just does the same for you" - ust LLDebug was the name of the UART where printf() prints to ;-D
<DocScrutinizer> so you could say I patched printf(), and it'S not a nice idea to use printf(9 inside printf() to debug it
<DocScrutinizer> btw Lauterbach trace32 software can do this on ARM core SoC via JTAG
<DocScrutinizer> so if it wasn't for the dongle, you probably wouldn't even need the Lauterbach hardware
<lindi-_> seems it is never exiting the interrupt handler
<DocScrutinizer> only thing that doesn't work when you use JTAG only is the 512MB backtrace buffer in Lauterbach hw, that allows you to run the code "backwards"
<DocScrutinizer> at least that's not possible in realtime via JTAG ;-D
<lindi-_> yeah nice non-free tools indeed :/
<DocScrutinizer> I thought you'd appreciate to hear what's possible via JTAG if only the free tools were smart enough
<lindi-_> now I'd like to know how the cpu gets to execute instruction at 0xc02975a4
<lindi-_> it's not executing the instruction before that so something is branching there
<DocScrutinizer> hehe
<lindi-_> but according to source there isn't any kind of loop :/
<DocScrutinizer> a clear case for backtrace buffer
<DocScrutinizer> or auto-singlestepped mode
<DocScrutinizer> though *terribly* slow, it should be able to create a backtrace as well
<lindi-_> hmm, single stepping seems to work after some openocd magic :/
<whitequark> DocScrutinizer: gdb has some support for reversible debugging, doesn't it?
<DocScrutinizer> should
<DocScrutinizer> I admit I'm not a gdb wizard
<whitequark> I'll just try it for my arm now
<whitequark> ... only to find out that I do not have it atm.
<whitequark> DocScrutinizer: actually, if your arch has a proper gdbserver, then you have half of those features for certain, and maybe have reversible debugging, if it's actually working. so things are not that bad
<DocScrutinizer> I never said things were bad
<whitequark> ok, then I misunderstood you
<DocScrutinizer> just debugging kernel on arm seems wasn't possible a year ago, since no free (or no at all) version of kdbg available for that
<DocScrutinizer> lindi-_ is debugging suspend/resume issues on GTA02, not exactly gdb's primary domain
wej [wej!~j@m2.mullvad.net] has joined #qi-hardware
<DocScrutinizer> and I think I should get a beer now at my pub, so I'll see sth else than LCD screens all day and all night
<DocScrutinizer> :-D
<wpwrak> you could try to find a CRT for home use :)
<DocScrutinizer> maybe I could invent some goggles/glasses that are made of some special material energized by washing with liquid air from Himalaya, to remove that nasty mind corrupting vibrations from that light that goes thru the liquid crystal. Might be a commercial success story on next esoteric convention
<wpwrak> sounds like a plan
<roh> re
<DocScrutinizer> MEH
<wpwrak> that was a quick beer
<DocScrutinizer> no, that was the slowest waitress I've ever seen, paired with amnesia and a bunch of drunken assholes
<DocScrutinizer> I probably would die from thirst in there
<wpwrak> ;-)
<DocScrutinizer> the reward for trying to do weird things which are not related to looking at LCD
<wpwrak> poetic justice, swiftly served by the agent on duty, disguised as a waitress
<DocScrutinizer> indeed
<DocScrutinizer> don't forget her troops! a really nice bunch of weird drunken people, one sitting left to me and arguing with the one right to me, face to face. Probably the waitress didn'T even dare to bring a beer for me, no way to place it anywhere
* DocScrutinizer gors washing his face
<wpwrak> you could have asked one of them to swap places with you :)
heberth [heberth!~heberth@190.97.216.164] has joined #qi-hardware
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #qi-hardware
qwebirc93098 [qwebirc93098!4766dbba@gateway/web/freenode/ip.71.102.219.186] has joined #qi-hardware
<rjeffries> whitequark Jean Claude Whippler of JeeLabs does a lot of home automation stuff, all very open. AVRs are ok/fine for the individual sensor nodes, need something beefier for central coordinator. He alswo recently worked through a design to steal a small amount of energy form 230V mains. is not selling due to liability.
<rjeffries> He uses the HopeRF RFM12B radio. cheap, and it works. I think that's also the device ?? mirko ?? uses for his project
jekhor [jekhor!~jek@leased-line-46-53-195-130.telecom.by] has joined #qi-hardware
DocScrutinizer [DocScrutinizer!~halley@openmoko/engineers/joerg] has joined #qi-hardware
B_Lizzard [B_Lizzard!~havoc@athedsl-428276.home.otenet.gr] has joined #qi-hardware
Ayla [Ayla!~paul@254.135.123.78.rev.sfr.net] has joined #qi-hardware
antoniodariush [antoniodariush!~antonio@host-92-2-65-80.as43234.net] has joined #qi-hardware
B_Lizzard [B_Lizzard!~havoc@athedsl-428276.home.otenet.gr] has joined #qi-hardware
antoniodariush [antoniodariush!~antonio@host-92-2-65-80.as43234.net] has joined #qi-hardware
blackrose1231 [blackrose1231!~blackrose@2401:8000:0:1::2ef] has joined #qi-hardware
kudkudyak [kudkudyak!~sun@94.72.140.37] has joined #qi-hardware
<qi-bot> [commit] Maarten ter Huurne: MIPS: A320: Fine-tune PWM backlight settings. (jz-3.2) http://qi-hw.com/p/qi-kernel/0bc374e
<qi-bot> [commit] Paul Cercueil: MIPS: JZ4740: enable the OpenDingux logo only when targetting the Dingoo. (jz-3.2) http://qi-hw.com/p/qi-kernel/2688101
<qi-bot> [commit] Paul Cercueil: MIPS: A320: Updated defconfig to match Kconfig changes. (jz-3.2) http://qi-hw.com/p/qi-kernel/9c420ed
<qi-bot> [commit] Paul Cercueil: MIPS: A320: defconfig: Tweak scheduling options to get better performance. (jz-3.2) http://qi-hw.com/p/qi-kernel/d9e5b2b
blackrose1231 [blackrose1231!~blackrose@27.225.223.72] has joined #qi-hardware
<qi-bot> [commit] Paul Cercueil: OpenDingux: initrd: added 'splashkill' program. (jz-3.2) http://qi-hw.com/p/qi-kernel/c9b9fe0
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #qi-hardware
<wpwrak> wolfspra1l: hmm, this could be an interesting product for qi-hw. should have a nice margin when produced in china. (page in german) http://www.bpes.de/de/boxentransformer.html
jluis [jluis!~jluis@2001:5c0:1400:a::515] has joined #qi-hardware
wolfspraul [wolfspraul!~wolfsprau@p5B0AA963.dip.t-dialin.net] has joined #qi-hardware
<whitequark> lol
<wolfspraul> wpwrak: thanks for the link! the text sounds a little esoteric at first read, but I'll read again
<wolfspraul> I am in no way worried about finding product opportunities
<wpwrak> (esoteric) i think it's highly concentrated snake oil :)
<wolfspraul> and I also don't think there will be anything specific about any country in the manufacturing process
<wolfspraul> no second read needed?
<wpwrak> but you can't beat the margin on a few pieces of what looks like plastic sold for EUR 2100 :)
<wpwrak> 2nd read only for entertainment value
<wolfspraul> oh that doesn't surprise me. I can't put a percentage figure but A LOT of businesses only survive because at some underlying point, they have these kinds of margins
<wolfspraul> my gut feeling says 50% of businesses at least :-)
<wpwrak> you can also look at their product catalog. they also have some energy varnish for violins and such :)
<wolfspraul> ok then no 2nd read, I thought it's something serious
<wolfspraul> there's a lot of innovation in speakers indeed, that's why I even read it in the first place
<wolfspraul> because I have come across a lot of initially exotic sounding speaker stuff lately
<wpwrak> ah ! sorry :) speakers sounded like just credible enough at first to make it more funny
jluis [jluis!~jluis@2001:5c0:1400:a::515] has joined #qi-hardware
rejon [rejon!~rejon@li382-141.members.linode.com] has joined #qi-hardware
<wolfspraul> maybe I become to open-minded towards 'creative' people nowadays
<wolfspraul> about margins, I went through a number of computer/electronics retailers in Germany in recent weeks, and wow, they are changing a lot
<wpwrak> yeah, though these show more the kind of creativity that gets you executed in china ;-)
<wolfspraul> all I see are piles of very high-margin accessories
<wpwrak> interesting
<wolfspraul> it's like people are stuck with their computers, and try to keep them alive
<wpwrak> all the rest is mail order ?
<wolfspraul> so they sell all these crufty little things, extensions, expansions, cables, etc.
<wolfspraul> the computers are also there, but they are clearly loss leaders
<wolfspraul> the store makes money with accessories, when people come back because something doesn't work :-)
<wpwrak> yeah, cables have traditionally had interesting pricing
<wpwrak> did you have any luck pimping M1 to shops ? (if you got to doing that ... you were once talking about it)
mstevens [mstevens!~mstevens@fsf/member/pdpc.active.mstevens] has joined #qi-hardware
<wpwrak> they shuold like it better now that is has midi. more accessories to sell ;-))
<wpwrak> (accessories) maybe we could offer a special usb-midi cable :)
<wpwrak> (i.e., USB A for the M1, USB mini B for the MIDI device. perhaps USD 50. after all, it is something a little exclusive that's hard to find elsewhere)
<whitequark> ... wait what
* whitequark had to read it three times before he finally understood
<wpwrak> important properties could include: 1) low transmission delay (< 10 ns); 2) ultra-low delay variation; 3) electromagnetic shielding
<whitequark> 4) asbestos-free
<wpwrak> oh right, GREEN !! :)
<whitequark> you need to add nanotechnologies somewhere
<wpwrak> maybe it could come in a sealed bag, sterilized
<wolfspraul> no pitching yet, for that I have to travel around to visit music/dj shops
<whitequark> everything is better (from the "get money from govt" point of view) with some nanotechnologies
<wpwrak> wolfspraul: train network down ? :)
<DocScrutinizer> EEEW
* DocScrutinizer puts on his frozen-air activated rock-crystal goggles before continuing to read http://www.bpes.de/de/boxentransformer.html on his evil LCD screen
<wolfspraul> for the archive records: that link is a hoax
<wpwrak> i still kinda like the usb-midi cable idea, though. you could probably make good money with this. and you wouldn't even have to lie :)
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wpwrak> as in "tell a lie". lies of omission are a different topic
<wolfspraul> what cable? size-A to mini-B is the most common type
<wolfspraul> faderfox comes with a cable, I forgot whether one was included in the icreativ
<wolfspraul> I will focus on the product, accessories are a distraction now.
<wpwrak> iCreativ comes with A to mini-B. so does the nanoKONTROL2 (and probably a ton of midi for iGadget devices)
<wolfspraul> first step is to finish the remote kbd idea, that's really nice
<wolfspraul> and why would that not work with the M1?
<wolfspraul> the connector on M1 is the same as the most common connector on notebooks
<wolfspraul> mini-b into icreativ, the other size into m1
<wpwrak> no no ... i'm not saying that any random usb cable wouldn't work. that would be a lie. but one could still offer a usb-midi cable, no ?
<wpwrak> like you can get some fancy ethernet cables for audio
<wpwrak> of course, that would be preying on the technically weak, who may be led to think (once you tell them that such a product exists) that you actually NEED a special usb-midi cable for usb-midi.
<wpwrak> or maybe they're just not sure and prefer to err on the safe side.
<wolfspraul> it won't sell
<wolfspraul> I think you underestimate the amount of work needed to actually sell such cables
<wolfspraul> let's make a strong core product first, then accessories
<wolfspraul> and btw, the #1 best accessory for the Ben NanoNote already exists - jane's pouches
<roh> wpwrak: do you know of a cable which has usb-midi on one end (host) and midi on the other?
<roh> to use usb-midi devices with stuff that likes real midi
<wolfspraul> we've only found the other way round
<roh> hehe... i know the other way round exists ;)
<wolfspraul> to connect old-style MIDI devices to a notebook, that exists for 5 USD or so
<wolfspraul> we have not found what you mean
<roh> i was just thinking if i could trigger wpwrak into hacking mode to brew something up *ducks*
<wpwrak> you can use a pc ;-)
<roh> wouldnt that be a job for your 8051?
<wpwrak> with a pc, it works great. plug in all the usb-midi you want, add a usb-to-midi dongle, connect them all together with qjackctl
<wpwrak> (my 8051) it doesn't do usb host :)
<wolfspraul> about the led mails... it was so much that I was overwhelmed in replying
<wpwrak> ;-))
<wolfspraul> I think all is good now - design verified
<wolfspraul> when Adam is back we can proceed to actual schematic entry?
<wolfspraul> the only question was the size of grid?
<wolfspraul> I have no overview over free pins and routing
<wolfspraul> otherwise you can just pick what you like
<wolfspraul> if we do well, I can imagine other uses for the led array later
<wpwrak> yeah. the only things missing are 1) see if there is led vs. ir interference. but i'm sufficiently unworried about that that i think i'll postpone such testing until a day i feel really totally and utterly bored :)
<wolfspraul> yes
<wolfspraul> not needed
<wolfspraul> worst case that led has to stay off, so what
<wpwrak> 2) pick a location of the leds in the matrix. i'd leave that to adam / the layout guys.
<wolfspraul> :-)
<wolfspraul> yes
<wpwrak> 3) size of matrix, yes. that can simply be use 3+3 pins, reserve one more
<wolfspraul> let's have one asking size
<wolfspraul> otherwise we just spread uncertainty to more people
<wpwrak> 4) picking pins would also be adam / layout guys. we can adapt to anything they pick within ~30 minutes, 25 of which are the xilinx tools doing their thing
<wolfspraul> that asking size can come with a note *) can be smaller if needed
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wpwrak> for the size, i'd go with 3 x 4. it's not an excessive number of pins and it allows for up to 24 leds. depending on how you populate the matrix, only a 2x4 or 3x3 area of it would be used, i.e., one pin could be unconnected
<wpwrak> (there would be no physical matrix anyway. just an equivalent topology)
<wpwrak> 5) decide on the exact layout rules for the leds. such as leaving an area for translucency, distance from connector edge, distance from board edge, any exceptions to the rules, etc.
<wpwrak> (ir led) yes, that worst case gives me great comfort :)
<wolfspraul> don't make 5) too complicated
<wolfspraul> but yes, sure. I saw your drawing :-)
<wpwrak> it's one more thing for adam to decide :)
<wolfspraul> ok, so 3*4 is the preferred one
<wolfspraul> great, seems led is exhaustively covered
<wolfspraul> if we are fiddling with layout, a wish I want to add is to move the memcard or jtag-serial so that the memcard can be fully opened
<wolfspraul> just move it a bit, no big change
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wolfspraul> also the jtag-serial has one corner cut out slightly, I am wondering whether that is still needed (there was a 2nd batch of jtag-serial board with minor improvements)
<wpwrak> 3*4 also happens to be the maximum size we can support with 6 mA per LED :) anything larger would get a bit more demanding (well, a little. we could go to vast quantities of LEDs without working up a sweat, if we really must :)
<wolfspraul> if it's still there, that's another thing we can fix
<wpwrak> yeah, saw the corner. very cute ;-)
<wpwrak> why is this an issue ?
<wolfspraul> finally the jtag-serial coult be 1mm or so further away from the acrylic, that would make inserting the cable a tad easier
<wolfspraul> not an issue, just a small annoyance
<wpwrak> i would make a hole in the acrylic and make both the cable and its insertion even easier ;-))
<wolfspraul> that's another idea
<wpwrak> "live hinge" anyone ? :)
<wolfspraul> so I just want to move jtag-serial and memcard a little (1-2mm) to solve those 3 issues
<wolfspraul> memcard open, 1mm more clearance to wall, no need for cut corner
<wolfspraul> sure we can make bigger changes, but that's a separate idea then
<wolfspraul> I like having the jtag-serial separate now, it's good
<wpwrak> again, why is the cut corner an issue ? once you know you need it, it should be trivial to have
<wolfspraul> even though for the foreseeable future all boards will have it inside by default
<wolfspraul> it's a detail that needs to be remembered, and really just a leftover from lack of mechanical overview early on
<wpwrak> if you want new jtag boards you make backward-compatible, you need to keep the corner anyway
<wolfspraul> it may actually already be fixed in the 2nd-gen jtag-serial, I don't know
<wolfspraul> no need because all m1 have one already and I have plenty in stock
<wolfspraul> I just want to cleanup the board a little, that's al
<wolfspraul> I'm talking about 1-2mm moves
<wpwrak> my M1r4 has an "RC2" jtab board. that has (and needs) the corner
<wolfspraul> if it's easy, layout should just do it
<wolfspraul> we already have two versions of jtag boards
<wolfspraul> and plenty in stock
<wolfspraul> the point is to cleanup the files going forward
<wolfspraul> has to start at some point...
<wolfspraul> same for memcard blockage
<wpwrak> this looks alike a case of fighting yesterday's battles :)
<wolfspraul> if those little things won't get done, no big deal either
<wpwrak> the memcard i get
<wpwrak> the jtag has already sailed
<wpwrak> if you move it and anyone makes cards that don't have the corner cut out, they won't work in rc2/rc3 boards
<wolfspraul> I would move the headers on m1 a little so that the board doesn't need the cut corner
<wolfspraul> doesn't matter, since all rc2/rc3 boards have jtag-serial already
<wpwrak> if you keep on cutting out the corner forever anyway, why bother moving ? :)
<wolfspraul> that's what I want to cleanup, the cut corner need
<wolfspraul> gee, small detail :-)
<wpwrak> the jtag board could need replacing due to loss, defect (real or imagined)
<wolfspraul> it should take layout less time to move this by 1mm than our discussion here :-)
<wolfspraul> I have plenty in stock
<wolfspraul> and I don't even plan another run without cutting the corner
<wpwrak> you're trying to solve a problem you've already solved :)
<wolfspraul> but I want to move the headers by 1mm :-)
<wolfspraul> so you don't make the same argument when we are at R5
<wolfspraul> if routing says it's easy, i will ask them to move
<wolfspraul> also memcard opening
<wolfspraul> and also 1mm extra clearance towards wall
<wolfspraul> a bigger thing would be whether to move the memcard to the side
<wolfspraul> I was worried you bring that up :-)
<wolfspraul> but I think we should not do that now
<wpwrak> well, probably no harm in it. just totally pointless :)
<wolfspraul> not in R4
<wpwrak> kinda like the endless renames in kicad ;-))
<wolfspraul> you agree about the memcard?
<wolfspraul> that's highest value of those 3
<wolfspraul> second is 1mm extra clearance to wall
<wpwrak> the memcard is a disaster. i don't think you can make it worse ;-)
<wolfspraul> third is remove need to cut corner
<wolfspraul> I think we agree actually, on everything. *if* they are moving the jtag-serial headers already, they can also consider that corner thing.
<wpwrak> so any change to the memcard is good :)
<wolfspraul> because you bet that was not intentional...
<wolfspraul> it has very small practical value now, only cleanup
<wolfspraul> but that most minor thing is what we discuss about
<wolfspraul> if routing says it's difficult in that area, or the power stuff is too close, or whatever, then I wouldn't touch any of this
<wolfspraul> I think the entire current situation is not bad, including memcard
<wolfspraul> I see the memcard as some sort of internal storage
<wolfspraul> and I ship all products with 2gb formatted and installed there
<wpwrak> while changes to jtag don't seem to do more than change for the sake of changing. kinda like when you go to the supermarket and find your favourite butter with a slightly different logo and somewhere in the corner they printed "NEW LOGO !"
<wpwrak> (i'm not kidding. i actually saw something like this. though it wasn't butter)
<wolfspraul> the corner cut was not intentional
<wolfspraul> just believe me
<wolfspraul> anyway this is indeed the most minor of those 3 small mechanical annoyances
<wpwrak> oh, i get that :) just, now that it's there and done, it has no further cost
<wpwrak> the pcb-cutting cnc machine won't mind that little turn :)
<wolfspraul> and you have no problem discussing whitespace in sources...
<wolfspraul> :-)
<whitequark> wpwrak: how do you think, how long will it take to make M1 Rlast? and how long will it be until it will be obsolete?
<wpwrak> Rlast ?
<wpwrak> ah, final :)
<wolfspraul> don't understand your question
<whitequark> R1, R2, ..., R5, Release.
<whitequark> yeah, final revision
<wolfspraul> the more it sells, the more revisions
<whitequark> ah, so that M1 revision isn't like release candidate. my bad.
<wolfspraul> even after a Milkymist Two or some other product that replaces M1 comes out, there may still be new M1 revisions
<wpwrak> it's like cars. you make a new model every year. you stop the line only when it stops selling.
<wolfspraul> whitequark: yes, but you noticed an important detail :-)
<wolfspraul> the 'candidate' was indeed confusing
<wolfspraul> we realized that recently
<wolfspraul> so we stopped saying RC1, RC2, RC3
<wolfspraul> and instead now it's just revision, or R4
<wpwrak> have we actually announced the name change on the list ? i'd still consider that our "official" channel
<whitequark> I'd personally suggest V4, or V1.4
<whitequark> like router vendors do
<whitequark> that's way less confusing
<wolfspraul> well, we've just settled on R4
<wolfspraul> but maybe V5 in honor of whitequark ? :-)
<wolfspraul> then W6 in honor of Werner
<wolfspraul> how about that?
<wpwrak> it was M1rc3 (confusing). wolfgang suggested M1r4, which is better. i think i kinda like the idea of a M1.4. been thinking about that for a while, too.
<wpwrak> each time i type "M1r4", it feels a little wrong
<wolfspraul> oh god, version number discussion
<wolfspraul> I am relaxed about this
<wolfspraul> if it makes werner happy, I am also ok with M1.4
<wolfspraul> the main thing on the sales side is product literature, manual etc.
<whitequark> yeah, M1.4 is fine too
<wolfspraul> and they all talk about 'milkymist one' only anyway
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wolfspraul> the rest is 'internal' (open for Qi of course), so we can communicate about improvements
<wolfspraul> so as long as the numbers make sense, including the old ones, I don't care which words or characters there are
<wolfspraul> meaning that... M1R4 can also be M1.4
<wpwrak> we have another thing, just "Milkymist". that would be the whole category. e.g., i could imagine an M2 with a >= 7" panel
<wolfspraul> that's another discussion
<wolfspraul> the Milkymist brand is confusing, overloaded a bit
<wpwrak> :)
<wolfspraul> but I wouldn't change that right now, the brand needs more visibility first
<wolfspraul> so I tend to say Milkymist SoC or Milkymist One
<wolfspraul> or sometimes I just say Milkymist when talking to new people, since I mainly want to catch their attention
<wolfspraul> wpwrak: btw, about the 1.4 thing
<wolfspraul> the current silkscreen says Milkymist One RC3 <datecode>
<wpwrak> datecodes are great to have
<wolfspraul> oh definitely
<wolfspraul> so you suggest Milkymist One M1.4 <datecode> ?
<wolfspraul> you want to repeat the "M1"?
<wpwrak> hmm, dunno
<whitequark> "Milkymist One V1.4 <datecode>" ?
<wolfspraul> with R4 the flow is better Milkymist One R4 <datecode>
<whitequark> or V4
<wolfspraul> since we are deep in opinion land, I think V is geeky and cheap
<wpwrak> yes, for the long form, R4 looks nicer
<wolfspraul> I believe if it's R, the product will take off! :-)
<whitequark> heh
<wolfspraul> there's a story why the founder of Roland chose that name
<wolfspraul> one reason supposedly was that there were very few/no other companies starting with 'R', and that would give Roland a very visible spot in alphabetical listings at tradeshows and exhibitions
<wolfspraul> that's the legend...
<wolfspraul> :-)
<wpwrak> (roland) before, they called themselves "Eyjafjallaj
<wpwrak> heh :)
<wolfspraul> I continue with "R4" unless some other active contributor insists on something else
<wolfspraul> I never type M1R4 anyway
<wpwrak> there's also the eternal battle for having the most "A" at the beginning of the name
<wolfspraul> because the context is clear
<wolfspraul> yeah but that's cheap
<wpwrak> very :)
<wolfspraul> but I can see the point of being the only one under 'R'
<wolfspraul> if the story is true
<wolfspraul> so about R4 - leds are settled
<wolfspraul> exhaustively
<wpwrak> ;-)
<wolfspraul> wpwrak: infinite thanks, really!
<wolfspraul> I hope this turns into a multi-billion dollar LED spinoff, one day
<whitequark> er, what?
<wpwrak> (M1R4) you should type M1r4 anyway ;-)
<whitequark> can I see the history of led thing?
<wolfspraul> it's mostly in #milkymist and the milkymist devel list
<wpwrak> whitequark: are you on the #milkymist list ?
<whitequark> wpwrak: nope
<wpwrak> bah
<wolfspraul> just have a bit here today so the Qi crowd doesn't feel excluded
<wpwrak> milkymist list, without #
<wolfspraul> most likely there would have been more feedback on the Qi list...
<wolfspraul> so leds are settled
<wolfspraul> mostly
<wolfspraul> I will add my wish item of moving the jtag-serial header slightly to address the issues above - if easy
<wpwrak> whitequark: for some visual impressions and random stuff: http://downloads.qi-hardware.com/people/werner/m1/leds/
<wolfspraul> then we have the expansion system
<wpwrak> whitequark: to make sense of it, you'll have to read the list, though :)
<wpwrak> (qi crowd excluded) boosting the traffic for the monthly statistics ? :)
<wolfspraul> nah
<wpwrak> yup. still needs more specs. but ... the part adam needs should be pretty much covered
<wolfspraul> quality stuff will find its way
<wolfspraul> you mean the leds?
<wpwrak> the expansion header
<wpwrak> or header(s)
<wolfspraul> oh, we settled on the pins for the second header?
<wpwrak> i'm fine with the pins adam uses
<wpwrak> there are two clock pins too (i think), so in case we need any of these, we'll have them
<wpwrak> nobody mentioned any other special pin features to take into account, so maybe there are none we should care about
<wpwrak> the ones we do take into account are: voltage (all 3.3 V), differential pairs, and having > 1 clock pins
<wpwrak> (up from 0 clock pins in M1rc3 :)
<wpwrak> what i'm not so happy about is that J21 is upside down. but that's too late to fix.
<wpwrak> and we should probably keep J22 like this too, for consistency
<wpwrak> better consistently bad than inconsistent :)
<wolfspraul> upside down?
<wolfspraul> >1 you mean >=2 ?
<wolfspraul> people don't mention special pins because almost nobody is using the header now
<wolfspraul> chicken & egg problem, like so many on m1
<wolfspraul> but I agree, the above looks right
<wolfspraul> we do factor in what we've learnt from kpaul and others - clock & differential pairs
<wolfspraul> and if more people learn more things, we will factor them in in the future...
<wolfspraul> ha ha, I like how you reply to the html mail in this ugly way
<wolfspraul> span span span span
<wolfspraul> div div div
<wolfspraul> yes
<wolfspraul> span span
<wolfspraul> div div div
<wolfspraul> :-)
<wolfspraul> (the "yes" was my actual message)
<wolfspraul> knowing you I'm pretty sure you did this on purpose :-)
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wpwrak> (special pins) well, also people who know that there special pins can mention them. they don't have to actually use them. but since nobody said anything, i suppose it's fine. else, we'll eventually find out ;-)
<wolfspraul> yes, fully agree
<wolfspraul> speed
<wolfspraul> R4 looks like a huge step up from R3
<wpwrak> (html mail) obviously ;-)
<wpwrak> (j21 upside down) in the schematics, it's shown with ground at the bottom, which is a common configuration (of the connector i mean, not just of the presentation)
<wpwrak> in the board, you notice that the ground pins are towards the center of the main pcb. if you work on such a board, you'll probably consider the edge of the M1 as your "bottom". thus, the connector will appear reversed.
<wolfspraul> hmm
<wolfspraul> ok
<wolfspraul> why not rotate the header?
<wpwrak> we can ease the pain by rotating it in the schematics or in the supporting documentation
<wolfspraul> or on the board
<wpwrak> if you rotate now, it'll be incompatible with rc2/rc3
<wolfspraul> show the layout folks some respect
<wolfspraul> wouldn't it just be upside down?
<wolfspraul> and plus, we are going from male to female anyway
<wolfspraul> without having found an easy-to-point-to adapter cable or piece yet
<wpwrak> well, ledm would still fit, even if rotated. not as elegantly, but yes. so 100% of my existing boards would be compatible ;-)
<wpwrak> (adapter) just take a header
jluis_ [jluis_!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wpwrak> the typical header has ~5 mm mating pin on the top and ~2.5 mm pin for soldering at the bottom. those 2.5 mm are just enough to mate with a female socket. it won't be great mechanically, but you get a contact
<wpwrak> of course, this gives you a bit of a stack
<wolfspraul> but if you rotate your board, it would fit even on rc2/3, no?
<wolfspraul> I think we can go for reversal of the physical header, no problem
<wpwrak> ledm can be rotated, yes. it'll sit on the dvi connector, but that's okay. there's nothing on the bottom
<wolfspraul> ok, so let's rotate the header?
<wpwrak> of course, future boards may be more difficult
<wpwrak> if we do it, it's now or never :)
<wolfspraul> not really because we already know that most <R4 boards are in the hands of developers or people that are very strong technically
<wolfspraul> and I have no problem at all offering ugprade options to the few that are not, if this should ever become an issue
Textmode [Textmode!~boneidle@adsl-syd-2-209.ozonline.com.au] has joined #qi-hardware
<wolfspraul> I think any argument for not rotating the header is quite hypothetical
<wolfspraul> with so many changes we are making already
<wpwrak> (future boards) i was thinking of making some experimental board and being able to try it out on an rc3. as the rc3 ages, it also becomes attractive for more risky experiments ;-)
<wolfspraul> sure but that is still possible, even with rotation, no?
<wolfspraul> if that makes you feel uneasy or slow down, then let's not rotate
<wpwrak> let's float the idea on #milkymist or the list ?
<wolfspraul> you can but there will be 0 responses
<wpwrak> (possible) yes, but you may have to design specifically for rc3
<wolfspraul> we can also leave the header unrotated
<wolfspraul> I can see arguments either way
<wolfspraul> but as you said, no more changes after R4
<wolfspraul> otherwise we really completely screw up any expansion idea
<wpwrak> yeah :)
<wolfspraul> so maybe no rotate?
<wolfspraul> your pick
<wolfspraul> you are *by far* the one who gave the expansion system the most thought and practical usage
<wolfspraul> and yes, if we leave J21 the way it is now, then j22 should be the same and we update schematics and documentation
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wpwrak> no rotating on the pcb is the safer choice. sometimes, cowardice is the better part of valor ;-) but we can still float it on the list
<wpwrak> it's also more democratic ;-)
<wolfspraul> sure, fine by me. do I understand this right: if list is silent we leave as-is, and update documentation?
<wpwrak> ok :)
valhalla [valhalla!~valhalla@81-174-22-194.dynamic.ngi.it] has joined #qi-hardware
emeb [emeb!~ericb@ip72-223-81-94.ph.ph.cox.net] has joined #qi-hardware
<wolfspraul> cool, so that was all for R4?
<wpwrak> how about connecting 5V on J21 via a header ?
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wpwrak> with jumper
<wpwrak> i.e., a cheap "switch"
<wolfspraul> don't understand. you mean a switch between 3.3V and 5V?
<wpwrak> no, 3V3 would always be there. but we'd get the ability to disable 5V.
<wolfspraul> some pins are 5V? wait, checking
<wolfspraul> ah yes, 1 and 2
<wolfspraul> I have no idea. You hear people saying they want 5V, others are saying they want lower voltages, even below 3.3V
<wolfspraul> the default is to leave the jumper open?
<wolfspraul> so 5V only after closing the jumper?
<wpwrak> yes
<DocScrutinizer> moo wolfspraul wpwrak
<wpwrak> i'm writing a mail with the rationale ...
<wolfspraul> hi there :-)
<wpwrak> gotta boost the list traffic stats ;-)
<wpwrak> hmm, what's the sound bats make ? chirp ? :)
<DocScrutinizer> what you're messing up right here? ;-D
<DocScrutinizer> wpwrak: depends on converter, here they ROAR
<wpwrak> (messing) keeping 5V away from the FPGA's 3.3V domain :)
<DocScrutinizer> sounds like a good idea :-D
<wpwrak> (roar) naw, our bats are small
<wolfspraul> you mean if someone shorts 1 and 3, the fpga and board are toast?
<wpwrak> that could happen, too
<wpwrak> or bring 5V to one of the I/O pins
<wolfspraul> how about bringing out lower voltages like 1.8, 1.2 ?
<wpwrak> not sure what happens if you short the 5V and 3V3 rails. maybe that's actually survivable because everything is then at a higher level
<wolfspraul> :-)
<wolfspraul> I somehow doubt that, but ok
<DocScrutinizer> not for long
<wpwrak> i wouldn't bother with that
<wolfspraul> well I have nothing against a jumper (default off) to disable 5V
<wolfspraul> of course it's more work
<wpwrak> perhaps we can have some use for the rc2 wolfgang is replacing with newer boards ;-)
<DocScrutinizer> if you're concerned, you usually use crowbar circuits
<DocScrutinizer> and fuses
<wpwrak> DocScrutinizer: are you on the milkymist mailing list ?
<wolfspraul> what's the proposed pin structure for J22 ?
<wolfspraul> another 2 gnd, 2 3V3, 2 5V ?
<DocScrutinizer> nope, and I'm happy with it
<wpwrak> (j22) 2 x GND, 2 x 3V3, the rest i/o
<DocScrutinizer> I got just a few lists with several 1000 unread mails already
<wpwrak> ;)
<wolfspraul> Qi is far bigger than Milkymist and has a more diverse set of people on the list
<wpwrak> well, you know the schematics. the issue in question is the to of the expansion header J21 (page 3)
<DocScrutinizer> linkie to schem pdf pls
<wpwrak> there we have the 5 V rail, right next to it the 3.3 V rail, and then a lot of 3.3 V FPGA I/Os
<DocScrutinizer> meh maybe I got it somewhare under my 587 bookmarks already ;-)
* DocScrutinizer missing a search in bookmarks, heard FF got sth like that
<wpwrak> yeah, bookmarks are not all that useful :)
<DocScrutinizer> J21 has no 5V?
<wpwrak> i have a little HTML page i keep on editing. would actually be easy to turn this into a smarter bookmark page.
<wpwrak> pins 1 and 2
<DocScrutinizer> ooh it has
<DocScrutinizer> prety please consider changing VDD symbols from upside-down GND symbol to a circle symbol!
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
* DocScrutinizer notices the "GND" symbols are actually PE symbols there
<wpwrak> wrong tree ;-)
<wpwrak> the plan is to migrate the schematics to kicad anyway. soon. like next week.
<wpwrak> on that occasion, a number of perversions can die :)
<DocScrutinizer> I'd happily help killing them :-D
<wolfspraul> next week?
<wpwrak> excellent. we have our first volunteer ! :)
<wpwrak> too soon ? basically once adam has processed the backlog
<DocScrutinizer> I just siign the execution orders though :-)
<wolfspraul> oh sure
<wpwrak> you;ll make a fine military governor ;-)
<DocScrutinizer> :-P
<wpwrak> but yes, perhaps next week is to ambitious. there is a bit of a pile awaiting him already :)
<DocScrutinizer> I already got upset about illegible GTA04 schematics, and about goldelico not even offering a way I might edit this mess
<DocScrutinizer> they got no GND symbols at all, rather wire up GND like any other trace
<wpwrak> excellent ! ;-)
<DocScrutinizer> confuses the living hell out of me
<wpwrak> learn from the rookiest of rookies ;-)
<wolfspraul> DocScrutinizer: you want to help with the kicad schematics?
<wolfspraul> I'll pray 5 times a day towards any direction of the sky you are telling me to :-)
<DocScrutinizer> wolfspraul: I'd maybe take some fun in doing so, alas I am afraid kicad is no fun to work with, esp on a laptop with ~300MB free space (actually less than the 5% reserved for root-only)
<wolfspraul> my installed size is 102 MB
<DocScrutinizer> new laptop is on my ToBuy list for next week
<wpwrak> kicad isn't commercial bloatware ;-)
<DocScrutinizer> (J21) so what's wrong with it?
<DocScrutinizer> for sure my choice to place the GND, 5V, 3V3 would have been slightly different
<wpwrak> the risk of accidently bringing those 5V somewhere they shouldn't go
<wpwrak> e.g., short to the neighbouring 3V3. or to any of the 3.3 V I/Os
valhalla [valhalla!~valhalla@81-174-22-229.dynamic.ngi.it] has joined #qi-hardware
<DocScrutinizer> the latter seems unlikely to happen, the first I'd tackle by placing GND *between* 5V and 3V3
<wpwrak> it's not just shorts by metal objects, but could be traces on the board
<wpwrak> this is for experimental boards. so they can have errors. or they could also simply be mis-inserted.
<DocScrutinizer> shorts on traces caused by faulty PCB can never be handled in any sane way by design
<wpwrak> correct. that's why i'm suggesting to keep 5 V away if we don't need it
<DocScrutinizer> for mis-inserting plugs, you usually cut one pin and plug one "hole"
<wpwrak> i'm not worried about shorting anything there to GND or to 3V3. that's survivable, often indefinitely.
<wpwrak> that assumes you use proper connectors :)
<DocScrutinizer> also a common best practice is to place GND pins so the plug's short between all the GND contacts would short VDD to GND when plug inserted wrong way round (180° rotated)
<wpwrak> for DIY/prototypes, improvisation is quite likely, so i wouldn't count on people to have the "right" connectors
<DocScrutinizer> for that you can't count on anything, so as well just forget about the whole issue
<DocScrutinizer> apart from separating 5V from 3V3 by one positions so shorting the pins by metal opbjects gets unlikely
<wpwrak> yes, short-on-rotation is good. seems to be a bit tricky here, though. or not ?
<DocScrutinizer> 5V, GND, 3V3, IO [...]
<DocScrutinizer> (tricky) not that much if you'd use 4 GND and only one for 5V and for 3V3if
<DocScrutinizer> er, where from is that trailing "if"?
<DocScrutinizer> o.O
<whitequark> DocScrutinizer: sorry what? why is it a best practice to short VDD to GND?
<DocScrutinizer> read context
<wpwrak> we'd rather not reassign pins. since that would break compatibility with rc2 and rc3 boards already in the field
<DocScrutinizer> :nod:
<wpwrak> whitequark: if you short the rails, the short-circuit protection of the regulator will kick in and you just power down
<DocScrutinizer> get a crowbar on 3V3
<wpwrak> how to do this without reassigning pins ? :)
<whitequark> wpwrak: ah ok, that's how it should work theoretically then
<wpwrak> whitequark: got some cases where it didn't ? ;-)
<DocScrutinizer> so same short-circuit shutdown would kick in when shorting 5V to 3V3
<whitequark> olimex did it with their jtag. plug the connector wrong way and their LDO explodes
<whitequark> almost literally
<DocScrutinizer> wpwrak: electronic crowbar circuit on 3V3 rail
<DocScrutinizer> OVP
<wpwrak> designed according to military standards, including the self-destruct :)
<wpwrak> (crowbar) but that still wouldn't help with 5V reaching the I/Os
<wpwrak> don't you like the simplicity of being able to just disable 5V with a jumper ?
<DocScrutinizer> wpwrak: it might, when IO got proper clamp diodes to 3V3
<wpwrak> it's the clamp diodes i'm worried about :)
<wpwrak> tiny little clamp diodes
<DocScrutinizer> yeah sure
<DocScrutinizer> they should survive a surge to charge up 3V3 buffer C to the point where crowbar kicks in and ters down both 3V3 *and* 5V *directly*
<DocScrutinizer> tears*
<wpwrak> sounds like a major redesign of the power supply circuit
<DocScrutinizer> nope
<DocScrutinizer> just add a synced crowbar circuit on both 5V and 3V3 rail
<wpwrak> crowbar .... "No records match your search criteria" says digi-key :-(
<DocScrutinizer> meh
<DocScrutinizer> no crowbar chips out there
<DocScrutinizer> thyristor, Zener, R
<DocScrutinizer> actually
<DocScrutinizer> thyristor, Zener, 2 R, C
urandom__ [urandom__!~user@p548A5A42.dip.t-dialin.net] has joined #qi-hardware
<wpwrak> hmm, the 2nd circuit looks scary. the 1st isn't so bad. but i notice that it works with 12 V. that may explain some of the simplicity.
<DocScrutinizer> you'd need some sync as well to trigger 5V crowbar when 3V3 engages
<wpwrak> phew. does sound major.
<DocScrutinizer> c'mon
<DocScrutinizer> good EE isn't for free on BOM
<wpwrak> i'm more worried about EE-time :)
<wpwrak> and design risk
<DocScrutinizer> better get some positions in BOM for *that* rather than for useless inductors etc
<wpwrak> but for an imperfect solution, a jumper on 5 V doesn't sound so bad, does it ?
<DocScrutinizer> design risk?
<wpwrak> yeah, these inductors where evil ;-)
<wpwrak> risk of a fuckup. wouldn't be the first :)
<DocScrutinizer> you can remove the whole circuit without any impact on normal operation, so what's the "risk"?
<wpwrak> rework :)
<DocScrutinizer> just make whole block "NC" and risk killed ;-P
<whitequark> wpwrak: what's with those inductors?
<wpwrak> naw, while i think the whole power supply circuit needs some overhaul, r4 may not be a good moment for it
<wpwrak> we don't want to delay that thing forever. and opinions on the importance of the expansion header are already divided
<wpwrak> so making this the source for another week of discussion and experiment wouldn't be popular
<DocScrutinizer> a "meh" for me. You asked me, I give a proposal. Up to you to deal with orga crap
<wpwrak> hence my proposal for a jumper :)
<DocScrutinizer> jumper for sure can't hurt
<wpwrak> OVP crowbar idea duly noted :) that's a good item to have on the requirements for the future proper power supply circuit. ideally already as part of the chip. but we'll see.
<wpwrak> whitequark: some ground planes are connected with inductors. e.g., the audio section with the main part of the circuit.
<wpwrak> or, rather, were :)
<wpwrak> now these inductors have yielded to a significant amount of tin
<wpwrak> kewl, already two votes for the jumper ;)
<whitequark> wpwrak: hm. I heard some guidelines recommend that. What was wrong with them?
<wpwrak> DocScrutinizer: and you agree that 5 V reaching the 3.3 V rail or the I/O pins in the 3.3 V domain is generally bad news. i.e., it's not just some theoretical risk i'm imagining
<wpwrak> whitequark: i'm glad you asked :-) connect audio equipment. a little voltage surge goes through ground (they're at different "floating" potentials). the inductor won't let the surge through. so it goes through the audio codec in one way or another.
<whitequark> sounds like fubar
<wpwrak> whitequark: audio codec hates that and crashes. luckily, it takes no permanent damage. system clock happens to be provided by audio codec. thus whole systems hangs. VJ is not happy ;-)
<whitequark> >no permanent damage
<whitequark> I guess it depends on the surge energy...
<wpwrak> yeah, i was lucky :)
<wpwrak> i would have kinda hated to burn my brand new M1 already on the first day
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<DocScrutinizer> wpwrak: yes, I agree on 5V is a bad thing on 3V3 domain, and should never happen
<wpwrak> kewl, thanks !
<DocScrutinizer> and risk to get shorts on expansion cables would cause exactly that to happen when 5V are on a connector that has lots of 3V3 stuff is not negligible
<wpwrak> aye
<DocScrutinizer> ideally your 3V3 IO is protected against such incidents, but yes... I know
<whitequark> DocScrutinizer: I heard of a cheap way to do overvoltage protection. Basically, to protect a 3.3V max input you place a 3.3V (or slightly bigger to account for imprecision) zener on it. Zeners always fail short, and when it fails short, your power supply protection kicks in. Afterwards, you replace failed zeners.
<whitequark> Does that work?
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<DocScrutinizer> usually yes
<wolfspraul> so the end result is we do the jumper, and we leave it open by default (but jumper seated there)
<DocScrutinizer> but Zener are no ideal perfect components, so you might see overvoltage nevertheless
<whitequark> DocScrutinizer: thanks
<wpwrak> wolfspraul: perfect
<wolfspraul> yeah well, work work work. but what wouldn't we do for THE FUTURE
<wpwrak> it's probably the easiest of all the changes in r4 ;-))
<wolfspraul> let's see
<wolfspraul> :-)
<DocScrutinizer> the reluctance to do changes on new hw rev basically defeats the whole purpose of getting a new hw rev at all
<DocScrutinizer> this old OM notion of "well, this maybe is a bug, but until now it didn't cause major issues so let's keep it this way it's now, rather than introducing new untested stuff into next hw rev" somehow always bewildered me
<wpwrak> not at all. it's a question of what gets improvements to people as efficiently as possible
<wpwrak> nobody benefits if we have the perfect design but it takes us ten years to finish it
<DocScrutinizer> it's a question of self esteem and professional experience whether you think you could fix a bug, or are incompetent to a degree where your fix would rather make things worse than better
<wpwrak> oh, i'm confident we can do anything :)
<wpwrak> given enough time and money :)
<DocScrutinizer> workload for *implementing* an existing improvement mustn't be a major concern, otherwise you again picked the wrong profession
<wpwrak> see, there is only a finite number of M1rc3. and they're selling. when wolfgang runs out of them, would it be better to sell M1r4 with some improvements or make more M1rc3 without any of them ?
<DocScrutinizer> depends on the workload vs benefit from a new revision, Often it's better to produce some more of the old rev, and get a real improved version later on
<DocScrutinizer> a major fail in procedures at OM
<wpwrak> well, rc3 had a number of nightmarish issues :)
<wpwrak> here, i prefer the "release often" approach over the "it's done when it's done" approach. making hardware is slow enough as it is.
<DocScrutinizer> haha, it only gets much slower by this release often approach
<wpwrak> correct. but you're making progress.
<DocScrutinizer> it's not like software where you simply hit a button to release
<DocScrutinizer> this misconception was another reason why OM hw release policy and procedures been so therribly fsckdup
<wpwrak> also, in case you really mess up, you have a previous version to fall back to that's reasonably close, not something already completely prehistoric
<wpwrak> OM also suffered from the "this is our last chance to do it" syndrome
<DocScrutinizer> which is somehow identical
<wpwrak> if you just accept that there will be, say, two hw revisions per year, you can be a lot more relaxed
<wpwrak> if it doesn't make it this time, you'll only have to wait a few moremonths
<DocScrutinizer> at OM Sean more thought of two *products* per year
<wpwrak> not like several years. or until your next life :)
<wpwrak> let's just say that he had a great many ideas ;-)
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
jekhor [jekhor!~jek@leased-line-46-53-195-130.telecom.by] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<wolfspraul> wow your voting works better than I thought
<wolfspraul> mehr Demokratie wagen :-)
<roh> ?
<DocScrutinizer> there's been any votes lately?
<wpwrak> and unanimously ! ;-)
<wolfspraul> that was about whether we should rotate J21 or not
<wolfspraul> a minor issue and I suggested Werner just decides what he likes better, but Werner wanted to ask the list (where I thought nobody would care)
<wolfspraul> and I was wrong, already 3 answers by now, all favoring to keep the layout as-is and fix the schematics/docs
<wpwrak> in general, the simpler the issue, the more people will offer their opinion :)
* mstevens attempts to reflash a long neglected nanonote
* lindi-_ still struggles with suspend bug :/
<lindi-_> currently it seems that an irq occurs even though it has been masked and __irq_svc does not cope with the unexpected situation and instead loop forever and never returns from the interrupt handler
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<mstevens> ooh you guys improved things so much since last time I flashed
<wolfspraul> mstevens: thanks! :-)
<wolfspraul> and I think we got 10% of what the Ben could do out of it
<wolfspraul> that bugs me, but well, just steady improvement is fine
<wolfspraul> the Ben could be a really great notebook companion, on a day when lugging around the big thing is a bad idea
<mstevens> wolfspraul: there are like actual applications now
<wolfspraul> :-)
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
dvdk [dvdk!~dvdkhlng@g225041073.adsl.alicedsl.de] has joined #qi-hardware
paroneayea [paroneayea!~user@fsf/member/paroneayea] has joined #qi-hardware
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
Ayla [Ayla!~paul@11.241.112.78.rev.sfr.net] has joined #qi-hardware
GNUtoo [GNUtoo!~gnutoo@host29-81-dynamic.48-82-r.retail.telecomitalia.it] has joined #qi-hardware
<GNUtoo> hi kristianpaul
<GNUtoo> did you already heard of MEIF?
<kristianpaul> GNUtoo: hey there
<kristianpaul> nope
<GNUtoo> basically it's a GPS protocol present on some phones
<GNUtoo> the CPU has to compute the fix
<GNUtoo> some people are interested about reversing it
<GNUtoo> like the new main replicant developer
<kristianpaul> is not another network to improve gps accuracy?
<GNUtoo> + another person in #openmoko-cdevel(morphis)
<kristianpaul> oh interesting (reverse)
<kristianpaul> what hardware does it need to work?
<GNUtoo> so we might share work and/or knowledge
<kristianpaul> i mean receiver part
<kristianpaul> but dont you want to implement a gps sofyware receiver from scratch? dont they?
<GNUtoo> I don't know, MEIF is present at least on some phones like some samsung ones or the nexus S(our target)
<kristianpaul> hmm
<kristianpaul> if you have more information about hw part, IF, etc..
<GNUtoo> but the interesting part is that it get the raw data, and compute the fix on the phone's CPU
<kristianpaul> yes this sounds very famiiar to RRLP
<GNUtoo> we don't have something working yet but as soon as we have the init sequence we should share infos/code
<kristianpaul> what about hw?
<kristianpaul> what chip does it use?
<GNUtoo> ah I remember now
<GNUtoo> broadcom something
<kristianpaul> hmm, still hard to guess ;)
<kristianpaul> lets see
<GNUtoo> bcm4751 it seem
<kristianpaul> wich phone have it?
<GNUtoo> there is a datasheet floating on the net
<GNUtoo> some samsung phones
<GNUtoo> like the nexus S
<GNUtoo> or other phones
<GNUtoo> look for MEIF on xda
<kristianpaul> Monolithic..
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<kristianpaul> argh, cant find anythoing
<kristianpaul> first time look at that xda
<GNUtoo> do you know xda?
<GNUtoo> let me look
<kristianpaul> "The GPS software also provides native support for Broadcom's Long Term Orbit (LTO) extended ephemeris service" what on hell is that??
<kristianpaul> why they need extend ehepmeris..
<GNUtoo> no idea
<kristianpaul> oh oh, you're going to replace firmware inside bcm4751 ?
<GNUtoo> it's da_G
<GNUtoo> no
<GNUtoo> we only want to talk to ir right now
<GNUtoo> da_G is the author of the posts if I remember well
<kristianpaul> ah..
<kristianpaul> i was looking a datasheet, seems baseband is just another blackbox
<GNUtoo> yes
<GNUtoo> however it's way better than qualcomm phones (for now)
<kristianpaul> so nah, nothing i could get interesting it, as the idea is to get a libre baseband SoC and firmware
<kristianpaul> sure sure
<GNUtoo> basically we should share the :
<GNUtoo> "how to compute GPS fix on a CPU"
<kristianpaul> that dont sound right to me,
<GNUtoo> ah? why?
<kristianpaul> mom
<GNUtoo> ?
<GNUtoo> not free enough?
<GNUtoo> I lack context in your don't sound right to me
<kristianpaul> wait
<kristianpaul> indeed is RRLP related
<GNUtoo> ok
<GNUtoo> I've downloaded the datasheet if you want
<kristianpaul> wikisend it! thanks
emeb [emeb!~ericb@ip72-223-81-94.ph.ph.cox.net] has joined #qi-hardware
<kristianpaul> so far your project look liks this to me http://gps.psas.pdx.edu/
<GNUtoo> ok
<kristianpaul> i never tought found a "GPS SoC" this days nice !
<kristianpaul> GPS receiver
<GNUtoo> ?
<kristianpaul> you plan get to the arm cortex later correct?
<GNUtoo> no
<GNUtoo> I'll explain
<GNUtoo> replicant is the project which replaces non-free software and libraries on android phones
<kristianpaul> but you meant, calculate fix on tye cpu
<kristianpaul> so..
<GNUtoo> we started with the htcdream and qualcomm devices
<GNUtoo> and we found out that they were very bad for freedom since the modem controlled:
<GNUtoo> *the GPS
<GNUtoo> *the sound card
<GNUtoo> *could read/write in the ram of the main CPU
<GNUtoo> but then we found the nexus S
<GNUtoo> another dev which is now the main dev reversed the modem protocol of it
<GNUtoo> we still need to reverse the GPS protocol
<GNUtoo> which is MEIF
<kristianpaul> MEIF is like NMEA ?
<GNUtoo> not at all
<GNUtoo> MEIF is like raw mesurement of the GPS sent to the main CPU(the arm CPU running android)
<GNUtoo> which is why I talked to you about it
<GNUtoo> the fix and everything must be calculated from the main CPU(running android)
<kristianpaul> sounds good
<GNUtoo> so if you have hints on how to calculate fixes with free software we are very interested
<kristianpaul> yes i DO !
<kristianpaul> well, lindi-_ had some experiences on field too
<kristianpaul> from ublox chips
<GNUtoo> ok
<kristianpaul> that provides navigation data
<GNUtoo> I'd love to have free software GPS running on my freerunner btw
<kristianpaul> but i dont see any hope if you cant hack the arm cortex soc from the broadcon chip
<kristianpaul> wich is that gpl-gps link above is about
<GNUtoo> ok
jluis [jluis!~jluis@2001:5c0:1400:a::313] has joined #qi-hardware
<kristianpaul> GNUtoo: if you have more datasheets perhaps i coould help or point something more accurate to do
<lindi-_> GNUtoo: currently I think it's a major milestone if we can extract raw data from non-free firmware and then recalculate the results from that
<kristianpaul> but resumiing if you can get navigation data from the soc, well is a early first step
<lindi-_> GNUtoo: replacing the non-free firmware on the chip sounds currently too hard
<GNUtoo> indeed
<lindi-_> GNUtoo: got a spec for this MEIF?
<GNUtoo> no
<GNUtoo> that's the problem
<kristianpaul> otherwise, trying to reverse eng closed source protocols like that MEIF is a waste of time i think
<GNUtoo> nokia offered it under NDA but they do not anymore
<lindi-_> kristianpaul: it can't be that complex
<kristianpaul> hack the arm cortex inside the bcm chip !!
<kristianpaul> learn how internals correlator works
<kristianpaul> GPS protocol as you called it not secret, specificaions are public
<GNUtoo> you mean we hack it and reimplement something like NMEA instead?
<lindi-_> nmea is not very nice format
<GNUtoo> I know
<kristianpaul> i said you cant ingnore this bcm chip run a firmware
<GNUtoo> like AT
<kristianpaul> hack that
<lindi-_> ubx is actually quite nice
<GNUtoo> ok
<kristianpaul> no learn how talk the chip, no just that
<lindi-_> compact, simple
<kristianpaul> GNUtoo: or help us port osgps to milkymist soc !
<kristianpaul> we are working on a free gps baseband and receiver here
<GNUtoo> lindi-_, what's the chip in the openmoko?