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.
He said that alone made life worth living, for him and them, but once any deteriorating conditions rendered him permanently unable to participate in this weekly activity then he felt it was time to go.
Maybe having a pre-set condition like this is less arbitrary, and also allows everyone involved to understand as the time comes closer.
So I need to collate some expenditure records for maybe 12 odd years going back, for these purposes mostly it will be in my gmails.So I click the Gemini star in Gmail and ask it to make a list of all invoices found in my gmails, and it tells me this:"I understand you would like to go through all your emails from the past 10 years to find invoices and create a Google Sheet with the biller, date,...
Additionally, you can easily define what output conditions are for every output in every state.
Where more than one possible to state transition exists, then you put multiple columns (one for each possible transition destination) and it is a matter of first solved wins, I usually go left to right, top to bottom.
I have developed a PyQt desktop application that allows building such tables, simulating them one scan at a time and generates code and documentation. Also, it allows for hierarchal state machines so you can build up very complex systems. I initially used it to develop Burner Management System compliant to IEC61511.
Presumably this occured because the Systems Analyst was virtually archtecture agnostic, but a computer person could consider both the problem breakdown and the optimal architecture to fit, juggling each a little to optimise that interface between requirements and implementation. This personage then claimed the title of "Architect".
However, I am seeing, in certain areas, a deep lack of specification skills and wonder the Systems Analyst might not partially have a resurgence as a profession.
For industrial controller software, esp distributed systems, there is a precedent of the standard IEC 61499.
One of the key components is the concept of an "Executable Specification", which may sound like unachievable BS, but if you are mainly doing state based systems, can be achieved by using state machines and working within a certain methodology/Activity framework.
I even wrote my own desktop application in PyQt specifically to satisfy requirements of 61508/61511 and the local burner code AS3814. The combustion and process engineers used this to specify (and verify by simulation, all within the tool) the exact exhaustive and unambiguous behavior for the machines (burner systems). As well for every state and transition condition attach a narrative about why it was like it was, with references, diagrams, attachments of manuals and datasheets etc.
Once all was decided, press the button, makes code, makes a documentation specification and compendium, and gives a level of traceability that is suitable for SIL 3, better accuracy, the systems guy (programmer) did not have to be a combustion engineer as well, because usually the crappy narrative type spec is always inadequate.
For certain types of code, this is the way of the future, and for things like rail and other super critical safety functionality, allows easy translation for application of formal methods to verify no unreachable conditions etc etc etc.
I had many colleagues that were initially in disbelief of the complexity but certainty of arbitrary functionality that was able to be specified with various hierarchal structures of state machines, as an executable specification