ALE 2G extension issues

This discussion was created from comments split from: v1.462 release available.
«1

Comments

  • Thanks for this release John, I've been eagerly anticipating it.

    I tried scanning the US Cothen network and got some decent captures despite my high noise floor.

    [13:34:31] [FRQ 15091.00] [Sounding THIS WAS] [From: OFFSPR ] [His BER: 3]
    [14:30:31] [FRQ 15091.00] [Sounding THIS WAS] [From: PLASPR ] [His BER: 26]
    [14:30:32] [FRQ 15091.00] [Sounding THIS WAS] [From: PLASPR ] [His BER: 26]
    [14:30:33] [FRQ 15091.00] [Sounding THIS WAS] [From: PLASPR ] [His BER: 26]
    [14:30:34] [FRQ 15091.00] [Sounding THIS WAS] [From: PLASPR ] [His BER: 26]
    [14:30:37] [FRQ 15091.00] [Sounding THIS WAS] [From: PLASPRSPR ] [His BER: 26]
    [14:34:39] [FRQ 15091.00] [Sounding THIS WAS] [From: OFF ] [His BER: 19]
    

    However I notice that once an active sounding frequency has been found, the scan doesn't seem to resume in order to find others.

    I'm not sure if I've got it setup correctly to do that, or if that is as intended, but either way it's still a brilliant new addition to the KiWi, which will please A LOT of utility listeners, myself included.

    Thanks again for all your hard work and dedication to your (hopefully increasing) user base.

    Regards,

    Martin

  • jksjks
    edited September 2021

    I need to know the exact sequence of events where you think scanning is not properly resuming. It worked fine in all my testing. Are you starting from a "scan" entry in one of the entries or the "scan" button after an individual frequency was selected in the menu? When scanning does the decode from pressing the test button stop the scan and then resume?

    Not to say there aren't bugs. Bugs are pretty much guaranteed with this since Kiwi scanning is a whole new concept that had its share of implementation difficulties.

    And I also realize it's often difficult to say exactly how you got to a broken state. I find myself in this situation all the time. I see something broken and then wonder, "Gee, how did I get here?" It is especially frustrating when I can't then repeat the behavior.

  • It worked OK on my system also...

  • edited September 2021

    OK.... it scanned and decoded for 30+ minutes then stopped scanning (8075 system)


    Extension pop-up shows scan, but freq and waterfall is not changing


    Looks browser related ... refresh browser solved it (Linux/Chrome)

    2139Z update. Happened again. browser refresh and ext restart solved it



  • edited September 2021

    Testing with Linux/Firefox now.... no issues yet


    Experienced same with FF

  • Working nicely with FF/Win10 on a i9-9900K - this is nice! I can leave these up all day...

  • Hi John,

    I just chose the Govt US Cothen scan list and let it run.

    After a while it found this active frequency, but didn't recommence the scan.

    The waterfall and everything else was still running OK.

    I'll leave it running today and see if it happens again.

    Regards,

    Martin

  • but yet my overnight run was OK. Perhaps other browswer use has an impact

  • Updated to v1.463 tried using Firefox, Chrome and MS Edge under Win10.

    KiWi in 12 and 8 Channel modes.

    Open first KiWi session and start ALE scan.

    All OK until I open a second session.

    All waterfalls and spectrum displays freeze, but audio and scans continue.

    When I tried to setup more sessions but ran out of receiver with a waterfalls, the sessions with the waterfalls froze but the session with just the Audio FFT waterfall continued to run.

  • I tried one of my remote KiWi's and started a session with my Win10 PC then set an ALE scan running.

    I then connected a second session using my iPad, and as soon as I started the ALE Extension the iPad waterfall froze.

    The other session on the Win10 PC continued as normal.

    ----------------------------------------------

    With a single session running, the previous problem I noticed with the scan finding a signal and then pausing but not resuming has occured again, showing the message.

    Amateur, Ham: scanning paused, signal detected

    I can't see anything obvious in the log, the only ALE stuff is similar to this section.


    Sun Sep 12 12:16:10 11:30:31.059 012.        ALE_2G rx1 SEQ: @11 got 94475 expecting 94443 (32)
    Sun Sep 12 12:16:11 11:30:31.574 012.        ALE_2G rx0 SEQ: @8 got 149448 expecting 149416 (32)
    Sun Sep 12 12:16:04 11:30:32.838 012.      L GPS correcting time: 12:16:04.966 (+18) UTC 12:16:12.666 deltaT -7.700 SET
    Sun Sep 12 12:16:17 11:30:37.378 012.        ALE_2G rx1 SEQ: @31 got 94623 expecting 94591 (32)
    Sun Sep 12 12:16:17 11:30:37.796 012.        ALE_2G rx0 SEQ: @26 got 149594 expecting 149562 (32)
    Sun Sep 12 12:16:14 11:30:42.741 012.      L GPS correcting time: 12:16:14.856 (+18) UTC 12:16:22.565 deltaT -7.709 SET
    Sun Sep 12 12:16:23 11:30:43.599 012.        ALE_2G rx1 SEQ: @17 got 94769 expecting 94737 (32)
    Sun Sep 12 12:16:23 11:30:44.065 012.        ALE_2G rx0 SEQ: @13 got 149741 expecting 149709 (32)
    Sun Sep 12 12:16:29 11:30:49.956 012.        ALE_2G rx1 SEQ: @6 got 94918 expecting 94886 (32)
    Sun Sep 12 12:16:30 11:30:50.426 012.        ALE_2G rx0 SEQ: @2 got 149890 expecting 149858 (32)
    Sun Sep 12 12:16:24 11:30:52.657 012.      L GPS correcting time: 12:16:24.761 (+18) UTC 12:16:32.482 deltaT -7.720 SET
    Sun Sep 12 12:16:36 11:30:56.185 012.        ALE_2G rx1 SEQ: @24 got 95064 expecting 95032 (32)
    Sun Sep 12 12:16:36 11:30:56.700 012.        ALE_2G rx0 SEQ: @21 got 150037 expecting 150005 (32)
    Sun Sep 12 12:16:42 11:31:02.503 012.        ALE_2G rx1 SEQ: @12 got 95212 expecting 95180 (32)
    Sun Sep 12 12:16:34 11:31:02.539 012.      L GPS correcting time: 12:16:34.686 (+18) UTC 12:16:42.364 deltaT -7.678 SET
    Sun Sep 12 12:16:42 11:31:02.822 012.        ALE_2G rx0 SEQ: @5 got 150181 expecting 150149 (32)
    Sun Sep 12 12:16:48 11:31:08.726 012.        ALE_2G rx1 SEQ: @30 got 95358 expecting 95326 (32)
    Sun Sep 12 12:16:49 11:31:09.194 012.        ALE_2G rx0 SEQ: @26 got 150330 expecting 150298 (32)
    Sun Sep 12 12:16:44 11:31:11.717 012.      L GPS correcting time: 12:16:44.504 (+18) UTC 12:16:51.542 deltaT -7.038 SET
    Sun Sep 12 12:16:54 11:31:14.915 012.        ALE_2G rx1 SEQ: @15 got 95503 expecting 95471 (32)
    Sun Sep 12 12:16:55 11:31:15.433 012.        ALE_2G rx0 SEQ: @12 got 150476 expecting 150444 (32)
    Sun Sep 12 12:16:53 11:31:20.216 012.      L GPS correcting time: 12:16:53.682 (+18) UTC 12:17:00.040 deltaT -6.359 SET
    Sun Sep 12 12:17:01 11:31:21.184 012.        ALE_2G rx1 SEQ: @2 got 95650 expecting 95618 (32)
    


  • Just tried opening two sessions on one Kiwi. Just opening the ALE extension in one session will drop the waterfall refresh rate in both sessions from 23 to 11 fps. Opening the extension in both will freeze both waterfalls.

  • One ALE session running.

    Opened second session using same browser.

    Stats.

    4:30:21, v1.463, 4 SDR ch, 12 GPS ch

    GPS

    acq yes, track 1, good 0, fixes 0

    WF

    7 fps

    Audio

    48.2k, Qlen 6

    BB

    64,8,26 usi%

    1.0 GHz

    FPGA

    7%

    Net

    aud 6, wf 7, http 43, total 70 kB/s


    Started ALE extension and waterfall froze, but stats hardly changed.

    4:30:51, v1.463, 4 SDR ch, 12 GPS ch

    GPS

    acq yes, track 0, good 0, fixes 0

    WF

    8 fps

    Audio

    48.1k, Qlen 6

    BB

    63,7,27 usi%

    1.0 GHz

    FPGA

    5%

    Net

    aud 6, wf 8, http 0, total 28 kB/s

  • Yeah. I haven't spent any time on the issue yet. But there may only be enough Beagle cpu to support a single channel running ALE.

  • edited September 2021

    I have seen it on my AI so that may be a clue on CPU mips or not. Also, I suspect there are a couple issues in play.

  • Some of the stats, particularly the waterfall frames-per-second (FPS), take a long time to update. Like several 10s of seconds sampling periods. So if the waterfall stops updating the stats won't reflect that for a long time.

  • edited September 2021

    Using a BBAI Kiwi on a Win 8.1 machine and chromium browser. It can run 14 channels with the ALE2G extension however I noticed that using more than 8 ALE extensions the GPS processing starts suffering and becomes to a standstill beyond 10 (see attached figure), decodes still do occur though.

    The 8 channel (2 wf + 6 audio ) configuration seems to works fine with 2 cases of "not resuming after detection" in 24 hours running, unfortunately also without any further details. These occurred starting from a "scan" entry .

    (fig showing case with 10 ALE2G extensions running)

    Trying a chromium browser on a RP3B with Linux did support 4 instances, but the RP becomes sluggish and display updates become really slow.

    Just curious to know how the processing for this (and actually also other) extensions is divided between the Beagle and the client's computer browser.

  • One other thing I discovered today

    The SSB receive passband needs to be set correctly.

    Maybe the ALE extension should change the filter bandwidth to some default valued best suited for ALE.

    Regards,

    Martin

  • Someone has mentioned loosing the logged signals when the KiWi times out and goes to the splash screen.

    A similar thing has happend to me when using other extensions such as SSTV.

    Is there any way to allow the KiWi's last view persist in the browser when a time out occurs so that the data or images can be grabbed ?

    Regards,

    Martin

  • @benson and others: I have not focused on performance at all. As soon as I get though this other crisis I will do so. Last night I realized that gr_ale unnecessarily used double precision floating point. I switched to single precision and got better results with 2-channels running ALE. There are possibilities for ARM Neon vectorization due to e.g. a MAC loop in the sample rate conversion etc.

  • Action Report....

    My 8075 box is running a BBAI in 4 chan. mode.

    With 1 ALE instance running, it uses more CPU than 14 ch of wspr on a BBAI

    I have W10/Chrome browser logged to the 8075 box, the W10 boxes only task.

    It has been collecting ALE acitivity for 25+ hours non-stop. An actual call or AMD does make it look like it is stumbling but it keeps on

  • When scanning does the decode from pressing the test button stop the scan and then resume?

    Yes, it does in the situation of halting after a "scanning paused, signal detected event". The only other way I found is close then re-open the affected browser tab and reselect the extension.

    Possibly related is that the first line of the decodes showed

    >icmd1 caller0 ic0 NR10 [08:23:53] CMD a38=0 a64=0 ?(11) 0(30) ?(08) 0xc45808 6 11 30  8
    

    and all decodes thereafter showed a BER value of 26 until the point where the scanning paused. Pressing the test button all went back to normal.



  • jksjks
    edited September 2021
    v1.465 September 20, 2021
      ALE 2G extension
    
      Improvements:
      "Menus" setting renamed "Format".
      Format settings include sorting menu frequencies high-to-low in addition
        to menu collapse.
      Display settings improved. "DX" mode that produces fewer output lines
        per ALE transaction.
      An optimized 600-2650 Hz passband is used. Passband restored when
        ALE extension closed.
      Supports LSB mode in net/station database.
      URL parameters
        A multi-frequency, comma separated user scan list can be specified.
          See extension help.
        Net names can have embedded spaces.
      "Admin" menu renamed "Local" given that a user scan list from the URL
        will be added as the first menu item (i.e. menu is no longer
        solely admin entries).
      Many new URL parameters. See extension help.
    
      Bug fixes:
      Resumption of scanning is now delayed until any recording is finished.
      Various problems with next/prev buttons fixed.
    


  • Wow, many great improvements in V1.465 . Will need some time to check out and monitor before commenting further. Thanks for all the work building this extension.

  • Hi John,

    Thanks for adding the url string capability so quickly

    Absolutely brilliant :-)

    Regards,

    Martin

  • One small bug (possibly).

    I've found that if you have opened a session using a url string and that remains in the browser, it may not be easy to switch to another predefined scan. The url scan seems to override anything else.

    I have to halt the url scan with the stop button, then load up a single frequency from one of the pre-defined lists and then select the list scan.

    Regards,

    Martin

  • No, definitely a bug there. Don't know how I missed that.

    Thanks.

  • Okay, there is a hot fix for this problem (i.e. not a full release).

    Go to the admin page, update tab. Click "build now". To monitor the build progress go to the console tab and connect. Type m blog ("blog" = "build log").

  • Hi John,

    Yes that fixed it.

    Thanks again.

    Regards,

    Martin

  • jksjks
    edited September 2021

    Some good improvements coming, just need a bit longer to finish the work: Automatic periodic browser download of message log (so you don't lose the log when the Kiwi you're using does a timeout!) Major performance problem identified and fix in progress.

  • jksjks
    edited September 2021

    v1.467 September 27, 2021

    ALE 2G extension improvements:

    • Significant performance improvements. It's now possible to run the ALE extension on 4 channels (with reduced waterfall performance).
    • Date, time and frequency condensed in message log.
    • Periodic browser download of message log added. "record" checkbox becomes a menu containing audio and log recording settings. See extension help. Should help prevent losing log info on Kiwis that have connection timeouts. Note that ALE scanning resets any "inactivity" timeout but does not effect the per 24 hour connection limit (if present).
    • Added a "Log" button to download the message log on demand.
    • Display menu order changed: DX all +cmds +debug => DX +cmds all +debug. This allows commands in the data stream to be added to the abbreviated messages of DX mode. If present, messages (i.e. AMD, DTM) are now included in DX mode.
    • Some errors in the construction of greater than 3 character to/from calls were fixed.


Sign In or Register to comment.