[TangerineSDR] DCC discussion list

Lyle Johnson kk7p4dsp at gmail.com
Fri Sep 13 11:30:25 EDT 2019


Might be something to learn from the Elecraft KX3 power supply design as well as the KSYN3A synth power design.  We had some challenges there, too!

Lyle KK7P

Sent from my iPhone

> On Sep 13, 2019, at 7:50 AM, John Ackermann N8UR via TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
> 
> Reference the voltage regulator conundrum.  I was looking at that when
> designing the synthesizer board that has now morphed into TangerineSDR.
> It becomes quite interesting to design power distribution when you have
> devices that want a couple of hundred ma at 3.3 or even 1.8 volts when
> starting from 13.8-- that's a lot of energy turned to heat.
> 
> Where we had gotten with that design was a switching regulator (we were
> looking the TI TS30011) to take 9 to 18 volt input and provide really
> clean 4V output.  That 4V bus would then drive ultra-low noise LT3045
> linear regulators to provide 3.3V and 1.8V.  Not-fully-finalized
> schematic of that arrangement attached.  The key was the physical layout
> of the switcher to keep the crud well away from the analog components;
> potentially even putting it on its own board.
> 
> 73,
> John
> ----
> 
>> On 9/13/19 9:47 AM, Phil Erickson via TangerineSDR wrote:
>> Hi Tom,
>> 
>>   Definitely agree with Option C.  Then the user would have a set of
>> specs that their +12V would need to meet in order to guarantee an
>> internal spur/RFI level of no more than XX -dBc or however it would be
>> quantified.  So for example, maybe the user gets a menu for how they
>> supply +12V vs how the TangerineSDR will perform:
>> 
>> Moderate effort, moderate cleanliness (lowest $$ for power supply; runs
>> off site power)
>> High effort, maximum cleanliness (higher $$ for power supply; runs off
>> site power)
>> Battery, maximum cleanliness (medium to high $$ given that this probably
>> is a LiFePO4 battery for good A-Hr life; limited run time)
>> 
>>   The thing one would watch out for of course is the user who thinks
>> that "Battery" means a battery hooked to a charge controller.  Our
>> experience is that you have to work incredibly hard to get a non-RFI
>> generating charge controller, but unless you've tried to do it, not as
>> many as you would naively hope seem to be aware of the problem.  (In the
>> same vein, solar panels are huge HF noise generators when they are
>> providing power; after all, they are nice antennas!)
>> 
>>   This is all perhaps obvious to those on this list, but useful to state it.
>> 
>>   Regarding your Question 2, not sure what the right answer is there. 
>> The real question is how to characterize the additional RFI that will be
>> produced if the user chooses the wrong DC voltage conversion
>> technology.  E.g. buck/boost converters are cheap but they have a
>> switching frequency which can land nasty coherent harmonics, that don't
>> average away, square in the middle of the HF bands.  Linear regulators
>> are of course nice, but they are energy inefficient.  Maybe it's better
>> to do that voltage conversion design engineering in the TAPR realm since
>> how many users are going to be really good at suppressing RFI if you use
>> Option 3?
>> 
>> 73
>> Phil
>> 
>> On Fri, Sep 13, 2019 at 9:29 AM Tom McDermott <tom.n5eg at gmail.com
>> <mailto:tom.n5eg at gmail.com>> wrote:
>> 
>>    HI Phil - We certainly will need requirements on power &
>>    distribution characteristics.
>> 
>>    However I think we first may need a plan.
>> 
>>    Question 1: do we operate off:
>>    Option A: 120VAC input  (North America)
>>    Option B: 120-240VAC input (Worldwide)
>>    Option C:  + 12VDC input?    [ +12V means in my view  +10.5 to +13.8
>>    VDC, allowing a battery to be the power input. ]
>> 
>>    In my view Option C is the easiest for project engineering, but
>>    requires the user to generate +12V, battery charge, etc.
>>    Given the possible worldwide AC variables, battery type and size
>>    variables, etc., it avoids many issues.
>> 
>>    If we were to choose Option C then, at the system level then:
>>    Question 2 how do we create needed voltages:
>>    Option 1. Data Engine regulates & distributes all the system
>>    voltages from a single +12VDC  (11-13.8V) input.
>>    Option 2: Separate DC supply derives all the needed voltages from
>>    +12VDC (11-13.8V) input.
>>    Option 3: Each module derives it's own voltages from a +12VDC
>>    (11-13.8V) input.
>> 
>>    -- Tom, N5EG
>> 
>> 
>> 
>> 
>> 
>>    On Thu, Sep 12, 2019 at 7:00 PM Phil Erickson
>>    <phil.erickson at gmail.com <mailto:phil.erickson at gmail.com>> wrote:
>> 
>>        Hi Tom,
>> 
>>          It is probably good for item 5 to think about whether
>>        cleanliness specs for the power supply are required.  As you
>>        know, hash on the DC lines could be a major RFI problem.
>>         (Batteries would tend not to have that issue, hence their
>>        mention earlier.)
>> 
>>        73
>>        Phil
>> 
>>        On Thu, Sep 12, 2019 at 9:58 PM Tom McDermott via TangerineSDR
>>        <tangerinesdr at lists.tapr.org
>>        <mailto:tangerinesdr at lists.tapr.org>> wrote:
>> 
>>            I've combed the meeting notes and some other thoughts and
>>            put together a frist draft of possible DCC discussion topics
>>            for HAMSCI / TangerineSDR.
>>            Please review and send me additions, deletions, changes,
>>            etc. by Monday the 16th and I'll iterate once before the
>>            conference.
>> 
>>            -- Tom, N5EG
>> 
>>            *
>>            *
>>            *HAMSCI project discussion Topics for DCC 2019*
>> 
>>            1.    Need cost estimates for the Clock, DE, RF, and
>>            Magnetometer modules.
>>            2.    What is the schedule for the modules, testing, prototypes?
>>               a.    Data Engine
>>               b.    2-chan RF receiver
>>               c.    GPS Clock
>>               d.    Magnetometer
>>               e.    Other ? SBC, Power supply, etc.
>>            3.    Each module will have a unique manufacturer serial
>>            number based on some PROMs that have this capability. Any
>>            issues with the number or format?
>>            4.    Do we need to create any videos describing what the
>>            project is, what the objectives are, status, or other?
>>            5.    No discussion so far on power supplies, other than a
>>            request for +12V battery power capable. Do we need a plan?
>>            6.    HAMSCI 2020
>>               a.    Any more information on the location?
>>               b.    Should we plan a demo of TangerineSDR or the
>>            completed parts?
>>            7.    Receive Antennas. Mike Pappas has acquired a
>>            calibrated filed strength meter, we discussed seeing if DX
>>            Engineering would let us measure a production lot of
>>            antennas (10?) to determine the field strength sensitivity
>>            and variance.
>>            8.    Do we need a test plan for the system?
>>            9.    Upload data compression appears feasible (3:1 ?).  Do
>>            we need any study or proposals of how much data we are
>>            asking folks to upload? Or is this better to determine
>>            experimentally?
>> 
>>            **//___^
>> 
>> 
>>            -- 
>>            TangerineSDR mailing list
>>            TangerineSDR at lists.tapr.org <mailto:TangerineSDR at lists.tapr.org>
>>            http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>> 
>> 
>> 
>>        -- 
>>        ----
>>        Phil Erickson
>>        phil.erickson at gmail.com <mailto:phil.erickson at gmail.com>
>> 
>> 
>> 
>> -- 
>> ----
>> Phil Erickson
>> phil.erickson at gmail.com <mailto:phil.erickson at gmail.com>
>> 
> <Screenshot from 2018-04-18 18-08-48.png>
> -- 
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org



More information about the TangerineSDR mailing list