I’ve lost my gps-signal for the RTKBase.
I have no green bars. Everything worked perfect for about 2 months ago.
I backedup my sim, and later borrowed the powersupply for another project.
Now when I power it up again the signal is gone.
Power source is an IPad charger so it should be enough power.
Detect and configure seems to work perfect.
How can I troubleshoot this?
I also updated RTKBase today, but that didn’t help.
Try going
sudo systemctl status str2str_tcp
In a terminal.
It should say something like this:
● str2str_tcp.service - RTKBase Tcp
Loaded: loaded (/etc/systemd/system/str2str_tcp.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-12-29 19:47:50 UTC; 4 days ago
Main PID: 1182 (str2str)
Tasks: 2 (limit: 2308)
The important thing is that it says active(running)
Sometimes the GUI doesn’t show satellite signals but everything else still works properly. I don’t know if there have been new version releases since that bug was noticed.
I’ll give it a go
I got banned from RTK2GO so i don’t think that’s the issue her.
sudo systemctl status str2str_tcp
displays the same as the Diagnosis under settings:
str2str_tcp.service - RTKBase Tcp
Loaded: loaded (/etc/systemd/system/str2str_tcp.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2024-01-03 15:58:22 CET; 7h ago
Process: 2764 ExecStart=/home/basegnss/rtkbase/run_cast.sh in_serial out_tcp (code=exited, status=0/SUCCESS)
Main PID: 2771 (str2str)
Tasks: 2 (limit: 1596)
CPU: 2min 12.529s
CGroup: /system.slice/str2str_tcp.service
└─2771 /usr/local/bin/str2str -in serial://ttyACM0:115200:8:n:1#ubx -out tcpsvr://:5015 -b 1 -t 0 -fl /home/basegnss/rtkbase/l>
● str2str_ntrip_A.service - RTKBase Ntrip A
Loaded: loaded (/etc/systemd/system/str2str_ntrip_A.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2023-12-29 20:03:34 UTC; 5 days ago
Main PID: 3861 (str2str)
Tasks: 2 (limit: 2308)
Memory: 2.9M
CPU: 34min 59.256s
CGroup: /system.slice/str2str_ntrip_A.service
└─3861 /usr/local/bin/str2str -in tcpcli://localhost:5015#ubx -out ntrips://:ssGhNxET@rtk2go.com:2101/OverlandRTK#rtcm3 -msg "1004,1005(10),1006,1008(10),1012,1019,1020,1033(10),1042,1045,1046,1077,1087,1097,1107,1127,1230" -p 38.45103520 -97.49914354 446.863 -opt -TADJ=1 -i "RTKBase U-blox_ZED-F9P,2.4.2 1.32" -a ADVNULLANTENNA -t 0 -fl /home/myuser/rtkbase/logs/str2str_ntrip_A.log```
So I’m curious now what you’d find under the NTrip_A(or whichever service you’re sending to rtk2go on) says.
Particularly the message string under CGroup
And you for sure did try re-configuring the reciever? I had mine off for a few weeks, and I had to reconfigure it after I powered it back on.
I use the Ntrip A service.
Enabling it, gives this output.
janv. 04 07:54:41 basegnss systemd-journald[151]: Suppressed 9 messages from str2str_tcp.service
janv. 04 07:54:46 basegnss run_cast.sh[2771]: 2024/01/04 06:55:04 [CW---] 10899012 B 1246 bps (0) /dev/ttyACM0 (1) waiting...
janv. 04 07:54:51 basegnss run_cast.sh[2771]: 2024/01/04 06:55:09 [CW---] 10899792 B 1244 bps (0) /dev/ttyACM0 (1) waiting...
janv. 04 07:55:41 basegnss run_cast.sh[2771]: 2024/01/04 06:55:59 [CW---] 10909080 B 1691 bps (0) /dev/ttyACM0 (1) waiting...
janv. 04 07:55:41 basegnss systemd-journald[151]: Suppressed 9 messages from str2str_tcp.service
janv. 04 07:55:46 basegnss run_cast.sh[2771]: 2024/01/04 06:56:04 [CW---] 10910068 B 1564 bps (0) /dev/ttyACM0 (1) waiting...
janv. 04 07:55:51 basegnss run_cast.sh[2771]: 2024/01/04 06:56:09 [CW---] 10910928 B 1370 bps (0) /dev/ttyACM0 (1) waiting...
janv. 04 07:56:41 basegnss run_cast.sh[2771]: 2024/01/04 06:56:59 [CC---] 10919084 B 1373 bps (0) /dev/ttyACM0 (1) 2 clients
janv. 04 07:56:41 basegnss systemd-journald[151]: Suppressed 9 messages from str2str_tcp.service
janv. 04 07:56:46 basegnss run_cast.sh[2771]: 2024/01/04 06:57:04 [CC---] 10919864 B 1243 bps (0) /dev/ttyACM0 (1) 2 clients
I seem to get the same output from the Ntrip Caster service.
janv. 04 08:05:41 basegnss systemd-journald[151]: Suppressed 9 messages from str2str_tcp.service
janv. 04 08:05:46 basegnss run_cast.sh[2771]: 2024/01/04 07:06:04 [CC---] 11017840 B 1693 bps (0) /dev/ttyACM0 (1) 2 clients
janv. 04 08:05:51 basegnss run_cast.sh[2771]: 2024/01/04 07:06:09 [CC---] 11018924 B 1760 bps (0) /dev/ttyACM0 (1) 2 clients
janv. 04 08:06:41 basegnss systemd-journald[151]: Suppressed 9 messages from str2str_tcp.service
janv. 04 08:06:41 basegnss run_cast.sh[2771]: 2024/01/04 07:06:59 [CC---] 11028072 B 1696 bps (0) /dev/ttyACM0 (1) 2 clients
janv. 04 08:06:46 basegnss run_cast.sh[2771]: 2024/01/04 07:07:04 [CC---] 11029092 B 1564 bps (0) /dev/ttyACM0 (1) 2 clients
janv. 04 08:06:51 basegnss run_cast.sh[2771]: 2024/01/04 07:07:09 [CC---] 11030096 B 1565 bps (0) /dev/ttyACM0 (1) 2 clients
janv. 04 08:07:41 basegnss run_cast.sh[2771]: 2024/01/04 07:07:59 [CC---] 11038696 B 1499 bps (0) /dev/ttyACM0 (1) 2 clients
janv. 04 08:07:41 basegnss systemd-journald[151]: Suppressed 9 messages from str2str_tcp.service
janv. 04 08:07:46 basegnss run_cast.sh[2771]: 2024/01/04 07:08:04 [CC---] 11039748 B 1564 bps (0) /dev/ttyACM0 (1) 2 clients
Sorry for not getting back sooner…
Try
sudo journalctl -xeu str2str_tcp
No problem. Only winter season yet 
It seem like a lot of logging or something??
sudo journalctl -xeu str2str_tcp
░░ in the unit file. See journald.conf(5) and systemd.exec(5) for details.
Jan 08 19:44:43 basegnss run_cast.sh[2771]: 2024/01/08 18:45:01 [CC---] 83991064 B 1754 bps (0) /dev/ttyACM0 (1) 127.0.0.1
Jan 08 19:44:48 basegnss run_cast.sh[2771]: 2024/01/08 18:45:06 [CC---] 83992084 B 1563 bps (0) /dev/ttyACM0 (1) 127.0.0.1
Jan 08 19:45:43 basegnss systemd-journald[151]: Suppressed 10 messages from str2str_tcp.service
░░ Subject: Messages from a service have been suppressed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ Documentation: man:journald.conf(5)
░░
░░ A service has logged too many messages within a time period. Messages
░░ from the service have been dropped.
░░
░░ Note that only messages from the service in question have been
░░ dropped, other services' messages are unaffected.
░░
░░ The limits controlling when messages are dropped may be configured
░░ with RateLimitIntervalSec= and RateLimitBurst= in
░░ /etc/systemd/journald.conf or LogRateLimitIntervalSec= and LogRateLimitBurst=
░░ in the unit file. See journald.conf(5) and systemd.exec(5) for details.
Jan 08 19:45:43 basegnss run_cast.sh[2771]: 2024/01/08 18:46:01 [CC---] 84001736 B 1693 bps (0) /dev/ttyACM0 (1) 127.0.0.1
Jan 08 19:45:48 basegnss run_cast.sh[2771]: 2024/01/08 18:46:06 [CC---] 84002756 B 1688 bps (0) /dev/ttyACM0 (1) 127.0.0.1
Jan 08 19:46:43 basegnss systemd-journald[151]: Suppressed 10 messages from str2str_tcp.service
░░ Subject: Messages from a service have been suppressed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ Documentation: man:journald.conf(5)
░░
░░ A service has logged too many messages within a time period. Messages
░░ from the service have been dropped.
░░
░░ Note that only messages from the service in question have been
░░ dropped, other services' messages are unaffected.
░░
░░ The limits controlling when messages are dropped may be configured
░░ with RateLimitIntervalSec= and RateLimitBurst= in
░░ /etc/systemd/journald.conf or LogRateLimitIntervalSec= and LogRateLimitBurst=
░░ in the unit file. See journald.conf(5) and systemd.exec(5) for details.
Jan 08 19:46:43 basegnss run_cast.sh[2771]: 2024/01/08 18:47:01 [CC---] 84012408 B 1624 bps (0) /dev/ttyACM0 (1) 127.0.0.1
Jan 08 19:46:48 basegnss run_cast.sh[2771]: 2024/01/08 18:47:06 [CC---] 84013444 B 1630 bps (0) /dev/ttyACM0 (1) 127.0.0.1
I don’t know, mine did that too. So could be normal.
try sudo systemctl restart str2str_tcp
then the sudo journalctl -xeu str2str_tcp
That should restart the str2str_tcp service, and clear out old logs. So you can tell what is happening currently. Mine says
░░ A service has logged too many messages within a time period. Messages
░░ from the service have been dropped.
░░
░░ Note that only messages from the service in question have been
░░ dropped, other services' messages are unaffected.
░░
░░ The limits controlling when messages are dropped may be configured
░░ with RateLimitIntervalSec= and RateLimitBurst= in
░░ /etc/systemd/journald.conf or LogRateLimitIntervalSec= and LogRateLimitBurst=
░░ in the unit file. See journald.conf(5) and systemd.exec(5) for details.
Jan 08 23:30:57 basementserver run_cast.sh[1182]: 2024/01/08 23:31:16 [CC---] -1256692164 B 27474 bps (0) /dev/tty>
Jan 08 23:31:50 basementserver systemd[1]: Stopping RTKBase Tcp...
░░ Subject: A stop job for unit str2str_tcp.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit str2str_tcp.service has begun execution.
░░
░░ The job identifier is 148482.
Jan 08 23:31:50 basementserver systemd[1]: str2str_tcp.service: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit str2str_tcp.service has successfully entered the 'dead' state.
Jan 08 23:31:50 basementserver systemd[1]: Stopped RTKBase Tcp.
░░ Subject: A stop job for unit str2str_tcp.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit str2str_tcp.service has finished.
░░
░░ The job identifier is 148482 and the job result is done.
Jan 08 23:31:50 basementserver systemd[1]: str2str_tcp.service: Consumed 1h 43min 30.988s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit str2str_tcp.service completed and consumed the indicated resources.
Jan 08 23:31:50 basementserver systemd[1]: Starting RTKBase Tcp...
░░ Subject: A start job for unit str2str_tcp.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit str2str_tcp.service has begun execution.
░░
░░ The job identifier is 148482.
Jan 08 23:31:50 basementserver systemd[1]: Started RTKBase Tcp.
░░ Subject: A start job for unit str2str_tcp.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit str2str_tcp.service has finished successfully.
░░
░░ The job identifier is 148482.
lines 57-112/112 (END)
I’m really not sure what’s going on yet.
Hmm 
Rather strange.
During the time it was down, I changed the network cable to a “wall-mounted” one that didn’t work. Had to fit a new plug in one end.
So It was actually started once, not connected to the network. I swapped cable to the old one that worked. And later back to the now working wall-monted cable.
Would not dream of that making any issues but…?
Not too well known with this, but is it possible that the str2str_tcp service (or other) was somehow fooled by this?
systemctl restart str2str_tcp
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentification requise pour redémarrer « str2str_tcp.service ».
Authenticating as: ,,, (basegnss)
Password:
==== AUTHENTICATION COMPLETE ===
basegnss@basegnss:~ $ sudo journalctl -xeu str2str_tcp
░░ A stop job for unit str2str_tcp.service has begun execution.
░░
░░ The job identifier is 4253.
Jan 09 07:45:58 basegnss systemd[1]: str2str_tcp.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit str2str_tcp.service has successfully entered the 'dead' state.
Jan 09 07:45:58 basegnss systemd[1]: Stopped RTKBase Tcp.
░░ Subject: A stop job for unit str2str_tcp.service has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit str2str_tcp.service has finished.
░░
░░ The job identifier is 4253 and the job result is done.
Jan 09 07:45:58 basegnss systemd[1]: str2str_tcp.service: Consumed 49min 8.498s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit str2str_tcp.service completed and consumed the indicated resources.
Jan 09 07:45:58 basegnss systemd[1]: Starting RTKBase Tcp...
░░ Subject: A start job for unit str2str_tcp.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit str2str_tcp.service has begun execution.
░░
░░ The job identifier is 4253.
Jan 09 07:45:58 basegnss systemd[1]: Started RTKBase Tcp.
░░ Subject: A start job for unit str2str_tcp.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit str2str_tcp.service has finished successfully.
░░
░░ The job identifier is 4253.
I found this issue:
Thinking some more…
My pi could be powered down long enough to expire the dhcp lease-time.
Cant remember the IP before this but I think it was 192.168.10.110
Now I have RTK-Base on both 192.168.10.110 and 192.168.10.111
Hostname “basegnss” points to 192.168.10.111
Should perhaps run this on manual IP.
Edit:
@Davidwedel
I followed the suggestions from Stefal on the github issue, and it may indicate hardware problem.
Could it be the same for you?
Borrowed a different antenna and signal came back… Bugger…
Must be wind and frost that broke cable or antenna then.
So, got some new connectors, and everything works. Antenna was fine.
Apparently I had connected 2 female connectors.
Quite funny that worked for a wile tho.