[TangerineSDR] TangerineSDR Digest, Vol 7, Issue 12

Larry Dodd 101science at gmail.com
Mon Oct 14 12:12:00 EDT 2019


Scotty
Yes just energy content. No demodulation required. We monitor for weak
signal Jupiter storms, weak ionospheric signatures, and solar flares. So
good sensitivity (>.5uV) and dynamic range are important parameters.
Ability to limit bandwidth to 15 to 30 MHz is desired. Minimum spurs and
low noise. If you need more specific specifications we can work that up for
you.
Larry

On Mon, Oct 14, 2019 at 12:00 PM <tangerinesdr-request at lists.tapr.org>
wrote:

> Send TangerineSDR mailing list submissions to
>         tangerinesdr at lists.tapr.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
> or, via email, send a message with subject or body 'help' to
>         tangerinesdr-request at lists.tapr.org
>
> You can reach the person managing the list at
>         tangerinesdr-owner at lists.tapr.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of TangerineSDR digest..."
>
>
> Today's Topics:
>
>    1. Re: TangerineSDR Digest, Vol 7, Issue 10 (Scotty Cowling)
>    2. Re: Elevator Pitch for Tangerine PSWS (Scotty Cowling)
>    3. Re: Seeking your Review and Comment on Tangerine SBC
>       Functional Specification (Engelke, Bill)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 13 Oct 2019 13:59:08 -0700
> From: Scotty Cowling <scotty at tonks.com>
> To: tangerinesdr at lists.tapr.org
> Subject: Re: [TangerineSDR] TangerineSDR Digest, Vol 7, Issue 10
> Message-ID: <c238a2b4-38c7-0854-141d-e46844bcf4a5 at tonks.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Larry,
>
> Welcome to the list! What kind of data are you looking for in the 15 to
> 30 MHz spectrum? Are you just looking for energy content or are you
> looking to demodulate certain sub bands? Or maybe energy content in
> specific sub-bands?
>
> Just trying to get an idea of the processing that the TangerineSDR will
> need to do on the input data in order to make sure that we can fulfill
> your use case.
>
> 73,
> Scotty WA2DFI
>
> On 2019-10-12 09:29, Larry Dodd via TangerineSDR wrote:
> > Hi
> > I?m a member of the NASA volunteer RadioJOVE project. We are very
> interested in your work to produce a PSWS with TangerineSDR. We monitor the
> 15 to 30 MHz spectrum 24/7/365 for Jupiter storms, Solar avtivity and the
> ionosphere in general and looking for an SDR to meet our future needs.
> Thanks to everyone working on this project.
> > Larry
> > K4LED
> >
> >> On Oct 12, 2019, at 12:00 PM, tangerinesdr-request at lists.tapr.org
> wrote:
> >>
> >> ?Send TangerineSDR mailing list submissions to
> >>     tangerinesdr at lists.tapr.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>     http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
> >> or, via email, send a message with subject or body 'help' to
> >>     tangerinesdr-request at lists.tapr.org
> >>
> >> You can reach the person managing the list at
> >>     tangerinesdr-owner at lists.tapr.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of TangerineSDR digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>    1. Elevator Pitch for Tangerine PSWS (Kristina Collins)
> >>    2. Re: Elevator Pitch for Tangerine PSWS (Phil Erickson)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Fri, 11 Oct 2019 15:06:22 -0400
> >> From: Kristina Collins <kvc2 at case.edu>
> >> To: tangerinesdr at lists.tapr.org
> >> Subject: [TangerineSDR] Elevator Pitch for Tangerine PSWS
> >> Message-ID:
> >>     <CAEeerr78U8UZP96jECqp3wW+wQEZpjg5_oE-E7GuiYOZcxKEpQ at mail.gmail.com
> >
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hi all,
> >>
> >> I'm putting together an article for Eos (eos.org) on the use of ham
> radio
> >> in geoscience, focusing on the two versions of the PSWS. What salient
> >> points should I be making about the Tangerine and its role? I have a few
> >> hundred words to work with for that part of the article.
> >>
> >> Bonus question for the space scientists in the audience (looking at you,
> >> Phil & Nathaniel): What should I say about TIDs and other phenomena we
> want
> >> to characterize?
> >>
> >> -KC
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191011/b0ab43b4/attachment-0001.html
> >
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Fri, 11 Oct 2019 15:08:46 -0400
> >> From: Phil Erickson <phil.erickson at gmail.com>
> >> To: TAPR TangerineSDR Modular Software Defined Radio
> >>     <tangerinesdr at lists.tapr.org>
> >> Subject: Re: [TangerineSDR] Elevator Pitch for Tangerine PSWS
> >> Message-ID:
> >>     <CAAZaqEuy31y=S5Q=6k3TOTJ4+g9CH+odKCSZu2U_AxjisJONkQ at mail.gmail.com
> >
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Hi Kristina,
> >>
> >>   I can't answer that question until I see the context of the rest of
> the
> >> article.  Best to put a draft together and share it in an editable
> online
> >> place such as Overleaf (if LaTeX source) or Google Docs, and then we can
> >> crowdsource it.
> >>
> >> Cheers
> >> Phil
> >>
> >>> On Fri, Oct 11, 2019 at 3:07 PM Kristina Collins via TangerineSDR <
> >>> tangerinesdr at lists.tapr.org> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I'm putting together an article for Eos (eos.org) on the use of ham
> radio
> >>> in geoscience, focusing on the two versions of the PSWS. What salient
> >>> points should I be making about the Tangerine and its role? I have a
> few
> >>> hundred words to work with for that part of the article.
> >>>
> >>> Bonus question for the space scientists in the audience (looking at
> you,
> >>> Phil & Nathaniel): What should I say about TIDs and other phenomena we
> want
> >>> to characterize?
> >>>
> >>> -KC
> >>> --
> >>> TangerineSDR mailing list
> >>> TangerineSDR at lists.tapr.org
> >>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
> >>>
> >>
> >> --
> >> ----
> >> Phil Erickson
> >> phil.erickson at gmail.com
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <
> http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191011/b6bd032d/attachment-0001.html
> >
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> TangerineSDR mailing list
> >> TangerineSDR at lists.tapr.org
> >> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
> >>
> >>
> >> ------------------------------
> >>
> >> End of TangerineSDR Digest, Vol 7, Issue 10
> >> *******************************************
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 13 Oct 2019 15:59:08 -0700
> From: Scotty Cowling <scotty at tonks.com>
> To: tangerinesdr at lists.tapr.org
> Subject: Re: [TangerineSDR] Elevator Pitch for Tangerine PSWS
> Message-ID: <5f9d9f8d-dec2-53d4-9cb9-a6c60d04185d at tonks.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi Kristina,
>
> The main points of the TangerineSDR are:
> Wide-band Direct Sampling DDC (four 500MByte/s digital input paths) with
> on-board FPGA
> High-speed data interfaces (USB 3.0 (@5Gbps) *and* dual GBe)
> Modularity and expandability (up to 4 RF input channels, selectable
> oscillator quality (TCXO/OCXO/GPSDO) and expandable low- and high-speed
> I/O)
> Easy pairing with SBC or Desktop PC (dual GBe ports) allows inexpensive
> pre-processing and network authentication
>
> Is that some help in filling a few hundred words? The above is more like
> a features list, so here are a few tie-ins to PSWS:
> oscillator can be upgraded to GPSDO for PSWS high-resolution data
> time-stamping
> dual, synchronously clocked 14-bit ADCs for synchronous RF sampling
> seamlessly integrates with a Single-Board Computer to provide PSWS
> pre-processing and authentication
> high-speed data interfaces provide wide simultaneous receive bandwidth?
> (>20MHz via GBe, >100MHz USB3.0 maximum)
> FPGA can split data into eight 192KHz simultaneous virtual receive
> streams, each centered anywhere within 0-60MHz antenna input
>
> Hope some of this is helpful.
>
> 73,
> Scotty WA2DFI
>
> On 2019-10-11 12:06, Kristina Collins via TangerineSDR wrote:
> > Hi all,
> >
> > I'm putting together an article for Eos (eos.org <http://eos.org>) on
> > the use of ham radio in geoscience, focusing on the two versions of
> > the PSWS. What salient points should I be making about the Tangerine
> > and its role? I have a few hundred words to work with for that part of
> > the article.
> >
> > Bonus question for the space scientists in the audience (looking at
> > you, Phil & Nathaniel): What should I say about TIDs and other
> > phenomena we want to characterize?
> >
> > -KC
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191013/06d71c12/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 14 Oct 2019 15:22:30 +0000
> From: "Engelke, Bill" <bill.engelke at ua.edu>
> To: Rob Wiesler <robert.wiesler at case.edu>, "TAPR TangerineSDR Modular
>         Software Defined Radio" <tangerinesdr at lists.tapr.org>
> Subject: Re: [TangerineSDR] Seeking your Review and Comment on
>         Tangerine SBC Functional Specification
> Message-ID: <52047bd0a2254d3c80ed98c98973629a at ua.edu>
> Content-Type: text/plain; charset="utf-8"
>
> Rob, I added the distribution list as you suggested. I greatly value your
> knowledgeable feedback, so please keep it coming.
>
> Regarding Celery: I am not crazy about Celery; I mention it only because
> it is used in the SatNOGS system.  We have decided that we wish base the
> PSWS Central Control system/database on SatNOGS (at least for Phase 1), as
> its functionality and UI seems to overlap so much on our needs. Having said
> that (since you mention that Celery may not fit the need), we should
> probably discuss what data is going to be generated, and then seek the
> right package for managing the uploads.  (As an aside, I have the entire
> SatNOGS system running on a server; if you like, we can look at it together
> on a Zoom session, and see what they are actually using Celery for).
>
> On the topic of heterogeneous vs homogeneous data, right now we envision
> two distinct data types:
>
> 1. Raw I/Q data from ring buffer ("Use Case 1").  These data are stored in
> ring buffer in Digital RF format. On request from Central Control, a
> selected chunk of data (from start time A to end time B) are to uploaded.
> Upon receipt, Central Control stores these as Digital RF files, with the
> file name being generated automatically, and the file name being stored in
> the database.
>
> 2. Pre-processed data.  ("Use Case 3") This case is for users with low
> bandwidth. An upload occurs about once per second (or could be as low as
> once per minute). GNURadio samples the bands (normally a few Hz around each
> WWV station), and does an FFT. The FFT is uploaded (along with magnetometer
> data) and stored directly in a database table.
>
> (There is a third situation, "Use Case 2," or "firehose," where raw data
> is streamed directly to a server. Central Control does not support that; it
> would be received by the institution's server farm or supercomputer).
>
> Use Case 3, best I can tell, matches what SatNOGS does: they pre-process
> received spectrum into a waterfall, and that's what they upload. We can
> certainly ask them why they picked Celery to use (for all I know, maybe
> they regret it). Maybe they are using Celery for something else (i.e., not
> for uploading). Its complexity definitely increases project risk.
>
> There are numerous other queueing packages. I have used IBM's Websphere MQ
> (works great, but costs a fortune) and MQTT, both with good success;
> however, I also gather we need to distinguish between task queueing and
> data queueing. Maybe there is an apples-to-oranges here.  Anyway , let me
> know your thoughts.
>
> -73- Bill, AB4EJ
>
>
> -----Original Message-----
> From: Rob Wiesler <robert.wiesler at case.edu>
> Sent: Saturday, October 12, 2019 6:03 PM
> To: Engelke, Bill <bill.engelke at ua.edu>
> Subject: Re: Seeking your Review and Comment on Tangerine SBC Functional
> Specification
>
> Bill, I won't re-add the mailing list to the distribution list without
> your permission, but in general please keep responses on-list, as it
> becomes difficult for anyone else to participate otherwise.
>
> On Wed, Oct 9, 2019 at 4:33 PM Engelke, Bill <bill.engelke at ua.edu> wrote:
> > Rob - for file backlogs, the plan is to use Celery,
> > (http://www.celeryproject.org/) , this works very well for uploading
> > the large # of files for SatNOGS, and integrates well with Django.  I
> > had been hoping to continue to use that. (I will still research
> > inotify so I know what it can do as well ) -
>
> I highly recommend not adding a dependency on Celery for this particular
> thing (or, preferably, at all).  Celery is a queue for asynchronous
> processing of heterogeneous tasks, while what we need is a queue for serial
> processing of homogeneous data.  We don't want our individual data files to
> end up in different tasks, because that implies a separate connection to
> upload each file (versus a single TCP stream where each data file is sent
> in serial for better throughput).
> We want one upload task, and a data queue (not a task queue) sitting in
> front of it.  If SatNOGs uses Celery, it's probably not involved in the
> step you're thinking of, and if I'm wrong about that, then that's a giant,
> fluorescent red flag saying that we shouldn't be following their lead on
> this.
>
> I'll also point out that Celery is a incredibly complicated library
> (>7000 lines without counting dependencies) that introduces a ton of
> dependencies.  The Celery FAQ gives lame, half-baked excuses for why this
> doesn't matter, but it definitely does matter (which I could get into, but
> for now that's outside the scope of this document).  The only upside is
> that Celery is actually packaged for Debian, so if we did decide to use it
> (for a purpose to which it's actually suited), those dependencies are
> somewhat more manageable.
>
> Why do you think that Django integration is relevant?  I wasn't aware that
> there was any interaction between the store-forward mechanism and a web
> page running on the SBC.  Even if we want to publish how many stored,
> unsent data files there are (and how much space they're taking up (In
> memory? On disk?) and how much space is left), there are significantly
> better ways to do that.
>
> The first draft of this email had more reasons not to use Celery, because
> it isn't at all suited as a store-forward system.  Now that I'm awake and
> thinking clearly, we don't necessarily want to store every single data file
> to an actual disk in case of power loss before the upload catches up with
> the backlog (since that's currently a sticking point for the ringbuffer),
> so those points are moot.
> However, I will say that if we overcome the problems associated with the
> ringbuffer, then Celery is *definitely* not what we want to use.
> Note also that inotify still works in a memory-backed tmpfs, so if we
> wanted to write an in-memory data queue first, then turn it into a on-disk
> ringbuffer later, that would be a trivial change.
>
> ------------------------------
>
> Subject: Digest Footer
>
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>
>
> ------------------------------
>
> End of TangerineSDR Digest, Vol 7, Issue 12
> *******************************************
>
-- 
K4LED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191014/1de4ee72/attachment-0001.html>


More information about the TangerineSDR mailing list