How to Transmit to Autopilot on COM40 ?

[RhythmDoctor]

Originally Posted by ON3CHD

Hi Dave,
To answer your question NO Open CPN does not send back the road info to the MUX.
In other words the Autopilot doesn·t receive the road info Open CPN should have sent back to steer the boat.
Have not checked logfiles and will do on an other occasion...

Does OpenCPN keep log files of NMEA communications? Where?

I went to the boat this evening for a quick test. It does appear that the Autopilot is not getting the NMEA sentences. OpenCPN is receiving AIS@38400 on COM40 and GPS@4800 on COM41. It's set to send to Autopilot on COM41 but not working. I need to go back and hardwire the connection to determine whether it's a Bluetooth problem or an OpenCPN problem.

ON3CHD - Does your Autopilot accept NMEA @ 38400? Mine only takes 4800, and from your description it sounds like you might be sending to the Autopilot at 38400.

[bdbcat]

ON3CHD....

RhythmDoctor makes a good point. A COM port can only be set for one baud rate. If the port is to be used for AIS, it will be set for 38KB.

In any event, OCPN Ver 2.3.1 does not support autopilot output to the AIS port. I think I coded it this way for precisely RhythmDoctor's reason. I know of no autopilot that can accept 38KB data.

FYI, the NMEA messages sent to the autopilot by OCPN 2.3 are $ECRMB... only.

The whole area of port management, sentence selection and multiplexing, etc. needs more work in OCPN. We need to generalize all possibilities, and build some dialogs to accommodate the wide variety of real life scenarios.

Volunteers, anyone?

Thanks
Dave

[ON3CHD]

Originally Posted by RhythmDoctor

Does OpenCPN keep log files of NMEA communications? ...
ON3CHD - Does your Autopilot accept NMEA @ 38400? Mine only takes 4800, and from your description it sounds like you might be sending to the Autopilot at 38400.

Hi ,
About log files don·t know yet. Will have to check If and When.
About autopilot of course NOT.
But that is all about what a MUX is for.
Brookhouse is making an excellent description of it·s product on the WWW.
Open CPN should send back the ROUTE info on the choosen channel ( 5 in my case) at 38400 bds to the MUX which is now becoming a LISTENER and a NMEA speed data transformer.
It is the MUX which is converting the info received at 38400 bds to 4800 bds for "feeding up" a few listeners like an Autopilot, an SSB for DSC , a Tacktick NMEA interface, a VHF...
My MUX does accept up to 5 listeners in parallel on the same listener channel RS 422.
Hope this clarify.
Cheers.

[ON3CHD]

Originally Posted by bdbcat

ON3CHD....

RhythmDoctor makes a good point. A COM port can only be set for one baud rate. If the port is to be used for AIS, it will be set for 38KB.

In any event, OCPN Ver 2.3.1 does not support autopilot output to the AIS port. I think I coded it this way for precisely RhythmDoctor's reason. I know of no autopilot that can accept 38KB data.

FYI, the NMEA messages sent to the autopilot by OCPN 2.3 are $ECRMB... only.

The whole area of port management, sentence selection and multiplexing, etc. needs more work in OCPN. We need to generalize all possibilities, and build some dialogs to accommodate the wide variety of real life scenarios.

Volunteers, anyone?

Thanks
Dave

Hi Dave,
thanks fyr.
I thing that I understand your comment about COM PORT.
Hope my answer to RhythmDoctor will clarify as I appreciate that AIS com port should not be used to transmit info back to the autopilot.
NMEA sentence sent by Open CPN is now clear to me.
Unfortunately I am not a technician but just an old retired banker so my help is for sure limited.
I am ready however to communicate directly on this NMEA matter with any developper to clarify how my system works and what are my needs but I believe it should be done outside of this forum. Should you find it useful as it can help to understand better where to go let me know.
Cheers.

[CarCode]

Originally Posted by RhythmDoctor

I hope this problem does not apply to me. My integrated Bluetooth hardware is not supposed to be supported by the Microsoft stack. My INF folder does not even contain the bth.inf file. So there should be no Microsoft stack active - just the Toshiba stack.

I have to hedge a bit on this because in the process of trying to get OpenCPN to work with Bluetooth, I did some things to try to force the Microsoft stack to activate. I basically did manual file copies and edits that were the equivalent of the automated procedure shown in your link. I did get my Bluetooth working under the Microsoft stack, but the capabilities of the Microsoft stack were far inferior and less reliable vs. the Toshiba stack (and OpenCPN autopilot COM port still did not work), so I undid my changes by deleting out the files and cleaning out the registry. I think I cleared out all the remnants of the Microsoft stack.

But thanks for the tip - I will definitely keep an eye out to see if the Tosh stack gets "stuck." The only problem I have seen so far is that I have to manually reconnect every time my computer goes into Suspend. Other than that, the Toshiba stack has been highly reliable. But my boat is on the hard for the winter, so I have not yet been able to test all this out in a real-world situation.

Be very carefully while working with the Registry entries!

There are still enough problems with Windows and Bluetooth as well as with virtually Com ports which are needed for serial to USB devices. Anybody knows the list of COM ports in use that Windows reports even when no device is attached.

Microsoft introduced its own Bluetooth stack end of year 2002 with very poor supported Bluetooth profiles, only 3 profiles in 2002. There exists however more than 30 profiles for different tasks such as audio, network or serial transfer (SPP) which is the most interesting for us. End of the year 2003 Microsoft supported 12 profiles although not enough for the rising market of Bluetooth devices. So the Bluetooth manufacturers provides their own stack from Widcom or e.g. Toshiba.

Without notice to the users and even not to the manufacturers as usual by Microsoft they made severe and secret changes in service pack 2 for XP in end of year 2004 for Bluetooth. This results into not working Bluetooth stacks for most Bluetooth manufacturers. We have been surprised by user claims of our own devices then until we found out the reason. Later on all manufacturers updated their stacks. But there are still problems until today.

Some vague informations has the Microsoft Knowledge Base # 841799 and 841803.

Gerhard

[RhythmDoctor]

Thanks for clarifying your configuration. Either I missed it before, or you didn't say and I assumed wrong.

Originally Posted by ON3CHD

Hi ,
...About autopilot of course NOT.
But that is all about what a MUX is for...

Actually, this is not necessarily true. If the baud rate is correct, you do NOT need a multiplexer to split NMEA to multiple listeners. Each NMEA port is single talker, multiple listener (up to 3). You can send NMEA sentences out to multiple listeners without a mux. From your description apparently you have about 4 listeners, so you do need a repeater, and since your sentences are going out at 38400 you also need a baud converter, and your Brookhouse is acting in that capacity. But it is not actually multiplexing, since that is only needed for combining multiple talkers. If you had 3 or fewer listeners, and your baud rate was correct, you would not need the Brookhouse for your outgoing NMEA sentences. (You would need it for the incoming NMEA sentences, since NMEA is single talker.) That's why I said, "it sounds like you might be sending to the Autopilot at 38400."

[ON3CHD]

Hi,
Thanks very much fy comments and explanation.
As I am a poor ex banker and not a technician I probably miss some of your comments but anyway to be honest my only purpose is to have a working set up of which I am quite happy with for the time being and I would love to have it working also with OCPN.
You probably will find some additional info on my set up while reading some comments in red in your text.
It is my opinion however that they don·t add anything to what I have written before.

Originally Posted by RhythmDoctor

...From your description apparently you have about 4 listeners, In fact I have 5 listeners as one of them is a second BT transponder receiving and sending some NMEA sentences that I have filtered at the Talker level i.e. PC 1 to a second "moving" PC 2 on board so you do need a repeater, and since your sentences are going out at 38400 you also need a baud converter, and your Brookhouse is acting in that capacity. Correct But it is not actually multiplexing, since that is only needed for combining multiple talkers. As I have said in 2 posts of this thread I have 3 talkers of which 2 are sending at 4800 bauds and one at 38400 bauds.Is that not Multiplexing ? ...

Thanks again for any comment from which I might learn more.
Cheers.

[ON3CHD]

Originally Posted by CarCode

Be very carefully while working with the Registry entries!

There are still enough problems with Windows and Bluetooth as well as with virtually Com ports which are needed for serial to USB devices. Anybody knows the list of COM ports in use that Windows reports even when no device is attached...

Gerhard

Hi, just in case...

http://www.techimo.com/forum/technical-support/173194-how-remove-unused-drivers-windows-xp.html

Cheers.

[CarCode]

Yes, I know. Therefore my comment about this ugly Windows...
It is not user friendly.

Gerhard

[RhythmDoctor]

Originally Posted by ON3CHD

But it is not actually multiplexing, since that is only needed for combining multiple talkers. As I have said in 2 posts of this thread I have 3 talkers of which 2 are sending at 4800 bauds and one at 38400 bauds.Is that not Multiplexing ?.

It is not multiplexing OpenCPN's sentences that going to your Autopilot (and other devices) - it is just repeating and distributing those sentences. That is what I was referring to. It is be multiplexing the other signals going to OpenCPN.

[ON3CHD]

Originally Posted by RhythmDoctor

It is not multiplexing OpenCPN's sentences that going to your Autopilot (and other devices) - it is just repeating and distributing those sentences. That is what I was referring to. It is be multiplexing the other signals going to OpenCPN.

Got your point. Thank you.
Cheers.

[RhythmDoctor]

Here is an update on my problem transmitting OpenCPN data to my Autopilot via Bluetooth. I am providing it in hopes that it may help others who have a similar problem.

Today I went to the boat and used a USB-Serial converter (instead of Bluetooth) to connect to the GPS and Autopilot on COM3. With this configuration the Autopilot was successfully receiving XTE, BTW, DTW, etc., from OpenCPN.

Based on this I believe that the problem is with my Bluetooth adapter (most likely) or with transmitting over COM41 (less likely). I have a couple ideas for configuration changes that I will make to the Bluetooth adapter, but I did not have the right cable to try them out today. I will return to the boat in a few days with a null modem adapter and a second laptop to test this further.

[haydude]

Originally Posted by bdbcat

In any event, OCPN Ver 2.3.1 does not support autopilot output to the AIS port. I think I coded it this way for precisely RhythmDoctor's reason. I know of no autopilot that can accept 38KB data.

Thanks
Dave

Dave, I am afraid in your design you made the assumption that each instrument would have its own dedicated COM port. Most installations (like mine) make use of an NMEA multiplexer (Brookhouse in my case) and feed all the NMEA data (AIS + WIND + SPEED + GPS + Chartplotter) from one serial port. Therefore imposing a dedicated AIS configuration tab might be a design issue. Also imposing a 38400 AIS bps might be an issue when we use Serial Bluetooth dongles.

In my case I have a Brainboxes BL-819 Serial/Bluetooth bridge. The dongle is configured to match the bps rate of the serial device (38400 in my case), but then the emulated serial port can be configured at any bps.

In particular Brainboxes recommends that the bps of the virtual serial does not match the physical serial bps and it should be set to 115200 bps. This is a trick to avoid the device entering configuration mode when receiving the "magic" sequence from the serial end (which might be in a casual NMEA sentence). If there is a mismatch the device locks the configuration mode understanding that only serial operation pass-through is required. In my case since with OpenCPN I can only have 38400 bps, which is the same bps as the hardware serial, I had to disable permanently the BL-819 configuration mode.

[ON3CHD]

Originally Posted by haydudeTake4

...In my case since with OpenCPN I can only have 38400 bps, which is the same bps as the hardware...

Hello, it looks like if you are a user of OCPN.
I am also using Brookhouse MUX + BT RS 232 Dongle to transmit and receive data to and from PC. My autopilet is connected to the RS 422.
Did you ever manage to send road info from OCPN to your autopilot via your MUX and if yes I would veruy much appreciate to know how you did it?
Thanks.
Cheers.

[haydude]

Well in the case of OpenCPN I am afraid I cannot even receive the NMEA stream from serial Bluetooth, let alone sending it.