David Wilcox <Djwilcox01@...>
toggle quoted messageShow quoted text
I, a 73 y/o ham of 63 years fully agree. I love this new radio stuff but getting it to work after it is built is sometimes a head scratching problem even with the help of all my .io group friends.
Also, don't ever think you are wasting your time on these sites. I read 100 emails a day re my radio interests and am learning so much even about kits I haven't built yet. THANK YOU ALL!
On Apr 27, 2018, at 10:49 PM, Jack Purdum via Groups.Io <jjpurdum@...
1Watter Transceiver Build, Phase 1 by K7QO
A series of videos on the building of the kitsandparts.com 1W transceiver kit for $46 USD plus S&H. Available fo...
However, his approach addresses the subject line here: How do you diagnose problems with a homebrew or kit project. If you are going to use the µC as part of the process, it would be much more successful if the diagnoses are done at stages along the way, rather than deferring until the project is done. It's much easier to diagnose a stage as it is built rather than waiting to a point where several stages can interact and be causing issues.
This suggests building the PS first, checking the voltages, etc. and pronouncing it "healthy". I would immediately then constuct the µC section, utilizing the the Serial object to verify it is working (e.g., the simple Blink program). Then (and you EE guys are better at deciding what's next) perhaps build the audio section and have program code that sends a 700Hz tone to the amplifier for replay through the headphones/speaker. If you get to a section where the test from the µC doesn't pass its test, you have limited the source of the error to the most recent section. It's the same concept as Encapsulation in software engineering.
My point is: If you're going to the trouble of building diagnostic software into the rig, utilize it through the entire construction process...don't defer it to the end. Not only does the approach enhance the odds of a working piece of equipment when the project is done, it builds confidence in the builder along the way--a double win!
On Friday, April 27, 2018, 8:35:43 PM EDT, Howard Fidel <sonic1@...
Great idea. If the Arduino only had
more inputs we could do a really thorough job with some mods.
On 4/27/2018 8:09 PM, John wrote:
I have started
developing a diagnostic software for the uBitx.
The need arose following a forum member's trouble with his
The objective is to help both the original kit builder for issues
like wiring or "not working" problems, but also to the more
advanced experimenters both during construction and after "oops
moments" like after a bad wiring or when a loose lead that "is
only there for 5 seconds and will never touch another part of the
circuit" went wandering around the board (I raise my hand here).
So far it only tests the I2C bus, the communication with the
SI5351 and the analogue inputs of the Raduino in a graphical form.
The plan is to expand to the audio circuit, the receiver chain,
the TX low pass filters' relays and hopefully more.
This is where I need your input to determine what to test for in
the first instance and then some ideas to make the test results as
simple but still useful to more advanced users.
So if you can give me some feedback as to what issues you had when
building the kit that I could incorporate in the diagnostic
software either as a new test or as a suggestion as to how solve
the issue, as a self help, that would be great.
Tests need not be Arduino only tests. Operator 's interpretation,
as in "Do you hear the tone in the speaker, Y/N" are quite ok.
I have uploaded the beta version of the software at https://groups.io/g/BITX20/files/uBitx%20Diagnostic%20software%20by%20VK2ETA/ubitx-Diagnostic%20-%20Version%20B0.2-2018-04-28.zip
Passed the tests are the questions of deployment and the best way
to do that since new kit builders may not be familiar or confident
to setup the Arduino's IDE. So maybe HEx files and a simple
All the best,
73, John (VK2ETA)