Onderwerp: COMpoort (NMEA) delen over meer toepassingen.

Miniplex heeft toch ook een nmea uitgang?
Op die uitgang kan je een aantal serial to usb converters aansluiten (die in een usb-hub zitten)
Zo heb je een boel compoorten met dezelfde info en kan elk programma gewoon een hardwarepoort pakken.

Op zich met com2com icm nmea router zou het moeten werken ik kon in het verleden gewoon extra compoorten aanmaken.
Maar kijk nu eens naar de TCP oplossing, TCP communiceert 2 kanten op en je kan het in meerdere programma's tegelijk gebruiken.
Nu heb je USB/COM en geen TCP maar dat kan nmea router weer voor je regelen.

Als je "multiplexer" dus gewoon een goede TCP verbinding zou hebben (dat hebben wij dus via wifi en nu ook via USB naar LAN) dan had je in alle programma's gewoon de TCP verbinding kunnen gebruiken.

Zeilprutser schreef :
Dat heeft hij (Miniplex 3 N2K USB Wifi).
Maar als de PC aan de wifi (TCP) van de mux hangt kan hij niet via de telefoon-hotspot aan internet hangen.
En dat moet ook, en nog wel tegelijk ook.
USB-kabel dus onvermijdelijk van mux naar PC.

Kan de miniplex niet als client aan een AP hangen?

It Paradyske schreef : Ik denk het wel. Maar dat is niet aan boord.

Mocht je wat willen proberen?

Ik ben helemaal onbekend met windows, maar in linux kan ik net zoveel netwerk/wifi adapters inpluggen als ik maar wil. Neem toch aan dat zoiets onder windhoos ook kan. Betekent wel dat je wat handmatig moet configuren wat IP adressen en www gateway betreft.

rooiedirk schreef :
Da's ook nog een optie ja, een tweede wifi-adapter. Die laat je connecten met de miniplex, geen gateway instellen voor die verbinding. Al het verkeer over die verbinding is lokaal.

De andere verbinding, via je ap op de telefoon krijgt wel een gateway, zodat extern verkeer daarlangs wordt geleid.

Alleen even opletten dat telefoon-ap en miniplex niet dezelfde ip-range gebruiken.

Kijk ook eens naar een router met 4G/5G ondersteuning en maak je eigen boordnetwerk. Dan kan je PC en op internet en via wifif naar je multiplexer.

Baasklusje schreef :
Ik heb vele jaren VSPE gebruikt in complexe configuraties en heb nooit data-loss ervaren.
Ben wel benieuwd hoe je VSPE geconfigureerd hebt (device definities en settings). Makkelijk genoeg met een paar screen captures hier laten zien. Dat lijkt mij toch het eerste dat ter discussie komt bij het ervaren van problemen.

WaltB schreef :
In het gebruik merk je er niets van, dus data-loss ervaren is wat sterk uitgedrukt.
Ik zie het pas als ik alle gelogde NMEArecords laat nakijken op overschrijvingen (2 $-tekens) of checksum-fouten. Gaat vaak samen: de checksum klopt wel over het erover geschreven deel,maar natuurlijk niet voor het hele record. Voorbeelden:

De configuratie in VSPE is een splitter. Fysieke COM3, gesplit in 2 maal COM1



De resultaten van 2 maal 12 uur varen (24uurs):
deel 1



deel 2



We hebben het dus over 0,2% van de records.

En met GPSgate gebeurt dat niet.....

Inmiddels antwoord van Eterlogic.
Ze zijn het aan het onderzoeken; kan te maken hebben met de buffergrootte in Splitter.
Er komt een geheel herziene versie van VSPE Splitter aan.

Prima produkt in mijn ervaring, erg veelzijdig, eenvoudig configureerbaar en ook als service te starten! Benieuwd hoe ze dit oplossen.

Maar los daarvan, is het hele COM poort gebeuren voor communicatie tussen software niet aan iets moderners toe? Zijn er geen hedendaagse technologiën die beter werken?

Nachtvlinder schreef :
Een serial bus (RS232, RS485, USB) is natuurlijk ontzettend robuust en al tientallen jaren in gebruik. Stekker erin en werken.

Alternatieven met dezelfde mogelijkheden (TCP, webserver, niet UDP) vereisen veel meer instellingen en zijn m.i. gevoeliger voor storingen. Ook de opstart met handshakes is lastiger.

COM is here to stay

Baasklusje schreef :
Geeft stof tot nadenken. Waardoor komt het dat de buffer niet groot genoeg is ? Een grotere buffer betekend ook een grotere mogelijke vertraging. De miniplex geeft een berichtje als er een buffer overrun is.

Mee eens, COM is here to stay. Je ziet asynchrone seriele data nog steeds gebruikt worden door wetenschappelijke apparatuur, moderne chips met comms, etc.

Dus de fout treedt al op wanneer slechts een VSPE “splitter device” is gedefinieerd, zonder connector of andere devices?

Dit lijkt mij geen buffer probleem, maar eerder een timing probleem, maw VSPE kan niet snel genoeg de NMEA data characters van de fysieke COM port verwerken en dus treedt een overflow situatie op.
Dit is o.a. afhankelijk van de snelheid van de PC, hoeveel apps er tegelijkertijd actief zijn, hoeveel I/O er plaatsvindt enz.
NMEA data transmissie gebruikt geen flow-control dus dat maakt het tijd kritisch als de source op volle snelheid data verstuurt.

Je vermeldt niet op welke baudsnelheid de port (en multiplexer) is ingesteld. Als die hoog is, zou als eerste maar eens proberen een lage(re) baudsnelheid te gebruiken. Bij matig verkeer en zonder AIS kun je vaak al wegkomen met de standard NMEA snelheid 4800 baud.

Verder zou ik als test/bevestiging i.p.v. WinGPS en SPD 2 copies van het simpele programma Teraterm gebruiken. Met 1 copy een logfile aanmaken. Dit zal minder CPU belasting geven.

Los van dit alles, ik weet niet wat je met de gelogde data wilt doen, maar ik zou me geen zorgen maken over die <1% overschrijvingen. De meeste instrumenten data wordt elke seconde herhaald. Het wordt pas echt vervelend als je AIS zinnen gaat missen, die niet herhaald worden.

Ik maak me idd geen zorgen over die records. Er zijn genoeg andere

De snelheid over USB (com) wordt voor zover ik weet besloten door de PC zelf. Niet in te stellen.
Er gaat nogal wat overheen; met AIS erbij (nodig voor navigatie-app) soms tot 120 recs per seconde.
4800 bps zal niet gaan

Er draaien op de PC 3 apps. WinGPS,SPD en RAK.
CPU blijft onder de 15% (Core i5).

Met een terminal kijken is ook watt eterlogic (VSPE) aanraadt. Ga ik doen.

Bij Splitter device kan onder device settings de baudrate van de source port ingesteld worden. Uiteraard moet dit hetzelfde zijn als de output baudrate van de multiplexer. Ben wel benieuwd waarop dit staat.
120 recs/sec is wel erg veel, bij gemiddelde NMEA sentence length van 50 chars komt dat op 60000 bps (incl start/stop bits). Is daar niet veel redundant data bij dat uitgefilterd kan worden?

WaltB schreef :
Het meeste is AIS, de rest 1 Hz NMEA; de Miniplex brengt 10 Hz voor sommige records uit de EV al terug naar 1 Hz.

SPD telt wat er binnenkomt per seconde. Varieert wat, maar 60 a 100 per seconde is normaal. 120 bij veel AIS.

Ik zal eens kijken naar de instelling in Splitter.

Je zou ook kunnen kijken naar de manier waarop je log naar de harddisk geschreven worden. Een HD is een block device. Dus daar zit ook een buffer. Een ouderwets SD kaartje kan max 115200 baud schrijven.
Hoeveel memory swap naar de HD vind er ondertussen plaats ?

Ok com is to stay but TCP is to go! Om alle redenen die genoemd worden.
Dat je in dit geval er niet aan wenst kan ik begrijpen maar ik probeer het er juist bij jou als programmeur de visie erdoorheen te krijgen dat het the way to go is.
Nu zijn de gemiddelde wifi moduultjes in de watersport momenteel achterhaald traag en zeer beperkt in het aantal TCP verbindingen en met zeer beperkte server/client mogelijkheden maar daar moet naar mijn mening eens iets aan gedaan worden.
Maar zodra je een router toevoegt is dat al geen probleem meer, dat hoeft helemaal geen router met mobiele data te zijn ook in die setup kun je gewoon je mobieltje als hotspot gebruiken.
Bij alle Lan radars en onze ap wordt multicast gebruikt en dan hoef je niet eens iets in te stellen.
En bij TCP kun je ook auto scannen op bekende ip adressen en poorten zodat gebruikers niets hoeven in te stellen.

Hi zeilprutser, een oude discussie. De een of de ander, TCP of COM is niet de kwestie en niet te vergelijken. Er is/blijft plaats voor beide. Async serieel is en blijft simpel en robuust en behoeft geen speciale drivers, behalve USB dan op consumenten PC's. Maar veel industrial PC's komen nog steeds met RS232 ports, onmisbaar voor wetenschappelijke en industriele toepassingen.
Absoluut niets tegen TCP/wifi, integendeel, ik ben al jaren een voorvechter. Modules zijn al jaren zeer geavanceerd met AP en STA ondersteuning, multiple TCP, client en server, allemaal configureerbaar via webpage. Zie dit project, alweer 5 jaar geleden: TCP wifi nav netwerk

Gisteren een wedstrijd gevaren (en gewonnen) van een uur of 4 varen.
Deze keer weer eens GPSGate gebruikt ipv VSPE om de COM te splitsen voor 2 apps.

Op 1,1 miljoen NMEArecords geen enkel overschreven record.
Het ligt toch echt aan VSPE, lijkt het.

@WaltB Als je gewoon leest wat ik schrijf dan zie je dat ik het eens ben dat COM/NMEA0183 is to stay.
Maar als communicatie middel tussen moderne stukken software is het ongeschikt en achterhaald en er is een goed alternatief.
Als je dan ook nog een beetje samenwerkt (Signalk sentences (Json) gebruikt bijvoorbeeld) dan maak je het elkaar al een heel stuk makkelijker. (dat heeft er niets mee te maken of je ook een Signalk server of client wel of niet wilt hebben draaien)
Als je wat meer complexere zaken met elkaar wilt koppelen heb je gewoon wat meer bandbreedte nodig.
Nu zie je iedereen kloten dat het ene kastje net te kort komt voor het andere of het nu MNEA0183, NMEA2000, Seatalk1, etc. etc is.
Zodra je echter Lan/Ethernet toepast heb je bandbreedte genoeg om alle soorten communicatie te ondersteunen ongeacht de taal of structuur en die kunnen tegelijk in verschillende richtingen in verschillende talen over het zelfde kabeltje en door de lucht.

Doordat TS zijn mobiel als hotspot wenst te gebruiken zie je de logische noodzaak al voor een router, mijn inziens moet je als visie de multiplexer dus ook als router zien echter gezien dat een router zonder internet niet meer realistisch is moet hij ook beschermt zijn tegen de boze buitenwereld en dan is het logischer een dedicated router te nemen (zodat je die onafhankelijk kunt upgraden en/of vervangen indien nodig) en een multiplexer met Lan en/of Wlan die de verschillende protocollen ondersteund.

Disclaimer: ja ik ben bezig met de nieuwe BoatController die precies die functies ondersteund.

@zeilprutser. Als je het linkje naar mijn post van 5jr geleden even volgt, dan zie je dat we het voor en groot deel eens zijn, toen al. TCP/ethernet is ideaal transport medium met high bandwidth. Alleen jammer dat n2k daar niet als higher level protocol gebruik van kan maken. Geen hardware multiplexer te bekennen, wel router. Het application level is in die context minder interessant, maar 0183 nog steeds handig omdat alle nodige data definities aanwezig zijn en door ASCII makkelijk leesbaar.