<div dir="ltr">Hi Tom,<div><br></div><div> 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:</div><div><br></div><div>Moderate effort, moderate cleanliness (lowest $$ for power supply; runs off site power)</div><div>High effort, maximum cleanliness (higher $$ for power supply; runs off site power)</div><div>Battery, maximum cleanliness (medium to high $$ given that this probably is a LiFePO4 battery for good A-Hr life; limited run time)</div><div><br></div><div> 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!)</div><div><br></div><div> This is all perhaps obvious to those on this list, but useful to state it.</div><div><br></div><div> 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?</div><div><br></div><div>73</div><div>Phil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2019 at 9:29 AM Tom McDermott <<a href="mailto:tom.n5eg@gmail.com">tom.n5eg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>HI Phil - We certainly will need requirements on power & distribution characteristics.</div><div><br></div><div>However I think we first may need a plan.</div><div><br></div><div>Question 1: do we operate off:</div><div>Option A: 120VAC input (North America)<br></div><div>Option B: 120-240VAC input (Worldwide)<br></div><div>Option C: + 12VDC input? [ +12V means in my view +10.5 to +13.8 VDC, allowing a battery to be the power input. ]<br></div><div><br></div><div>In my view Option C is the easiest for project engineering, but requires the user to generate +12V, battery charge, etc.</div><div>Given the possible worldwide AC variables, battery type and size variables, etc., it avoids many issues.<br></div><div><div><br></div><div></div><div></div><div>If we were to choose Option C then, at the system level then:</div><div> Question 2 how do we create needed voltages: <br></div><div>Option 1. Data Engine regulates & distributes all the system voltages from a single +12VDC (11-13.8V) input.</div><div>Option 2: Separate DC supply derives all the needed voltages from +12VDC (11-13.8V) input.</div><div>Option 3: Each module derives it's own voltages from a +12VDC (11-13.8V) input.</div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 12, 2019 at 7:00 PM Phil Erickson <<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Tom,<div><br></div><div> 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.)</div><div><br></div><div>73</div><div>Phil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 12, 2019 at 9:58 PM Tom McDermott via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">I've combed the meeting notes and some other thoughts and put together a frist draft of possible DCC discussion topics for HAMSCI / TangerineSDR.</div><div dir="ltr">Please review and send me additions, deletions, changes, etc. by Monday the 16th and I'll iterate once before the conference.</div><div dir="ltr"><br></div><div>-- Tom, N5EG</div><div dir="ltr"><br></div><div dir="ltr"><b><span style="line-height:107%;font-size:14pt"><br></span></b></div><div dir="ltr"><b><span style="line-height:107%;font-size:14pt">HAMSCI project discussion Topics for DCC 2019</span></b></div><div dir="ltr">
</div><p style="text-align:left" dir="ltr">1. Need cost estimates for the Clock, DE, RF, and Magnetometer modules.<br>2. What is the schedule for the modules, testing, prototypes?<br> a. Data Engine<br> b. 2-chan RF receiver<br> c. GPS Clock<br> d. Magnetometer<br> e. Other ? SBC, Power supply, etc.<br>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?<br>4. Do we need to create any videos describing what the project is, what the objectives are, status, or other?<br>5. No discussion so far on power supplies, other than a request for +12V battery power capable. Do we need a plan?<br>6. HAMSCI 2020<br> a. Any more information on the location?<br> b. Should we plan a demo of TangerineSDR or the completed parts?<br>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.<br>8. Do we need a test plan for the system?<br>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?</p><p style="text-align:left" dir="ltr"><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><br></p><p style="text-align:left" dir="ltr"><br></p></div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">----<br>Phil Erickson<br><a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">----<br>Phil Erickson<br><a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br></div>