fps-hero

I think you’re missing the broader point. The “netbook” form factor was absolutely on to something, but it failed to deliver. The atom processor is what enabled the form factor, and practically set the trajectory for laptops for next 10 years.

Everyone has rose tinted glasses and short memories when it comes to just how far computers have come in the last 15 years. For reference, netbooks predate iPads by 3 years. They came out about the same time as the first iPhone.

The low power long life computing platform has for the longest time been a dream. Netbooks with 4-8 hour battery existed at the same time that a top of the line laptop would get only 3 hours battery life, a normal consumer grade laptop would top out at 1-2 hours, for a 1/4 of the price.

If you squint hard enough, there is no discernible difference between the aspiration of the netbook platform, and a modern chrome book or iPad with a keyboard, but Intel doesn’t make processors for either platform.

It may help to a limited extent with compression, but the window size is so small it is hardly worth it. I imagine a huge part of the speed of the algorithm is how cache friendly it is. Worse is better sometimes.

Imagine if you could simply deploy an army of fuzzers on a piece of code, vs what could be derived from client side probing. Yes, having access to the source is a problem.

An hour later, wow. That podcast is mesmerising. That’s absolutely incredible what they were up to. Thanks for the share, on to part two now.

It’s so frustrating that the entire CSI camera module ecosystem has been completely handicapped by the choice of connector for the camera module.

The V1 camera module (OV5647) only supported two lanes, so it was a fair enough decision then, but they had a chance to change it when they changed connector on the PiZero.

The connector even had the 4 extra pins specifically to support 4 lane CSI, but it was as if it was forgotten about. The V2 camera came out not long after so the combination would have made for a massive upgrade.

I think they ended up back peddling from the new connector due to the horrific combination of a too thin custom flat flex cable with a connector that could barely meet its 10 mating cycle rating.

It didn’t have to be that way, a standard 0.5mm FFC with decent swing down latch connector is 10x more robust.

Forget the USB boards, they all work to the best of the USB / UVC limitations but they aren’t great. You want to hook your camera sensor up to a processor with a CSI input.

Image sensors are really just high speed ADC clocking out data, whether the data is useful or not is up to the viewer. What I’m getting at is forget FPS and think data rates.

So, you need a processor that is that can handle that data rate. The napkin math says 2K@240FPS has the same data rate as 4K@60FPS. All you need is a processor or module that can handle it and you’re golden. There are demos of the RPI pushing 1000fps (at a significant lower resolution) but you get the point.

Off the top of my head, NVIDIA jetson, imx8m mini plus, the latest allwinner V series, and a whole host of unobtainable in less than 10k qty parts all supported this. The rest is up to you.

Also, RPi is out even with 4 lanes because the CSI input doesn’t support the speed required on each lane.

Solar is by far the cheapest form of energy by a significant margin. It is already at the point where it makes sense to put it everywhere, and have concentrated large scale generation.

For solar to win, we need to solve energy storage, or perhaps the energy distribution problem. There is no amount of solar which will give you power 24 hours in a day in a single location.

Energy storage is the best short term solution. If we can capture peak solar generation and move that energy to the peak demand period, we can have a serious discussion about moving away from coal for baseload generation. It won’t be needed during the day, and the demand periods covered by storage.

However, for solar to really win, we need to think bigger with our energy distribution networks. Think of a global scale distribution network, like an internet for electricity.

If you can send an IP packet from your computer across the world, why not energy?

With a sufficiently large interconnected global scale network of renewable generators, energy storage becomes less important. We don’t need gas pipelines, we need longitudinal and latitudinal HV distribution networks.

It may be a hack but it isn’t a new idea. MBed DAPlink has had drag and drop programming for a long time. The STlink programmer also does this, so do the Segger J-links.

Based on what you could buy through distributors, less than 5% of the STM32 lineup is available to buy. The situation was worse, 6 months ago there were 27 variants available on Digikey of the 3000 or so they make.

The G series seems to have good availability at the moment, if I was going to bet on a MCU for a new design that would be it. L series has only just gotten better, couldn’t get them a few months ago.

Some F3 chips have been looked over (didn’t go out of stock) despite being more advanced than their F4 counterparts. That’s marketing I guess.

Consoles and open source do not mix. NDAs prevent code using their APIs from being released.

That said, a lot of open source projects have console ports, they just can’t be shared publicly.

Thankfully we have great consumer laws in Australia. This is referred to as drip pricing. It also makes practices such as mandatory minimum tips illegal, which would make someone from the US’s head spin.

https://www.accc.gov.au/consumers/pricing/price-displays

Perhaps a better way would be to use something along the lines of SSH’s randomart.

I’m sure there would be an even more interesting variant where the address could be used to generate a prompt for DALL-E.

The 20mm profile also comes in multiple widths and double thickness combinations, so there is indeed a 80x20mm profile (4x1).

Also, it’s 1 and 1.5 inch t slot, not 20mm.

Weird name indeed.

The bug relies on undefined behaviour in the C language, but it’s exploitable is due to the way memory access operations are written in C. Equivalent Rust code would not be exploitable at a language level because that type of raw pointer array access isn’t possible with resorting to unsafe blocks. The undefined behaviour that caused the bug also doesn’t not exist in Rust.

And the Window 7 fresh install conundrum, how do you install wifi drivers when your laptop only has wifi and no ethernet?

I also have a vague recollection of needing to install windows 98 from a floppy disk boot, then upgrading to windows XP as an upgrade, just because the bios didn’t support a cd-rom boot option. Fun times.

That’s a neat looking trick, will have to see how well it works in practice. I can’t see it working too well if you need to feed the wire into a through hole.

My trick is to tin the joint and the wire, apply no-clean flux to either the joint or the wire (situation dependent), then bring the two together while reflowing the joint. Quite handy for soldering tight multi-pin connectors.

The real tip is buy flux, it’s just as important as solder.

Another factor, travelling on the Shinkansen is an experience in itself. JR pass maximises your chance of experiencing the bliss of high speed rail.

Don’t mess with a Cassowary. Fairly rare to see them in the wild outside a few places, but they give no grace. The ones in captivity will 100% have a go at you if you get too close to the fence.

Modern sensors seem to quite useless with something able to crunch the numbers, so this is becoming increasingly common.

TI’s mmWave sensors (IWR series) incorporate a top of the line C674x DSP core that is clocked at 600MHz.

If something becomes important or necessary, the entire document would be leaked, or relevant sections documented. Thank you Scihub and libgenesis.

The more likely outcome is the specification will become its last version. If the spec isn’t open, people will implement it, but poorly. This will lead to gross incompatibly, and force people to default to known good legacy standards. For reference, see USB 3.0+.

HDMI is already USBified. Most of the headline features of 2.1 are just making the 2.0 features mandatory, but introducing another set of optional features.

I would say that patents and copywrite are orthogonal.

A patent, hopefully, captures a truely new and original idea. Where as as copywrite encompass actual work.

One huge problem with patentable ideas is that the idea should not obvious to those in the field, but intails a proof by contradiction. If the idea was obvious to one person, surely it was obvious to many. And is more clearly obvious to anyone who has seen the idea.

Trade marks are only to protect branding, they stop mimicry that doesn’t violate copyright.

Trade secrets are the real secret sauce. They are legally protected and by definition are unpatenable. It’s the only way to keep a competitive edge.

CRTs were all 4:3, and had better specifications than the LCDs of the time. Back then LCDs also followed PC standard 4:3 resolution. It wasn’t until LCD tech was cheap enough for mass production in TVs that 1080p monitors became the norm.

Offline, air gapped, and limit control at gateways. Is SCADA security really that hard? If it absolutely has to tap into you company’s cloud based SAP, make the interface hardware enforceable supervisory only?

I love solvespace, the UI is quick, minimal and easy to come up to speed with.

I use it as a 2D parametric sketch pad, for 2D designs for laser cutting, making 3D models for kicad, and a few basic 3D printed fixtures, but it is in no way a replacement for even Freecad.

The constraints are feature complete, but minimal. Some basic geometry is often a pain to get setup. Once you hit 3D you’ll realise that your basically limited to extruding and revoking sketches. Still a powerful tool but not suitable for serious mechanical design.

What world really needs is for FreeCad to be as usable is it’s paid equivalents. I don’t understand why free software always neglects the UI. How hard is it to even simply copy the time tested work flows in proprietary software. Once you learn Solidworks, Inventor, or Fusion 360, you can pickup any other parametric modeller.

Code as CAD as an idea I believe is flawed. It doesn’t solve any of the hard problems of mechanical design. Designing physical objects requires good visualisations and iterative feedback. I.e changing this dimension solves this interference in a complex assembly. Besides, most mechanical engineering are not proficient coders.

Thank you for sharing, gosh that must have been horrific to track down.

There really is something about USB buses that cause the worst kinds of errors. I happen to know that the USB2 driver in the RPI 1/2/3/4 has a Linux kernel corruption bug which is completely masked by the use of a USB hub.

Why does it matter? Because the RPI 1, 2, 3 all hide the USB port behind a hub. Only the zero, and the a series have a naked port. Now, try searching the RPI forum for USB problems and start to notice a correlation.

The problem is that the hive mind decided that all USB errors must be power related, and given the complete dodgeyness of most RPI zero setups it was always assumed this was the culprit.

Unfortunately it isn’t. No amount of probing, decoupling, externally powering ever fixed the glitches, ah but yes, not using an official 3A RPI branded psi was definitely the issue, sorry Agilent your psu’s just aren’t up to task, probably the reason you had to “rebrand” in the first place. :S

We ended up retrofiting a USB hub in-line with a USB connector for a prototype, and we’ve since designed in the hub just for that one USB port used for USB data storage, which is brilliant at the moment because USB hubs ICs are unobtainium, so, we can’t make any more product, because of this software bug.

Every couple of months I would try the latest kernel, but all you needed to do was write to disk continuously and you would hit the bug in 4 hours max, 10 minutes on average. The best part is the kernel corruption kills the file system, we got a trace on a monitor (normally a headless system) but if you ssh’d in, you were dropped into and empty file system and you couldn’t run any tool to diagnose a problem, a simply tab competition would hang the shell. Fun times.

Never bother reporting the bug because I found hundreds of threads on the forums detailing similar issues. It is very uncool that to this day they still insist on using their bespoke driver instead of trying to mainline their performance fixes, otherwise everyone using the dwc2 ip would have befitted, and this bug would have been fixed with hundreds more eyeballs on the problem, not just the one USB guy at RPI towers.

If your getting X’s, why bother? Every PCB place I’ve dealt with tells you test rate and success rate (nominal 95% not factoring in specifics of the PCB). For a prototype run, you are effective guaranteed 4.95x good PCB out of 5 Minimum order. 50% e testing means you still got two out of five.

I wish they advertised it more! That reduction in annular pad plus the inner player geometry is a game changer. Effectively any 0.8mm pitch bga is completely prototype-able now.

The best reference I can point to is the Xilinx bga pdf in google. Basically, for given capability (geometry really) there are only certain ways of breaking out pads. You can either fit multiple (luxury of process), one, or zero traces between vias and pads. And as a result of this, you need xTimes PCB layers to effectively breakout BGAs given there ball depth.

Simple chip scale bgas can be broken out one layer, but the geometry requires capabilities that only multi layer process provides.

The real takeaway is JLCPCB just got a whole lot more competitive with there 6 layer service. 0.2/0.4 vias, 0.1 trace/space is the holy grail. Anything smaller geometry than that you need board house support, and a finely tuned assembly process.

> Also note that I only used the small trace size to get to the pads, where it's actually necessary: as any trace that is close to the limits of the board houses capabilities has a chance of not being manufactured correctly, I tried using as little trace length that is minimum-width as possible.

I wish we could stop repeating this fallacy. It simply isn’t true. You can specify 100% e-testing if you are that concerned.

I’ve had thousands of prototypes PCBs made, and only two failures I can remember, both were from under etching. Never had a NC on a trace running at specified capability.

> Well... that's not necessarily true. For instance, even the cheapest 2-layer process that JLCPCB offers is capable of 0.127mm tracks spaced 0.127mm apart... which means you can lay down tracks at a minimum of 0.254mm apart. That's good enough to connect to pads with a 0.35mm pitch.

The fence post error of PCBs, you need 4x the minimum spacing / trace width to breakout without vias. 1x trace, two spaces, and half a trace on both sides to match your BGA pitch. Best you can do on JLC is a 2 row 0.5mm breakout without resorting to tricks. You really need 0.1mm capability for these tiny pitches.

Edit: Just double checked JLC, their 4 layer does offer full 0.09mm capability, which is new! It use to only be the outer layers that could be 0.09mm, and 0.127 on inner layers. You can actually do a proper 0.8mm BGA breakout now, and 1mm pitch is child’s play now, you can fit two traces between vias.