|
Klyith posted:My favorite thing about psychoacoustics and all this stuff is when you realize just how amazingly crap and easy to fool our sense of hearing is. Early human evolution definitely put a priority on sight & touch, and I get the feeling any time evolution asked "how do we get more brain space for all this visual cortex?" the answer was "gently caress ears". And then we cannibalized like half of the auditory area for speech. That's not true! Humans have much, much better directional hearing perception than almost any other animals. Top scores go to humans, elephants, and barn owls. Humans are incredibly amazing at localizing sounds. You know how someone could throw their keys, and you'd immediately know where they landed from the sound? Most animals can't do that. In a carefully controlled lab setting, humans can locate the source of a sound within 1 degree. Cats and dogs can only locate sounds to like 30 degrees. They can swivel their ears around, and they can hear quiet (and ultrasonic) sounds, but they aren't actually that good at perceiving sound direction.
|
#
¿
Mar 30, 2021 08:15
|
|
|
|
| # ¿ May 29, 2024 05:55 |
|
|
Yeah, they created a new USB-C PD 5V/250MA profile for it.
|
|
#
¿
Apr 6, 2024 20:24
|
|
|
Zero-size SBCs with not-Broadcom wifi? I'm looking for something in a RPi Zero form factor, with a well-supported wifi chip and a U.FL or SMA connector for an external antenna. The RPi Zero 2 W fails on both these grounds, so I'm not that excited about using it. Are there boards from other companies that are similar size, with non-Broadcom wifi? I don't need good range or throughput on the wifi, I just need the connector so I can get the antenna outside the metal enclosure. I would like to run OpenWRT (even though this won't be running as an AP).
|
|
#
¿
Apr 9, 2024 17:48
|
|
|
OK, both those appear to use the AP6212 wifi module, which I think has Broadcom guts. But hearing that they really do work on an open source OS like OpenWRT is good news. That opens up a lot of not-RPi boards for me to look at. Thanks!
|
|
#
¿
Apr 9, 2024 18:27
|
|
|
Oh! I hadn't seen that site before. It looks useful.
|
|
#
¿
Apr 10, 2024 03:33
|
|
|
Dylan16807 posted:It needs its power supply to explicitly offer that profile by default, which as far as I'm aware roughly nothing does. Allow me to direct your attention to the official Raspberry Pi USB power supply, now available for you to buy. This is the 3rd official Raspberry Pi brand USB power supply released by the Foundation. Collect all three!
|
|
#
¿
Apr 13, 2024 23:28
|
|
|
|
| # ¿ May 29, 2024 05:55 |
|
|
You should be able to setup the Arduino so a user on the RPi can type: $ cat /dev/ttyserial999 And on the Arduino, you can see the connection open when (bool)Serial == true, then you printf your info and close the connection so cat gets EOF. I think this involves stty on the RPi. Check out stty hupcl and eof. Hupcl is needed for the Arduino to know if someone has the device file open. And I think stty eof is how you tell the tty driver to treat ctrl-d as EOF and make read(2) return zero bytes. You can make any character the EOF char, like a null byte or whatever. Make your 'protocol' text-based and line-oriented, then hand off all the open/close logic to the tty driver. There are thousands of weirdo terminals in the history of computing, and unix tty drivers have cruft for dealing with most of them. Beacuase of this, the tty drivers are very configurable. One time, I used the tty driver to greatly improve the performance of a USB enviromental sensor thing. The old code was reading a char at a time, unbuffered with short timeouts, in hopes to read data and send replies inside some USB turn-around time. I don't remember the details, but it was something like needing to process it in the same 1 ms tick? Or else you'd miss your slot until some later time and latency and throughput go to poo poo? Something like that. The trick was configuring the tty driver to 'understand' the protocol, which didn't require any changes to the text-based protocol at all. Just needed to set the right options with stty. And once the tty driver understood what character meant line end, and when to buffer, it was lightning fast. This is because the character processing and buffer logic was now running in the kernel, and userspace was presented the complete records, rather than loving around char-by-char. Running in the kernel, the tty driver hit the 1ms window every time. tldr: Lean on stty and the tty driver. It is very flexible, and if you use it right, a lot of convenient UNIX-y details will work right. ryanrs fucked around with this message at 04:47 on May 24, 2024 |
|
#
¿
May 24, 2024 02:20
|
|