<div dir="ltr"><div>Hi Scotty</div><div><br></div><div>The spec says that there is a DE function and a Host Computer function - it doesn't say how they are</div><div> physically connected or implemented. If that is unclear then the spec is not written well <br></div><div>enough and other folks will likely make the same (mis)interpretation, so it should be reworded.<br></div><div><br></div><div>Thanks for idea about the synthesizer. You are right, the SL spec does say that the output dividers are all</div><div> synchronously reset at power up and can also be reset by the programmer to re-sync. It also says they</div><div>will maintain phase-sync across outputs that are derived from the same synthesizer. I will make some</div><div> measurements on the Eval Board across the 4 outputs to see how well they stay aligned. I hope it's</div><div>not susceptible to glitches un-syncing them. That would be a dog to debug in the field.</div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 4, 2019 at 6:27 PM Scott Cowling via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Tom,<br>
<br>
OK, I was thinking that the four outputs of the AD5344 would be our <br>
Clock Module outputs. One to the FPGA, one to each RF Module, one <br>
external. If you wanted two or more of them phase-coherent, just drive <br>
them from the same AD5344 synthesizer. Then the AD5344 output block <br>
would perform our clock distribution, making an additional chip <br>
unnecessary. The variable frequency provided by the AD5344 synthesizers <br>
would be used to configure clock outputs for different kinds of RFMs. <br>
This would enable us to build a low-cost LowFER RFM (100kHz-500KHz) that <br>
samples at, say, 10MHz if we want to. NCOs are totally under the control <br>
of the DE, so they can be designed as one shared NCO or multiple NCOs as <br>
desired.<br>
<br>
Yes, the whole point it to have the hardware that is best suited to each <br>
task, do that task.<br>
<br>
Implementing a full TCP/IP stack or SSH in the FPGA is an expensive use <br>
of hardware (so let the SBC do it). Implementing decimation and slice <br>
filtering in the SBC puts an unreasonable burden on a low-cost <br>
general-purpose SBC (so let the FPGA do it).<br>
<br>
Tom, it just seemed like you were picking one way over another in your <br>
document by having a DE section 6 and a Host PC section 7. I agree that <br>
we need to specify the tasks, but not necessarily the hardware that does <br>
each one. Hopefully it will become obvious where each task is best <br>
handled when we document the needed steps. And I am trying really hard <br>
to keep the SBC out of the main flow, if possible. (Maybe it is not.)<br>
<br>
It was never my intention to allow the user to pick any old SBC for <br>
PSWS. My intent was to be flexible enough that *we* could pick from many <br>
alternatives and pick the one that works best for us.<br>
<br>
All these options will get out of control very quickly if we let users <br>
pick whichever ones they want. It will turn out exactly as you describe! <br>
Just look at the early days of Flex, when users got to pick their own <br>
sound card to use with the SDR-1000. Total mayhem, even after Flex TOLD <br>
them to use "brand X, model Y" cards.<br>
<br>
The options are for US to more easily build something that meets the <br>
requirements that this specification is enumerating (and others that we <br>
decide to support). And if users want to play, that is fine. They do so <br>
at their own skill level. We support only those configurations that we <br>
have engineered to meet specific targets.<br>
<br>
OK, I'm off my soapbox now. :-)<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<br>
On 5/3/19 8:36 AM, Tom McDermott wrote:<br>
> Hi Scotty - yes, having one synthesizer output feed two clock drivers <br>
> (one per RFM) would be fine.<br>
> It's not a problem to have a phase offset, provided that offset does not <br>
> change.<br>
> <br>
> I don't think it's a problem to have fixed frequency on the ADC clocks. <br>
> That clock is not used to tune the receiver,<br>
> the NCO in the DE is used to tune the receiver. So the DE can implement <br>
> one NCO for the synchronous case,<br>
> and two NCOs for the case where we want the two receivers to tune to <br>
> different frequencies.<br>
> <br>
> While the spec describes SBC and DE, those two functions could <br>
> theoretically co-exist on on module (for<br>
> example the Red Pitaya) where the FPGA does both the DE function, and <br>
> via the CPU-block does the SBC<br>
> function. A concern with having the FPGA do both is the lack of <br>
> sufficient computational capability in the<br>
> limited CPU performance that's implemented on the FPGA die. So the <br>
> spec tries to separate the functionality<br>
> without saying where it's physically implemented.<br>
> <br>
> I do hope we restrict ourselves to one implementation. If folks can <br>
> choose any SBC, any Receiver, etc. then there<br>
> will be no end of "The software doesn't work on my combination", "My <br>
> hardware receivers aren't coherent",<br>
> "My hardware is overflowing buffers", "My hardware doesn't support <br>
> amplitude calibration" ad nauseum.<br>
> The data that is produced risks being largely garbage.<br>
> <br>
> -- Tom, N5EG<br>
> <br>
> <br>
> <br>
> On Fri, May 3, 2019 at 7:08 AM Scotty Cowling via TangerineSDR <br>
> <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a> <mailto:<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>>> wrote:<br>
> <br>
> Hi Tom,<br>
> <br>
> Regarding the clocks, it seems that the AD5344 addresses this<br>
> problem with the cross-point switch and synchronous dividers.<br>
> <br>
> We can feed two outputs with one synthesizer if we like, for a fixed<br>
> (and very small) phase offset. Routing one clock output to two RF<br>
> Modules is problematic, especially with LVDS outputs. Wouldn't this<br>
> work?<br>
> <br>
> Alternatively, we could put a clock distribution chip on the DE to<br>
> take one Clock Module output and distribute it to FPGA, RFM1 and<br>
> RFM2, but then we lose the capability to clock the RFMs at different<br>
> frequencies (for example, when one is a TX and one is an RX).<br>
> <br>
> One thing to keep in mind is that the FPGA has multiple clock<br>
> inputs, so we can route one from each RFM, one from the Clock Module<br>
> and one from a local oscillator and let the FPGA code decide which<br>
> one to use. Of course, we would have to either let the FPGA generate<br>
> the RFM clocks or route multiple clocks to each RFM to clock the<br>
> ADCs directly. The reason I bring this up is that I want to use an<br>
> on-board inexpensive oscillator (and no Clock Module at all) as the<br>
> inexpensive, entry-level SDR. No, the performance would not be as<br>
> good. But the cost would be much lower than with any clock module,<br>
> and it would be selectable by simply loading the FPGA with a<br>
> different image and unplugging the Clock Module.<br>
> <br>
> The section 7 comment was not intended to dictate a data flow path.<br>
> I just wanted to show that we need (and will have) two GbE ports to<br>
> use that path in case we want to handle data in this way (for<br>
> example, if the SBC cannot keep up). We can word it in whatever way<br>
> makes it clear that we can do it either way. Isn't your description<br>
> implementation specific also (i.e., data flows through the SBC)?<br>
> <br>
> Maybe for PSWS, the data has to flow through the SBC? That is the<br>
> impression I got, and I am not sure we want to restrict the<br>
> architecture that way, but we could if that is our intent.<br>
> <br>
> 73,<br>
> Scotty WA2DFI<br>
> <br>
> <br>
> On 2019-05-03 04:09, Tom McDermott wrote:<br>
>> Thanks for the good comments, Scotty !<br>
>><br>
>> Section 3: the ADC clocks MUST come from the same one synthesizer<br>
>> output. If they<br>
>> come from two different outputs there is a big problem...<br>
>><br>
>> The clocks to the two ADCs must be (and remain) phase coherent.<br>
>> If the ADC clocks come<br>
>> from different outputs of the synthesizer, then each time the<br>
>> synthesizer starts, there could<br>
>> be any phase difference between the two. Further they could drift<br>
>> back and forth relative to one another<br>
>> a little bit because of the way synthesizers work. Thus the phase<br>
>> between them under<br>
>> the best case would be +/- 180 degrees. At 30 MHz that would<br>
>> represent +/- 45 degrees. This<br>
>> means that the baseband sampled signal at 30 MHz would also have<br>
>> an unknown phase<br>
>> difference of +/- 45 degrees. That completely wrecks the ability<br>
>> to discriminate polarization.<br>
>><br>
>> There can be a difference in phase between the two ADC clocks, but<br>
>> it must remain constant over time.<br>
>> Any difference will be calibrated out when the antennas and<br>
>> feedlines are calibrated for phase delay.<br>
>> But then the phase differences cannot change. The only way I see<br>
>> to do that is to have one<br>
>> synthesizer output that is distributed to the two ADC clocks. If<br>
>> the ADCs are on different modules<br>
>> then one clock signal has to be routed to the two of them in some<br>
>> manner (parallel, daisy-chained, etc.)<br>
>> Maybe there is some other way but it's difficult to see.<br>
>><br>
>> This is one of those things that makes phase coherent receivers<br>
>> very difficult, and why off-the-shelf units<br>
>> have to be carefully evaluated, as virtually none of the ones I've<br>
>> seen address this problem properly.<br>
>> It's the Radio Astronomy problem.<br>
>><br>
>> Section 7: The spec attempts to be implementation-non-specific. <br>
>> Forcing a particular method<br>
>> to distribute Ethernet data may eliminate all other potential<br>
>> solutions. The approach you outline<br>
>> is a really good and elegant solution, but the spec should not<br>
>> mandate it (it should allow it).<br>
>><br>
>> Section 8: great comment. I will restructure as you outline.<br>
>><br>
>> -- Tom, N5EG<br>
>><br>
>><br>
>><br>
>> On Thu, May 2, 2019 at 5:27 PM Scotty Cowling via TangerineSDR<br>
>> <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a> <mailto:<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>>><br>
>> wrote:<br>
>><br>
>> Hi Tom,<br>
>><br>
>> Here are my comments on your excellent document.<br>
>><br>
>> 73,<br>
>> Scotty WA2DFI<br>
>><br>
>> Notes on PSWS Specification V 0.1 5 May 2019<br>
>><br>
>> Section 3.0<br>
>> Clock module will have 4 *programmable clock* outputs:<br>
>> 1. FPGA<br>
>> 2. RF Module #1<br>
>> 3. RF Module #2<br>
>> 4. High-speed Reference Clock<br>
>><br>
>> In addition, two more outputs:<br>
>> 5. 1 PPS timing<br>
>> 6. 10MHz fixed reference<br>
>><br>
>> Clock outputs should be differential LVDS. Single ended clocks<br>
>> will be<br>
>> too noisy, especially across a connector boundary.<br>
>><br>
>> The FPGA should not provide the ADC clocks, they should come<br>
>> directly<br>
>> from the clock module. The ADC may supply a source-synchronous<br>
>> data<br>
>> clock to the FPGA.<br>
>><br>
>> Section 4.0<br>
>> Magnetometer interface can be I2C, SPI, serial UART or RS-485.<br>
>><br>
>> The magnetometer will almost certainly need to be remotely<br>
>> mounted. In<br>
>> this case, RS-485 is recommended. We can specify two-wires for<br>
>> communictions and two wires for power (typically 5V).<br>
>><br>
>> Section 5.0<br>
>> It is not immediately clear that *each* RF Module has two<br>
>> synchronous<br>
>> channels.<br>
>><br>
>> Note that the *pluggable filter* can be bypassed with a<br>
>> jumper, making<br>
>> it optional. Maybe call it "optional pluggable filter".<br>
>><br>
>> Section 6.<br>
>> The DE shall also be capable of sourcing or sinking UDP data<br>
>> streams<br>
>> to/from any IP address, under direction of the host processor.<br>
>><br>
>> The DE will have a three-port GbE switch, connecting the FPGA,<br>
>> host PC<br>
>> and external network. How do you want to explain this?<br>
>><br>
>> Section 7.0<br>
>> Processing the stream from the DE is optional, since it may<br>
>> not be able<br>
>> to process this much data. The metadata tasks will fall to the<br>
>> DE in<br>
>> this case.<br>
>><br>
>> The host will not always transmit the data to the central<br>
>> server. The<br>
>> host may direct the DE to stream data directly to the central<br>
>> server if<br>
>> it cannot process the volume or rate of data.<br>
>><br>
>> Section 8.<br>
>> I have been using "Command and Control Protocol" for the<br>
>> protocol used<br>
>> between the central server and the host PC. I have been using<br>
>> "Local SDR<br>
>> Protocol" for the protocol between the host PC and the DE.<br>
>><br>
>> We could use "Remote Command and Control", or "RCC" for the<br>
>> host<-->central server communications, and "Local Command and<br>
>> Control"<br>
>> or "LCC" for host<-->DE communications. Whatever we use, we<br>
>> should<br>
>> define it.<br>
>><br>
>> The Remote Command and Control section seems to be missing<br>
>> (although you<br>
>> refer to it once in section 10). Even though we don't know<br>
>> what the<br>
>> protocol is, I think it should be mentioned (as defined an<br>
>> a separate<br>
>> document?)<br>
>><br>
>> I think we need to make a clear distinction between Remote C&C<br>
>> and Local<br>
>> SDR C&C. We will need security and maybe encryption on the<br>
>> Remote C&C,<br>
>> but not so much on the Local SDR protocol.<br>
<br>
<br>
<br>
-- <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>