Chain Counter - a Winter Project

[Hurricane]

Following on from another thread, I am providing details of a chain counter that I'm currently building.
On that thread, I stated that my design is very specific to my particular installation but there may be some "offshoots" from my solution that might be useful in other installations.

For me, this is not the first winter chain counter project.
The last one was a bit ambitious and never, properly, got off the ground.

So I have been tackling this one with much more caution.
Essentially, the problem is that the electric windlass creates an electrical noisy environment which can damage modern electronics.

Earlier this year, I installed an Anchor Camera.
I chose to integrate an IP camera into my PC network on the boat.
Once installed, any of my devices connected to my network can use the Anchor Camera.
The difficult part was to route wires from the chain locker into the forward cabin where I already have an Ethernet connection to the ship's network.
As soon as the camera was attached to the network, it was available throughout the boat.
And it really works well.

Here is a clip recorded by the camera itself of the anchor being recovered.



Our boat has never had a chain counter fitted and it would be very difficult, now, to route extra cables onto the flybridge.
However, whilst installing the wires between the chain locker and the forward cabin's network connection, I also ran a pair of wires to extend the Lewmar reed switch that is usually used as a chain counter.
This reed switch is activated by a magnet fitted into the windlass' gipsy.
Most Lewmar windlasses have this reed switch facility.

So, after the success of the Anchor Camera, I got thinking.
Maybe I could build an interface (similar to the IP camera that drives Ancam) which would also be available throughout the boat.

So, thats what this winter project is all about.

I apologise to those reading this that are cleverer than me.
I've kept this post as simple as possible so that most people can understand it.

Over the years, I've worked with a number of low cost embedded micro processors.
Last winter, I extended my home media centre which is in the living room under the TV to play the same media content on all the other TVs in the house.
All the clients are cheap Raspberry PIs which seem to handle the video processing (and streaming) well.
The Raspberry PI does have digital I/O but IMO the software isn't low level enough do run a project like the chain counter.
Back in the early 1980s when I was working with the 8080 and Z80 processors, we used a feature in the microprocessor called "interrupts".
Essentially, these are small subroutines that can be "triggered" by an external event.
As soon as an interrupt is triggered, the microprocessor stops what it is doing and just services the code within the interrupt.
In my chain counter project I don't want to miss the windlass operating the reed switch so I looked for a device that could be programmed at a reasonably low level and one that could handle interrupts efficiently.
A device that I've worked on before immediately came to mind. - The Arduino.
Lots of support and they are now very cheaply available on Ebay for, literally, just a few quid.
In fact, I already had one in my toolbox.
Unfortunately, the one I had didn't have an Ethernet interface (they do exist) so I bought an add on Ethernet card for about a fiver.
All I needed then was a means of safely interfacing the fragile electronics with the noisy outside world of the windlass.
The solution which I have tested (and it works) uses a small prototype board and some opto isolators.
Optos are an integrated circuit package that contains an LED set to shine on a light dependant transistor.
There is no actual electrical connection between an Opto's input and its output - great for this application.

If people are interested, we can discuss my circuit design as this thread progresses.
But for the moment, I've taken a few photos that, hopefully, will explain the basics of the project.

This is an Arduino - the main board - contains all the I/O connections which connect to the "outside world" using the small black vertical connectors.

This is the cheap Ethernet board that clips on top.
As said above, you can buy the main board and the Ethernet as a single board but I already had a main board.

And this is my little prototype board containing the Opto Isolators - again this just clips on top.
If you look carefully you can see 3 Optos - One will be for the windlass' reed switch and the other two will be used to "sense" the direction that the windlass is turning so that the software knows whether to count chain in or chain out.

And this is a pic of the whole thing assembled.

Finally, the next pic shows the kind of display that I will end up with.
Remember that this is a "work in progress" so this page is a bit of a "mock up".
Note that the "amount of chain out of the locker" is displayed at the top of the same screen as the Anchor Camera

Sorry - a Dolphin crept into that shot!!

On the other thread, it was thought that this might be a good place to discuss projects like this so please feel free to ask questions.
The 64,000 dollar question is - how can something like this be used on boats other than Jennywren.

 

[vas]

nice Mike, that was quick

I very much like the setup!

I'll answer the 40 and 140 dollar Qs and leave the 63820 dollars to the rest of the panel:

For 40 dollars, the bottom and top boards together can output NMEA0183 sentences that will feed to the GMI10/20 presenting rode out / rode remaining on these small screens. No other s/w needed apart from the bit you've done and the bit i'm testing re NMEA sentences and their checksums.
"Market" for say 10-20 boats as you'll need the reed switch and wire it up to the windlass, undo cabin panels to route the two cables (plus another two for the windlass control box...) it back inside, etc.

For 140 dollars, someone could also built another setup whereas a composite video feed is created by the arduino showing up on the plotter screen (assuming plotter has a video feed) Will be naff unless you could do what you're doing and supperimpose the info on a real anc cam video feed as I cannot see much of a point having a full screen (10 or 15inch!) showing one number (or two!) and don't know of an open platform plotter where you can add info on screens without them being accepted from the NMEA standards. Don't know how easy that would be though and may end up buying a raspberry pi to deal with video and superimpossing digits on them...
"Market" slightly larger: JFM, JtB who already have anc cams and potentially all others having a less than 15yo plotter with analogue video feed.

Main problem I see on the 40 and 140 dollar answers is that you just VIEW the windlass rode, you don't CONTROL the windlass from this setup.
That would mean much more work, and much more custom s/w to interface to the various plotters (who are typically closed systems not allowing for such things)
Mind, the arduino board wont need much work on it to be able to trigger the windlass relay controller

The JW setup may not be that difficult to become more open to an ethernet equipped boat (don't know how many are around though).

Probably the 240 dollar answer would be to interface to a wifi through which an android / i-device app then solves the HANDLING and CONTROLLING of the windlass as well. Business opportunity for you to built and sell enough boards to pay for enough diesel to helm JW just outside this lagoon of yours

Should have the NMEA0183 code ready (effectively 20lines or so...) by the w/e so would be interesting to see if all that can work together and show up on the GMIs. Obviously haven't got opto isolators but i'll be able to test with dummy values and see the behaviour of the system. If it works with the GMI, i'll ask for further help re code and opto hardware.

cheers

V.

 

[vas]

Sorry - a Dolphin crept into that shot!!

if you try a bit harder and with some decent image pattern recognition s/w, this app would end up as anchor rode-dolphin counter (rodoTM counter for short)

cheers

V.

 

[DougH]

Mike, never even contemplate selling your boat, without your winter projects you would curl up and die of boredom.

I do look forward to reading your progress on every ' I have an idea'.:encouragement:

 

[Hurricane]

Mike, never even contemplate selling your boat, without your winter projects you would curl up and die of boredom.

I do look forward to reading your progress on every ' I have an idea'.:encouragement:

Doug
You won't believe just how close you are to the truth when you say that.

I retired early.
It is very difficult when all your friends are still working to keep a "grip on life".
Something has to keep the grey matter working - or you simply die.
Luckily, my business life involved computers and I've always treated them as a kind of "intellectual challenge".
Over the last 10/15 years, the boat (in whatever form) has been a focus of things to do.
Some people take up gardening when they retire - some play golf - some DIY - and, of course - some die.
I've tried all those things (not the die bit) but the boat seems to be the most demanding.
And, of course, the boat has been the most fun, most rewarding and we have been to some beautiful places.

Lots of small winter projects this year - this chain counter is almost finished - roll on 2016!!

 

[Hurricane]

Vas

Lots of interesting ideas there.
Nothing that really works for most people though.
The big issue is the human interface - the bit where people actually see the chain count.
The Arduino certainly ticks the boxes on the cost and performance front.

I would like to explain how my software works.
The interrupt routine inside the Arduino software has to be kept as short as possible so it simply reacts to the reed switch signal and increments a counter (a global number stored in memory).
After changing the number the interrupt releases control back to the main program.
The bit that I haven't done yet is to have two more interrupt routines that simply switch a global binary value (true / false) which indicates which way the windlass is/was turning.
These two interrupt routines will, again be very short.
The first interrupt routine will the be changed to either increment or decrement the counter according to the global binary value.
This process provides an accurate value of the number or turns that the windlass has made.

The next bit was to communicate back to (in my case) a PC.
Initially, I built a web server inside the Arduino and then, accessing the Arduino using standard web technology.
This worked but I needed to have a constant update on the screen.
A full web page refresh every time I wanted to update the screen made the whole thing far too slow and unusable.
I've used AJAX techniques before to speed up web access but this all seemed far too much like "a sledge hammer to crack a nut".
All I needed was simple (single character) data transferred from the Arduino to the PC.
So, I started looking much lower down the stack and chose to use UDP messages - something I've never done before.
It turned out to be really simple.
The process is as follows:-
The PC sends a UDP packet to a remote host (the Arduino) using a specific IP port (for the moment, I think it just sends a word "Hello")
The Arduino then responds by sending a reply which at the moment is a string of numbers that relates to the value of its counter.
The PC then turns the string into a number and does the necessary calculation to change it from number of revs to a length of chain.
Effectively - thats JOB DONE

To enhance this, I will be changing the PC's initial UDP message to become a "command message" - for example one command will be to clear the counter inside the Arduino.
Maybe another command to set the counter at a particular value.
The Arduino software will also be changed to store the counter all the time (probably on its microSD card) so that if the power is switched off for any reason, it will still "remember" the amount of chain still out.

Now then, I have to admit a bit of cheating on the PC end. I've used lots of different languages and software tools in my time but I have a soft spot for the very old Microsoft Visual Basic 6 - not even a proper OOP language but it is really simple and easy to use.
In my chain counter project, I've made Visual Basic display the Ancam video using VLC support. Visual Basic is an event driven language so (using Winsock) I've been able to send and pick up the UDP packets from inside the Visual Basic code.
A really simple solution - for me anyway.
I did smile the other day when I realised that I could easily slip in my "talking" routines and have the anchor counter "Speak" the amount of chain out - there are some on here that know my passage logging software does that all the time!!!

So, how useful is this to a more universal solution.
I have no idea how NMEA2000 works but if they use similar concepts to UDP, maybe we could "inject" NMEA sentences into a NMEA 2000 network!!!
Just thinking whilst typing - I believe that there are engine NMEA Sentences - maybe we can use these and the chain counter could come up alongside the engine displays on a plotter.
Still not really universal enough.
The Garmin GMI might be a better solution.
Back to the beginning of this post, what we really need is a good human interface.
It will be interesting to hear any other ideas.

 

[djefabs]

Vas

Lots of interesting ideas there.
Nothing that really works for most people though.
The big issue is the human interface - the bit where people actually see the chain count.
The Arduino certainly ticks the boxes on the cost and performance front.

I would like to explain how my software works.
The interrupt routine inside the Arduino software has to be kept as short as possible so it simply reacts to the reed switch signal and increments a counter (a global number stored in memory).
After changing the number the interrupt releases control back to the main program.
The bit that I haven't done yet is to have two more interrupt routines that simply switch a global binary value (true / false) which indicates which way the windlass is/was turning.
These two interrupt routines will, again be very short.
The first interrupt routine will the be changed to either increment or decrement the counter according to the global binary value.
This process provides an accurate value of the number or turns that the windlass has made.

The next bit was to communicate back to (in my case) a PC.
Initially, I built a web server inside the Arduino and then, accessing the Arduino using standard web technology.
This worked but I needed to have a constant update on the screen.
A full web page refresh every time I wanted to update the screen made the whole thing far too slow and unusable.
I've used AJAX techniques before to speed up web access but this all seemed far too much like "a sledge hammer to crack a nut".
All I needed was simple (single character) data transferred from the Arduino to the PC.
So, I started looking much lower down the stack and chose to use UDP messages - something I've never done before.
It turned out to be really simple.
The process is as follows:-
The PC sends a UDP packet to a remote host (the Arduino) using a specific IP port (for the moment, I think it just sends a word "Hello")
The Arduino then responds by sending a reply which at the moment is a string of numbers that relates to the value of its counter.
The PC then turns the string into a number and does the necessary calculation to change it from number of revs to a length of chain.
Effectively - thats JOB DONE

To enhance this, I will be changing the PC's initial UDP message to become a "command message" - for example one command will be to clear the counter inside the Arduino.
Maybe another command to set the counter at a particular value.
The Arduino software will also be changed to store the counter all the time (probably on its microSD card) so that if the power is switched off for any reason, it will still "remember" the amount of chain still out.

Now then, I have to admit a bit of cheating on the PC end. I've used lots of different languages and software tools in my time but I have a soft spot for the very old Microsoft Visual Basic 6 - not even a proper OOP language but it is really simple and easy to use.
In my chain counter project, I've made Visual Basic display the Ancam video using VLC support. Visual Basic is an event driven language so (using Winsock) I've been able to send and pick up the UDP packets from inside the Visual Basic code.
A really simple solution - for me anyway.
I did smile the other day when I realised that I could easily slip in my "talking" routines and have the anchor counter "Speak" the amount of chain out - there are some on here that know my passage logging software does that all the time!!!

So, how useful is this to a more universal solution.
I have no idea how NMEA2000 works but if they use similar concepts to UDP, maybe we could "inject" NMEA sentences into a NMEA 2000 network!!!
Just thinking whilst typing - I believe that there are engine NMEA Sentences - maybe we can use these and the chain counter could come up alongside the engine displays on a plotter.
Still not really universal enough.
The Garmin GMI might be a better solution.
Back to the beginning of this post, what we really need is a good human interface.
It will be interesting to hear any other ideas.

Hi Mike, I read this with great interest and didn't understand a word until I got to the 'speaking' bit. Remembering the 'Logging Event' very well I still hear that voice in my sleep :sleeping: surely you are not going to inflict an 'Anchor Event' on your guests and crew.

 

[Hurricane]

Hi Mike, I read this with great interest and didn't understand a word until I got to the 'speaking' bit. Remembering the 'Logging Event' very well I still hear that voice in my sleep :sleeping: surely you are not going to inflict an 'Anchor Event' on your guests and crew.

Actually, I thought of you when I posted the above!!
No, I don't think it would be of any benefit - there are two main ways to implement it.
1 - Press a button and it speaks - not really useful because you could just look at the display.
2 - Or it could speak all the time!!!
There is one possible use and that it sets an alarm (Speaks) when it reaches a specific point - maybe just as the anchor breaks the surface or at (say) 10m when deploying.
Thinking about it - I might write that option - dead easy to do.

Since cruising with you, I've upgraded the voice - she now has a much more sexy voice - I'm thinking of getting her to say "darling" when she is talking!!

Great that you should take the time to read my posts.
I showed you the Arduino last month after Jez's delivery before I'd tested it - you looked a bit "glazed over" then so I thought it was just me being geeky.

 

[alt]

Looks very cool, Hurricane.

I also work in computers, can you please tell me what i'm doing wrong? (Granted, i'm still south of 30, but still.....)

 

[djefabs]

I remember the Arduino but I guess I was still trying to digest the Raspberry Pie:encouragement: so yes probably did look a bit glazed over. I always read your post with great interest, not sure that I fully understand them all !!! but nevertheless...great interest.:sleeping::sleeping:
I guess that being serious for a moment there could be a useful 'anchor event' being just before it breaks the water surface so that it could bring your attention to the AnCam and ensure safe/slow stowage of the anchor.
I look forward to further instalments.

 

[laika]

A few random comments since you asked: feel free to ignore . Sounds like a great project.

Small note on the pi interrupt thing. Yes hardware interrupts on linux are handled in kernel space and you possibly don't want to write a driver for this, but all the various pi gpio libraries seem to have the facility to let you wait for state changes on the gpio pins. At least some (and possibly all?) use sysfs to flag this to userspace. This isn't something I've personally played with but I'd be thinking of using a thread sitting in epoll() on the state change which either does the count incrementing itself (with the counter protected by a mutex) or simulates an interrupt by signalling the main thread. There seems to be bindings for various languages which would doubtless allow you to do the same thing in a cleaner, event driven way. Should be easily doable for the frequency of pulses we're talking about with a chain counter.

Using the Arduino makes much more sense though if that's what you feel comfortable with

I have no idea how NMEA2000 works but if they use similar concepts to UDP, maybe we could "inject" NMEA sentences into a NMEA 2000 network!!!
Just thinking whilst typing - I believe that there are engine NMEA Sentences - maybe we can use these and the chain counter could come up alongside the engine displays on a plotter.
[...]
Back to the beginning of this post, what we really need is a good human interface.
It will be interesting to hear any other ideas.

N2K requires more hardware and it's unclear if there's a pre-defined PGN for this. Personally I'd skip N2K.

As it probably doesn't matter what format you actually use for a custom interface, using the format which vas's garmin displays understand might make the project more generalisable. Martin_J posted the specs on the thread vas started on the PBO forum:
http://www.autoanchor.co.nz/sites/default/files/NMEA_Message_Formats.pdf


It also does involve the arduino doing the calculation of chain out rather than the receiving PC (which I think is a good thing). You could output that via the arduino's UART as well as stuffing it into a UDP packet. Or ditch the network shield and connect the arduino via serial to a wireless NMEA-0183 multiplexer?

For control you could just make up your own proprietary sentences. Or, of course, just do what you're doing now.

Signal K is all very du jour as a data format but is far more verbose than you need for this.

If you want to start getting all IoT with this, CoAP is your friend here but it's probably unnecessary bloat for a simple application:
http://coap.technology

Is the intention here purely a chain counter or is controlling the windlass relay from the arduino also on the cards?

 

[Hurricane]

A few random comments since you asked: feel free to ignore . Sounds like a great project.

Small note on the pi interrupt thing. Yes hardware interrupts on linux are handled in kernel space and you possibly don't want to write a driver for this, but all the various pi gpio libraries seem to have the facility to let you wait for state changes on the gpio pins. At least some (and possibly all?) use sysfs to flag this to userspace. This isn't something I've personally played with but I'd be thinking of using a thread sitting in epoll() on the state change which either does the count incrementing itself (with the counter protected by a mutex) or simulates an interrupt by signalling the main thread. There seems to be bindings for various languages which would doubtless allow you to do the same thing in a cleaner, event driven way. Should be easily doable for the frequency of pulses we're talking about with a chain counter.

Using the Arduino makes much more sense though if that's what you feel comfortable with



N2K requires more hardware and it's unclear if there's a pre-defined PGN for this. Personally I'd skip N2K.

As it probably doesn't matter what format you actually use for a custom interface, using the format which vas's garmin displays understand might make the project more generalisable. Martin_J posted the specs on the thread vas started on the PBO forum:
http://www.autoanchor.co.nz/sites/default/files/NMEA_Message_Formats.pdf


It also does involve the arduino doing the calculation of chain out rather than the receiving PC (which I think is a good thing). You could output that via the arduino's UART as well as stuffing it into a UDP packet. Or ditch the network shield and connect the arduino via serial to a wireless NMEA-0183 multiplexer?

For control you could just make up your own proprietary sentences. Or, of course, just do what you're doing now.

Signal K is all very du jour as a data format but is far more verbose than you need for this.

If you want to start getting all IoT with this, CoAP is your friend here but it's probably unnecessary bloat for a simple application:
http://coap.technology

Is the intention here purely a chain counter or is controlling the windlass relay from the arduino also on the cards?

Thanks for taking the time to post that.
Just a quick comment on using the Arduino vs Raspberry PI
As you say, the PI would probably be run under an operating system (Linux etc) which would need considerable software to get the interrupts working.
With the Arduino, you simply write the interrupt routine and attach it - 5 lines of code in my case.
So, I think that the Arduino wins hands down - in this case - there are places where the PI is best though.
Anyway thanks for posting how the PI would be programmed.

Since my last post, I've had a thought.
It (kind of) comes back to my project 2 or 3 years ago.
We all have smart phones these days so maybe an Arduino feeding into a smart phone app would be more universal (using either WiFi or Bluetooth).
Just looked at WiFi and Bluetooth modules for the Arduino - very cheap.
In fact there is even an Arduino with built in BT
Maybe thats the way forward.

My project failed last time because I was trying to be too clever.

Since then and for this season, I bought a Navis wind transducer that uses Bluetooth to a smart phone app in exactly the same way.
It really worked well this season - maybe a chain counter could work the same way - and be so cheap that anyone could afford it.

Not sure that actually controlling the anchor would be a good thing but it would be interesting to hear what people think.

I've written apps for IoS and Android - bloddy hard work they were as well but maybe this will be an interesting way to go.
A "kind of" Open Source Chain Counter Project - maybe we call it OSCA (Open Source Chain Application)
Perhaps it could end up as a cheap Arduino (say under a tenner) and a free app for a smart phone.

 

[vas]

thanks Laika for posting, indeed getting rid of interrupts was one reason for going the arduino route tbh.

Mike, I think we should all write-OFF NMEA2K. From my understanding it's a quite closed system, expensive even to get the docs, and you have to be verified or whatever by the body or something. Much easier to work on 0183 which is just two wires and well documented sentences

Talking about what can an arduino be used for I recon that we could reasonably easily go for:

• fuel consumption: It's an opto switch on a couple of flow sensors, two counters a subtraction and you're ready (if that isn't an oversimplification I don't know what is )
• rev counter for non ECU analogue engines

Catch is that I haven't found the right sentences for these, I think all devices supporting them are NMEA2K so may be a dead end, any ideas?

Further as GHA points we need a v.expensive serial board (99p) that does the NMEA to arduino serial data conversion that sits in between them and I'm about to order a few for testing.

Mike, care to point where you got this opto isolator board from? Found quite a few on ebay not sure what to buy. Was thinking to get one with maybe 4-6inputs to be able to route other things on it if necessary...

cheers

V.

 

[Hurricane]

thanks Laika for posting, indeed getting rid of interrupts was one reason for going the arduino route tbh.

Mike, I think we should all write-OFF NMEA2K. From my understanding it's a quite closed system, expensive even to get the docs, and you have to be verified or whatever by the body or something. Much easier to work on 0183 which is just two wires and well documented sentences

Talking about what can an arduino be used for I recon that we could reasonably easily go for:

• fuel consumption: It's an opto switch on a couple of flow sensors, two counters a subtraction and you're ready (if that isn't an oversimplification I don't know what is )
• rev counter for non ECU analogue engines

Catch is that I haven't found the right sentences for these, I think all devices supporting them are NMEA2K so may be a dead end, any ideas?

Further as GHA points we need a v.expensive serial board (99p) that does the NMEA to arduino serial data conversion that sits in between them and I'm about to order a few for testing.

Mike, care to point where you got this opto isolator board from? Found quite a few on ebay not sure what to buy. Was thinking to get one with maybe 4-6inputs to be able to route other things on it if necessary...

cheers

V.

First replies to your post.
I agree NMEA 2000 would be tricky to implement - I don't believe that it would be impossible though - it is a bit like Ethernet.
But I agree that NMEA 0183 is dead easy.

Arduino Serial board - can you post a link to the one you are proposing?
I assume that you are thinking of a board with a UART (Universal Asynchronous Receiver Transmitter)
In the old days, we were able to create a serial interface using digital I/O and just software.
There may be a way of doing that here but it needs some research.

I made my own Opto Isolator board using these:-
1 - https://www.robotics.org.za/index.php?route=product/product&product_id=104&search=4n25 (Cant remember where I bought them from though)
2 - A few resistors
3 - An Arduino Prototype board - this one - http://www.ebay.co.uk/itm/121708771025?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649

However, I think you are going the wrong way if you think other people will want to build anything similar.

IMO, if you want to put a project together along the cheap electronics line, it must be something that people could use with the equipment that they already have.
There is so much existing fixed kit out there that won't handle any new NMEA sentences thrown at it.
The only kit that I think people will have to receive and display something built from a cheap electronics project would be a smart phone.

So I have a proposal.
We set up an "Open Source Project"
The project would consist of software and hardware.
The hardware would consist of a single board that we design using the Arduino as a basis.
The board would contain a radio (Bluetooth or WiFi)
The board could be wired to a windlass.
The packaging of the board could be left to individuals to connect how they see fit (in their own watertight boxes etc).
The software would run on the new board and send the chain count to a smart phone.
Later, the software/hardware could be made to control the anchor as well.
The target price for producing this board should be as low as possible - I'm thinking that the electronics could be put together for under £20.
To do this in a true "Open Source" environment, we would need participation from lots people.
All the time given to the project would be free and then the project made free to anyone wanting to use it.
So if anyone reading this would like to help, please post a reply.
Those contributing would have different talents.
I can do most of the tasks in a projects (badly) - I'm a kind of "Jack of all trades"
I'm sure with a bit of discussion, we can design a robust circuit and software to drive it.
Actually, I don't think a project like this would take very long to put together.
It could be a YBW Forums "Open Source" project.

What does everyone think?

 

[laika]

I assume that you are thinking of a board with a UART (Universal Asynchronous Receiver Transmitter)
In the old days, we were able to create a serial interface using digital I/O and just software.

You can bit bang it but surely the UART route is way simpler and more efficient.

 

[Nick_H]

out if interest Mike, is the anchor cam picture clear enough to see coloured markers on the chain? I guess that would be the simplest form of chain counter, but not as much fun for you

 

[Hurricane]

out if interest Mike, is the anchor cam picture clear enough to see coloured markers on the chain? I guess that would be the simplest form of chain counter, but not as much fun for you

Not really, Nick
SWMBO always operates the windlass from the bow and she counts the coloured markers.
This project is just a bit of fun - Just like the AnCam and gives me some more information on the flybridge.
It certainly isn't a vital thing to fit.
Having said that, it might be nice to know exactly how much chain is out using other than coloured markers.
We will have to see - Although Ancam has, in fact, been quite useful in another area - during recovery, if I keep the chain in a particular segment of the screen, the boat's bow seems to follow the rode quite well thus keeping the load off the windlass as much as possible.

 

[vas]

So I have a proposal.
We set up an "Open Source Project"
The project would consist of software and hardware.
The hardware would consist of a single board that we design using the Arduino as a basis.
The board would contain a radio (Bluetooth or WiFi)
The board could be wired to a windlass.
The packaging of the board could be left to individuals to connect how they see fit (in their own watertight boxes etc).
The software would run on the new board and send the chain count to a smart phone.
Later, the software/hardware could be made to control the anchor as well.
The target price for producing this board should be as low as possible - I'm thinking that the electronics could be put together for under £20.
To do this in a true "Open Source" environment, we would need participation from lots people.
All the time given to the project would be free and then the project made free to anyone wanting to use it.
So if anyone reading this would like to help, please post a reply.
Those contributing would have different talents.
I can do most of the tasks in a projects (badly) - I'm a kind of "Jack of all trades"
I'm sure with a bit of discussion, we can design a robust circuit and software to drive it.
Actually, I don't think a project like this would take very long to put together.
It could be a YBW Forums "Open Source" project.

What does everyone think?

sorry for the late reply, was having a couple of v.hectic days plus a few hours on the boat working on the f/b helm setup (cutting and fitting...)

fully agree, I like modular projects
so, yes I'm in!

So core project has arduino with wifi/bluetooth and outputs to mobile. I'd have thought that it would be more generic if it was a webpage served rather than an BT thing, but it all is tricky as some plotters already have wifi and you probably DONT want to disconnect from the plotter wifi to connect to the chaincounter one... The ethernet serving would be a strong option for more complicated setups but as you say cannot have a solution for all unless you go for a custom system with it's own screen (that's too much)

Would it make sense to actually built the kit (or send it to ppl as a kit) or is it better to find readymade boards and recommend what to buy and how to install the s/w?

[meanwhile I can in parallel built the NMEA0183 part with the cheap serial board for whoever has a GMI10/20]

On the implementation, had a look for ready made optoisolation boards, plenty 1,2,4,8 channel ones around for silly money. Do they work? planning to order one for prototyping/testing.

As far as NMEA2K is concerned, from some extra reading (cannot find yet the analysis of sentences/packets and description for building them it should be OKish to built and offer something like that, it wont ever be certified (which we probably don't care anyway) but anyway it's a v.long shot only worth it if you start thinking of ways to implement more exotic features...

If I'm lucky I'll report on NMEA0183 testing via the arduino next week once I receive the right h/w...

cheers

V.

 

[vas]

You can bit bang it but surely the UART route is way simpler and more efficient.

laika,

care to point how the raw option of sending the sentences would work (saves me the time waiting for the board to arrive from china or wherever that is...) Would that work on an uno, or I'll run out of memory?

cheers

V.

 

[John100156]

Mike - I still have your box of bits on my desk - let me know if you want me to pop them back to you, I wish I could get involved with this project but time as always is a problem - roll on retirement, just six years to go....! :-(