Closed dagnall53 closed 1 month ago
Hello dagnall53,
Everything with N2k is a bit difficult with OpenCPN. I don't have an EVO autopilot and therefore can't test it in real operation. Without reports from users telling me possible errors, I can't correct anything. The N2k messages cannot be viewed in OpenCPN. To view the messages, assemble the following part: https://github.com/ttlappalainen/NMEA2000/tree/master/Examples/ActisenseListenerSender and connect the serial port. Or ... send virtually internally on the PC. OPENCPN (SerialPort with NMEA2000)<-> com0com <-> hub4com <-> com0com -> virtual serial port -> ActsenseReader (all free PC software) https://actisense.com/nmea-software/
Thanks for an amazingly quick response!! I think that OPCN not showing any N2K in the debug window is a huge error on their part and something that needs correction ASAP. It makes debugging any N2K comms impossible. You may also note that I am "Scubacat" on Cruiser forum ( https://www.cruisersforum.com/forums/f134/nmea-2000-over-wifi-282755.html#post3931022 ) (Rant over!)
(Simple) Question: Would you expect your plugin to send the keystroke PGN "out" even if there was no AP detected in the network? I have looked at the code and am unsure if the sendN2K needs to see an Autopilot related PGN first??.
Some FYI, and stuff about me..
I actually already have an ESP32 version of the TL Listner/sender on my desk that allows me to monitor my desk top boat test setup. This sends the binary actisense RAW via USB and I already use the Actisense NMEA reader to monitor N2K traffic. I often use OCPN (windows) to check stuff out.
I presume you know that the Actisense reader uses the Binary RAW format ?. That format is OK for serial links, but unsuitable for sending over UDP/TCP, so I much prefer the N2KASCII or PCDIN formats for sending "N2K" over UDP / TCP. It seems that OCPN is now supporting these in the most recent updates, although they do seem to have issues with sending! That part of how OCPN tries to send N2K and how it selects which RAW format to use is opaque to me.
My interest is because I have been using the TL libraries (plus other stuff) to help write the code (unpaid) for the N2K0183 WIFI gateway https://www.vela-navega.com/index.php/n2k0183. The users of this seem to use OCPN a lot! (Luis and I do this mainly as a retirement hobby, he sells the boards, my 'payment' is the development fun). So, for the past year or so I have had a test setup with a fake boat (using the TL instrument simulation) and two of the N2K0183 on my desk so I can test for correct conversions 0183 <>N2K and develop the code. All N2K<>0183 for most situations work well. And the RAW formats allow N2K from suitable programs to generate / send any and all N2K pgn.
Like you, we rely on user feedback! A recent user was asking for "Wireless" control of his AP modes (Engagement in OPCN speak). But we discovered that your plugin was apparently not sending any N2K (raw) PGN for the gateway to build the real canbus PGNs. I think this is probably a OCPN issue somehow blocking you, but I think you can now see where I am "coming from" with my question.
Also FYI: I have a (old) Raymarine smartpilot AP on my boat that I control using $STALK. and I have used it to try to test N2K, but it refuses to respond to any N2K at all!! After much trying I have concluded that it can only receive either St1 OR STng and because the control head is ST1, it only "sends" N2K, but will not "receive" STng data.. This is Very Frustrating!
So going back to first principles, I wanted to see the PGNs sent by your plugin! (which brings me back to the question at the start)
All the very best
Dagnall
On Wed, 4 Sept 2024 at 11:38, Bernd Cirotzki @.***> wrote:
Hello dagnall53,
Everything with N2k is a bit difficult with OpenCPN. I don't have an EVO autopilot and therefore can't test it in real operation. Without reports from users telling me possible errors, I can't correct anything. The N2k messages cannot be viewed in OpenCPN. To view the messages, assemble the following part:
https://github.com/ttlappalainen/NMEA2000/tree/master/Examples/ActisenseListenerSender and connect the serial port. Or ... send virtually internally on the PC. OPENCPN (SerialPort with NMEA2000)<-> com0com <-> hub4com <-> com0com -> virtual serial port -> ActsenseReader (all free PC software) https://actisense.com/nmea-software/
— Reply to this email directly, view it on GitHub https://github.com/BerndCirotzki/raymarine_autopilot_pi/issues/34#issuecomment-2328527235, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVA5IGQPCMJIOTS3VELNXDZU3PJZAVCNFSM6AAAAABNT7NBZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRYGUZDOMRTGU . You are receiving this because you authored the thread.Message ID: @.***>
(Simple) Question: Would you expect your plugin to send the keystroke PGN "out" even if there was no AP detected in the network? .... Oh it's so long ago .... but I think "standy" and "auto" is send but +1,-1,+10,-10 not. Take a look ...
Ok, I see you have enough test equipment. Im using OpenCPN only with NNMEA0183 over serial. I think N2k is not realy ready developed. So I developed my own translater(ESP32). from NMEA0183 to N2k and to Seatalk and ... back. (Including AIS). So I only have one connection to OCPN. So I can translate everthing to everything and have no problems. ... to your cruiserforun : the PGN ... for active Route I translate in my translater from RMB, APB, XTE sentence to the N2k PGN (and to Seatalk1). But I have a problem with that what OCPN is doing : https://github.com/OpenCPN/OpenCPN/issues/4103
(OPENCPN in not sending out N2k Messages when a route is active. How I mean, there are not ready yet.)
Here are some test N2k messages in actesense format for testing. send them (for ex .with hterm) to OPENCPN serial NMEA2000 an see what the Autopilot plugin is doing. Binary NMEA2000 messages.zip
and for sending the Heading, COG, SOG in N2k Format use "the NMEA Simulator" virtuel and conect to an second COM.
Thanks again. I agree totally that OCPN is not really N2K ready yet. It should send out route PGN just like it sends 0183 !
Interesting that you have been working ST1 to N2K.. Luis and I have Seatalk1<>0183 as the NMEA3WIFI and that includes a hidden Webpage that sends $STALK so one can test if the AP responds to Seatalk1. (it does!) But I did not want to do the same with the N2KWIFI device as the webpage was not that reliable.
I DID wonder if I should / could translate the $STALK to PGN 126720 (for just auto / stby track/ +- 1/10) but was reluctant to mix the protocols like that! I can translate $PCDIN to N2K so if your plugin had the option to send "0183" $PCDIN raw N2K that might work- but would be counter intuitive for most people. I do not have sufficient knowledge / talent to rewrite your plugin to send $PCDIN instead of $STALK .
I see the zip file has the data in that dreadful binary format! How do you use it/them ?
Luis wrote a sort of universal serial UDP TCP program that we use for testing. It can send / receive ASCII - so if you send the correct (ASCII based) RAW, it "sends" N2K pgn when sent to the gateway.. But not the Binary Raw.. I was going to send a zip with it but GMail refused to send it as a "dangerous attachment".
Cheers D
On Wed, 4 Sept 2024 at 13:19, Bernd Cirotzki @.***> wrote:
(Simple) Question: Would you expect your plugin to send the keystroke PGN "out" even if there was no AP detected in the network? .... Oh it's so long ago .... but I think "standy" and "auto" is send but +1,-1,+10,-10 not. Take a look ...
Ok, I see you have enough test equipment. Im using OpenCPN only with NNMEA0183 over serial. I think N2k is not realy ready developed. So I developed my own translater(ESP32). from NMEA0183 to N2k and to Seatalk and ... back. (Including AIS). So I only have one connection to OCPN. So I can translate everthing to everything and have no problems. ... to your cruiserforun : the PGN ... for active Route I translate in my translater from RMB, APB, XTE sentence to the N2k PGN (and to Seatalk1). But I have a problem with that what OCPN is doing : OpenCPN/OpenCPN#4103 https://github.com/OpenCPN/OpenCPN/issues/4103
(OPENCPN in not sending out N2k Messages when a route is active. How I mean, there are not ready yet.)
Here are some test N2k messages in actesense format for testing. send them (for ex .with hterm) to OPENCPN serial NMEA2000 an see what the Autopilot plugin is doing. Binary NMEA2000 messages.zip https://github.com/user-attachments/files/16870063/Binary.NMEA2000.messages.zip
and for sending the Heading, COG, SOG in N2k Format use "the NMEA Simulator" virtuel and conect to an second COM.
— Reply to this email directly, view it on GitHub https://github.com/BerndCirotzki/raymarine_autopilot_pi/issues/34#issuecomment-2328828605, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVA5IFDK4E7VKDXBW3UV53ZU33E3AVCNFSM6AAAAABNT7NBZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRYHAZDQNRQGU . You are receiving this because you authored the thread.Message ID: @.***>
Send the data out as binary with the free program "hterm" to a virtual COM to Opencpn using com0com and hub4com for virtual loop on the PC. Input in opencpn or in ActsenseReader as Nmea2000 data input.
04.09.2024 15:26:06 dagnall @.***>:
Thanks again. I agree totally that OCPN is not really N2K ready yet. It should send out route PGN just like it sends 0183 !
Interesting that you have been working ST1 to N2K.. Luis and I have Seatalk1<>0183 as the NMEA3WIFI and that includes a hidden Webpage that sends $STALK so one can test if the AP responds to Seatalk1. (it does!) But I did not want to do the same with the N2KWIFI device as the webpage was not that reliable.
I DID wonder if I should / could translate the $STALK to PGN 126720 (for just auto / stby track/ +- 1/10) but was reluctant to mix the protocols like that! I can translate $PCDIN to N2K so if your plugin had the option to send "0183" $PCDIN raw N2K that might work- but would be counter intuitive for most people. I do not have sufficient knowledge / talent to rewrite your plugin to send $PCDIN instead of $STALK .
I see the zip file has the data in that dreadful binary format! How do you use it/them ?
Luis wrote a sort of universal serial UDP TCP program that we use for testing. It can send / receive ASCII - so if you send the correct (ASCII based) RAW, it "sends" N2K pgn when sent to the gateway.. But not the Binary Raw.. I was going to send a zip with it but GMail refused to send it as a "dangerous attachment".
Cheers D
On Wed, 4 Sept 2024 at 13:19, Bernd Cirotzki @.***> wrote:
(Simple) Question: Would you expect your plugin to send the keystroke PGN "out" even if there was no AP detected in the network? .... Oh it's so long ago .... but I think "standy" and "auto" is send but +1,-1,+10,-10 not. Take a look ...
Ok, I see you have enough test equipment. Im using OpenCPN only with NNMEA0183 over serial. I think N2k is not realy ready developed. So I developed my own translater(ESP32). from NMEA0183 to N2k and to Seatalk and ... back. (Including AIS). So I only have one connection to OCPN. So I can translate everthing to everything and have no problems. ... to your cruiserforun : the PGN ... for active Route I translate in my translater from RMB, APB, XTE sentence to the N2k PGN (and to Seatalk1). But I have a problem with that what OCPN is doing : OpenCPN/OpenCPN#4103 https://github.com/OpenCPN/OpenCPN/issues/4103
(OPENCPN in not sending out N2k Messages when a route is active. How I mean, there are not ready yet.)
Here are some test N2k messages in actesense format for testing. send them (for ex .with hterm) to OPENCPN serial NMEA2000 an see what the Autopilot plugin is doing. Binary NMEA2000 messages.zip https://github.com/user-attachments/files/16870063/Binary.NMEA2000.messages.zip
and for sending the Heading, COG, SOG in N2k Format use "the NMEA Simulator" virtuel and conect to an second COM.
— Reply to this email directly, view it on GitHub https://github.com/BerndCirotzki/raymarine_autopilot_pi/issues/34#issuecomment-2328828605, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVA5IFDK4E7VKDXBW3UV53ZU33E3AVCNFSM6AAAAABNT7NBZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRYHAZDQNRQGU . You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub[https://github.com/BerndCirotzki/raymarine_autopilot_pi/issues/34#issuecomment-2329045724], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AHU3PHGRTDSBX5FMJ7YENOTZU4C6VAVCNFSM6AAAAABNT7NBZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRZGA2DKNZSGQ]. You are receiving this because you commented. [Verfolgungsbild][https://github.com/notifications/beacon/AHU3PHELHPEUVU27L7G6XFLZU4C6VA5CNFSM6AAAAABNT7NBZWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUK2JVNY.gif]
Hello dagnall,
I'm having a bit of trouble understanding what you want. So I had to read twice. This is probably because you are trying to translate Portuguese into English and I am doing the same with German.
I took a look at your website and think I understand what it's about. You sell your translators that use NMEA0183 as an interface to PC (Opencpn) and not a binary interface to OpenCPN NMEA2000. But in order to use a Raymarine EVO autopilot using my plugin, you want the plugin send and receive $PCDIN (N2K Data in NMEA0183 ASCII format). The idea isn't a bad one. But how you see here on Github, I have no response if it works with the EVO or if anyone uses it. I thing I could occupy on it in the german winter and I think this would work immediately with OpenCPN. One strenuous thing for me is the communication with the making public via the OpenCPN developers.
However, since you sell your translators, expanding the plugin would be a financial gain for you. Participation would be appropriate in this case. I had also sold my translator before, just not industrially manufactured. In this respect, it might make more sense not to necessarily talk over Github in order to make the plugin compatible with your hardware.
By the way, I wrote an APP for Android with which you can control the Seatalk1 autopilots via (serial) WiFi or Bluetooth via my translator. However, I think it's a pointless toy. But there seem to be people who want something like that. The old Raymarine autopilots (s1, S2 ...) cannot do N2k (SeatalkNG) so everything would stay the same.
Best regards Bernd
HI..(again).Im actually English, but Luis is Portugese!.Luis’s business is more something to support fellow DIY sailors than a “big business”. If you have already tried selling multiplexers you will be familiar with the economics. (I’m not paid, and just do this for fun.) Making a N2K version was my idea, so I am afraid I am to blame. We thought that the N2K018 hardware would be useful for experimenters. - It will run the TL ESP32 example codes - although you need to specify different Canbus pinouts as we made a mistake in the layout! You are correct that Luis’s multiplexers all convert to 0183 for ‘multiplexing’. So the standard OCPN 0183 messaging works very well for 90% of users. We use one of three RAW formats (but NOT binary) to be able to send ANY other ‘n2k PGN’ through the multiplexer without converting to 0183 messages. - but this does need the source to build the messages! I had not realised that you have had no feedback about the ‘EVO’ option for your plugin. That is a pity. Im glad for your feedback about S1/S2 Raymarine as it confirms my understanding! That explains my S1 ‘s behaviour and not accepting N2K inputs.There are a number of Apps available that can control AP via use of the $STALK commands and by replicating the keypad keystrokes. NavCenter is one that I have used which allows me to control the AP from my Iwatch. (NavCenter sends the AP commands as either $STALK for ST1 AP or $PCDIN for N2k AP). There is also MidWiFi. I agree the wireless AP remote control aspect is a toy.. But it is something that more users of the N2K0183 seem to want. ! I believe that all commercial gateways for Seatalk1 include the $STALK message - as we do with NMEA3WIFI. I think the (expensive) commercial N2000 gateways use either N2KASCII, PCDIN or Actisense(Text) Raw formats depending on who makes the gateway. Our N2k0183 gateway allows selection of any one of these. OCPN currently accepts many RAW formats, and I think its supposed to be able to send in RAW (selecting the same as it ‘sees’) - but since It does not seem to send anything with the current version, it is difficult to check.The logic of when to send RAW and when to send converted 0183 is actually quite complex, so if you were to modify the AP plugin code to send $PCDIN RAW, then at least two commercial gateways would be able to use it. A better option would be to have selection to send any of the RAW formats (as 0183). Unfortunately, this will still need user feedback to check if it works!! But none of this is going to be money-making I’m afraid! Sent from my iPadOn 4 Sep 2024, at 17:14, Bernd Cirotzki @.***> wrote: Hello dagnall, I'm having a bit of trouble understanding what you want. So I had to read twice. This is probably because you are trying to translate Portuguese into English and I am doing the same with German. I took a look at your website and think I understand what it's about. You sell your translators that use NMEA0183 as an interface to PC (Opencpn) and not a binary interface to OpenCPN NMEA2000. But in order to use a Raymarine EVO autopilot using my plugin, you want the plugin send and receive $PCDIN (N2K Data in NMEA0183 ASCII format). The idea isn't a bad one. But how you see here on Github, I have no response if it works with the EVO or if anyone uses it. I thing I could occupy on it in the german winter and I think this would work immediately with OpenCPN. One strenuous thing for me is the communication with the making public via the OpenCPN developers. However, since you sell your translators, expanding the plugin would be a financial gain for you. Participation would be appropriate in this case. I had also sold my translator before, just not industrially manufactured. In this respect, it might make more sense not to necessarily talk over Github in order to make the plugin compatible with your hardware. By the way, I wrote an APP for Android with which you can control the Seatalk1 autopilots via (serial) WiFi or Bluetooth via my translator. However, I think it's a pointless toy. But there seem to be people who want something like that. The old Raymarine autopilots (s1, S2 ...) cannot do N2k (SeatalkNG) so everything would stay the same. Best regards Bernd
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Made an Update to $PCDIN ... for You ! Test it and have fun Best regards Bernd
Bernd. To save me reading the code.. ( ;-) ). How did you make PCDIN send the address of the Autopiot as the Destination — I thought PCDIN only included the Source Address. !! Since writing I have discovered that RM AP ONLY accept N2000 commands if they are addressed DIRECTLY at them. (Sensible really!! ) Therfore it is technically impossible for PCDIN type messages to be translated to RM AP N2000 commands that will actually work! (Which explains a lot!!).
UNLIKE “N2KASCII” RawN2K messages, These DO contain both source and dest data, and so CAN be directed to the correct AP!..
(Sorry for not updating the comment earlier when I found out about this! - I had forgotten about asking you!)
I think there are some other Raw formats that also include both Source and Dest, they would also work.!!
Oh, yes, I think you're right. I did not know this. OpenCPN, I think, there is no way not get the device Information. But when your direct connected to the N2k CAN with your ESP32, you can get the destination address, by using "tN2kDeviceList" and send all known EVO PGNs with the address of the EVO you get by this way. By default, send with address 204. I think this would be very simple in the ESP32.
uint8_t GetEVOPilotAdress() { uint8_t Adress = 204;
if (pN2kDeviceList == 0) { if (0 == (pN2kDeviceList = new tN2kDeviceList(pNMEA2000))) return Adress; } if (!pN2kDeviceList->ReadResetIsListUpdated()) { if (pN2kDeviceList != 0) delete pN2kDeviceList; pN2kDeviceList = 0; return Adress; } for (uint8_t i = 0; i < N2kMaxBusDevices; i++) { tNMEA2000::tDevice device = (tNMEA2000::tDevice) pN2kDeviceList->FindDeviceBySource(i); if ( device == 0 ) continue;
if (strstr(device->GetModelVersion(), "EV-1") != NULL ||
strstr(device->GetModelVersion(), "SPX") != NULL )
{
Adress = device->GetSource();
break;
}
} return Adress; }
uint8_t GetDestinationAddress(unsigned long PGN) { // Raymarine EVO PGN uint8_t RV = 255;
switch(PGN)
{
case 126720:
case 126208: RV = GetEVOPilotAdress();
break;
}
return RV;
}
void HandleDIN(const typeNMEA0183Msg &NMEA0183Msg) { tN2kMsg N2kMsg; char buffer[MAX_NMEA0183_MSG_BUF_LEN]; uint32_t t = millis();
if(!NMEA0183Msg.GetMessage(buffer, MAX_NMEA0183_MSG_BUF_LEN))
return;
if(SeasmartToN2k(buffer, t, N2kMsg))
{
N2kMsg.Destination = GetDestinationAddress(N2kMsg.PGN);
pNMEA2000->SendMsg(N2kMsg);
}
}
I might be missing something important, but the “ESP32” multiplexer will (and can only!) convert messages sent to it in a suitable RAW format. The issue is not really how one might fake PCDIN to send to a RM AP, but is simply to make sure that the command is sent correctly to the RM AP in the first place usibg a RAW format that supports destination.
Since your program is an OCPN addin, you can ask the netework for the device list - but you have to use N2KASCII format (or similarly capable) to do this, so that you can define the subsequent destination data for AP commands. _ I had assumed you did this already? - Or the plug in cannot work.
You are correct that a specially modified multiplexer could internally check for RM AP presence and then FAKE the destination address into any PCDIN send AP commands. But this would not be a general solution and would open the multiplexer to multiple possible ‘bad situations’ where this Faking could intefere with other legitimate N2000 PGNS and device operation. FYI I have tested this “solution” previously with a very simple network, where the AP self reported as Address 0. (!) It failed to accept commands on this address!
The only real universal solution is to use a RAW format such as N2KASCII. (And for the plug in to determine the AP address!). I would forget PCDIN completely!! Its just a confusion with no real use in this application.
Ok, then even not. OpenCPN does not know N2kASCII. It's a little bit like "signalk". Again someone who comes up with a new protocol. You must not do it. I don't need it. I found the Idea not so bad. And it works. Now you have the chance to develope it into your Translater and be tho only one how can do. Or let it be. for me it's totally irrelevant.
Thanks for a good plugin. It works well with $Stalk 0183 outputs, and I can see the reaction to any keypress in the communications debug window.
However, experimenting with the N2000 elements I have run into difficulties and cannot see any "action" either on the N2K network (UDP and TCP connected) or in the debug window. Is the output 'gated' in some way to only work if it gets/sees some AP related data? - in my test situation I do not have an actual AP present. - "$Stalk" sends regardless of AP presence. I would have expected PGNs to be generated in the same way when EVO mode selected? - Are you trying to send to a specific destination? only when you know the AP destination number??/ - Can you add an option to send to broadcast dest (255) for testing?
With the new inclusion of N2000 WIFI UDP/TCP - OCPN now (apparently) auto selects which RAW format it will use to send N2k over UDP/TCP. (although you may follow https://www.cruisersforum.com/forums/newreply.php?do=postreply&t=282755 and note that currently it does not look like OCPN actually sends anything 'N2K' out at all! (But Im sure that will soon be fixed). So I also wonder if it might it be necessary (beneficial?) for you to have a selector for which N2K RAW type you will use to send to the "N2000 OUT" wifi ports (I would prefer N2KASCII or PCDIN RAW formats!).
Cheers D