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
SKfilter and NMEA0183 out
#11
That's what I was thinking originally, but what I understood from esailing was that NMEA was a straight pass-through. Regardless, it didn't work.
Reply
#12
(2020-09-02, 05:08 PM)abarrow Wrote: That's what I was thinking originally, but what I understood from esailing was that NMEA was a straight pass-through. Regardless, it didn't work.

That's odd, I just tried it on a connection where node red sends dummy  MWV data to a signalk UDP connection, put MWV in the ignored sentence box and the sentence didn't get passed through.
Reply
#13
Okay, I guess I'll try it again. I thought I was seeing it in the diagnostics.

We try again! Thanks.
Reply
#14
You could also ask in Slack - way easier to get timely answers.

Then again, testing it with a bit of node-RED works also...

"Ignored Sentences" is implemented early in the SK server's processing pipeline, prior to sending non-parsed NMEA0183 lines out to tcp 10110.
Reply
#15
Thanks Teppo. I tried again today, and was able to get what it needed through a combination of Ignored Sentences and the use of the SK to UDP plugin. One suggestion: if possible, it would be very helpful to have the UDP plugin respond to other sentences than just nmea0183 and nmea0183out.

Of course, just as I was getting things working, it got so hot below decks on my boat (35 degrees) that my RPI started getting really flaky, and finally just refused to boot, even after pointing a fan directly on it. I've been having problems with OpenCPN not shutting down without being forced, and it seems to be getting worse. If trying it again after everything cools off doesn't fix the problem, I think a new RPI is in my future.

Thanks for all your hard work in SK. You have helped us greatly.
Reply
#16
Maybe add an issue for that in https://github.com/tkurki/udp-nmea-plugin/issues
Reply
#17
Done. Thanks.
Reply
#18
Done in version 1.2.0, give it a go.
Reply
#19
(2020-08-28, 08:28 PM)abarrow Wrote: Hi all,
I've been working with SKFilter to eliminate some faulty HDM data coming from one of my sensors. I was finally able to filter out the incoming string, and my nav station display is working well.

I have exactly the same problem. From seatalk I get incorrect HDM data and the correct HDM data from the imu is messed up but I was unable to filter out the incorrect signal k sentence.

could you please explain in detail how you did this?
Reply
#20
I depends on how you are getting your SeaTalk data, but generally I filtered incoming data using a combination of settings in the Server connection and SKFilter. I found two issues: The major one was the heading sensor in my Calypso wind sensor was about 70 degrees off. In that case, I just put "HDM" in as the string that I wanted that port to ignore. That's in the Server - Connection settings. The other weird problem was that my magnetic deviation was going from zero to like 10 degrees. Using SKFilter, I was able to tell the SignalK server to ignore that key. It took me a while to get the right combination of source in the SKFilter app.

I think I'd need to know a little more about your setup.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)