I oftentimes find myself wondering what might be the equivalent of this sort of electronics hackery in the world of software.
It's not uncommon for me to see engineer friends of mine working on these sorts of projects and to find myself envying the apparent complexity of such projects - nothing (kernel hacks, ATMEGA projects, large C++ (shudder) systems, crypto/security work, ...) feels as though it requires the same level of knowledge/expertise as working on even relatively simple engineer's projects like this.
Might this just be a standard insider's view of one's own field?
To put it in context, Alec (M0TEI) is a student of engineering at Cambridge and a friend.
It's not so much the complexity as it is the lack of knowledge of basic EE theory that tends to trip up "outsiders."
Case in point; I've been helping a coworker with software only background (I started out as an EE) with a very simple circuit that he could not get to work. As I explained how to debug it, I began to realize that there was a a lot of required background knowledge I simply took for granted and that most hobbyists didn't have. And that made explaining what to do very difficult.
And my day job is a large C++ system. Trust me, this kind of stuff is easier and more relaxing ;-)
Agreed. Electronics hackery, especially making sense of someone else's circuit, takes a lot of acquired knowledge. Knowing common circuit topologies and being able to identify them when you see them, knowing that if you see a component in a TO220 package there's a 95% chance its either a transistor or a linear reg (usually you can guess more specifically just from its location on the board), having a mental list of components you can use to design a certain circuit (hmm, an audio preamp? I wonder if an NE5532 would be suitable?), knowing that a yellow bipedal surface mount thing is almost certainly a tantalum cap, knowing that a number of connectors near a SoC is probably JTAG etc. All of this just comes from experience and recognising patterns! Although I imagine dealing with code is somewhat similar? Perhaps there are certain things which you come to notice by instinct? Eg maybe you can look at some assembly and, just skimming over it know that it's supposed to be a time delay?
In terms of complexity, certainly. When you look at the assembly code from the inside, with something like IDA it branches out infinitely. In terms of fun. I'm not so sure.
Say, finding and replacing some part in an aviation radio is a lot more fun, than spending time annotating insides of some executable.
I think that depends rather on who you are and your interests, to be fair - as much as I'm a fan of the former, the latter sounds like rather more fun.
True. But a lot also depends on the context. When you are dealing with some binary, unless it is antique, most likely you are doing something nefarious. Like obliterating somebodies license check. And while there is certainly a feeling of some elation, when you are finally succeeding, it can't compare with the joy you feel, when some electronic component is coming alive after you've finally fixed it.
Has an NSN, so it's military. Also, it doesn't look like it was ever used (and/or recently-manufactured. although if they use the pseudo-standard serial numbr scheme, then it was manufactured in 97).
The indicator light styles are kinds I have seen around in years on military a/c. That doesn't really mean much, though. Slightly interesting, nonetheless.
This seems about right. I found various components inside with date codes ranging from 1996 to early 1997. The indicator lights had no markings on them, but IIRC the bulbs inside were 28v incandescents. Do you know any more about them? I'd be interested to know what IP rating they have (IP67?)
It's not actually an atomic clock, it is an atomic frequency standard. The difference between the two is that an atomic clock outputs 'time' whereas an atomic frequency standard merely outputs a very regular square wave.
You can easily build an atomic clock once you have such a frequency standard. The confusion probably stems from the electronics term 'clock' for square wave used to clock other digital circuitry but the general public would definitely misinterpret the term atomic clock to mean something different.
Fair enough. I think its close enough though to warrant the use of "atomic clock" in the blog post - you need to simplify things just a limit bit if you want to audience to be bigger than 14 people.
It's not uncommon for me to see engineer friends of mine working on these sorts of projects and to find myself envying the apparent complexity of such projects - nothing (kernel hacks, ATMEGA projects, large C++ (shudder) systems, crypto/security work, ...) feels as though it requires the same level of knowledge/expertise as working on even relatively simple engineer's projects like this.
Might this just be a standard insider's view of one's own field?
To put it in context, Alec (M0TEI) is a student of engineering at Cambridge and a friend.