[TangerineSDR] Functional Specification v 0.3

Engelke, Bill bill.engelke at ua.edu
Wed May 29 09:16:57 EDT 2019


Tom – or anyone else who can answer…
I have a question regarding the Red Pitaya. I have code working as follows:
1.      Using Pavel’s code – start SDR transceiver compatible with HPSDR

2.      Now I run my c program on the XU4. It does discovery and finds the Red Pitaya.

3.      Send a START to the Red Pitaya, and it begins sending samples via UDP packets. The start is the ultra-simple Metis command consisting of:

a.       <0xEFFE><0x04><Command>< 60 bytes of 0x00>

4.      I am able to convert these samples to floating point and save them in Digital-rf (HDF5),

QUESTION:  What is the default sample rate and center frequency ?   So far, I have not sent the Red Pitaya a control command with these data, but it works anyway.  I would think/guess that the Red Pitaya is using a 48 ksps sample rate, but what is its default frequency? I have looked thru all the docs I can find, including the FPGA programming, but have not found that.    ???    -73- Bill, AB4EJ


From: TangerineSDR <tangerinesdr-bounces at lists.tapr.org> On Behalf Of Engelke, Bill via TangerineSDR
Sent: Tuesday, May 28, 2019 9:57 AM
To: Tom McDermott <tom.n5eg at gmail.com>; TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr at lists.tapr.org>
Cc: Engelke, Bill <bill.engelke at ua.edu>
Subject: Re: [TangerineSDR] Functional Specification v 0.3

Tom – let’s talk more about the throughput issue. As I mentioned before, I am working right now on a way to do some benchmarking to start gauging what is possible.  I have a related question for you:


-          On your quad core I7, have you narrowed down where the bottleneck is?  There have been some discussions that a rotating hard drive might not be able to keep up with the data rate, no matter what format is used.  (Something else I am going to test). It is quite possible that the compute time to put the data out as HDF5 might be the smaller part of the time budget, and disk writing the larger.

-          At today’s prices, a 2 TB or 4 TB SSD is a budget buster, but this might not be the case in 2024.

Any thoughts?  I am building a crude prototype to see if I can save multiple channels off a Red Pitaya using HDF5 (Digital RF actually, but it uses HDF5), and compare throughput using both spinning drive on USB3 and SSD. -73- Bill

From: Tom McDermott <tom.n5eg at gmail.com<mailto:tom.n5eg at gmail.com>>
Sent: Sunday, May 26, 2019 9:08 PM
To: TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr at lists.tapr.org<mailto:tangerinesdr at lists.tapr.org>>
Cc: Scotty Cowling <scotty at tonks.com<mailto:scotty at tonks.com>>; Engelke, Bill <bill.engelke at ua.edu<mailto:bill.engelke at ua.edu>>
Subject: Re: [TangerineSDR] Functional Specification v 0.3

Hi Bill - thanks for iterating the specification.  Here are a few comments on 0.3:

There are no paragraph numbers to  reference, and the page numbers may change
depending on how mark-up is selected by the reader, so I'll reference the Title of the paragraph.

General Requirements - Assumptions and Dependencies:

1. The HD may be able to be reduced to 2TB if the 20GE snapshot
can be made while recording to the ring buffer.  2T SSD drives
are coming down in price faster than 4T.

Technical Notes

I am skeptical that a SBC-based host can run HDF5 and keep up
with the received data. My quad Core I7-3740 3.4 GHz can not
keep up with 4 x 192k from one antenna (one fourth the DE
requested throughput). It may be better to run HDF5 only on the
snapshot that is uploaded to the Central Server. That way it
doesn't have to run at real-time speed, it only needs to code a small
subset of the data and can run at a much slower rate paced by how
fast the upload link is.

Data format.  The DE will downconvert and decimate the received
samples. This will produce 24 bit I and 24 bit Q samples, probably 2's
complement binary.  These will need to be converted to single
precision floating point I and floating point Q prior to HDF5 encoding.

 -- Tom, N5EG



On Fri, May 24, 2019 at 12:40 PM Engelke, Bill via TangerineSDR <tangerinesdr at lists.tapr.org<mailto:tangerinesdr at lists.tapr.org>> wrote:
Scotty - Please see attached, updated to include some of the things discussed at Dayton.  Next I will work on the Functional Specifications for the Central Control & Database system.

If anyone would like me to start posting to the TAPR github or somewhere, please just text credentials to my mobile number, below.  I can assure everyone that I will not make a mess of it, having done this before.

W. D. Engelke (Bill), Asst. Research Engr.
Center for Advanced Public Safety
Cyber Hall
The University of Alabama
Tuscaloosa, AL 35487
Desk: (205) 348-7244
Mobile: (205) 764-3099

--
TangerineSDR mailing list
TangerineSDR at lists.tapr.org<mailto:TangerineSDR at lists.tapr.org>
http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20190529/12619967/attachment-0001.html>


More information about the TangerineSDR mailing list