cathalferris

The Ireland ISP is HEANet who had the interesting note of being the only Irish ISP that was not forced to filter the Piratebay when that court order came through, as it's an academic supplier and not a home supplier. One SSH port forward later from a machine I had access to on an academic network and I once again had unfettered net access via a proxy. That was very useful when I was abroad and using Irish websites that were geo-locked.

Agreed re: DNS as one of the easy ways to block/lose portions of the net. The other interesting way is BGP poisoning - and that's really interesting to see who trusts who!

A quick and dirty "fix" would be to run a regular cronjob to execute a script; the script checking to see if wlan0 is present, and if not present / valid then reconnect wlan0.

Create a file called check_start_wlan.sh in root's directory ("/root/check_start_wlan.sh")

#!/bin/bash
if ! `ifconfig | awk -F: '/^wlan0:/ && $0 != "" { getline; print $0}' | awk {'print $1'} | grep inet > /dev/null`
        then `connmanctl connect _managed_psk`
fi

Change the "your_wlan0_connection_string" for your particular wlan0 connmanctl connection string

then as root:
crontab -e
Add this line to the end of the crontab:
*/10 * * * * /bin/bash /root/check_start_wlan.sh

make sure to add an empty line after that line, then save/exit.

Verify the crontab looks sane
crontab -l

This should every 10 minutes via cron: check the output of ifconfig, look for the line starting with "wlan0", get the next line and check if there's a valid IP address present (checking if the "inet" phrase is present), if "inet" not present then ask connmanctl to connect that connection.

Note - only tested in my head, error conditions not trapped, running scripts as root creates a theoretical security risk etc etc etc.
Happy to take suggestions/improvement

I ended up using connmanctl to set the configuration of the interfaces, as I was trying to get wireless working on the Beaglebone Black. I now have the pair of Kiwis almost identical in setup.

Amusingly one of the Kiwis decided that the wireless card would work again, but would only talk to the network on the ethernet connection. This meant that the Kiwi thought the ethernet was not the LAN, and required the use of passwords for local admin access etc. Went in with connmanctl and disabled wifi, problem resolved.

Is anyone else on here using a DX Commander all-band vertical, as sold by Callum at https://www.m0mcx.co.uk/store/products/multi-band-80m-6m-hf-antenna-p-ale-compliant-antenna-survival-prep-sota-kit/ ? Just curious really as to if anyone here has one, and if one does, what are the general impressions?

I recently got one and put it together, and I've found it to be significantly better to receive than any of my other antennas. I've been able to pick up the Alpha locator beacons on a Kiwi in some of the testing, which I've been unable to do with any of the other wires in the air that I have at the moment. I've also carried out a/b testing with my HF+ Discovery and have found better SNR with the DXC on any frequencies I've tried.

My setup of the DXC has the 80m option, and I've got the 12m horizontal portion of the inverted-L strung across the lawn at 7-9m height to a Sotabeams TravelPole, and I've got about 180m of radial wires varying between 3m and 12m for my groundplane. (overkill, and diminishing returns, but it was cheap to add the extra..)

I've not yet got the proper setup to switch the input on TX, and to split the receive to a number of devices - but those are on the plan for the next month or so, when I order some stuff from SV1AFN to do that job

Openwebrx is the software that does the decoding of the radio signal input to show on screen or to pipe to other programs. The original author maintained a semi-public directory of stations that used the software, but he has since stopped working on that project due to PhD committments.

The KiwiSDR interface is based on an earlier fork of the openwebrx codebase, but hasn't followed the changes there in some time - mostly as a lot of the changes were not that relevant to the Kiwi setup and processing capabilities.

Note that there is a fork of the openwebrx code that is being currently maintained at https://github.com/jketterl/openwebrx and this fork is very likely to be considered as the main fork of the openwebsdr project as this is where the majority of the ongoing development is taking place.

The status of the openwebrx project is not really of any relevance to the KiwiSDR project, but if anyone is a competent coder and has the time to spare, then the retrofitting of the current-fork code updates from jketterl's tree and submitting to John's codebase at https://github.com/jks-prv/Beagle_SDR_GPS would be a really nice thing to do (but chat with John first just to make sure effort is not wasted).

As for how the Kiwi works, I'm not sure what level of detail you're looking for. Each Kiwi device is self-contained, but the owners can choose to add their device(s) to the http://rx.kiwisdr.com registry for public access. This registry was recently created to duplicate the functionality that the openwebsdr's creator had in place before his removal of that service.

Openwebrx is the software that does the decoding of the radio signal input to show on screen or to pipe to other programs. The original author maintained a semi-public directory of stations that used the software, but he has since stopped working on that project due to PhD committments.

The KiwiSDR interface is based on an earlier fork of the openwebrx codebase, but hasn't followed the changes there in some time - mostly as a lot of the changes were not that relevant to the Kiwi setup and processing capabilities.

Note that there is a fork of the openwebrx code that is being currently maintained at https://github.com/jketterl/openwebrx and this fork is very likely to be considered as the main fork of the openwebsdr project as this is where the majority of the ongoing development is taking place.

The status of the openwebrx project is not really of any relevance to the KiwiSDR project, but if anyone is a competent coder and has the time to spare, then the retrofitting of the current-fork code updates from jketterl's tree and submitting to John's codebase at https://github.com/jks-prv/Beagle_SDR_GPS would be a really nice thing to do (but chat with John first just to make sure effort is not wasted).

As for how the Kiwi works, I'm not sure what level of detail you're looking for. Each Kiwi device is self-contained, but the owners can choose to add their device(s) to the http://rx.kiwisdr.com registry for public access. This registry was recently created to duplicate the functionality that the openwebsdr's creator had in place before his removal of that service.

I've managed some online forums over the past decade, and found that forum spam is a right pain in the rear end to deal with. Once a forum gets recognised as somewhere that a spammer can post and the posts get read, the volume of incoming spam posts tends to rise fairly quickly.

As forum users, if you see an obviously spam post, don't click in to it. Some of the spammers put images inline to verify that the posts get read, and the spammer then knows they can afford to put more resources into that forum.

We'll just have to wait for an admin on the forum to remove the user that has put up the spam posts earlier today.

Safer for the rest of us to just ignore if we can.

I've come across some BBAI wifi instability over the past 36 hours.

My setup has the BBAI using connman to connect to a 5GHz router and statically assign an IPv4 IP address, and I've also got the BBAI connected via USB-C to an Intel NUC. I've had the BBAI become unavailable via wifi, and getting in over the USB networking shows me that the wlan0 interface no longer has an IP address associated.
Attempting to "connect " tells me that it's already connected, "disconnect " fails.

My current workaround is to restart the connman daemon, and that brings back up the interface and has the correct static IP assigned.

BBAI is up to date according to apt-get, temperatures are stable at 47 degrees or so, cpu @1GHz, normal cpu power profile, nothing mechanical changing (door to room closed to stop kitties interfering).

Over the weekend I'll run up a little watchdog script that will check for a lack of connectivity and restart the connman service as needed (similar to the pingfail service from here:). Currently I'm restarting the connman via cron and it's working.

@WA2ZKD My kiwis are aready being listed on your pages.
SWLIO52RP in Limerick, Ireland, MFA-30 cheapie amplified antenna as a 4m horizontal dipole literally on the lawn in the garden, gets ~15% of world's wspr transmissions, top 50 is positions.
SWLJN47FJ in Zurich, Switzerland. AAA-1c amplified antenna, two pairs of 1m pipe loops, in the attic of an apartment building (loads of noise), get ~11% of wspr transmissions, top 100 positions.

The Zurich one may have to go offline in a month, depending on the job market results.

Yes, I had noted this.
My current workaround is to tap shift+"s" once to set auto scale, then tap shift+"w" between 5 and 10 times quickly until satisfied with the appearance of the waterfall. I'm usually tending to go 10 steps so suit my aesthetic requirements.
When I'm using the sqrt=2 parameter in the URL I'm picking 8 steps.

I also think that people are forgetting to redo the auto scaling when changing zoom level, and that can have a less than desired effect on the view.
I wonder, would a solution to this be to mark the current scaling numbers relative to what the auto-scale values are for that view, and when changing zoom level that the same delta between auto and user be applied to a new autoscale in the new zoom level?

As an example, the user is in WF6, and the autoscale gives -49 and -101, but the user has chosen -55 and -93; that's a delta of -6 and +8.
Then the user zooms to WF9, and the autoscale for that view when the zoom has completed is -43 and -110; add the delta of -6 and +8 to give -49 and -102
That seems to work for the scenarios I've tried manually here at least.

John, to better answer your question:
My own experience is that the waterfall in SDRConsole has been the most aesthetically pleasing for me, and the "auto" button there does a pretty good job of getting the range generally right. Their choice of colour scheme really does help that though with the navy/blue/grey/white/yellow scheme is nice for contrast for radio signals. The refresh rate of SDRConsole waterfall has also really helped my visualisation of noise generators in the area, but that's a rabbit-hole for another time.
I've done a fair amount of personal work in visualisation of astronomical images and using false-colour for gaining more info from monochromatic images I've taken, and I've found that the most useful is something similar to the SDRConsole scheme, with nice contrast and colour only really used for the off-scale areas.

Hope that helps.
-Cathal.