[TangerineSDR] Weekly Status report

[Jonathan]

Rob can take the GNU Radio block diagram used by the Grape 1 Digital RF
configuration that Tom wrote, modify the LO (probably sample rate too) of
the multiplicative mixer to produce an appropriate downmixed frequency of
the carrier baseband. You can have one for all time stations.

The issue is that I am not aware of a way to get the multicast IQ slice
stream into GNU radio unless you write it to files, then have GNU Radio
process the files.

Jonathan
KC3EEY

On Thu, Jun 22, 2023 at 12:23 AM Dr. Nathaniel A. Frissell Ph.D. via
TangerineSDR <tangerinesdr at lists.tapr.org> wrote:

> Thank you, Dave and Franco. This all looks good.
>
>
>
> A brief update from me. We have a student, Rob Troy, who is tasked with
> working with the RX888 and the KA9Q software. Rob reports he now has the
> RX888/KA9Q up and running at Scranton.
>
>
>
> Rob’s next task is to make the RX888/KA9Q combination “emulate” the output
> of a Grape2. Stan Pozerski KD1LE currently has three Grape 1’s tied
> together all outputting their data into a single GNU Radio/DigitalRF
> stream. I believe this is essentially what the Grape 2 will also be doing.
> I will be having Rob work with Stan Pozerski to get this same processing
> chain running with the RX888 instead of the Grape 1s.
>
>
>
> Next week I will be on travel with a number of students to the NSF CEDAR
> conference in San Diego, CA. So, it is likely I will not be able to be on
> the Monday telecon next week.
>
>
>
> 73 Nathaniel W2NAF
>
>
>
> *From:* TangerineSDR <tangerinesdr-bounces at lists.tapr.org> *On Behalf Of *Franco
> VENTURI via TangerineSDR
> *Sent:* Monday, June 19, 2023 10:51 PM
> *To:* David Witten <wittend at wwrinc.com>; tangerinesdr at lists.tapr.org; Mr.
> Majid Mokhtari <majid.mokhtari at scranton.edu>; Rob Robinett <
> rob at robinett.us>; Tom McDermott <tom.n5eg at gmail.com>; John Ackermann <
> jra at febo.com>
> *Cc:* Franco VENTURI <fventuri at comcast.net>
> *Subject:* Re: [TangerineSDR] Weekly Status report
>
>
>
> Dave,
>
> first of all thanks for the report and kudos for all your work.
>
>
>
> A few quick comments:
>
>
>
> - regarding the maximum throughput achievable with the FX3 the best place
> to start IMHO is Cypress AN86947 (
> https://www.infineon.com/dgdl/Infineon-AN86947_Optimizing_USB_3.0_Throughput_with_EZ-USB_FX3-ApplicationNotes-v05_00-EN.pdf?fileId=8ac78c8c7cdc391c017d073e3a2e6243)
> - as you can see there the maximum throughput is achieved using an AUTO DMA
> channel with the GPIF II interface, 32bit wide, and with a clock rate of
> 100MHz (and with 4 DMA buffer of 8kB each - bulk transfer mode)
>
>
>
> - if I remember correctly, Oscar Steila IK1XPV design is based on the
> 'cyfxbulklpauto' example (you can find it in
> 'cyfx3sdk/firmware/dma_examples/cyfxbulklpauto' in the FX3 firmware SDK
> file 'fx3_firmware_linux.tar.gz'), and on a couple of very useful
> application notes from Cypress/Infineon: AN65974 "Designing with the EZ-USB
> FX3 slave FIFO interface" (
> https://www.infineon.com/dgdl/Infineon-AN65974_Designing_with_the_EZ-USB_FX3_Slave_FIFO_Interface-ApplicationNotes-v17_00-EN.pdf?fileId=8ac78c8c7cdc391c017d07396c095deb),
> and the 'ping-pong' DMA buffers approach shown in AN75779 "How to implement
> an image sensor interface using EZ-USB FX3 in a USB Video Class (UVC)
> framework" (
> https://www.infineon.com/dgdl/Infineon-AN75779_How_to_Implement_an_Image_Sensor_Interface_with_EZ-USB_FX3_in_a_USB_Video_Class_(UVC)_Framework-ApplicationNotes-v13_00-EN.pdf?fileId=8ac78c8c7cdc391c017d073ad2b85f0d)
>
>
>
> - when I looked at what he did a few years ago I didn't think it was
> exceedingly difficult; I remember the one thing to get right is the design
> of the GPIF II state machine using the program 'GPIF II Designer' (that I
> think runs only on Windows), but we can definitely look at what Oscar did
> and follow his footsteps (I think the design of his GPIF II state machine
> is in his GitHub repository too, so we can use that as a starting point)
>
>
>
> - if I have to give you one advice is to try to 'keep things as simple as
> possible'; this is what Oscar did in his design of the BBRF103, which he
> was able to design and make in a relatively short period of time. I think
> the important thing is to get a prototype out that works even if it is not
> perfect and meet all the specifications. We can always improve from that
> but at least the first step is done.
>
>
>
> - regarding the choice of the ADC I don't think 14bit or 16bit makes much
> of a difference in terms of ENOB, since I read somewhere about diminishing
> returns at those resolutions (can't find the link now); since the FX3 GPIF
> II works with 16/32 bits at a time, using a 14bit ADC would give us two
> extra bits for each sample: one could be used for the overflow bit, and the
> MSB for the PPS from the GPSDO, which I think is what Tom is doing in the
> TangerineSDR.
>
>
>
> - and finally I expect that someone will eventually come out with the
> "ClementineSDR+" that uses the LTC2208-16, since for some reason they are
> dirt cheap on AliExpress.
>
>
>
> 73,
>
> Franco K4VZ
>
>
>
>
>
> On 06/19/2023 2:36 PM EDT David Witten <wittend at wwrinc.com> wrote:
>
>
>
>
>
> Hello All,
>
>
>
> I have attached a PDF covering what I have been doing this week, and What
> else needs to be addressed.  This primarily addresses work on an
> alternative [Clementine]SDR based on USB SuperSpeed and beyond. This is a
> further derivative of the RX-888 and its predecessors.
>
>
>
> Comments Welcome!
>
>
>
> Dave Witten, KD0EAG
>
> --
> TangerineSDR mailing list
> 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/20230622/9f9fa6b0/attachment.html>