Guys, don’t take the claim so literally. He’s a successful tech poster. He makes good money showing off his purchases the good money complaining about how expensive they were.
But certainly don’t imitate his choices, his economics aren’t your economics!
Thats pretty much a given, but what the real takeaway should be from most of the content is that whatever you are doing, these days the answer in all likelihood is not to buy a raspberry pi. It's specs to price just do not add up at all anymore, and it's looking like a pretty damn stagnant place these days.
What if you need ARM? What is the best sub $100 sbc that I am missing? Orange Pi hardware always looks good but I hear a lot of negativity about the software that I don't really experience with Raspbian.
Then you should take a good hard look at older, much cheaper Raspberry Pis.
Then look at Apple’s ARM offerings, and AWS Graviton if you need ARM with raw power.
If you need embedded/GPIO you should consider an Arduino, or clone. If you need GPIOs and Internet connectivity, look at an ESP32. GPIOs, ARM and wired ethernet? Consdier the the STM32H.
Robotics/machine vision applications, needing IO and lots of compute power? Consider a regular PC with an embedded processor on serial or USB. Or nvidia jetson if you want to run CUDA stuff.
And take a good hard look at your assumptions, as mini PCs using the Intel N100 CPU are very competitive with modern Pis.
There are a lot of reasons you probably would want a Pi over an ESP32 (or in addition to one), e.g. you want GPIO, plus, internet connectivity, and want to run certain linux programs (e.g. full python, not micropython), or need timesharing, or any number of reasons you might want a linux box over an embedded.
But single board computers with something external to do your GPIO is often way more compelling.
I've heard nothing but horror stories on the Jetson & Tegra in general. I'd Avoid it unless the project MUST use a SoM w/ CUDA. which will basically only be Professional stuff. I've never heard of anything hobby level where a PCIe slot was a deal breaker- even with high vibration. (PCIe 4.0 isn't terrible difficult to get good flex cables for)
A different thread on here the other day seemed to come to the consensus that if you're considering an N100, you may as well go with a low end Ryzen. And for much the same reasoning being used here. Seems to be a little bit of a slippery slope.
If you or someone can find that thread I would find it an interesting read.
My cursory research indicates that a low end ryzen would make sense if you are building the board yourself. Right now, I haven’t found a new ryzen mini pc sub 200$. New N100 minis can be had for 150-175$, and if you don’t care so much about power N95 minis are even cheaper.
A lot of others are stuck in a loop where they essentially review tech for making more youtube videos - render times, colour accuracy, camera resolution, audio fidelity.
People are commenting about issues loading the images leading to them abandoning reading the article. Here is a fully cached copy of TFA, but note that the videos (and images, but especially the videos) load _really_ slowly https://web.archive.org/web/20240317122351/https://blinry.or... (but they do load if you wait long enough).
I was informed maybe 7 or 8 years back that my electric company would be replacing my analog meter with a smart one and always intended to try and glean more information about my electric consumption habits from it. It took me a lot longer than I intended, but last year I finally bought an RTL-SDR in the hopes of being able to get realtime info from the meter. Unfortunately, it seems that it's not one of the ones that emits consumption info over ISM bands for consumption by household appliances (so far as I can tell) and I ended up only capturing info from TPMS sensors off of passing cars (which was cool, but not really what I was looking for).
Do note that if you purchase an RTL-SDR these days, you'll probably get a v4 which, at least as of last year, does not play out-of-the-box at all with the software available on the Ubuntu apt repos and the RTL-SDR drivers that ship with 24.04 out-of-the-box — there were some hardware protocol/interface changes between v3 and v4 that make the old drivers incompatible and you'll get a litany of misleading or non-specific errors if you try without downloading and installing the latest drivers from GitHub (or somewhere).
Look into Rainforest Automation. I have their EMU-2 which can be paired with my electric meter. It spits out XML data which can be read by Home Assistant.
I’m intrigued but that is one of the worst (least technical) product pages for a very technical product that I’ve come across. My biggest concern was that it has no mention of compatibility, it just says it connects to the smart meter via zigbee but aside from the obvious fact that zigbee is just the network protocol and does not necessarily mean all smart meters use the same layer 7 details, I don’t even know if my smart meter has zigbee to begin with! Ah, I just found a FAQ page for the site not linked from the product page that answers the compatibility question.
Also, I wouldn’t have known the product exposes an API I could use to programmatically get the (XML-only?) usage data in realtime over the network if you hadn’t told me, the product listing makes it look like it’s just a screen (and the faq doesn’t have anything about connecting to the device programmatically).
Anyhow, thanks for brining this to my attention! This might be exactly what I was looking for!
I received my device as part of a pilot program with my utility company.
Check with your electric company first, and also look at your local library -- my brother was able to borrow one from there to check compatibility first.
A number of smart meters communicate over the mains wires, especially when they're in very sparse areas. There was even a thought for a bit to offer internet services over the power distribution cables, but I don't think they ever really got effective data rates high enough to be competitive.
Yes, that seems to be what mine is doing as my ecobee thermostat is able to read info about peak usage times from the mains. I didn't know about the latter part though, I never imagined electric companies were making a play for the internet (though it seems like an obvious thought in retrospect).
A lot of electric companies in the US are also ISPs. They already have most of the equipment to run fiber, and many also do wireless links between substations.
And its "last mile" friend of using the in-wall cable as Ethernet drops, too, e.g. https://www.tp-link.com/us/powerline/ (but I don't think it holds a candle to actually pulling cat 5 or 6, for clarity)
In the early 2000’s there were efforts to provide broadband over power lines (BPL). I think one of the biggest obstacles was the radio frequency interference it generated.
Re-reading some of the history of it that does sound like RF interference was more of a concern than data rates. Some places even attempted roll-outs but were stymied by regulators wanting more studies about potential impacts.
If it's low enough bitrate, wouldn't you be able to read that by putting an antenna or loop of wire near the mains? I assume they use a documented standard.
A lot of the Nesdr kits come with a Ham It Up 1.3 already, which seems to be the only real difference listed besides the accuracy of the crystal oscillator being much more accurate in the Smart v5.
I disagree, there are too many variables and ultimately the end user would be th one that knows best. The proper solution isn’t having the library or application dev, who has no idea what kind of network connection the user is running, the type of dns server (caching or not, lan or remote, etc) or the name servers of the target domain and their performance or availability. This is all really the domain of the sysadmin.
The solution is to make it a properly non-blocking api.
Historically libcs have been leery of imposing threading on otherwise singlethreaded applications; and for similar reasons, try to minimize startup costs.
This is, essentially, what the previous (largely pathetic) excuse for true asynchronous I/O on Linux did with the libc aio(7) interface to essentially fake support for truly asynchronous file IO. It wasn’t great.
But certainly don’t imitate his choices, his economics aren’t your economics!