Jim, I'm reading your e-mail while replying. On Thu, Jun 11, 2020, 4:43 PM jim bell <[email protected]> wrote:
> "I am interesting in participating in designing and building one. It > helps me to set a norm of speaking concisely and to the point, as reading > can be hard for me when working. I am sorry if I have skimmed over > something already said. Have you started any projects?" > > > I've done a substantial amount of electronics in the 1970's and to the > early 1990's, but I haven't done an electronics project since then. Not > that I couldn't pick it up quickly: The major thing I'm missing is > knowledge of the current set of devices available and construction > techniques. > > I designed and built a constant-temperature bath in the ealry 1970's, also > a 4-digit audio frequency counter, also a 4.5 digit digital voltmeter. In > 1977 I built a "Dyna-Micro" microprocessor trainer, from the design in > Radio-Electronics magazine. > I was born in 83 and I believe I built a robot hand by following a design in Radio-Electronics as a child. I was self and family taught, but mostly software. https://en.wikipedia.org/wiki/Single-board_computer > > > http://www.vcfed.org/forum/showthread.php?57918-Dyna-Micro-Single-Board-Computers > > > I added to that with a custom-PC board with 8K by 8 memory, which actually > seemed like a lot of memory at that time! > > Starting in 1978, I designed and built my custom-bus Z-80 microprocessor > computer which at one point had about 600 IC's, mostly wire-wrapped. My > father and I set up the ability to make 2-sided PC boards around 1972, but > since we couldn't plate-through the holes, actually assembling such a board > was a bit tedious. I built two 32K by 8 DRAM cards using Motorola 4k x 1 > 6605 DRAM chips, later replacing them with static RAM. > https://datasheetspdf.com/datasheet/MCM6605A.html In hindsight, I > decided that I should have used one of the 16k x 1 DRAMs that had become > available. > > > In 1980, I invented the solid-state disk, I called it a "SemiDisk", and in > late 1981 I started a company which built them for 10 years, for the S-100 > bus, the TRS-80 Model II, the IBM PC, and the Epson QX-10. The first three > started as 512k byte cards, with software that implemented a virtual disk. > http://www.storagesearch.com/consumer-ssd.html > > > http://www.s100computers.com/Hardware%20Folder/SemiDisk/History/History.htm > > You are very experienced with electronics. > In 1990, I designed and built a device which used 76 IRLEDS to flash, > activating the Opticom traffic control system to turn red traffic lights > into green traffic lights. Had I gone into major production, I would have > used as its motto: "It's the most fun you can have in a moving car !!!". > That sounds awesome. > > HOW I FORESEE THE PERSONAL BLACK BOX: > > I see a central box, about the size and shape of a common smartphone, but > with no user interface. It will include connectors to: > > 1. USB, to a standard, commercial smartphone. > 2. To the camera stack, 4-6 HD cameras. (About 3 gigabytes per hour > per camera.) > 3. To a battery pack. > 4. To a SSD. At 3 gigabytes/camera/hour x 6 cameras, about 18 > gigabytes per hour. So, a 1 terabyte SSD should be sufficient, if its data > transfer rate is enough. > > The central box will probably include 2-3 multi-core microprocessors, and > its main task will be taking the data outputs of the cameras, compressing > them, and sending the result to the SSD. > Sounds reasonable for now. Thinking of making the number of cameras customizable. Any thoughts on supporting a standalone phone app, on the software side? You mentioned a lot of experience making new hardware designs. Are you imagining designing a custom board? I imagine that would open options up a lot but it sounds like a big investment of effort and time for most people. It will probably not be possible to send more than a tiny fraction of this > data directly to the Internet, so I anticipate sending maybe 1 frame/second > for each camera, to be stored remotely. I've read that eventually, 5G > technology will be able to transfer 10 gigabits/second, but I doubt that > this will be kept up in a crowd of thousands of people, many of whom will > be using their own cell phones. > You can also compress it super-low quality when quick motions matter. > The smartphone might also be linked to a nearby confederate (is that word > too anti-PC these days?) by WiFi, whose system might mirror as best as > possible the video material being collected. One goal is to ensure that > complete destruction of the system will not lose all the data collected. > If the location of the event was anticipated, perhaps a remote > data-collection box could be installed, which would act as a safe data > backup. > Any thoughts on a data protocol with wifi peers? https://datproject.org https://gnunet.org . I've also found https://git-annex.branchable.com which uses git of course https://scuttlebutt.nz which is nodejs and json based but has nice data preservation goals, a modified blockchain might work. Haven uses the signal private messenger protocol. A local webserver could do a simple handmade one, I suppose; harder to make many backups. > The actual control of the camera system might be done remotely: The > person wearing the system shouldn't be expected to do anything other than > being a camera platform. > Sounds good for journalists working with a team. This kind of system would probably have an even bigger market to > journalists and news crews. I don't expect it to substitute for > traditional video cameras, but its presence would tend to guarantee that > most information gets collected. It would tend to protect the news crews, > because it would store a record of any attacks on them. > > Jim Bell > Sorry I jumped excitedly on your project like this. I can do some software coding but need to work with others to take something to completion. That difficulty is also why I think of reusing existing work where possible. On Wednesday, June 10, 2020, 12:26:08 AM PDT, Karl <[email protected]> > wrote: > > > It's obvious that people who are oppressed by local authorities need a > personal black box. > > I am interesting in participating in designing and building one. It helps > me to set a norm of speaking concisely and to the point, as reading can be > hard for me when working. I am sorry if I have skimmed over something > already said. > > Have you started any projects? > > I have started https://github.com/xloem/openrealrecord (nodejs, messy) > and https://github.com/xloem/libgame/blob/wip-1/source/stream-up.cpp (c++ > livestreams data to sia skynet with hash identifiers). openrealrecord has > an open bountysource.com bounty of I think a little over $1000 that a > contributor never claimed, left over from back when I had money. > > I also started developing videorecording in guardianproject's haven app > towards this goal https://github.com/guardianproject/haven/pull/418 . > > I'd like to build this in a way that quickly gets it usable by average > people. Once it is easy to use and stable the people who can make the most > use of it can share it among each other and more developers may contribute > exponentially. > > Am I on the same page as you? > > On Mon, Oct 1, 2018, 2:16 AM jim bell <[email protected]> wrote: > > A few weeks ago, I got done binge-watching every episode of NCIS, and am > now up to Season 4 of Criminal Minds. Naturally, this induces a bit of > what I'll call cinematic paranoia. In what seems to be a majority of > episodes, a victim gets attacked, usually ends up dead, and the plucky > investigators are stuck trying to figure out what happened. Naturally, > they usually do, but only after about 45 minutes of high-tension showtime. > It occurs to me that what people may need, for physical security, would be > what might be called a "personal black box", analogous to an airplane > flight recorder. Or, a civilian version of a cop's body-cam. > > Any modern smartphone would have the basics of such a device: A > high-resolution camera, microphone, and a huge amount of storage. And a > quick 911-call if necessary. The mere possession and use of such a device > would probably deter the large majority of potential attackers. And even > if it does not completely protect a given user, it would allow far more > easy identification of the perpetrator. Parts of this, of course, are > not a new idea. > > https://www.sparkfun.com/news/702 > > https://www.theglobeandmail.com/technology/gadgets-and-gear/gadgets/your-own-personal-black-box/article4300839/ > > > https://www.zdnet.com/article/fitbit-activity-data-as-evidence-in-court-wearables-serve-as-personal-black-boxes/ > https://www.medgadget.com/2005/08/cpod_a_personal.html > https://newatlas.com/australia-black-box-flight-recorder-soldiers/51267/ > > > However, storage is not enough: In use, in some instances, an attacker > would presumably be aware enough to take or break the device, so some sort > of continuous or discontinuous upload of the data could be done, to be > available no matter what else happens. Say, a frame per second when > nothing seems to be happening, and a greater rate when triggered somehow. > Could a heart-rate monitor be employed, sensed one axis of the phone's > accelerometers? Or if the wearer falls down? Or if a sufficiently-loud > noise is heard, etc. Or if a trigger-word is spoken a la Siri? > > Can the data transfer be made economical? Even an average of 1 > megabit/second would be over one gigabyte during a 3 hour usage per day. > That's substantially greater than most people currently use. One > possibility is that the phone could upload the data to the cell phone > company, where it could be "parked" for a few seconds or minutes. If > nothing happens to the phone to cause a trigger (some sort of attack) the > phone could instruct the cell phone company to abandon the data. > Conversely, if a trigger occurs, the cell phone company would move 100% of > the data to a backup system for later retrieval. Presumably, the cell > phone company would offer discounted rates for such transfers, and only > offer that service if the local service is sufficiently unloaded at that > moment. > > Jim Bell > > >
