<Joerg-Neo900>
aah, plus the magnet in display slide
<ds2>
doesn't have to be a motor... can also be a piezo, etc
<Joerg-Neo900>
hm?
<Joerg-Neo900>
the vibra motor we have is a motor with permanent magnets I think. And odds are those are on rotor
<ds2>
*nod*
<ds2>
just saying heptics is a whole family of things use to generate physical feedback
<Joerg-Neo900>
the magnets in display slide and in kickstand move. however one is normally in default position (kickstand) and the other has only two positions and a sysfs node to ask which is the current one (display slide open)
<Joerg-Neo900>
but yeah, N900 never been optimized for compass and hardly anything we could do about it
<ds2>
*nod* there been android phones where charging traces were ran under the mag... very bad results
<Joerg-Neo900>
hehe yeah
<Joerg-Neo900>
we should keep such high current tracks layer-paired
<Joerg-Neo900>
and away from the compass
<ds2>
anyways - I did a pass through it and don't see anything else obvious but I didn't look up all the datasheets
<Joerg-Neo900>
very welcome, thanks a lot
<ds2>
btw - was there a reason you guys choose the bosch sensors?
<Joerg-Neo900>
hmm, they looked good
<ds2>
how are they pricewise?
<Joerg-Neo900>
I can't recall we found any comparable other part. But that decision been done by Nikolaus
<ds2>
there are tons of comparables
<ds2>
off hand - MPU9xxx series, the ST 9 axis variations
Oksana has quit [Ping timeout: 252 seconds]
<ds2>
IIRC - the mag is nicer on the ST parts but the AKM mag on the MPU9xxx isn't horrible
<Joerg-Neo900>
function, availability in low quantity, EOL status, price...
<Joerg-Neo900>
and datasheet of course
<ds2>
AFAIK, both of those can be sourced in 1's... donno how they all stack up on price though
<ds2>
data is available for both of those
<ds2>
wonder if it is harder to get those in europe
Oksana has joined #neo900
<Joerg-Neo900>
if you feel like doing an evaluation... swapping a sensor chip for an equovalent part is a nobrainer
<ds2>
was doing that stuff as the day job
<Joerg-Neo900>
though I guess Nik also picked them since they also are in Pyra?
<ds2>
price is one thing I don't have visiblity into
<Joerg-Neo900>
we only have mouser and DK
<ds2>
MPU9xxx should be orderable on Invensense's website
<Joerg-Neo900>
if those don't offer it in low quantity, it's already a huge minus for a part
<ds2>
Donno if the ST parts made it to DK yet
<Joerg-Neo900>
ooh, and of course linux driver availability
<ds2>
non issue... whipped those out in an hour or two
<Joerg-Neo900>
yeah, prolly
<Joerg-Neo900>
I'm no kernel driver devel
<ds2>
had to do that for the day job projects
<ds2>
was just wondering
<Joerg-Neo900>
prolly 90% generic driver framework, 10% max to read the data and provide it via the get() function
<ds2>
8% to read and 2% to figure out the init sequence
<Joerg-Neo900>
IRQ handler
<Joerg-Neo900>
there's prolly a bazillion similar kernel device drivers that would only need very slight patching of a few I2C and register addresses
<Joerg-Neo900>
but then, I would dare to bet on the probability that we find existing drivers for *all* our peripherals
<ds2>
with these parts, there is also a political aspect of it
<Joerg-Neo900>
that's why I suggested to actually prepare a list with status
<ds2>
there are input drivers and there are IIO drivers
<Joerg-Neo900>
o.O political?
<ds2>
current kernel politics is pushing for IIO drivers but input drivers abound
<Joerg-Neo900>
IIO?
<ds2>
Industrial IO
<ds2>
is a new subsystem
<Joerg-Neo900>
never heard of
<ds2>
just got out of staging like a year or two ago
<Joerg-Neo900>
aah ok
<ds2>
there are a ton of input event drivers if you know where to look
<Joerg-Neo900>
what is it?
<ds2>
it is suppose to be a more "efficient" way of dealing with ADCs which is what these chips are really
<Joerg-Neo900>
:nod:
Pali has quit [Read error: Connection reset by peer]
<ds2>
it really doesn't matter unless you are running it really fast (say 1-2KHz sample rates)... for many apps 100-200Hz is more then enough
<Joerg-Neo900>
sure
<Joerg-Neo900>
what's the key difference in concept?
<ds2>
historical - input is was designed for mice, touch screen, and keyboards so each data 'sample' has a tag - for an accel, it would generate soemthing like ABS_X, ABS_Y, and ABS_Z events whereas IIO would say "SAMPLE: X, Y, Z, ..."
<Joerg-Neo900>
sorry, probably too tired to grok it :-)
<Joerg-Neo900>
anyway generally _all_ our sensors have an IRQ option, so no need to poll. Which is mandatory for all embedded
<Joerg-Neo900>
in case of accel sensor etc we have some sophisticated "filter" engines in sensor itself, which need a way to get configured by user
<ds2>
data is so slow, polling isn't much of a problem
<Joerg-Neo900>
and also mayn sensors have internal clock
<ds2>
they do
<Joerg-Neo900>
polling is a HUGE problem . it drains your battery
<Joerg-Neo900>
polling is absilutely forbidden in embedded
<Joerg-Neo900>
everything needs to work even driven, to keep CPU idle as much as possible
<Joerg-Neo900>
event*
<Joerg-Neo900>
that's the fist commandment of embedded, which is widely unknown to the usual sw devel
<Joerg-Neo900>
first*
<Joerg-Neo900>
and to reduce events even further, e.g. accel sensor has filters that only trigger an IRQ e.g. on free-fall or on double-tap or on movements that meet any other arbitrarily complex parameters, depending on complexity of the filter engine
<Joerg-Neo900>
kbd matrix scanner does an IRQ on every key press
<Joerg-Neo900>
touchscreen on any touch event
<Joerg-Neo900>
really *nothing* should get polled
<Joerg-Neo900>
and even if you'd want to sample accel on a 400Hz rate, you'd use the built-in clock and IRQ
<Joerg-Neo900>
so the accel driver probably should provide /dev/accel_400Hz and /dev/accel_100Hz and a /dev/accel for single "poll" like instant data acquisition
<Joerg-Neo900>
or you do that via writes to /dev/accel or via ioctl to configure it
* Joerg-Neo900
can't see how ioctl would be faintly versatile enough to configure the complex filter engines
infobot has quit [Ping timeout: 246 seconds]
<Joerg-Neo900>
o.O
* Joerg-Neo900
waves at infobot
Oksana has quit [Quit: Hello, 911? Yeah, it's caught in the window this time.]
freemangordon has quit [Read error: Connection reset by peer]
<wpwrak>
Joerg-Neo900: our barometric sensor has no interrupt. so neo900 will make a poor (at least not optimally environment-friendly) choice for traditional aircraft bomb triggering.
<wpwrak>
something that's very annoying with the bosch data sheets is that they have no PDF index. and some have a lot of pages (e.g., bmx055 has 172), with important information scattered all over the place.
cybiko123 has joined #neo900
cybiko123 has quit [Client Quit]
cybiko123 has joined #neo900
GuyWhowanttoknow has joined #neo900
GuyWhowanttoknow has quit [Client Quit]
mzki has quit [Ping timeout: 245 seconds]
mzki has joined #neo900
M-DzzzzzzR has quit [Read error: Connection reset by peer]
SylvieLorxu has joined #neo900
M-DzzzzzzR has joined #neo900
chomwitt1 has joined #neo900
chomwitt has quit [Ping timeout: 252 seconds]
jonsger has joined #neo900
Pali has joined #neo900
cybiko123 has quit [Quit: Leaving.]
jonsger has quit [Ping timeout: 260 seconds]
qws-user-1229 has quit [Read error: Connection reset by peer]
drrz has quit [Ping timeout: 248 seconds]
qws-user-1228 has joined #neo900
wpwrak has quit [Read error: Connection reset by peer]
<Joerg-Neo900>
wpwrak: yes, for *very* slow rates (like once every 5 minutes) fixed schedule data acquisition you may replace the IRQ in sensor by a hardware timer IRQ. This applies e.g. for the hygro-baro sensor
<Joerg-Neo900>
one thing's for sure: with this sensor we won't be able to come up with a particularly great (atomic) bomb, meteor, volcano eruption distributed sensor grid app, since it would be too power hungry to run poll of the baro at 30Hz all the time, on all existing/contributing devices
how900 has quit [Quit: Neo900: a Free Communicator for Free People]
how900 has joined #neo900
how900 has quit [Changing host]
how900 has joined #neo900
<atk>
Distributed sensor app?
<atk>
For nuclear bombs?
<Joerg-Neo900>
somebody came up with something similar for android and sensing earthquakes
<Joerg-Neo900>
I think they use accel sensor
<atk>
But unless you lay the phone on the ground or basically not in your pocket, you wouldn't detect anything.
<atk>
is this specifically for phones sacrificed specifically for the purpose of sensing?
<Joerg-Neo900>
and a network aka grid of 100s of k of devices
<Joerg-Neo900>
no idea, I also wondered
<Joerg-Neo900>
maybe only active while phone charging or at least in rest
<atk>
Also, wouldn't it be cheaper to put a accelerometer with some ethernet enabled MCU and plug it into a wall adapter and an ethernet switch
<atk>
There was a similar kind of thing for sensing radiation
<Joerg-Neo900>
anyway for very low frequency audio such a sensor network can do amazing things
<atk>
it was on the EEV blog
<atk>
(some chip with a geiger-muller tube attached with some ethernet interface)
<Joerg-Neo900>
atk: the point of the earthquake app *AIUI* was that it also warns up to 30s before the waves arrive
<atk>
hmm
<Joerg-Neo900>
the barometer sensor is fast and sensible enough so it *could* sense earthquakes(?), for sure meteorites and guge explosions, as well as many volcano eruptions
<Joerg-Neo900>
and _locate_ them
<Joerg-Neo900>
by trilateration
<Joerg-Neo900>
for meteorites even direction and speed of movement
<Joerg-Neo900>
alas I guess *our* sensor and app would leech a maybe 30mA constantly from battery
<Joerg-Neo900>
maybe even more
<Joerg-Neo900>
s/guge/huge/
* Joerg-Neo900
idly muses about a mere scientific experiment to turn *all* phones in a crowd like e.g. in a football stadium into high precision timestamped audio recorders, and then correlate a 1000some of them to focus on one particular point. I *guess* the results would be highly surprising and disturbing
<Joerg-Neo900>
afaik in some american cities they already do something similar - tough with dedicated stationary sensors, to detect and locate gun shots
<Joerg-Neo900>
and of course they did same approach since decades with that US navy undersea hydrophones, to detect all submarine
<Joerg-Neo900>
nah, this is what it looked like a 20 years ago, nowadays the only screen you see there is the one of the smartphone the director uses to control the machinery
<Joerg-Neo900>
;-)
<x29a>
i dont think the movie batman is 20 years old ;)
<Joerg-Neo900>
I didn't say the movie. I thought you were talking about that control room
<Joerg-Neo900>
but sure for a movie a concabe video wall with 10*50 small video screens and 18 keyboards - notably for ONE operator - is better to convey the concept so everybody understands it
<Joerg-Neo900>
concave*
<Joerg-Neo900>
nowadays this wouldn't be 10*50 monitors, but 1000*5000 at very least. Though no human being needs to look at them, there's AI to do that
<Joerg-Neo900>
if anything at all, you get one or two really huge screens
<Joerg-Neo900>
to show the relevant stuff
<atk>
Joerg-Neo900: yes, america has some gunshot sensing system
<Joerg-Neo900>
atk: x29a: if you're interested in distributed sensor network concepts, blitzortung.org is a really nice project
<Joerg-Neo900>
enable "Sensors" for instant obvious explanation how it works
jonsger has joined #neo900
<Joerg-Neo900>
err "Detectors"
<Joerg-Neo900>
"Delay" value is for processing and display, _not_ the trilateration observed delay of reception of signal
<Joerg-Neo900>
which obviously is in the range of speed of light, so ns or µs
<Joerg-Neo900>
also a very nice FOSS example of generic U-TDOA