[TangerineSDR] Weekly Status report

Fri Jun 23 16:47:48 EDT 2023

Phil should be in Germany.

Dave KV0S

On Fri, Jun 23, 2023, 12:00 PM Jonathan via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> Hi Franco,
>
> Thank you for this investigation! I agree with you, iqplay and iqrecord
> probably listens on the multicast group from the SDR interface application.
> Phil, can you comment on this?
>
> It does looks like the iq mode will create the slice of IQ data from
> radiod. Phil, can you comment on this?
>
> I also agree that there are a few sources of input to GNU Radio, and a GNU
> Radio module will have to be created to join the multicast group of
> interest and pipe the output to the rest of the GNU Radio processing chain.
> For the time being, writing iq streams from slices or from the SDR
> interface application (ie rx888d) seems like the only way to input the IQ
> data into GNU Radio.
>
> Thanks.
>
> Jonathan
> KC3EEY
>
> On Thu, Jun 22, 2023 at 11:05 PM Franco VENTURI <fventuri at comcast.net>
> wrote:
>
>> Jonathan,
>> tonight I spent some more time reading ka9q-radio source code and Phil's
>> documentation (
>> https://github.com/ka9q/ka9q-radio/blob/main/docs/Realtime%20Multicast%20for%20SDR%20Interconnection%20-%20Phil%20Karn.pdf),
>> and I think the way the various pieces work is more or less like this:
>>
>> - iqrecord and iqplay work directly with the I/Q stream from the
>> front-end SDR, in our case the RX888 - specifically iqplay 'plays' an I/Q
>> recording file from a previous session and 'radio' can connect to it
>> pretending it is connected to a live SDR; this setup would be good for
>> testing 'radio' and the other programs downstream, but I don't think this
>> is what we want to do
>>
>> - also I think iqrecord and iqplay deal with the whole I/Q stream (at
>> 64.8Msps or 129.6Msps) before the 'magic' of Phil's fast convolution filter
>> bank occurs
>>
>> - on the other hand in 'modes.conf' Phil defines a linear mode called
>> 'iq' (https://github.com/ka9q/ka9q-radio/blob/main/modes.conf#L71-L76),
>> with a sample rate of 12ksps, which I think is the I/Q stream that the
>> Grape wants
>>
>> - the 'channels = 2' line at the end of that section makes me think that
>> 'radio' in this case outputs a stereo PCM stream with I on the left channel
>> and Q on the right channel
>>
>>
>> I also looked at the examples of the file/wav source blocks from GNU
>> Radio, and I have the impression that they can only read 'regular' files -
>> the fact that on the 'File Source' wiki page (
>> https://wiki.gnuradio.org/index.php?title=File_Source) they have a note
>> that says "The file MUST be on the local computer" seems to also confirm
>> this assumption, but I might be wrong
>>
>> This said, I don't think it would be that hard to create an OOT GNU Radio
>> module for a source block that reads I/Q samples directly from the
>> ka9q-radio 'radio' multicast stream, similar to what 'pcmcat' does; if you
>> think it could be useful, I'll look into this in more detail (probably
>> after this weekend, when I find some time).
>>
>> Franco K4VZ
>>
>>
>> On 06/22/2023 9:59 AM EDT Jonathan <emuman100 at gmail.com> wrote:
>>
>>
>> Hi Franco,
>>
>> pcmcat receives RTP streams of demodulated audio and pipes it to stdout.
>> For the Grape, IQ data is needed. In this case, radiod would need to be
>> configured to output only the IQ stream. Possibly iqplay can pipe IQ data
>> to stdout? Can GNU Radio read from stdin? If so, that might be worth a
>> shot.
>>
>> Jonathan
>> KC3EEY
>>
>> On Thu, Jun 22, 2023 at 8:59 AM Franco VENTURI <fventuri at comcast.net>
>> wrote:
>>
>> For the integration between ka9q-radio (its 'radiod' daemon, to be exact)
>> and GNU Radio, you may want to look at the simple program 'pcmcat' (
>> https://github.com/ka9q/ka9q-radio/blob/main/pcmcat.c) that Phil wrote
>> to connect to the multicast stream, and write the PCM output to stdout.
>>
>> I took a quick glance at it this morning and I believe it shouln't be
>> hard to write a GNU Radio OOT module starting from the code from the
>> existing GNU Radio wav source module, and replace the code that reads from
>> the wav file with code that reads from the multicast stream, like Phil does
>> in 'pcmcat'.
>>
>> Franco
>>
>>
>> On 06/22/2023 6:39 AM EDT Jonathan via TangerineSDR <
>> tangerinesdr at lists.tapr.org> wrote:
>>
>>
>> Bill,
>>
>> I think he means the GNU Radio graph that takes in the Grape mixer audio
>> output and then downmixes it to 10Hz carrier baseband signal in Digital RF.
>> That baseband signal is then plotted in frequency to show the doppler shift
>> throughout the diurnal.
>>
>> This can be implemented in GNU Radio processing chains using the IQ
>> stream, either individual slices around each frequency or a wider bandwidth
>> slice for each time station, and for AM broadcast carriers too. You would
>> have to have an individual chain for each station, but probably use one IQ
>> data file.
>>
>> Jonathan
>> KC3EEY
>>
>> On Thu, Jun 22, 2023 at 6:22 AM Bill Liles via TangerineSDR <
>> tangerinesdr at lists.tapr.org> wrote:
>>
>> 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
>>
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
>> --
> 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/20230623/dc09cdf4/attachment-0001.html>