xyx0826

I hate how it’s heavily marketed as a “challenge” and a “learning opportunity” when it’s a clear attempt to crowdsource for-profit IP geolocation data. There’s nothing challenging about running around collecting data for free, neither is there much to be learned.

The “challenge” has been on for 7 days. The stats say there are 1,779,796 IPs collected by 221 participants. That means on average each of these participants had to submit 1,150 IP location pairs, per day. How is that even possible?

For those not in embedded: the SO (not S0) pin is commonly called MISO (Master In Slave Out) in a SPI bus; it is the pin on which the SPI device (SPI flash) sends data to the controller (ethernet bridge). The CS (Chip Select) pin of the device, on the other hand, is supposed to be held at logic low during an entire SPI transaction. Tying a pin that should transition between high and low to a pin that should stay low would likely screw up the communication and make the ethernet bridge think a SPI flash is not there.

I thought the art of making wildly inconvenient UX assumptions on behalf of users had largely stayed in software, eg. websites doing “copied to clipboard!” completely unprovoked overwriting whatever you have kept in system clipboard. A few years ago I had a Realtek wifi adapter that would sometimes do this too on Windows though at least it didn’t try to hide the network device. It’s hilarious that this design trend has even found its way into silicon, though I suspect it’s rarer these days now.

Not a proxy but SoftEther VPN supports connection over DNS and/or ICMP. This is meant for circumventing firewalls.

https://www.softether.org/1-features/1._Ultimate_Powerful_VP...!)

Quite surprised to see UW materials on HN. I took the non-major equivalent of this course; it was an introduction to C, Bash, Linux, and assembly. It was quite helpful back then, although the web helped me expand on what I know as with most computer science topics.

I wish I could’ve taken the major version but, alas, I wasn’t offered a spot in UW’s CSE program despite all my passion and effort. I will refrain from turning this comment into a lament of the university’s capacity constrained major system.

Reddit was archived by PushShift, which was killed along the API changes. Nevertheless the archives remained online. https://the-eye.eu/redarcs/

Real time data is fed into an InfluxDB instance and shown on Grafana hosted on the ground station. This data is downsampled to cope with the volume of raw traffic. We also tried some solutions used by other teams like KX [0] but decided to go with a FOSS stack. A post processing pipeline converts original data to a however proprietary format used by AEMdata [1], a proprietary data analysis tool from our ECU vendor and used somewhat commonly in the racing scene.

[0]: https://code.kx.com/dashboards/

[1]: https://www.aemelectronics.com/products/software-aemnet/aemd...

Sadly my team is pretty light on public tech blogs, but there are plenty of projects like this one! Copying from my comment above:

> The system is for a Formula SAE (FSAE) Electric style race car. FSAE is a collegiate competition, and I'm part of a US Pacific Northwest team. Our car uses a 550 V battery and is 4WD. Most of our electronics and firmware/software are in-house besides motors and inverters. I lead the telemetry project and work with 1-2 other members on the system.

> The system consists of an on-vehicle computer (Raspberry Pi or NXP i.MX) and a ground station (Rockchip RK3588S). We use Python heavily and the real-time dashboard part is done with InfluxDB and Grafana. Both computers and any user devices are on a Wi-Fi network made with a long-range WISP access point.

> Our team is unfortunately very light on public tech blogs and how I wished I can change that... There is plenty of information on FSAE electric cars, vehicle telemetry, and both on the internet and they were a source of inspiration as I designed my own solution.

The system is for a Formula SAE (FSAE) Electric style race car. FSAE is a collegiate competition, and I'm part of a US Pacific Northwest team. Our car uses a 550 V battery and is 4WD. Most of our electronics and firmware/software are in-house besides motors and inverters. I lead the telemetry project and work with 1-2 other members on the system.

The system consists of an on-vehicle computer (Raspberry Pi or NXP i.MX) and a ground station (Rockchip RK3588S). We use Python heavily and the real-time dashboard part is done with InfluxDB and Grafana. Both computers and any user devices are on a Wi-Fi network made with a long-range WISP access point.

Our team is unfortunately very light on public tech blogs and how I wished I can change that... There is plenty of information on FSAE electric cars, vehicle telemetry, and both on the internet and they were a source of inspiration as I designed my own solution.

There are a lot of SQLite praises in this thread, on the internet and on SQLite's website so here are a couple of reasons that drove me to choose it. My experience with traditional formats like CSV or raw binary is that they have a somewhat lower overhead to "get working" but are quite difficult to scale and adapt to changing needs, a phase most projects are bound to go through.

SQLite's reputation and adoption makes me comfortable to assume its operational correctness so I can focus on data itself, not reader/writer logics for it. Even though a SQLite database's schema may change, I'm glad knowing that the database file can still be easily opened and read many years into the future, something that custom formats may not guarantee.

On CSV: Syntax and library differences aside, SQLite almost works like a drop-in replacement for CSV since a single table database can be essentially treated as a glorified spreadsheet/CSV if wished. My post processing data pipeline is built with pandas so it is virtually the same for me to read a SQLite database vs. a CSV file.

All that and more! Sensors like shock potentiometers, strain gauges, temperatures from all over the car, IMU readings ([ag][xyz]), and electrical measurements like HV/LV voltage, current, power, energy, as well as controls like motor commands and speeds, controller states, etc.

Lots of folks put work into a car and they all have metrics of interest to tell how their systems perform. An ideal telemetry system for us captures all this information and makes it available both in real time and analysis.

Precisely so! There are two CAN buses and one UART port to log from, and the Python code spawns subprocesses for each of them. They each create or open a SQLite database named after their bus/port and get to work.

This setup is easy to put together but might not be optimal. I don't have a lot of experience with SQLite performance tuning, and I wonder if it will be faster to have worker threads pass everything thru IPC to a writer thread, which batches rows and writes to a centralized database.

I'm not familiar with HDF5 but agree on resiliency. We are a collegiate racing team and our car's power rails aren't stable and redundant at all times, so power loss failure is something I've kept in mind from day one on my telemetry project. SQLite is generally equipped to handle power losses and write thread crashes:

> An SQLite database is highly resistant to corruption. If an application crash, or an operating-system crash, or even a power failure occurs in the middle of a transaction...

Quite often after a run the entire car is turned off and, on next power up, the databases are left as .db and .db-journal files. The code has no problem processing or even continuing on logging with DBs in this state.

The onboard code processes binary data: CAN bus messages and alike, along with their nonbinary metadata. The first version of the code used CSV because they are so trivial to read and write, but CSV as a text format required me to either hex or base64 the bytes which incurred a non-trivial waste of time and space. For a custom binary record I would need to write custom (de)serializers, which I wasn't willing to do given frequent changes in types of data I need to record during development.

SQLite is the only solution for me so far that provides a structured data store for mixed data types, is power loss safe (important to an embedded system,) and is a high-quality and portable industry standard. Let along the SQL language itself, which has proved to be hugely useful for first-pass post processing given the amount of data that I ingest.

Perhaps there are other technology that will work just as well or better: maybe Protocol Buffers and alike? Yet SQLite currently ticks all my boxes and I'm quite happy with it.

I extensively used SQLite in a telemetry system for an electric race car. The car has an onboard computer, first a Raspberry Pi then a dual core Arm processor. Onboard code logs ~4000 messages a second into three SQLite databases. After a drive session a script merges the three databases into a single SQLite session log. The session log is decoded on a different computer to ~400 columns of time series data again stored in SQLite. This data is then finally converted into a proprietary format for visual analysis.

Prior to SQLite I tried CSV files and raw binary formats. None of them could match the flexibility, ease of use, and throughput of SQLite. My setup has been in use for several weeks now and has processed numerous rows of data. As the SQLite project outlines on its website:

> SQLite does not compete with client/server databases. SQLite competes with fopen().

Hardware Design with RP2040 [0].

An official guide on integrating the Raspberry Pi RP2040 microcontroller into one’s own circuit design. Essentially a series of worked examples that touch on pretty much every hardware feature of the chip, with a good amount of advice transferable to other microcontrollers. Provides steps and justifications. The RP2040 datasheet is equally fantastic: straightforward wording, minimum abuse of passive voice commonly seen in microcontroller literature, and accompanying C/asm examples.

[0]: https://datasheets.raspberrypi.com/rp2040/hardware-design-wi...

Very interesting to hear about CircuitPython being used in the industry. I had thought it’s largely a hobbyist/ prototyping framework much like its upstream MicroPython. Out of curiosity, does your team implement all logics and math in Python, or is it a mix of C/Python? Has the platform posed any memory management challenges?

The chickens died from heatstroke due to ventilation computer malfunctioning. They weren’t actually “boiled” alive, i.e. in water.

So there was an alarm for barn temperature but not for the ventilation system itself? I can’t think of any industrial system that doesn’t raise an alarm upon failure.

An attacker gained administrator access to the forum in question. The admin changed passwords and continued to observe more password bruteforcing attempts from the attacker.

The attempts were made to the forum's mobile login endpoint using different IP addresses from a proxy pool. Strangely the attacker would rotate the username once or twice every hour but stick to the same password, x4ivygA51F. The admin later modified the forum software to hash the plaintext password locally before sending it to the server, and the attacks promptly stopped. First of all, I don't think the admin realized validating a hash from the client without hashing it twice would actually make security worse.

From what I can tell, this is largely Discuz's login flow:

- Server has `sitekey` and `authkey`; they are unique and permanent for each Discuz site

- Generate `formhash = md5(timestamp_days / 115, user_id, sitekey)` and embed in HTML

- Client POSTs username and password with `formhash`

- Server validates

- Server generates `discuz_auth_key = md5(authkey, user_agent)` which is used to encrypt user ID and password

- Server hands out `auth` cookie with the encrypted string

The cookie is used on subsequent visits to authenticate. My guess is the attacker created throwaway accounts on the forum to perform a known-plaintext attack on the forum's sitekey and authkey.

> Having your power connector come loose on a vibrating machine or having your SD card die is a serious problem when you're trying to use a machine to make money reliably and consistently.

Hah, I’d never thought of the power connector coming loose but I can see how it will be a real issue in an industrial environment, or on vehicles. I’ve also heard a lot of stories of the Pi’s SD card corrupting or dying, though I agree that actual products might use eMMC instead.

I think the Pi is better suited for less portable products like NAS, or TV boxes, although we already have popular inexpensive SoCs for those.

Raspberry Pis have commercial and industrial use cases so they can have pretty good reliability. There’s an official “for industry” page [1], and there are PLC products made with the Pi [2]. I’m curious on why do you think the Pi (including the Pi Compute Module)’s form factor make it unsuitable for consumer devices that need computing power a SBC offers?

[1]: https://www.raspberrypi.com/for-industry/

[2]: https://www.industrialshields.com/industrial-plc-raspberry-p...

Shucking means removing the HDDs from the enclosure to use them on PCs or servers. Un-shockable enclosures might have HDDs with proprietary electrical connection which makes standalone usage impossible.

Given that the Tempo codec works great as a feature parity replacement (which the Framework team anticipates), it’s quite likely they will stick with it.

The Tempo do lack the ALC’s smart features but they couldn’t get the latter to work anyway...

TL;DR: Framework is switching its audio codec from Realtek ALC295 to Tempo 92HD95B.

While I don’t own a Framework I welcome this change and find it quite interesting, partly because it seems like every laptop and PC maker these days are putting an ALC chip on their boards. You also don’t see computer companies announcing “we’re ditching chip X for chip Y” often and this is very informative transparency.

It feels like Realtek puts a lot of red tape around its chips. Most notably, it’s very hard to look up a datasheet for an ALC chip unless it’s a very popular part. Realtek also seem to only provide stock and support to their biggest customers like Dell and Gigabyte, because it sounds like Framework struggled to secure stock, probably from a one-off source, for their first batches and couldn’t get in touch with Realtek to implement the Smart DSP feature.

The Tempo chip on their other hand is much more open. The datasheet is right on the product page, and the chip has first-class Linux support. In the integrated sound card market where Realtek is to codec as Clorox is to bleach, I welcome attempts to diversify the market share.