I'm not OP, but there's a lot of criticism of meshtastic from people knowledgable about mesh networks. I also have been critical of meshtastic on this site.
I have no experience with the community, but if they couldn't have been bothered with understanding AlohaNet from several decades previous, than maybe it's not surprising.
I myself have been fairly critical of meshtastic, you can probably search for bb88 and meshtastic to find more criticisms.
To save you some time, I live in a fairly populous city with a bunch of meshtastic nodes, and can't get a message accross from me to my friend who lives one hop away.
It's not clear to me which portions of that very long newsletter are responding specifically to Meshtastic, but it seems like the most relevant section starts by listing some challenges but offers nothing in the way of solutions except to digress into talking about a wildly different class of radio hardware (SDRs that can monitor many channels at once).
"Meshtastic Is Rediscovering Lessons (Already Learned) of Amateur Radio Data Networking"
Instead of actually trying to understand the arguments these days, it's easier to inject noise into the argument, proclaiming it's too "hard to find" or "too hard to understand."
Mesh networking is a hard topic. Expect to expend some brain cells to understand it. I'm not here to spoon feed you tech that was well understood 3 decades ago.
How about you make an actual argument here in this thread, instead of vaguely gesturing at an excessively long newsletter and claiming there's relevant substance in there somewhere? Or at least tell me if I've incorrectly interpreted the "Meshtastic Is Rediscovering Lessons (Already Learned) of Amateur Radio Data Networking" section as listing problems but no solutions aside from buying a radically different (more expensive and power-hungry) type of radio?
Try making some specific suggestions for what Meshtastic is doing wrong that could be done differently. That way, we can tell whether your beef is with the Meshtastic software and protocol, or with their choice of LoRa radio hardware, or if you're just trying to preach about your ideal mesh network design with unstated assumptions about the priorities and constraints of such a network.
FWIW I have some background in this area and got curious how Meshtastic works so I read some of the docs and code. It seems like they are unaware of existing work even 20+ years ago, a specific suggestion is to study the state of single radio CSMA meshes in say 2005 and make a list of subjects to read on, then do that. There's a lot of stuff that happened later but in the early 2000s many people tried to make meshes out of 802.11b IBSS and a lot got written about those efforts.
having read that meshtastic section: I mostly agree with their requests tbh. the only suggestions in there seem to be "use full duplex" (with approximately one reason why, though it's a good one) and "solve frequency discovery with SDR" which they've already addressed as somewhat ridiculous - because it is, for someone interested in a low power and low cost network.
particularly the SDR stuff, which is the VAST majority of that section. this is not at all the same target audience as meshtastic:
>A computer with “sufficient” compute power and RAM, to run the ka9q-radio software. KA9Q has stated that a Raspberry Pi 4 is sufficient, and now we have the Raspberry Pi 5 with up to 16 GB of RAM, for only $120.
that's like suggesting the way to fix a wireless problem is to use a wire. otherwise the criticism seems to summarize as "it's slow and bad" and well. okay? that's hardly constructive, whether or not it's accurate.
the whole thing reads like "the solution is left as an exercise to the reader ;)" because it sounds like it's written by and for people who are already experts and just want to read a cathartic list of flaws they already know. and/or "buy better hardware lol". it's not at all the logical slam-dunk that you seem to think it is.
Meshtastic can only use one frequency at a time. So, say, a battery status update can stomp on a message trying to get to a meshtastic router. (He's got the link to the hidden node problem with a great wikipedia article about it).
The more popular the network, the more frequent these message stomps happen. Flood routing makes these stomps more frequent.
There is also no end to end packet acknowledgement system like tcp, so at hop 3 (e.g.) if the message got stomped on, who would know?
Let's say someone made a dual band lora transceiver. Well that would help, but it wouldn't solve anything else, because there's still core routing/reliability/topology issues.
So if you had 20 channels to talk over, well that would be even better. The chance of having your message stomped on would go down significantly making the network much more reliable. That's the SDR part (the listening of 20 channels at once) vs the Lora chip which can only listen/transmit on 1 channel at once.
Edited to add:
"But that's super expensive hardware/engineering to do that!" you might say. Well, it's being done today.
The point is that if you can fit 20 1khz channels in a 20khz RF space. The 20khz RF can be converted into audio and fed into a soundcard and processed. This exists today with FT-8, though FT-8 uses 150hz bandwidth per stream in 2.8khz sections per band.
You can see some FT-8 activity by looking at some websdrs.
Maybe go here and tune to 14.074Mhz Upper Side Band (USB)
I still don't see how your suggestions amount to anything other than telling people to spend a lot more money on completely different hardware and use it in a completely different manner.
FT-8 doesn't seem usefully relevant here. The fact that the bandwidth is so low that it can be sampled with a sound card isn't at all helpful when Meshtastic doesn't require a PC. And FT-8 carries minimal payload (typically amounting to no more than the automated status updates you dislike Meshtastic wasting airtime on), and I've never heard of anyone doing routing over FT-8. You're just making noise about a completely unrelated niche radio hobby.
If the constraints of LoRa and Meshtastic don't make it possible to implement the kind of radio system you want to play with, that doesn't prove that Meshtastic has made any wrong decisions. It just says you would get a more fulfilling experience from getting into a different radio hobby, and stop getting in the way of potentially productive discussions about how Meshtastic could be improved within the constraints of the currently-existing commodity hardware.
> FT-8 doesn't seem usefully relevant here. The fact that the bandwidth is so low that it can be sampled with a sound card isn't at all helpful when Meshtastic doesn't require a PC.
This is what I meant about adding noise to the argument. This isn't a useful argument. FT8 could be decoded with a microcontroller. But you wouldn't know that. And it only shows your ignorance of the subject.
Meshtastic maximalists are the true believers, throwing away the decades of experience and knowledge because they drank the kool-aid of the leaders that think they are smarter than the folks who have been doing this for the last 40 years.
Why does this pattern come up so often? Something is promoted ignoring the lessons of the past and claiming not to have those problems, then it's discovered that it does have those problems and that ostriching didn't solve them (surprise) and that ostriching made it even worse than if they'd left a TODO placeholder
There is some issues with "boomers" and "toxic culture". Ham radio can be pretty toxic -- but you have to find the groups that have the knowledge but don't have the toxicity. There is a stigma to being a Ham these days -- often well deserved I think. You can find lots of youtube videos of toxic hams on the air. Or you know facebook forums.
But those people aren't the experts typically. The experts have their own community, friendships, etc. They'll be super nice, and they might speak up, but they expect to have polite conversation. And if the forum is a shit show, they'll take their expertise elsewhere.
The message would be 20 times longer (in time), increasing its chance of collision by 20 times and exactly cancelling the 20 times reduction that it gets from randomly selecting one of 20 channels.
But that's also true on 1 channel. Doesn't solve the hidden node problem. You have 1/20 as much risk of starting to transmit at the same time on the same channel as someone else, after you both determined the channel was clear, since that's a race condition with a fixed time window per transmission, but is that the main cause of collisions?
Here's a thought experiment. Remember, there's only one channel.
Let's say you have 100 meshtastic nodes in a residential valley. And you have 1 meshtastic repeater up on a mountain overlooking the valley (or it could be on a radio tower or water tower, say).
So it's clear that most of these nodes won't see each other because terrain, housing, trees, etc.
But it is possible that the repeater may have clear line of sight to most of them. And that's where the hidden node problem lies.
And adding more nodes and more repeaters is not going to help. The problem is either solved by increasing the number of channels (hence the sdr angle) or by time division multiplexing the single channel and coordinating who can talk at what time. The first is easy. The second is much harder.
yeah, that's exactly what I was referring to as "use full duplex" (use at least 2 frequencies, I agree this sounds like pretty solid critique (particularly with meshcore's network setup) and wouldn't make hardware dramatically more expensive) and "buy better hardware lol" (use 20+ frequencies and make it a completely different product at a MASSIVE price increase. why not just suggest wires then).
so there's one bit of probably-usable advice (slightly raise cost for significant benefits) and one that completely misses the point (charge at least 5-10x more for wildly different hardware, use hundreds of times more power, etc). the article spends several times more text on the latter.
flood routing and lack of end to end ack I also agree with, I sincerely doubt those are the best options and if user complaints are any sign then I think it's an existence proof that it doesn't scale, exactly as predicted. neither are part of that article, though it is in a linked also-large mastodon thread, which has basically just one constructive suggestion (8x the channels, though they don't think it'll work either) and many "this sucks" examples (flood fill, hop limit, etc. it amounts to "do better", not "X is better, learn from it").
> charge at least 5-10x more for wildly different hardware, use hundreds of times more power, etc
So I think what's super interesting is that it not necessarily need to be 5-10x more, nor needs hundreds of times more power.
I'll start with the power argument first.
WSPR (pronounced "whisper") often uses 100mW transmissions and can be heard across the globe in the HF spectrum. The techniques for reception can pull the signal out of the noise. It's common for weather balloons to send telemetry this way. People use it to monitor band conditions as well.
The trick is that WSPR puts all the power into one signal approximately 6hz wide. That's why it's so efficient, and one reason why it can be heard across the globe with such low power. Now you're probably not going to get that distance in the 900Mhz ISM band, but you will be heard further if you so choose (or need to be).
As per cost?
100mW assuming a 75ohm antenna (dipole) is 36mA of current. For 1W (which is roughly the ISM limit) it's 115mA of current, so the components won't need to be high power, probably jelly bean parts.
The RTLSDR is $25 bucks with 2.4Mhz bandwidth which is way overkill for this.
Lots of microcontrollers are cheap.
There's engineering cost and time, sure, but Meshtastic did show that a need for reliable mesh low power messaging exists even if it's not the final form.
I've been spending a lot of time experimenting with and learning about Meshtastic and MeshCore recently,[0] and I'm also puzzled by the criticism of Meshtastic.
In the article you linked, there are three paragraphs about Meshtastic in a 150-paragraph newsletter about several topics. The criticism seems to be that they they use digipeating, and then it refers to a Fedi thread[1] which is more coherent but still fairly vague. The upshot seems to be that flood routing doesn't scale, which is a fair criticism but feels disproportionate to the level of vitriol against the project.
The Fedi thread also adds that the Meshtastic founders were rude or unprofessional to him but doesn't cite any specifics or evidence.
I see this a lot with Meshtastic. People keep saying the founders are toxic and disrespectful of the community but it's always in these vague terms so I don't know what's driving it.
But specifically in this thread, I agree with sibling poster that you're being disrespectful and arguing ineffectively by pointing to such poor resources and then blaming other people for being unconvinced or confused.
As I understand it, the section on "what not to do" features many things that Meshtastic does, though it does not say that explicitly. Perhaps the linked post wasn't clear to non hams (it is a newsletter targeted at hams), but the biggest issue is not flood routing, but using the same channel for networking and user access. It, by definition, cannot scale meaningfully. Many commercial networks solve this with either FDMA or TDMA.
Elsewhere in the newsletter, the author advocates for a form of FDMA, where users operate on different, dynamically allocated frequencies and all of them are received at once. P25 trunked radios used by almost all law enforcement in the US operate on a system like this.
I think the vitriol from those who are in the space either professionally or as an amateur comes from the fact Meshtastic is repeating mistakes we knew about in the 80s at the latest, for which reams if literature freely exists.
That's a reasonable take to an extent, but underlying all of that is the assumption that Meshtastic should be trying to scale up to support hundreds or thousands of active nodes on a single mesh. Since that's clearly almost impossible to achieve with an ad-hoc network of low-power LoRa radios, it's not entirely fair to criticize Meshtastic for not inventing a revolutionary solution to a very hard problem.
It would be more fair to criticize Meshtastic for not being clear enough about the tradeoffs and limitations inherent in a low-speed ad-hoc mesh network, and for not actively encouraging people to seek other hardware and software if their use cases are not well-matched to what Meshtastic hardware is capable of. A one size fits all solution simply isn't possible, and Meshtastic can't be the right answer for everyone.
This is also a fair response, however I'd argue that the current architecture, far from supporting hundreds or thousands, won't even support dozens in a small area with meaningful traffic being exchanged (e.g., not just heartbeats and routing data). The solutions exist and no revolutionary approach is needed. That's the crux of the complaints.
Now, for the hobbyist these solutions are harder to implement and that's not nothing, but I don't even see a movement to switch over to something more robust.
> Now, for the hobbyist these solutions are harder to implement and that's not nothing,
I'd argue it's everything. A network architecture that requires serious fixed infrastructure should probably be an entirely separate project from the ad-hoc mesh formed solely by cheap battery-powered portable/handheld gadgets. And everyone should be realistic about what "meaningful traffic" is for a network with a default data rate of ~1kbps; it's not reasonable to expect that to support the kind of chatter a busy IRC server would see.
Have YOU ever tried interacting with the developers? No?
* They made incredibly poorly designed software — the firmware and the mobile apps — and then yell at you for “using it wrong”
* The refuse to admit they made a mistake with the 7 hop limit and call you an idiot for not believing in their garbage “simulator”
* They write nasty responses to app reviews and GitHub issues because they’re petulant children. Just go read the responses, and look at the hissyfit the of the primary app developer in discord.
* They’ve taken down multiple community groups because they decided they needed to be a business rather than an open-source project. Seriously just go look at the history in their discord #trademark channel. They’re on the verge of evil.
All this stuff is available and just because YOU choose to put your head in the sand doesn’t mean it didn’t happen.
While it looks like Meshtastic devs probably made at least some mistakes relating to that underlying complaint, I think that thread provides thorough evidence that banning that particular user was a reasonable choice.
He went off the rails as a reactionary move is how I see it. He got mad because his issue was deleted. I'm banned from the discord for a disagreement with one of the developers; but I've done code contributions to the project as well.
Even without toxicity, as a domain expert, I'm cynical about community experiments in this space in general.
Hobbyist "mesh networking" communities readily adopt suboptimal modulation, frame specification, packet format, encoding, ineffective mesh arrangements, flood-prone routing mechanisms, poor reference hardware, and bloated user interfaces, while often ignoring basic practices like forward error correction, collision detection/multiplexing, trust mechanisms. Community solutions tend to be opinionated in the worst ways ("we assumed you'd use an arduino" or "here's a mandatory packet header field to indicate whether you're currently in a hot air balloon") and under-constrained in areas where opinion would be helpful "our client UI has 75 configurable options -- get one wrong and you won't be able to communicate."
By the time there is a "community" it's too late to address these issues: network effects have already locked in the worst design decisions.
Looking back, funnily the top comment drew a parallel to negotiating USB-PD in u-boot, aka the bootloader. I suppose this wouldn’t have worked for your case though, since your device couldn’t boot at all on 5V.
Valetudo. I haven’t had personal experience using it (due to an unsupported model of NAND memory chip), but I’ve heard good words: https://valetudo.cloud/
That said, I did some research last year before buying my first robot vacuum. I wasn’t able to find a project - Valetudo included - that would support the bigger, fancier robots made by Roborock etc. If you’re looking to decloud a recent model, I don’t have a good answer.
Is it necessary to prevent the water from freezing? If the chamber and water within are subzero while the SoC produces sufficient heat, the ice would simply melt.
* Edit: the article mentioned freezing could crack the seal. Freezing would be a bigger issue than I had thought, then.
I remember being stuck on a ski lift on a day that was too cold and windy for any intelligent person to be skiing. The phone in my breast pocket was cold to the touch and the battery capacity evaporated by 50%. The display's response time was hundreds of ms. I turned it off at that point.
Not a huge deal. Just charge it when it's warmer. I would have been a little surprised if something inside popped and suddenly the phone started thermal throttling or had water damage.
In my city, temperatures are regularly below -20 Celsius and sometimes below -40. iPhone just doesn't work. You need to keep it close to body and you can't use it outside for a prolonged period of time, it'll simply shut off in a few minutes and won't turn on until you heat it.
Old phones and some android phones work just fine in these conditions.
I applaud his efforts to document this what must’ve been a nightmare of a case for him. But it felt like a lot of the wording is speculative or hyperbolic in nature and aggressively tries to paint Volvo in a bad light. For example:
“Analysis of Volvo's Final Response: This response … confirms Volvo's complete abandonment of customer responsibility…This is Volvo's definition of ‘customer care’ in 2025.”
“Center Display Failure - Critical Interface Blackout: Main Controls Inaccessible”
“Climate Control Malfunction - Climate System Override: Controls Unresponsive Despite Interface Status”
“Complete Center Screen Malfunction - Total System Breakdown: Hard Reset Failed to Restore Screen”
I know little about Volvo or this case; I’m choosing to offer them some benefits of doubt. Comms and decision making are prone to break down on the corporate ladder. Volvo had no doubt fumbled his case badly but I’m not convinced it is indicative of the company’s overall customer support policy. Sure, the main touchscreen had failed. But how is this an “override” of HVAC or a “total system breakdown”? And what’s the “system” anyways? On top of all that, these subtitle summaries smell like AI.
I don’t deny that Volvo has a lot to answer for. Though the choice of these instigating descriptions might not be the best one giving the author is actively pursuing litigation.
> But it felt like a lot of the wording is speculative or hyperbolic in nature and aggressively tries to paint Volvo in a bad light. For example:
Part of it is that he clearly used ChatGPT or Claude to write the prose. (I really should not have to explain how, despite not reading the OP at all, your example quote alone establishes that. You see this kind of hyperbolic unordered list/checklist all the time now. This seems like more of a Claude tic, but could also be ChatGPT due to sheer base rates.)
Being sycophantic and ordered to write polemic, a LLM'll go overboard.
I don't think I'd spend 150k for a car, I imagine it would create a certain sense of entitlement, but he does sound pretty annoying.
It's just an order mess-up, but opening with stuff like: "Sent a formal complaint to Volvo Canada on January 16, requesting escalation to Managing Director Matt Girgis. Volvo Canada never confirmed this escalation." is a vibe.
He puts down a deposit, and waits almost a year, then experiences multiple delays. He seems to be experiencing multiple issues before he requests escalation. I don't think he opens with escalation request in a second email. His vibe seems to be of someone being ignored and just told to deal with it, and not willing to just accept something less than the original agreement.
What would be a "better" vibe than requesting an escalation? if you buy something and you don't get something you've bought? Just say "oh well, it is what it is"?
Ordering a custom car build from a factory is an experience. These sorts of delays are not uncommon, and there just isn't much anything the US or Canadian divisions can do about it most of the time.
That's for basically what amounts to supercars. I imagine a normal luxury car for the "mass market" like the EX90 is going to get even less attention.
For someone not used to it, I can see it being quite frustrating if their dealer is not totally up-front about what an allocation and build timeframe actually means.
A deposit is really not anything more than giving the dealer a bit of assurance that you will actually buy the car they burned their allocation slot on when it arrives - vs. them using it for a more standard common build that has a wider market for it. You are under no obligation to buy the hot pink on light blue custom color options you ordered should it arrive and you decide it looks horrible, for example.
It's a strange weird scene. I followed this on various car forums when I was planning on ordering a custom spec for my "dream car" a while back, but decided to just get something not quite optioned how I'd like it off the lot instead.
> there just isn't much anything the US or Canadian divisions can do about it most of the time
This sort of thinking about the internals of the business isn't necessary. They're paid to be there; they need to manage their suppliers, internal or external.
Having a very expensive car just randomly roll to a stop on a highway is a "vibe", too. More of a vibe than anything we might reasonably claim to be picking up from this guy, I would opine.
Eh the author is coming from a place of emotion (considering the effort put into the website) so I would definitely cut them some slack on the fairness of their reporting. The owner is telling their story, not a journalist.
> But how is this an “override” of HVAC or a “total system breakdown”?
Complete failure of the throttle would fall within total system breakdown to me.
> Comms and decision making are prone to break down on the corporate ladder.
Businesses do not deserve the benefit of the doubt, they aren't human. If their support ladder broke down to this point that it is fair game to name and shame and up to them to do a PR push and fix their support.
Referring to GP, is there any other type of HN comment than one that completely ignores the human emotion, instead wanting to focus purely on technical and specific pedantry?
They have cars these days that put essential climate, infotainment, and other controls being a screen. This could be a lot worse than just a false positive check engine light.
In Tesla's speed and "engine" warning lights are on screen. IMO it's not really critical, given you can reboot the screen while driving. There aren't any "controls" on screen, idk what you are waffling about.
A lot of the language and wording on this site it’s not actually the author’s - most of it is AI-generated. The “analysis of”, which is actually longer than the letter it analyzes, is a glaring example.
Before I came across this tool, one use case I’d conceived for a tool like this is to help in debugging and reverse engineering. One could hook this up to a microcontroller under test/analysis and essentially monitor its “disk I/O” or supply it with arbitrary data.
Files looks great but it has performance issues and occasional crashes when I tried it out a few months ago. When going into subfolders, there is a very noticeable subsecond lag which I don’t get from native Explorer. For all complaints of lack of features that Windows File Explorer gets, it’s still a very respectable native GUI app for being Windows’ most used program!
It's usable most of the time until it isn't. Far to often I wonder what they were thinking making things. Say, where is the recycle bin? If I could switch to the windows 95 explorer I would do it immediately.
yeah honestly files was such a disappointment for me. Modern i5 from 2 years ago desktop system on windows 11 and it would crash every 2-3 days just browsing with at most <15 tabs open.
Was it coded in electron? What's filepilot made in?
I think college student teams strike a combo of time, talent and resource that would be surprisingly hard to come by in the larger “civilian world.” In college, you have a bunch of freshly educated, similarly minded people in one place with a whole bunch of free time to put towards one project, highly motivated because it’s both an extracurricular escape and a career prep achievement. And these teams are often financially supported by their school departments or fundraisers. If you fail, there are little if any consequences on your life. All these motivators improve the likelihood of making something truly impressive.
Sure, we can make an arrangement like this out of college. Call up your ex-rocket club teammates, who have all now graduated and making banks at rocket startups. Spend the Thanksgiving week grinding out the CAD, code and circuit boards then test everything out in a desert. But projects like this are a huge time investment and with work and family in the way, they can often be very difficult to coordinate and pull off.
Even if your rocket does end up shooting off and breaking a record, does it truly “beat them”? I find it a bit hard to compare a team of similarly educated college students to a group of adults, usually with relevant professional backgrounds. Maybe the closest we can get are YouTuber collabs. Sometimes I miss my days spent on my college team; it’s pretty hard for me to get an exciting, rewarding, comradely and occasionally traumatizing experience like that ever again.
> I think college student teams strike a combo of time, talent and resource that would be surprisingly hard to come by in the larger “civilian world.”
The flip-side of this that you have a bunch of very smart young people absolutely dripping with theory knowledge and close to zero relevant real world experience in anything applicable in this space. The ability of college university teams to make exceptionally bone headed f ups is very well known. I've mentored a couple of university rocket teams for over 5 years now and I can tell you it's often an exercise in 'unknown unknowns'.
USC RPL has been at this for almost 20 years now. Their main competitive advantage (besides in-house cf cased motors) is documentation and knowledge transfer. As I'm sure you can imagine there are probably no founding team members actively involved today. I was at Balls in 2013 (IIRC it was 13) when they launched their first Traveler rocket, which was their first space shot attempt. They didn't actually reach that goal until April 2019.
I used to be part of a very successful competitive robotics team. You'll be surprised at how many student teams have this one guy who has been doing his PhD forever/startup founder who spun off from your team and mentors it that exist in the more successful teams.
I've seen PhDs whove mastered the art of being in the same uni team. One of them I knew has followed the path from undergrad (4 years), masters (2 years), RA (2 years), Phd (7 years), Post-doc (2 years).
Another is a startup founder who started the team in undergrad, worked as an RA for 4 years, then spun-off his own company over the next 6 years.
For the most part its beneficial for the uni to retain such talent. Especially, cause they are better grounded than some of the professors who claim to be "experts".
Unless they turn faculty I kinda doubt it. Not to sully your robot team, but I expect many of these students to want to progress to bigger and better things in the commercial space launch sector which they can't do at USC. Also, money.
Founded in 2005. They probably have a very strong Knowledge transfer system and alumni network in place (useful for funding). This is something I can attest to when I go back to my college days.
> you have a bunch of very smart young people absolutely dripping with theory knowledge and close to zero relevant real world experience
For sure! And that’s perhaps the #1 reason these teams are so valuable: it’s an environment to get hands dirty in. If something sticks, that’s great and goes on the resume. If something awful happens, just walk away with a cool story assuming you didn’t blow up a school building or anything like that. Either way the experience and hopefully learnings stick with these young people like me for a long time.
Somewhat but it's still such a wealthy student body that if everyone in the photo was from a family worth millions that would not even be a very unlikely statistical anomaly.
The biggest issue with college teams is that there is no institutional knowledge retention. Once they are done padding their resumes, they will move on. The next batch of club members will usually reinvent the wheel again. There is little incentive for good management and long term innovation beyond proving out one or two ideas that are immediately relevant to their academic research.
This is so frustrating to me. I was involved in a cyber security club that just started in my university. Both complete incentive misalignment and lack of focus. In the first committee meeting I was excited and pitched a plan to go from "zero to one", setting up training curriculums, building talent pipelines (esp from year 1s) from the student populace to us, institutional knowledge retention to keep and grow knowledge, getting mentors/research links with professors etc. After drawing everything on a white board, I turned around to find a glassy eyed committee. Every single one said "nah, let's just meet every week and uh, talk about a ctf or something". The president looked around and agreed with them. Over the semester I realized the president was far more interested in going to events and introducing himself as president than actually having any impact. As I predicted at the start, the initial hype and momentum gave way to lethargy and indifference. Participation from both non members and members fell off a cliff.
I think we can see that this isn’t true in this case. They are building on successful work from 2019’s record setting attempt, implying plenty of continuity. And these are undergrads so they are not generally doing heavy research. They are likely well advised.
If a 21 century rocketry group takes 20 years to reach the Karman line, college students or not, they are the definition of incompetent. Maybe they should all get internships at the United Launch Alliance; good for lapping out of the gravy train and not much else.
Making it graded tends to F it up bigtime. You waste soooo much time doing overkill process for the sake of proving that you can to get the grade. CAD models will be made. Simulations will be run. Powerpoints will be made to convey the results. When in reality all you needed was one dude to spend two hours prototyping both so that they could be evaluated and the more viable path of development chosen.
Heh, grades served as a good barometer for me to know how much effort I needed to put into the boring classes to pass them. My transcript is a nightmare, high 50s and low 60s in the "easy classes", high 90s in the hard/interesting classes. And then a bunch of really fun/challenging extracurricular stuff that used to get a line or two on my resume when I was a fresh grad.
Thank goodness that the only employer to have ever cared was one where many of my extracurricular friends already worked and vouched for me. The only other time my transcript has actually mattered was when I went back to grad school; my overall average was about 2% too low for the good funding and I had to spend a semester working a lot of hours at the undergrad homework help desk until my first semester MSc. grades came in and qualified me for a significantly better stipend with less hours spent on other people's homework.
With an ESP32 or comparable (RPi Pico W, for example) you get MicroPython or CircuitPython support! That means a Python interpreter, drivers for popular peripherals and usually a network stack. Performance doesn’t beat a native SDK but Python is Python.
