[hpsdr] New Hermes 2M Board

Shirley Márquez Dúlcey mark at buttery.org
Mon Jul 10 14:14:19 PDT 2017 

But also keep in mind that the "mediocre" hardware may be the best
solution for a lot of people because it falls within their budget or
meets other operating constraints that matter to them. I'd love to see
high end designs because they explore the limits of the possible, but
designers shouldn't be disappointed if some people choose not to buy
them.

On Mon, Jul 10, 2017 at 1:38 PM, Doug Ronald <doug at dougronald.com> wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> This posting addresses some of my pet-peeves, namely the designs of mediocre
> hardware vs the best possible, when the best possible would be only perhaps
> double the cost or less. One idea to address your number 1 below is to use
> four 16 bit ADCs, and average the result to gain an extra bit. A decent
> front-end LNA would also reduce the 30 dB or so NF of the ADCs down to a
> more respectable 7 dB where on the higher bands, the lower NF would matter.
> I have an HF LNA design with a 3.3 dB NF, 12 dB of gain, and a 53 dBm OIMD3.
> It wasn't all that hard to develop with a Norton amplifier configuration.
>
> Now that the HAM community has gotten its feet wet with SDR, let's get a
> decent radio out there...
> -Doug Ronald
> W6DSR
>
> -----Original Message-----
> From: Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] On Behalf Of Larry
> Gadallah
> Sent: Sunday, July 9, 2017 01:01 PM
> To: HPSDR Lists
> Subject: Re: [hpsdr] New Hermes 2M Board
>
> ***** High Performance Software Defined Radio Discussion List *****
>
> 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
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help:
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/

More information about the Hpsdr mailing list