All:

I think Chuck Adams has the right approach to this. His video series on YouTube for building W8DIZ's 1 Watter () has a lot of good stuff about kit building in general.

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!

Jack, W8TEE

On Friday, April 27, 2018, 8:35:43 PM EDT, Howard Fidel <sonic1@...> wrote:

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 Raduino.

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?/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 terminal...ideas welcomed.

All the best,

73, John (VK2ETA)

there are just a few challenges and many ways to meet them in transiting to 435 MHz, VHF is just a milestone along the way. The idea of making something on VHF/UHF is no longer economically justified if you are doing it just to save money. You can buy a baofeng for twenty dollars. Probably, it is a good idea to do that in anycase, you will have a ready rig to test your homebrew with.

The local oscillator:
The first challenge is to get a local oscillator going at around 400 MHz. There are three ways to do it:
- A crystal oscillator with a multiplier chain. This needs you to have a good way to sniff RF frequencies. A wavemeter of a lecher line would do the trick.
- Just triple the Si5351. This means, you need to tune just one bandpass filter at 435 MHz
- Use an Si589 or Si570, LVDS version. This costs as much as a Baofeng, you can order it from Mouser.

Architecture: The options are:
- Two diode mixers that directly mix down to audio, to make a phasing, direct conversion transceiver. This is simple, it involves cutting a phase line down by millimeters until you get the phase angle right. But you don't dabble with all the fun (really??) of a superhet.
- Single conversion to 20-25 MHz IF with stripline filters to keep the image rejection high, it is a bitx from the other side
- double conversion to 45 MHz, this throws the image to around 350 MHz, easily suppressed by LC bandpass filters.

Modulation/Demodulation:
There are many ways to achieve it. You can build analog mod/demod with conventional technology as done in the bitx transceivers. Or...
add an SDR back-end (if you are lazy).

What do you guys think?

- f




On Saturday 28 April 2018 08:32 AM, Tim Gorman wrote:

Respectfully, as Allison points out, it's not just the PA active element
that will be the problem. When your frequency width is an order of
magnitude, e.g. 14Mhz to 144Mhz, you begin to run into all kinds of
issues with components. Lead lengths and circuit trace lengths/widths
at 2m cause many more problems than at 14Mhz. It gets even worse at
432Mhz.

I agree with others on here. It would be a lot more feasible to do one
band modules, e.g. one for 2m and another one for 432Mhz, that are
small enough they could be placed in one case along with a ubitx
being used as an IF amplifier.

tim ab0wr

On Sat, 28 Apr 2018 01:12:16 +0000
"Ashhar Farhan" <farhanbox@...> wrote:

Allison,
For a power chain of about 5 watts that goes from 50 mhz to 500 mhz,
what would be your recommendations? The RD15HVF1 seems to be used
frequently at 435 Mhz. Are there any broadband alternatives? What
kind of cores can we use at UHF?
- f

On Sat, 28 Apr 2018, 06:37 ajparent1/KB1GMX, <kb1gmx@...> wrote:

Several things, like others have repeatedly pointed out the uBITX
is very unsuited for FM or AM.
FM needs wider filter and far more gain to get the needed limiting
action.? Its not drop in its full
replacement.? A Baofeng UV5R goes for 30 bucks and does 2M and
70CM.??? AM there are
issues with drive level and sustained power out, that and its
sparsely used.? My opinion is
that if you want all that get a FT817, its a do all and has a noise
blanker.

To get the front end to cover VHF the LO system deliver a VHF LO
(95mhz for 6M, about 99 or 189mhz for 2m)
and the input filter needs to pass the VHF band and not a low
pass.? IF memory sers the 5351 can go to 220Mhz
A LNA before the mixer would be required for reasonable performance.
For UHF if you had a version of the
5351 or maybe used a si570 flavor to generate the LO and an
improved mixer 432 is possible but its more
effort and would likely need a board redesign.

UHF is better done with a competent converter/transverter with a
404mhz LO and run that into a uBitx at 28mhz.

In all cases 6 though 70cm the tx power chain would need work as the
drivers are all 300mhz FT devices
just will not do it.?? The IRF510 I've used at 50mhz as a monoband
linear and its respectable
(40+W for push pull @ 28V properly done for 6M only) but I think
maybe 70mhz is a stretch without
first trying.? In all cases the TX chain is mono band only as VHF
impedance matching from stage
to stage is required. Just dropping in higher FT devices will not
help its a across the board redesign
for a specific band.

Receiving is easy enough, transmit above 50mhz is going to be
harder.


Allison

Respectfully, as Allison points out, it's not just the PA active element
that will be the problem. When your frequency width is an order of
magnitude, e.g. 14Mhz to 144Mhz, you begin to run into all kinds of
issues with components. Lead lengths and circuit trace lengths/widths
at 2m cause many more problems than at 14Mhz. It gets even worse at
432Mhz.

I agree with others on here. It would be a lot more feasible to do one
band modules, e.g. one for 2m and another one for 432Mhz, that are
small enough they could be placed in one case along with a ubitx
being used as an IF amplifier.

tim ab0wr

On Sat, 28 Apr 2018 01:12:16 +0000
"Ashhar Farhan" <farhanbox@...> wrote:

Allison,
For a power chain of about 5 watts that goes from 50 mhz to 500 mhz,
what would be your recommendations? The RD15HVF1 seems to be used
frequently at 435 Mhz. Are there any broadband alternatives? What
kind of cores can we use at UHF?
- f

On Sat, 28 Apr 2018, 06:37 ajparent1/KB1GMX, <kb1gmx@...> wrote:

Several things, like others have repeatedly pointed out the uBITX
is very unsuited for FM or AM.
FM needs wider filter and far more gain to get the needed limiting
action. Its not drop in its full
replacement. A Baofeng UV5R goes for 30 bucks and does 2M and
70CM. AM there are
issues with drive level and sustained power out, that and its
sparsely used. My opinion is
that if you want all that get a FT817, its a do all and has a noise
blanker.

To get the front end to cover VHF the LO system deliver a VHF LO
(95mhz for 6M, about 99 or 189mhz for 2m)
and the input filter needs to pass the VHF band and not a low
pass. IF memory sers the 5351 can go to 220Mhz
A LNA before the mixer would be required for reasonable performance.
For UHF if you had a version of the
5351 or maybe used a si570 flavor to generate the LO and an
improved mixer 432 is possible but its more
effort and would likely need a board redesign.

UHF is better done with a competent converter/transverter with a
404mhz LO and run that into a uBitx at 28mhz.

In all cases 6 though 70cm the tx power chain would need work as the
drivers are all 300mhz FT devices
just will not do it. The IRF510 I've used at 50mhz as a monoband
linear and its respectable
(40+W for push pull @ 28V properly done for 6M only) but I think
maybe 70mhz is a stretch without
first trying. In all cases the TX chain is mono band only as VHF
impedance matching from stage
to stage is required. Just dropping in higher FT devices will not
help its a across the board redesign
for a specific band.

Receiving is easy enough, transmit above 50mhz is going to be
harder.


Allison

?

All:

I think Chuck Adams has the right approach to this. His video series on YouTube for building W8DIZ's 1 Watter () has a lot of good stuff about kit building in general.

?

? 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!

Jack, W8TEE

?

?

On Friday, April 27, 2018, 8:35:43 PM EDT, Howard Fidel <sonic1@...> wrote:

?

?

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 Raduino.

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?/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 terminal...ideas welcomed.

All the best,

73, John (VK2ETA)

?

I have started developing a diagnostic software for the uBitx.?

The need arose following a forum member's trouble with his Raduino.

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?/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 terminal...ideas welcomed.

All the best,

73, John (VK2ETA)

I have started developing a diagnostic software for the uBitx.?

The need arose following a forum member's trouble with his Raduino.

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?/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 terminal...ideas welcomed.

All the best,

73, John (VK2ETA)