anchor chain counter to NMEA0183 Garmin proprietary sentences via arduino?

[vas]

I think your right on both counts, first one is wrong, second one, though way over the top, should work. 5v into one side of the output, the other into a pin set as an input.
Ebays great

thanks,

yes the second one is way over the top but couldn't find anything smaller (or even larger for that matter, it was the only one I could find!). Yes windlass trigger is 24V but on this thing there will be a few millAmps doing bugger all. The massive relays to trigger the arduino are indeed hillarious, I'll make a nice sealed box and keep it by the windlass relay box so that noone ever sees what's in there

Of course the other option is to buy the chips and diy, but I'm not into that ATM. Still curious how others solve that!

cheers

V.

 

[vas]

after a bit more studying I found THE right device to measure solenoid activity in the form of Current Sensor modules. They are available in three sizes 5A, 20A and 30A
all employing the same ACS712 hall effect chip meaning you just introduce this on the + side of the circuit bringing the trigger current to the solenoid and it measures how much current goes through. Again it's not exactly what you want, but since it's sensing from .something of an Amp and solenoid probably runs on something very low, the 5A version should be enough to sense it. Further, it's one size fits all as it doesn't care if its a 12 or 24V windlass/trigger. Typical example looks like this:
http://www.ebay.co.uk/itm/5PCS-New-...502601?hash=item48872cc189:g:LOQAAOSw3KFWcNhL
I obviously need two but might as well get five for the price as I can think of half a dozen other uses While at it I'll get a few 20 and 30A ones.
Youtube video explaining the wiring and demoing how it works: https://www.youtube.com/watch?v=UF5jrnXvTlM

Only bit that confused me is where exactly to fit it if there are 2 or even 3 cables coming to the UP solenoid + terminal. I have foot switches on the bow, and toggles on lower helm and f/b. I guess I simply join all three at the current sensor and fit a small cable on the other side going to the solenoid

Since this project is going to start growing bigger, I noticed the same seller has some K-type thermocouples for silly money. Anyone used such a thing to measure exhaust elbow or better exhaust manifold temps?
I'll probably get a few of them and try for e/r temp, battery temp, manifold temp, etc and route them to the other project on the Due and NMEA2K (more on that over the w/e
http://www.ebay.co.uk/itm/MAX6675-M...05502601&tpos=top&ttype=price&talgo=undefined

Expecting snow on Sunday eve, so nicely timed to spend a few evenings programming
although kit ordered today will probably be here at the end of the month...

cheers

V.

 

[GHA]

af
http://www.ebay.co.uk/itm/MAX6675-M...05502601&tpos=top&ttype=price&talgo=undefined
.

I would go for a bag of these...
http://www.amazon.co.uk/DS18b20-Wat...ie=UTF8&qid=1452845552&sr=8-1&keywords=ds1820

Great little things, really accurate, cheap and you can daisy chain them so just use one input onto the arduino. I've a couple on the engine head and exhaust already. Also the rtc and sd card Shields are cheap to record it all. My fridge thermostat is an arduino using ds18's as well. With a little blue tooth module so I can adjust the temp without getting out of bed
also, not sure if current measuring is the way forward to check which way the windlass is running, but those acs current sensors are cool, I got halfway to building a battery capacity tester using one.. look what you've got yourself into, the possibilities are endless.......

 

[vas]

got some more time to work on this while waiting for ebay bits to come, so time to post my new problem...

I would go for a bag of these...
http://www.amazon.co.uk/DS18b20-Wat...ie=UTF8&qid=1452845552&sr=8-1&keywords=ds1820

Great little things, really accurate, cheap and you can daisy chain them so just use one input onto the arduino. I've a couple on the engine head and exhaust already. Also the rtc and sd card Shields are cheap to record it all. My fridge thermostat is an arduino using ds18's as well. With a little blue tooth module so I can adjust the temp without getting out of bed
also, not sure if current measuring is the way forward to check which way the windlass is running, but those acs current sensors are cool,

Thanks, ordered a dozen of these temp sensors already but not from Amazon who for some reason stopped selling stuff to Greece.

Curious why you recon current measuring is not the right way. I have the 24V version of this Quick solenoid

and I've got 3 cables coming on either side spade for the up and down from footswitches, lower and upper helm.
If I get the three cables on the up for example to the current tester and the other side of the tester wired to the solenoid spade, I should do what I want as there wont be any current flowing there unless I hit one of the three buttons, right?

I got halfway to building a battery capacity tester using one.. look what you've got yourself into, the possibilities are endless.......

nice, wonder to what extend the battery drop was due to the arduino itself
slightly confused though, magenta line is for voltage, blue line is for current it seems?
Starting at 12.2V is not that brilliant though, guess battery was loaded and discharging already for sometime...

OK, Question time

trying to receive NMEA signals from the GMI10 (which is probably naff as I doubt it sends anything out as is and without provoking it)
main reason is to get the signal that is sent when form the AutoAnchor screen I'm trying to reset rode. That's the main reason I'd like that function as I can see easily being a function used in case of failure to write or read to the SD (this is another chapter I've not tackled yet, but it can wait) or hardresetting the system.
So, I got the program loaded on the arduino, connected the 0pin to the TTL-RS232 converter for RX from the GMI and got the right GMI cable (blue) to the RS232 plug, nada!

NMEA0183 GMI10 wiring diagram looks like this:

Am I right in assuming that for the TX of the GMI to work I have to wire both TX/B(-) and RX/B(-) into the ground of the TTL-RS232 plug? (pin5 on the 9pin plug iirc)
Wired it again nothing.

I'm using the following in the loop() :

if (Serial.available() > 0) {
Serial.print("reading...");
inByte = Serial.read();
Serial.println(inByte);
} else Serial.print("nothing");
.

[btw browser trims (for some odd reason) the trailing double quote, closing bracket and semicolon, don't worry they are there]

Am I missing something?
I do seem to be at loss when dealing with reading rather than building and writing.

cheers

V.

 

[GHA]

Curious why you recon current measuring is not the right way. I have the 24V version of this Quick solenoid
and I've got 3 cables coming on either side spade for the up and down from footswitches, lower and upper helm.
If I get the three cables on the up for example to the current tester and the other side of the tester wired to the solenoid spade, I should do what I want as there wont be any current flowing there unless I hit one of the three buttons, right?

Dunno, just seemed a bit running around the houses, though if it works then so what. One thought came the other day, if you still have some hall effect sensors maybe one of those attached to the solenoid might trigger when the solenoid is engaged. Maybe.

nice, wonder to what extend the battery drop was due to the arduino itself
slightly confused though, magenta line is for voltage, blue line is for current it seems?
Starting at 12.2V is not that brilliant though, guess battery was loaded and discharging already for sometime...

Those batteries where not in the best of health as is was so were struggling to keep the voltage up even with just a 10A load. Poor things.
(total thread drift but there are interesting graphs on here showing voltage expected against load..
http://www.arttec.net/Solar_Mower/4_Electrical/Battery Charging.pdf)

Am I right in assuming that for the TX of the GMI to work I have to wire both TX/B(-) and RX/B(-) into the ground of the TTL-RS232 plug? (pin5 on the 9pin plug iirc)

Hmm, got me there, have you tried ignoring the /B- and just attaching pin5 of the TTL-RS232 to earth? All the boxes I have onboard just use single wires for nmea in/out and earth,

Good luck, please let us all know of successes

 

[vas]

me again...

need some H/W serial help for sure.

Trying to debug the receiving NMEA0183 streams part of my arduino sketch, I hooked up a simple USB-Serial adapter and connected the serial of the adapter to the TTL-232 socket.

So basically I have a loop where COM4 is the arduino uno, sending data to the TTL-232 which then connects to the USB-Serial cable and goes back to COM7.
Obviously both COMs are virtual, but they work fine.

HTerm is connected on COM7 (USB-Serial) and receives whatever my arduino pumps out from the serial. Fine, no problems there and anyway this part has been working fine with the GMI10 as well.

However, no matter what I try to send via the HTerm to the arduino, nothing appears.

I'm using a v. simple prog that was in the Serial.Event Tutorial.

Wonder what's wrong with the setup/code/myself...

Code is this:

String inputString = ""; // a string to hold incoming data
boolean stringComplete = false; // whether the string is complete

void setup() {
// initialize serial:
Serial.begin(4800);
// reserve 200 bytes for the inputString:
inputString.reserve(200);
}

void loop() {
// print the string when a newline arrives:
if (stringComplete) {
Serial.println(inputString);
// clear the string:
inputString = "";
stringComplete = false;
}
delay(1000);
}

/*
SerialEvent occurs whenever a new data comes in the
hardware serial RX. This routine is run between each
time loop() runs, so using delay inside loop can delay
response. Multiple bytes of data may be available.
*/
void serialEvent() {
while (Serial.available()) {
// get the new byte:
char inChar = (char)Serial.read();
// add it to the inputString:
inputString += inChar;
// if the incoming character is a newline, set a flag
// so the main loop can do something about it:
if (inChar == '\n') {
stringComplete = true;
}
}
}

any help much appreciated!

cheers

V.

 

[vas]

sorry, had my browser on reply mode and lost your message...

Dunno, just seemed a bit running around the houses, though if it works then so what. One thought came the other day, if you still have some hall effect sensors maybe one of those attached to the solenoid might trigger when the solenoid is engaged. Maybe.

sensors will probably arrive in a couple of weeks and anyway it's too freezing cold for me to do any work on the spot! Make sense, will test and let you know, thanks.

Those batteries where not in the best of health as is was so were struggling to keep the voltage up even with just a 10A load. Poor things.
(total thread drift but there are interesting graphs on here showing voltage expected against load..
http://www.arttec.net/Solar_Mower/4_Electrical/Battery Charging.pdf)

will check in the evening when I have more time

Hmm, got me there, have you tried ignoring the /B- and just attaching pin5 of the TTL-RS232 to earth? All the boxes I have onboard just use single wires for nmea in/out and earth,

Good luck, please let us all know of successes

don't seem to have much luck, hence my last post. I'll try that once I establish a working setup.
Do you happen to have any working serial signal "intercepting" code to test my setup?

cheers

V.

 

[rgarside]

Do you happen to have any working serial signal "intercepting" code to test my setup?


V.

Not sure its exactly relevant to your problem, but I did a system that listens to two NMEA inputs, captures them both, and writes the composite data to an SD card and an output port.

To make that work I used the "SerialPort" library. This enabled me to extend the buffer sizes on the various ports. Using the standard serial library I ran into problems which were probably buffer overflows. It all worked using the extended library.

The code is too big to post here, but send me a PM with your email and I'll send it to you.

 

[vas]

Not sure its exactly relevant to your problem, but I did a system that listens to two NMEA inputs, captures them both, and writes the composite data to an SD card and an output port.

To make that work I used the "SerialPort" library. This enabled me to extend the buffer sizes on the various ports. Using the standard serial library I ran into problems which were probably buffer overflows. It all worked using the extended library.

The code is too big to post here, but send me a PM with your email and I'll send it to you.

thanks,

PM on it's way, however I seem NOT to get ANYTHING through the whole setup, a single byte would be nice. I feel there's something more fundamentally wrong in my current setup.

Ah, btw, I CAN sent code to the Uno even with the RX pin0 connected to the TTL-232. Is that right?
Any change I've fried the RX part of my TTL-232 thingies?
I feel it's highly unlikely considering I've got two of them and both do the same.

cheers

V.

 

[rgarside]

thanks,

PM on it's way, however I seem NOT to get ANYTHING through the whole setup, a single byte would be nice. I feel there's something more fundamentally wrong in my current setup.

Ah, btw, I CAN sent code to the Uno even with the RX pin0 connected to the TTL-232. Is that right?
Any change I've fried the RX part of my TTL-232 thingies?
I feel it's highly unlikely considering I've got two of them and both do the same.

cheers

V.

Email sent.

I don't have a clear idea of your hook-up [it was hard enough to work out mine!].

If this is about the issue of 1 and 2 wire flavours of NMEA, my set of hardware has a mixture of both. In putting together the data logger, and interconnecting the hardware, I just treated it all as RS232, and connected the data [-ve] of the two wire items to the ground of the one wire items. Fortunately it all worked so I didn't have to dig any deeper.

Good luck

D

 

[GHA]

So basically I have a loop where COM4 is the arduino uno, sending data to the TTL-232 which then connects to the USB-Serial cable and goes back to COM7.
Obviously both COMs are virtual, but they work fine.

HTerm is connected on COM7 (USB-Serial) and receives whatever my arduino pumps out from the serial. Fine, no problems there and anyway this part has been working fine with the GMI10 as well.
.

Which pins are the USB-serial connected to?
I just tried this and it works OK on a Mega, bog standard software serial sketch.
With realterm (couldn't get hterm to connect) type some text in the arduino serial monitor and send, it shows up in real term & vice versa.

Also, if you want to check a usb-serial device is working you can connect the RX & TX pins , then if you send anything from a terminal it will get sent straight back and be displayed in the terminal.

/*
  Software serial multple serial test


 Receives from the hardware serial, sends to software serial.
 Receives from software serial, sends to hardware serial.


 The circuit:
 * RX is digital pin 10 (connect to TX of other device)
 * TX is digital pin 11 (connect to RX of other device)


 Note:
 Not all pins on the Mega and Mega 2560 support change interrupts,
 so only the following can be used for RX:
 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69


 Not all pins on the Leonardo support change interrupts,
 so only the following can be used for RX:
 8, 9, 10, 11, 14 (MISO), 15 (SCK), 16 (MOSI).


 created back in the mists of time
 modified 25 May 2012
 by Tom Igoe
 based on Mikal Hart's example


 This example code is in the public domain.


 */
#include <SoftwareSerial.h>


SoftwareSerial mySerial(10, 11); // RX, TX


void setup()
{
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }




  Serial.println("Goodnight moon!");


  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
  mySerial.println("Hello, world?");
}


void loop() // run over and over
{
  if (mySerial.available())
    Serial.write(mySerial.read());
  if (Serial.available())
    mySerial.write(Serial.read());
}

 

[vas]

Which pins are the USB-serial connected to?
I just tried this and it works OK on a Mega, bog standard software serial sketch.
With realterm (couldn't get hterm to connect) type some text in the arduino serial monitor and send, it shows up in real term & vice versa.

Also, if you want to check a usb-serial device is working you can connect the RX & TX pins , then if you send anything from a terminal it will get sent straight back and be displayed in the terminal.

TTL-232 is connected on pins 0 and 1 the "proper" h/w uart of the Uno. Still haven't tried using softserial.

OK, you gave me an idea so I looped pin0 to pin1 effectively making a send-return thing without any other h/w.
Amazingly it works
so my sketch is fine but my wiring is crap. I'd prefer the sketch was crap and wiring fine as I don't see what's wrong, but we'll get there...
At least something to start with.
Too late for anything more, will report again tomorrow

cheers

V.

 

[GHA]

TTL-232 is connected on pins 0 and 1 the "proper" h/w uart of the Uno. Still haven't tried using softserial.

OK, you gave me an idea so I looped pin0 to pin1 effectively making a send-return thing without any other h/w.
Amazingly it works
so my sketch is fine but my wiring is crap. I'd prefer the sketch was crap and wiring fine as I don't see what's wrong, but we'll get there...
At least something to start with.
Too late for anything more, will report again tomorrow

cheers

V.

That sounds like both com4 of the arduino and com7 of the usb-serial are connected to the same place- pin 0 & pin 1.
AFAIK the uno has a usb-serial adapter which then connects to rx/tx which are pins 0 & 1. Sounds like you might have have 2 things trying to talk/listen down one thing. They might get a bit confused and grumpy with that..

 

[vas]

Email sent.

I don't have a clear idea of your hook-up [it was hard enough to work out mine!].

If this is about the issue of 1 and 2 wire flavours of NMEA, my set of hardware has a mixture of both. In putting together the data logger, and interconnecting the hardware, I just treated it all as RS232, and connected the data [-ve] of the two wire items to the ground of the one wire items. Fortunately it all worked so I didn't have to dig any deeper.

Good luck

D

Spend some time trying to understand all your code, no luck yet, I'm still at kindergarden level and you're probably up to K12

I'll resort back to it plus some other code others kindly donated as I get up to speed (anyway out of crawling at least...)

That sounds like both com4 of the arduino and com7 of the usb-serial are connected to the same place- pin 0 & pin 1.
AFAIK the uno has a usb-serial adapter which then connects to rx/tx which are pins 0 & 1. Sounds like you might have have 2 things trying to talk/listen down one thing. They might get a bit confused and grumpy with that..

no, they were okayish conflict wise, my code was all over the place regarding strings and their manipulation.


anyway happy to report that after spending most of Sunday I just managed to have a working loopback setup good enough for testing strings and sentences back and forth to the Arduino Uno.

So, pins 10,11 are Software serial in out, arduino is COM6 and USB-Serial adapter is COM7. TTL-RS232 is not used at all in this setup and probably wont be for the time being.
I can now use HTerm (connected to COM7 USB-Serial adapter) and send strings from the USB-Serial to the arduino, which is able to read them properly and send them back out to the USB-Serial.
It took me four bloody hours to figure out:

A. that the incomprehendable crap I was getting on the arduino were because I hadn't added the true flag on the SoftwareSerial in order to invert the logic (doh!)

B. following number lists I was getting on the serial in of the arduino were the bleeding ascii values of the characters I was sending and all I had to do was to change the test code from:

read()
to
readString()

that's shows my programming skills nicely, off to have a few drinks, had enough!
wonder how I'll manage to progress with N2K sentence building...

cheers

V.

 

[rgarside]

Spend some time trying to understand all your code, no luck yet, I'm still at kindergarden level and you're probably up to K12
.

It was all perfectly clear and understandable when I wrote it, of course when I go back to it now I have to do at least a week's revision to remember what on earth was going on - I'm told that real programmers document their code as they go along [but there aren't many of them].

 

[vas]

It was all perfectly clear and understandable when I wrote it, of course when I go back to it now I have to do at least a week's revision to remember what on earth was going on - I'm told that real programmers document their code as they go along [but there aren't many of them].

I tried to read some of the code I wrote 20yrs ago in lisp, that was fun, I just gave up!

I recon unless you write a bleeding essay describing what you've done on the top and type inline comments 3X the size of the actual code you've no luck
Mind in your case things have changed a lot as arduino progresses and new libraries are coming up as I now use SoftwareSerial instead of Serial and I recon some things are much simpler.

Looks like I managed to get some garbage/NMEA out of the GMI10 whilst in the AutoAnchor page a couple of hours ago, so now trying to sort that out. Would be nice to have at least something working in the right direction today as both Garmin Splash screen and gearbox projects went really bad today.

cheers

V.

 

[rgarside]

Mind in your case things have changed a lot as arduino progresses and new libraries are coming up as I now use SoftwareSerial instead of Serial and I recon some things are much simpler.

My datalogger has a Mega2560, so I was using the other hardware UARTs. I think I saw you are using an Uno, so having just the one UART you are stuck with SoftwareSerial.

 

[vas]

yet another update!

Started working on the new arrival (Due) and got an SD card shield on it.
Removed softwareSerial and went back to proper TTL-232 on Serial1
Not only everything works fine, I also got the reading and parsing of NMEA0183 signals from the GMI10 interpreted nicely, correct and quick (SoftwareSerial is indeed slow!!)
Well impressed with myself, I can now count chain out, speed of chain etc, but I can also reset chain counter from the GMI as well as change the gypsy dia from the GMI and the new values are updated on the arduino and reflect on new operations on the GMI. OK, the second is not something you'll use often, but the first is something useful.
Effectively the project is complete as the only thing missing is wiring the current sensor to the up signal of the windlass to start reversing the rode count. Down or freefalling doesn't need a current sensor (saves me a euro or so...)
Obviously a failed windlass with me using the manual backup lever will mess the rode count but I'll be more worried on the failed windlass...

My new question has to do with data logging necessary to keep rode and gypsy circumference between power cycles

I've created a folder on the SDcard, and want to read/write to the AA.log file the following info:
rode out and gypsy circumference

values are real and integer respectively and I guess a format like this should be ok:

"12.2000,3840" in one single line

Anyone done it before and cares to comment on the following:

Am I wearing the SD by reading/writting to the same spot all the time?
Am I better of appending the values to the file in a new line everytime - and maybe reading the contents and wiping the file everytime the arduino is powered on?
How often do I write to the SD? I could do it everytime a value changes (which is going to be once every few secs when the gypsy is working...)

any other issues I should be aware of regarding SD cards?

Since this project will be a general hub of I/O next step is to try the N2K sentences (well first wiring the MCP2515 to the Due and trying to send something).

cheers

V.

 

[GHA]

yet another update!

Started working on the new arrival (Due) and got an SD card shield on it.
Removed softwareSerial and went back to proper TTL-232 on Serial1
Not only everything works fine, I also got the reading and parsing of NMEA0183 signals from the GMI10 interpreted nicely, correct and quick (SoftwareSerial is indeed slow!!)
Well impressed with myself, I can now count chain out, speed of chain etc, but I can also reset chain counter from the GMI as well as change the gypsy dia from the GMI and the new values are updated on the arduino and reflect on new operations on the GMI. OK, the second is not something you'll use often, but the first is something useful.
Effectively the project is complete as the only thing missing is wiring the current sensor to the up signal of the windlass to start reversing the rode count. Down or freefalling doesn't need a current sensor (saves me a euro or so...)
Obviously a failed windlass with me using the manual backup lever will mess the rode count but I'll be more worried on the failed windlass...

My new question has to do with data logging necessary to keep rode and gypsy circumference between power cycles

I've created a folder on the SDcard, and want to read/write to the AA.log file the following info:
rode out and gypsy circumference

values are real and integer respectively and I guess a format like this should be ok:

"12.2000,3840" in one single line

Anyone done it before and cares to comment on the following:

Am I wearing the SD by reading/writting to the same spot all the time?
Am I better of appending the values to the file in a new line everytime - and maybe reading the contents and wiping the file everytime the arduino is powered on?
How often do I write to the SD? I could do it everytime a value changes (which is going to be once every few secs when the gypsy is working...)

any other issues I should be aware of regarding SD cards?

Since this project will be a general hub of I/O next step is to try the N2K sentences (well first wiring the MCP2515 to the Due and trying to send something).

cheers

V.

I can't remember the write cycles of an SD card but they must be loads and loads.
- Do you need to save the circumference of the gypsy, could it stay in the code?

Then you could just have a file with one entry to save the chain out , this seems to work OK, delete the file before writing the new number, though it's actually a string so you might need to convert it, but as a starter this seems to work as a test in a loop...

//WRITE TO SD CARD
String dataString = "";
dataString="123.123";
SD.remove("datalog.txt");
dataFile = SD.open("datalog.txt", FILE_WRITE);
dataFile.println(dataString);// and prints it to the file with a line feed
dataFile.flush();






String saved="";

dataFile = SD.open("datalog.txt");
if (dataFile) {
// read from the file until there's nothing else in it:
while (dataFile.available()) {
//Serial.write(dataFile.read());
saved=dataFile.readStringUntil('\n');

}
// close the file:
dataFile.close();
Serial.println(saved);


delay(1000);

 

[vas]

I can't remember the write cycles of an SD card but they must be loads and loads.
- Do you need to save the circumference of the gypsy, could it stay in the code?

since I'm doing a "proper" job I might as well write it on file.
Point is that I can change that value from the GMI (it's a option)
Since I'll be writing 5chars I may write 10, doubt it makes much of a difference...

thanks for the code, but in the meantime I debugged that so now I read the SD when it fires up (or when new code is uploaded on the Due) and each time:

• I hit the reset rode or
• change the gypsy circumference or
• reed counts new turns (hence new NMEA0183 sentence is sent out to the GMI)

I open the file, seek() to first position and rewrite the 10chars.

Amazingly everything works now, well impressed!

No excuses left now, got to try the N2K sentences during the w/e as I have a cheap NASA NMEA0183 wind sensor arriving during the week and got to sort that out soon together with the rudder angle sensor.

cheers

V.