Usually, not adhering to timing recommendations isn't going to damage a circuit. However, it introduces potentially undefined or unpredictable behavior. For example, if you are driving a pump with specific timing requirements to control precisely the amount of fluid passed and you skew the timing a bit. Most of the time it would probably be fine, but there would be the potential that it might pump too much or too little. For a low precision application like a sump that's ok, but for a high precision application like an medication pump it has the potential to kill someone.
At the end of the day, it depends on your tolerance for risk. Manufacturers generally certify their products for the timing on their datasheets. If you operate out of those specs, you are taking the responsibility of what happens.
Don't want to scare anyone off, but it all depends on what you're doing with it. In personal projects, yeah I'll do all kinds of squirrely out of spec shit, but I'd never do that at work cause of potential liability. It's up to you to determine if losing a couple steps on your watering pump will kill anybody or not! :D
At least one of the big 3 isn't meeting production demand due to battery assembly. Long series of management and integrator fuck ups where their solution seems to be just throw more engineers at it. Can't build EVs if they can't build batteries.
I got a Litter Robot 3 a couple years ago and its the best money I've spent in a long while. Super convenient and I haven't had any issues with it even with 2 cats.
I use mergerfs to pool a bunch of varying sized drives and then run snapraid on the whole pool to protect it. Then, I've got Kopia backups running and backup up to a remote repository. This solution has been flexible and I've already been able to recover from 2 drive failures very quickly and easily.
You should test it out and report back with the results.
The Yogscast Jingle Jam! They do an annual month long Livestream where they play games and raise money for a variety of charities. Donations of 35 pounds or more also get a whole bevy of game keys as part of the collection that can be redeemed on steam. You can see the list of games or donate at jinglejam.tiltify.com
Less biased than some other media sources I've seen and makes it more likely that I'll read it. Since the opinions are clearly marked it's possible to skip them as well and just read the facts as presented. I just keep it in mind as I read and it works for me.
I recently found out about Axios which does short bullet point coverage of just the interesting/most important parts of stories. It seems to be a bit biased liberal overall, but being able to get the highlights without wasting time reading all the fluff is pretty convenient.
I just use a cheapo Bluetooth ELM327 clone from Amazon. I got the second cheapest one that reviews said worked and after a bit of fiddling to get it paired, it seems to work alright for the occasional issue.
It's the best one that I've found since the old ES File Explorer sold out and became adware
AndrOBD for connecting to my car OBD2 Bluetooth adapter. It lets you read any diagnostic codes and let's you reset warning lights.
Aegis for managing 2FA tokens. Weawow for weather. MiXplorer for file management.
Purdue University still has a campus-only file sharing network called DTella that's DC++. It been getting smaller, but there were a few members that shared 50+ TB at one point.
I don't think so. It might have been delisted as I don't see it either. Regardless, it's OSS so you can get it from the GitHub repo. https://github.com/hidroh/materialistic
Assuming that there is at least some amount of slippage between the wheel and ground, it seems to me that you'll need to regularly check the ToF sensors anyway. I've found that encoders are fantastic for a lot of things, but not so much for measuring distance because of the problems you've described. Perhaps a recurring local check on a reduced set of points to verify location then forward the full cloud less often for further remote processing? It really sounds like you have a tradeoff depending on whether you value accuracy of location or accuracy of wheel rpm (analogous to speed). Using both would give you a nice way to calculate the ideal motor rpm to minimize slippage in a surface agnostic way.