-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I agree with Gabby.
On 3/14/14, 11:56 PM, 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
<mailto:g2g-public01@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
<mailto:jake@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
<mailto:sudo-discuss@lists.sudoroom.org>
https://lists.sudoroom.org/listinfo/sudo-discuss
_______________________________________________ sudo-discuss
mailing list sudo-discuss(a)lists.sudoroom.org
<mailto:sudo-discuss@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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -
https://gpgtools.org
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iQEcBAEBCgAGBQJTJBfQAAoJEK2jBhiHY3O6QXgIAKC1FFCPH5PAzmLKSOCmwDRp
OjoR+F8GtxTZW6sk6cUD4Wbuimy+faR91ntXybiHAPc4OLNymyKs9aRpET6LFo4q
A2xZIrYhoS4ch19JFlJPlhT8DLpiBL8Kh0TW+JnvVAhkLdQXE9V8mWOUCDz22wI+
DC4psAobrKmQWSnuGWPg8d79dv3d1tIgvlgY86vvBzYYIj4rJKsQDFzJRXT+Ayjb
QmfIUy2i46cvMzK1Pq4UoGuPhTP2lj/w2H8u832O2ok27Emwsk9iQIvnyzWgyP8t
tshfcCSb0RwLCSFW0y2ClgOvCsy1IGv+3xTzuJnhuxa0h3wlix9yiZEp32mpYYY=
=mmWq
-----END PGP SIGNATURE-----