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). apparently the city pays $264,000 per year to keep shotspotter going.  I think sudoroom people could do it for much less if they thought it was a useful thing.  They would be discontinuing it to save money, or perhaps to avoid having to send cops to do actual work once in a while... i mean.. sending police toward the gunfire?  sounds like a good idea... http://www.sfgate.com/crime/article/Oakland-cops-aim-to-scrap-gunfire-detec… _______________________________________________ sudo-discuss mailing list sudo-discuss(a)lists.sudoroom.org https://lists.sudoroom.org/listinfo/sudo-discuss

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). > > apparently the city pays $264,000 per year to keep shotspotter > going. I think sudoroom people could do it for much less if they thought > it was a > useful thing. They would be discontinuing it to save money, or > perhaps to avoid having to send cops to do actual work once in a while... > > i mean.. sending police toward the gunfire? sounds like a good > idea... > > http://www.sfgate.com/crime/article/Oakland-cops-aim-to- > scrap-gunfire-detecting-5316060.php > _______________________________________________ > 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 > > > >

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).

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: -- -steve _______________________________________________ sudo-discuss mailing listsudo-discuss@lists.sudoroom.orghttps://lists.sudoroom.org/listinfo/sudo-discuss _______________________________________________ sudo-discuss mailing list sudo-discuss(a)lists.sudoroom.org https://lists.sudoroom.org/listinfo/sudo-discuss

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" &lt;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: _______________________________________________ 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-----

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 &lt;jake(a)spaz.org&gt; 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 &lt;jake(a)spaz.org&gt; 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 &lt;patrikd(a)gmail.com&gt; 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 &lt;jake(a)spaz.org&gt; 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

I have several thoughts. 1. There is a real question about whether a "people's shotspotter" constitutes "snitching". Just as importantly is the question of whether it would be perceived of as snitching or collaborating with the police and what that could mean organizationally and for individuals. I think these are murky dangerous waters. I have seen truly horrible infighting and messy nasty cointelpro type incidents break out over less. 2. I do recognize that guns hurt people and ruin lives. Jake, you asked what my alternative solution is and I would say prevention and recourses pending revolution. Ok? 3- If someone's been shot the priority should be an ambulence. 4- Certainly making information open and public and never feeding directly to cops is less controversial, but there is no getting around the reality that a shotspotter system (alerting to gunshots, fireworks, random street noise, maybe loud parties?- Am i totally crazy here?) would be used almost exclusively by the police. 5- If you have never been on the receiving end of violence, harassment, or curruption at the hands of OPD, there's a good chance you are a white person or that you can pass as middle class. 6- I hope my comments are understood as coming from a place of respect and concern. 7- I don't want to tell other people what to do and what to build. I think its a bad idea but I hope that if this does move forward in some form that the people who are working on it are doing so consciously and thoughtfully, recognizing that it's going to be controversial. Gabby On Mar 15, 2014 7:18 PM, "Jake" &lt;jake(a)spaz.org&gt; wrote: > 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 &lt;jake(a)spaz.org&gt; 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 &lt;jake(a)spaz.org&gt; 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&gt; 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&gt; 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 > >