[TangerineSDR] Notes from PSWS / TangerineSDR call of 04-27-2020

[Phil Erickson]

Hi all,

  Sorry that I haven't been able to make these discussions much lately.
COVID-19 has added a huge amount of work here.

  I'm fairly concerned about using "fldigi".  In the recent Frequency
Measurement Test a few days ago, I decided to use its frequency algorithm
in the "ANALYZE" portion in order to track the unknown carrier that K5CM
was putting out.  I had a bunch of data already recorded through things
like Gnuradio stacks; for this discussion, let's assume I had I/Q data in
some kind of format similar to what Tangerine would put out.  (It was
DigitalRF to be specific.)

  Frankly, it was a disaster.  The only way you can input data that I could
find is through WAV files, so I had to convert all my data to that format.
When you start up the program, it immediately starts generating bogus data
on nothing while you fumble around getting to the menu that plays back a
WAV file.  When the WAV file ends (I chose non-loop for playback), you get
another bunch of junk data while you are fumbling around with literally
quitting the entire program as the only way I could figure out to stop the
analysis.  While the WAV file is playing and the algorithm is analyzing, I
found that there are occasionally jumps/glitches in the time stamp because
the time stamp has nothing to do with the WAV file and everything to do
with how your computer analysis burden is keeping up (or not) with realtime.

  The resulting files needed a lot of hand editing afterward to remove junk
before I could profitably do anything with them.  This took a lot of time.
I considered myself lucky that I had 2 minutes of data to look at for the
tone analysis that were clear enough that I could spot them on a very
simple uniform-X-axis vs frequency plot.  If I hadn't been able to see
that, it would have been game over.

  So I would definitely not use it again for any kind of serious analysis.
In fact, that is why we've separately requested that the statistical
frequency measurement algorithm buried within "fldigi" be broken out into a
separate Python routine. I believe CWRU is working on it.  I looked at the
fldigi code at one point to see if I could do it, but it's an
interconnected quasi-monolithic series of routines with unclear
cross-connections and internal assumptions.  That was a research project
that I ultimately passed on for lack of time.

  Sorry to be negative, but this recent experience is I think quite
relevant to Tom's (1) item.

73
Phil W1PJE


On Tue, Apr 28, 2020 at 12:27 AM Tom McDermott via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

>
> Notes from PSWS / TangerineSDR call of 04-27-2020
>
> 1. Discussion of bundling / interfacing FLDIGI into the TangerineSDR
> software. Tangerine produces IQ data, while FLDIGI may need WAV data (does
> it accept other formats?). Having the ability to use the various FLDIGI
> capabilities would be nice to have.  There would be a need to reject the
> positive or negative frequency spectra to convert from complex to real,
> multiple approaches are available.
>
> 2. Discussion of a lightning detector for the magnetometer board. Does it
> need an I2C interrupt?  Scotty mentioned that he may want to abandon the
> PMOD connector and turn the magnetometer board into a Raspberry-PI HAT.
> Dave discussed some potential issues with the I2C interface on this
> particular part, he is still trying to find some details on the issue.
> Another question: what is the science need for lightning detection in terms
> of range and sensitivity? Gerry Creager might be a good person to ask about
> the science requirement.
>
> -- Tom, N5EG
>
> --
> 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/20200428/fc940c36/attachment.html>