121–130 of 157 posts
For those of you who didn't read the fine article, I've quoted it here:
> As usual, this post is not a request for THE ONE to show up. If you are THE ONE, you don't make mistakes. We know. Shut up and go away.
I think the last paragraph was my favorite part of this article. For those of you who didn't read the fine article, I've quoted it here: > As usual, this post is not a request for THE ONE to show up. If you are THE ONE, you don't make mistakes. We know. Shut up and go away.
The wireguard problem is a pain in the neck. Even if you're happy for your system to not have a realtime clock, when it does come online you'd want wireguard to not start until after the clock has synced to a timeserver. The below is what I'm doing at the moment, but I can't say I'm sure it's working - haven't seen wireguard start before the time is synced since doing it, but it could be probabilistic: systemctl enab…
It's surprising that it was left out. Ie, the workaround makes sense, but this is a peripheral that is sometimes built into MCUs themselves. For example, most (all?) STM32s include an RTC... with the caveat that if you are using them for canonical use cases, you will need external hardware in the form of a dedicated 32kHz oscillator, and possibly a battery. For a lot of micro-controller timing uses, they aren't requi…
It’s definitely served me well in a wide variety of disciplines.
Earlier quoted context omitted.
You can use plain HTTP for time sync. Almost all HTTP servers respond with a time header.
The whole point of the exercise was to make it secure though. If you don't care about MITM attackers then NTP works great.
Years ago I've tried privilege escalation exploit to play with a phone and it involved rolling back date to unexpire signature, so I know there is exploit potential, but it... it just feels like RTC bootstrap problem should be something solvable.
I've personally had so many issues with SD card corruption on raspberry pi's that I've decided it was a mistake to even allow SD card disks I only ever use USB storage on my pi's now and not had a single issue since
I've always been amazed that the Foundation never mandated the use of validated brands or types of SD cards.
Not that it matters much to me, I've had to retire all of my Pis earlier than the 4. It seems that all of my Raspberry Pis prior to the 4 all had some sort of design issue with their power regulation. After a couple years of constant operation, they just start locking up randomly around once every day or so. I've had everything from a Pi 1 through 3 exhibit this behavior. I spent WEEKS troubleshooting this and conclusively ruled out wonky SD cards, power supplies, connected devices, proximity to other equipment, and every other factor I can think of. I found many threads with other people reporting the same issues but the Foundation refuses to acknowledge it as a problem. I only run Pi 4's now, and am gradually switching over to Intel N100-based systems for low-power operation.
By the time you buy everything you need to make a Pi 5 even remotely usable and reliable today, you'll have spent as much as a small form factor PC. What do you need?
1. Special power supply - Yes, it's USB-C but it requires a high amperage 5V supply instead of accepting a higher voltage like most USB-C stuff
2. Active cooler - Pi 5 throttles immediately without it; it's not an optional component
3. NVMe Expansion HAT - Seriously why the fiddly little PCIe header? Put an NVMe slot on the bottom and let people adapt *that* connector
4. RTC Battery - At least put a damn capacitor on the board
5. Enclosure - I'm halfway expecting the pi foundation to print some dashed cut lines on the cardboard box so they can say it comes with a case =]
Not like the Pi Foundation couldn't have contributed to uboot or the upstream kernel or anything before thier hardware was released. Pretty much nothing released for "Raspberry Pi" runs on a Pi 5 at this point in time.
They better try to salvage something before putting out the expected CM5, but I'm not expecting much.
Earlier quoted context omitted.
Ah okay. Conversely I've never tried that setup :) Nice to hear about it though.
This is off-topic, but I was looking at your sbts-aru project and remembered having read the hackaday post on it about fireworks. I'm curious if you've ever seen the RaspberryShake BOOM sensor? If so, any thoughts on how your project and it differ? https://shop.raspberryshake.org/product/turnkey-iot-atmosphe...
Currently I only support USB mics at 16 bits that can talk to jackd. This was a conscious decision because it was all that was needed but also because jacks makes it essentially have multiple source sinks. Such as as well as recording a real time audio processing pipeline that potentially leads to real time gunshot and other sound event localization.
But it would be cool if the infrasound sensor had a USB sound interface. As then it could be useful in localizing elephants.