DocScrutinizer05 changed the topic of #neo900 to: http://neo900.org | conversations are logged to http://infobot.rikers.org/%23neo900/ and http://irclog.whitequark.org/neo900 | 2013-11-04 - the day our fundraiser reached its goal | 2014-05-01 360 devices 75k€| 0712 183 ~30k | 0810 300 ~49k | 0914 346 ~56k
norly has joined #neo900
norly has quit [Quit: Leaving.]
ReqGame has joined #neo900
SylvieLorxu has quit [Quit: ZNC - http://znc.in]
* jonwil is not looking forward to all the work that is necessary for the cellular daemon on the Neo900
<DocScrutinizer05> yeah, we need to tackle that beast as low level as possible
<DocScrutinizer05> I.E provide replacements for all the com.nokia.csd.* and com.nokia.phone.* dbus daemons
<jonwil> yeah thats what I mean, figuring out all those dbus interfaces is going to be a nightmare
Nix\ has joined #neo900
<DocScrutinizer05> com.nokia.phone.SSC is prolly for supplementary service codes (aka starhash)
<jonwil> no, com.nokia.csd.ss is for that
<DocScrutinizer05> ooh
<jonwil> com.nokia.phone.ssc is for the system syncronization controller
<jonwil> which handles modem state
<DocScrutinizer05> ta :-)
<jonwil> Pitty so many of these dbus calls translate directly into undocumented modem isi calls :(
<jonwil> com.nokia.phone.sim.get_service_provider_info for example
<DocScrutinizer05> undocumented? duh!
<jonwil> Actually thanks to www.wirelessmodemapi.com and files I have that came from there, not everything is undocumented :)
<jonwil> it just happens that the modem SIM server is one of the things I dont have documentation for :(
nox- has quit [Quit: Leaving]
<DocScrutinizer05> hmmm
jonwil has quit [Ping timeout: 250 seconds]
jonwil has joined #neo900
<jonwil> If I thought it was even remotely possible I would try and dig inside the cellular modem firmware itself. But I don't have a clue how to disassemble such firmware...
<DocScrutinizer05> well, yeah, it's for sure not linux
<jonwil> Dont even know what CPU it is
<DocScrutinizer05> ARM
<jonwil> how do you know its ARM?
Oxyd76 has joined #neo900
<DocScrutinizer05> http://privatepaste.com/cc388cf8e8 sucks (dbus-send ... com.nokia.phone.sim.get_service_provider_info )
<DocScrutinizer05> (ARM) this http://www.forum.gsmrapid.com/showthread.php?t=4957 every now and then has better picture
<jonwil> All I see on that thread is a broken imageshack image and nothing else
<DocScrutinizer05> yes, that's why I said "every now and then has better picture"
<jonwil> ok
<DocScrutinizer05> I guess it's not the brightest idea to embed imageshack pictures into vBulleting and similar forums
<DocScrutinizer05> you generally are better off attaching the original picture file to your forum post
<DocScrutinizer05> iirc that guy also elaborated somewhare about him being a TI employee who helped Nokia to build the rapuyama
<DocScrutinizer05> somewhere
<jonwil> Thankfully we at least have SOME information on the workings of the CSD dbus stuff.
<jonwil> libcsnet-dev (in the repos somewhere and likely a mistake) has documentation for com.nokia.phone.net.*
<jonwil> and the documentation folder for csd-gprs (which isn't normally accessible due to docpurge) contains full documentation of com.nokia.csd.gprs.*
<jonwil> not to mention things like qtsysteminfo and bluez that have bits and pieces
<DocScrutinizer05> http://www.prnewswire.com/news-releases/global-and-china-mobile-phone-baseband-industry-report-2010-now-available-reportsnreports-112795209.html >>TI's RAPUYAMA has replaced RAPIDOYAWE jointly developed by Nokia and FREESCALE. New smart phones of Nokia without exception employ RAPUYAMA as basebands<<
<DocScrutinizer05> so it's prolly safe to assume it's even OMAP-alike
<jonwil> knowing stuff about baseband doesn't help, I doubt its possible to reverse engineer the RTOS its using
<jonwil> not easily anyway
<DocScrutinizer05> for sure not
<DocScrutinizer05> and prolly also useless, since even when we had complete sourcecode of RAPUYAMA firmware, the semantics of the ISI cals are not necessarily obvious
<DocScrutinizer05> calls*
<jonwil> yep
<DocScrutinizer05> but I guess several PC windows tools of class "Nokia PC suite" know at least some stuff about how to talk sort of ISI
<DocScrutinizer05> I guess phonet and ISI is pretty much the same
<DocScrutinizer05> and it also seems all Nokia phones talk phonet/ISI on their USB link to PC
ReqGame has quit [Remote host closed the connection]
ReqGame has joined #neo900
<jonwil> I can see 4 possible solutions to our modem stack, first is that somehow magically we are able to find older documentation from www.wirelessmodemapi.com somehow, second is that we find someone who worked on this stuff who is willing/able to share information with us (whether that be on the ISI interface or the dbus calls), third is that we somehow magically obtain source/dev/doc packages for...
<jonwil> ...these dbus interfaces and last (and most likely) is that someone with good reverse engineering skills (better than mine most likely) comes up and reverse engineers this stuff.
ReqGame has quit [Remote host closed the connection]
ReqGame has joined #neo900
<DocScrutinizer05> well, all the debus protocol is mostly plaintext whivh helps on guessing what a call is supposed to do. Plus we can watch all the stuff working in a system that is already up and running
<jonwil> it doesn't help with whats going back and forth is numbers
<DocScrutinizer05> in the end it will probably be a synthesis of all the different approaches we have
<jonwil> Look at all the constants in http://www.cncmods.net/files/dbus/net_definitions.h for example, how hard would it be to figure those out...
<DocScrutinizer05> * This file contains all definitions needed by client so that it can use
<DocScrutinizer05> * services offered by Phone.Net.
<DocScrutinizer05> :-)
<DocScrutinizer05> one more such file for csd and we're "almost done" ;-)
<jonwil> nope, thats only for com.nokia.phone.net
<jonwil> we need others for com.nokia.phone.sim, com.nokia.phone.ssc, com.nokia.phone.sms, com.nokia.csd.call and com.nokia.csd.ss
<jonwil> We have documentation only on com.nokia.phone.net and com.nokia.csd.gprs
<jonwil> plus small bits of documentation on the others from various sources
<DocScrutinizer05> sim is prolly rather easy for as much as we care about it for an initial "it works" implementation. call is also not too much and test-able. SSC sounds scary
<jonwil> The hardest one is going to be SIM
<DocScrutinizer05> sms is mostly decoded alrady, afaik
<jonwil> nope, I haven't seen it
<DocScrutinizer05> SIM doesn't really have much in terms of e.g. AT commands that deal with it
<jonwil> in terms of .sim, the ones that look to give trouble would be com.nokia.phone.sim.get_service_provider_info, com.nokia.phone.sim.get_language_prefs, com.nokia.phone.sim.get_sim_status and com.nokia.phone.sim.status (for the last 2 its figuring what the different numbers mean)
<DocScrutinizer05> for the last two I'd start by comparing to AT+CFUN command
<DocScrutinizer05> or maybe not CFUN but the SIM related AT commands
<jonwil> in terms of com.nokia.phone.ssc, the hard ones would be com.nokia.phone.ssc.set_radio and com.nokia.phone.ssc.set_system_ready
<jonwil> the modem state stuff looks fairly sane
<jonwil> its just a string with the state and figuring out all the strings the stock blob can send shouldn't be hard
<DocScrutinizer05> I mean, the AT command set been there first, then somebody implemented the BB5 firmware and most likely adoped same enum for same functions, so the AT interpreter doesn't need to transfor each enum in a lookup-table
<jonwil> worth seeing what pnatd does...
<DocScrutinizer05> yup
<jonwil> also com.nokia.csd.info, forgot about that one
<jonwil> although that doesn't look too hard, we just need to figure out what to make com.nokia.csd.info.GetDSPSWVersion return
<jonwil> com.nokia.csd.call probably wont be too hard, we probably have some documentation for bits of it plus we can figure it out by running some calls and logging what goes on
<jonwil> conference calls might be a pain though
<jonwil> I cant say that com.nokia.csd.ss is going to be easy though, just from looking at it
<jonwil> not with things like com.nokia.csd.ss.CheckCLIR
<jonwil> or com.nokia.csd.SS.USSD.Command
<DocScrutinizer05> I guess nobody but answer to "*#0000#" will be interested in what com.nokia.csd.info.GetDSPSWVersion returns
<jonwil> We do need to implement a number of different commands for getting the IMEI and some others for getting the IMSI though
<DocScrutinizer05> btw mine here seems to be "V3.2010.02-8"
<jonwil> GetDSPSWVersion is only used by maesync it would seem
<DocScrutinizer05> wut?
<DocScrutinizer05> what got the DSP's SW version to do with maesync?
<jonwil> no idea, let me see what it does with it
<jonwil> hmmm, the DBusHandler::getDSPSWVersion function that uses that dbus call doesn't seem to be called. That said, libmaesync is a C++ program so its possible its called but IDA cant pick up the call for some reason
<DocScrutinizer05> it would be needed when you sync two Nokia devices that both use some version of dial-by-voice
<DocScrutinizer05> the voice command recog is prolly done by DSP
<DocScrutinizer05> so the patterns stored to contacts to recog the number to call cannot simply get synced from one device to another one with different DSP SW
<jonwil> Actually looking at what pnatd does, it doesn't appear to be handling AT commands at all, it must be passing them off to somewhere else
<DocScrutinizer05> quite possible. Other BB5 phones also come with AT interpreter, at least I'd guess so
<DocScrutinizer05> you could momotor the phonet device with wireshark ISI dissectors and watch what happens when you talk to pnatd. Should be easy to spot if there are plain text AT commends in payload data
<DocScrutinizer05> monitor*
<DocScrutinizer05> of course you don't need wireshark with ISI dissectors for that, a plain (tc)pdump shall do
<DocScrutinizer05> or tshark
<DocScrutinizer05> rawshark :-o
ReqGame has quit [Remote host closed the connection]
<jonwil> yep, the wirelessmodemapi docs I have feature a file called i_at_modem_fp.pdf which describes AT command handling by modem
<DocScrutinizer05> maybe ask frals? he seems to have had access to some of that stuff, at times. http://foolab.org/node/7888
<DocScrutinizer05> and of course ofono is worth to have a look at
<DocScrutinizer05> since THEY definitely had full Nokia support, for whatever they needed
<jonwil> well yeah I have definatly been using ofono to fill in gaps but it seems like ofono goal was to implement the bare minimum required AND to document it all as little as they could get away with
<jonwil> as for frals, I have no idea how to contact him nor does he seem active anymore.
<DocScrutinizer05> ~seen frals
<infobot> frals is currently on #harmattan (2d 18h 1m 41s) #maemo (2d 18h 1m 41s), last said: 'i just asked for another context and it set it up if it was possible'.
infobot has quit [Remote host closed the connection]
infobot has joined #neo900
<DocScrutinizer05> tnaks purl!
<DocScrutinizer05> thanks purl, even
<infobot> DocScrutinizer05: no problem
ReqGame has joined #neo900
ReqGame has quit [Quit: Leaving]
ReqGame has joined #neo900
ReqGame has quit [Remote host closed the connection]
ReqGame has joined #neo900
ashneo76 has quit [Ping timeout: 244 seconds]
ashneo76 has joined #neo900
Nix\ has left #neo900 ["off"]
ReqGame has quit [Ping timeout: 244 seconds]
ReqGame has joined #neo900
<jonwil> frals: Do you know anything about the N900 cellular modem?
<jonwil> oops, wrong window :P
<jonwil> looks like frals cant help me...
<jonwil> freemangordon: ping
paulk-collins has joined #neo900
ReqGame has quit [Ping timeout: 256 seconds]
Wikiwide has joined #neo900
<Wikiwide> Another use-case: warm (28°C) summer day, a thunderstorm arrives unexpectedly. Would the phone be able to shut down itself before suffering water damage?
<DocScrutinizer05> hardly
<DocScrutinizer05> we would need a battery ejector, or the shutdown won't help to mitigate any water damage
<bencoh> water ?
<bencoh> wouldnt the phone be safer deep in your pocket ?
<Wikiwide> Okay, so theoretically it's battery which should be turning itself into waterproof brick?
<jonwil> The safest place for a phone is in some sort of bag
<Wikiwide> Deep in your shirt pocket? ;-) In such a warm summer people hardly expect hale out of nowhere :-) Ok, so I did have umbrella with me, thanks to weather radar :-)
<Wikiwide> Bag, yes, I have one, and I carry the phone in it (raincoat is better, though, imho). But the fabric gets wet easily when there is rain, wind, ice, and no raincoat (warm summer).
<jonwil> I keep my N900 and other stuff (wallet, keys etc) in one of these http://www.bagworld.com.au/shop/detail/cat-millennial-ronald-utility-bag-black-80002/ and it works great.
<jonwil> That bag and similar previous bags I owned have saved various devices from rain many times
<DocScrutinizer05> makes me realize Neo900 has no hygrometer
<bencoh> Wikiwide: pants ... n900 is way too heavy for shirt pocket :p
<DocScrutinizer05> maybe too large for a woman's pants pocket. When she's wearing pants
<Wikiwide> Water-proofing and such are definitely high on my priority list. Hail, sorry for misprint.
<DocScrutinizer05> and when those have pockets
<Wikiwide> Pants pockets are reserved for bus tickets, only. Anything else will bend-break in them :)
<jonwil> Pants pockets for me are only for my keys on the rare occasion I am going outside without my bag :)
<jonwil> so bored, cant get anywhere with either cellular services daemon work or pulseaudio work.
<jonwil> All the games I want to play I cant play because they are crashing my PC for some reason.
<Wikiwide> Paper tickets are pretty much unbreakable. For their life-span of one week. :-) Raincoat is currently functioning as my hold-all pocket. What about MicroB?
<jonwil> I am stuck on microb work too
<jonwil> since I dont know the first thing about Gecko
<jonwil> well technically I DID do a little playing with it once upon a time
<jonwil> but its changed so much since then...
<Wikiwide> What's the question? I mostly viewed Gecko through lens of extension developer... And it was long ago, too.
<jonwil> The idea was to update the version of Gecko used in microb to something newer.
<jonwil> But even getting started means pulling Gecko source tree (takes ages) and then getting it to compile (takes even longer)
<jonwil> And trust me, compiling Gecko is not a very good way to relieve boredom :)
<bencoh> it's high way to insanity
<Wikiwide> Yes Taking into account their version-speed, it might be better to use ESR versions, but it's matter of taste.
<freemangordon> jonwil: pong
<jonwil> So yeah I am totally stuck on anything pulseaudio related. Have hit a brick wall trying to figure out any of the various data structured involved in -voice.
<jonwil> so I can't really help you with any more PA stuff at this point
<freemangordon> jonwil: hmm, I think I REed most of that big structure, wanna share what I have so far?
Pali has joined #neo900
<freemangordon> jonwil: at least share what you have done so far
<freemangordon> jonwil: BTW what is our biggest problem with Gecko, speed?
<freemangordon> as I was planning to spend some time on the JS engine to see if it can be optimized a bit
arcean has joined #neo900
sparetire_ has quit [Quit: sparetire_]
<jonwil> My biggest problem with Gecko as of right now is that its (for me at least) seriously unstable.
<jonwil> Every time I use microb on any number of websites that are in any way resource-using, gecko can guzzle up so much memory and CPU and display the dreaded "web page not responding" dialog
<jonwil> which then brings down the browser
blueLumocolor has quit [Ping timeout: 245 seconds]
mva has quit [Ping timeout: 272 seconds]
<jonwil> If I open up top when this is happening, it tells me that its browserd at fault
<jonwil> and if I then attach to browserd with gdb to see where its stuck, it ends up in some random place and wont give me any useful info.
<jonwil> as for pulseaudio, this cncmods.net/files/pulseaudio/module-nokia-voice.idb is my latest idb file for -voice
mva has joined #neo900
<jonwil> Thats got basically everything I know about -voice in it
<jonwil> The other reason I wanted to upgrade microb is so it can support more of the latest HTML standards and make sites like www.trello.com work
Wikiwide has quit [Ping timeout: 264 seconds]
<jonwil> But that's much less important than solving the instability
<jonwil> 99% of the sites I want on my phone do work fine when they aren't crashing browserd
<jonwil> well not crashing it, more like causing it to hang
<bencoh> I think it's just "too slow"
blueLumocolor has joined #neo900
<bencoh> and needs more ram than we can provide it
<DocScrutinizer05> exactly. swap hell
NIN101_ has quit []
<DocScrutinizer05> and no surprise gdb shows rubbish when it's trying to trace program text pages that are swapped out
<DocScrutinizer05> also I guess tracing browser is kinda tricky thanks to several threads, but I think that's old dusty news to RE experts ;-)
NIN101 has joined #neo900
<DocScrutinizer05> dang, this must be 7 years since I last used gdb to trace into a frozen program (twinklephone). Completely forgot every single detail on how that works
<jonwil> I dont know anywhere near enough about Gecko to do a thing about this problem.
SylvieLorxu has joined #neo900
<jonwil> but if we can fix it, I will be VERY happy
<bencoh> how does it "hang" btw ? stuck at ~100% cpu, or 0 doing nothing ?
<jonwil> let me see if I can reproduce it and verify
<jonwil> definatly super-high %cpu use and %ram use though
<jonwil> it seems to be the high RAM usage that triggers it
<DocScrutinizer05> swap
<bencoh> yeah, swapswapswap
<bencoh> has anyone tried jemalloc wit browserd ?
<DocScrutinizer05> I think there will always be websites and pages with JS-crap that any decent browser should simply refuse to execute/render
<DocScrutinizer05> I mean it's not reasonable to allow JS-coders to write crap like endless creation of new objects or whatever, and then blame browser-coders that the engine eventually blows chunks on that, when all RAM got used up
<jonwil> I wouldn't exactly call http://forums.whirlpool.net.au/ as being crappily written or full of Javascript yet that is one of the sites that is likely to trigger it
<jonwil> especially when accessing a thread with a lot of pages in it
<DocScrutinizer05> dunno
<DocScrutinizer05> I've seen stuff that rolled up my toe nails
<bencoh> must have hurt
<DocScrutinizer05> oh yes!
<DocScrutinizer05> even tmo downloads whole pages with up to 40 posts which all had quoted original post with 20 huge photos in it, and every browser tries to download and render the full size picture and then zooms it to a tumbnail seen in the tmo thread
<DocScrutinizer05> guess how long it takes to download 20 pictures (assuming local caching works) and then render each of them 40 times
<DocScrutinizer05> and how much memory that tries to allocate
<jonwil> thankfully that forum doesn't even allow embedded pictures
<DocScrutinizer05> other websites crammed with crappy JS do even worse stuff
<DocScrutinizer05> but of coure there also might be new CSS gimmicks that also majke slightly matured rendering engines barf up
<DocScrutinizer05> even most recent FF seems to memleak until it gets closed, on some JS pages that do autorefresh a lot
<jonwil> Autorefresh is also not a problem on this particular forum :)
<DocScrutinizer05> and don't even get me started on exploits/vulns in flash and whatnot
<jonwil> I do run adblock for maemo which at least disables Flash as used in ads
<jonwil> which is where 90% of the nasties come from
<DocScrutinizer05> LOL
<jonwil> LOL what?
<DocScrutinizer05> ~jrtools
<infobot> jrtools is probably http://wiki.maemo.org/User:Joerg_rw/tools
<DocScrutinizer05> >>AdBlock will slow down browser to a grinding halt.<<
<DocScrutinizer05> that's meant literally
<jonwil> ok, will uninstall it then
<jonwil> on my desktop it works great and doesn't slow things down at all
<DocScrutinizer05> yeah, since your desktop has sufficient memory to handle the blacklist db without swapping out other stuff
<SylvieLorxu> There's nothing like Android's AdAway on that platform? (Which simply writes entries to /etc/hosts or whatever it's called to make them not resolve)
<DocScrutinizer05> did I recently tell the story about my CF-27 laptop I used some 6 or 7 years ago, which had some 192MB ram and worked "great" even on openoffice (tool ~60 s to start up) - only YaST packet manager took 12 .. 20 *hours* to handle the dependencies list of all the packages and repos
<jonwil> ok, so is adblock the only thing in the repos I need to worry about re browser slowdowns?
<jonwil> Nothing else I have installed seems to be browser related
<DocScrutinizer05> there's always a magic limit where slowdown boosts exponentially with every other byte more of needed storage. Taht's exactle the moment when a data structure that's in use doesn't fit into RAM anymore
<DocScrutinizer05> prolly for yast PM the _complete_ dependency tree had to gets swapped in and out again for each access to a index on the tree, and for each insert of a new leaf
<jonwil> Hopefully uninstalling adblock will make my browser more stable
<jonwil> and less prone to hangs
<DocScrutinizer05> for browser I could imagine a wallpaper background and lots of elements with transparency in several layers over it will have a similar effect
<DocScrutinizer05> jonwil: (adblock) iirc you don't even need to uninstall it, it's sufficient to drastically reduce size of the blacklist
<jonwil> Does having apps installed (just general apps like e.g. mbarcode that dont run until you start them) make things slower as a rule?
<jonwil> well I already uninstalled it :)
<DocScrutinizer05> no, installed apps that are not started are generally considered harmless as long as they are properly optified
<DocScrutinizer05> truckloads of mimetypes shipped with .desktop could change that a bit, but the general case is a don't-care
<DocScrutinizer05> also a dbus proxy could have impace even when app itself is not started
<DocScrutinizer05> "service"
<DocScrutinizer05> impact*
<DocScrutinizer05> but most apps don't run as dbus service
<DocScrutinizer05> and generally every app has only one associated dbus service, so an overload on services is pretty unlikely
<DocScrutinizer05> one at most
mvaenskae has joined #neo900
<DocScrutinizer51> ~#maemo adblock
<DocScrutinizer51> ~listvalues adblock
<infobot> Factoid search of 'adblock' by value returned no results.
drathir has quit [Ping timeout: 256 seconds]
drathir has joined #neo900
<mvaenskae> no adblock for maemo? did someone lose that package from the repos?
Pali has quit [Remote host closed the connection]
Pali has joined #neo900
che1 has joined #neo900
jonwil has quit [Remote host closed the connection]
mvaenskae has quit [Ping timeout: 264 seconds]
mvaenskae has joined #neo900
Oxyd76 has quit [Ping timeout: 250 seconds]
Oxyd76 has joined #neo900
ravelo has joined #neo900
Kabouik has joined #neo900
louisdk has joined #neo900
Oxyd76 has quit [Ping timeout: 250 seconds]
Oxyd76 has joined #neo900
mva has quit [Ping timeout: 260 seconds]
mva has joined #neo900
mva has quit [Ping timeout: 272 seconds]
mva has joined #neo900
R0b0t1 has joined #neo900
<R0b0t1> need phone nao
<enyc> heh
blueLumocolor has quit [Ping timeout: 252 seconds]
blueLumocolor has joined #neo900
ReqGame has joined #neo900
mvaenskae has quit [Ping timeout: 250 seconds]
norly has joined #neo900
nox- has joined #neo900
<Wizzup> R0b0t1: you can preorder/predonate
<bencoh> :]
<enyc> Hrrm (not n900/neo900) but still.. random question: How would you go about finding a genuinely safe 18650 Cell pack charger? seemingly there are loads with poor electrical isolation / overcharge proteciton, exploding chargers etc etc =((( ...
<DocScrutinizer05> for cell packs you need load balancer and a charger that's tailored to fit
<R0b0t1> Wizzup: NEED PHONE NAO
<R0b0t1> Wizzup: though I did miss the preorder link, if there was one - point me towards it?
<R0b0t1> enyc: Each cell should be made with its own charge circuitry, ideally you would just hook up a not-shit power supply and let them do their own thing
<DocScrutinizer05> R0b0t1: it's called "Donate", is a donation to allow us to do the R&D needed and will reduce the price to pay for Neo900 in maybe 9 months
<DocScrutinizer05> 7
<enyc> R0b0t1: i.e. 4.2v or 8.4v PSU, agross 1 or 2 cells' worth of 18650's ?
<DocScrutinizer05> alas cells are not made witht their own charging
<DocScrutinizer05> that's why cell packs generally have more than 2 or 3 contacts
<DocScrutinizer05> enyc: you can charge a single cell with a current limited voltage stabilized 4.20V power supply
<R0b0t1> DocScrutinizer05: If it is not tied to an identity which will receive a phone I am not very interested, unfortunately
<DocScrutinizer05> youu can NOT charge two cells in swries with a 8.40V supply
<enyc> DocScrutinizer05: hrrm because balance needed?
<R0b0t1> DocScrutinizer05: A single battery unit will have its own charging circuitry, any other way is using it improperly
<DocScrutinizer05> R0b0t1: sorry? identity?
<enyc> DocScrutinizer05: well mane of the cheapie headtochers etc etc seem to have just an 8.4v charger block ...
<DocScrutinizer05> enyc: yes, exactly
<R0b0t1> 18650s are made with charging circuity built in... it's under the nipple if it exists at all.
<DocScrutinizer05> that's nonsense! sorry
<R0b0t1> DocScrutinizer05: i.e. a preorder
<R0b0t1> it's not
<R0b0t1> it's okay, you've convinced me I know more than you
<DocScrutinizer05> that circuit is just a protective circuit, if there's any at all
<enyc> R0b0t1: supposedly some 18650's have a overcharge protector or similar ... exactly as DocScrutinizer05 says =)
<R0b0t1> >protective circuit
<R0b0t1> >not a charge monitor
<R0b0t1> no, he was saying they didn't ever come with them, from what I could tell
<R0b0t1> anyway, gone, nice talking to you both
<DocScrutinizer05> a balancer would *bypass* current around a fully charged cell to allow the other weaker cell to continue charging. A protective circuit simply cuts out
<enyc> So... from a practical POV -- can you get, reliably, a reputable charger for 18650 cells or packs, or not ?!?!? i apperiacete you can use a full blown Current limited psu etc. but still asking the question =)
ravelo has quit [Ping timeout: 246 seconds]
<enyc> DocScrutinizer05: nods, make sese nse ,thogh some balancers will just 'discharge' the other cell wasting power but provide similar effect in the end
<DocScrutinizer05> enyc: from a practical POV you can use a 4.20V to charge a single cell. When the pack has contacts per cell then that's OK. When the pack has built-in balancer (usually don't) then you need 4.20V * num_of_series_cells
<DocScrutinizer05> otoh when a pack has multi-cell-series and only 2 contacts, it *must* have built-in balancer
<enyc> nods, theres at least some icrucits in the 4* and 6* cells (8.4v) packs i have
<enyc> but do *safe* *current limited* 8.4v supplies intended for such lithium cells exist ?? I seem to find loads of questionable chargers about ;/ o well
<DocScrutinizer05> no, nothing specialized. I charged a few of the mozilla cells with my lab PSU
<DocScrutinizer05> 4.2V @ 700mA current limit
<enyc> kk indeed i know a lab-psu is an option but intreesting hard to find decent specialized unit
<DocScrutinizer05> there are no general purpuse specialited chargers for multicell LiIon afaik
<DocScrutinizer05> specialized*
<enyc> kk
<DocScrutinizer05> since the packs differ way too much, in their circuitry
<enyc> oh isn't variety fun ;p
<DocScrutinizer05> sure :-/
<enyc> is the same sort of fun underpinning neo900 in general? who nkows =)
<enyc> but if hardware design was easy... =)
<DocScrutinizer05> the fun in Neo900 design is mostly th eper.. err inverted economy of scale principle (of sorts), it's hard to secure components in a quantity that's not generating 6 digit business. And components nowadays tend to vanish after 3 to 4 years of active market life
<enyc> nodsnods
<DocScrutinizer05> often it takes longer for the datasheets to go public than it takes for the component to go EOL
<enyc> which is ridiculious... ?
<enyc> lots of things seem to be just NDA by default all over the lpace with no necesarially aany good reasons?
<DocScrutinizer05> rather extremely annoying
<DocScrutinizer05> the fits-all excuse for NDA mess is patent issues and/or liability to guarantee what's written in datasheets
<enyc> where is component sourceing *still* a problem for the neo900 ? i recal recently got help with sound system fun
<DocScrutinizer05> hm?
<enyc> soryr im being confusing
<enyc> more wondering whats going on of late =)
<enyc> (a) where is component sourceing still an issue for neo900 ?
<DocScrutinizer05> risk components (except the obviously terrible N900 proprietary spare parts situation)?
<enyc> nods, and i souhld probaly jsu be reading te relevant page =)
<enyc> whereveer that is
<DocScrutinizer05> Knowles TINY speakers are a headache
<DocScrutinizer05> 12*8*2.5mm speakers
<enyc> oh i thought hte speakers were separate pcb-contacts to the n900 PCB
<DocScrutinizer05> there's Knowles PETRA but that's 12*8*2mm and only 10mW. It's an earpiece transducer
<DocScrutinizer05> yes, they are
<enyc> so why can't they just be re-used and not part of neo900 board?
<DocScrutinizer05> strictly speaking speakers are part of the N900 mech parts
<DocScrutinizer05> they can get reused
sparetire_ has joined #neo900
<enyc> DocScrutinizer05: oooh you are looking at still ebing able to sell complete units, too, or something ?????
jonwil has joined #neo900
<DocScrutinizer05> sure, of course
<enyc> good luck with that hehe =)
<enyc> do you have any clue on overall ETA given current developments I wonder ?
<enyc> i know how projects always have fun with unexpecteds cropping up!!! experienced all that myself!
<DocScrutinizer05> and we still have no decent values how many of our ~380 customers want a complete device and how many want NeoN board only
<enyc> is that not easily fixed by askin them in an an electronic manner, something akin to doodle-polling everyone ?? or is this disffiult given the way the donation transfers tec etc happened?
<DocScrutinizer05> currently our schedule is slowed down by *) seasons *) other GDC projects (pyra?) *) Studies (dos1)
<DocScrutinizer05> the latter also hinders all efforts of doing proper polling
<enyc> coo i did'n't actualyl know about the pyra
<DocScrutinizer05> I don't know details of GDCs order book and schedule, but stuff was quite slow during last 2 or so months
ReqGame has quit [Ping timeout: 252 seconds]
<DocScrutinizer05> seems we might manage to get decent complete schematics for proto_v2 before xmas though
<enyc> nods =)
<enyc> i suspect you will be bleased to get it all done, given the time its' taken !!
<DocScrutinizer05> fun details at peripherals of our work: https://developer.gemalto.com/threads/phs8-p-atsdport2
<DocScrutinizer05> internally such stuff often creates discussions of the type >> joerg: " we need USB *and* UART attached to modem! Otherwise aiui we might suffer deadlock" Answer: "no, way to complicated. Modem will reset on powercycling" Joerg: "prolly it doesn't" ... etc ... pp <<
<enyc> ;p
<enyc> what is really going on anyway?!?!? etc =)
<Oksana> What about hygrometer in Neo900? :-) Or is it something left to hacker-bus?
<DocScrutinizer05> no hygrometer
<DocScrutinizer05> useless since those need hours to adjust to the real environment, and we couldn't expose such thing to environment in a good way anyway. Similar to thermometer
<DocScrutinizer05> also hygrometers usually are huge
<kerio> we could use the stylus slot :P
<DocScrutinizer05> who wants to know about the microclimate in her pocket?
<kerio> measure the amount of water in it
<kerio> with a special spongy stylus, maybe
<enyc> Apparently there was a time when some sembalnce of which board/device were wanted :-
<DocScrutinizer05> sorry?
<enyc> spongy stylus ?!?!!?
arcean has quit [Quit: Application terminated!]
<Oksana> Here is one interesting tiny humidity sensor: HDC1008 http://www.digikey.com/product-detail/en/HDC1008YPAT/296-38440-6-ND/5015652
<DocScrutinizer05> thanks, this component looks good indeed. Nevertheless placing it in a reasonable way inside the N900 case shell is nearly impossible
<DocScrutinizer05> and it's a quite expensive component, also nasty to handle re soldering and generally manufacturing processes (no wash, no chemicals, etc)
<enyc> hrrm .... r.e. neo900 hackerbus -- *where* would anything on the hackerbus go/fit anyway ??
kolp has joined #neo900
<Oksana> They are greedy. They can sell it for 2.40, but they prefer to get 4.95, if they can. 2.04mmx1.59mm (height?) ; DSBGA, 8 pins: I2C, power supply, ground. Should not be close to heat sources, the LCD and battery.
<DocScrutinizer05> e.g. in/under a mugen cover?
<Oksana> Hmm... Why doesn't digikey or somebody else push the prices down? Profit from the difference between unit prices? http://www.digikey.com/product-detail/en/HDC1008YPAT/296-38440-2-ND/5015650
SylvieLorxu has quit [Quit: ZNC - http://znc.in]
<Oksana> Is there I2C on hackerbus? I see Ground, NFC (for NFC antenna, right?), USB (data and power), GPIO and UART...
<DocScrutinizer05> you can do bitbang I2C via the GPIO, or you can assign I2C bus to (some of) them, by resoldering a few 0R/wire jumpers on PCB
<DocScrutinizer05> all GPIO on HB have a "patch matrix field" on PCB to attach the pins to other signals
mva has quit [Ping timeout: 260 seconds]
mva has joined #neo900
<Oksana> 3mmx3mm, Si7020s may be ordered with a factory-fitted, solder-resistant protective cover: for PCB assembly and rework; can be left in place for the lifetime of the product. http://www.digikey.com/product-detail/en/SI7020-A10-GM1R/336-2539-6-ND/4211733
<DocScrutinizer05> we're not going to add a humidity sensor, due to problems to cut slots or holes into the case
<DocScrutinizer05> also demand is low for such feature
<DocScrutinizer05> iow nobody is interested in air humidity
<Wizzup> well ... interested but not too interested ;-)
<DocScrutinizer05> for me it falls into same category like the lightning detector
<Wizzup> hah
<DocScrutinizer05> Wizzup: would you pay a extra 15 bucks for such feature?
<DocScrutinizer05> (hunidity)
<Wizzup> depends on the total cost :p
<Wizzup> but I don't think it's a good thing to spend time on
<Wizzup> there's always the connectivity if people want to hack their own things, right
<DocScrutinizer05> exactly
mva has quit [Ping timeout: 250 seconds]
mva has joined #neo900
<DocScrutinizer05> on unrelated but good news: GDC will upgrade eagle so whole project team using same version and can share project files among each other
<DocScrutinizer05> \o/
<Wizzup> :)
<DocScrutinizer05> and finally this will also create searchable strings in schematics pdf's
<DocScrutinizer05> \o/ \o\ /o\ /o/ \o/
<DocScrutinizer05> at least I hope so...
<DocScrutinizer05> I dunno why all "old" eagle pdf printouts had those friggin vectorfonts that were barely readable and not searchable
<DocScrutinizer05> I just noticed a funny (though obvious) thing: when you place or remove a locked N900 without battery lid to the table, it unlocks - thanks to battery IR "proximity" detector
<DocScrutinizer05> only works on light / white tables / surfaces
<wpwrak> (fonts) i guess the power of competition (kicad) :)
Pali has quit [Remote host closed the connection]
R0b0t1 has quit [Ping timeout: 265 seconds]
che1 has quit [Ping timeout: 250 seconds]
norly has quit [Remote host closed the connection]
paulk-collins has quit [Ping timeout: 250 seconds]
jake42 has quit [Ping timeout: 240 seconds]
R0b0t1 has joined #neo900
gurki has quit [Ping timeout: 264 seconds]
<DocScrutinizer05> I rather think that's unholy legacy from early eagle versions that didn't support true character fonts but "emulated" that by adding polygon "components" for each char of writing. Since then it seems the default been to stay compatible to that and not use true fonts
<DocScrutinizer05> that's all mere guessing though
<DocScrutinizer05> almost
<DocScrutinizer05> I seem to recall there actually were only vector fonts in ... errr... 2000? when I did the pusteflipper thing with eagle
<DocScrutinizer05> indeed 2000 http://maemo.cloud-7.de/dscf3350.jpg
<bencoh> what's this ?
kolp has quit [Remote host closed the connection]
<DocScrutinizer05> some ancient design of mine
<DocScrutinizer05> around a cheap but easy to handle 8051 alike atmel MCU