Will put together the final piece that allows us to finally put this project in to the sunset phase.
He confirmed by rolling back the compiler to GCC 4.3.3 (the original compiled version) we could get the unit to actually work as it is supposed to. Apparently, AVR-GCC is available usually through microchip or some various locations and older versions are not available readily. So Will ended up snooping He did it through this GitHub repository (https://github.com/smeshlink/Arduino-Plus/tree/master) a fork of the Arduino main line development from 2013 (11 years ago now!). That repo happened to upload the old AVR-GCC version and will pulled it down and started the compile.
Now, I was warned about this over by the original developer. See the post I read once or twice back when I had all those issues with what ended up being the AVR fuses…
Found wisdom of the comments
I suppose until you have gone down the rabbit hole you don’t really understand what not guaranteed to work really means.
I’ve yet to recompile on my end, but using Will’s compiled build removes all of the chaotic behavior the synthesizer was showing before. One of the points of code that is likely quite dependent on this compiler version is a snippet that occurs in the editor.cc file.
Note that this function does a direct read of program memory via the pgm_read_byte() function. This function is used to directly read pgm memory. In this case, the code works to reading flash out into memory at a specific address as command. Now this could work but the method of using “programmer_switch_mapping + that index means at some point the compiler (no matter how good it is) is not aware of this memory location. The call in this case requires foreknowledge of where this given piece of information resides in active memory. The compiler is unable to check for any sort of error condition in the way it is written. For all it cares, the compiler is presented with a sum of two numbers before passing up to pgm_read_byte. No checks can be done on whether the memory is valid or not or if there is anything at the target address.
I can imagine something like this was done to same memory usage in a constrained design (to do: is there a linker output report?) if you aren’t going to use up these things as much in the code space. But again this is mere speculation. At least at the moment we have functioning products.
New PWBs and manufacturing errors
I received a new set of PWBS this week. I was excited to build and started soldering them up when I saw this
Note those cuts in the PWB
Traces broken in multiple sections of the board from what looks like a razor blade or something run across the board. Whats odd is its just one out of the group of boards so I didn’t lose my entire $230 on these from OSH park. I emailed them out and received a very quick response. They let me know this board should have been screened out of my order as a test sample and I’ve gotten the extra boards as a show of good faith.
I do like the aesthetic of the clear solder mask style, but with so much of the copper plane covering each side I think I’ve lost the cool factor that would have come with more black.
“It’s possible the fab was attempting to indicate an etching failure on that one copy. During AOI testing they’ll scratch the traces, which lets someone else down the line know to mark it with a big silver “X” so we can notice it and get a replacement started. “
Onward to soldering up this round of boards and getting prototypes out to my friends. Will is still on the enclosure part then we can start packing this project up.
Roadmap
Build the remainder of analog and digital units
Send them to friends!
Design and fab cases for these synths
Create a lessons learned
Random Observations
Until this point my head was so deep in the design I never questioned the original name of this synth the Shruthi. I happened to mis type a google search and I learned that this is an accordion like drone instrument out of India. Some links below.
https://gcc.gnu.org/releases.html I’m not quite sure about my AVR-GCC comments any more or even whether or not AVR-GCC is just standard GCC wrapped with some libraries. I have gotten turned around on this on. Something to report back on in another post.
Its hard to believe how much (or how little) can happen in five months. So I wanted to do an update on where I’ve gotten to on this Shruthi synthesizer project since February. At this point I expected to be wrapped and building units two and three, but things rarely go so close to plan.
So far this project has tackled:
PWB design
Analog electronic analysis
Source control and Git when working in an emulated version of Ubuntu
Logistics on buying parts and when in 2023 you can and cant get them.
How to keep sane when you cant fit all of your equipment in your apartment.
How to manage workflow going between a lab in your parents basement and your own place.
Time management around this hobby project, personal crises and relationships, and the day job.
But the biggest realization is running this sort of project for me is that I need a better system for this sort of work. That system should be easy to make a habit out of.
The plan was to make very clean summary blog posts of each phase as i went through the project. The second post on buying the components and the PWB has been in draft for quite some time now even though there are many words written. There’s nothing that is inherently problematic about that post, its just that formalizing it and feeling “comfortable” releasing that article is entirely independent from where I’m at in the project today.
Today I’m looking at the two Highest bits of parallel data signals toggling to the OLED display and they are active and look to be reasonable transition times!
But when I inspect the front display there is no active OLED display activity…..
👎👎👎👎
I’ve built two prototypes (this one performing better than the first one I butchered with some trace destruction. So now I’m grappling with a few other ideas Id like to explore more as this project moves forward.
How to synchronize work across multiple computers
This has been easily the slowest process. I could have kept it basic and done a google drive of everything months ago but I insisted on using Git to its full intent and not what works for me. I’m glad for the experience but more calories have been spent in pulling my Digikey order googling the the same datasheet on multiple machines that I’d like to mention.
Other options are out there I’m sure and Git should work I think too but deciding on this is a task in itself that gets me away from the hardware.
How to prioritize work
I had an instinct this was going to happen but it was only magnified with personal issues with my family over the time I had to tend to. Quick takeaway is that this project needs space in my week without the consideration of what I’m going to do once I get there. Preparing for the next week may be a better matter of keeping documentation organized and available to jump in no matter what location
How to keep the right tools available
I bought quite a few things so far on this project that haven’t gone into the hardware. Flux, Solder Iron tips, a new drafting chair after my back was hurting, magnifier glasses. But I’ve also made the mistake of taking have soldered assemblies back to my apartment with my o scope and needing either a 9V adapter or a DMM i didn’t bring back. Maybe the solution here is to have a semi “mobile” lab setup if I’m going to do certain tasks in one place as opposed to another, and just pack it up each time.
How to get a more systematic hardware bring up plan.
On the last one I think I couldn’t have known that ahead of what I experienced.
How can this be so? The display gets a clearly intentional signals from the micro (pins are wiggling correctly) but it does nothing to drive the display with anything meaningful. Could this be a pin assignment issue?
Parallel Data lines (DB7, DB6) From Micro To NHD-0216KZW-AG5
Schematics indicate the same pins are used to connect to this Display. The other oddity is that the control pins look deliberately controlled. Pin 5 (R/W MPU Read/Write select signal, R/W=1: Read; R/W: =0: Write) stays Low. Pin 6 (E MPU Operation enable signal. Falling edge triggered) always high. Since I didn’t write this code I’m not sure how the firmware could screw this up in this partial manner. Could a transfer to the device really be occurring that would have some pins activate and others stay high???
A fork is a personal copy of an existing Github project that the developer can do to with whatever you like. A developer can work on their own stuff in their protected bubble and then “push” back up the changes to the original project and thread if the original project wants to incorporate the forked features. A fork is in contrast to a branch, another agile software development term. A branch means a developer takes a copy a project (just like with a fork) with the goal of correcting one or more “issues” or “bugs” that the developer is interested in fixing. By creating the branch everyone on the project is aware of what the developer is trying to fix but they can go off their bubble with the intent that my changes will be compiled and tested solo. Then a kindly wizard associated in the project one day will allow me to “merge” those changes back in to the main Tree of the project.1
A good infograhic from theserverside.com
So merging gets complicated when we are dealing with files in different electronics CAD packages instead of lines of code. I will use transitioning development software platforms from Eagle (as I will discuss below) to KiCad as an example. If I compared the actual schematic design files on my local hard drive you would be left with a long list of changes of the bits and bytes that no human can use to track changes happened. The file extensions you save into are different the GUI interface is different, none of this can just transfer from one platform to another without a person in the loop. So for this project, I will create a branch and leave breadcrumbs in the Readme.txt file for those curious to work their way back.
After inspecting the original files in the shruthi/hardware_design/pcb folder, I discover these files were originally developed in Eagle 6. The PWB folder contains two types of files .sch and .brd. Currently Eagle is up to version 9.0 and no longer available without bundling together with some other AutoDesk features, which is exactly why the goal is to take these files out of something not exactly maintainable and to move it to Kicad.
Going back to the design folder and searching around this /pwb directory is what I am looking for. These are the schematic and Printed Wiring Board files for multiple designs in the project. 14 designed boards with schematic and PWB design files!
The Github Shruthi PWB directory
After converting all the schematic files over to inspect them, I found that the original Shruthi product concept isn’t to have fourteen PWB’s on one assembly, but to have the end user select analog boards and plug it into the digital control board, and if the musician wants they can swap between boards for different voices. From the archives, i can see there was an original control board (powered by a micro controller), but at some point theXT versionof the Shruthi was released. This version exposed more encoder controls that were hidden behind menus and clicking buttons in lists within the original. For this project it means there may be more pots and buttons to solder, but more fun to mess with when it all works at the end.
I’m going to limit the scope here and after looking back at thebuild documentation I’m going to start working with two specific boards, the SMR4 mkII_V02. which is a four pole “Roland like” analog filter board, mark II being the second version of this and V02 being the second revision of the second generation.
With these two boards chosen the work begins. Kicad in theory supports Eagle file import but not from the old Eagle files used 12 years ago on the Shruthi2.. So to start, I have to open Eagle to get these Eagle 6 boards rolled up to the newest version and spent a few hours installing this Autodesk Eagle combination, opening the files and then saving them again to be current Eagle files. Once that was completed Kicad successfully recognized the files and could import them.
Kicad and PWB Updates
Kicad Up and Running with the Converted Board File
Now I would just congratulate myself and crack a beer in victory, but I didn’t realize the work had just begun. I had discovered one of the main components for the Analog section of the Synthesizer the LM13700 no longer existed in a PDIP package.
I figured I could solder surface mount (more on that later) and could easily swap out the SOIC version for the PDIP. So I set to work making a new footprint for the part and rewiring the schematic and PWB file to ensure my new part fit. It ended up fitting fine as it was smaller than before but because of the shrinking of the component other assumptions about signal and ground trace lengths had to change and i ended up rerouting more than i planned. I still maintained the two layer setup but much was streamlined and moved from the original SMR_mkII_V02 design to the new SMR_VJK3.
I was lead through the process by the very useful Kicad documentation as well as remembering my old scars using electronics design tools at my day job. Kicad by far was an easier flow than other packages Id used before.
Imported Original Analog Filter BoardImported Original Schematic
Theory: Transconductance Amplifiers
Lets talk about the nitty gritty of the design. So the PWB is quite simple once I got my head around it. It is only a two layer board, with a handful of different through hole parts. Having been the “analog guy” for a few years now the Voltage to current mode transformation of the LM13700 was very interesting. Whats more is that it seems to be a common mode of operation with classic analog synthesizers. Control of the audio signal path is done via potentiometer DC setting the current through these trans conductance amplifiers. This is done both in the gain section of the design as well as the filter section. So the voltage is fixed but the resistance changes and that shifts the level. The diagram below shows an example circuit. So for the gain stage at least its quite obvious that your base current in the output is a function of the gain setting voltage. The current sources used in this application are actually exponential in relationship to the output signal.
LM13700 Example Circuit
And here it is in action within the LPF analog filter board in the Shruthi.
Note the Amplifier with the two large circles
So you can see there’s an off board potentiometer that controls the I_GAIN current and then gets buffered before being driving out the line level cable. I’d love to get deeper into how this is all working (and I Imagine I will in bring-up) but lets get back to the task at hand. The PWB update and removing the PDIP to get an SOIC into the design. Well whacking in the new pads was a piece of cake but since everything got smaller many small changes rippled through the rest of the board.
Back to Board updates
Larger pins mean larger and thicker traces, and once i shrink the pins the room you had is reduced. The thickness of the old device allowed of running voltage rails underneath the part, once i shrunk down to the SOIC i lost all room to do that trick and had to move the rails out from underneath. Now that the power was routed outside, I had to re route the signal traces under or around what Was already there. And finally I noticed a few things i didn’t like so I had to deal with those.
Original Layout of DIP LM13700NNew Layout of the Same Section.
Some other highlights. The DRC settings were set to roughly default but I did space the VDD and VSS on the LM13700’s to be further spaced apart than the older design. My Thought was that the pads also shrunk so any more copper wont move the needle very much. Although we will see in the testing where that ends up.
Overview of the New PWB design
You can take a look at the full design and Kicad files at the project directory for the project.
The next section will be about purchasing the parts for the build as well as an over view of the assembly. The final post will be about testing the end product and lessons learned.
Since the time I started this project is now at 7.02 and will probably be further along by the time I post https://www.kicad.org/blog/
SOIC versus PDIP comparison of footprints.
Pinchettes does a much better job than me at actually explaining the theory of the VCO/VCF/VCA. At this point im merely an observer until the day I have to debug the thing.
Liftoff describes a life and a situation that although not as exciting as it may be I have experienced. The early days of SpaceX walk the line that is out of vogue now, but can become intoxicating if you catch it. When people have hard work to do, and are allowed to do it with almost 100% of their waking energy, great things can happen. Additionally getting the right folks on projects like this is truly helping an addict get what they need and it may never happen for more than a few years in their lives.
It may seem minor, but the early actors at SpaceX are filled with people with very little else that moves their needle than rocketry and many of those people lose other things because of the desire for space flight. The double edged sword of hard work (in my view) is that we cant have it all, you only have enough power to do so many things no matter how little you sleep and when you set off to build a rocket you either see it to the end and at all costs you can give or you go to some other job where you can be happy work and go home. I’m sure some people see that as pure madness and some see that as excitement. Maybe I’m jealous but i did notice a few details again that allowed the crew here to push everything into their work, living at the office literally, being removed from any other environment worth relaxing in (the first phase of launches described here happened in Quag totally remote) being straight out of college and obsessed with learning something for the first time.
On the optimistic side, whenever something when wrong whether it was minor corrosion on an unsealed fuel tank or something else. I got to feel the same comradely when i flipped an op amp backwards or something melted in the oven when running right to 86C when 85 was just fine. Engineering or really problem solving for its drawbacks still flips a switch for me and as I get older I can now see that as a little more of a strength than a liability.
Also orbital mechanics is one of those “hard/not hard” kind of things which is why i kept the space and Low Earth orbit theme going by reading Seveneves later in the yaer.
John (Jake) Kolb III 