Does this command have a specified number of RSSI values it records: python kiwirecorder.py -k 30 -s host -p port -f 800 -m am --tlimit=10 I thought it was supposed to record 6 values per second, but that doesn't seem to be consistent.
Does --s-meter run for a set amount of time?
Is there any way to get more than one RSSI value from the --s-meter option?
Here's a snippet from a bash script I wrote to record to a csv file using the S-meter:
Antenna=`$KR -s $HOST -p $PORT -f $i m iq -L -5000 -H 5000 --s-meter 1` # discard, first reading is bogus !!!! Antenna=`$KR -s $HOST -p $PORT -f $i m iq -L -5000 -H 5000 --s-meter $AVERAGES`
Where: $KR=kiwirecorder.py $HOST is the IP address, e.g. n6gn.no-ip.org $PORT is the Port number, e.g. 8073 $i is frequency in kHz, e.g. 25000 for WWV25 L/H are upper IF frequencies, respectively, in this example measurement is made in a 10 kHz bandwidth $AVERAGES is the number of S-meter measurements to be included in the $Antenna, the returned value
You'll see that I take a single measurement (after frequency change, at least) and discard it because it has proved untrustworthy and I don't want to corrupt the measurement.
The S-meter seems to run at 'full speed' so one frequency point with 2 averages takes about 1 sec, 10 averages ~2 sec and 100 takes ~20 seconds. I'm not sure of your question in (3). To get more values with different receiver configurations, reissue with the desired changes. To get more averages make $AVERAGES larger.
Just made a commit to my kiwiclient repo. --s-meter=0 now streams S-meter/RSSI values instead of averaging them for N periods (i.e. --s-meter=N) Use the --tlimit option to set an (optional) bound on how long streaming occurs.
That first bogus value is now suppressed. It is an artifact of the glitch that gives you a split second of audio from the last frequency the channel was tuned to when you first connect (a separate bug that needs to be fixed).
New option --stats reports the number of RSSI readings per second. The number is a bit rough and gets more accurate over longer sampling periods.
The question of how often an RSSI value is sent from the Kiwi is a bit complicated. The RSSI is included in the header of every audio packet sent on the network. The packet frequency varies with audio sample rate (12k or 20.25k), real or IQ mode and compression. With a 4 or 8-channel Kiwi (12 kHz sample rate), a non-IQ mode and 4:1 compression (the default) it works out to about 5.8 RSSI values/sec (12000*1*2/4/1024: srate, nchan, bytes/samp, comp, bytes/pkt). With no compression it's 4x that (12000*1*2/1/1024) and with IQ mode it's also 4x (12000*2*2/1/2048) because the packet size is doubled which balances the doubled number of channels. There is never compression in IQ mode. For 3-channel mode (20.25 kHz srate) scale up by 20.25/12 (~1.7).
Look at the Makefile targets sm, smt, sms and smst for example uses.
John, Thanks for the additions. Much appreciated. "That first bogus value is now suppressed. It is an artifact of the glitch that gives you a split second of audio from the last frequency the channel was tuned to when you first connect (a separate bug that needs to be fixed)." But maybe " it's not a bug it's a feature ". That artifact can be very useful as a means for identifying the wired LAN as a source/mechanism for noise coupling into a kiwi. It turns out that if one pulls the cable with a suitable waterfall running and then restarts somewhat later, a short viewing period of LAN-less operation is possible! One can see what the world would look like without QRN from LAN traffic. This can be tremendously useful as an indication of where to look and the potential benefit of removing CM current on the LAN cable (perhaps by going to a USB/WiFi dongle). I'll gladly sacrifice the extra/first S-meter measurement to keep this bug/feature. Glenn n6gn
I have not studied in detail what happens when you pull and re-attach the Ethernet cable over certain intervals of time. It is possible that some changes to the Kiwi's little internal web server could be made so it is more tolerant to network interface errors, e.g. get it to use a large amount of buffering when interface disconnection is detected such that the SDR can continue to capture data without dropping anything.
This probably needs to be a configurable option however. You wouldn't want false positives causing the existing elastic buffering mechanism to get overpowered and cause arbitrary delays. People complain about that enough already.
Agreed that it might cause issues and requiring it to be enabled, even with no more buffering than it presently has, would probably be good. But I do find it valuable and have on several occasions quickly disconnected/reconnected the LAN cable to identify LAN-induced interference via direct waterfall comparison. It's fairly slick.
I am confused about the S-Meter option and how it works.
"--S_meter=S_METER", where S_METER is the number of S-meter averages you want (e.g. 1, 10 etc.) After the averaging it prints a single line with the RSSI value in dBm."
does this mean that if I set --S-meter to 10, that the recording would be split into 10 sections, and each of those sections averaged and outputted?
When I run it with --S-meter there only ever seems to be 1 output, which doesn't make sense to me.
Even if I run it like this: python kiwirecorder.py -s www -f 1440 -m iq -L -5000 -H 5000 --s-meter 10 >> output.txt
S_METER is the number of single S-meter readings the program obtains from the Kiwi. They are then averaged and a single value printed. An S_METER value of zero gives a "streaming" mode where each S-meter reading obtained is printed individually with no averaging.
Maybe we need an option that allows streaming but with a certain amount of averaging to reduce the measurement noise.
You can use the time limit option to stop the measurement after some number of seconds.
Okay, if you update to the latest kiwiclient / kiwirecorder then when in S-meter mode:
"--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.
"--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.
Sample output. See the Makefile for command line examples.
python kiwirecorder.py -s kiwi -p 8074 --s-meter=0 --ts --dt-sec=2 --tlimit=10 --stats
26-Oct-2019 19:24:32 UTC RSSI: -111.2 3.0 meas/sec
26-Oct-2019 19:24:34 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:36 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:38 UTC RSSI: -111.2 5.0 meas/sec
26-Oct-2019 19:24:40 UTC RSSI: -110.9 6.0 meas/sec
5.9 meas/sec
Okay, the "--sound" (also "--snd") option now applies to S-meter mode, meaning you can record and obtain S-meter readings at the same time. Please update from my repo.
Note that "--dt-sec" now only applies to recording files. A new non-conflicting option called "--sdt-sec" determines the S-meter measurement interval. So in the example below averaged S-meter readings are being taken every second while a new file is being recorded every 4 seconds:
>>> make smsi
python kiwirecorder.py -s www -p 8073 -f 1440 -L -5000 -H 5000 --s-meter=0 --tstamp --sdt-sec=1 --stats --log-level=info --dt-sec=4 --snd
2019-10-31 10:08:09,303 pid 61925 started sound recorder 0
2019-10-31 10:08:10,052 pid 61925 Server version: 1.337
2019-10-31 10:08:10,071 pid 61925 GNSS position: lat,lon=[-37.63, +176.17]
2019-10-31 10:08:10,729 pid 61925 Started a new file: 20191030T210810Z_1440000_am.wav
30-Oct-2019 21:08:11 UTC RSSI: -95.0 2.0 meas/sec
30-Oct-2019 21:08:12 UTC RSSI: -95.8 6.0 meas/sec
2019-10-31 10:08:12,110 pid 61925 Started a new file: 20191030T210812Z_1440000_am.wav
30-Oct-2019 21:08:13 UTC RSSI: -95.3 6.0 meas/sec
30-Oct-2019 21:08:14 UTC RSSI: -95.6 6.0 meas/sec
30-Oct-2019 21:08:15 UTC RSSI: -95.3 5.0 meas/sec
30-Oct-2019 21:08:16 UTC RSSI: -94.9 6.0 meas/sec
2019-10-31 10:08:16,171 pid 61925 Started a new file: 20191030T210816Z_1440000_am.wav
30-Oct-2019 21:08:17 UTC RSSI: -95.2 6.0 meas/sec
30-Oct-2019 21:08:18 UTC RSSI: -95.6 6.0 meas/sec
30-Oct-2019 21:08:19 UTC RSSI: -95.5 6.0 meas/sec
30-Oct-2019 21:08:20 UTC RSSI: -95.1 6.0 meas/sec
2019-10-31 10:08:20,124 pid 61925 Started a new file: 20191030T210820Z_1440000_am.wav
30-Oct-2019 21:08:21 UTC RSSI: -95.4 6.0 meas/sec
30-Oct-2019 21:08:22 UTC RSSI: -94.8 5.0 meas/sec
^C30-Oct-2019 21:08:23 UTC RSSI: -95.1 6.0 meas/sec
KeyboardInterrupt: threads successfully closed
Comments
python kiwirecorder.py -k 30 -s host -p port -f 800 -m am --tlimit=10I thought it was supposed to record 6 values per second, but that doesn't seem to be consistent.
Antenna=`$KR -s $HOST -p $PORT -f $i m iq -L -5000 -H 5000 --s-meter 1` # discard, first reading is bogus !!!!
Antenna=`$KR -s $HOST -p $PORT -f $i m iq -L -5000 -H 5000 --s-meter $AVERAGES`
Where:
$KR=kiwirecorder.py
$HOST is the IP address, e.g. n6gn.no-ip.org
$PORT is the Port number, e.g. 8073
$i is frequency in kHz, e.g. 25000 for WWV25
L/H are upper IF frequencies, respectively, in this example measurement is made in a 10 kHz bandwidth
$AVERAGES is the number of S-meter measurements to be included in the $Antenna, the returned value
You'll see that I take a single measurement (after frequency change, at least) and discard it because it has proved untrustworthy and I don't want to corrupt the measurement.
The S-meter seems to run at 'full speed' so one frequency point with 2 averages takes about 1 sec, 10 averages ~2 sec and 100 takes ~20 seconds.
I'm not sure of your question in (3). To get more values with different receiver configurations, reissue with the desired changes. To get more averages make $AVERAGES larger.
Glenn n6gn
Use the --tlimit option to set an (optional) bound on how long streaming occurs.
That first bogus value is now suppressed. It is an artifact of the glitch that gives you a split second of audio from the last frequency the channel was tuned to when you first connect (a separate bug that needs to be fixed).
New option --stats reports the number of RSSI readings per second. The number is a bit rough and gets more accurate over longer sampling periods.
The question of how often an RSSI value is sent from the Kiwi is a bit complicated. The RSSI is included in the header of every audio packet sent on the network. The packet frequency varies with audio sample rate (12k or 20.25k), real or IQ mode and compression. With a 4 or 8-channel Kiwi (12 kHz sample rate), a non-IQ mode and 4:1 compression (the default) it works out to about 5.8 RSSI values/sec (12000*1*2/4/1024: srate, nchan, bytes/samp, comp, bytes/pkt). With no compression it's 4x that (12000*1*2/1/1024) and with IQ mode it's also 4x (12000*2*2/1/2048) because the packet size is doubled which balances the doubled number of channels. There is never compression in IQ mode. For 3-channel mode (20.25 kHz srate) scale up by 20.25/12 (~1.7).
Look at the Makefile targets sm, smt, sms and smst for example uses.
Thanks for the additions. Much appreciated.
"That first bogus value is now suppressed. It is an artifact of the glitch that gives you a split second of audio from the last frequency the channel was tuned to when you first connect (a separate bug that needs to be fixed)."
But maybe " it's not a bug it's a feature ".
That artifact can be very useful as a means for identifying the wired LAN as a source/mechanism for noise coupling into a kiwi. It turns out that if one pulls the cable with a suitable waterfall running and then restarts somewhat later, a short viewing period of LAN-less operation is possible! One can see what the world would look like without QRN from LAN traffic. This can be tremendously useful as an indication of where to look and the potential benefit of removing CM current on the LAN cable (perhaps by going to a USB/WiFi dongle).
I'll gladly sacrifice the extra/first S-meter measurement to keep this bug/feature.
Glenn n6gn
This probably needs to be a configurable option however. You wouldn't want false positives causing the existing elastic buffering mechanism to get overpowered and cause arbitrary delays. People complain about that enough already.
But I do find it valuable and have on several occasions quickly disconnected/reconnected the LAN cable to identify LAN-induced interference via direct waterfall comparison. It's fairly slick.
I am confused about the S-Meter option and how it works.
"--S_meter=S_METER", where S_METER is the number of S-meter averages you want (e.g. 1, 10 etc.) After the averaging it prints a single line with the RSSI value in dBm."
does this mean that if I set --S-meter to 10, that the recording would be split into 10 sections, and each of those sections averaged and outputted?
When I run it with --S-meter there only ever seems to be 1 output, which doesn't make sense to me.
Even if I run it like this:
python kiwirecorder.py -s www -f 1440 -m iq -L -5000 -H 5000 --s-meter 10 >> output.txt
The output.txt only has value in it.
An S_METER value of zero gives a "streaming" mode where each S-meter reading obtained is printed individually with no averaging.
Maybe we need an option that allows streaming but with a certain amount of averaging to reduce the measurement noise.
You can use the time limit option to stop the measurement after some number of seconds.
Just in case you're going to look at adding averaging to the streaming data, could you also see if timestamps can be added to those S-meter readings.
Best regards, Ben.
"--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.
"--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.
Sample output. See the Makefile for command line examples.
Thanks,Ben
Thanks for the quick work on the s-meter functions.
Would it be possible to add an option to also allow for Audio recording even while using the s-meter option?
I would like to have the option to do Audio only, RSSI only, or both.
Thanks.
Note that "--dt-sec" now only applies to recording files. A new non-conflicting option called "--sdt-sec" determines the S-meter measurement interval. So in the example below averaged S-meter readings are being taken every second while a new file is being recorded every 4 seconds: