Date   
Re: Modular uBitx - "Ex: Harmonics"

Russ Hines
 

Here's to a free and independent India.  Happy birthday. 

And thank you, Ashhar Farhan, for making this versatile platform available.

Salute!
Russ Hines
JMS & Associates, Inc.
SBE CSRE
WB8ZCC
--
Reply to: russ@...
On 8/14/2018 11:10 PM, Ashhar Farhan wrote:

Peeps, Jack, 
I hope that it is clear to everyone that ubitx is an open design. There is no restriction on anyone kitting it and selling products based on it. I would encourage people to try their hand and running it even as a business.
There is no challenge to hf sigs, really. There are more radios to be built and shipped than what hfsigs can ever do. Do go ahead and branch off. Cooperation beats competition each time!
Happy independence day to all my friends who believe in the idea of India! 
73, f. 

On Wed, 15 Aug 2018, 08:23 Jack Purdum via Groups.Io, <jjpurdum=yahoo.com@groups.io> wrote:
This is what we used for the antenna analyzer (QST, Nov., 2017). The only reason I switched away from it was its clock speed. At 16MHz, it just wasn't up to the DSP power we needed.

Jack, W8TEE


On Tuesday, August 14, 2018, 9:57:21 PM EDT, Adrian Waiblinger <vk5zbr@...> wrote:


Keep a option for 630m band too. 
If to hard an output from the Nano to drive the external 630m pa relay / 

Regards 
Adrian 


On 15 Aug 2018, at 10:44 am, Nick VK4PP <nickpullen@...> wrote:

One of these?
Image result for mini mega 2560

Re: Arduino Hangs

John (vk2eta)
 

Hello Howard,

Based on what you describe I suspect an issue with the I2C bus.

Suggested tests would be either to
a) Comment out the wire.xxxx call lines in the si5351 tab or
b) Load my test program (in the file section) as it performs 3 gradual tests of the bus, including writing to the si5351 but with a timeout. So it will always return a result, positive or negative.

From memory the wire library uses blocking call for sending data over the bus. So if the communication is not possible it would hang there.

Reasons could be defective nano A4/A5, short/open circuit in bus lines, defective si5351.

73, John (VK2ETA)

Re: Spurs - BPF fix? #ubitx

ajparent1/KB1GMX <kb1gmx@...>
 

ARV,

>>Inductors are interesting in Spice simulations.  Usually the amount of resistance in a couple 
feet of AWG-20 is so insignificant as to have any large effect on performance.  I <<

There are several effects one is the DC resistance of the wire which is small. Then the AC
resistance due to skin effect and this varies with frequency and surface area of the wire.
Of course we have inductance as well.

The presence of all of those are what is called Q.  Higher Q is typical of large outer
diameter conductors or even tube, low DC resistance and low intertrun capacitance.

SMT inductors generally fall on the range of 40-70 not great but useful.  Some like
Coilcraft mini and maxi spring are better.  A good inductor using toroid and thick wire
might hit 250 though 200-225 is typical.  

With all that said adding resistor to the perfect devices of LT-spice (or others
like Genesys) is part of trying to make them look real.  Most spice/sim programs
have spaces for user parts when you get to fill in the real part behavior which in
many cases are available from the various vendors.

Capacitors are pretty much the same game save for the ESR is important.
Decent caps MLCC, Mica, ATC, polystyrene, and some ceramics can have
very high Q.  However some ceramics are not and its not important for their
general (bypass, coupling) use but it makes them not very useful for some
types of RF circuits like tuned circuits and filters.

If there is anything to take away is be aware of the parts in use.  Q is only
one factor.  Current handling is a concern at higher power, and self inductance 
and self resonance are as well.  To answer those questions one god to catalogs
and data sheets.  Remembering what was done before that worked also counts.

Allison

OT: Any new projects?

Alan Jones <oalanjones@...>
 

Ashhar,
Just out of curiosity, do you have any new projects you are working on?

Al, N8WQ


Re: Harmonics

Rahul Srivastava
 

This is great news Allison, I offer to layout the boards and make the files obtanium ...

Rahul VU3WJM

Re: Arduino Hangs

Howard Fidel
 

John:
I did find a short between D3-D4-D5 under the connector to the uBitx main board. I don't know how that happened, since I didn't touch that connector doing the rework. Anyway, the problem didn't go away after clearing the shorts. I loaded your ubitx_diagnostic and it also hangs with the version on the display. It seems it is not getting to the I2C bus section? Or do I have the wrong program?

Thanks,
Howard

On 8/15/2018 9:48 AM, John wrote:
Hello Howard,

Based on what you describe I suspect an issue with the I2C bus.

Suggested tests would be either to
a) Comment out the wire.xxxx call lines in the si5351 tab or
b) Load my test program (in the file section) as it performs 3 gradual tests of the bus, including writing to the si5351 but with a timeout. So it will always return a result, positive or negative.

From memory the wire library uses blocking call for sending data over the bus. So if the communication is not possible it would hang there.

Reasons could be defective nano A4/A5, short/open circuit in bus lines, defective si5351.

73, John (VK2ETA)


Re: uBitx v4 plus 3 AGC kits and 3 Pop Fix kits for sale

Lawrence Macionski <am_fm_radio@...>
 

Carl - Check your Email.. I need your paypal info...

Re: Arduino Hangs

Howard Fidel
 

John:
I added a print statement before and after the first i2c write and it is definitely the I2C that is hanging up, it doesn't get through the write statements. Great call!
Now I have to figure out if that chip also died, or if there is another issue. I've got to leave for a while, so I probably won't look at it again until tonight.

Howard

On 8/15/2018 9:48 AM, John wrote:
Hello Howard,

Based on what you describe I suspect an issue with the I2C bus.

Suggested tests would be either to
a) Comment out the wire.xxxx call lines in the si5351 tab or
b) Load my test program (in the file section) as it performs 3 gradual tests of the bus, including writing to the si5351 but with a timeout. So it will always return a result, positive or negative.

From memory the wire library uses blocking call for sending data over the bus. So if the communication is not possible it would hang there.

Reasons could be defective nano A4/A5, short/open circuit in bus lines, defective si5351.

73, John (VK2ETA)


Re: uBitx v4 plus 3 AGC kits and 3 Pop Fix kits for sale

RCBoatGuy
 

Lawrence,

I've replied to the email you sent earlier.  

Many thanks,

Carl

Re: Harmonics

ajparent1/KB1GMX <kb1gmx@...>
 

One item to note...

All the stitching, those are the vias fro top ground to bottom ground.

I have a bin full of those relays and they are compact, inexpensive,
and good at RF.

Allison

Re: Arduino Hangs

James Lynes
 

Jack:

Good idea!

Would be nice to have a loop-back cable, set 1/2 I/Os to input and 1/2 to output. Cycle the pins and display to serial monitor. Reverse ins and outs and repeat.

Haven't had good diagnostics since PCs killed minis. Data General NMORT could find anything as long as you remembered that a failed multiple/divide test meant that the card reader cable was loose.

James

Re: Modular uBitx - "Ex: Harmonics"

ajparent1/KB1GMX <kb1gmx@...>
 

All,

Thoughts mostly as applied to making ubitx or bitx modular.  From start good idea.
Breaking it into modules allows one to solve issues as they arise like power amp
isn't good enough build and replace a new one.  IT takes all the ugly fixes out as 
now a module deemed less than desired can have a new or modified one substituted.

Now lots of questions:
Many of the uBitx problems are related to:
 Board layout (many cases of good circuit compromised)
 Filtering circuits (and their layout)
 Gain distribution, some places not enough other way too much.
 Power amp performance (power fall off and instability).

These are for  TX path only:
How much gain is planed for the path starting at the balanced modulator
(not the audio before that is also low gain) though all the filters and possible
mixer to the last mixer?

How many devices are needed to supply that?

How much audio gain, gain control, or compression?

once you have a signal(s) at the last mixer what is the filtering scheme to
insure a reasonable spectral purity ant the input to the power amp?

How much gain and its distribution in the power amplifier?

Just an opening set of questions.

Building a radio is like building a house or bridge, you need an idea of what
size and how its going to look.  The foundation must be sound and support
the planed design.  For a Transceiver that is the basic RF core.  Everything
else builds from there.

Also for the moment unless the MCU is doing DSP its not part of this save
for its integration must be clean referring to the paths from 5351(s) to the 
various points that signals are needed.  The MCU is the user interface only
and as stated unless its doing DSP it cannot enhance the signal.

On a different path.
Items I see as useful as in should have:

*SWR/power out measurement built in its trivial and everyone needs that.
*Ways and tools built in to help diagnose.  Others have done this and please
 read the Elecraft  K1 and K2 manual if this is not clear.  Its handy for those
 without lots of gear and a kindness for those of us that will use it.
* Consider BITE, Built In Test and Error report.  It can as simple as
 measuring the 12V in to assure you have enough DC power during
 transmit!  Another could be excess SWR, Excessive PA current (from
high SWR or Fault).  Simple and easy measurements.

Allison

Re: Modular uBitx - "Ex: Harmonics"

Jack, W8TEE
 

The MCU is the user interface only and as stated unless its doing DSP it cannot enhance the signal.

Exactly, which is why I think we need a relatively powerful µC with good library support. With some programming effort, Al was able to define these CW filters:
Inline image
plus we added a user-defined CW filter, too. We have similar filters for SSB. Software filters via DSP make such things so easy when compared to designing a fixed filter in hardware.

Jack, W8TEE



On Wednesday, August 15, 2018, 11:54:17 AM EDT, ajparent1/KB1GMX <kb1gmx@...> wrote:


All,

Thoughts mostly as applied to making ubitx or bitx modular.  From start good idea.
Breaking it into modules allows one to solve issues as they arise like power amp
isn't good enough build and replace a new one.  IT takes all the ugly fixes out as 
now a module deemed less than desired can have a new or modified one substituted.

Now lots of questions:
Many of the uBitx problems are related to:
 Board layout (many cases of good circuit compromised)
 Filtering circuits (and their layout)
 Gain distribution, some places not enough other way too much.
 Power amp performance (power fall off and instability).

These are for  TX path only:
How much gain is planed for the path starting at the balanced modulator
(not the audio before that is also low gain) though all the filters and possible
mixer to the last mixer?

How many devices are needed to supply that?

How much audio gain, gain control, or compression?

once you have a signal(s) at the last mixer what is the filtering scheme to
insure a reasonable spectral purity ant the input to the power amp?

How much gain and its distribution in the power amplifier?

Just an opening set of questions.

Building a radio is like building a house or bridge, you need an idea of what
size and how its going to look.  The foundation must be sound and support
the planed design.  For a Transceiver that is the basic RF core.  Everything
else builds from there.

Also for the moment unless the MCU is doing DSP its not part of this save
for its integration must be clean referring to the paths from 5351(s) to the 
various points that signals are needed.  The MCU is the user interface only
and as stated unless its doing DSP it cannot enhance the signal.

On a different path.
Items I see as useful as in should have:

*SWR/power out measurement built in its trivial and everyone needs that.
*Ways and tools built in to help diagnose.  Others have done this and please
 read the Elecraft  K1 and K2 manual if this is not clear.  Its handy for those
 without lots of gear and a kindness for those of us that will use it.
* Consider BITE, Built In Test and Error report.  It can as simple as
 measuring the 12V in to assure you have enough DC power during
 transmit!  Another could be excess SWR, Excessive PA current (from
high SWR or Fault).  Simple and easy measurements.

Allison

Re: Modular uBitx - "Ex: Harmonics"

ajparent1/KB1GMX <kb1gmx@...>
 

On Wed, Aug 15, 2018 at 01:41 AM, Henning Weddig wrote:

first IF > 45 MHz (to avoid the 2*IF - LO problem) using four pole xtal filters  e.g. 70 MHz (if easily avaliable)? Another "popular IF could be 58 MHz or 58.1125 MHz (used in Hagenuks cordless phones) My be enough NOS filters are laying around.

Henning,

The magic frequency is over 60 mhz. At 58.1125 the half IF is ~29.06mhz 
or the point where the 2IF minus LO will be one loud birdie (RX and TX).  
It moves the current issue up but not out.  Works for cell but not a 3-30mhz radio.

Band pass filters are easier.  As is we are asking a 300mhz transistor to work
marginally at 45mhz.  Going up makes that worse.  Better yet a better transistor.

1) receiver/exciter pcb

Makes the core a module and replaceable with improved or different technology
without having to toss everything else out with it.

2) xtal filter board for the second IF (e.g. 5 MHz) with filters for SSB; AM; FM(?), CW

FM again, why?  For 10M, easier to make a dedicated radio for that with 
a decent limiter for the RX.  Same for AM, 10W radio with full carrier AM
is 2.5W, not a power house.   It forces a decent power amp as well one
that an sustain full power.  Better to limit to SSB/CW.  Switched filters
makes sense.

2) input lowpass filter (corner freq. 1.6 MHz) plus  overlapping bandpass filters (e.g. 1.6 - 4MHz; 4 - 8 MHz, 8 - 16 MHz; 16 - 30 MHz)

Input highpass at 1.6mhz? Correct?  
Also not octave filter I presume you mean half or 2/3 octave filters so the second harmonic is not able to escape.
The the 2/3 octave lineup results in a large umber of filters unless their corners are suitable to stop harmonics
in the next band up.

3) driver board

5) PA board

This is an approach the driver has to be designed with 50 ohm outputs.  The interconnect can be short wires.

6) lpf´s

Goes without saying easy and its more about layout and switching.

7) VSWR bridge

Should be there and its a very useful and simple thing.

8) VFO (several SI5351 ? to avoid crosstalk between outputs of a single SI5351 driven from a single reference (TCXO; or VCXO which
could be synchronized to a GPS reference?)

Leave out the gps locked oscillator.  we are not designing the next generation Hilberling.  More than one LO device
makes a lot of sense and allows for a better RF layout to put it where its needed.  The 5351 is inexpensive.

RF signals to be routed via SMA connectors

No, as much as I use them and like them they are not cheap and for those that
are mechanically challenged or lack dexterity the word torture comes to mind.
They are not inexpensive  Cables with the connector on them are not cheap.
The base idea that RF should be routed with RF connectors is a vhf and up
thing.  With care at HF pin connectors can work but the board layout has to 
not create RF current loops.

Allison

Re: Modular uBitx - "Ex: Harmonics"

RCBoatGuy
 

Here's some features I'd like to see in any new design that shouldn't cost much, but would make life/testing/experimentation easier:

- Sockets for CPU boards on any new Raduino design.  (Teensyduino has this already, and I think the JackAl does, too)

- Sockets for relays, as these have been a frequent source of failure

- Move any pull-up resistors required onto the Raduino/Teensyduino/JackAl board and not rely on the user to wire them up.  Many users either failed to wire up the 4.7K external resistor correctly or had the connection fail later, causing the rig to immediately go into transmit on power-up.  This is easily avoided by having the required pull-ups on the Raduino/Teensyduino/JackAl board itself.

- Add 3-pin 0.1" input and output headers/jumpers to each section (Bi-di Amps, Audio Amp, Mic Amp, BPF, PA, LPF, etc) on a given board so that the given section can be isolated and tested independently.  For inputs to a section, 1st pin is output from prior section, 2nd pin is input to current section, 3rd pin is GND.   For outputs from a section, 1st pin is output from section, 2nd pin is input to next section, 3rd pin is GND.  Normal operation uses shorting jumpers across pins 1 and 2 to allow signals to flow thru, but jumpers can be removed and test inputs/outputs connected via molex/etc connectors to pins 2 and 3 (or to all 3 pins if desired).  This also makes it easier to replace a given section with an external circuit for experimentation/modification.

- Room for extra I2C headers on the Raduino (Teensyduino already has this, not sure about the JackAl) that the user can install later if desired

- Would be nice if the modular design had the PA on a separate board so different PAs can be used based on user preference.  Having different boards for a IRF510 PA, a RD16HHF1 PA, etc, would be nice as the user can pick and choose what they want, or build their own much easier.

- Support for adding additional BPF/LPF for those that want 160M, 6M, etc

- As for the LPF relays, I'd recommend using a relay scheme like that on the mcHF transceiver.  Their approach minimized the number of relays (only 4 DPDT relays needed for 4 filters), but still had filter inputs and filter outputs going to different relays.

- Design board so that the Raduino/Teensyduino/JackAl board has no obstructions from parts and/or connectors along the entire edge of the radio board.  The Teensyduino had to design in special cut-outs to use with the current uBitX due to obstructions. It would be nice if cut-outs like this were not needed in the future.

- Si5351 on main board, not on Raduino/Teensyduino/JackAl

That's my 2 cents.  Take it for what it's worth.  :)

73, 

Carl, K0MWC

Space

Larry Smith
 

Interesting article/Youtube

Re: Arduino Hangs

Arv Evans
 

Howard

Might only need to flow-chart the section where it displays the Version Number and then hangs. 
I would start in that area with adding print statements that point to individual lines of code (turn on
line numbers in the IDE and use these numbers in the print statements to keep them short).

Arv
_._


On Tue, Aug 14, 2018 at 9:45 PM Howard Fidel <sonic1@...> wrote:
Jack:
Thanks. I am running my customized version which I have been using for a few months. I also tried
the original code, but I get the same exact problem. It would be nice to have a flow chart for the code so I can better understand the flow and figure out where to put in test statements to figure it out. It must be some I/O issue I think because the code is good, and I had to rework the Raduino to change the Arduino. Maybe in the morning I will look for possible shorts on the I/O pins, maybe something it looks at?

Howard

On 8/14/2018 11:35 PM, Jack Purdum via Groups.Io wrote:
If you're using "known" software (e.g., from Dr. Lee or Allard), I would download a "fresh" copy and try again. Also, make sure you are using the latest version of the IDE.

Jack, W8TEE


On Tuesday, August 14, 2018, 11:30:51 PM EDT, Howard Fidel <sonic1@...> wrote:


As I said, the Arduino starts and displays the version number then hangs.

On 8/14/2018 11:28 PM, Jack Purdum via Groups.Io wrote:
Does the "code" hang, or does the "compile process", or does the "upload" hang?

Jack, W8TEE


On Tuesday, August 14, 2018, 11:22:44 PM EDT, Howard Fidel <sonic1@...> wrote:


Yes, and the V4 program I was running before loaded properly.

On 8/14/2018 10:54 PM, Jack Purdum via Groups.Io wrote:
Does it run the sample program named Blink that comes with the IDE?

Jack, W8TEE


On Tuesday, August 14, 2018, 9:45:21 PM EDT, Howard Fidel <sonic1@...> wrote:


I was hopping I could pick someone's brain before I start to experiment with the code I am running on my Arduino. My Arduino nano died, and I just replaced it with a new one. (I tried to socket it, but the pins didn't plug into any sockets I have.) The code hangs at the version number. Is there anything going on that the code looks for that it is not seeing to move on? I know how to add print statements to see if I can locate where the problem is, but if someone has seen this, maybe you could save me some time.
Thanks,

Howard




Re: Three cheers for the uBITX! Keeping problems in perspective....

Doug W
 

I am assuming 99% of us already follow xkcd. For the 1% that do not...



https://xkcd.com/2033/
--
www.bitxmap.com

Re: Modular uBitx - "Ex: Harmonics"

Jack, W8TEE
 

Carl:

Some very good ideas.

I'm showing the Rev 2 JackAl board here, partly to show what we done, but also to show the mistakes we made along the way. (We're doing
Inline image
the Rev 4 board now.) First, we've taken the buck converter off simply because it was too fragile when adjusting...far to easy to rip the adjusting screw right off the board. Second, the 7W audio amplifier (big IC on lower left) is stupid for the nano acres it takes plus its cost. Most users have powered speakers or can easily add them. We don't have a direct I2C connection, but we do have an SPI interface for the touch screen display. (Our display handles the video processing.) The rest are connections that work through the exiting µBITX headers, which would not be the same for a new design. Still, the above is less than 100mm x 100mm and parts are being taken off. Obviously, we have the Si5351 chip onboard, but that probably should be on the main board. The SMD parts will be part of the PCB when sold.

To me, perhaps the most important thing we've done is bring out a bunch of pins, both digital and analog, for others to use. I hope the selected processor for such a project has a bunch available.

Jack, W8TEE



On Wednesday, August 15, 2018, 12:27:03 PM EDT, RCBoatGuy via Groups.Io <ijnfan-HamRadio@...> wrote:


Here's some features I'd like to see in any new design that shouldn't cost much, but would make life/testing/experimentation easier:

- Sockets for CPU boards on any new Raduino design.  (Teensyduino has this already, and I think the JackAl does, too)

- Sockets for relays, as these have been a frequent source of failure

- Move any pull-up resistors required onto the Raduino/Teensyduino/JackAl board and not rely on the user to wire them up.  Many users either failed to wire up the 4.7K external resistor correctly or had the connection fail later, causing the rig to immediately go into transmit on power-up.  This is easily avoided by having the required pull-ups on the Raduino/Teensyduino/JackAl board itself.

- Add 3-pin 0.1" input and output headers/jumpers to each section (Bi-di Amps, Audio Amp, Mic Amp, BPF, PA, LPF, etc) on a given board so that the given section can be isolated and tested independently.  For inputs to a section, 1st pin is output from prior section, 2nd pin is input to current section, 3rd pin is GND.   For outputs from a section, 1st pin is output from section, 2nd pin is input to next section, 3rd pin is GND.  Normal operation uses shorting jumpers across pins 1 and 2 to allow signals to flow thru, but jumpers can be removed and test inputs/outputs connected via molex/etc connectors to pins 2 and 3 (or to all 3 pins if desired).  This also makes it easier to replace a given section with an external circuit for experimentation/modification.

- Room for extra I2C headers on the Raduino (Teensyduino already has this, not sure about the JackAl) that the user can install later if desired

- Would be nice if the modular design had the PA on a separate board so different PAs can be used based on user preference.  Having different boards for a IRF510 PA, a RD16HHF1 PA, etc, would be nice as the user can pick and choose what they want, or build their own much easier.

- Support for adding additional BPF/LPF for those that want 160M, 6M, etc

- As for the LPF relays, I'd recommend using a relay scheme like that on the mcHF transceiver.  Their approach minimized the number of relays (only 4 DPDT relays needed for 4 filters), but still had filter inputs and filter outputs going to different relays.

- Design board so that the Raduino/Teensyduino/JackAl board has no obstructions from parts and/or connectors along the entire edge of the radio board.  The Teensyduino had to design in special cut-outs to use with the current uBitX due to obstructions. It would be nice if cut-outs like this were not needed in the future.

- Si5351 on main board, not on Raduino/Teensyduino/JackAl

That's my 2 cents.  Take it for what it's worth.  :)

73, 

Carl, K0MWC

Re: Modular uBitx - "Ex: Harmonics"

Arv Evans
 

The idea of a "Modular uBITX" is interesting because with a full set of specs for each
module it might be possible for different persons or groups to concentrate on one module,
resulting in a group-designed transceiver.  This has potential to reduce design work from
"doing it all" to doing just a module that could be incorporated into the overall product.
But modular does imply added electrical and mechanical specifications for interfaces,
which could be either good or bad.

Arv
_._


On Wed, Aug 15, 2018 at 2:57 AM Gordon Gibby <ggibby@...> wrote:
Those are great ideas, but what about a limitation on cost? Should be under $140.


On Aug 15, 2018, at 04:42, Henning Weddig via Groups.Io <hweddig@...> wrote:

Nick,

I already started to do "my" improvement on the µBITX, but then stopped, after reading and trying to understand all the issues involved and going back to ideas about a spec and blocks to be designed.

As I am an retired electrical engineer specialized in RF and communication techology (I started my profesional career in 1980 at the company Hagenuk in Kiel Germany designing part of the ship´s main communication receiver RX 1001 and later RX1001M, then working on the RF part of the ST900 cordless telephone) 

As I posess a "good equipped home lab" witrh used commercial equipment (spectrum analysers, networt analyser, signal generators and so on), I can test my disgins properl.

Before going to design something  we first should think about a specifiaction and wirte it down. Yes I know seldom engineers like it,  but this will give some insight into what has to be designed. Very important are also level diagrammes of the bolocks involved to see if the to be designed unit will fulfill the desired spec.

From this point of view Glenn´s way of doing a new design in  first to test sub modules is a brilliant idea as it was also used in the industry (and my last occupation within a physics high energy research lab). We often only developed a single unit wioth the use of connectorized "Mini Circuit modules" and built into a case.

As SMD compoents are used the size of the "cheap" chinese pcb´s should be < 100 * 100 mm.

I believe that this forum including Farhan can and shuld be a good potential for an optimized new µBITX!

My previous ideas:

modular design on pcb´s (<100 * 100 mm)

frequency range 10 kHz to 30 MHz

first IF > 45 MHz (to avoid the 2*IF - LO problem) using four pole xtal filters  e.g. 70 MHz (if easily avaliable)? Another "popular IF could be 58 MHz or 58.1125 MHz (used in Hagenuks cordless phones) My be enough NOS filters are laying around.

1) receiver/exciter pcb

2) xtal filter board for the second IF (e.g. 5 MHz) with filters for SSB; AM; FM(?), CW

2) input lowpass filter (corner freq. 1.6 MHz) plus  overlapping bandpass filters (e.g. 1.6 - 4MHz; 4 - 8 MHz, 8 - 16 MHz; 16 - 30 MHz)

3) driver board

5) PA board

6) lpf´s

7) VSWR bridge

8) VFO (several SI5351 ? to avoid crosstalk between outputs of a single SI5351 driven from a single reference (TCXO; or VCXO which could be synchronized to a GPS reference?)

RF signals to be routed via SMA connectors

Of course AGC should be inclueded!

For the mic amp I remember that for maritime ship transmitters there is a requirement to limiting the max RF output via a Mic compressor. Chips like the SSM2167 could easily fulfill such a (similar) spec!

Comments are welcome
Henning Weddig
DK5LV

Am 15.08.2018 um 02:37 schrieb Nick VK4PP:
Hi Allison/ Kees/ Glenn/ other technical competent hams...

Would you consider working on a uBitx v2 so to speak, advice, criticisms and such?
Tweaking the current design as much as possible to perform better, address the major issues (spurs + harmonics)? 
Better components (2n2222a) ect,
Extra driver stage?
LPF layout..
proper BPF using QRP Labs Modules..

I would like to make it very modular, so its easy to fix/upgrade a section.
I will make some boards, happy to send to you for testing and evaluation at no cost.
Also smaller boars fit in a DL envelope (110x220mm) for DX shipping at $3.50. so that kind of defines the foot print.
Would be cool, 4 boards each about 105x105mm Stacking on one another.
Nano socketed on one board, SI5153 integrated, either SMT or Adafruit module ($$$ vs convenience)

I am not aiming to build a cheap copy, just an upgraded uBitx that you can assemble your self if you don't mind spending a bit more.

I want to enjoy the process and the radio, learn stuff along the way, contribute to the community.
As soon as this is no longer happening, there is no point in carrying on for me.

What are your thoughts people?

Cheers & 73.
Nick VK4PP