This is true. You only have to deal once with a device that doesn't have a light or something to realize just how essential indicators are. I have sworn to the electronics gods to never to make a device without at least a power led.
BlueAure
joined 1 year ago
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
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.
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.
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.
Screen is probably broken. You might be able to replace it by buying a replacement screen and following a guide by ifixit. Usually pretty straightforward.