Onderwerp: Arduino project aan boord

Arduino pas ik al veelvuldig toe op de boot. Je hebt er geen omkijken aan. Spanning er af en de volgende keer start het gewoon weer op. Ik heb inmiddels een Arduino voor BMS, met GSM-module, voor lampcontrole en in de MUX. In de MUX zit een Mega die allerlei nmea-zinnen ontvangt, controleert en doorstuurt, naar plotter en marifoon.



Ik blijf het topic lekker volgen.

@woody130; je hebt rs422<->ttl shifters op de uitgangen en niet op de ingangen en opto couplers op de uit en niet op de ingangen. Ben benieuwd naar je reden. Ik wil ze op de in en de uitgangen....

@Yazz De optocouplers zitten tussen de uitgangen van de randapparatuur (IS15, AIS en marifoon) en de ingangen (RX) van de mega. De rs422 converters zitten op de uitgangen van de mega (TX). De marifoon heeft in- en uitgangen. Ingang voor GPS en uitgang voor alarm. De ingangen van mijn randapparatuur bevatten optocouplers.

Yazz schreef : Strings (als type) zijn makkelijk maar erg onzuinig met de heap en zorgen binnen de kortste keren voor fragmentatie en de onmogelijkheid om geheugen te alloceren. Aswin legt het goed uit. Character arrays (met hun beperkingen) zulllen waarschijnlijk gaan helpen.

Meer over “Evil” Strings en waarom je ze voor de Arduino eigenlijk niet moet gebruiken: The Evils of Arduino Strings

Yazz schreef :
Dat is conform NMEA0183 en je beveiligd de ingang (is makkelijker) dan is de uitgang beveiligen niet nodig.
Persoonlijk beveilig ik ook beide.

@zeilprutser Mijn optocoupler bij de ingang is van jouw webshop

Gepost met de officiële Zeilersforum-app

Dat is natuurlijk altijd leuk om te horen!

Geïnspireerd door het schema van @Woody130 heb ik ook een schema van de beoogde opstelling gemaakt. De enige twijfel die ik nog heb is over het gebruik maken van een RS422<->TTL converter of toch eenRS232<-TTL> converter voor het signaal uit de oude Databox. De Databox geeft een TX+ en een GND (daarnaast heeft het ook een RX+ en een Vout en GND). Dat duidt op een RS-232 verbinding( -10V en +10v) Echter als ik aan het signaal meet zie ik netjes een blokgolf tussen 0V en 3.1V, wat weer duidt op een RS422 signaal.
De YDWR02 heeft een galvanisch gescheiden ingang op poort 4. De roze blokjes vallen buiten het project en leveren of ontvangen alleen data (Databox en GX2200 en de YDWR-02)

Rs232 is vaak minder dan 10 volt hoor. Maar als het signaal negatief wordt tov gnd is het rs232.
en heb je dus een max232 of gelijke nodig.

@roozeboos; ik heb het signaal gemeten en zit tussen 0V en 3,1V in lijkt daarmee dus op een RS422.... Maar ik heb beiden dus als het een niet werkt moet het de andere zijn

het beste is optocoupler in. Eentje die snel genoeg is.
2k2 op ingang en omgekeerde diode.
Gaat altijd goed.

@roozeboos: een optocoupler als converter bedoel je? Dus ipv de RS422 of RS232? EN dan eentje die hoog uit stuurt als tie hoog binnen krijgt. Als dat werkt is dat misschien helemaal geen gek idee....

nou als de ingang actief wordt wordt de uitgang laag. Dat is precies wat een rs485 of 232 converter ook doet.
Op de collector uitgang van de optocoupler dan een 6k8 naar de plus.

@roozeboos; dat wordt een leuk experiment. Maar qua octocouplers heb ik niet veel kennis. Dus 2k2 en 6k8 zegt mij (nog)niets. Ik heb al eens zitten kijken bij bv digikey, maar zie door de bomen het bos niet. Ik zie bv forward voltage van 1.7V terwijl ik denk de Arduino doet 3.3 of 5V dus dat gaat niet werken. CTR begrijp ik intussen. Max doorlaat voltage kan volgens mij op 6V maz. 1 Mbps is wel het minimum aan snelheid lijkt mij. Een Scmidttrigger lijkt me niet nodig want DC. En dan zie ik een Darlington met een dubbele PNP of NPN transistor lijkt mij ook niet nodig... etc

Oh ja... voor de stabiliteit en voorkoming van valse triggers zou een pull-up resistor dan wel wenselijk zijn op de ingang van de Arduino met 3,3, of 5V...

ja, sorry,
2k2 in serie op de ingang. En over de beide pinnen een diode met de kathode aan de anode van de optocoupler, dus in sper.
Beschermt de optocoupler led tegen omgekeerde spanningen, daar kan ze niet zo goed tegen.

Dan aan de andere kant een weerstand van 6.8 kilo als pullup. dus collector aan weerstand en de andere van de weerstand aan de plus. emitter aan ground uiteraard.
Wil je ook 38400 bps doen dan moet er een 100 pF van data naar ground.
Collector naar arduino in, uiteraard.

Wil je een kant en klaar bordje voor weinig, dan moetje naar prutser zijn webshop. Heeft hij ook weer een loopje naar de post.
Maar ik denk niet dat daar de 100 pF in zit.

@roozeboos: Ik heb als ik het goed heb begrepen je voorstel in een schema gezet. Als ik er aan reken er van uit ga dat het aangeboden signaal max 5V is en het forward voltage van de optocoupler 1.2V is ik een I_F overhou van 1.7mA en dat lijkt me vrij weinig.
Aks ik uitga van een CTR van 100% voor het gemak en Vcc ook 5V is dan hou ik een Ic over van 0,73mA voor de Arduino. Ook dat lijkt mij te weinig.

Van welke waarden ben jij uitgegaan?

ja dat draait goed hoor. Je wil de nmea uitgangen ook niet te veel belasten. en soms hangen er meerdere optos nog parallel ook.
mooie opto is de ACPL-M50

Update 22 mei.
Alle onderdelen zijn binnen dus ik kan zometeen ook met de hardware aan de gang om e.e.a. te solderen. Intussen werkt de software van het prototype samen met het 3,5" touchscreen.
Het plan is om nu alle onderdelen te solderen en aan te sluiten zodat er zometeen een eerste test-run gedaan kan worden met het aangesloten boordnetwerk. Ik zit dus nog wel steeds in de get-it-working fase. Hieronder een screenshot van de display die in het logscherm netjes de gegenereerde berichte leest, omzet naar het juiste formaat en naar buiten stuurt.
De berichte in Oranje zijn de door de Arduino aangepaste berichten

Update 2 juni: Nadat de software ogenschijnlijk deed wat het moest doen op basis van test berichten die vanuit de software werden gegenereerd, was het tijd om de boel aan het boordnetwerk te knopen. Ik noem het maar even de pre-FAT. Dat werd een behoorlijke desillusie. Inkomende signalen werden niet gezien en uitgaande signalen werden ook niet gezien. Met de multimeter met oscilloscope view de signalen gemeten en die bleken niet boven 1,5V uit te komen. Zowel inkomend als uitgaand. Dat is niet genoeg om volgens NMEA specs een overgang van een 1 naar een 0 of vice versa te zien. Teleurgesteld ben ik weer terug naar de "tekentafel" gegaan. Door de basis opnieuw te testen, dus allen de communicatie met het netwerk zowel in als uitgaand, kwam ik er achter dat ik het lezen en schrijven naar een seriële poort verkeerd heb geïmplemeteerd. Na voorbeelden goed bestudeerd te hebben heb ik de functies volledig opnieuw geschreven en voilá ik kan nu zowel inkomende berichten lezen (getest met een NMEA simulator en een Rs-232 kabel) en schrijven (getest met een seriële kabel en SerialTools software) . Beiden op de Mac.
Ik kan nu aan boord gaan testen om te testen of het ook daadwerkelijk werkt. Zodra ik heb getest kom ik weer in de lucht.

Naschrift; Ik kwam er achter dat meten aan de signalen invloed heeft op het spanningsniveau van de signalen, de reden waarom ik niet meer dan 1,5V op de signalen heb gemeten. Ik kwam hier toevalligerwijs achter toen ik eerst rechtstreeks de signalen aan de voltmeter hing en netjes conform verwachting meette, maar toen ik ook de draadjes naar de Arduino bijprikte zakte het voltage op de signalen onder de 1,5V. Terwijl ik dacht dat als je parallel meet je geen beinvloeding hebt...(?)

Yazz schreef : Vooropgesteld dat ik weliswaar geen complete nitwit ben op elektronica gebied, ben ik zeker geen expert.
Maar als ik het bovenstaande lees, zou ik eerder concluderen dat niet de meter, maar de arduino het signaal niveau beïnvloed.

@PvO; dat zou nog best eens kunnen. Als zonder enige aansluiting meet op de uitgangen meet ik 5V. Het resultaat veranderd er echter niet door Maar het betekent wel dat iets aan signaal versterkin moet doen als je meer wilt dan eenvoudige I/O

Op welk punt meet je precies de 5V die "inzakt" naar 1,5V? Ik zie dat je met breadboards test. Mijn ervaring is dat die (de goedkopere breadboards dan) een behoorlijke overgangsweerstand kunnen hebben.

@H20; het breadboard is alleen voor de MPU9255 in gebruik. De NMEA signalen komen nu rechtstreeks vanaf de digitale pinnen 53 (In) en 50 (Out).Bij het waarnemen hiervan zaten de draadjes nog op de Tx2 en Rx1 pinnen van de Arduino Mega 2560. Bij het meten heb ik eerst de multimeter rechtstreeks op het open einde van de draad aan de pin gemeten. Dat was voldoende om signaalovergangen te meten die als NMEA geïnterpreteerd zouden kunnen worden. Draadje van de pin in een Wago-klem en de taster van de multimeter in de andere opening van de Wago-klem.
Als ik vervolgens ook de RS-232 kabeltje erbij verbind( het draadje zit dat bij de taster in de wago-klem), dan zie ik een soort van halvering van de spanning. Wellicht maak ik een meetfout.....

Op dit moment kan ik in ieder geval signalen via RS-232 op de laptop uitlezen die als herkenbare NMEA berichten worden gezien. Het binnenkomende signaal loopt via een RS-422<->TTL converter. Dit signaal op de digitale pin 53 hoeft niet te worden terug geinverteerd na de TTL converter omdat de Arduino op TTL niveau werkt (proefondervindelijk uitgevonden). Het uitgaande signaal op pin 50 moet echter wel eerst worden geinverteerd om het weer als RS-232 te kunnen lezen.

Update 6 juni; Vandaag een eerste life test aan boord gedaan om de basis functionaliteit, de must-haves, te testen. Dat betekent NMEA berichten uit het boordnetwerk inlezen, modificeren indien nodig en checksum toevoegen en naar de multiplexer schrijven. Ook een wish-to-have is meegenomen, n.l. het tonen van de ingelezen data op het beeldscherm.
De should-have, n.l. het electronisch kompas, is in deze test buiten scope geplaatst. Dit omdat de huidige sensor eerst goed moet worden gekalibreerd voordat er bruikbare data uit komt. Dat kalibreren is nog een vak apart en daar ga ik me de komende tijd op focussen.
Uiteraard ging e.e.a niet meteen van een leien dakje; Ik kon wel uitgaande data naar de mux sturen (in de test mode) maar kon geen data vanuit het boordnetwerk inlezen. Dit terwijl de droge test op de keukentafel succesvol was verlopen. Na het deduceren van de verschillende scenario's waarom dit niet werkte, bleek de laatste optie ( het zal eens niet de eerste optie zijn...) de reden van het niet werken bloot te leggen. Op de keukentafel heb ik de baudrate voor zowel het inkomende als het uitgaande signaal op 4800 Bd gezet. Aan boord echter komt de data met 4800 Bd binnen , maar gaat op 38400Bd naar buiten. De SoftSerial library waarmee digitale ingangen als soft UARTS gebruikt kunnen worden (en het signaal indien nodig ook kunnen inverteren) is niet in staat op op verschillende baudrates te werken; gek genoeg. Voor dat ik daar achter was heb ik elke regel code bestudeerd met een test programmaatje die alleen de poort leest en die wel de data zag binnen komen. Maar ik kon niet ontdekken waarom het een wel werkt en het andere niet. Totdat ik ontdekte, door wat code in de loop() op te nemen dat de ingaande poort niet stond te luisteren, terwijl ik die netjes had geïnitialiseerd, net zoals ik dat ook voor de uitgaande poort had gedaan. Toen begreep ik wat er aan de hand was. Uiteindelijk heb ik de inkomende communicatie nu via een van de de standaard Rx poorten (Rx2) ingelezen en dat werkt zoals te zien in onderstaande video. Een belangrjjke mijlpaal is dus bereikt.

Van de week dit ESP32 ontwikkelsysteempje gekocht om eens uit te proberen:



https://www.tinytronics.nl/shop/nl/platforms/m5stack/m5stack-m5core-gray-esp32-development-kit

Een compact (5x5cm) ESP32 systeempje met 16MB Flash, een SD kaart slot, een ingebouwd 320x240 TFT schermpje, een LiIon batterij(tje), een BMM150 3D geomagnetische sensor, een MPU6886 6-DOF accellerometer en gyroscoop en natuurlijk WiFi en Bluetooth en zelfs een speakertje, allemaal in een net klein kastje. De basis kan worden uitgebreid door er modules op te "stapelen" met o.a. GPS, CAN / RS485 en nog meer, maar er kan ook eigen hardware aan worden gekoppeld. Alles is vanuit de Arduino IDE te programmeren (maar ook bijv. met MicroPython). E.e.a. ziet er veel meer "af" uit dan een Arduino met Shields.

Eerste indruk is erg goed. Lijkt me een ideaal systeempje om in een (NMEA0183 / 2000) boordnetwerk te hangen. Misschien iets voor versie 2.0 van je project? Zou makkelijk te porten moeten zijn.