GPS Recommendation

[barnakiel]

Originally Posted by bcn

On our Olimex A20 ARM system you will find ttyUSBx and ttyACMx. Plus the physical serial ports with ttySx.

Ok then as the gps is a BU puck then I assumed it is a usb puck (yes, i am aware serial BU exists).

If it is a usb puck, it should crop up on a tty USB, not ACM?

If it is a serial puck, it should come uo on tty S?

Why ACM comes up the discusiion then?

Sorry for this many doubts I just like to understand such things.

barnakiel

[AedanC]

Have you tried using a USB hub that's powered externally?

[bcn]

Originally Posted by barnakiel

Ok then as the gps is a BU puck then I assumed it is a usb puck (yes, i am aware serial BU exists).

If it is a usb puck, it should crop up on a tty USB, not ACM?

If it is a serial puck, it should come uo on tty S?

Why ACM comes up the discusiion then?

Sorry for this many doubts I just like to understand such things.

barnakiel

In theory a "/dev/ttyACM0 is a USB communication device (CDC) of sub-type "abstract control model" (ACM)" or modem.
In our case the Navilock USB puck shows up as ttyACM and the em-trak AIS receiver as ttyUSB.
So most probably simply a question of the driver used for the USB-serial chip in either case.
All the ttys are acting a serial device without distinctions - in our case.

[petter5]

See photo. This is from openplotter 0.8 running GPS and AIS receiver.

The GPS is VK172 G-MOUSE USB GPS/GLONASS USB GPS Receiver and the AIS is dAISy HAT for raspberry PI.

This is a live system so the configuration is correct as shown in the photo.

Go to marinetraffic.com and search for "Fulehuk Lighthouse - Oslofjord - Station #3516"

Originally Posted by bcn

In theory a "/dev/ttyACM0 is a USB communication device (CDC) of sub-type "abstract control model" (ACM)" or modem.
In our case the Navilock USB puck shows up as ttyACM and the em-trak AIS receiver as ttyUSB.
So most probably simply a question of the driver used for the USB-serial chip.
All the ttys are acting a serial device without distinctions - in our case.

[barnakiel]

Originally Posted by bcn

In theory a "/dev/ttyACM0 is a USB communication device (CDC) of sub-type "abstract control model" (ACM)" or modem.
In our case the Navilock USB puck shows up as ttyACM and the em-trak AIS receiver as ttyUSB.
So most probably simply a question of the driver used for the USB-serial chip in either case.
All the ttys are acting a serial device without distinctions - in our case.

OK, understood.

Then the puck in question should arrive att tty USB, not acm, UNLESS BU changed the drivers from ver 2. to 4. It is very easy to tell as the drivers are freely available at their site. All my (Windows) machines install this puck without drivers (as it is indee a generic what? ftdi or prolific.

My Linux toys always connect them to tty USB. I understand Pi does so via ACM maybe.

Re the power issue. Our puck needs only a fraction of an amp. So low power on usb should not be an issue. If it is, the puck will not lock in nor on (blinking, then solid led).

As I have said, IP gps seems much easier to config for the less skilled user.

Thanks for taking time and explaining the ACM detail to me!

Love,
b.

[petter5]

I agree that IP gps is a no brainer, BUT the openplotter is capable to provide NMEA over IP for all devices on the network as soon as the connected GPS is configured correct so here it is a question of what comes first, the chicken or egg ? Finally answered! Which came first, the chicken or the egg? | MNN - Mother Nature Network

Even if the GPS use close to no power, using a good quality power supply for a raspberry PI can not be stressed enough. First thing to check when you have problem with external connected devices on the PI id that you have a good power supply. I have set up many RPI's with usb plug connected GPS and all of them work.
To trouble shoot the problem, could you post your .kplex.conf that is located in your home directory. this is a hidden file so you must enable display of hidden files.

Originally Posted by barnakiel

OK, understood.

Then the puck in question should arrive att tty USB, not acm, UNLESS BU changed the drivers from ver 2. to 4. It is very easy to tell as the drivers are freely available at their site. All my (Windows) machines install this puck without drivers (as it is indee a generic what? ftdi or prolific.

My Linux toys always connect them to tty USB. I understand Pi does so via ACM maybe.

Re the power issue. Our puck needs only a fraction of an amp. So low power on usb should not be an issue. If it is, the puck will not lock in nor on (blinking, then solid led).

As I have said, IP gps seems much easier to config for the less skilled user.

Thanks for taking time and explaining the ACM detail to me!

Love,
b.

[barnakiel]

Originally Posted by petter5

I agree that IP gps is a no brainer, BUT the openplotter is capable to provide NMEA over IP for all devices on the network as soon as the connected GPS is configured correct so here it is a question of what comes first, the chicken or egg ? Finally answered! Which came first, the chicken or the egg? | MNN - Mother Nature Network

Even if the GPS use close to no power, using a good quality power supply for a raspberry PI can not be stressed enough. First thing to check when you have problem with external connected devices on the PI id that you have a good power supply. I have set up many RPI's with usb plug connected GPS and all of them work.
To trouble shoot the problem, could you post your .kplex.conf that is located in your home directory. this is a hidden file so you must enable display of hidden files.

OP has an input not an output challenge. It does not matter what can be done with the gps data once it gets in; the question is how to get the gps data in, in the first place.

kplex.conf tells you nothing about where the device attaches. But I am not going to tell this x times only this one last time.

I am not sure why you need kplex to get data from a gps puck to OpenCPN as a Linux based OpenCpn reads gps from serial or usb tty, without any need for kplex. As I have said before, I am not a Pi virtuoso just wondering why you guys make simple things difficult. Complex platforms make life difficult for the end user. KISS.

Make sure the driver is loaded.
Make sure the usb is recognised.
Check how the gps attaches to your machine.
(all these is done by checking linux machine startup logs)
View the flow on this specific tty.
Then attach this specific tty to OpenCPN config page in the GUI.

Puck status: blinks=locking on, steady=locked on. Depending on your puck, before locking on the signal the puck may provide zero data in the terminal window. Wait till the led is solid.

Use simple methods, and troubleshoot from the source, outwards, one step at a time.

Signing off,
b.

[petter5]

Well, he uses openplotter. The idea behind openplotter is to do all input in the openplotter GUI and then multiplex all singals to other applications including the opencpn instalation that comes with openplotter so on this platform you shall NOT add any connections to the opencpn installed on the RPI since opencpn is already configuere to take input from openplotter (kplex). Yes I know you can do thing many different ways but most "drivers" is included with openplotter so if a device ir recognized by the system and correctly configured in the openplotter gui (witch writes to .kplex.conf) this will give information to start trouble shooting.

Originally Posted by barnakiel

OP has an input not an output challenge. It does not matter what can be done with the gps data once it gets in; the question is how to get the gps data in, in the first place.

kplex.conf tells you nothing about where the device attaches. But I am not going to tell this x times only this one last time.

I am not sure why you need kplex to get data from a gps puck to OpenCPN as a Linux based OpenCpn reads gps from serial or usb tty, without any need for kplex. As I have said before, I am not a Pi virtuoso just wondering why you guys make simple things difficult. Complex platforms make life difficult for the end user. KISS.

Make sure the driver is loaded.
Make sure the usb is recognised.
Check how the gps attaches to your machine.
(all these is done by checking linux machine startup logs)
View the flow on this specific tty.
Then attach this specific tty to OpenCPN config page in the GUI.

Puck status: blinks=locking on, steady=locked on. Depending on your puck, before locking on the signal the puck may provide zero data in the terminal window. Wait till the led is solid.

Use simple methods, and troubleshoot from the source, outwards, one step at a time.

Signing off,
b.

[barnakiel]

Originally Posted by petter5

Well, he uses openplotter. The idea behind openplotter is to do all input in the openplotter GUI and then multiplex all singals to other applications including the opencpn instalation that comes with openplotter so on this platform you shall NOT add any connections to the opencpn installed on the RPI since opencpn is already configuere to take input from openplotter (kplex). Yes I know you can do thing many different ways but most "drivers" is included with openplotter so if a device ir recognized by the system and correctly configured in the openplotter gui (witch writes to .kplex.conf) this will give information to start trouble shooting.

I can see the point. But this policy apparently does not work. Or at least it does not work for this poster.

A developer must decide either to be plug and play (Mac way), plug and possibly play (Win way) or plug and play (for hours, with the settings, aka Linux way).

So the problem is not an OpenCPN nor it is a problem with the gps puck or its drivers. All have been proven to work well and reliably on Linux.

Then you are right what you said earlier you want the kplex.conf. I can see the point now.

I have seem kplex fail in many ways when the conf calls at ttys where no devices are attached. This again happens easily if we plug USB devs into different ports each and every time (twice is enough).

So, to troubleshoot this, one must know where at tty the device landed this time and then adjust the content of the kplex.conf acordingly.

Start with finding out where the device attached to the machine.
Cat tty make sure there is a data flow there.
Adjust kplex.conf and restart the machine.

Cheers,
b.

[petter5]

.kplex.conf standard settings in the main part of the conf file in openplotter must be changed through the gui, if not kplex will fail when saving/restart.

if making any manual changes to .kplex.conf they can be added at the absolute BOTTOM of the file under the settings that is done through the gui.

Originally Posted by barnakiel

Adjust kplex.conf and restart the machine.

Cheers,
b.

[rgleason]

Bu353-S4 works very well with Windows 10, that is what has been stated in the manual. I am not aware of a report that it works "out of the box" whatever that means, for rpi3b. Evidently openplotter can be a helpful version in this regard, but others will need to advise, as I do not use rpi.

[barnakiel]

Originally Posted by petter5

.kplex.conf standard settings in the main part of the conf file in openplotter must be changed through the gui, if not kplex will fail when saving/restart.

if making any manual changes to .kplex.conf they can be added at the absolute BOTTOM of the file under the settings that is done through the gui.

OK. I stand corrected.

My kplex sits on a wifi router so I just enter the parameters manually into the conf file. Hence the confusion.

I was actually thinking of building a GUI for kplex so maybe I will look up openplotter see if your gui could work on my routers.

Cheers,
b.

[bcn]

All the OpenPlotter stuff is in Python.
A port to Windows and the rest of architectures would be very interesting.

Obviously one will not be able to read the GPIO pins under Windows...

[barnakiel]

It is not required under Windows as OpenCPN does the same job (multiplexing nmea data) natively.

Also NavMon does this. We do not need kplex under Windows.

As far as python or something else is concerned, as long as the code is open source, it can be plainly rewritten for the new environment. But maybe this is not required. I think Pi is Linux and my nmea routers are also Linux.

I cannot write python but I could look at the source and write the same thing in C.

b.

[chuckr]

I am not a techie - so bear with us

We are OpenCPN on a laptop and tablet with windows 10 -- our gps is a Hamlet blue tooth that is actually solar powered -
all I can say is it works and yes you have to go to 9600