Read the README file!

Hello all.

I hope everyone is staying sane in these interesting times!
I find retreating to my shop is often a good way of keeping sane, so make stuff! It helps!

We had another STEM club meeting last week and this time we had media presence! There's a brief shot of my sweater helping kid1 with the project but most of the footage is, rightfully, of Ralph and the kids (Kid2, seen below in his yogurt bedecked shirt was disappointed that he didn't make the news.). This weeks project was hoop gliders. They're simple little things, made up of a straw and some some strips of paper, but they fly surprisingly well. The concept Ralph was trying to get across was actually iteration and documentation. He tried to communicate the idea of controlled experimentation by having them change one piece at a time and seeing how the resulting glider performed. Of course it devolved into a mass of straws and paper wings, but that's to be expected. I only had to retrieve one glider from the stacks this time around.





I've made some progress on the BITX40! With the expert help of Yves D., Engineer Extraordinaire, I was able to locate the issue in the Arduino code that was causing so many compiling errors in my hack-up of the Si5351-Arduino VFO circuit.

Days of internet research returned no results for the error I was seeing (at least, no results that my novice experience could parse). The key was Yves' comment that the only issue with open source software like Arduino code is that the same iteration and documentation process Ralph was trying to communicate to the kids is mostly non-existent. The code gets changed for whatever reason, sometimes good ones, but that the changes don't tend to propagate across the larger community very well. That spurred me on to dig a bit deeper into the files included with the newest sketch. Finally, I found and dug into the wall of text that is the README file for the VFO sketch and sure enough, listed in there is a description of changes that were made to the libraries which require some minor tweaking of the code to compile properly. Now, of course, that README file was available to me the whole time, but it took me embarrassingly long to find it. So there are two morals to this story: first read the README files! All of them! Second, document your modifications. Do it one at a time, and write them out clearly so that you or some other poor soul who comes after you, can see the changes you made and make the appropriate modifications. If the original author hadn't documented properly I would have had very little hope of coming up with working code. Of course I had to look in the right place to find the answers I was looking for, but knowing where to look is often the hardest part of problem solving.

Lastly, at the recommendation of Micheal, N1FBZ, who I think was horrified to learn that I did not have a frequency counter, I picked up this $12 cymometer on eBay. I've got it "boxed" up in a piece of PVC and I'm actually pretty happy with the way it came out. My wife thinks it looks like an explosive device from some movie. I tested it out on the VFO circuit for the DC Receiver project and was happy with both the performance of the meter and the fact that it showed the VFO right where I want it to be. It tunes from about 6.8 to 7.4 MHz. It's a bit wide, but that's no big deal.

OK, I'm done, quit reading and go build something!

73 de KB1VNA
Eric

And Now, Back To Our Show!

OK, don't look now, but I think we all made it through the holidays.

Sorry for the radio silence. I had at least three posts planned since just before the holiday started, but let the crazy of the season get the better of me. Fortunately, I've got some new toys to play with and some projects to report on, so all is not lost!

First and foremost, the last STEM club meeting at the school was back just before the school holiday break. Ralph had them making hovercraft this time around, and as could be expected, the balloons were barely contained. (We did lose at least one to the stacks in the library.) Here's a short video of the project.

The concept is simple enough. The air escaping the balloon provides lift through some small holes in the cap on the PVC tube you can see between the balloon and the circular base. A little bit of rotation is applied when the balloon, twisted to keep the air in, is released, and a bit of a push sends it down the table. It was interesting to see how quickly the elasticity of the balloons degraded and how much that affected the performance of the design. I'm not sure what's next on the agenda, but I'm pretty sure Ralph will have them flying something around the library. As always, our thanks to the long-suffering staff of the Fairfax Community Library, and none of this would be possible without Ralph's remarkable efforts to part out all these kits.

The second thing I'd like to talk about is actually a couple things rolled into one under a larger theme. The two main projects I've got on the bench are the same ones that have been there for an increasingly embarrassing length of time. The 40m direct conversion receiver and the tuning mechanism for the BITX40. I took the 40m receiver and my BitSope Oscilloscope over to Nerd Night at a local IBMer's house where Nerd royalty gathers once a week to break bread(board) together. The good news was that my BitScope was not reading properly and I actually was pretty close to 7MHz with the oscillator circuit. The bad news was that my BitScope was not reading properly. So I've got some research to do and hopefully it's not a lost cause. The BITX40 case is nearly done, and I've assembled the SI5351/Arduino system to act as the Direct Digital Synthesis (DDS) unit for the transceiver. The bad news is that I'm rubbish at arduino coding and applying the scripts I've found online is an exercise in frustration. That brings me to my overarching theme. Failure. The reason why the DC receiver project has been on my desk for so long is that it's not working right. Something's wrong in the circuit somewhere and I'm having trouble nailing it down. The BITX40 would be done by now if I could get that stinking arduino code to work. I keep getting errors in the Integrated Development Environment (IDE) when compiling. That doesn't mean I'm giving up, by any means. It's frustrating, sure, and I've got plenty of projects stuffed away in various corners due to frustration at failed attempts, and there's always another project to try. 

It's easy to get discouraged when we see projects on web or see them at a Maker Faire, or magazine somewhere. We generally only see the good stuff. The ones that worked. The plane that flew, or the circuit that didn't explode dramatically (like that electrolytic capacitor that went BANG on me the other day! Fun!). We tend to show off our successes, and we should! They deserve to be to celebrated, but lets celebrate our failures too. That's where things actually make progress anyway, where we really learn. There's a quote attributed to Isaac Asimov that goes something like this: 

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' (I found it!) but, 'That's funny...'"

Who knows if he actually said it, but I love the sentiment. It's the unexpected result that teaches.

I think next year for Maker Faire I'm going to see if I can get some local nerds to contribute and get together a "Maker Fails" table. Stuff that Did Not Work. I think I'll divide it in two parts, stuff people want suggestions for, and stuff people do not want suggestions for. Maybe I'll have a "Free Failed Experiments!" area too.

73 de KB1VNA