[sudo-discuss] shotspotter will be discontinued

Sat Mar 15 02:05:21 PDT 2014

-----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 at att.net 
> <mailto:g2g-public01 at 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 at spaz.org 
>> <mailto:jake at 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 at 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 at 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 at 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 at lists.sudoroom.org
>> <mailto:sudo-discuss at lists.sudoroom.org> 
>> https://lists.sudoroom.org/listinfo/sudo-discuss
> 
> 
> _______________________________________________ sudo-discuss
> mailing list sudo-discuss at lists.sudoroom.org
> <mailto:sudo-discuss at lists.sudoroom.org> 
> https://lists.sudoroom.org/listinfo/sudo-discuss
> 
> 
> 
> _______________________________________________ sudo-discuss
> mailing list sudo-discuss at 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-----