Initial System Testing?

SatNOGS Software
1

Newbie here…

I believe I have everything setup and registered correctly for ground station 103. However, my initial scheduled test yielded no data being sent. I’m in the dev site.

Are there lower level tests that can be performed on the RPI to establish that in fact the RTL SDR and Rotor controller are actually working correctly?

Why doesn’t the “Schedule” button work for me on the Upcoming passes page for my ground station?

I’ll note my configs look fine in: /etc/supervisord.d

I do see a socket error in the satnogs-error.log…

2017-06-06 00:25:09,382 - satnogsclient - INFO - Starting status listener thread…
2017-06-06 00:25:09,386 - satnogsclient - INFO - Dir /tmp/.satnogs/data/files/
2017-06-06 00:25:09,389 - satnogsclient - INFO - Check dir /tmp/.satnogs/data/files/SU_LOG
2017-06-06 00:25:09,390 - satnogsclient - INFO - Check dir /tmp/.satnogs/data/files/WOD_LOG
2017-06-06 00:25:09,392 - satnogsclient - INFO - Check dir /tmp/.satnogs/data/files/EXT_WOD_LOG
2017-06-06 00:25:09,404 - satnogsclient - INFO - Press Ctrl+C to exit SatNOGS poller
WebSocket transport not available. Install eventlet or gevent and gevent-websocket for improved performance.
Traceback (most recent call last):
File “/usr/bin/satnogs-client”, line 9, in
load_entry_point(‘satnogsclient==0.3’, ‘console_scripts’, ‘satnogs-client’)()
File “/usr/lib/python2.7/site-packages/satnogsclient/main.py”, line 22, in main
socketio.run(app, host=‘0.0.0.0’)
File “/usr/lib/python2.7/site-packages/flask_socketio/init.py”, line 469, in run
use_reloader=use_reloader, **kwargs)
File “/usr/lib/python2.7/site-packages/flask/app.py”, line 841, in run
run_simple(host, port, self, **options)
File “/usr/lib/python2.7/site-packages/werkzeug/serving.py”, line 736, in run_simple
inner()
File “/usr/lib/python2.7/site-packages/werkzeug/serving.py”, line 696, in inner
fd=fd)
File “/usr/lib/python2.7/site-packages/werkzeug/serving.py”, line 584, in make_server
passthrough_errors, ssl_context, fd=fd)
File “/usr/lib/python2.7/site-packages/werkzeug/serving.py”, line 501, in init
HTTPServer.init(self, (host, int(port)), handler)
File “/usr/lib/python2.7/SocketServer.py”, line 417, in init
self.server_bind()
File “/usr/lib/python2.7/BaseHTTPServer.py”, line 108, in server_bind
SocketServer.TCPServer.server_bind(self)
File “/usr/lib/python2.7/SocketServer.py”, line 431, in server_bind
self.socket.bind(self.server_address)
File “/usr/lib/python2.7/socket.py”, line 228, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 98] Address already in use
[root@satnogs supervisor]#

2

A little more info… I used rotor id 602 and scheduled a pass. This time the rotor controller was definitely doing something, but it seems to update the rotor every degree of change. Is it possible to buffer that to 2 degrees of change needed before a command is sent to move the antenna? That’s how satpc32 does it and it always worked well. As it is, my rotor controller is going nuts (lots of relay action) with every degree of change.

3

I had similar problems with my Rotor Controller. I found in HamLib rotctl a command line option that forces up to a .999ms delay between commands sent. I added this to the rotctld command line: -C post_write_delay=950

The full command line is:
rotctl -m 603 -r /dev/ttyUSB0 -C timeout=500 -C min_az=0 -C max_az=359 -C min_el=0 -C max_el=180 -C post_write_delay=950

The SatNOGS client sends out move commands rapid fire, which was overrunning the serial buffer on my controller. I did mention to the developers that it would be a good idea to slow down the move commands and offer an option for degrees of change before next move command. 1 degree is a little silly for the type of antennas found at most ground stations.

The rest of the issues I can’t help with. The SatNOGS guys had to help me get my site to work.
I will be adding a pre-amp at the antenna this weekend to help with signal level then I think I will be ready to go live.

4

Yeah we’re going to move to a threshold based model for moving the rotator. Needs a bit more code to probe the rotator for its current location before firing off a command to move.

You can follow along here: https://github.com/satnogs/satnogs-client/issues/269

5

If the pass is within 15 minutes of “now” the schedule button is disabled, scroll down past 15 mins to find some enabled. There is a bit of lag time in getting a scheduled job to the ground station though it typically 1-2 minutes.

6

thanks, but where are you (N7IPY) setting up the command modification? Is that in a particular file?

I’m trying this, but after service reload and restart, now nuttin works.
Here’s what I’m trying…

[program:rotctld]
command=/usr/bin/rotctld -m 602 -r /dev/ttyUSB0 -s 9600 -C post_write_delay=950

7

I make the edit in /etc/supervisord.d/rotctld.ini

To test the operation, I use supervisorctl to stop rotctld and then I run the interactive command line ‘rotctl’ with the same configuration string. Then I use the command ‘p’ to issue a get status command where you should get an Azimuth and Elevation response that matches what the rotor system sent. Then I use a “Paaa eee” command to issue a move command to the rotor.

Once I have proven that the configuration is working, I exit rotctl and use supervisorctl to restart rotctld. I ended up using the rotor model 603 to get things working properly on my hardware.

8

That will be a great improvement for the ‘other’ Az/El Rotor Systems. Or to at least increase the degree per movement to anything other that 1 degree steps and only issue the move command when there is a change in position. The rapid fire commands with the same location data caused me all kind of grief to work around.
My ground station seems to be behaving it’s self now and the new pre-amp goes online this weekend.

1 Like
9

Can you provide a full example of your rotor config file? There’s a format error on my part that I believe is causing things to not work for me.

10

How do you test that the rtl sdr dongle is working locally? One of the passes I scheduled, yielded a picture that looks like it isn’t working at all.

11

Hey,

You can run manually in rpi the gnuradio script that uses rtl-sdr with this command:

satnogs_fm_demod.py --rx-sdr-device=rtlsdr --rx-freq=444000000 --file-path=./audio-out.ogg --waterfall-file-path=./waterfall.dat

This will start getting data from rtlsdr on 444MHz frequency and will write an audio file and a dat file with data for the waterfall in the current directory. The script stops with ctrl+c.

For generating the waterfall image from the dat file you should run:

gnuplot -e "inputfile='./waterfall.dat'" -e "outfile='waterfall.png'" -e "height=1600" /usr/local/share/satnogs_waterfall.gp

12

thanks for the suggestion. It seems to confirm that something is wrong with the usb dongle being recognized? I plugged it into my windows pc and it seems to work just fine, so the dongle doesn’t appear to be the issue. How do you resolve a “Wrong rtlsdr device index” error?

[root@satnogs gr-satnogs]# satnogs_fm_demod.py --rx-sdr-device=rtlsdr --rx-freq=444000000 --file-path=./audio-out.ogg --waterfall-file-path=./waterfall.dat
linux; GNU C++ version 6.2.1 20160916 (Red Hat 6.2.1-2); Boost_106000; UHD_003.010.001.000-0-unknown

gr-osmosdr v0.1.x (0.1.4git) gnuradio 3.7.10.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf rfspace

FATAL: Wrong rtlsdr device index given.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

13

Can you run rtl_test and post the result here?

14

[root@satnogs gr-satnogs]# rtl_test
No supported devices found.

15

So it is not even finding it. Can you try unplugging it and then plugging it in again and post final lines from dmesg ?

16

[ 82.344205] usb 1-1.4: new low-speed USB device number 5 using dwc2
[ 82.558828] usb 1-1.4: New USB device found, idVendor=0c40, idProduct=8000
[ 82.561324] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 82.564948] usb 1-1.4: Product: iPazzPort
[ 82.566196] usb 1-1.4: Manufacturer: ELMCU
[ 83.469701] input: ELMCU iPazzPort as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/0003:0C40:8000.0001/input/input0
[ 84.027830] hid-generic 0003:0C40:8000.0001: input,hidraw0: USB HID v1.11 Keyboard [ELMCU iPazzPort] on usb-3f980000.usb-1.4/input0
[ 84.866824] input: ELMCU iPazzPort as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.1/0003:0C40:8000.0002/input/input1
[ 85.125207] hid-generic 0003:0C40:8000.0002: input,hidraw1: USB HID v1.11 Mouse [ELMCU iPazzPort] on usb-3f980000.usb-1.4/input1
[ 188.537758] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
[ 190.206090] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[ 190.217932] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
[ 4587.573534] i2c-bcm2835 3f205000.i2c: Got unexpected interrupt (from firmware?)
[ 7539.561635] usb 1-1.3: new high-speed USB device number 6 using dwc2
[ 7540.055640] usb 1-1.3: device not accepting address 6, error -71

17

Is this a Fedora 25 setup?

18

yes. The original SD card provided with the satnogs kit this summer.

19

interesting… i unplugged the other two usb devices (amsat rotor controller and keyboard transciever) and now it registers, but the test script still says no devices.

[ 7539.561635] usb 1-1.3: new high-speed USB device number 6 using dwc2
[ 7540.055640] usb 1-1.3: device not accepting address 6, error -71
[ 7869.362207] usb 1-1.4: USB disconnect, device number 5
[ 7871.670462] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 7871.675373] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 7871.922182] usb 1-1.2: USB disconnect, device number 4
[ 7871.927959] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 7871.941343] ftdi_sio 1-1.2:1.0: device disconnected
[ 7872.617629] usb 1-1.3: new high-speed USB device number 8 using dwc2
[ 7872.725899] usb 1-1.3: New USB device found, idVendor=0bda, idProduct=2838
[ 7872.731142] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7872.736310] usb 1-1.3: Product: RTL2838UHIDIR
[ 7872.741361] usb 1-1.3: Manufacturer: Realtek
[ 7872.746329] usb 1-1.3: SerialNumber: 00000001
[ 7872.902096] usb 1-1.3: dvb_usb_v2: found a ‘Realtek RTL2832U reference design’ in warm state
[ 7872.968770] usb 1-1.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 7872.979491] dvbdev: DVB: registering new adapter (Realtek RTL2832U reference design)
[ 7873.063141] i2c i2c-3: Added multiplexed i2c bus 4
[ 7873.069289] rtl2832 3-0010: Realtek RTL2832 successfully attached
[ 7873.075079] usb 1-1.3: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))…
[ 7873.129174] r820t 4-001a: creating new instance
[ 7873.142232] r820t 4-001a: Rafael Micro r820t successfully identified
[ 7873.162623] Registered IR keymap rc-empty
[ 7873.169085] input: Realtek RTL2832U reference design as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/rc/rc0/input2
[ 7873.181896] rc rc0: Realtek RTL2832U reference design as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/rc/rc0
[ 7873.195211] usb 1-1.3: dvb_usb_v2: schedule remote query interval to 200 msecs
[ 7873.210475] usb 1-1.3: dvb_usb_v2: ‘Realtek RTL2832U reference design’ successfully initialized and connected
[ 7873.218371] lirc_dev: IR Remote Control driver registered, major 242
[ 7873.230321] usbcore: registered new interface driver dvb_usb_rtl28xxu
[ 7873.245121] rc rc0: lirc_dev: driver ir-lirc-codec (dvb_usb_rtl28xxu) registered at minor = 0
[ 7873.258080] IR LIRC bridge handler initialized
[ 7874.994184] usb 1-1.3: USB disconnect, device number 8
[ 7875.020419] r820t 4-001a: destroying instance
[ 7875.028416] dvb_usb_v2: ‘Realtek RTL2832U reference design:1-1.3’ successfully deinitialized and disconnected

20

That seems like an abrupt disconnect. Maybe connector issue? Or power supply issue?