The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz
ALE 2G extension issues
This discussion was created from comments split from: v1.462 release available.
It looks like you're new here. If you want to get involved, click one of these buttons!
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.
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
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...
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
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.
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.
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.
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
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.
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
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.
v1.467 September 27, 2021
ALE 2G extension improvements: