Folks:
My Raspi 4 is extended with a pican-m HAT. Connection to NMEA2000 - send and receice - is working well. I am struggling with connecting to my Standard Horizon GX-2100 vhf to send position and SOG using the rs422 screw connector of the pican-m.
Everything seams to work fine but the GX-2100 does not recognize the data.
I am using the signalk-to-nmea0183 plug-in to and selected to send GLL, GGA and RMC sentences. These sentences originate from OpenCPN where a UDP Connection is used to transfer them to signal-k. The data can be seen in the signal-k serial stream log and can be captured from from my windows-pc when I conncet it to the rs422 screw connector instead of the vhf.
The "strange" behaviour is, that the NMEA sentences are received in chunks of exactly 512 bytes with a 5 seconds delay between them. This implies that the last sentence is never complete unless the 512 byte chunk directly ends after the sentences cr+lf characters.
I would expect that the pc receives the data "as sent" without delay and without cut in chunks and I wonder if this is the reason for my problem. Does the GX-2100 drop the received data when the last sentence of a chunk is incomplete?
Question: How can I convince the Raspi/pican HAT to sent every sentence immediatly after it was emitted by signal-k?
Best Regards
Michael
Interesting as I have a GX-2100 and have not been able to get the GPS in to work, nor the AIS out to happen in a similar configuration. Hoping to see an answer on the chunking.
Just out of curiosity, what happens when you plug that RS422 converter back into your PI and look at that port? You could do it with "cat /dev/tty<whatever the port is>". The reason I ask is that I"m wondering if the chunking you are seeing is actually a Windows thing rather than the data coming out of the SignalK server.
(2021-06-10, 04:09 PM)abarrow Wrote: [ -> ]Just out of curiosity, what happens when you plug that RS422 converter back into your PI and look at that port? You could do it with "cat /dev/tty<whatever the port is>". The reason I ask is that I"m wondering if the chunking you are seeing is actually a Windows thing rather than the data coming out of the SignalK server.
Keen idea, but I do not have any more serial ports available.
I believe it has to do with some send buffer size configuration.
The same happens when I create a serial connection directly in openCPN.
Do both programs simply do not flush the send buffer after each sentence?
But can that be? Serial communication might be relatively new to signal-k but its mature in openCPN.
(2021-06-10, 04:09 PM)abarrow Wrote: [ -> ]Just out of curiosity, what happens when you plug that RS422 converter back into your PI and look at that port? You could do it with "cat /dev/tty<whatever the port is>". The reason I ask is that I"m wondering if the chunking you are seeing is actually a Windows thing rather than the data coming out of the SignalK server.
You are perfectly right. The problem is was Windows the type command. I switched over to putty and I am getting the sentences line by line as expected.
Conclusion: Do not use "type com1" to test anything on Windows serial ports.
But the question still is: What is wrong with the GX-2100?
(2021-06-10, 03:57 PM)SailAlpha Wrote: [ -> ]Interesting as I have a GX-2100 and have not been able to get the GPS in to work, nor the AIS out to happen in a similar configuration. Hoping to see an answer on the chunking.
SailAlpha:
It's all up an running. How that? Here is the story:
At Standard Horizon they have at least one color-blind production worker: The documentation says the calble coded green is ground, the blue one is nmea in+. On my one these calbles are inverted (blue = ground, green = in+). That's why the correct sentences emitted by signal-k have not been read - in my case.
Have you tried this?
Best regards
Michael
Same issue with the GX2000. I have a Digital Yacht NMEA0183 USB cable, which works fine. When I remove it and connect the radio to the Pican-M, it doesn't work. I have sent some 0183 data back into the pican-m and it does receive, although it's all garbled.
I'm wondering if there is an issue with some drivers. I have a Renogy Commander USB connection that is slightly temperamental. It's plugged into a USB hat and doesn't play very well with others. For now, I've reinstalled the YD usb cable and everything else works great. Pican-M N2K is fast!
This question appeared on Slack and the suggestion is that the Standard Horizon uses TTL instead of RS422. In which case, the Pican-M will probably never work for this purpose, at least now without a converter to match the ground referenced data to differential data protocol. There are converters out there, but I just hooked mine back up to my Digital Yachts NMEA0183 to USB adapter (which must use TTL the radio expects) and everything continues.
(2022-07-02, 05:58 PM)SCarns Wrote: [ -> ]I still look at this periodically. Standard Horizon didn't "mislabel" anything, they just use rs232 instead of rs422. I found this info regarding this: https://copperhilltech.com/blog/testing-...pberry-pi/
and this regarding proper rs232-to-rs422 wiring: https://stratusengineering.com/rs232-rs4...ics-power/
However, I still don't have this working yet. I hope to try again soon.
My GX2000 is working properly with a RS422 to USB connector. the wiring is inverted RX+ to RX- etc. but it is working fine. I have Maiana connected up as well to give AIS - it works awesomely
and I have the GX2000 external Speaker out connected into a USB sound card on the Pi, then the USB sound card Output connected to the boat stereo to hear VHF over the boat speakers.
See:
https://youtu.be/KSLpdpwWujo