GPS tracking halts overnight and odd restarts...

[Rassiloth]

With a stable 4G connection now in place, and the 'Remote Access' also working fine, I've started to keep an eye on the GPS data.

This has lead to a couple of strange observations:

The SM platform stops getting any GPS data from the GPS unit overnight:-
Not 100% sure on the exact time but it was fine at 11:30pm last night and was down again this morning.
After a fail all that show is the base indicator on the map. If no base is set it defaults to showing the Project Computers location.
GPS is from a USB device and a quick cat /dev/ttyUSB0 shows data still being received by the RPi itself.
The issue is resolved till the next night by a reboot.

If I try to connect a sensor the main RPi unit starts crashing and restarting every few minutes
Its fine with the USB device, 4G dongle and a USB BT dongle, apart from the off GPS behavior mentioned above its solid
I can add sensors and they register in the BT stack fine but if you let it link to one it just starts rebooting.
Even tried removing the 4G and GPS and just leaving the BT dongle but it still reboots.

Any thoughts?


Regards

Ian
NB Crossmead

[crb]

The GPS is very strange. Out of curiosity what happens if you schedule a reboot in crontab at ,say, 2200?

The internal bluetooth is definitely turned off I take it? What are the results from l2ping on the bluetooth sensor? Can you see a stream of data using picocom on /dev/rfcommn where n is the device no. If you have only one sensor connected it will probably be rfcomm0. See your postgresql entry in table sm_remoteunit.

Good luck,

Colin

[Rassiloth]

Colin,

I'll do the sensor tests when I have a bot more time, they are currently shutdown to stop the rebooting, but for the GPS see below.

Checking the portal last night (11:35pm) everything was ok and GPS data was shown in the 'Real Time Update' view.
The unit was rebooted at 11:44pm and when checked in the morning only the base set (March 1st) was showing, no data was shown in the 'Real Time Update' view.
After a remote reboot through the portal everything started working again.

[crb]

Sounds almost as though it is time related. What happens if you change the crontab reboot to 0100?
I notice that you reported intermittent gps problems here https://www.skippersmate.co.uk/skippers ... =10#p13994 Is this the same problem?

[Rassiloth]

Colin,

Some of it is probably related. Doing some testing (and assuming I've understood the platform correctly), a reboot just clears out anything except the base registration from the database and this seems to work fine. Whether the reboot is scheduled or manual has no untoward impact.

What does seem to be the root is the entry in the crontab that tidys up the ram disk each morning. The command below is scheduled for ten past three each morning and after that the GPS data seems to stop being collected until the BCS is rebooted.

/usr/bin/pcltidyramdisk

The fix for now is to schedule a reboot sometime after the pcltidy command, although this clears the previous days data records.

That's not a major issue as its relatively simple to setup a local process to capture GPS positioning to a local file for copy to a master store at sometime. This is mainly for log keeping, unless the SM system can do this?

Incidentally, on the main BCS menu the option 'Plot Your Cise', under GPS, is struck through. Is this something that is available only with a different variant of SM?

Ian

[penny]

Hi,

As you have surmised the pcltidy routine merely tidies the database and is a substitute for a reboot. Historical records are hel on the database on the main server. This routine is common to all users (including our system) and doesn't seem to cause any problems. With your permission I'll log on to your system and have a look when I'm back in the office later this week.

Plot your course is a new feature under development and not yet released. Thisiswhy it is struck through.

Regards,

Colin

[Rassiloth]

Colin,

No problem, feel free to connect.

The system sits on its own dedicated connection so nothing should interfere.


Regards

Ian

[crb]

O.K. I'll be in the officee later this week. I'll do i t then.

[crb]

Hi Ian,

Think I've tracked down the problem, at least I can reproduce it on our system. It is connected with the overnight ramdisk tidying program. The easiest work around is to reboot (which obviously tidies the ramdisk) instead. I've made this change to your system and would be interested to hearb how it goes. In the meantime I'll tr y to tracvk down the root cause of the problem. Maybe not until the end of the week as we are being lifted early this week (weather permitting ).

Cheers,
Colin

[Rassiloth]

Colin,

So far so good.

No halts in the plotting process to date.


Ian