Almost everything is state based behaviour.

On the other hand, if it is not, then stop wasting effort arguing against the inevitable and use that effort to get ahead of the curve.

Either way, whinging about it is the least effective use of your skills and time.

This usually results from an inadequate system-subsystem decomposition and/or not considering modes, both of which lead to hierarchal state machines instead of one big flat one.

This aspect of architecture is difficult to teach, it is one of the "black arts" that comes from experience and is difficult to codify.

Just one example why, is that often it might require the synthesis of state machines not directly evident as needed from the functionality, eg to perform a one to many or many to one functionality.

But we can short circuit that and consider in terms of distributed generation (mostly solar) and storage (batteries), see further down.

But the group website has no real information about real people involved, it's best information is some links to some papers that are not even clear if any members of the group were involved in. There is a photo, but I couldn't see that anyone was named.

Maybe in my 3 minute look I missed something, but it rapidly became fairly obvious that is about all the idea and website seemed to warrant.

It is possible that one person created the website as it totally comes across as "havea big idea and try and cast a big shadow and see if someone will bring some more sunlight".

If I am wrong, then they really need to do a better job of their website, otherwise it looks like an attempt bootstrap on a thought bubble, at best.

Some background:

I live where we have the most isolated grid interconnect system in the world (and it is not Texas) and in this system generation is about 50% of the cost and transmission is the other 50%, so the incentive to optimise the transmission network is probably higher than anywhere else in the world.

The idea proposed sounds attractive, but would have been even more so when there was a far greater abundance of base load generation that could only cycle at relatively slow rates compared to the change in demand rates, but now, as generation becomes increasingly more distributedthe nature of the problems change a little (the duck curve, for example).

Analogs to this concept exist, eg water infrastructure where in order to not have to build expensive fatter pipes for water to serve increasing populations, local water towers are built that pump up at night during low demand and draw down during peaks. There are distinct available economies there, but the round trip energy efficiency is also potentially very high.

I am not sure that economically any similar equivelent for electricity could be implmenented, especially when compared to the cost of solar generation and the recent plunge in battery costs, it now is far more likely that at a household level it would be cheaper to get some solar panels and a decent sized battery and be done with it, at city block level probably even more economic as there is effectively no transmission, it is all distribution, so near 50% could be saved already on end use costs.

I just don't see it.

If you adequately specify what you want, then LLM's today are perfectly capable to produce code of a quality exceeding most humans.

But what has been going on is that many of the details of architecture and code have been implied as "good practice" or "experience" because it is time consuming to write a good specification, partly because you need to first work out exactly what you want.

So I decided that I wanted web apps, something that is probably beyond me in any reasonable time, if at all, if I was to code myself by hand.

For my coding AI "stack" I am now running OpenClaw sitting on top of Claude Code, I find the OpenClaw can prompt Claude Code better and keep it running for me without it stopping for stupid questions. Plus I have connected OpenClaw to my Whatsapp so I can ask how it is going or give instructions to the OpenClaw while not at the keyboard.

One app was a little complex with 35,000 loc, plus libraries etc. I reckon I had spent maybe 2500 hours on it over some years, but a significant part of that was developing the algorithm/workflow that it implemented - I only knew roughly what I wanted when I started, writing several to throw away at the beginning.

AI converted it to a webapp overnight, with a two sentance prompt, without intervention of any kind.

It took me another 15 minutes and a couple of small changes, mostly dependancies issues, and I had a working version of the same app that was literally 95%+ of the original, in terms of funcitonality and use.

I have a bunch of ideas for things I want to make that I probably never would have been able to otherwise.

I am just totally unable to fathom people that just make a blanket proclamation that AI is good for nothing. I can accept that it is not good for everything, it may cause some social disruption and the energy use is questionable, but improving, but not useful? Wake up.

I did it online thru the New York Radio Club (?).

I did Novice then General in about 30 minutes. I studied for maybe 6 hours immediately prior.

I grew up from age 5 in my Dads ham shack in NZ - every single thing he had made, transmitters, receivers, antennas, the feed wire, oscilloscope, signal gens, grid dip oscillator etc with many parts salvaged. In NZ in those days that is how most people did it, at least partially.

I also have an Electrical Engineering degree.

So sort of had a bit of background working knowledge, which meant I wasn't starting from scratch.

KK7RBX

It also seems to provide a substantially better experience of claude code, picking up when it is looping and breaking it and restarting, plus handling all the stupid questions claude code asks, hanging on. (Even when started with dangerously I cant be rid of them).

All in all they seem to be a match made in heaven and I strongly suggest you try this.

While IEC 61508 is the parent of all Functional Safety, medical devices are a little divorced form 61508 and have their own primary standard IEC 60601.

Some good explanation occurs here https://blog.johner-institute.com/systems-engineering/functi....

But this is the sort of engineering where you know everything about what your functionality will be, and what code and what type of code will be used to achieve it, well before you even think about starting to code.

The testing requirements can include things like testing every possible combination of inputs, for every possible combination of states (often just not practical, but there are some techniques to say, we will ignore these combinations etc). Every part of the final code shall be traceable back to a requirement so on and so on.

In industrial Functional Safety you might very easily work on requirements and definition for 2 years before you even think about what you might code, or even the device or platform you might be coding on.

I know of a mine winder job (Could kill 100 people in one go, so sort of like a passenger jet in risk profile) where the defining aspect of the design/build/commissioning critical path was Functional Safety, and it ran 10 years from very beginning to in service.

Imagine the most painful and anal waterfall process you could possibly dream of, and it is more onerous than this, plus you are exposed to being kicked backed to an earlier phase if certain problems are discovered.

If you are a move fast and break things, Mondays is pivot day and we like to actually roll some dice to decide what this weeks pivot will be, type of guy/gal, you are likely totally mentally not ready for how this needs to work, and probably don't want to be.

Plus if you come from a world where everything is a listener, and various other event driven paradigms, most of these people real struggle with real time highly deterministic systems.

This is because these invariably end up needing to be scanned logic, which looks stupid coming from this background. But, it is the best way that you can assure repeatable defined behavior, because event driven code is almost always of the type that ends up with an arbitrary order of execution, and this is not suitable for systems that have expectations of a highly deterministic nature.

There are zero cases for such devices where the answer to a problem is "just send that email again", to show the wagon wheel and/or drop a few frames or show some at lower resolution, or tell the user "just reboot at intervals of no more than 23 days and hold down the reset button while you boot", and so on.

And, some of these devices can do firmware upgrades OTA (not actually very common for somewhat obvious reasons), some need a special programming device within very close proximity and/or wired, and some are made with code in factory silicon and if you get it too wrong you recall them all for binning, at great expense.

I see another comment says that time to market for medical devices averages 12 years, and 75% of companies formed to make these devices fail - yeah I can totally see that, especially if it is a device that might roll out in the thousands to hundreds of thousands, the potential for harm, and for that harm to arise from software that either is specified poorly, or implemented poorly, is very large, extremely large.

I am a functional safety engineer, for well over ten years now, mostly industrial process and machinery, I hold certs from TUV Rhineland SIS and Certified Machinery Safety Expert TUV Nord.

But these are like one week courses, almost anyone that can pay attention could usually pass, though you need grades like 80% or 65% etc depending who runs the course you do.

More importantly (and written quite heavily into the standards) is you need to be competent, in the formal sense, which only comes from working with, or under, other engineers with suitable experience and background, and this might realistically be minimum 5 years, certainly no less than 3.

So moving into real time, embedded often, limited memory and CPU resources, need to know RF maybe as well, on it goes, do you as a well paid dev engineer want to go back to close to square 1 for x years, working in a way that will probably at best seem very antiquated to you, though most requirements are for good reasons when you understand them.

And ultimately, similar to other Fields of Functional Safety, the coding and all the computer stuff is probably easier learned by someone with extensive domain experience,

This is opposed to being an experienced coder (in most likely a different kind of code) and acquiring anywhere near the same domain experience in any reasonable time. eg in this case you are probably much more likely to to find medical people with training and experience that fell into dev roles to service the need, and it might be very difficult to compete with them, for what might be both real and perceived/cultural/"club" reasons.

There is more, but I am sure that is enough in the immediate context - not trying to be discouraging, just realistic.

From wikipedia "lifting gas"

"Helium is the second lightest gas (0.1786 g/L, 14% the density of air, at STP). For that reason, it is an attractive gas for lifting as well.

A major advantage is that this gas is noncombustible. But the use of helium has some disadvantages, too:

    The diffusion issue shared with hydrogen (though, as helium's molecular radius, 138 pm, is smaller, it diffuses through more materials than hydrogen[4])."

Unless you would rather be a calligrapher than a novelist.

Users have a habit of describing their problem as the solution they think they would like to have, often being disastrously far from the actual need.

Having part of my background in Functional Safety, I have seen it done many times, and it can most definitely be done.

It is just it can't be done in the sort of time frames that people who do not specify before coding, are used to.

But, if you can't afford to move fast and break tings, because it is an airplane, or train signaling system, or complicated elevator system with multiple cars in the same shaft, then you generally write no code until you know exactly what you want the code to do (and more importantly, not do).

It is just that for some decades now it was possible to get away with poor or lacking specification, by continually incrementing by sprints, or pivoting, or whatever.

But, back in the day when systems analysts were still a person with very particular skills that might never code, specification was everything.

And now, the wheel turns, and the importance of good specification appears to be the defining factor once again, all of a sudden.

"This video explores LoRaWAN communication using a microcontroller without a dedicated radio chip. CNLohr demonstrates techniques to transmit LoRa packets over surprisingly long distances, pushing the limits of inexpensive hardware. The project involves creative software and hardware interaction to generate signals at unexpected frequencies."

From distant memory you got quite a bit more compaction.