[sudo-discuss] shotspotter will be discontinued
Jake
jake at spaz.org
Sat Mar 15 19:18:27 PDT 2014
i never suggested video cameras.
and the city would never sign a contract like that.
i think providing the sound itself along with the location data is the
best way to differentiate the sounds. but there are too many objections
to that for privacy reasons, and i don't think it could be workable
without the recording.
maybe gunshots aren't as big a problem as i thought.
On Fri, 14 Mar 2014, GtwoG PublicOhOne 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> 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
> https://lists.sudoroom.org/listinfo/sudo-discuss
>
>
>
>
More information about the sudo-discuss
mailing list