[hpsdr] New Hermes 2M Board

[Larry Gadallah]

I realize this is a very late response to Kjell's request (perhaps too
late, I'm probably at least a year behind on the list :-( ), but I
thought I'd throw in my two cents worth, FWIW (Disclaimer, my
professional background is in software, not RF or hardware).

In my experience, the challenges faced in getting the absolute best RF
performance out of an SDR design start in a couple of places:

1. ADC capabilities

The absolute dynamic range and noise figure are ultimately determined
by the capabilities of the ADC and its clock. Unfortunately it seems
that the development of new ADCs seems to be driven by the
requirements of the digital cellular base station industry, which
seems satisfied by the current generation of 16-bit, 100-200 MSPS
parts. AFAIK, for 16-bit ADCs these days, the best performance you can
get is not quite 100 dB SFDR. This seems to be about 20 dB short of
the required dynamic range needed for a high-performance HF receiver,
but this is typically addressed by decimating down in CIC or polyphase
filters.

2. Clocking performance

I have been very disappointed with the frequency stability of a number
of SDRs, because the stability of the ADC clock was not good enough to
support even long term SSB operation, much less the emerging digital
modes like WSJT and so on. This seems relatively easy to fix, compared
to phase noise/jitter issues, but I am surprised at how often it seems
to be overlooked.

More learned individuals like Robert Sherwood, NC0B and Adam Larson,
VA7OJ have demonstrated that phase noise on the ADC clock limits
dynamic range (see http://www.ab4oj.com/sdr/seapac17/sdrpres14.pdf)
and so in some respects, it might be argued that more attention should
be paid to the design of the ADC/DAC clocking system than the
selection of the ADC/DAC themselves. I think it might also be the case
that regardless of the clocking system, provisions should be made to
allow people to use external clocking of some sort, in order to
support uses that require better than average clock performance.

Some argue that we should get faster ADCs in order to more easily
support under-sampling and VHF operation. This might be true, but my
perception is that the performance/price curve for adequate ADC
clocking follows at least an exponential (or even geometric) curve
versus clock frequency. In general, I am surprised at how little
discussion there is about ADC/DAC clock performance requirements,
given how much impact they seem to have on overall system performance.

Beyond the ADC performance discussion, it seems to me that one of the
biggest obstacles to the evolution of SDR technology is the limited
number of people who can understand and program FPGAs:

3: FPGA Design and Interface

It seems unfortunate that the industry has not converged on a suitable
interface between ADCs and FPGAs, but there seems to be a lot of
available, low-cost digital hardware (e.g. Zync, et al) comprising
FPGAs and SoCs that would be quite suitable for our purposes if they
had a standard interface between the ADC and the FPGA that would not
degrade the noise performance of the RF/ADC module. Scotty Cowling and
the people at iQuad Labs (and probably others) have demonstrated this
concept some time ago. It is also worth noting that for the design of
the UDRC, Northwest Digital stopped several years of design of a
custom ARM SoC controller for their system and replaced it with a
commodity-priced Raspberry Pi. Ideally, I suppose it would be best if
the RF/ADC "module" was separate from the FPGA/Interface "module" so
that each could evolve independently.

My background is more in software than hardware or RF, and it seems to
me that another issue that comes up frequently is that the FPGA
firmware design ends up being somewhat "static" and monolithic. I know
almost nothing about FPGA firmware, but I keep wondering if more
people could do more things with the SDR hardware without having to
resort to FPGA programming if the FPGA firmware was "parameterized" at
key points with registers that would modify the operation of the FPGA
at run time.

4. System-level Design

Observing much of the discussion, it seems like we have many expert
participants in various areas that are definitely needed to design a
SDR system, and each tends to weigh in on their individual areas of
expertise within the overall system. There are also self-declared
non-expert SDR "users" who provide quite legitimate requirements, but
somehow there does not appear to be much open discussion of overall
system design and the attendant compromises and trade-offs.

I wonder if some techniques like Value Stream Mapping might be brought
to bear to balance out all of the competing and conflicting
requirements for the design of systems like Hermes 2? That is to say,
we typically discuss the fine details of half a dozen domains within a
SDR system, and end up optimizing each of them in some arbitrary
order, without much explicit consideration of how that ordering will
affect the overall performance or usefulness of the whole system.

> Message: 6
> Date: Sun, 28 May 2017 21:33:07 +0200
> From: "Kjell Karlsen" <la2ni at online.no>
> To: "hpsdr at lists.openhpsdr.org" <hpsdr at lists.openhpsdr.org>
> Subject: [hpsdr] New Hermes 2M Board.
> Message-ID: <op.y0yq9hg4nknqug at kjellkarlsen-pc>
> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>
> Hi All.
>
> As Apache Labs has decided to stop the production of the Hermes board, we
> have discussed to see if it is possible to get it produced by others.
>
> I have for a long time thought of the possibility to improve the
> construction and include some long wanted features. I am going to describe
> the modifications I am thinking on. And of course we are open for other
> ideas!
>
> We have got all the original layout files for Hermes from Abhi and that is
> a good starting point.
>
> Endre Kiss, YO6OGJ is going to do the layout job. The first he is going to
> do is to draw completely new schematics in Altium Designer. The physical
> layout of the new board will follow the original as near as possible to be
> sure that the good performance of Hermes is kept or even improved.
>
> The preliminary list of modifications follows:
>
> 1: New PA giving 5W PEP output. By increasing the power output it can be
> used to drive a LDMOS PA directly to >1KW output. I have tested 2 of the
> newest 14V LDMOS transistors from NXP (Freescale) and they can give >5W
> linear output, also on 50 MHz. With Pure Signal, the IM3 is >70 dBc at 5W.
> Even at 145 MHz, the power out is >1W with good linearity.
>
> 2: After a suggestion by Leif Aasbrink, SM5BSZ the DAC is going to give
> full
> output all the time and the drive regulation to the PA is done by using a
> step attenuator after the first low noise amplifier. This will keep the
> phase noise as low as possible in the TX signal. The same solution is going
> to be used in Metis.
>
> 3:Use the newest SMPSU chips for the power supply. The latest chips are
> much more "silent" than the old and it is easier to suppress the spurs. By
> using one for the 5V bus and one for 3,3V and run synchronously, we need
> only 2 or 3 linear regulators in addition for the most critical systems so
> the total power consumption can be reduced. It might also be possible to
> use only one switcher delivering 3,3V. There are only a few circuits that
> use 5V so just a small linear regulator is needed.
>
> 4: Remove the ON/OFF switch from the board. In most systems the switch is
> on another board or installed on the front separately. And we can use the
> space for other parts.
>
> 5. Add 2 meter operation on Hermes 2M by using under sampling. By
> installing
>   the 145 MHz BP filters on the bottom side of the board, the switching
>  from HF to VHF should not introduce any extra spurs.
> Including 70 MHz has been asked for but the restricted space forbids this.
> And the chances to get extra spurs would increase.
> As the new PA can give >1W even on 145 MHz, also TX is included.
>
> 6 New FPGA. Phil, VK6PH is looking for a more modern FPGA to replace the
> Cyclone III that is used today.
>
> 7: There is a need for some more I/O?s. For ex. control output for use
> with EER-PWM Power Amplifiers, interface to control an external ATU
> (compatible with ICOM ATU)and so on.
>
> We are open for other ideas so please give feedback.
>
> The decision to start a production will be taken after the schematics are
> completed and the cost is calculated.
>
> A few prototype boards has to be produced and tested and eventually
> modified.
>
> When the construction is tested and found OK, we can make a list and
> produce fully populated and tested boards. Also bare boards will be
> offered for the brave ones.
>
> We also plan to make prototypes of a new Apollo board with 30W PEP out,
> also
> on 50 MHz and offer ready made boards without the inductors installed.
>
> At the moment there are no plans to make complete transceivers. But
> combining
> Hermes 2M with Apollo and the PiHPSDR controller, a complete transceiver
> like
> the one I showed at Friedrichshafen last summer is possible.
>
> We hope there are enough people that are interested in this. When I read
> the reflectors, my impression is that there still are a lot of people
> interesting in building their own equipment.
>
> 73, Kjell
>
>
> --
> Sendt med Operas e-postklient: http://www.opera.com/mail/
>

-- 
Larry Gadallah, VE6VQ/W7                          lgadallah AT gmail DOT com
PGP Sig: B5F9 C4A8 8517 82AC 16B6  02B6 0645 69F0 1F29 A512