Given the reputation for the cost and provenance of the cameras I'm surprised that Hasselblad passed through QC with that solder spooge at the edge that got into the frame of the film. I mean... it's visible on all the photos. I'm surprised that someone didn't notice that in testing before the camera left and send it back. Hell, even if I bought a cheap camera today and every photo has a little unexposed notch in the edge I'd be pissed. If you told me a camera was going to the moon I'd think I'd want the frame to be flawless....
The table lists F1 cars as having "Carbon fiber brake calipers".
This is glaringly incorrect. All current brake calipers are machined from aluminum, specifically Aluminum-Lithium or Aluminum-Copper alloys. There is a rule denoting bulk elasticity modulus limit on brake calipers of 80 GPa, which was set just at that to allow the more exotic Lithium Aluminum alloys but to dis-allow Titanium alloys or anything else stiffer (There was experimentation with Titanium calipers in the past.)
Absolutely no calipers are made from composites, CF, graphite, or otherwise.
Discs are Carbon-carbon.
So you're telling me that simply walking out to the car and hitting a button inside the car is just too much of an "inconvenient experience"?
You know we used to have to drive the car... sometimes many miles... to a station, get out, and fill it up with a liquid fuel that costs many times more, and then drive home...
Seriously now- The perceived 'inconvenience' you have is the reason that so many of these connected features are being pushed and then the because the ability is there the business types can't resist the data gathering that became possible because of all the antennas, etc.
Yes, because it's entirely possible to do. Hell, the manufacturer even charged a price when you bought the car, or I can pay the $20 for my lifetime share of server usage.
The hierarchy doesn't seem to work. The extremely weak conjecture is the Archimedean property, but I don't see how you prove it from "every number above 7 is the sum of two other numbers". That can be true even if there are only five numbers above 7.
Or in the other direction, if numbers stop at 3, that certainly won't falsify "every number above 7 is the sum of two other numbers". It will prove that it's true. And the extremely strong conjecture immediately proves that the extremely weak one is false.
There is 32MB of SDRAM on the FPGA board.... I wonder exactly what using 1MB of that as the system memory would have entailed instead of the separate 1MB SRAM chip that had to be soldered. Was using the extra SRAM chip just done just to do it, or is there a specific reason there that I'm not seeing/understanding...
The main reason is just due to me knowing my own limitations. SRAM is really simple to interface with and i've not yet tried to write a DRAM controller since its much more complex. Putting SRAM on the board made me more confident about the project. I did have it in mind that I could try to use the DRAM in place of the SRAM at a later stage (as you suggest) as a good way to focus on learning how to use it.
Really cool, I figured that was the case and I'd be in the same boat.
I have an ice40UP5k board but I quickly ran out of block ram and LUTS whenever trying to use it for anything substantial, but seeing this project has me itching to start something around one of these icesugar pro boards. yosys & nextpnr support made things really damn easy when I was working with the ice40.
Ever since 802.11ah devices started appearing I've thought it would be perfect for partnering inside wireless IP cameras... and hell, make them mesh together with something like this so each one configured on your network extends the range of the others in it's area. Streaming 720P H265 is easily doable at the speeds the networks achieve for a few cameras, and the range would be perfect for perimeter monitoring most properties ala farms & industrial parks.
This device however - an entire Raspberry Pi + hat for a router to do..? ... seems like a solution in search of a problem to solve.
A medium range trail/offgrid camera is perfect for this application. All the other solutions in the space are sdcard only, or dependent on some variant of LTE/5G.
So, after seeing how cheap and available these Phomemo printers are and with this CUPS driver looking like a good option, my instinct as someone who also wants one of these sitting permanently on my home network as to appear all the time on all my machines' available printer options, is to get one and tether it permanently to a tiny linux SBC that has bluetooth and running the driver and print sharing. Like the OrangePi Zero 2w I have sitting unused in a drawer somewhere collecting dust.
I was recently thinking about super deep drilling after coming across a very neat mini-documetary [0] self-filmed by a geophysicist around the work at the Kola superdeep borehole [1] in 1992.
It is project I had heard about before but only in bullshit-passing articles and scrolling past brain rot youtube videos (seriously, search 'Kola superdeep borehole' on youtube and take note of how absolutely trash every other thumbnail appears concerning what in reality is just a normal scientific endeavour). So this video by David Smythe of the actual work there was wonderful and also a nice little nostalgic look at science and research as filmed by a VHS camcorder in that era. The computer equipment stuggles, etc...
It left me wondering about new research in this area and surprised I had not heard of any other such projects recently, so this news in interesting.
That didn't sound right to me, and so I checked it as follows:
Estimate for a standard classroom globe at 13" in diameter (I'm seeing a rnage of 12-14 inches as typical). I'm reporting in inches because that is what came up first and most of the globes are for sale in the US. Mixing units here, but, it works out.
But, in meters, the diameter of the Earth is 12,742,000 m on average. if we use the 'Karman line' as defining the edge of what the atmosphere is, that is 100,000 meters. Solving for X ... (13" / 12742000 m)=(X / 100,000 m). gives us an atmosphere thickness of approximately 0.1". -----
Paper glued to the globe would have a thickness of maybe, 0.004" (thin paper) to 0.012" (like a card stock paper).... so that analogy is off by an order of magnitude or more.
Even if you use the mesosphere as the definition for the top of the atmosphere, that is still 85,000 meters and thus similar.
People can check the numbers I used.
* Perhaps the analogy should go more like: the thickness of the cardboard sphere the globe is made out of is about the thickness of the atmosphere. Because, having completely destroyed a globe once in my youth, I remember the cardboard shell being approximately a tenth of an inch thick. But, that's maybe not a great reference for the analogy because not everyone has cut apart a classroom globe....
If I recall correctly... my very first post on Reddit was doing calculations for a (practically immortal) person eating beans and storing the flatus for a trip to the moon (searching shows that this is a not-infrequent request). It was only concerned with quantity - not storage or the engine.
... and the source document for the numbers was based on a paper that is fairly easy to find given the proper keywords in google search... https://pubmed.ncbi.nlm.nih.gov/1648028/ (and I learned that methane more rare in flatus than not).
Did you account for the weight of storage? Because I would think the tyranny of the rocket equation for such a low ISP would cause various levels of impossibility, not to mention the problem of getting enough thrust.
I think the scale was on the hundreds of thousands of years. We're dealing with 700 ml of hydrogen and 70 ml of methane at standard pressures and scaling this up to 90,000 kg of hydrogen and 635,000 kg of kerosene (with the 1:1 methane).
The System on Module board is an Inforce 6601 SOM. [0]
It uses a Qualcomm Snapdragon 820 and they provide prebuilt Ubuntu Linaro distros for it, preconfigured for the board.
The camera manufacturer likely just tossed it straight in as configured and thus didn't know how the full disk encryption was setup.
This whole camera design looks like one of those 'we gave this project to some undergrad engineering students who've never designed a commercial product before and had no price target and thus it has a whole damn embedded linux system inside it for merely taking some HD video and stills triggered by some external wiring and saving them to an SD card'.
See also: almost any specialty medical electronic device ever manufactured.
> This whole camera design looks like one of those 'we gave this project to some undergrad engineering students who've never designed a commercial product before and had no price target and thus it has a whole damn embedded linux system inside it for merely taking some HD video and stills triggered by some external wiring and saving them to an SD card'.
> See also: almost any specialty medical electronic device ever manufactured.
These are not design mistakes.
When building products in short runs and where the costs of part have little impact on your margins compared to R&D, it completely makes sense to go for a full computer rather than bother with embedded development where everything is more complicated. Medical also has to deal with certification which is a much more significant concern than saving on parts and will often reuse already certified components.
I'll admit I only watched a video on it not the report, but it had pictures reportedly redacted at manufacturer request. It showed a teensy 3 and some adafruit qwiic board in there. Obviously the real engineering is in the enclosure. Otherwise it could just be a webcam. But still, it's clearly not a very in depth electrical design. I'm all for SoMs if you can but they don't guarantee you the adventure of custom hardware bringing moving through all the software stacks and whatnot.
Usually (not always), something like a Teensy or a Pi Pico or an Arduino is treated like a development board for prototyping.
A person builds out their circuit using hardware they can solder/wire-up by hand on a workbench, maybe even with relatively-giant solderless breadboards, to prove the concept and the general design.
And a dev board can be great for spinning a few prototypes. It's quick to get started (code can begin being tested on-chip after just plugging in a USB cable), and to try different things and to make (and correct!) mistakes. (Blow up a Teensy? No worries; just grab another from the drawer, try not to make that same mistake again, and keep moving -- no esoteric soldering required)
But when the design is finished-enough and it becomes time to spin up custom-built PCBs for a final product that will be sold, a separate dev board like a Teensy tends to lose much of its initial charm.
Instead, it's more-typical just put the microcontroller IC plus whatever supporting hardware is necessary for the overall device's actual functions on the main board. Don't need USB, or an Ethernet PHY, an LED, a button, or a separate voltage regulator? Want more or less flash? When including the MCU on a board of one's own design instead of a kitchen-sink dev board, one is empowered to use exactly the parts that are required.
This can save a substantial amount of space and greatly improve the flexibility of the layout, while also improving mechanical and electrical robustness by having fewer connections between the MCU and the world around it. Plus, fewer parts tend to be less costly than more parts are.
(But again, it's not always done this way. This camera from the submarine is an example of one instance where the whole dev board was put inside of a finished product. Sometimes that's a good idea, and sometimes it isn't. I'm not attempting to suggest that it was or was not a good move in this instance.)
Everything you said makes sense except you haven't explained why you can't just seal up a Teensy in an enclosure and sell it that way, except for "you're not supposed to do that". Are Teensies prone to random failure or something? Because if they just work and you're only selling <50 devices for extremely specialized nieche then I really don't see a problem with this?
Well, but it's not about whether someone can or cannot do something. Since you seem experienced with these devices I'm just asking if there's any technical reason why this might be a bad idea other than the fact that it just doesn't seem like a very professional thing to do. Like for example even though I'm far from an expert I know Raspberry Pis would be awful for any commercial application because they are notorious for killing their SD cards rendering the device useless.
The Teensy wasn’t engineered, tested, rated, or certified for any sort of continuous duty, let alone within a pressurized O2-enriched environment (assuming it was inside the vessel), especially not within deep sea Helium-enriched environments (that have been shown to break things like MEMS devices), and present unnecessary risks for an entirely inefficient choice (see: comment above, Teensy’s are ~$30-40/ea where small PCBs populated with the same circuit features can be had for under $20).
I’m probably not as qualified as the person you replied to, but that’s my intuition as someone with a passing familiarity with electronics engineering (I have an associates degree in EE).
People do whatever they want. It doesn't have to make sense.
Perhaps disturbingly: I even know of one bit of critical public safety communications infrastructure that is is expensive, low production volume, and has a Raspberry Pi 3 embedded inside. I won't name names because that's getting a little too close to home for my liking, but I was quite surprised to find this inside of a very nice waterproof box with chonky, expensive, olive-colored milspec connectors to connect it up to the outside world.
Which, well: Yeah. There's a ton of good reasons not to do that. But building a whole Linux system on a custom board using individual parts is hard, so it can make sense to buy someone else's work instead.
Except... that's what the CM3 is designed to provide, including on-board eMMC instead of an SD card. I'd not have been surprised at all if there was a CM3 in there, but there is instead an entire Pi 3.
But MCUs, like on the Teensy, aren't like that. They aren't hard to integrate on a custom board like the Broadcom SoC on a Pi 3 or CM3 is.
The primary purpose of an MCU is not to be stuffed onto a dev board like a Teensy, but instead to be stuffed onto the board inside of a microwave oven or an air fryer or a fancy remote control and be easy to interface with other things and to program.
It really doesn't take much to get them going: Some require external ROM or flash, but a lot of them have internal flash memory and only need power and programming pins wired up to let them run code and do whatever IO is needed within a system.
This camera already had at least one very custom board inside. It could have integrated the MCU, as well, instead of the kitchen-sink Teensy.
Doing so is not just style points; it's quite often easier, cheaper, and more flexible.
This allows a person to use all of the IO pins on the MCU to do stuff with, instead of just the functions that the designer of a dev kit decided to build out through whatever interfaces they decided to include.
I suspect you're right about the quantities. In support of that notion, when looking closer at the (linked in another user's comment) PDF of the report, I can see that a lot of this camera's internal structure quite clearly appears to be the product of an FDM 3D printer. This suggests that quantities are low.
And I don't know when that camera was manufactured or designed.
But these days, it's possible to get even hobbyist-quantities of custom PCBs delivered with difficult-to-solder ICs installed from sources like JLCPCB.
(Depending on the features and functions wanted, it doesn't take a whole lot of extra parts to get an MCU to do its thing: There's not a ton of parts on a Teensy to begin with.)
reply