hi diego,
can you please provide your log files as well?
thanks,
richard
Hi Richard,
I tried to download them using the web interface, but it is not working (it keeps me waiting). I see that in /opt/log there is a bunch of *.log files. Can you tell me which log files you need, so I can manually copy and send them to you?
Thanks
Diego
hi,
if you can use this command to send them all, that would be great.
> tar cf /tmp/shake.logs.tar /opt/log
and then copy the file located in /tmp to your local computer and attach them here.
thanks,
richard
Hi Richard,
please find attached the log files for my two RS3D (v5) units.
The 2374 unit yesterday afternoon (Nov 29, 2021) has been tentatively connected to a GPS antenna to test if it could get the timing from it. The 373 unit has been connected to the LAN only.
Let me know in case you need anything else.
Thanks
Diego
shake373.log.tar (10 KB) shake2374.logs.tar (3.2 MB)
hi diego,
the 373 unit tar file is empty, i’m afraid. can you have a look and re-send?
thanks,
richard
Hi Richard,
I apologize for replying so late, but I did not get any message about your request.
Please find attached the correct 373 unit tar file.
Thanks
Diego
shake373.logs.tar (4.9 MB)
1 Like
hello diego,
for both units, the GPS log file gpsd-mgr.log is reporting that no GPS module is attached:
========== TEST BEGIN ==========
2021 333 14:08:17
Required output from command 'cat /dev/ttyUSB[0-9]' not found, please investigate.
========== TEST END ==========
verify it’s plugged in and try again. (fyi: it did previously successfully connect, then stopped, see the gpsd-mgr log file for exact details on which day this happened.)
and what brand of GPS module are you using? it’s possible it will not be coming in on the ttyUSB port. is there a port named \dev\ttyACM0 by chance?
Dear Richard,
I believe the units started to have problems with the GPS module after the OS update to version 0.19.
I restarted both the units and I plugged the GPS module just in the 373 unit. Below you can find some screenshots for both the units. Actually there is a port named ttyACM0 and, if I’m not wrong’, the GPS module seems to be connected to that port.
I forgot to say that, for unit 373, the GPS log file gpsd-mgr.log is still reporting that no GPS module is attached.
Please, let me know what you think.
hi,
can you please also include the log files? you can download them from the home page of the rs.local front-end config screen.
thanks,
richard
Hi Richard,
apologies for my late reply, but I could not reach my units remotely.
I just made a further test (restarted both my units after I plugged in the GPS USB antennas) but it seems that I still have the same issues.
I attach the log files for both the units.
log373_20220112.tar (5.0 MB) log2425_20220112.tar (3.6 MB)
Let me know
Thanks and happy new year
Diego
hi diego,
what’s very strange about all this is that when the units were first started back in 2018.281, the dongle was successfully detected on /dev/ttyUSB0 (or some other number), followed by a successful install of the GPS support software.
but then, on 2018.282, the port is no longer found:
========== TEST BEGIN ==========
2018 282 14:43:14
No device named /dev/ttyUSB* found, dongle appears to be not plugged in.
========== TEST END ==========
========== TEST BEGIN ==========
2018 283 14:00:24
========== TEST END ==========
========== TEST BEGIN ==========
2018 283 14:42:07
========== TEST END ==========
========== TEST BEGIN ==========
2018 283 14:19:17
No device named /dev/ttyUSB* found, dongle appears to be not plugged in.
========== TEST END ==========
(a section without an error indicates success, i need to fix this…)
after this initial success, it never again finds the GPS dongle. i was recently looking at the u-blox receiver and did find that when it’s plugged in it automatically defines the /dev/tty name, which was a surprise. this would explain what’s going on now, but doesn’t explain why this initially worked back when the unit was set up. was the initial setup done with a different GPS receiver than the u-blox currently attached?
fyi: there was no update to how the GPS dongle is detected in v0.19. this problem started back in 2018, in fact, so there is no relationship to the recent update.
one way to solve this (in the short term) is to set up a udev rule that will create a soft-link between /dev/ttyUSB0, for example, and /dev/ttyACM0. i will find the details of this later today and send them to you. do you still have access to the boxes to make changes?
cheers, more info on the udev rule coming later.
and happy new year to you as well,
richard
Hi Richard,
actually we have been using the same GPS receiver since the beginning.
To make the story short, initially (2018 or 2019?) the GPS dongle was successfully detected but we had to manually set a time close to the actual one in order for the unit to align with the GPS clock. When the OS of our units was still 0.15 or 0.16 (in the beginning of 2020 I think) we wrote a simple routine to be executed at boot in order to automatically get the GPS clock from the attached USB GPS receiver (see also the title of this post). Then, in another post in this forum, I was told that bugs related to GPS dongle detection are solved with OS 0.19, so I updated the units (second half of 2021). Since the update, the GPS dongle is no longer detected.
I do have access to the units and appreciate your help.
Thanks
Diego
hi diego,
this is what confuses me, the update to fix the bug setting the time at system startup did not have anything to do with the port name being used. and, the identification of the incorrect /dev/tty being used stopped working back in 2018 according to the log files, which was almost two years before v0.19 came out.
but let’s forget the history for the moment and try to get it working now. i am still investigating the best way to solve this in the short term for you. i will get back to you soon, apologies for the delay. now that the log files have told me exactly what’s going on, i am able to provide a solution that will work for you.
thanks,
richard
Hi Richard,
did you get the chance to think about how to solve my issue?
By the way, I had a look at what I did to automatically get the timing from the GPS module.
I simply added the following line to etc/rc.local that should be executed at boot
./opt/run.sh
run.sh is simply
FILE=/opt/gps_new.py
rm /opt/nohup.out
nohup python $FILE &
and gps_new.py (1.4 KB) (a bit of spaghetti coding I’m afraid) is actually the routine that gets the timing from the GPS module.
Unfortunately, I found out that this workaround introduces a delay of about 0.48s in the absolute timing of my units.
Let me know what you think
Thanks
Diego
Hi Richard,
do you have any news for me?
Thanks
Diego
Hi Richard,
could you please get back to me about the GPS issue?
Shortly, I will need to deploy my units in the field and I am afraid I must solve that issue before the deployment.
Thanks
Diego
hi diego,
apologies for the ongoing delay. i have been attempting to come up with a generic solution, but it is elusive. some GPS units, inconveniently, decide the name of the serial port to use. at the same time, the methods used to connect the PPS to the OS can also differ, making a generic solution a moving target. that’s not to say it’s not possible, just that it is not obvious.
nevertheless, i will try to get something to try to you this week, if that’s not too late.
richard
Hi Richard,
I am encountering the same problem that was discussed here more than a year ago.
I have an RS1D in an outdoor enclosure and GPS antenna purchased from Raspberry Shake in May.
My GPS antenna is not connecting/communicating with the RS1D (as far as I can tell). The gpsd-mgr.log is reporting the exact same message as Diego’s shakes were:
cat /dev/ttyUSB[0-9
I’ve checked that the GPS unit was ‘activated’ via (I got an installed message):
$ sudo gpsd-mgr -ic
But running:
$ sudo gpsd-mgr -t
or
$ sudo gpsd-mgr -i
Results in failure/no data.
See screenshot below:
Do you have any insight into how to solve this problem?
i.e. resolve the connection from the RS1D to the GPS?
I am planning to deploy them next week, so this is fairly urgent, at a remote location for a couple of months.
Thanks,
Annika
RSH.R5228.2023-06-29T18_21_13.logs.tar (773.5 KB)
Hello Annika, and welcome to our community!
We have deployed a fix for the issue you are experiencing as other users had notified us of having the same connectivity problems between the Shake and some newer GPS modules.
Could I please ask you to (if you haven’t already) re-burn the microSD card of the Shake, to see if the procedure solves the issue? Regarding the burning procedure, I will leave it here for your convenience:
- Please take the microSD card you have and format it before burning the new Shake OS image
- Make sure, when you format it, that the shown capacity is the maximum (i.e. if the SD card is 32GB, then the capacity should be near or equal to that value). This is to check that no partitions have been involuntarily and erroneously created. They could be the cause of the error we see now
- Take care to format the SD card in a FAT32 File System (or exFAT if the SD card is 64GB or larger)
- Download the new Shake OS image from here: https://gitlab.com/raspberryShake-public/raspshake-sd-img/-/raw/main/raspishake-release.zip
- And follow the microSD burning instructions from here: raspishake-microSD-card-software-Instructions.txt · main · raspberryShake-public / Raspshake Sd Img · GitLab
Once done, re-insert the microSD card into the Shake and boot it again normally. Once you see that the Shake is working fine, shut it down, connect the GPS module,and reboot it. Now the Shake should be able to see the GPS and use it as an NTP time source.
If not, could you please provide the following?
1) Contents of `cat /etc/ntp.conf`
2) Output of command `ntpq -p`
3) Output of command `sudo journalctl -xn` if and when ‘restart ntpd’ fails
4) The new log files
Thank you for your collaboration.