Your Kiwi must be running the v1.690 (or later) release to use the proxy service and be in the public Kiwi list (rx.kiwisdr.com, map.kiwisdr.com)

Please visit kiwisdr.com (documentation) and kiwisdr.nz (online store)

kiwirecorder crash when no GPS lock on Kiwi

I don't know this is a high priority bug to fix, but we spent several hours today debugging a crash of kiwirecorder which we finally traced to the Kiwi not having a GPS signal.
So I thought I would post this warning in the hope I might save other kiwirecorder users some debug time.

Comments

  • I can run the current version of kiwirecorder in IQ mode with the "--kiwi-wav" flag (include GPS timestamps in the .wav file) and it works fine. Even using a Kiwi where GPS is enabled but there are no solutions because there is no GPS antenna connected.
  • edited March 2019
    The crash occurred at Glenn's where he added a third Kiwi with no GPS signal. I had no remote access to his system or to a Kiwi where I can disconnect the GPS signal, so I can't give you a copy of the Python stack trace. Perhaps Glenn can do that for us. We are recording wav files by executing:

    python -u /home/pi/wsprdaemon/kiwiclient-jks-v0.1/kiwirecorder.py --freq=28124.6 --server-host=10.14.70.78 --server-port=8073 --user=wsprdaemon_v2.2h --password=none --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1250 --hp-cutoff=1750 --dt-sec=120

    I execute "git clone git://github.com/jks-prv/kiwiclient" to load your recorder. Is that getting the latest version?
  • Did this crash occur more than once? Was it repeatable? Did it stop crashing when the only change was to enable GPS? If not, how did you conclusively decide it was related to GPS? Given that you were not using --kiwi-wav and/or IQ mode it is extremely unlikely this has anything to do with GPS.

    I execute "git clone git://github.com/jks-prv/kiwiclient" to load your recorder. Is that getting the latest version?
    Yes.
  • John,
    Yes, it occurred every time of the many it was tried it which is what prompted the investigation into why the 3rd kiwi didn't work. The only thing that was necessary to change from the non-working condition, which issued a 'string to float" conversion error, was the addition of a GPS signal on the failing kiwi. Up to the point where we discovered the problem we had been at a loss to determine what the difference was with the third receiver that kept it from working. We hadn't even considered that the presence/absence of gps would be relevant. The error seemed to be associated with the GPS and establishing gridsquare or something related.
    If it is necessary, I may be able to recreate the condition and provide the output. I may need Rob's assistance to do that though.
  • I just reconnected the same kiwi where this was witnessed, with the GPS disconnected. As I'd had it powered off, it promptly loaded v1.277 before I could even re-try the kiwirecorder call. When it finished, I re-ran the command-line call to kiwirecorder which failed when Rob and I were watching, one that was from his script but with "-v" added and --user modified:

    python -v -u /home/ge/wsprdaemon/kiwiclient/kiwirecorder.py --freq=7038.6 --server-host=10.0.0.25 --server-port=8076 --user=UStest --password=kiwis_password --agc-gain=60 --quiet --no_compression --modulation=usb --lp-cutoff=1250 --hp-cutoff=1750 --dt-sec=120

    Not only did it run flawlessly this time but when I looked I discovered that Rob's script, which also happened to be running with this kiwi still in the schedule *also* had successful WSPR sessions running on it. All with no GPS. The only difference was time and the fact that it had rebuilt to v1.277 .

    Though repeated multiple times previously, the problem no longer seems to be reproducible.
Sign In or Register to comment.