[TangerineSDR] Just joined and some comments

[Lyle Johnson]

Scotty,

I ordered the Jetson Nano from Nvidia on April 16, they shipped on April 
18 and it arrived here on April 24 (after sitting in Phoenix since April 
20).

The M.2 to MEC certainly makes sense for the HF1, HF2 and TX2 boards.

And, yes, a clock module carrier board along with the clock module seems 
to be a logical step from my perspective as well. I'd like to see the 
carrier board able to spread out LVDS clocks (as opposed to only 
single-ended 50-ohm BNC/SMA ports) with thought given to hacking into 
the Red Pitaya standard and SDR configuration modules.

-Lyle


On 4/26/19 3:11 PM, Scotty Cowling via TangerineSDR wrote:
> Hi Lyle,
>
> Yes, you are correct in your assumption that we are using the physical 
> M.2 connector, but not the NGFF board mechanical outlines. We are not 
> even using any of the electrical signalling standards, since they are 
> all over the map, depending on what kind of function you are 
> implementing. We adhere to the keying and gold finger dimensions, and 
> little else.
>
> My desire is to come up with a TAPR SDR standard interface for RF 
> Modules on M.2 connectors to allow anyone to build TangerineSDR 
> compatible RF Modules. And along the way, we will build a few 
> ourselves. :-)
>
> I just picked the connector because it has enough pins, is suited to 
> high-speed signalling, is cheap ($0.80 in quantity) and requires no 
> mating connector.
>
> Unfortunately the MAX10 (low cost, up to 50K LEs only), CV-E (Cyclone 
> V Logic only) and CV-SoC parts do not share common footprints. They 
> are enough different to require different DE layouts. But the RF 
> Module, Clock Module and I/O interfaces can be made identical, while 
> adding more capability to the DE. The MAX10 was chosen mostly because 
> of cost, but, unlike the LimeSDR Mini, we picked the biggest one, not 
> some small toy one. (Can you see my disappointment with current SDR 
> offerings showing? :-)
>
> John and Tom and I were already talking about making a base board just 
> for the clock module that would make it usable by the members of the 
> time nuts group. This could be a separate product for TAPR, and 
> another "user" of the Clock Module that would help expand its numbers. 
> Designing the Clock Module first, then the DE will not only work, but 
> is the desirable order, I think!
>
> Agreed that fewer variants is less headache. The idea is to allow a 
> "variant" to be built to quickly address a new market (as we identify 
> each one). No need to address a small market of 10 users, but if 
> University XYZ says, "I'll buy 500 if it has a GPSDO", then we can 
> configure one easily and quickly.
>
>  I also think that different price points for different performance 
> points and relatively low cost modules will help spur on 
> experimenters. How many HPSDR systems would we have sold if we had 
> waited until all the boards were done and tried to sell a system for 
> $1500? A lot fewer that with our "$250 board of the month club" 
> approach. (Maybe it was more like "board of the year") :-)
>
> One of the other things that might have escaped your notice is the USB 
> 2.0 host port. This allows you to plug in $20 DVB-dongles, which are 
> everywhere. Now you can have a cheap  8-bit dual ADC system with FPGA 
> processing. Or plug in a Kerberos SDR and have 4 of them at once.
>
> As for HPSDR systems, we could build a shield that interfaces directly 
> to the Atlas bus and drives differential clocks out to, say four 
> Mercury boards on their differential clock headers. The Atlas bus 
> would still be the limiting factor, but you could get synchronous 
> clocking across multiple Mercury boards.
>
> I was also thinking of building an adapter board from M.2 to MEC 
> connector (used on the BeMicroSDK). Then I could use my substantial 
> existing stock of SDRStick HF1, HF2 and TX2 boards to build "instant" 
> transceivers from prototype DE boards. The HF2 is essentially a 
> Mercury front end up through the LTC2208 16-bit, 122.88Msps ADC. The 
> HF1 uses a 14-bit, 80Msps ADC. The TX2 uses the same transmit section 
> as Hermes, with an added T/R switch.
>
> How long ago did you order your Nvidia Nano? I ordered one a week ago, 
> and still have not got it. Which supplier did you order it from? I 
> ordered from NewEgg, since shipping was free.
>
> 73,
> Scotty WA2DFI
>
> On 2019-04-26 12:59, Lyle Johnson via TangerineSDR wrote:
>> Hello Scotty!
>>
>> And thank you, John, for the slide deck.  Interesting survey.
>>
>> On 4/26/19 12:15 PM, Scotty Cowling via TangerineSDR wrote:
>>> Hi Lyle,
>>>
>>> Welcome!
>>>
>>> I guess it is my fault for putting the cart before the horse and 
>>> writing  hardware spec for one of the boards in multi-board system, 
>>> expecting everyone to know what I am thinking.
>>>
>>> So here goes. I will put this into an architecture document that we 
>>> can add to as we figure things out. But fr now, here is my vision of 
>>> the TangerineSDR system.
>>>
>>> As for terms, PSWS stands for Personal Space Weather Station, a 
>>> receive only, 100KHz to 60MHz SDR receiver with some small array of 
>>> sensors for detecting magnetic disturbances and perhaps including 
>>> some other as-yet unspecified sensors. Nathaniel at New Jersey 
>>> Institute of Technology (NJIT), who is the head of the HamSCI 
>>> organization,  calls it the SSDR or "Scientific Software Defined 
>>> Radio".
>>>
>>> The DE is supposed to be the "digital" part of a modular SDR that 
>>> can be assembled, with proper choice of modules, to be a PSWS, a 
>>> Phase 4 ground station radio (P4G, with a "nickle and dime"  5GHz 
>>> uplink/10GHz downlink), a general experimenter's SDR, a STEM SDR, 
>>> etc. Kind of like a modular Red Pitaya.
>>>
>>> The reason you don't see any high-speed ADCs or DACs is because 
>>> there aren't any on the DE. The DE accepts one or two high-speed 
>>> (via M.2 connectors and LVDS) RF modules. This allows us to build a 
>>> $30 8-bit, 10Msps ADC board or a $300 16-bit, 250Msps ADC board, 
>>> depending on what the user's needs and wants are. We use M.2 (NGFF, 
>>> like an SSD) connectors because they are small, high-speed and cheap.
>>
>> Am I correct to assume that because we're not trying to build server 
>> racks, we can allow mechanical form factors of the attached boards to 
>> exceed the 30 mm x 110 mm x ~4 mm M.2 spec dimensions? In other words 
>> we're adhering to the M.2 signaling and physical keying and and so 
>> forth, but not the module dimensional limitations?
>>
>>
>>> As Tom mentioned, one of the biggest problems with SDRs today is 
>>> poor clock quality (stability, phase noise, jitter, overall 
>>> accuracy, etc). We place the clock generator on a separate M.2 
>>> module, allowing the user to pick an inexpensive VCXO (like the 
>>> CVHD-950 from Crystek, now $15 from DigiKey) or an expensive GPSDO 
>>> (like uBlox LEA-M8F or LEA-M9F or Jackson Labs LTE-Lite) for $150. I 
>>> plan to place an on-board reasonable performance oscillator for the 
>>> low-cost version of the DE that will not require any clock module at 
>>> all.
>>
>>
>> Makes sense :-)
>>
>>
>>> Speaking of DE variants, the base model DE (MAX10 FPGA, 50K LEs) can 
>>> be produced in several build versions, by de-populating some 
>>> components for reduced cost (and reduced functionality, of course). 
>>> The idea is to come out with several higher-end (and more expensive) 
>>> versions of the DE (like a big Cyclone V, 300K LEs or a Clyclone V 
>>> SoC, 110K LEs plus a dual core ARM HPS) that can use the same clock 
>>> and RF modules.
>>
>>
>> Ah!  So the FPGAs across these families have available (or planned) 
>> parts that are footprint and pinout compatible? I hadn't looked 
>> closely at any of this.
>>
>> One thing we found at Elecraft (and it appears Tesla has also 
>> discovered) is the fewer variants, the easier it is to handle supply 
>> chain issues.
>>
>>
>>> By providing an on-board GbE switch, we can connect a Single Board 
>>> Computer (SBC), like a lower-performance Raspberry Pi 3+ or a higher 
>>> performance Odroid N2 via GIgabit Ethernet. Now we can separate the 
>>> command and control channel (Internet <--> SBC) from the streaming 
>>> channel (SDR <--> Internet) from the local control channel (SBC <--> 
>>> SDR). They will be on the same physical GbE wire, but they will be 
>>> logically separated.
>>
>> Got it.  I just received an Nvidia Nano development board.  Some 
>> serious performance possibilities for $99!
>>
>>
>>> This removes the low performance SBCs from inside the high-speed 
>>> data stream (which they could not keep up with anyway), while still 
>>> allowing TCP/IP command and control, network security and other 
>>> low-compute power tasks that the SBC can do at a price that I can 
>>> never match on the DE board.
>>>
>>> So the configurability is not meant to be for the user to have a 
>>> general-purpose radio, but for us to be able to address different 
>>> markets quickly by selecting different modules or build options, 
>>> without having to design a new board.
>>>
>>> Hopefully this answers most of your questions, but maybe the whole 
>>> idea is hare-brained from the start. It is just my answer to dozens 
>>> of SDRs out there, and not one of them doing what I want. And I 
>>> can't be alone. But hopefully we appeal to at least 500 rather than 
>>> 10 players.
>>
>>
>> QSL
>>
>> It might be interesting if the super-clock module could have some 
>> means to allow it to be hacked back into a Hermes or Mercury or Red 
>> Pitaya or etc to meet the timing and phase-noise needs of the larger 
>> community?  In other words, design the clock first and then the Data 
>> Engine if it becomes clear it is needed, rather than design the Data 
>> Engine first and still need the super-clock for it.
>>
>> Sorry I am so late to the game...
>>
>> Lyle KK7P
>>
>>>
>>> 73,
>>> Scotty WA2DFI
>>>
>>> On 2019-04-26 09:06, Lyle Johnson via TangerineSDR wrote:
>>>> Hello Scotty, Dan and Tom!
>>>>
>>>> Still digesting the preliminary document.  I see lots of IO...
>>>>
>>>> I also see references to PSWS which seems to be Personal Science 
>>>> Work Station.  Not sure what this is intended to be.
>>>>
>>>> I also recall some interest in a "space weather station" but have 
>>>> been out of the loop for too long.
>>>>
>>>> The TangerineSDR Data Engine seems to be a general purpose FPGA 
>>>> development board with lots of specialized IO.
>>>>
>>>> I am unclear as to what specific problems this project is 
>>>> attempting to solve, or what peripheral board(s) might be needed to 
>>>> solve the problem set that is driving this development.  Are such 
>>>> boards already existing (hence the large set of various standard IO 
>>>> interfaces) or do many/most of them still need to be designed -- 
>>>> and if so how does that play out in the overall scheme of things?
>>>>
>>>> TAPR's early history with general purpose solutions not aimed at 
>>>> solving a particular (perceived) need in the community in general 
>>>> meant a lot of development effort by one to five individuals to 
>>>> create something that was only adopted by a few tens (METCON comes 
>>>> to mind).
>>>>
>>>> Does a board like the Red Pitaya - especially if it were to have a 
>>>> TAPR-sourced "IO expander" - already solve many or most of the 
>>>> problems that this board attempts to solve?  Or the new Red 
>>>> Pitaya-SDR with bigger FPGA, better ADC, 50-ohm front end, lower 
>>>> noise floor, etc but at $500 (fast 16 bit ADCs and 14-bit DACs) 
>>>> instead of $200 (10-bit fast ADCs/DACs) or $300 (fast 14-bit 
>>>> ADCs/DACs), solve the problem(s)?
>>>>
>>>> -Lyle KK7P
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>