Posts: 21
Threads: 3
Joined: Jan 2020
Reputation:
0
(2024-04-19, 11:13 AM)Sailoog Wrote: Updated openpotter-sdr-vhf v4 adding "Share with AIS-catcher" option. (2024-04-19, 06:44 PM)Techstyle Wrote: is this something that works with Maiana as well as SDR? (2024-04-19, 07:09 PM)Sailoog Wrote: I am afraid not:
Per my update and implementation, AIS-catcher is not dependent on SDR. It can receive AIS messages from other sources, such as socketCAN via HAT - ie directly off NMEA2000 network being populated by MAIANA or another commercial AIS product.
Posts: 3,149
Threads: 65
Joined: Mar 2016
Reputation:
306
Posts: 41
Threads: 4
Joined: Nov 2023
Reputation:
1
(2024-07-09, 11:00 AM)tsr Wrote: (2024-07-08, 07:44 PM)Sailoog Wrote: (2024-07-08, 06:43 PM)Hakan Wrote: The openplotter v4 is downloaded and used to make an image by Raspberry pi imager. The card is mounted and the Rpi4 is started as normal.
It's wired connected to the Internet. The same result if a wifi is used. Internet connection is working.
npm/nodejs is not working so any SignalK update is not working.
This is a really strange issue because no one else reported something similar. Could you open a new thread for this issue? Did we already have one?
My Signal K also doesn't update anymore. The web UI pretends everything is working (update being installed - ... - please restart) but on a restart I find myself with the same version as before. Could only track down some checksum errors on the npm downloads so far and assumed that this as a temporary glitch (caching issue for example). Hence no report here so far.
Also: Everything still working fine in v4. It's just the updates.
See https://forum.openmarine.net/showthread....7#pid33097
Posts: 21
Threads: 0
Joined: Jun 2020
Reputation:
0
For info I just downloaded the starting image and used it on a RPi3
Again the npn issue as described some times before. It hangs on updating Signalk installer. A lot tasks with "cache misses" and finally hangs.
It also not possible to update SignalK version. Probably hangs in background due to similar npn failures.
Action log:
1. Started the Pi using the the image on a SD-card
2. Used Sweden as the wifi-country
3. Changed to Swedish keyboard. (Didn't changed system country, left it at GB)
4. apt update apt upgrade
5. In raspi-config used Wayland-labwc
6. Reboot
7. apt update apt upgrade
8. Opened Openplotter settings - Refresh
9. Open openplotter Signalk installer - Start.
The installer hanged after a lot missed cache
Also for info my other Pi's I ended up to make my own npn installer but to this Rpi 3 nothing more done so far.
Håkan
Posts: 21
Threads: 0
Joined: Jun 2020
Reputation:
0
2025-03-09, 10:39 PM
(This post was last modified: 2025-03-09, 10:41 PM by Hakan.)
Sailog..
The above about Rpi3 and npn either came to a solution or never was one.
I tried again with a fresh image. Now didn't change anything. I use a wired network to not being forced to enter a wifi country.
Now the SignalK installer had a lot "missed cache", as before, but now when it hangs on something like: "npn info serial...." I waited. So after a very long time, 15 minutes?, he did continued and eventually finalized the "Start" procedure.
So now it seems to work. If it depends on the changes to wifi or keyboard or my previous impatience I can't say. I haven't verified it.
But so far case closed.
Posts: 5
Threads: 0
Joined: Mar 2025
Reputation:
0
I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie. For performance and logging reasons I added an NVME board to run the OS from an SSD. However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.
My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).
Is this a "real" issue, or did I just screw up somewhere?
Posts: 5
Threads: 0
Joined: Mar 2025
Reputation:
0
2025-03-21, 04:43 AM
(This post was last modified: 2025-03-21, 04:50 AM by xavierlh1.)
(2025-03-21, 03:31 AM)xavierlh1 Wrote: I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie. For performance and logging reasons I added an NVME board to run the OS from an SSD. However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.
My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).
Is this a "real" issue, or did I just screw up somewhere?
At this point, I now longer have a means to check where the system boots from…! The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card. When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.
I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so. I'll stay away from it until I hear more...
(2025-03-21, 04:43 AM)xavierlh1 Wrote: (2025-03-21, 03:31 AM)xavierlh1 Wrote: I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie. For performance and logging reasons I added an NVME board to run the OS from an SSD. However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.
My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).
Is this a "real" issue, or did I just screw up somewhere?
At this point, I now longer have a means to check where the system boots from…! The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card. When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.
I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so. I'll stay away from it until I hear more...
Although now my SSD is no longer accessible... :-( I'll keep digging
Posts: 5
Threads: 0
Joined: Mar 2025
Reputation:
0
(2025-03-21, 04:43 AM)xavierlh1 Wrote: (2025-03-21, 03:31 AM)xavierlh1 Wrote: I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie. For performance and logging reasons I added an NVME board to run the OS from an SSD. However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.
My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).
Is this a "real" issue, or did I just screw up somewhere?
At this point, I now longer have a means to check where the system boots from…! The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card. When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.
I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so. I'll stay away from it until I hear more...
(2025-03-21, 04:43 AM)xavierlh1 Wrote: (2025-03-21, 03:31 AM)xavierlh1 Wrote: I run OP V4 on RPI5 with a dAISy hat and try to keep things as simple as possible as I'm a newbie. For performance and logging reasons I added an NVME board to run the OS from an SSD. However, again as I'm a newbie, I try to backup my install using the cloning function to create an image on an SD card in case things go south as they often do.
My problem is that setting OPrescue=1 in /boot/firmware/config.txt appears to override the boot order so that I can no longer boot from the clone I create on SD cards (unless I suspect if I remove the SSD which is what I'm trying to avoid for practical reasons).
Is this a "real" issue, or did I just screw up somewhere?
At this point, I now longer have a means to check where the system boots from…! The only option I can think of is to physically remove the SSD.
I was able to disconnect the NVME board before reboot - Don't know whether I can reconnect w/o taking the box apart - and doing so was able to confirm that I booted from the SD card. When check sudo raspi-config - Advanced - Boot order, I get the message "Current EEPROM version 2025-02-12 or newer not found - abordting. Try updating the rpi-eeprom APT package."
Following https://commandmasters.com/commands/rpi-...ate-linux/, sudo rpi-eeprom-update provides
BOOTLOADER: up to date
CURRENT: Wed Feb 12 10:51:52 AM UTC 2025 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberry pi/bootloader-2712/default_
Use raspi-config to change the release
Looking online I found https://commandmasters.com/commands/rpi-...ate-linux/
Reading through it I ran sudo rpi-eprom-update -r to try and get back to the previous version and it seemed to work - i.e. the next boot was from the SD card.
I don't have clear evidence that this is the result of the OPrescue=1 update, it certainly seems so. I'll stay away from it until I hear more...
Although now my SSD is no longer accessible... :-( I'll keep digging
Inconclusive. ribbon cable wasn't properly seated. Once fixed, system still booted from the SSD even though the Boot Order is B1 - SD card boot first.
sudo rpi-eeprom-update give the same results as above.
Used raspi-config to reset the bootloader to the default configuration.
Still booting from SD card with Boot Order option B1, although sudo rpi-eeprom-update now reports:
BOOTLOADER: up to date
CURRENT: Wed Jun 5 03:42:49 PM UTC 2024 (…..)
LATEST: Wed Jun 5 03:42:49 PM UTC 2024 (……..)
RELEASE : default (/lib/firmware/raspberrypi/bootloader-2712/default)
Use raspi-config to change the release
Tried running raspi-config Option 8 Update but got an error. System says to try apt-get update or with --fix-missing. Running sudo apt-get update only got me a bunch of failures.
I'm hoping someone can get me on a straighter path...
Posts: 79
Threads: 3
Joined: Jan 2018
Reputation:
6
(2025-03-06, 09:10 AM)Hakan Wrote: For info I just downloaded the starting image and used it on a RPi3
Openplotter is no fun on old boards. I would suggest to Sailoog that he should warn the users that the Openplotter can only be used with at least RPi 4b with 2GB RAM
If you want to continue using your pi 3b(+), you can either install SK yourself on a RaspiOS lite image or e.g. a ready-made image from AvNav
Posts: 3,149
Threads: 65
Joined: Mar 2016
Reputation:
306
Enabling Rescue mode in OpenPlotter adding OPrescue=1 to config.txt will not have any impact at all in boot behavior because it only acts at OpenPlotter scripts level. You boot problems must have different source for sure. Maybe when you edited config.txt you added some incorrectly formatted entries, or maybe your SD card is faulty...
OpenPlotter v4 should work without problems in Raspberry model 3 but some apps can be slow and that is why we recommend Raspberry 4 or 5 models in docs.
|
