Steve:
Thanks for the great response as always.
Yes, I've been having fun playing with this stuff. DVB-T is the EU standard
for digital broadcast television. The standard is different in the US(go
figure☺). The dongle I bought was around $12 USD. I've heard WWV on 25MHz,
US Citizen's Band around 27MHz, US Broadcast FM 88-108 MHz, Aircraft
120-135 MHz, 2m Amateur 144-148 MHz, NOAA Weather 162 MHz, and 70cm Amateur
440 Mhz. Normal Amateur bands and shortwave stations below 24 MHz require
the 24 MHz upconverter which I haven't built yet). The output of gqrx can
be fed through Pulse Audio to fldigi for decoding digital data streams(I
have just started looking at this feature).
Based on your comments I went and read the Perl Threads tutorial and
searched Perl Monks for Wx and Threads(very little there). Also no working
example on the wxPerl Wiki.
I think Threads and Threads::Shared with lock() is the way to go. Now I
just have to go figure it out!
Thanks again,
James
On Thu, Sep 24, 2015 at 9:47 AM, Steve Cookson <steve.cook...@sca-uk.com>
wrote:
> Hi James,
>
> On 21/09/15 23:43, James Lynes wrote:
>
> I apologize for the length of this question in advance.
>
> Background: The July 2015 issue of Nuts and Volts magazine had an article
> on using an inexpensive DVB-T USB dongle along with a 24MHz upconverter as
> the basis for an HF and higher Software Defined Receiver(SDR).
>
> Amazing, I didn't know there were such things as SDRs, although I did play
> around with the idea of using a microprocessor to act as a video capture
> card, which I guess is a similar idea. So you're using a TV receiver as a
> radio receiver? Slightly inverted, but cool.
>
> The software used in the article was SDR# an MS-Windows application. As I
> am an Ubuntu user, I looked for a similar Linux application. I found gqrx.
> While waiting on parts to build the upconverter, I installed gqrx-sdr from
> the Ubuntu Software Center. It ran and pulled in various signals from 24MHz
> up, but was unstable. Turns out this was a pretty old version and after
> uninstalling and then installing sudo add-apt-repository
> ppa:gqrx/snapshots, a stable version was found.
>
> Well, gqrx has a Remote Control feature that can accept commands over a
> Telnet connection and more digging turned up a perl script(gqrx-scan) that
> uses this interface, through Net::Telnet, to implement a scanner feature.
> gqrx-scan has many bells and whistles that I wouldn't ever use so I wrote a
> lite/crude version(lite.pl) that just scans from F1 to F2 repeatedly. For
> more flexibility(and practice) I decided to expand lite.pl into a wxPerl
> application(wxgqrxLite.pl), mostly a bunch of text controls and sizers.
>
> Problem 1: lite.pl is basically a while(1) loop scanning from F1 to F2,
> listening for a second when a strong signal is detected.
> Question 1: Where should the non-GUI stuff fit into a wxPerl application?
> Current Solution 1: I created two timer events and put the scan code in
> one and the listen code in the other. They trigger each other alternately
> at separate rates(30msec and 2 seconds). Only one of these events/timers
> are active at a time. This actually works!
>
> This depends on how decoupled you are. If you are completely decoupled
> and just want an on or off signal (and I have a number of cases where I do
> this) then a parallel process will do it. For instrance I have a process
> to check network availability. Sometimes the network availability is
> mixed, like on the edge of a mobile or wifi signal, in this case wx::Timer
> will appear to hang and your process will freeze. If this is not what you
> want, use a separate process. Here is an example where I use a temporary
> file with 1 byte in it.
>
> `echo 0 > /home/image/Documents/Endoscopia/DB/nw.txt`; #
> Create base file with '0' (network not available)
>
> # if in case previous instance crashed
> with nw available
>
> # and it now isn't.
>
> $gl_nw_process_id_int=Wx::ExecuteCommand("perl iM_nw.pl",
> wxEXEC_ASYNC); # Maintain network status file asynchronously.
> .
> .
> .
> call other stuff.
> .
> .
> .
> # on exit or crash
> # Switch off nw monitor.
> Wx::Process::Kill( $gl_nw_process_id_int, Wx::wxSIGKILL() ) if
> $gl_nw_process_id_int;
>
> I then use wx::Timer to reread the file and there is no pause. It always
> returns 1 or 0.
>
>
> Problem 2: You can't start scanning unless the Telnet connection is open,
> otherwise it throws a connection refused error.
> Solution 2: Add code to track scanning and connection status to prevent
> the user from doing illegal operations or multiple consecutive hits of the
> same button, and popup message boxes to flag these errors.
>
> You can use a similar solution to the above.
>
>
> Problem 3: The error checks, interlocks and message boxes between the
> {startbutton} and {stopbutton} events seems to be ok. The same cannot be
> said for the {connectbutton} and {disconnectbutton} events. There seems to
> be a race/async processing problem between establishing the Telnet
> connection(which errors and should set the {tnerror} flag) and the mainline
> event code. The three individual print Dumper $self->{tnerror} statements
> all show {tnerror} = 0 (wrong!) while the print Dumper $self statement
> below shows {tnerror} = 1 (right!). There's a delay in this flag being set
> in the Net::Telnet call which causes the rest of the {connectbutton} event
> routine to process a wrong flag value.
> Question 3: HELP ????? I'm out of ideas...
>
> Maybe a similar one a again?
>
>
> Question 4: Does event->Skip() terminate the current event handler like
> last terminates a while loop?
>
> You have Skip and Veto, Skip says continue and imagine I am not here. Eg
> if you pressed the escape key out of a dialog box, if you have code there,
> the dialog box will not exit. If you use ->Skip, it will, as it would as
> if there was no code there.
>
> Veto says, undo what you just did and is not always applicable.
>
> Neither of these says this routine over-rides and replaces the default
> behaviour.
>
> (People, do you all agree?).
>
>
> Code attached. It will run without the dongle or gqrx installed. It just
> fails on the Telnet connection.
>
> Thanks for your input.
>
> Broadly speaking your choices are Wx::Timer, Threads and
> Wx::ExecuteCommand/Wx::Process
>
> Good luck,
>
> Steve
>
>
> James
> Ubuntu 14.04.2LTS/perl 5.18.2/wxPerl 3.0.1/HP 15 Quadcore Laptop
>
>
>
>
