USB key dongle for oeSENC

[bcn]

Taking note...

[svspirited]

Any timeline on when the dongle will be supported on MacOS?

[bcn]

We launched another request yesterday...

[svspirited]

Originally Posted by bcn

We launched another request yesterday...

Thanks

[hreuver]

The all new oeserverd with SGlock library was released for arm64.

On my Ubuntu 18.04 / arm64 system it works like a charm (Odroid N2). (Tested with 5,1,621/github, but I'm sure the 5.1.619/bdbcat version also works).

On my Pi4 (Ubuntu 20.04 / arm64) I get an error.

I guess there will be some request for information. Please tell me what you need.

PS Undoubtedly the current release of OpenCPN5.2 has currently a higher priority than the making the USB key ready for Ubuntu 20.04/arm64.

[verkerkbr]

Hi Reuver,

Oesenc plugin for my dongle works here on my Raspberry P4 2 GB and the 64 bit RaspiOS.

With the latest OpenCPN version. There is a new plugin manager. But if you look at it, it shows empty folders..

But if you remove the OpenCPN config first. Then a new one is generated at the start.

Then the folders of the plugin manager shows up. And you can install the 4.2.12 Oesenc-pi pluging.

Then my present Oesenc charts works. There is no longer a need to make a fingerprint for the dongle.

Regards,


Bram

[hreuver]

Originally Posted by verkerkbr

Hi Reuver,

Oesenc plugin for my dongle works here on my Raspberry P4 2 GB and the 64 bit RaspiOS.

With the latest OpenCPN version. There is a new plugin manager. But if you look at it, it shows empty folders..

That's the way it works with Ubuntu 18.04. Plugins via OpenCPN, when I looked it up there is currently only one platform for ARM64 for the pluginmanager from OpenCPN.

I suspect either you are using the same plugins via a backdoor or openplotter provides a set of plugins for raspbian.

Ubuntu            Debian
20.04  focal      bullseye/ sid   - 11
18.04  bionic     buster  / sid   - 10

However for 20.04 the pluginmanager provides no plugins.

The github version of the plugin which works with 18.04 does not work for 20.04 (both compiled on the computers involved).

I think you may run into trouble when you are "upgrading" to RaspiOS Bullseye. For now Bullseye is the testing environment for Debian. For the laptop (Debian/Bullseye/Sid/x86_64) I bypassed the problem by switching to Flatpak.

[verkerkbr]

Originally Posted by hreuver

That's the way it works with Ubuntu 18.04. Plugins via OpenCPN, when I looked it up there is currently only one platform for ARM64 for the pluginmanager from OpenCPN.


I suspect either you are using the same plugins via a backdoor or openplotter provides a set of plugins for raspbian.

Ubuntu            Debian
20.04  focal      bullseye/ sid   - 11
 18.04  bionic     buster  / sid   - 10

However for 20.04 the pluginmanager provides no plugins.


The github version of the plugin which works with 18.04 does not work for 20.04 (both compiled on the computers involved).

It seems to be part of the OpenCPN version for Arm64. But remember first remove the Opencpn.conf file. Then go to the plugin manager and you will see the 4.2.12 version. Focal seems also be supported by OpenCPN.


Not done any compiling.


Bram

[verkerkbr]

Image of the plugin manager.

[hreuver]

Perhaps this might give a clue:

# oeserverd -a
oeserverd Version 1.17

# oeserverd -s
0
# oeserverd-armhf -a
oeserverd Version 1.14

# oeserverd-armhf -s
1

Small feature request for Dave:
Is it possible to add a switch for architecture of the plugin, just in case people claim to be using "arm" without stating "armhf" or "arm64".
I think it might give you some cheap information which can expose some obvious mistakes which should never happen but can never be ruled out completely.


I will open an Issue at github (bdbcat/oesenc_pi).

[hreuver]

Originally Posted by hreuver

The all new oeserverd with SGlock library was released for arm64.

On my Ubuntu 18.04 / arm64 system it works like a charm (Odroid N2). (Tested with 5,1,621/github, but I'm sure the 5.1.619/bdbcat version also works).

On my Pi4 (Ubuntu 20.04 / arm64) I get an error.

With the release of OpenCPN I retested the RPI4. It seems that I overlooked something before, most probably the dependency on libusb-0.1 (the udev rule was certainly present).

I thought I tested it explicitly after some comment from Dave as a reaction on a post by Bram in the beta thread. Seems I was not thorough enough.

When it works on Focal it should also work without much trouble on Bullseye.

Currently tested:
Odroid N2 / supplier Ubuntu 18.04/4.9.xx kernel, OpenCPN 5.2 bionic
Odroid N2 / Armbian (Focal)/ 5.6.x kernel, OpenCPN 5.2 bionic
RPI4 / Ubuntu Focal 20.04 (Canonical), OpenCPN 5.2 focal / github oesenc_pi-4.2.14.

With the bionic version I used the oesenc plugin from the PluginManager. (Armbian probably works with the bionic version due to an older libwxgtk version).

[SkibladnerII]

I have been in contact with o-charts.org and their response was:

Hi Benjamin,
There is a small bug in OpenCPN that will be fixed on next versions. Please open an terminal and type this to install a required package:

sudo apt install opencpn-sglock-arm32

You are right something is not working as it should with the oeSENC plugin on Raspberry. I have been able to reproduce your issue.
I will escalate this to plugin developers and I will back to you with a solution ASAP.
Roberto

[toolbar]

@bcn: Any news on the Mac front? I tried and few weeks ago, but it didn't seem to work with the same messages described two years ago.

Paul

Paul

[bcn]

Hi Paul,


some weeks ago we got the notice from SG "working now on it, shall be available in some weeks".


As you are from Kiel, you might just pick up the phone and give them a call, perhaps. Or visit them.. SG-Intec, Schauenburgerstr. 116, 24118 Kiel


Cheers


Hubert

[CarCode]

Originally Posted by bcn

Hi Paul,
some weeks ago we got the notice from SG "working now on it, shall be available in some weeks".
As you are from Kiel, you might just pick up the phone and give them a call, perhaps. Or visit them.. SG-Intec, Schauenburgerstr. 116, 24118 Kiel
Cheers
Hubert

Their website talks about "MAC OS X (32/64-Bit)" compatibility although macOS is not 32Bit anymore since some times ago.
https://www.sg-lock.com/de/products.php
Strange...