RTKBase: a GUI for your own Gnss Base Station

Hi !

It’s strange that the main service is off after a restart.
Maybe @bluerabbit case gave an answer : If the gnss board doesn’t get the same tty path, the main service will fail.

If you have another power cut, could you check if the tty path changed in /dev/ ?

Perhaps you had a very small power cut, which was long enough to cut the F9P power, but not the Pi. Then the F9P got a new tty path.

I have something that could fix that. I think I will include this in the next release. It’s a udev rules. With it the F9P will always get a ttyGNSS path.

It’s your router that gives an ip adress to your base station with its dhcp service.

That’s exactly what happened to me.

You can set a static IP on the Pi either from the GUI (right click on the network icon near the clock and follow your nose) or from the CLI:

So I set up an orange pi today. Right at the end there was this error message, and an IP scanner shows port 80 is closed. I disabled the firewall on the pi, didn’t help. Any advice? Thanks!

EDIT: trying to access via ip address doesn’t work either

You can ignore the gpsd.service error.

Check the output of sudo systemctl status rtkbase_web and for more details : sudo journalctl -u rtkbase_web

orangepi@orangepizero3:~$ sudo systemctl status rtkbase_web
● rtkbase_web.service - RTKBase Web Server
Loaded: loaded (/etc/systemd/system/rtkbase_web.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Fri 2023-10-13 12:59:14 UTC; 23s ago
Process: 4125 ExecStart=/usr/bin/python3 /home/orangepi/rtkbase/web_app/server.py (code=exited, status=1/FAILURE)
Main PID: 4125 (code=exited, status=1/FAILURE)
CPU: 3.811s

orangepi@orangepizero3:~$ sudo journalctl -u rtkbase_web
Oct 13 12:56:54 orangepizero3 systemd[1]: Started RTKBase Web Server.
Oct 13 12:56:57 orangepizero3 python3[4029]: /usr/local/lib/python3.10/dist-packages/_distutils_hack/init.py:33: UserWarning: Setuptools is replacing distutils.
Oct 13 12:56:57 orangepizero3 python3[4029]: warnings.warn(“Setuptools is replacing distutils.”)
Oct 13 12:56:57 orangepizero3 python3[4029]: Traceback (most recent call last):
Oct 13 12:56:57 orangepizero3 python3[4029]: File “/home/orangepi/rtkbase/web_app/server.py”, line 59, in
Oct 13 12:56:57 orangepizero3 python3[4029]: from flask_bootstrap import Bootstrap4
Oct 13 12:56:57 orangepizero3 python3[4029]: File “/usr/local/lib/python3.10/dist-packages/flask_bootstrap/init.py”, line 3, in
Oct 13 12:56:57 orangepizero3 python3[4029]: from flask import current_app, Markup, Blueprint, url_for
Oct 13 12:56:57 orangepizero3 python3[4029]: File “/usr/local/lib/python3.10/dist-packages/flask/init.py”, line 5, in
Oct 13 12:56:57 orangepizero3 python3[4029]: from .app import Flask as Flask
Oct 13 12:56:57 orangepizero3 python3[4029]: File “/usr/local/lib/python3.10/dist-packages/flask/app.py”, line 30, in
Oct 13 12:56:57 orangepizero3 python3[4029]: from werkzeug.urls import url_quote
Oct 13 12:56:57 orangepizero3 python3[4029]: ImportError: cannot import name ‘url_quote’ from ‘werkzeug.urls’ (/usr/local/lib/python3.10/dist-packages/werkzeug/urls.py)
Oct 13 12:56:58 orangepizero3 systemd[1]: rtkbase_web.service: Main process exited, code=exited, status=1/FAILURE
Oct 13 12:56:58 orangepizero3 systemd[1]: rtkbase_web.service: Failed with result ‘exit-code’.
Oct 13 12:56:58 orangepizero3 systemd[1]: rtkbase_web.service: Consumed 4.057s CPU time.
Oct 13 12:57:28 orangepizero3 systemd[1]: rtkbase_web.service: Scheduled restart job, restart counter is at 1.
Oct 13 12:57:28 orangepizero3 systemd[1]: Stopped RTKBase Web Server.
Oct 13 12:57:28 orangepizero3 systemd[1]: rtkbase_web.service: Consumed 4.057s CPU time.
Oct 13 12:57:28 orangepizero3 systemd[1]: Started RTKBase Web Server.
Oct 13 12:57:31 orangepizero3 python3[4099]: /usr/local/lib/python3.10/dist-packages/_distutils_hack/init.py:33: UserWarning: Setuptools is replacing distutils.
Oct 13 12:57:31 orangepizero3 python3[4099]: warnings.warn(“Setuptools is replacing distutils.”)
Oct 13 12:57:31 orangepizero3 python3[4099]: Traceback (most recent call last):
Oct 13 12:57:31 orangepizero3 python3[4099]: File “/home/orangepi/rtkbase/web_app/server.py”, line 59, in
Oct 13 12:57:31 orangepizero3 python3[4099]: from flask_bootstrap import Bootstrap4
Oct 13 12:57:31 orangepizero3 python3[4099]: File “/usr/local/lib/python3.10/dist-packages/flask_bootstrap/init.py”, line 3, in

Thanks,
Could you open a ticket on the github repository with all these informations and add the informations asked for a new ticket ?

Like that?

1 Like

Hello,

I seem to have a strange problem, which I am having a hard time to fix.

My orange pi base has worked flawless for a year or so, but now ntrip service a is working as should, connected to centipede. My ntrip service b connected to rtk2go is not working. It seems to be connected but just not sending corrections. Rtk2go pointed me to a Rtklib known problem and suggested a power cycle, which did not solve the problem for me.

Any suggestions?

Ntrip A (caster.centipede.fr) is working
but
Ntrip B (rtk2go) isn’t working ?

Seems to be the case, although I get the feeling service A is not behaving as should, loose rtk quite easily it seems the past few weeks…

What is your mount point on the centipede caster ? I will check the rtcm stream.

It is: DRGHZ

Everything seems ok with the centipede caster. As the source is the same for all the ntrip service, rtk2go should be ok too.

image

Thank you for checking, might try to make a new mountpoint with rtk2go, or stick with centipede which usually works fine for me.

I encountered the problem with Werkzeug tonight. The solution seems to be to add Werkzeug==2.2.2 to the requirements.txt so pip will install that version instead of the current 3.0.0 version, which Flask is not compatible with. I added a comment to the github issue linked to earlier to indicate this.

So did you manually install it? Or just “threw it in” requirements.txt when you were done running the ./install.sh?

It would have to be in the requirements.txt before running install.sh. But after the fact, you can add it to requirements.txt and then run:

pip install -r requirements.txt
2 Likes

I finally got rtkbase up and running on my OrangePi5 (way overkill but that’s what I have). I also will be putting it on an old Pine64 board as a backup. At first I couldn’t get any satellites to show up at all, but that turned out to be a bad plug on my test antenna, a UBlox Ann-MB[1]. I swapped antennas and everything came alive.

I’m very impressed! I love that RTKLIB does everything so I can plug any ZED-F9P into my Pi and it works without doing any configuration other than maybe a clean reset of the F9P. Makes it much more of an appliance. If the receiver dies, just swap it out. My previous setup was rather fragile, and RTKBase makes my base station more reliable and replaceable. And it supports my triple mode of operation out of the box. NTRIP serve to rtk2go, local raw tcp/ip socket over VPN, and serial out to my radio transmitter! Overall I think this is a better way to go than ESPRTK because of the flexibility.

Again, many thanks, @Stefal.

[1] Problem was the center pin in the antenna SMA plug was shorting to the outer shield. I’ve had this happen before on a cheap extension cable and it damaged my ArduSimple board. That was repaired and the repair actually made the board tolerate this kind of short without frying, although it did cause the power regulator to heat up.

I do have a question for @Stefal, though. Currently the daemonized str2str processes write to stdout every few seconds, which fills the syslog. Is there a way to quiet them? They are supposed to be logging to log files if there are problems, so I don’t see the need to output to the log file. I modified run_cast.sh to redirect echo str2str instance stderr to /dev/null and that made them quiet.

Also, and this is just a matter of personal preference, I find it preferable to let systemd do the daemonization, so in my service files I usually set Type=simple rather than Type=forking, and then not background my process. Systemd then handles it and restarts when necessary. systemd is pretty smart, so it really doesn’t matter too much.

One more thing… I modified rtkbase to allow me to use long serial port id names instead of just the short ones like ttyAC0. Id names are more stable than the short names. Depending on how things are plugged in, sometimes you might get the F9P at ttyACM0 and sometimes ttyACM1, especially if another device is also a ttyACM device. By using the long name that’s normally in /dev/serial/by_id I can avoid that problem. For example, here are the names of my f9p and radio module:

/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0
/dev/serial/by-id/usb-u-blox_AG_-_www.u-blox.com_u-blox_GNSS_receiver-if00

I modified server.py to detect the GNSS with the long name, and then I modified run_cast.sh to resolve the long names to the correct path.

If you’re interested, see:

If in the future rtkbase will automatically present a list of serial ports when configuring the rtcm_serial service, consider using the long names.