Gabby, no one has suggested calling the police on anyone. I am proposing
that we build a shotspotter system that locates the source of gunfire in
the city, and makes that information available to EVERYONE. If the police
want to use that information to go fuck with people who are SHOOTING GUNS
IN THE CITY then i think that's fine.
Does that make it okay? Or would you prefer that the information was
somehow made available to everyone except the police? Because we wouldn't
want the mean nasty OPD going after nice friendly people shooting guns?
You still haven't answerd my question, what do you suggest people do about
people shooting guns in the city? Do you think it's okay? Will you at
least acknowledge that guns kill people and ruin lives?
-jake
On Fri, 14 Mar 2014, Gabrielle Silverman wrote:
I don't want to spout rhetoric or stifle conversation. I feel like there's good
intention but I do feel obliged to raise this point:
When you call the police you are not sending helpful helpers who are out to catch the bad
guys and keep Oakland warm and fuzzy and safe. OPD is completely fucked up.
I can see the shitstorm churning on the horizon. I extremely encourage Sudo Room not to
collaborate with the police.
Gabby
On Mar 14, 2014 6:49 PM, "GtwoG PublicOhOne" <g2g-public01(a)att.net>
wrote:
Anything that can pick up a gunshot will also pick up false positives such as:
fireworks going off, automobiles backfiring, loud motorcycles starting, and sometimes,
basketballs bounced hard on the street and baseballs hit with bats. That's why
audio recording & monitoring is useful during possible gunshot events.
If all the event-datapoints are logged to a public map that anyone can click to
examine the data more closely, the risk of abuse of any audio or video transmission
or recording function is minimal, because any abuse or non-essential use of
audio/video will be found and exposed quickly.
With appropriate safeguards, audio & video will help catch shooters.
Safeguards would include a rolling record/erase that stores a maximum of e.g. 15 minutes
of
recording, centered on the event. With this you can see e.g. the car drive up
before the passenger shoots the pedestrian, or the souped-up motorcycle start up with
loud pops and a roar. The same actions that trigger saving a recording for
evidence, would also put information to that effect on the datapoint on the map.
The contract terms with the city (which should also be public) should specify usage
for evidence of violent crimes only, and that any abuse of the recording
capability (such as to pull over that motorcycle driver for a loud exhaust system)
would trigger a large financial penalty. If the city gov is serious about
stopping crime rather than e.g. catching loud motorcycles and illegal fireworks,
the city should have no trouble signing a contract with those terms & conditions.
-G.
=====
On 14-03-14-Fri 5:46 PM, Steve Berl wrote:
It is a DSP problem that should already be solved. I suspect google can turn up a
lot of info. I suspect It can likely be implemented on a little Linux board
computer like a RaspberryPI or similar. Add the cost of a microphone, GPS, and mesh
networking HW.
Steve
On Friday, March 14, 2014, Jake <jake(a)spaz.org> wrote:
I'm glad somebody knows about this! however i would suggest that it's not
quite as simple to decide "when the big impulse of sound starts" without
waiting for it to end and then choosing a peak event.
the best i know how to do is a peak detector where you wait for the slope of the
amplitude to head downward after a threshold is achieved, but i think we
can do better, and i think we would need to if we were going to achieve good
results. and the more versatile the analysis is better, to reduce false
alarms (!) and increase detection of events at lower amplitudes.
On Fri, 14 Mar 2014, Steve Berl wrote:
You don't need to record and transmit the audio at all. You just need the
time of when the big impulse of sound starts, which you can do
locally. Just transmit the
time stamp.
NTP has a lot of the logic built in to discipline a computer clock to a few
microseconds of UTC time. It works best attached directly to a
serial port.
Steve
On Friday, March 14, 2014, Jake <jake(a)spaz.org> wrote:
I think it would be a positive move. When you hear a gunshot outside
you want to believe it's far away, somebody else's problem.
when you can look at a website and see where the gunshots have been
over time, you can figure out if it is your neighborhood, and
decide to talk with your
neighbors about it. Maybe everybody knows who it is and nobody knows
what to do about it. You can have subtle, problem-solving
conversations with people
that the police obviously are not capable of.
as for the timing data, i think GPS clock is necessary to remain
synchronized with all the other nodes (plus it serves as a handy
location resolver) but
i'm not sure yet what is the right way to stamp the audio data. My
best guess would be to put the timestamp into the audio stream as a
second audio
channel, so that the central processing computer can sort it all out
and pinpoint the source.
I do think this would be a good opportunity to grow the mesh network
but i don't know if the mesh group would be excited to do it this
way.
-jake
On Sat, 15 Mar 2014, Hol Gaskill wrote:
setting up a system like this would have a powerful effect on the
public safety narrative - if the public is able to
self-organize a better
solution at a low cost and
share the data directly with everyone, it makes alot less sense
for public officials to propose alternatives wherein our freedoms
are demanded
in exchange for
whatever degree of security is theoretically offered. who's
saying it has to be the police that respond? if the data is made
public people
could show up and
videotape or whatever, or reconsider going to that area within
the next hour, generally use that info however they see fit.
i think using gps clock signal or a realtime clock IC such as a
ds1307 we could get pretty good time data. a condenser mic doing
amplitude
and spectral (audio range)
analysis would be enough to check for gunshots, maybe car
crashes, sirens, etc, without storing or transmitting the actual audio.
could this
be a potential optional
addon module to the mesh nodes?
on Mar 14, 2014, Patrik D'haeseleer <patrikd(a)gmail.com>
wrote:
Very interesting! That $264,000/yr fee does seem outrageous
- once the system is installed, there should be relatively
little
maintenance to keep it
running.
I wonder if the company will be disabling or retrieving the
microphones when the contract ends. It's possible the city is only
"leasing" the
equipment. Or that
the company has build in some sort of self-destruct to prevent
cities taking over the network without them...
FWIW, I do think ShotSpotter is a useful technology, but it needs
to be designed with some ethical issues in mind (e.g. not
collecting and
transmitting more
information than is required for its stated purpose). I think
that Sudo Room taking over and overhauling the existing network in
a completely
open-source
fashion would be a great thing to do. That way people could
satisfy themselves that the technology only does what it claims to
do.
Patrik
On Fri, Mar 14, 2014 at 3:23 PM, Jake <jake(a)spaz.org>
wrote:
what do people think of the shotspotter system installed in
oakland?
it's a network of microphones on telephone poles, each
with a GPS (for a precise clock) and a network connection. When a
gunshot-like
sound is
detected, they send the sound and its precise timing to a
central server that determines the location of the shot, and
tells the police
to go there.
some people have expressed concern that the microphones are
used to spy on people, but it would be impossible to hear a
conversation
from the top of
a telephone pole that wasnt already loud enough to be heard
inside nearby houses (or the phone in your pocket).
--
-steve
_______________________________________________
sudo-discuss mailing list
sudo-discuss(a)lists.sudoroom.org
https://lists.sudoroom.org/listinfo/sudo-discuss
_______________________________________________
sudo-discuss mailing list
sudo-discuss(a)lists.sudoroom.org
https://lists.sudoroom.org/listinfo/sudo-discuss