[sudo-discuss] shotspotter will be discontinued
Gregg Horton
greggahorton at gmail.com
Sat Mar 15 00:00:20 PDT 2014
jake stop being boring, lets at least use the microphones to spy on the
mayor
On Fri, Mar 14, 2014 at 11:56 PM, Gabrielle Silverman <
gabbywingnut at gmail.com> 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> 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 listsudo-discuss at lists.sudoroom.orghttps://lists.sudoroom.org/listinfo/sudo-discuss
>>
>>
>>
>> _______________________________________________
>> sudo-discuss mailing list
>> 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
>
>
--
Gregg Horton
greggawatt.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sudoroom.org/pipermail/sudo-discuss/attachments/20140315/ed2f19d1/attachment.html>
More information about the sudo-discuss
mailing list