Posts by Electronics'R'Us 569 publicly visible posts • joined 13 Jul 2018
Many years ago, a coworker had an intermittent bug.
A signal handler had been set up but would not reliably fire.
The reason is that his code was expecting the signal before the OS (Linux1.x as I recall) had properly registered it.
The fix was to add fflush() immediately after the signal init code which yields the time slot to the kernel which can then do the necessary steps to actually set up the handler.
Like you, I inherited a PCI enumeration function for an embedded system that needed to ensure that the expected devices were present. This was on a LynxOS box that talked to a network connected host.
The problem was that there were no error checks. None. Nada.
Failed enumeration and init simply bailed out with no indication different from a successful init.
So if the enumeration and init failed, the host would simply receive an error message that the device | was trying to connect to did not exist. Not very useful when I am trying to guide the system builders a couple of time zones away.
I added a status word to the function and as each stage of the enumeration went and was OK, I cleared the relevant bit in the status. A status result of 0 (as is common) was a successful enumeration and init of the various bits we expected to find.
That status word was sent back to the host; if the init failed, I could state precisely what had failed by looking at the first non-zero bit in the status. Not difficult but hardly the first time I have seen lazy code. Without an error code there was no way of knowing if everything was OK short of the entire box not doing anything.
It ended up being used in the production code.
I do a lot of custom embedded hardware and having a really simple boot mechanism is essential - especially for that initial bring up.
A simple (which this seems to be) front end that avoids unnecessary complexity seems to be a wonderful thing.
I don't want the initial start-up to be overly complex - that is the task of the various drivers that can load in their own good time. Long gone are the days when we had to write our own PCI enumeration code (we are almost universally PCI express now and that will happily initialise the basic underlying system in hardware) among many other things that are far simpler now.
Given that RISC-V has the explicit expectation of different peripheral fit on a device basis, the simpler the better.
Simplicity is the key here, and I applaud this project for using that mantra.
Side note: there is a reason we expose serial ports for debug (the RS/EIA 232 type which have the benefit of being well known and very easy to set up and use). They are universally available and we can just use them.
I was using the Xilinx (as it was) Microblaze soft core back in the early 2000s in XIlinx parts.
Modern FPGAs are very fast, not necessarily from raw clock speed but because they are inherently parallel devices.
Instruction decode in parallel with instruction fetch (so pipelIning). internal arbitrarily wide data paths (within the capability of the device - to feed a hard PCIe endpoint at 16Gb or 32Gb we still need to move that much data around at those speeds).
They are not hard to develop for or program although the learning curve can be steep as VHDL/Verilog/<your language of choice> looks like software but the mindset is very much not software. I have been doing such stuff off and on for 30+ years and the biggest single headache is timing closure, particularly for physical pin interfaces. That has been helped a lot by the newer generation of tools that do a lot of the analysis for you.
Some have internal flash so they load their bitstream from an internal memory array at powerup (used extensively in avionics as the configuration in flash is immune to single event upsets).
They are very widely used for any number of things and many come with embedded cores (often ARM) so we can do the things that need speeding up in the fabric (and the fabric is faster than software by orders of magnitude) and then do some software around it.
Much more common than many might think.
Many years ago (early to mid 90s) I was working as a test engineer for a company that made 'smart payphones' Not what we understand that term to be now, though.
Basically a microcontroller, some memory and peripherals that acted as a payphone.
The company offered a flash memory upgrade on one particular line and as those things were very expensive at the time, it was provided in a socket.
I was tasked with writing a self test for this (so the production team could check the device was properly socketed and had no problems). Given that the function to write to the device already existed, this wasn't particularly difficult. What was difficult is that there was a total of 32kB code space (in a UV style EEPROM, microcontroller based on 65C02) and very little was available (around 50 to 60 bytes IIRC).
I managed to write a test (all 6502 assembly, of course) with walking ones and zeros for address and data (a pretty standard test) in 33 bytes. (Not all the instructions were 2 bytes).
Still ran pretty quickly (maximum internal rate for logic was 1MHz with a 4MHz crystal but as we were cheap we used a 3.58MHz NTSC colour burst crystal which were easily available and very cheap).
The days when literally every byte counted.
I came here with the same thought.
This partnership with LinkedIn will give us a clearer understanding of the jobs market – what employers need, where opportunities are, and how people are building their careers, in order to boost economic growth.
Given that the majority of the jobs on LI are fake (clickbait for cheap recruiters to amass lots of CVs) this is going to be of as much use for the stated purpose as tits on a boar hog.
I remember watching the Kenny Everett show when it first came out.
The dance group they had was Hot Gossip and was somewhat risque, to say the least. Mary Whitehouse complained and so every show after that, Kenny started with the line:
Warning - This Show Contains Naughty Bits.
Very amusing.
Did wonders for the viewer ratings.
There is actually one for DV and SC cleared!
If that isn't something that says 'here are people with lots of juicy information' I don't know what is.
There is actually fairly strict guidance that you never show any security clearance on public profiles (which includes so-called 'private groups' on any social media).
WTF is this supposed to mean?
Some people are quite happy to not be active in the so-called digital economy. I would note I am quite active but there are many times I happily pay cash for items (particularly at the village shop).
I suppose I am in the age group they think needs this 'inclusion' drive because they are, to put it bluntly, stupid.
Having been actively involved (and continue to be involved) in technology for well over 50 years, I would suggest that the people suggesting this should be part of a digital exclusion drive.
One of my primary tasks at $EMPLOYER is to design hardware, so I use a pretty powerful CAD package. I also do a fair amount of software (embedded, mostly ARM).
My Dell laptop (which I had upgraded to 16GB - really the minimum necessary for a modern CAD package) handles this without a problem with my multiple screen setup.. No 'AI' chips in sight.
I see no point in the AI add-ons as they cannot do anything useful in my area (it might leave something useful its wake just as expert systems did but what remained after that debacle was a far cry from what had been promised - sounds familiar...).
I have seen lots of posts across various sites where the claims of 'AI did my PCB!' pop up now and then but the problem with that is the schematic and layout are the implementation phase by which time I have already done the hard work of figuring out what the design has to be, something no amount of current AI / LLMs can do (well, without very specific guidance but if I have to get that specific I have already done the work).
When I was fixing two way radios (and other stuff) in Florida, we also had the contract with most of the local police for their blue lights and sirens as well as the radios.
One day, a deputy comes in and tells us the blue lights on his cruiser need fixing as they were blowing fuses and he put a temporary measure in place in the fuse holder which was the clamp type.
The temporary measure was a bullet.
Some time ago (decades now) I was writing test / diagnostics software for smart payphones (basically a microcontroller with supporting bits that acted like a payphone).
In this case, I had written the code running on the test machine and the target hardware.
One day, the director of operations came over to my desk screaming that my tests had all gone wrong and we had 100% failures at test at the build house (who had one of the testing systems).
I went to said build house (not a short journey) and looked at the failures and they were all failing one specific test: Escrow relay. For those who may not know, this is the beast that will either take or refund your money. In this specific design, it was powered by a static inverter that generated 120VDC and dumped the energy into the relay when required.
I took a few of these failed units back to the office and the first thing the director of engineering said was 'test it on <other engineer>'s test setup'. Those in hardware will know this is hardly a scientific test, but the relay did operate (although to me it seemed sluggish). <other engineer> declared the unit was fine.
I took said board to a test bench and hooked up a scope to the drive circuit and fired the circuit into a known load. Rather than seeing the expected 120V peak and discharge curve [1], the signal went up to around 80V and abruptly dropped back to 40V from where the normal discharge curve was observed.
A close inspection of a couple of capacitors (which were carefully desoldered) showed they were delaminated and were shorting out at the above 80V. That meant this was a build issue. While I was doing those tests, the director of engineering, director of operations and <other engineer> were watching and once they saw what I had found they were rather red faced and left without another word.
I talked to the build house and they found the build process was heating up that area of the board to a temperature well above what it should get to, so the problem was solved.
In this case, my tests were working just fine.
Note 1. I was sampling this signal multiple times in this test to capture the energy under the curve.
A lot of avionics have a pedigree from between ten and twenty years ago and there are good reasons.
An update to anything safety critical (and radalts can come under that heading) is a time consuming process as the new kit has to be thoroughly qualified and there is a rule: Don't be the first with anything. We only want to use a proven basis, which is sensible in safety critical design.
When those earlier systems were designed, the band limit filtering was easily sufficient for the operational profile required. As noted by at least one other, brick wall filters are very difficult to achieve (and we prefer to not have any software if possible).
Circuit fundamentals haven't really changed over the years although there are some newer modules that can help with the situation but I suspect part of the solution will be to detect interference and remove it. There are a number of ways to do that depending on what the interference type actually is.
So it is not that we don't use filters - we do. It is just that we need to update them to account for a new RF threat that did not previously exist.
Having actually done some of these, here is the pretty standard design requirements.
Triplex design, galvanically isolated so if one lane goes out, the other two are not electrically affected. Processors must be 3 completely different architectures to make the chance of a microcode problem (spurious execution) so small as to be effectively zero as all the processors will actually have completely different engines under the hood (in reality, the numbers are more like 10^^-12 or so).
Memory interfaces: L1 = parity protection. L2 and higher ECC (fix one, detect 2).
All the above is in hardware.
Every relevant sensor is read (typically 20 times per second) and the 3 channels vote with their results which will naturally have some margin for different physical sensors. That is usually done either in a processor or quite commonly now, a FPGA [1]. If there is a disagreement, the two in agreement will reset the other channel.
Ultimately it is software that commands control surface movement based on pilot input against the control laws, a specification given to the manufacturer of the equipment by Airbus in this case. In this particular case, if Airbus are doing the top level or have replaced the third party vendor model it looks like the control laws may well not be properly defined.
I don't know the current software stack in the A320 but I do know the process is very strict.
1. FPGAs in this context are designed to the requirements of DO-254 (or the Airbus equivalent which has the same requirements) and is very similar in scope and effect to DO-178 for software. FPGAs with SRAM configuration data are (or at least were) a big no-no. The old Actel ProASIC flash based series were the go to parts in this area for a long time. Flash is pretty much immune to free neutron hits.
Most atmospheric particles are free neutrons, the density of which increases with increasing altitude (it is an air pressure issue and varies quite considerably across the world)
Microsoft has turned the humble Windows Paint app from a basic bitmap wrangler into an AI-enhanced nightmare
So very true. The previous version was simple and lightweight with a reasonably easy to use interface. The new version is a horrible mess with standard controls that were often icons or plain text on the menu (crop comes to mind) hidden away behind an extra right click.
So a tool that was great for a quick image markup has become infested with bits no-one wants (the copilot button is probably larger than any other but I have yet to find a use for it other than to show how crap this stuff has become).
I live in a rural area, just outside the village proper.
My postcode covers an area of perhaps 0.7 miles by 0.4 miles. The centroid (depending on which map service you use) will either put you in the village to the west (which is not in this postcode at all) or close to 0.5 mile to the east as I am on the western edge of the postcode.
Many have the times been where a delivery driver cannot find my location (it is also not visible from the country lane until you are on top of it).
Even the energy company was sending my initial bills to the wrong postcode when I moved in.
As far as I can discern, postcodes are based on a number of dwellings.
This veteran is not beaten, broken or conditioned to kneeling before authority and I wasn't even during active service.
I left the service over 44 years ago (and if you think the transition support is bad now do I have some stories to tell although I was given time off for interviews).
When I left I was on my own and I didn't really worry about it as that was the same for everyone (not sure if that was true for officers).
Having had an interest in infosec for a long time, this scheme can really only be about creeping control as there is no need for it as far as I can see. I have a NI number and proof of identity already. It won't stop illegal immigration (who are employed by people who simply ignore the rules anyway).
So they can take their digital ID (and driving licence for that matter) and shove it where the sun don't shine.
From what I see in the veteran community (such as it is) the vast majority are saying no.
Electronics is highly reliable. Far more than spinning things or connectors [1].
Properly designed electronics [2] will last decades so my view of the arbitrary hardware requirements from M$ is it is just to help their 'partner companies' sell more hardware and the ecological effects (potential several millions of fully functioning devices going to landfill) be damned.
I agree with the commentard who took a position that if software forces a device to be obsolete (but it is still perfectly functional otherwise) then full documentation for the device in question should be made public [3]. That way, the devices can be re-purposed and still be useful and not end up as e-waste. I would not put any specific time limit on this; just a requirement that if the device in question is still functional at the hardware level then the documentation should be released if the software vendor has made their code base unavailable thereby making the system obsolete.
1. Connectors that are mated just once will last a long time. They are actually usually rated for the number of mating cycles and still be operational. Too many mating cycles wears the conductive layers and reduces the strength of the contact retention mechanism. This also depends on the type of connector and how it has been mated, assuming it has been properly rated for the level of current going through the contacts.
2. I have seen electronics in the high reliability sector that is well over 50 years old and still operational, albeit having had relatively minor repairs over the years. A lot depends on he environment as this is highly thermally dependent. A temperature rise of 10C yields the rule of thumb (very conservative) that it reduces the device life expectancy by 50%. More typically it is quite a bit less. Most of the things I have designed over the last few decades should last (for the electronics at least) for 40 years or more.
3.Not as difficult as some might assume. GPUs go obsolete after 1 or 2 runs at the fabricator (those runs are typically in the 100k+ to millions of units). The internal secret sauce has been deprecated so a 10 year old GPU should have no reason to be kept secret. The same goes for other high volume products such as CPUs (Intel always keeps their behind a NDA as do others).
Many years ago (late 80s to early 90s) National Semiconductor (now part of TI) had a 3 volume set of databooks (yes, real books!).
In the special functions book the LH0033 / LH0063 buffer amplifiers were featured. These were designed for video applications and the databook stated Fast and Damn Fast Buffers.
In the applications section for the parts where the physical PCB layout was being discussed it had the headline:
ACHTUNG!
This was because the output transition rates were very fast (for the time - we surpassed that many years ago) and needed careful consideration for the manufacturing capabilities of the day.
From a time when people didn't take offence at every silly little thing and besides techies were known for their sense of humour quite aside from their perceived social issues. (which is actually not the case with most).
Such a leak could be construed as an offence under the official secrets act although that may be open to question.
At the very least, the person who made the blunder should have had an interview with the security vetting people. That is not very common for SC but it has been known to occur.
Perhaps further training and tighter supervision as well.
Anyone who comes into contact with UK classified information as a standard part of the day job has signed a little piece of paper (or electronically nowadays) that specifically reminds them of their responsibilities under the act. Not having signed it does not mean you are not covered by it, but that little piece of paper / file means you have no excuses (I didn't know about that....) if you do something dumb.
Security clearances are a bit of a Catch-22.
Individuals cannot apply for them; it has to be sponsored by a company that has a reason to require the clearance, such as list X companies.
In many cases, it is perfectly acceptable to start with the lowest level clearance (BPSS) which takes days (a DBS check is required but that is pretty simple to do and some statements from the candidate).
In my case, I have started with the BPSS when I did not hold a current clearance. When you go beyond this (SC for example) is when the real scrutiny begins.
The last time I had to do the application, it took about 4 weeks or so after completing the questionnaire for the certificate to be issued to the company.
As to not advertising it (even to HR), most companies have security passes that have visual identifiers to indicate the level of clearance so if you know those, you know the clearance level (to a certain extent - one I worked for had the markers for 'is cleared to SC or above').
I joined the Royal Navy in 1970 and I must have been cleared, but like you I was never told what level.
I figured it out several years later when a Petty Officer declared bankruptcy and received shortly thereafter a 'Services No Longer Required' letter. Bankruptcy = Lose your secret or above clearance.
In those days (as I am sure you may recall), bankruptcy was one of the immediate 'no clearance for you' items for anything above restricted [1] and therefore we clearly all needed to have a minimum secret clearance (even though the next level of classification was Confidential, the next level of clearance was secret). On one amusing occasion, I had to go to the signals office to get one of the signals for the squadron CO because the duty officer did not have a high enough clearance to collect it.
I currently still work in the defence industry (and my LI profile shows the company so it is pretty easy to know that I am in the industry) but the details of what I do (in terms of projects) is never shown; I might list some types of tasks I do which is sufficient for recruiters to contact me, if they are looking for someone with a particular skill set. My level of clearance is never stated and I am not in the 'SC' or 'DV' groups which would rather give that information away.
1. Information is routinely overclassified by UK govt. The newspapers that came on to the base would be stamped 'Restricted'
This is not a religious view nor do I look either up or down at other operating systems and users. They are using what they wish and I am going to use something that meets my needs.
I have used Linux (and written a significant amount of code for it) on and off for over 25 years. I know it has its 'quirks' but generally it just gets things done, which is exactly what I need. I had to talk to SWMBO to make sure she wouldn't have an issue with it.
My work laptop got updated (it is definitely not an upgrade) last week and it has convinced me to finally make the switch to one of the Linux distros for my personal devices. We have nothing M$ specific so it should be fairly painless.
I don't want this spyware ad-slinger that masquerades as an operating system on my home devices (I have managed to pretty much clean up the Win 10 installations).
The UI is horrendous, lots of settings are even further buried in obscure locations (even getting back a reasonable UI took 2 hours of digging), some apps are totally different (paint, for example which has been infected by the AI kool-aid. As a simple tool for grabbing an image and marking it up, the old paint did a good job - not so much the new version where common commands are now not on the toolbar at all such as crop).
The work laptop has to have some flavour of Windows as I have CAD tools that are only available for Windows and I am being paid to use it, so I will simply put up with the slowdown caused by having to make more selections to get a particular application up and running.
So in a way, the work experience was useful and tipped me over the edge of waving goodbye to Windows on my personal devices.
In fact, the UK Lightning Force faces "major personnel shortages across a range of roles," which the NAO says are not likely to be resolved for several years, although it notes the MoD is recruiting to fill some of these gaps.
There are multiple levels for maintenance that require (sometimes) different skill sets and it varies by trade.
Flight line / flight deck. Limited to LRU replacement (a part of the avionics kit in a bay, for instance). Other things such as refuelling, adding / removing payloads and turnaround checks.
Hangar. For most electronics, this is the same as flight line (replacement of LRUs) but also full system testing can be done. For airframe and engines it can be much more in depth but that depends on a number of things such as level of training and equipment availability. When I was doing this stuff (admittedly a long time ago), we could do engine changes in the hangar when at sea.
Third line support. Often with contractors either from the company or simply sending equipment back to the OEMs for repair. We used to have a pretty much sovereign repair capability on bases and ships for most avionics but that changed over the years to support contracts and is now mainly card replacement within a box. The turnaround time for some equipment can take several months especially if the kit is US made and sold with the aircraft under FMS (foreign military sales). Even UK made kit [1] (of which there is actually quite a bit) may still need to go back via Lockheed Martin (depending on the wording of the contracts of which I am ignorant).
For weapons, it is not just the aircraft software, but also the rather slow process at Boscombe Down to get weapons approved onto an aircraft.
So it is not a simple problem.
The day to day stuff is flight line and hangar and needs to be serving RAF / RN personnel, of which there is a known shortage for a number of reasons. Until that is addressed, the problem will continue.
Note 1. I have been involved in the design of some of it.
One of the subjects I had was 'mental arithmetic'. No book, no slide rules. Juist questions and answers.
When I took my (belated) mathematics GCE O level in the 1970s it had 3 papers.
Mensuration (no, not that). Evaluation of numeric questions. The hardest I remember was 27 to the power of 2/3. No calculation aids of any type permitted
Plane geometry. As the calculation phase here depends on knowing which trigonometric function to use, calculators were permitted.
Calculus. As with geometry, knowing how to solve for the answer is the biggest challenge. I recall one question on the lines of 'a bullet is fired at an angle of <x> with a velocity of <y>. Ignoring wind resistance, what would be the highest point of its trajectory? Take G to be 10m/s^^-2.
The last two required you to show your work.
As noted by others, this has been going on for a long time.
I recall seeing a job advertised on LI (I know, I know) for an electronics engineer.
They stated 'Typically 2 to 5 years of experience' so not quite entry level but not far above it.
They wanted:
Degree in electronics. [6]
Expert in analog and digital design [1]
Design for EMC [2]
Experienced with high end CAD tools [3]
Mixed signal design layout expertise [4]
High speed digital design [5]
among other things.
1. I have yet to meet a graduate from any university with any real knowledge of analog design and that is true of at least the last 30 years. It takes typically a couple of years of solid mentoring (if it even exists) or the grad studying it for said amount of time (or more typically 4 to 5 years) and actually building the circuits because it can advance their career , so they would need their own at least basic lab equipment. There is also a whole lot more to digital design than it seems at first glance. Sometimes the person who did not go to university has a better grasp depending on the career path.
2. This is still one of the darker arts although there is a lot of science but every design is different and has to be assessed with an experienced eye. To get good at this takes several years in its own right.
3. Depends on where they were previously; these tools are expensive although there are open source alternatives; those alternatives don't come with support, though, which most companies need or want. Even the relatively low end of the market (Altium) runs to almost £10k per seat per year. They all do (roughly) the same thing but each has its quirks, so there is always a learning curve.
4. Hahahahahahaha. This is possibly the most difficult of skills and can take literally decades to fully master.
5. For this, one needs to understand a lot of things from all the above and transmission line theory at a minimum. I started in RF so it really wasn't that big a deal for me.
6. Slight afterthought; some of the best engineers don't have one.
The real applicant for such a position would be very senior (probably a principal level) and would laugh at the offered salary.
These generate their own oxygen after ignition, so starving the fire of oxygen (foam type firefighting) is not really going to achieve anything.
In this case, it really doesn't matter where the fire started (although my view is was probably a Li+ battery in one of the said EVs as there shouldn't be much fuel in the other types although that remains a possibility) as once the fire gets going there is little that can be done. For very small fires, they can be dealt with by using Aqueous Vermiculite Dispersion (AVD),. Source: FPA
Lots of distilled water would help (cooling only) as that is an insulator but most water on the planet contains some salts (the level depends on a lot of factors).
There are a lot of reasons Li+ can catch fire and although the rate is low, the consequences can be somewhat brutal.
In some older gas turbine engines that used cartridge start, the fuel used generated its own oxygen so it isn't as if we don't know the risk.
I do quite a bit of CAD work with this laptop (Dell with a core i5) and it copes quite well (I had the installed RAM upped to 16GB as that is really the minimum for such things).
I have seen some frankly ridiculous claims on various sites about AI can do this or that (the latest fad is it can design your circuit and lay it out and another claiming you won't need to read the datasheets anymore).
I can't see this aggregated ignorance [1] providing any assistance in the core part of designing electronics (by the time I start actually using the tools I have already designed the thing at a decent level). One of the other things I do is troubleshooting, and given that each and every circuit is a bit (or a lot!) different, not sure how that will somehow miraculously find the solution to all the problems we can see.
I just can't see the value (and nor do my IT group, AFAIK) in paying for internal functionality that we neither want or need (to say nothing of the slurpage going on).
The vendors are desperate but if they are that desperate maybe they should be selling what the buyers actually want. [2]
1. Brazenly stolen from a post here some time ago. Best description I have ever seen.
2. I know, I know...
I see a lot of posts around where "AI" (aggregated ignorance) can produce a working piece of electronics.
Circuit diagrams.
Layouts.
We can check your design so you don't have to read your datasheets!
All things I have seen.
For trivial circuits that can be extracted from a datasheet or application note it is just regurgitation and as for checking your datasheets for you, it is simply checking pin types and recommendations that is already in the documentation (such as 'you should have a decoupling capacitor of x as close to the power pin as possible'). Pure snake oil. I can check things faster than any of these 'tools' (I use that term in the pejorative sense) can possibly do.
I can also check things it cannot possibly know how to do (things like why do I have occasional memory problems which is probably due to crosstalk or some other design issue).
I fear (well, I expect) that someone who fancies themselves as skilled will use one of these circuits (which will have all manner of unusual edge cases) and then try and flog it as 'AI generated! - it's the future!'
AI engineering? Don't know whether to puke or laugh. Maybe both but not necessarily at the same time.
For those who can effectively work from home then it makes sense on many levels.
I am aware that not all jobs permit this (building stuff requires hands on at a plant of some description) but my job (primarily electronics design) can be effectively done from my home office just as well as the company office(s).
My $company has a pragmatic view on this; just about all the engineering staff (including management) are on a hybrid pattern with varying amounts of time in the office, driven by need. There are times I really need to be in the office / lab / production and I fairly regularly go to the main office for precisely that reason (it's a bit of a hike so I go there for a week). There is a (fairly) local office but the lack of public transport in my neck of the woods means driving but I do go in but when it adds value, not just to see my butt on a seat.
The company has a 'green' initiative and has an annual report on how much we are contributing to pollution (this report is increasingly being demanded by our customers) so it is a win for everyone.
I gain more flexibility (my commute is about 10 seconds) and the company gains more productivity (no interruptions or distracting noises from Joe in sales). Collaboration? We use online tools and there doesn't seem to be a problem with that.
The management isn't paranoid about seeing people at desks; they just want results.
If you want to be long term successful, anyway.
Contrary to some comments, this doesn't mean you studied Chaucer or necessarily the classics (although that doesn't hurt).
I have had to effectively communicate with people at all levels of organisations and the interesting thing is that they all effectively speak different languages, even though (in most cases) it has been English.
It isn't just about fixing problems quickly, either. Can you explain how the problem occurred so it can be prevented in the future? In my experience, being able to clearly explain what a problem was / is and how to prevent it is a very important skill.
Senior management wants to know there is a solution. Engineering management wants to know the solution and how it might be implemented. Engineers want to understand the solution and the practical effect.
QA wants to know how this will be documented and applied.
If you have junior engineers who you are mentoring (you really should be) then it is perfectly possible you will need to be able to explain a concept in at least two different ways.
If you are helping with bid work then you need to be able to explain how your part of the bid will solve the customer's problem.
As far as getting jobs goes, the fact I really know my core subjects (and a lot of tangential ones) would not be very useful if I cannot explain clearly how and why I know those things.
The list goes on but that is the gist of the subject. Explaining how a fix affects the business to a senior manager is a lot different to explaining how that will affect day to day engineering to the line manager.
Back around 1999 / 2000 I was doing diagnostics for a video on demand system. Quite an impressive beast.
This newer system was based on a 3U compact PCI rack with our own designed cards apart from the control processor (a power architecture). It communicated with a host over sockets.
The initialisation was not particularly complex but did have to do PCI enumeration and then initialise all the cards in the rack.
One fine day when I was looking at this fairly new system, I was rather surprised to find that none of the initialisation code (including the enumeration phase!) tested for successful completion. After a (failed) initialisation that was totally silent, I would be met by an error message that the system could not be reached.
I set about rectifying this by adding a status word that cleared a bit for each part of the initialisation when it succeeded. At the end of he init, that status word was returned to the host. If it was non-zero, something had failed but just what was obvious as it would be the first non-zero part of the status word.
Took me about 4 hours or so [using ioctl() over a socket]. That as eventually added to the production version because the customers were complaining of silent failures.
Even back then, we had the 10 commandments for C programmers many of which apply elsewhere, in particular number 6.
Sheer laziness imo.
The official secrets act applies even if you haven't signed the piece of paper or online document.
The document we sign explicitly states the responsibilities for those likely to come into routine contact with classified information so there can be no doubt what the rules are.
I am one of that earlier generation [1] and I am perfectly comfortable with most of my interactions being online (Teams manly). I am still doing full time electronics design and my home office is by far preferable to any open plan office (or juts about any corporate setting for that matter).
I do go into the local office once a week (most weeks) as it helps to catch up with the integration team and see what issues they may have been having. I regularly go to the main office (where the team I primarily work with are based), but as that is a couple of hundred miles or so, I go there for a week at a time.
For those of us who really need peace and quiet to do our best, WFH with the occasional office day is superb.
My management is relaxed about it - I am measured on results, not where I happened to be when I did the latest new / updated piece of electronics. Don't get me wrong, the company is fast paced (not that big with a lot of growth and large orders incoming) so we regularly get new starters. I can just as effectively mentor them in the ways of electronics in an online chat as being in person (which, contrary to popular opinion, really hasn't changed that much over the years [2]). The key to those online interactions is getting it right.
I hover between introvert and extrovert; when I am in the middle of actually designing something, someone coming along for a 'casual' conversation is the last thing I need.
1. I haven't paid employee NI for some years which will give you an idea of my age.
2. Many things have evolved, particularly in PCB layout and we now have functions contained within a few square mm that would previously have taken up a complete 3U board. The underlying principles really haven't changed, though. There are still times when I will use a circuit type from several decades ago as it is often still the best solution.. We do have far better tools for many things (CAD, for example, and IDEs for FPGA development).
Elez was granted an interim secret clearance on January 22
I must assume that this was 'encouraged' by the dynamic duo. There have been some real howlers in the USA from inappropriate clearances.
Having a security clearance myself (for the umpteenth time), the screening takes a few weeks in the UK and although I don't know if they scrutinise antisocial media, they do check a lot of other things.
Would be interesting to know just how much of a background check was actually done.
Unfortunately, not all pilots did push back.
The amount of technology in a modern airliner is astounding and I have designed some of it.
Autopilot, fly by wire[1], auto-landing capability [2] and more.
The worst case of over reliance on technology was AF447 which crashed into the Atlantic some years ago. After it went missing, I looked at the telemetry the aircraft had sent (that was satellite based IIRC). The pieces I remember very clearly were:
Airspeed disagree. This means that the 3 computers, each with their own pitot tube, did not all agree on the airspeed. Not usually a major issue but it was a major contributing factor here.
Alternate laws. Flight control computers have what is known as 'control laws'; under ordinary circumstances these are time, but when the system goes from triplex to duplex those won't do the job, so we have alternate laws for that situation.
After all this, apparently all 3 pitot tubes iced up (they were in the middle of a massive thunderstorm which is a prime location for icing).
Without any reliable information on airspeed, the flight control system disengaged. Then the worst part happened - the pilots in the cockpit did not know how to manually fly the aircraft. They kept pulling the stick back which eventually led to an aerodynamic stall. The captain (who was on a scheduled rest break) arrived back in the cockpit but was unable to recover from this. Flat spins are one of the worst situations to be in.
Over reliance on technology is never a good thing.
Note 1. Fly by wire uses (as mentioned) flight control computers. The person at the controls inputs what they want the aircraft to do, but the electronics and various motors and actuators does the task. For civil aviation, these are triple redundant with some interesting requirements such as the processors in each 'lane' must be different architectures and each lane must be galvanically isolated. We also have FADECs =- Full Authority Digital Engine Controller. These are what actually adjust engine thrust.
Note 2. I have experienced this going into Salt Lake City almost 30 years ago. Smoothest landing (grease job) I have ever had.
Open plan offices are guaranteed to be less productive than a quiet office (be it at home or company office).
There are times I go to the office. I am encouraged to show my face in the relatively local office in Plymouth once a week, but I get little objection if I am busy with something that requires concentration (implying peace and quiet) as said office is open plan [1]. The marketeers are usually loud and I once just packed up after being in the office for an hour.
When asked why, I told them that I needed to concentrate and their constant loud conversations (from one desk to another) was preventing that.
I do go to the more distant office (not far from Gatwick) every now and then (very ad hoc usually but sometimes there is new kit to test or problems to solve that can only be done hands on). Given that (by train) that office is the best part of a days travel from where I live in Cornwall so I go over for a full week.
Those offices, although nominally open plan, are populated with various teams, so the area i get to hot desk at is fully of engineers who truly appreciate a quiet atmosphere.
Back on the primary subject, a full RTO mandate whether it is appropriate or not is silly. If I am going to just work with the rest of the team to get a design solution (which happened 3 times this morning), it matters little where I physically sit.
There are those who really do need to be onsite, such as production teams, but working from where i do the best work just seems logical [2].
1. I have a really good manager who is also an engineer and understands this.
2. I am aware that many middle and senior managers are incapable of grasping this difficult concept </sarcasm>
You are completely correct on the 4 year comment.
Properly designed electronics hardware (ignoring the spinning things for now) should easily last decades. The biggest single hardware killer is excessive heat which is why we go to great lengths to get it out of the box.
The rule of thumb for silicon devices is that for each temperature rise of 10C, the life will be halved. This is based on the Arrhenius equation
I have some really old equipment (30+ years old) that is still going strong.
I am in the high reliability business so typical system life has to be measured in decades (some parts are allowed to fail after a few years which can be an obsolescence nightmare), but that said, some really old parts are still being manufactured such as the 741 (designed in the 1960s).
An office or home based system should easily last 10+ years. Pushing users to dump it just because the vendor no longer supports the OS or insists that a certain type of device be present that is really not necessary is, to me, a form of vandalism.
Another problem is that way too many parts are used for a given system. We could probably use 50% of the components that actually exist in equipment with probably no noticeable change in response. This does require a disciplined software approach: don't require 16G RAM for a simple app because it happens to run well on <framework that is downloaded in its entirety>.
