rrobinet
I have configured several Kiwis for wifi access by attaching an inexpensive router configured as a Wifi client to the ethernet port of the Kiwi. This $25 TP Link has worked well for me:
https://smile.amazon.com/TP-Link-Wireless-Portable-Travel-Router/dp/B00TQEX8BO/ref=sr_1_14?keywords=tplink+wifi+router&qid=1548188019&sr=8-14
In principle one could enable the internal BB Wifi or attach a USB wifi adapter, but I am reluctant to fiddle with the Kiwi's OS.
About
- Username
- rrobinet
- Joined
- Visits
- 1,300
- Last Active
- Roles
- Member
- Points
- 9
-
wsprdaemon - A Raspberry Pi WSPR decoding service
I have just checked in V2.6b to https://github.com/rrobinett/wsprdaemon where you will find installation and upgrade instructions.
Among other improvements, this version addresses an upload problem which may be causing WD users to pound the wsprnet.org database.
So I strongly encourage existing user to upgrade to V2.6b -
wsprdaemon - A Raspberry Pi WSPR decoding service
I have been watching the WD upload log and see many, many timeouts on upload attempts to wsprnet.org.
WD caches it spots until a successful upload so when wsprnet.org goes offline for 10 minutes or more WD can be caching 100 or more spots.
wsprnet.org seems to reject uploads of 100+ spots (I'm not sure what is that limit, so that is a guess). At that point WD gets into a continuous upload failure loop while its cache of spots grows larger and large.
I am going to add a limit of upload size to WD 2.6b to try to address this problem.
But the larger problem is the frailty of wsprnet.org.
I maintain a research grade database of noise data at wsprdeamon.org and I am thinking I will add a spots database as well.
WD users will be able to make real queries of their spot data and create graphs from queries. -
wsprdaemon - A Raspberry Pi WSPR decoding service
I have been watching the WD upload log and see many, many timeouts on upload attempts to wsprnet.org.
WD caches it spots until a successful upload so when wsprnet.org goes offline for 10 minutes or more WD can be caching 100 or more spots.
wsprnet.org seems to reject uploads of 100+ spots (I'm not sure what is that limit, so that is a guess). At that point WD gets into a continuous upload failure loop while its cache of spots grows larger and large.
I am going to add a limit of upload size to WD 2.6b to try to address this problem.
But the larger problem is the frailty of wsprnet.org.
I maintain a research grade database of noise data at wsprdeamon.org and I am thinking I will add a spots database as well.
WD users will be able to make real queries of their spot data and create graphs from queries. -
wsprdaemon - A Raspberry Pi WSPR decoding service
Hi Clint,
wsprnet.org is the source of ZKD and AMG lists, so if your spots were in wsprnet.org but not ZKD/AMG, then the problem was not in WD.
There is a seperate flow of data and files to create the WD logs and graphs, so uploads could fail while graphs appear.
So I have no explanation for your extended disappearance. There are some WD log files which could potentially grow to fill the /tmp/wspr-captures file system, but without access to your PC while in a failure state I can't really diagnose the cause.
Your GPS was diagnosed and fixed by JKS v1.335. In a busy 8 channel mode the Kiwi was not searching for new satellites. I encounters your GPS problem at KPH during WD v2.6 development and can certify that the problem has been fixed.
I have posted a late apha version of WD2.6 in github: https://github.com/rrobinett/wsprdaemon/tree/rrobinett-v26
Logging of overload events is one new feature you might find useful. -
wsprdaemon - A Raspberry Pi WSPR decoding service
Hi Clint,
wsprnet.org is the source of ZKD and AMG lists, so if your spots were in wsprnet.org but not ZKD/AMG, then the problem was not in WD.
There is a seperate flow of data and files to create the WD logs and graphs, so uploads could fail while graphs appear.
So I have no explanation for your extended disappearance. There are some WD log files which could potentially grow to fill the /tmp/wspr-captures file system, but without access to your PC while in a failure state I can't really diagnose the cause.
Your GPS was diagnosed and fixed by JKS v1.335. In a busy 8 channel mode the Kiwi was not searching for new satellites. I encounters your GPS problem at KPH during WD v2.6 development and can certify that the problem has been fixed.
I have posted a late apha version of WD2.6 in github: https://github.com/rrobinett/wsprdaemon/tree/rrobinett-v26
Logging of overload events is one new feature you might find useful.