[TangerineSDR] Weekly Status report

[Bill Liles]

Nathaniel, I am not sure what exactly you mean by “the same processing
chain.” The same as what?

1) one RX888/KA9Q acting as a grape 2 or
2) three RX888/KA9Q acting as three grape 1s connected together?

I assume one RX888/KA9Q acting like a grape 2 but want to be clear.

If using one RX888/KA9Q to receive WWV/H and CHU, why limit to three
frequencies? Can receive all the WWV/H frequencies and CHU. And for that
matter also the AM transmitter used by Dartmouth.

Bill NQ6Z

On Thu, Jun 22, 2023 at 00:23 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/fa962898/attachment-0001.html>