Hopium? This blog is suggesting an incredible margin of victory for Harris.
VDH is the website. They are outright calling respected meta-polls FiveThirtyEight and RCP completely wrong. Their overall argument is that the Senate-race is incredibly favored in the Democrat's favor.
I don't know if I necessarily believe that argument. But its still interesting to think about. Discuss?
Editor's note: I can't post pictures from my Lemmy.world account. I presume that recent trolling-attacks vs Lemmy.world have to do with this restriction, so I'll use my Lemmy.ca account for this post.
Today is a "Sidenote" for my "Beginner Series", because its not a particularly scheduled discussion point. I was browsing the internet for some documentation when I found Microchip's Signal Chain Design Guide.
Yes, this is marketing material. But its well written and covers many important concepts for beginners. Again, the PDF is here: https://ww1.microchip.com/downloads/en/DeviceDoc/21825g.pdf
At the crux of the 'Signal Chain' is the following diagram:
Many, many applications can be simplified down to this loop. Sensors provide a signal of some kind: changing voltages or currents as real life events happen. Temperature changes resistance and/or voltage of a thermocouple, pressure changes resistance of resistors as well. More complex sensors like IR Photodiodes will change their current due to the presence of light. (and that IR Photodiode may itself be encoded information: with lights turning on-and-off associated with machinery RPMs).
Whatever the "sensor" is, it may need analog processors to condition. OpAmps are the most common analog processor, but instrumentation amps, differential amps, and sometimes even raw BJTs are used for this step (when high-frequency is needed, such as amplification of radio signals). There's a side note here about digital-potentiometers and their ability to calibrate analog bits of your circuit, but calibration can be skipped if you don't care much about accuracy.
In particular: whatever your "signal" originally was needs to be converted into a voltage of the appropriate size for your ADC. For example, a capacitive touch sensor can track the human-body (fingers) moving across different electrical pads. This "signal" is watching for the change of capacitance over different electrical lines. But "capacitance" isn't voltage. Instead, you need to inject small amounts of current into the various pads while measuring their change-of-voltage over time, which converts the "change of capacitance" into a "change of voltage" formula, thereby allowing later stages to operate upon your data.
Once the signal is processed to appropriate levels of voltage and/or current (or if you're lucky enough: the raw signal is good enough without need of preprocessing), then you can feed it into an ADC and digitize the signal.
Once the signal is in digital form, you write a computer program to analyze and manipulate the data. For many, the data will remain in digital form perpetually, sent out over WiFi, Bluetooth, or perhaps to a MicroSD card for recording. But for others, the job is not done yet. The combined sensor data goes into an algorithm to determine actuator outputs.
Those actuator outputs leave in either PWM form or DAC as an analog signal directly. Alas, microcontrollers usually have weak pins, so output processing and amplification is needed to increase power levels to appropriate voltages and/or currents.
Finally, those voltages and/or currents affect an actuator. That could be a servo, a motor, LEDs to blink or really anything.
While these steps are individually pretty simple, as a whole they constitute a pattern and architecture that matches a huge number of electronic designs. Your thermostat (temperature sensor -> microcontroller -> turn furnace on or AC on). Drones (accelerometers to measure bearings in space - microcontroller -> motor controls), motor controls (sense current through motor to estimate torque -> microcontroller -> BLDC Motor signals), and more.
This page summarizes the sensors available from Microchip. And remember, this is just one company. There are plenty of sensors available around the world in many other forms.
As far as actuators... Microchip doesn't make too many of those. But motors, speakers, MEMS, refrigerators... anything you can hook up to electricity is something you can control with a microcontroller.
I hate this setup.
Rasp. Pi Pico W has a Wi-Fi card. Cool. The WiFi connects to your local WiFi network, which connects to your ISP, which connects to the internet, which connects to ntfy.sh. NTFY.sh then creates a push notification over Apple and/or Android, then finds your Phone, likely realizing your phone is currently in your WiFi network. It then sends a message to your ISP, to send a message to your WiFi network, which sends a message to your Phone and you finally get the alert.
Its probably the easiest way to get things done, but a bluetooth alert and/or Wifi-direct alert of some kind would be better. Phone APIs don't seem too keen on WiFi / Socket servers however. Bluetooth would likely be a better solution, but involves pairing and other such noise to complicate the process.
Hmmmmm. I see that ntfy.sh is the easiest way to bridge it all together. But that doesn't mean I have to like it.
Old news.
https://www.cnx-software.com/2019/02/21/stmicro-stm32mp1-cortex-a7-m4-mpu/
This happened in 2019. STM32MP2 release is coming soon, so we're well on our way to having the 2nd generation of STM32-microprocessors.
I'm mostly a MCU fan. MPUs are awesome too, though the gross complexity increase makes my head spin. Supporting "proper" DDR2 and 512MBs sounds awesome though, my personal VPS for years has always been just a 512MB instance because that's enough for personal websites and simple Linux tasks.
512MB DDR2 on a single-core ARM A7 is exciting to me. But... in a way that feels forbidden, too complex for me to truly get into and try to use. I'd probably just buy things like Beaglebone Black ($50 at the moment), or Rasp. Pi (if it ever comes back to a good price).
That didn’t fit with his limiting how many tweets users are able to view.
The theory behind that is that Twitter failed to pay for their web-services and needed to suddenly cut traffic, otherwise they'd be shutdown by Amazon / Google.
After Twitter paid Amazon/Google, they raised the tweet view-limits appropriately, but the damage was already done.
Washington Post confirms the story https://www.washingtonpost.com/technology/2023/08/15/twitter-x-links-delayed/
Yeah, cause the Win32 API + DirectX is more stable than the rest of Linux.
There's a reason why Steam games prefer to emulate Win32 API on Linux, rather than compiling to Linux binary native. Wine is more stable than almost everything else, and Windows's behavior (both documented, and undocumented) has legendary-levels of compatibility.
You know that doesn't matter when commercial software often only releases and tests their software on Ubuntu and RedHat, right?
I run Ubuntu / Red Hat / etc. etc. because I'm forced to. Do you think I'm creating a lab with a billion different versions of Linux for fun?
Linux kinda-sorta works if you've got the freedom to "./configure && make && make install", recreating binaries and recompiling often. Many pieces of software are designed to work across library changes (but have the compiler/linker fix up minor issues).
But once you start having proprietary binaries moving around (and you'll be facing proprietary binaries cause no office will give you their source code), you start having version-specific issues. The Linux-community just doesn't care very much about binary-compatibility, and they'll never care about it because they're anti-corporate and don't want to offer good support to binary code like this. (And prefers to force GPL down your throats).
There's certainly some advantages and disadvantages to Linux's choice here (or really, Ubuntu / Red Hat / etc. etc. since each different distro really is its own OS). But in the corporate office world, Linux is a very poor performer in practice.
like saying you are running last night’s upload
If only. I'm running old stuff, not by choice either.
Ubuntu 18.04 and up literally fails to install on one of my work computers. I've been forced to run Ubuntu 16.04. BIOS-incompatibility / hardware issues happen man. It forces me to an older version. On some Dell workstations I've bought for my org, Ubuntu 22 fails to install and we're forced to run Ubuntu 20.04 on those.
Software compiled on Ubuntu 16.04 has issues running on Ubuntu 20.04, meaning these two separate computers have different sets of bugs as our developers run and test.
I'm running old LTS Ubuntu instances, not because I want to mind you. But because I've been forced with hardware incompatibility bugs to do so. At least we have Docker, so the guy running Ubuntu 20.04 can install docker and create an Ubuntu 16.04 docker to run the 16.04 binaries. But its not as seemless as any Linux guy thinks.
CentOS is too stable and a lot of proprietary code is designed for Ubuntu instead. So while CentOS is stable, you get subtle bugs when you try to force Ubuntu binaries onto it. If your group uses CentOS / RedHat, that's great. Except its not the most popular system, so you end up having to find Ubuntu boxes somewhere to run things effectively.
There's plenty of Linux software these days that forces me (and users around me) to use Linux in an office environment. But if you're running multiple Linux boxes (This box is Ubuntu, that one is Ubuntu 16 and can't upgrade, that other box is Red Hat for the .yum packages...), running an additional Windows box ain't a bad idea anyway. You already were like 4 or 5 computers to have this user get their job done.
Once you start dealing with these issues, you really begin to appreciate Windows's like 30+ years of binary compatibility.
Ongoing DDOS attack right now. Testing federation post with my alt-account. Lemmy.world is down as of this post, but I'm still able to get to Lemmy.ca as expected.
Microcontroller ADCs still have a bad reputation compared to "hardcore" analog designers, but STM32 isn't bad in the great scheme of uCs.
https://hackaday.io/project/188051-rpscope
Here's the original project, and with a circuit layout closer to what I'd expect to be typical. However, notice that the STM32 contains all the parts that are in the rpscope: STM32 has an ADC (albeit a slower one), multiple OpAmps (albeit with lower accuracy), and a microcontroller (albeit with less RAM than the RP2040).
Shrinking and consolidation is the goal for these devices, leading to far cheaper designs with possibly better reliability (now that its all put together in one package). Of course, the specs are far weaker on the STM32 rather than dedicated ADCs, but you can see the size, cost, and power/watt difference by just looking at this thing.
Test post for my alt to be promoted to moderator.
I realize this story is about the ESP32-S3, but the OTHER board discussed in that article is way more intriguing to me.
Wait, wut? They've got an i.MX unit? Well now I'm super intrigued. I've posted about the difference between Microcontrollers and Microprocessors in my guides. But the i.MX series from NXP tries to toe the line inbetween the two categories. A Cortex M7 though is still solidly "Microcontroller" to me, but any i.MX will intrigue me because its specs are incredibly high for a uC (or incredibly low-power for a uP).
With regards to Arduino form factor... the size roughly compares to 3x AA NiMH cells or larger 18650 Li-ion cells. Its a good size for portable applications, though a bit larger than something you'd reliably put inside a pocket (big pockets can probably fit Arduino form factor + batteries though).
Adafruit themselves seem to be most interested in the Cosplay-electronics community, so something like this would be a wearable that you'd hide in your costume somewhere. (Ex: controlling the lights to an Overwatch costume or other "techie" video game costume that needs a lot of lights, fiber optics, and the like).
In any case: that's three boards with three different sets of capabilities: from the lowly RP2040, to ESP32-S3, to i.MX Cortex M7 "crossover" chip.