This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Signal K Server v1.32.0 Released
#11
(2020-08-06, 05:48 AM)MatsA Wrote: Maybe this will help https://github.com/SignalK/signalk-serve...-as-daemon .....

Hi MatsA,

thanks for the info. Setting up with SystemCTL was the solution. The restart could not find the systenctl (start) to stop.

Problem solved.

Bram

And the application MXTommy KIP is also working.
Reply
#12
Well, the truth is that I have spent a whole day trying to make the invention of seatalk to Signal K work and I must confess that my results have been null.

I tried to follow the instructions of:

https://github.com/SignalK/signalk-serve...k(GPIO).md

And I acquired this optocoupler circuit:
https://es.aliexpress.com/item/400114570...63c0AT6Q3a

[Image: H32634bafd02f476eb70af75e5f59b5c64.jpg]



And also this other version that I like better and based on the same optocoupler:
https://es.aliexpress.com/item/327199577...63c0AT6Q3a

[Image: HTB1nN64MVXXXXbQXXXXq6xXFXXXJ.jpg]


Null results in both methods. At hardware level I would say that they worked fine. As soon as I connected the seatalk signal, the LEDs would flash and the output of the optocoupler would repeat the signals at a lower voltage -above 13 Volts in seatalk and above 3 Volts at the output of the optocouplers.

I never saw any data entered into signal k or using the test script. I tried other GPIO pins instead of the 4 and nothing. Inversion connection, no inversion as well.  I also tried the simplest method using the transistor, in my case a BC547 which is also NPN and runs at a very similar voltage also with no results.

I still have to test the assembly of: https://github.com/Thomas-GeDaD/Seatalk1-Raspi-reader

[Image: connections.png]

But I have the impression that there is something about the software that escapes me and I do not know what it is. I have tested it on Openplotter32bit and Openplotter64 without any difference in the results. And I know that my seatalk network works well because I have a seayak to nmea0183 converter and it works fine.

I am totally baffled and tired. I suppose that my lack of results is due to chronograf that, to tell the truth, I did not even remember that it was installed and that by the way I do not know how to change port since the configuration in openplotter-dashboards takes me to localhost:8888 but there is nothing in such place.  Although a port scan tells me that:
8888/tcp open sun-answerbook
...but I don't know if is talking about cronograf or gpiod using that port right now.
Reply
#13
(2020-08-08, 09:13 PM)monos1 Wrote: Well, the truth is that I have spent a whole day trying to make the invention of seatalk to Signal K work and I must confess that my results have been null......
Seems to be a software problem, not hardware. Checking the log with for example  "cat /var/log/syslog" should give some hints. Another way, to isolate the problem, is doing a fresh install with just SignalK and the mentioned SeaTalk software, nothing else.
________________________________________

Blog; https://pysselilivet.blogspot.com/
Reply
#14
the Signal K server log could help too
Reply
#15
sun-answerbook is a deprecated program that probably you do not have installed but linux will always return that no matter what program is using 8888 port. Uninstall chronograf from openplotter-dashboard app to clear 8888 port, try again and check sys log and signal k log.
Reply
#16
I already checked. It doesn't matter which of the two services uses port 8888 that the nmap scan will give the same diagnosis.

When I get to the ship, I'll resume testing. I'll try to stop the chronograph service by hand and start pigpiod to see if it works. I will also take two virgin 32 and 64 bit OP versions to test.

I'm especially interested in checking the second circuit as it incorporates the resistance - although of a value of 10k, I don't know if it will work as it is - and the third connector for 3.3V+:

[Image: HTB1nN64MVXXXXbQXXXXq6xXFXXXJ.jpg]

It would be easy to use for dummies who are the ones who most require a method as easy as possible to do things.
Reply
#17
(2020-08-10, 11:58 AM)monos1 Wrote: I already checked. It doesn't matter which of the two services uses port 8888 that the nmap scan will give the same diagnosis.

When I get to the ship, I'll resume testing. I'll try to stop the chronograph service by hand and start pigpiod to see if it works. I will also take two virgin 32 and 64 bit OP versions to test.

You can change the port chronograf starts on by editing the file /lib/systemd/system/chronograf.service and restarting the service.

 cat /lib/systemd/system/chronograf.service
# If you modify this, please also make sure to edit init.sh

[Unit]
Description=Open source monitoring and visualization UI for the entire TICK stac                                                                   k.
Documentation="https://www.influxdata.com/time-series-platform/chronograf/"
After=network-online.target

[Service]
User=chronograf
Group=chronograf
Environment="HOST=0.0.0.0"
Environment="PORT=8889"
Environment="BOLT_PATH=/var/lib/chronograf/chronograf-v1.db"
Environment="CANNED_PATH=/usr/share/chronograf/canned"
Environment="PROTOBOARDS_PATH=/usr/share/chronograf/protoboards"
EnvironmentFile=-/etc/default/chronograf
ExecStart=/usr/bin/chronograf $CHRONOGRAF_OPTS
KillMode=control-group
Restart=on-failure

[Install]
WantedBy=multi-user.target
Reply
#18
(2020-08-10, 11:58 AM)monos1 Wrote: I already checked. It doesn't matter which of the two services uses..............
The 10k resistor will not be a problem. On the other hand the input with 470 Ohm resistor, if circuit diagram is right(LED is missing), will make a heavier load than I have used, 3k. But if the ST 1 devices still works ... 
To check the daemon, after setup, use "sudo systemctl status pigpiod" as stated in the documentation.
________________________________________

Blog; https://pysselilivet.blogspot.com/
Reply
#19
As MatsA commented, the input resistance is not sufficient and saturates the optocoupler emitter. I have to put a resistor in the Seatalk input to use the circuit I like. I used a 10k resistor. For the other circuit it is not necessary but the resistance at the output is not built in.

On the other hand, it has only worked for me in a clean openplotter installation. Only with stopping the chronograf service it didn't work with stability. Another unexplainable problem that I have found is that I have seen wind, direction and speed sentences. Also water temperature, but no water depth. In the script I think they were, which points out that it could be a mistake in the implementation and translation to signal K.

It doesn't work at all on openplotter64 I think because of the differences in the python versions.

Another important issue is that when the system works, pigpiod takes 100% of the process of one of the 4 processors of the rpi. I don't know if I would be willing to give up so much processing power just for seatalk.
Reply
#20
The seatalk to $stalk parser strips the beginning 0.

So the 00 02 YZ XX XX Depth below transducer is translated to a single 0 instead of 00. Thus no depth input.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)