|
Yesterday I learned you can run 24v into a Pi 2 with no ill effect. The buck converter explodes a little when you do, but glad the $1 thing I have 20 of broke and not the $40+ Pi 2. Unrelated, but does anyone know if there is a transistor out there that will pass 12v 1A using a 3.3 gate voltage? I'm grabbing a 3v relay that will do it, but was hoping for a smaller package. Amperage can theoretically be as low as 600mA.
|
#
?
Feb 28, 2023 00:09
|
|
|
|
| # ? Apr 28, 2024 11:42 |
|
|
If you can't, you could also get a small bjt to drive the gate.
|
|
#
?
Feb 28, 2023 00:13
|
|
|
I think a Darlington (TIP120 and the like) would work? Just remember that they switch the low side - they go between the load and ground. Usual "I briefly played with this some years ago" caveats apply.
|
|
#
?
Feb 28, 2023 01:38
|
|
|
If high side switching is preferred, do a high side P-channel MOSFET and then the gate drive can be either a little logic-level mosfet or just a 2n3904 or whatever bjt is handy. Since you have 12 volts might as well take advantage. If you really just want a single low-side mosfet and SMT is okay then go for something like https://www.digikey.com/en/products/detail/anbon-semiconductor-int-l-limited/AS2312/16708465 Rescue Toaster fucked around with this message at 02:12 on Feb 28, 2023 |
|
#
?
Feb 28, 2023 02:10
|
|
|
tuyop posted:Trying to make a cat food control system because I have one cat who needs special $$$ food and two cats who LOVE special $$$ food. I looked into this problem myself - my cats were eating each other's food. In my case the cats worked it out amongst themselves and I didn't care anymore, but not before I'd done a fair bit of research into how I'd make bowls. The approach I looked at was scanning the microchips that are already in the cats. First of all, this product exists: https://www.surepetcare.com/en-au/pet-feeder/microchip-pet-feeder But if you want to make it yourself, you can get an RFID reader that can read pet tags (annoyingly they don't use the common rfid frequencies, so you need some pretty specialised hardware): https://m.aliexpress.com/item/32847058721.html?gatewayAdapt=4itemAdapt I don't think facial recognition would work without you basically building your own database, as your cats look very similar and all the facial recognition algorithms are trained on people. Google photos built in one doesn't do a great job of my cats, and they're totally different colours. Double check the pet microchip frequency used in your area - I chose this one for Victoria, Australia. It seems pretty common but there are a few systems in use around the world.
|
|
#
?
Feb 28, 2023 02:45
|
|
|
I also looked at that for the same reason (ultimately both cats just ended up on the same food). It's definitely doable even if they look similar, when you're dealing with two specific cats. But you need a lot of training data, in a variety of lighting conditions, etc..etc.. it can easily pick up on differences you don't expect.
|
|
#
?
Feb 28, 2023 02:53
|
|
|
Cojawfee posted:If you can't, you could also get a small bjt to drive the gate. Ended up I had a BC327 which is working great. Looks like it can do about 800mA, which is enough headroom I'm not worried about it. It was real confusing at first as as soon as the power supply is plugged in the light came on and I thought I royally hosed it up, but I guess the GPIO behavior is pin dependent, and 6 starts high. Computer viking posted:I think a Darlington (TIP120 and the like) would work? Just remember that they switch the low side - they go between the load and ground. Yeah something like that would be perfect too, if maybe overkill. Bondematt fucked around with this message at 07:26 on Feb 28, 2023 |
|
#
?
Feb 28, 2023 07:18
|
|
|
Bondematt posted:Yesterday I learned you can run 24v into a Pi 2 with no ill effect.
|
|
#
?
Feb 28, 2023 07:34
|
|
|
Rescue Toaster posted:I haven't messed with every weird boot config so take this with a grain of salt Thanks for the reply! Turns out the whole problem was a bad microUSB cable. I switched out the cable and tried again, and it worked fine! I was expecting it to be much more complicated than that.
|
|
#
?
Feb 28, 2023 20:59
|
|
|
Olly the Otter posted:Thanks for the reply! Turns out the whole problem was a bad microUSB cable. I switched out the cable and tried again, and it worked fine! I was expecting it to be much more complicated than that. I regret how my hours of my life I've wasted on what wound up being a bad cable.
|
|
#
?
Feb 28, 2023 21:06
|
|
|
cruft posted:I regret how my hours of my life I've wasted on what wound up being a micro USB cable. Fixed. Here's to another decade of lovely connectors with USB-C!
|
|
#
?
Mar 1, 2023 22:57
|
|
|
I've been transcoding videos for the last week or so on the Raspberry Pi 4. All four cores are pegged at 100% and I'm even offloading h264 encoding onto the hardware. The case it's in is a gigantic heat sink. Like, the case is 100% heat sink. No fan. It's stayed under 70 degrees the entire time: right now it's at 66. GeekPi aluminum case in case anybody's interested.
|
|
#
?
Mar 5, 2023 01:18
|
|
|
cruft posted:I've been transcoding videos for the last week or so on the Raspberry Pi 4. All four cores are pegged at 100% and I'm even offloading h264 encoding onto the hardware. If that's 66F then that's amazing. If that's 66C then that's also amazing but I had no idea that raspberry pis could run so hot and still be comfortable. I know that AMDs and Intels only start to worry at 80C but I had considered ARMs to be a bit more fragile.
|
|
#
?
Mar 5, 2023 03:12
|
|
|
Semiconductors are fine until the bond wires start melting. 80C is a soft limit for just about anything, that's comfortable.
|
|
#
?
Mar 5, 2023 03:24
|
|
|
sb hermit posted:If that's 66F then that's amazing. If that's 66C then that's also amazing but I had no idea that raspberry pis could run so hot and still be comfortable. I know that AMDs and Intels only start to worry at 80C but I had considered ARMs to be a bit more fragile. Heh. 66C. The CPU starts to throttle itself when it hits 80, so there's a nice bit of thermal overhead here. I imagine I'd see a few more degrees in summer, but I still won't need a fan.
|
|
#
?
Mar 5, 2023 07:32
|
|
|
cruft posted:Heh. 66C. The CPU starts to throttle itself when it hits 80, so there's a nice bit of thermal overhead here. I imagine I'd see a few more degrees in summer, but I still won't need a fan. If I get any more rpi 4b, I'll have to pick that up. Seems really useful.
|
|
#
?
Mar 5, 2023 09:37
|
|
|
It's a real shame availability has become so bad. On the one hand it's nice that there's other boards and old cheap tiny pcs that can do a lot of the same jobs, but the Pi was a good piece of hardware anyone could buy to do a specific project on and use as a standard. For one example, I've noticed fewer people running Octoprint for their 3d printers and I think the lack of availability of the Pi has caused part of it (the other is that some new printers have their own web interface, and the other, other, part is that a lot of people are buying resin printers and Octoprint doesn't support them, afaik). I've heard and read a lot about the Pi foundation securing semiconductor supplies and they expect much more availability in the second half of 2023 but it sure has been rough for the last year or two.
|
|
#
?
Mar 5, 2023 13:00
|
|
|
TBH if raspberry pi died and was replaced by a more open source alternative, that would not be a bad thing, and would prevent this kind of shortage ever happening again. Even in the peak of the supply disruptions it was still very easy to get Arduino compatible boards, because everyone is making them.
|
|
#
?
Mar 5, 2023 13:38
|
|
|
Splode posted:TBH if raspberry pi died and was replaced by a more open source alternative, that would not be a bad thing, and would prevent this kind of shortage ever happening again. Even in the peak of the supply disruptions it was still very easy to get Arduino compatible boards, because everyone is making them. I can see the rpi going risc-v eventually but the GPU is going to be the sticking point. I don't think there are any open source GPU contenders in the pipeline right now
|
|
#
?
Mar 6, 2023 00:24
|
|
|
Splode posted:TBH if raspberry pi died and was replaced by a more open source alternative, that would not be a bad thing, and would prevent this kind of shortage ever happening again. Even in the peak of the supply disruptions it was still very easy to get Arduino compatible boards, because everyone is making them. Linux on ARM needs to improve and standardize (not a strength of open source). I've been looking at an orange pi 5 for an emulation system because I never got a pi 4, the hardware performance blows the pi 4 out of the water, but the software looks like a nightmare. I understand the boot situation is getting better with the industry converging on u-boot as a sort of BIOS for ARM/embedded devices, but getting to a desktop and still having to screw around with GPU drivers is terrible. It's like a throwback to Linux in the early 00's. Hadlock posted:I can see the rpi going risc-v eventually but the GPU is going to be the sticking point. I don't think there are any open source GPU contenders in the pipeline right now Eben Upton came from Broadcom when they started RPi and I think they got a sweetheart deal for a mobile processor with a bunch of cell phone stuff stripped out. They've been pretty tied to Broadcom ever since, ... and RP2040 is still ARM. I don't think them going vertical on their tech stack is going to solve their supply problem. But a standardized risc-v pi would be sick (it would need video like you say).
|
|
#
?
Mar 6, 2023 08:34
|
|
|
mewse posted:a mobile processor with a bunch of cell phone stuff stripped out. Settop boxes and gpu/photo accelerator for nokia phones. It doesn't seem to have had any cellphone stuff like modem. Speaking of stuff stripped out. Pi 4 does not have AES and SHA acceleration that basically every other ARM8 sbc have
|
|
#
?
Mar 6, 2023 11:09
|
|
|
mewse posted:Linux on ARM needs to improve and standardize (not a strength of open source). I've been looking at an orange pi 5 for an emulation system because I never got a pi 4, the hardware performance blows the pi 4 out of the water, but the software looks like a nightmare. Nah mate, I don't think the problem is "linux needs to support hardware". It's that companies making the hardware need to support linux. They have the drivers for linux, all of this poo poo is running android. But the only people with incentive to put them in compatible packages for standard non-android linux are the people selling the product. Hardware companies realizing that they needed to pay someone to make their poo poo work on linux is why the desktop situation has changed from the early 00s. That's why raspberry is the standard and the other chinesium clones are not: rPi did the work to upstream support and provide repos. They get closed-source binary drivers from broadcom and make them work for general linux. Orange Pi gets a SoC from Rokchip, sticks it on a circuit board, and then both Orange and Rockchip say "support isn't our job, gently caress you". Don't buy product from people who say that. Or at least recognize that you're getting superior hardware for a cheaper price because they've cut costs on a thing that is both important and non-trivial, and correctly assign blame.
|
|
#
?
Mar 6, 2023 17:14
|
|
|
Klyith posted:That's why raspberry is the standard and the other chinesium clones are not: rPi did the work to upstream support and provide repos. They get closed-source binary drivers from broadcom and make them work for general linux. Yes. In fact Broadcomm was not known to be especially open-sourcey before this. I don't know what their reputation is now: there are still proprietary blobs required for the RPi. But the situation is much, much better post RPi than it was pre.
|
|
#
?
Mar 6, 2023 17:24
|
|
|
I have a raspberry pi 4 controlling a 3d printer with fluiddpi/klipper. This includes a webcam and active cooling (heatsinks and a 30mm fan or whatever), which were necessary when I added the webcam. It runs LXDE for the sole purpose of allowing me to control it locally via the webui in firefox. This was slow, but functional and good enough for like a year but has become unusable, very slow to update, with very slow input and commands often never going through until I run to the other room to do it from my PC. This began out of the blue after sitting idle a few months, and updating everything made no difference. Evertything is snappy when I use the webui from another PC on the network. Any suggestions for improving performance?
poverty goat fucked around with this message at 14:19 on Mar 7, 2023 |
|
#
?
Mar 7, 2023 14:14
|
|
|
Is the SD card hosed?
|
|
#
?
Mar 7, 2023 14:25
|
|
|
Thanks Ants posted:Is the SD card hosed? How do I evaluate this? It was a new samsung SD card iirc
|
|
#
?
Mar 7, 2023 14:26
|
|
|
poverty goat posted:How do I evaluate this? It was a new samsung SD card iirc You post the symptoms you did above. They are considered a disposable commodity and are usually the first step in troubleshooting. Copy your image to a new one, or reflash a new OS and move your config over. This is why people also dabble in network boot
|
|
#
?
Mar 7, 2023 14:56
|
|
|
I'm frankly surprised you got any performance at all from a GUI running off an SD card. I tried this once for, like, a week. The SD card is slow, and every operation's performance is going to be magnified. Is your filesystem close to filling up? That could impact I/O. Have you been doing any Internet activity with your browser / did you forget to install security patches? Maybe you have malware. Check dmesg output: I expect you'd see some sort of message if you can no longer write to the SD card, but I'm not positive. I can tell you that if you're unable to write, there'd be a hell of a lot more problems than "just feels sluggish generally". So I'm inclined to think it's something else.
|
|
#
?
Mar 7, 2023 15:13
|
|
|
Roundboy posted:You post the symptoms you did above. Nothing about that sounds like a definite match for SD card being hosed. It's not like the SD is being used for swap or anything. (Or hopefully it isn't.) poverty goat posted:It runs LXDE for the sole purpose of allowing me to control it locally via the webui in firefox. This was slow, but functional and good enough for like a year but has become unusable, very slow to update, with very slow input Is everything in the desktop environment slow and lovely, just firefox, or specifically just firefox viewing the printer webui page?
|
|
#
?
Mar 7, 2023 15:14
|
|
|
poverty goat posted:Any suggestions for improving performance? If you’re not uploading gcode files via Firefox on the pi, try using KlipperScreen instead for local control. I have that on a 5-inch touchscreen connected to a Pi 4, and it can do everything else. I believe it works with a mouse too, if that’s how you’re set up.
|
|
#
?
Mar 7, 2023 15:20
|
|
|
Klyith posted:Nothing about that sounds like a definite match for SD card being hosed. It's not like the SD is being used for swap or anything. (Or hopefully it isn't.) cruft posted:I'm frankly surprised you got any performance at all from a GUI running off an SD card. I tried this once for, like, a week. TVs Ian posted:If you’re not uploading gcode files via Firefox on the pi, try using KlipperScreen instead for local control. thanks I will try this at some point poverty goat fucked around with this message at 16:23 on Mar 7, 2023 |
|
#
?
Mar 7, 2023 16:16
|
|
|
poverty goat posted:The desktop environment is as minimal as possible, it opens firefox on boot and has never been used for anything else. It never performed well, but it was usable enough to monitor progress, turn on/off the extruder for filament changes, or home/raise the extruder. Now an emergency stop will go through after a delay and the UI will never update to let me raise the extruder afterwards, etc. It went a few months without patches but was unused and not connectable from the outside for the duration, and updating everything was one of the first fixes I tried, so probably not malware I think. Also, there is lots of space available Okay. Is there anything of interest in dmesg output?
|
|
#
?
Mar 7, 2023 16:26
|
|
|
poverty goat posted:How do I evaluate this? It was a new samsung SD card iirc Probably the easiest way to troubleshoot this is to just make a backup image off of the SD card, wipe it with the RPi imager, and then try to install like raspbian stock and see if it boots and works properly. From there you could also configure the pi to boot from USB using the RPi imager (which has eeprom configuration options in the "Utility" tab of the source dropdown) and burn the backup image you just made to an appropriately sized USB stick and see how that goes.
|
|
#
?
Mar 7, 2023 16:42
|
|
|
tuyop posted:Probably the easiest way to troubleshoot this is to just make a backup image off of the SD card, wipe it with the RPi imager, and then try to install like raspbian stock and see if it boots and works properly. This isn't troubleshooting, it's nuke/pave. I and at least one other goon feel like SD card failure is a conclusion that the evidence does not point toward. Unless I'm really confused about how the technology works, when an SD card fails, it would manifest as filesystem errors. Operating systems are complicated and slowdowns on a long-running system could happen for any number of reasons. We don't even know what the process list looks like, much less have any indication of filesystem problems. Assuming it's because of the SD card based solely on "it's slow" seems premature at best, and a malicious waste of OP's time at worst. Remember, in order to do a side-by-side comparison, OP is going to have to reinstall and reconfigure their entire application stack from scratch and send it similar workloads. That's not trivial. cruft fucked around with this message at 17:06 on Mar 7, 2023 |
|
#
?
Mar 7, 2023 17:01
|
|
|
We deploy rpis in a lab to act as control/uart interfaces to test systems and I continually have to insist that we NOT attach them to the web enabled power supply because if people are just shutting them off willy nilly that is gonna gently caress the sd cards really quickly. I still get pushback and a lot of “what if we need to power cycle them remotely??” To which I say well fine do what you want just understand you will have to come in to replace the the sd cards then. I would like to move to a pxe netboot but our IT has things far too locked down to even attempt that.
|
|
#
?
Mar 7, 2023 17:10
|
|
|
priznat posted:We deploy rpis in a lab to act as control/uart interfaces to test systems and I continually have to insist that we NOT attach them to the web enabled power supply because if people are just shutting them off willy nilly that is gonna gently caress the sd cards really quickly. Is the concern the media, or the filesystem? Either way, if they're forbidding netbooting (why...) somebody's going to have to be physically present when things go to hell. I'm just curious about the failure scenario here. My current understanding, which could be wrong, is that the card itself doesn't care when you shut off power, but the filesystem 100% cares.
|
|
#
?
Mar 7, 2023 17:19
|
|
|
cruft posted:This isn't troubleshooting, it's nuke/pave. I and at least one other goon feel like SD card failure is a conclusion that the evidence does not point toward. Unless I'm really confused about how the technology works, when an SD card fails, it would manifest as filesystem errors. Yeah you're right but I think you're adding steps to the process. I'm just advocating for making a backup image, wiping the SD card, writing a stock image to it, then booting it up again. If the booted stock image works correctly and is snappy, then we have a good idea that the problem is software in the backup image rather than hardware. Then the process is repeated again, SD card wiped and reimaged with the backup. Now the next troubleshooting step of digging into the software can be tried. Edit: I don't think that's very much time. Like ten minutes of clicking buttons and powercycling a raspberry pi, the rest is just waiting on the imaging process. Last I tried it takes about 90 seconds to image Raspbian to a card and less than 5 minutes to restore a backup image.
|
|
#
?
Mar 7, 2023 17:20
|
|
|
tuyop posted:Yeah you're right but I think you're adding steps to the process. I'm just advocating for making a backup image, wiping the SD card, writing a stock image to it, then booting it up again. If the booted stock image works correctly and is snappy, then we have a good idea that the problem is software in the backup image rather than hardware. Then the process is repeated again, SD card wiped and reimaged with the backup. Now the next troubleshooting step of digging into the software can be tried. e: erasing everything I wrote here. OP, I don't think this is going to be helpful, but go ahead and try it. I'm expecting you to report that, in fact, a brand new OS performs as well as a brand new OS. Personally, I'd like to see what dmesg and top say on this slow system. cruft fucked around with this message at 17:41 on Mar 7, 2023 |
|
#
?
Mar 7, 2023 17:39
|
|
|
cruft posted:Is the concern the media, or the filesystem? Yeah, filesystem, I got em twisted. Corrupting the card will cause someone to have to go in and swap. My argument to not being able to switch off the power to the pi is that if os restart doesn’t work you need to go in anyway, and it removes the possibility that someone accidentally powers off an outlet with a running pi on it. It’s still mildly chaotic in the lab so this can happen. I think perhaps setting up the web power to lock certain ports might be a good option too but overall it just doesn’t seem necessary to have that control over the power input. As for the lack of netboot it’s a whole thing, IT is ridiculous. I might be able to get them to allow it to a staging server. I have given up trying to have something like FOG for reimaging servers because that requires some dhcp control iirc and that’s not gon happen!
|
|
#
?
Mar 7, 2023 18:05
|
|
|
|
| # ? Apr 28, 2024 11:42 |
|
|
cruft posted:My current understanding, which could be wrong, is that the card itself doesn't care when you shut off power, but the filesystem 100% cares. No, SD cards can get super-hosed by power loss during a write. Flash really really does not deal well with incomplete erase or program operations. It can leave chunks of flash in busted non-repairable states that the controller can't handle or even detect. A normal SSD has a bunch of capacitors to prevent this from ever happening. Server SSDs have big hefty capacitors to finish all the queued writes the OS has sent at the macro scale, but even consumer SSDs have a bunch of tiny ones around the flash chips to insure that the micro-operations never leave a flash page in a busted state. Your filesystem might have problems but the drive itself will be fine. SD cards have no power loss protection owing to the small size and their history as a thing mostly designed for battery-power devices. If your application is writing to the card frequently during the normal course of use, then power loss is a risk to be aware of. If your app mostly lives in ram, the OS is set up to avoid needless disk writes (log2ram etc), and the chances of power failure during a write are thus very low, they're generally ok. (However a hosed up SD card does not generally not generally result in "one particular thing that shouldn't be hitting the disk during use is slow and lovely, and there are no other symptoms". More likely total failure or corruption of data that spreads every time the hosed pages get used, which can include .)
|
|
#
?
Mar 7, 2023 18:36
|
|