In my last post, I mentioned that the only way to eat an elephant is one bite at a time. Building anything with any degree of complexity is the same way; you have to break it into manageable chunks, otherwise you're invariably going to find yourself overwhelmed. In an electronics project containing more than a single stage, I will divide the overall project into a series of modules, each with a defined function (eg: IF amplifier stage) and parameters (input/output levels, impedances, gain). Modularity allows each element to be developed, tested and refined individually, which is important because, realistically, at the amateur level (where I proudly reside) things seldom work right the first time. It's much less frustrating to have to scrap a single module than it is an entire project.
The photo above shows the modules on the underside of the SR-16. Each module is on it's own circuit board and wired such that it can be removed independent from all other modules (with the exception of the power and TR switching, for obvious reasons.)
The large, shielded enclosure to the left contains the Hayward/Damm HyCas IF/AGC circuit, which I'd built some time before conceiving of this project. Since I knew the function and I/O parameters of HyCas module, designing and building a rig around it was straightforward: I drew-up the block diagram to use as a road map and went to town.
Like Master Homebrewer Pete, N6QW, I have a number of favorite circuit modules that I use in my rigs. An example of this is the mic and audio preamp module; I've got a design based around a single LM324 that works well, so rather than reinvent the wheel, I've used the same circuit in my last three rigs. But, since it's built as a module, if I find something that I like better, swapping it out will be a snap.
Modularity isn't limited to the hardware side of the project, but extends also into the Arduino sketch that runs the bloody thing. Since I'm using an SI5351 to provide the LO and BFO signals, much of the work has already been done for me byJason Mildrum, NT7S, Przemek Sadowski, SQ9NJE and Tom Hall, AK2B, so I used their code as a starting point. Not being a programmer, it took a lot of studying before I understood how their sketch worked and was able to modify it to perform the additional functions required by this project.
In the same manner that the block diagram served as a road map for the rig's hardware, I sketched (pencil and paper - too ugly to post!) a flow-chart for the sketch and wrote modular "functions" for each, well, function of the software. Each function is analogous to a hardware module - they can be developed independent of the main program, and subsequently refined individually without disrupting other parts of the code.
While I don't want to share my ugly flow-chart for the entire sketch, here's how I keep the functions organized on my hard drive:
Here's a drill-down into the folder containing the function to load the VFO frequencies and status from EEProm when the rig's fired up. Notice that it took me several attempts to get it right!
Notice that I keep to a standard that I've developed for myself to maintain version control - this becomes increasingly important as the code grows longer. I think that'll be the next entry into this crazy blog - it's absolutely essential to keep track of where you've been in order to get where you want to go.
I can't imagine successfully homebrewing anything more complicated than perhaps a Michigan Mighty Mite without using the modular approach.
73 de N8NM
The large, shielded enclosure to the left contains the Hayward/Damm HyCas IF/AGC circuit, which I'd built some time before conceiving of this project. Since I knew the function and I/O parameters of HyCas module, designing and building a rig around it was straightforward: I drew-up the block diagram to use as a road map and went to town.
Like Master Homebrewer Pete, N6QW, I have a number of favorite circuit modules that I use in my rigs. An example of this is the mic and audio preamp module; I've got a design based around a single LM324 that works well, so rather than reinvent the wheel, I've used the same circuit in my last three rigs. But, since it's built as a module, if I find something that I like better, swapping it out will be a snap.
Modularity isn't limited to the hardware side of the project, but extends also into the Arduino sketch that runs the bloody thing. Since I'm using an SI5351 to provide the LO and BFO signals, much of the work has already been done for me byJason Mildrum, NT7S, Przemek Sadowski, SQ9NJE and Tom Hall, AK2B, so I used their code as a starting point. Not being a programmer, it took a lot of studying before I understood how their sketch worked and was able to modify it to perform the additional functions required by this project.
In the same manner that the block diagram served as a road map for the rig's hardware, I sketched (pencil and paper - too ugly to post!) a flow-chart for the sketch and wrote modular "functions" for each, well, function of the software. Each function is analogous to a hardware module - they can be developed independent of the main program, and subsequently refined individually without disrupting other parts of the code.
While I don't want to share my ugly flow-chart for the entire sketch, here's how I keep the functions organized on my hard drive:
Notice that I keep to a standard that I've developed for myself to maintain version control - this becomes increasingly important as the code grows longer. I think that'll be the next entry into this crazy blog - it's absolutely essential to keep track of where you've been in order to get where you want to go.
I can't imagine successfully homebrewing anything more complicated than perhaps a Michigan Mighty Mite without using the modular approach.
73 de N8NM
 |
| Top view of the SR-16 outside of it's cabinet. The circuit modules occupy space on four subchassis. Each subchassis is also modular in that it can be removed, tested and refined independent of the others. Modules containing modules. It's module madness! |
I suggest you take a look at GitHub as a place to store your code and it's history. It takes a little bit to learn but you will find that it's a much cleaner and easier to maintain way of managing your code.
ReplyDeleteI love the idea of modularity. Thanks for sharing this!
Thanks, Aaron!
DeleteI'll check that out; I've gotten stuff that other's have done from GitHub, but never looked into it as a storage/management tool.