<div dir="ltr">Hi John,<div><br></div><div> I used the very latest "fldigi", downloaded 24 hours before the FMT. The key difference perhaps is that I did the analysis in retrospective mode on already recorded data - not live from the antenna. That is a different use case from yours, and different use cases are not of course going to use the same methods. Not suggesting either that a Python module be inserted real-time into anyone's flow on a resource limited platform (how did we get there?), but that Python is the language of choice for back-end, non-realtime, iterative, retrospective analysis. That frankly is where I spend 100% of my time as a scientist.</div><div><br></div><div> So a scenario where a C language, fast algorithm is used for all the realtime needs, and that this very same algorithm is then bundled into an auto-generated Python module for backend non-realtime retrospective work, serves all customers from what I can tell.</div><div><br></div><div>Cheers</div><div>Phil W1PJE</div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 28, 2020 at 11:57 AM John Gibbons via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">All,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">With my mods, FLDigi has been working flawlessly for use by us. There are some things in the user interface you need to be aware of, and unfortunately Phil got bit by a few of them. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I could get into them, but it isn't going to apply to us long term.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">What version of FLDigi were you using? </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">FLdigi-4.1.12 (just released last Monday) was the first version that has my improvements in it (that came from this WWV project), and I did use it for the </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">FMT (and <span style="font-family:-webkit-standard;font-size:medium">- shameful brag alert..... </span> had an error of 0.01 hHZ on 40M and 0.05Hz on 80M) 😵</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">It does work. But as usual, the devil is in the details....</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I'll be pushing out a report on a test I just completed on the Gen1 Radio I designed for the low cost PSWS and using FLDigi shows how well it performs for frequency estimation.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">We've been using it since July 2019, and a lot of our data collection has been done through this radio receiver (ALL of the data collection has been using my modified version of FLDIGI-4-1.09).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">My test was a COMPLETE 'system' test - from antenna input to file numbers output. I wanted to see how well the whole system was doing including the freq analysis algorithm.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The 'final' version will be the algorithm extracted and customized for our use. <b>FLDIGI is NOT our long term solution</b> (it never was) - it's a stepping stone.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">With the processor / memory limitations of the low cost PWSW we will try to do python code, but coming from 35+ years of designing embedded real-time systems it will more likely be C / C++ code.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The reason is that an interpreted language (i.e. python) runs so much slower (10x - 100X) and uses up so much more system resources that it bogs down (and usually fails). </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Also, depending on the interpreter to (not) getting an OS upgrade that breaks our code is just a bad idea. Been there.... been burnt by it... don't want to do it again. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Having compiled code means WE control the updates and not the latest release of an interpreter. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">And Gen 2 of my radio will attempt to do 4 channels of WWV ( or some on CHU) at the same time.. Running 4 instances of FLdigi simply is not an option - it just will not work.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">BUT, the final software is being started with the tests being run now in python, and concurrently I'm creating tests in C++. Again, the OS overhead of running an interpreted language for a real time </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">data acquisition is not done in industry for lots of good reasons with lots of test cases to back it up. If you want a reliable system, using an interpretive language is simply not the way to go.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">We have made some advancement in the frequency determination algorithm(s), and even had one of our helpers try/work on implementing one in a MAX10 FPGA implementation. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">He got interrupted this semester by having to teach a new embedded systems IOT class, but hope to get that development back on track soon (stop drooling Scotty😁🤔😃).<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><div><div><div><div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">More to come later...</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></div><br></div><div><br></div><div><br></div><div><br></div><div>John C. Gibbons<br></div>Director - Sears Undergraduate Design Laboratory<br></div>Dept. of Electrical Engineering and Computer Science</div></div>Case Western Reserve University <br></div><div>10900 Euclid Ave, <span style="font-size:12.8px">Glennan 314</span><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><br></span></div></div><div><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px">Cleveland, Ohio 44106-7071</span><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px">Phone </span><a href="tel:216-368-2816" value="+12163684572" style="color:rgb(17,85,204);font-family:Helvetica;font-size:12.8px" target="_blank">(216) 368-2816</a><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"> FAX </span><a href="tel:216-368-6888" value="+12163686888" style="color:rgb(17,85,204);font-family:Helvetica;font-size:12.8px" target="_blank">(216) 368-6888</a><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px">E-mail: </span><a href="mailto:jcg66@case.edu" style="color:rgb(17,85,204);font-family:Helvetica;font-size:12.8px" target="_blank">jcg66@case.edu</a><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 28, 2020 at 8:07 AM Dr. Nathaniel A. Frissell Ph.D. via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal">Hi Phil,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks for the comments. I think that is very good to consider. In light of review, I think it is a good idea to postpone FLDigi integration at this time. As Phil said, we should pull out the frequency estimation routine for separate testing
and possible direct use. I believe Skylar Dannhoff is working on this. For the WWV monitoring program, we also do need to have the ability to save both the raw data and the derived frequency estimation data product.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">73 de Nathaniel W2NAF<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> TangerineSDR <<a href="mailto:tangerinesdr-bounces@lists.tapr.org" target="_blank">tangerinesdr-bounces@lists.tapr.org</a>>
<b>On Behalf Of </b>Phil Erickson via TangerineSDR<br>
<b>Sent:</b> Tuesday, April 28, 2020 7:12 AM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
<b>Cc:</b> Phil Erickson <<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a>><br>
<b>Subject:</b> Re: [TangerineSDR] Notes from PSWS / TangerineSDR call of 04-27-2020<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi all,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> Sorry that I haven't been able to make these discussions much lately. COVID-19 has added a huge amount of work here.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 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.)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> 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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> Sorry to be negative, but this recent experience is I think quite relevant to Tom's (1) item.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">73<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Phil W1PJE<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Tue, Apr 28, 2020 at 12:27 AM Tom McDermott via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><br>
Notes from PSWS / TangerineSDR call of 04-27-2020<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<p class="MsoNormal">-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal">----<br>
Phil Erickson<br>
<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><u></u><u></u></p>
</div>
</div>
</div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">----<br>Phil Erickson<br><a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br></div>