Anchor Alarm II

meridian

Member
A couple of years ago we discussed the need for an extension of the anchor alarm on Meridian, as my wife wasn't with me and my mate who was helping, was equally hard of hearing. Part of the problem was that there was no signal wire for the anchor alarm which gets triggered by the GPS when the position is outside the circle of safety, eg .02 or .03 NM.

The solution was to fit a piezo inside the case to pick up the beep. This was fed to a VOX circuit with the 08 between the output and the relay. The relay closed the contacts on a wireless doorbell, which could be placed close by the sleeping skipper. To avoid random noise spikes setting it off, the 08 looked for a high from the amp, waited about 10 secs for another high to activate. If nothing heard after 10 secs, it slept for 30s. (I can't find the code now).

This has worked OK most of the time but it sometime goes off with random noise, or, more worryingly, doesn't go off when it should.

So I'd like to revisit the whole idea. I have attached a zipped mp3 file of the actual alarm. It is roughly 2 seconds per on/off cycle, I was hoping that someone could analyse it more accurately in terms of frequency, period on and off. I don't have a scope on the boat any more (I did have once!).

The question is:
(a) do I sample the beeps and silences to determine a true alarm condition or
(b) ditch the amp and measure the frequency directly by the 08 and then sample?

View attachment 13678View attachment 13678

I hope that the attachment works, I haven't done this before...


paulr
 

SAborn

Senior Member
Nope the attachment dont work.

I do remember the project from last time, (still think a string tied to the anchor and attached to the skippers toe would work :) )
I dont recall the final circuit you used now so will wait to see the schematic and hear the attached file (if you can actually attach a MP3 file here as i doubt it)
 

hippy

Ex-Staff (retired)
To avoid random noise spikes setting it off, the 08 looked for a high from the amp, waited about 10 secs for another high to activate. If nothing heard after 10 secs, it slept for 30s.
I would have thought that improving how the PICAXE determines when an alarm signal is present would help. Check that a signal is present for about 2 seconds, is not present for 2 seconds, is present for 2 seconds again.
 

SAborn

Senior Member
Here is a screen shot of the MP3 file opened with "audacity" which is a freeware audio program.
It might help to give you a better view of the periods.

Alarm.JPG
 

lbenson

Senior Member
Based on SAborn's timings, with 6 pulses in 14 seconds, you should be able to do something like this using the 08M2's "time" variable (counts seconds):
Code:
#picaxe 08m2

if pin1 = 1 then ' whichever pin the detector is on
  bit0 = 1       ' save pin state
  b1 = 1         ' first pulse detected
  time = 0       ' built-in seconds timer for M2 parts
  do while time < 14
    if pin1 <> bit0 then ' change of state
      if bit0 = 0 then   ' previous state was off
        inc b1           ' new "on" state--increment count
      endif
      toggle bit0
    endif
  loop
  if b1 = 6 then         ' we have the expected 6 positive transitions
'    do something
  endif
endif
Untested, but no syntax errors.
 
Last edited:

meridian

Member
Here is a screen shot of the MP3 file opened with "audacity" which is a freeware audio program.
It might help to give you a better view of the periods.

View attachment 13680
Thanks, SAborn, that is exactly what I was after! That's what I like about this forum, someone will always have an answer.
THe problem with the string-on-toe idea is that when the anchor is dragging, the distance to the toe remains the same!
 

meridian

Member
Based on SAborn's timings, with 6 pulses in 14 seconds, you should be able to do something like this using the 08M2's "time" variable (counts seconds):
Code:
#picaxe 08m2

if pin1 = 1 then ' whichever pin the detector is on
  bit0 = 1       ' save pin state
  b1 = 1         ' first pulse detected
  time = 0       ' built-in seconds timer for M2 parts
  do while time < 14
    if pin1 <> bit0 then ' change of state
      if bit0 = 0 then   ' previous state was off
        inc b1           ' new "on" state--increment count
      endif
      toggle bit0
    endif
  loop
  if b1 = 6 then         ' we have the expected 6 positive transitions
'    do something
  endif
endif
Untested, but no syntax errors.
Great! ibenson, I will give it a go today. I was thinking of maybe checking say every 300ms within the peak or trough, but your idea looks fine. I will report back tomorrow I hope.

Update: Just checked the stocks and find no M2s only 8M and 14M. Have to rethink.

paulr
 
Last edited:

meridian

Member
Meridian here is a simple sensor for a anchor alarm which does not rely on the GPS signal.You can add a Picaxe for more reliability. Built one myself a few years ago and works fairly well for its simplicity.
http://www.yandina.com/anchAlrm.htm#AA Parts List
Yes, it looks simple and not relying on GPS. As a matter of fact, I was dragged out of bed by my wife at 2am last night, I didn't hear the alarm which is the whole point of this thread. Anyway I saw that we hadn't moved- it was a GPS error putting us about 100m away from where we were. It eventually came back but about 10 minutes later the same error occurred! Bugger.
 

boriz

Senior Member
Meridian. Hope you don't mind me straying slightly off topic, but I have a nautical question.

I'm lead to understand that the anchor chain does the actual position fixing, not the anchor 'hook'. Works by friction between the the sea-floor and the chain links, rather than the hook structure of the anchor itself. So the chain has to be heavy so that it 'drags well' rather than because it is needed to support the weight of a heavy anchor. Is this true?
 

meridian

Member
I have found the code from 2 years ago. I'd be interested if someone can point out why it doesn't always work. (Bad connections aside).
Code:
symbol mic_input = 1
symbol mic_value = b1
symbol trip_point = 160
symbol doorbell = 4
symbol loop_count = b2
symbol beep_count = b3

 'high doorbell

main:
for loop_count = 1 to 3
	readadc mic_input, mic_value
'debug
	if mic_value > trip_point then
	beep_count = beep_count + 1
	endif
	pause 100
next loop_count

if beep_count >= 2 then

high doorbell
pause 500
low doorbell
beep_count = 0
endif
sleep 5
goto main
paulr
 

meridian

Member
Meridian. Hope you don't mind me straying slightly off topic, but I have a nautical question.

I'm lead to understand that the anchor chain does the actual position fixing, not the anchor 'hook'. Works by friction between the the sea-floor and the chain links, rather than the hook structure of the anchor itself. So the chain has to be heavy so that it 'drags well' rather than because it is needed to support the weight of a heavy anchor. Is this true?
Hi boriz,
The anchor and chain have to work together. BTW there as many anchors and theories as there are skippers. The anchor has to dig in, but the chain has to resist the anchor pulling out in the case of gust, wave or tide. The rule of thumb is 'length of chain = 4 * water depth. You want the chain to be flat on the bottom, so that it pulls the anchor in. Too little chain, and a gust can cause the chain to straighten and pull the anchor out. In trying conditions of high winds and waves, you might use 7 to 1. But if in doubt let it all out. As a friend once said "it's no good in the locker".

We think Meridian is about 18 tons. We use a 60lb plow anchor with 66m * 10mm short-link chain, ie the links are made of 10mm rod. 22m = 50kg. With increased depths, you can get away with 3:1, so we can anchor in depths up to (down to?) 20m. In calm conditions, I've seen our anchor lying on it's side and still we didn't move, the chain was the main element. Of course with tide changes every 12 hours, the chain gets dragged around. It still needs that hook to stop it going anywhere.
 

SAborn

Senior Member
I have found the code from 2 years ago. I'd be interested if someone can point out why it doesn't always work.
It might be better to add the 3 ADC readings in the loop, then check it against a trip_point setting, rather than increase a counter on each read.

Looking at the sound recording there is around a 1.5 second burst of sound and then around a 1 second null period, it might be better to look for this wave patten with the picaxe, as it should filter out false alarms.

If it was me i would pre filter the ADC input with a opamp and filter the sound signal to a square wave input to the picaxe.
That could be adjusted and recorder using Audacity as a improvised scope by feeding the square wave into your sound card on the laptop.
If its 5v max input it should not harm the pc audio input..
 

hippy

Ex-Staff (retired)
I have found the code from 2 years ago. I'd be interested if someone can point out why it doesn't always work.
It basically looks for any two incidents of noise 100ms or 200ms apart and triggers. That could explain why it is giving false alarms. There is only a window of looking for an alarm for 300ms every 10 seconds so that is probably why you do not get many of them.

And that short window for detecting the alarm and a long time not doing so is probably why it misses some. It's like turning your phone on only for 5 minutes every hour and wondering why you don't get many calls.
 

lbenson

Senior Member
It seems to me that 'beep_count=0' should be after the endif--otherwise single glitches hours apart will ultimately add up and trigger your alarm.
 

meridian

Member
Use frequency?

Using Audacity (thanks SAborn) the peak frequency is 2540Hz. Can I use this to avoid false alarms? How do I detect it?

paulr
 

Paix

Senior Member
SAborn said:
If its 5v max input it should not harm the pc audio input..
You could always use a pot or voltage divider to scale the signal into the PC audio input rather than overload it, if the level was of concern to you.

Had a scope, but no longer . . . temporary anchor?(rhetorical of course!) Thanks Boriz and Meridian, the explanation about the purpose of the anchor chain wasn't entirely wasted.
 

meridian

Member
FInished!

Well thanks to all who contributed. I was interested in the transition method proposed by Ibenson but I also noted hippy's comments about the sampling. So I thought I might as well try to improve what I've got before heading off in a new direction.

It took ages to talk to the 08. Firstly it seems that my USB converter, although Prolific and fine for the GPS, wouldn't work. So I had to fire up the PC and use the direct COM port. Then I had to remember which way the header went on the breadboard.

I played with various parameters but couldn't get a reliable trigger. Eventually it was probably a combination of things.

Things changed:

Loop now 10 times
pause 10
readadc value reduced to 100
jump out of loop on readadc < 100
reduce pause after doorbell to 100symbol mic_input = 1
set beep_count to 0 outside loop.
sleep 1 before starting again


Alarm_II.bas
symbol mic_value = b1
symbol trip_point = 100
symbol doorbell = 4
symbol loop_count = b2
symbol beep_count = b3

'high doorbell

main:
for loop_count = 1 to 10
readadc mic_input, mic_value
'debug
if mic_value > trip_point then


beep_count = beep_count + 1
else
beep_count = 0
goto main
endif
pause 10
next loop_count

if beep_count >= 8 then

high doorbell
pause 100
low doorbell

endif
beep_count = 0
sleep 1
goto main

Thanks again

paulr
 

Paix

Senior Member
Fear not Boriz, I phrased it badly - as always! :)

I'm sure that you knew about the purpose of the chain and only needed confirmation, or maybe you just knew that people like myself might not really have a clue or never given it two thoughts. I never worked hard enough to earn sufficient cash to make anchor chains an issue for me . . . (decode = I have never progressed past rowing boat operation). The description wasn't wasted upon me. I am the wiser for it.

Even more so having glimpsed Boriz's sensitive side . . . :cool:

It's an interesting application that displays the broad knowledge base of forum members, above and beyond the PICAXE chip itself.
 

meridian

Member
Spoke too soon!

Well, the alarm works great, but still getting false alarms from ambient noise. I will play with different samplings, but I would be interested in using the actual frequency of 2540.

paulr
 

hippy

Ex-Staff (retired)
Well, the alarm works great, but still getting false alarms from ambient noise. I will play with different samplings,
The current program looks for a continuous 80ms signal then activates the alarm. Looking for long periods of tone present - as well as looking for the tone repeating - should improve things.

I would be interested in using the actual frequency of 2540.
You will need to replace your microphone amplifier to get a digital representation of the signal rather than just the 'signal present' indication. Then replace the READADC with COUNT and check that the counted value is within range for the tone's frequency.
 

boriz

Senior Member
...The solution was to fit a piezo inside the case to pick up the beep...
Since you're comfortable accessing the inside, can't you tap the speaker wires directly? It would simplify things and make it completely reliable.

Otherwise...

Can you tap the battery terminals that supply the alarm? You might find a nice clear AC ripple on the DC voltage when the alarm activates. This could be amplified and used as-is to drive a speaker, or used via Picaxe sensing.
 

meridian

Member
Meridian moves at last, alas, alarm failure.

Hi boriz, SAborn and all...

I have just come back to the forum after a long absence. On the 11th March we were quite ill, and made our way to Port Carmen to recover and then for a lot of work on the boat. I tinkered with the loops, etc and got it working well in a relatively quiet environment. Yesterday we made our first excursion since March and are now in Cebu Harbour where there is a lot of constant background noise.

To answer boriz'z question (and also put by Mr Clod Hopper) I can't access the internal speaker as it is all under soldered shield casing. This is a new Furuno GP-32 which replaced the 12 year-old GP31. I had hoped that the new one would have an alarm out but no. So the only way to connect is sonically.

I am using a FutureKit FK408 VOX cct. http://www.futurekit.com/2009/manual/future/eng/PDF_FK4/fk408te-2_a3.pdf. This has a condenser mic into an LM324. There is a sensitivity pot but even on the lowest setting, it still picks up a lot of background noise. Last night it drove us mad with the constant going off, so I switched it off. With my deafness, it is up to my wife to hear the alarm going off.

It seems the only fool-proof method is to detect the 2540Hz tone emanating from the unit. I don't have any M2 parts, so can't use the COUNT command. As SAborn pointed out above, the tone is on for about 1.5 secs, off for 1 sec.

meridian
 

SAborn

Senior Member
Paul,

Good to see you are now well and sailing the high seas once again. (what a life you have)

I think it was Hippy who suggested using count and the 08M still supports the count command.

On a quick look back through the thread and the sound wave patten, i think you could just do ADC samples and look for a patten in the sound wave, as you have about 1.5 seconds of high noise and 1 second of low noise, repeating during an alarm period.

That would mean there should be somewhere around a count of 15 high alarm ADC readings with a 100ms delay between readings.

A idea you could try is in the code below, where a counter (variable) is increased on high alarm signals and decreased on low alarm signals, this way any false short alarm triggers from background noise should be cancelled out.

It will take a little setting up as you first need to find an ADC value that is related to a high alarm tone, (mic_high) then set a low alarm tone value (no tone emitted) that might be just a value of say 50 lower than the high tone ADC, ( mic_low ) to give a little hysteresis between the 2 settings.

Then set a count value to which the remote alarm is triggered at, ( trip_point )

You might need to adjust the "Delay" time to allow for the instruction time the program takes for ADC and sertxd etc to bring the count sample time closer to 100ms.

For 1.5 second of high tone with a 100ms delay between readings would give a count of around 15, less whatever time is lost in other code instructions.

Just an idea for you to ponder over, as its untested and im not even sure how you can test it or set it up.

Code:
symbol mic_value     = b0
symbol counter     = b1

symbol alarm     = b2

symbol mic_input     = C.1
symbol doorbell     = C.4

symbol delay     = 100 'pause time between ADC readings

symbol trip_point = 15  'the count vale the alarm is activated
symbol mic_high    = 500 'the ADC value a alarm tone is registered at
symbol mic_low    = 400 'no alarm tone, just background noise




Main:

    readadc mic_input, mic_value


    If mic_value > mic_high  then
    inc counter
    endif
   
    if mic_value < 100 and counter > 0 then
    dec counter
    endif
   
    if counter >= trip_point then
    counter = 0
    gosub anchor_alarm
    endif
   
    pause delay

'#rem   

    Sertxd ("Mic High = ",#mic_value, 13,10)
    Sertxd ("Counter  = ",#counter, 13,10, 13,10)
   
'#endrem
   
    goto main
   
Anchor_alarm:


    for alarm = 0 to 9
    high doorbell
    pause 100
    low doorbell
    next alarm

    return
 

meridian

Member
Hi SAborn!
Thanks for the suggestion and the code. I am sitting in Cebu waiting for the hearing aids to be returned from Singapore where they are being repaired. Still no use in the alarm detection, I take 'em out at night.

The current code is basically the same as before but does 100 counts instead of 10. What I am finding here is almost constant LED on, with flickers. What I am wondering is do I need a sharp filter at 2500Hz in front of the amp? BTW I had to download Audacity again because the previous laptop went for a swim and didn't like the salt water.

I will study your code and give it a try. Previously I had all the gubbins in an external box. I worked out that there is plenty of space inside the GPS so moved it in. I can generate an alarm any time by changing the mode from anchor to arrival.

BTW(2) I don't know if it has anything to do with the US Govt shutdown, but I am getting many GPS errors today! Sometimes has me .1NM away.

meridian
 

Paix

Senior Member
I don't know if it has anything to do with the US Govt shutdown, but I am getting many GPS errors today! Sometimes has me .1NM away.
meridian
Welcome back.

That's not a good navigational situation to be in close to a rocky shore. Doubtless safety of navigation at sea has been classed as non-essential in their current dilemma. It doesn't do a lot for the US Government's reputation.
 

meridian

Member
Well everyone, you can relax and get on with what you were doing. Once again, it is SOLVED!! (perhaps) I have said this before...

First thing I did was to replace the condenser mic with a Kyocera piezo that I had on hand. At first I thought it wasn't working then realised that it takes nearly a minute for the caps to charge up. My theory anyway. With that in place and adjusting the sensitivity, I got very little response from background noise and reliable triggering of the alarm every second beep.

SAborn, I tried your code but it didn't work, and I wasn't able to monitor the output to see where it was failing.

After I had tested it outside the GPS, I then had to fit it inside the GPS case. Had an intermittent in the power to the doorbell Tx, poor connection, fixed. Worked OK. Put it all together, fitted GPS into the panel with some difficulty, not working!! So I pulled it all apart again, and was testing the relay that suppies power to the doorbell Tx. I then had an 'Oops' moment, connected 12V to the resistor in the transistor cct, and guess what? That went back to pin 4 didn't it? One useless 08. All of the others in the box failed the hardware test, so now I have to use a 14M. That means rewiring the input and output but that's not too difficult.

So, once again, many thanks to the best forum for support and ideas.

Just hope it IS the last time we raise this subject. Just for completeness (and in case I drown this laptop, I'll include the latest version, Alarm_III.bas. Now how do I put it in a box?

Code:
Code:
'Alarm_III.bas
symbol mic_input = pin1

symbol mic_value = b1
symbol trip_point = 100
symbol doorbell = 4
symbol loop_count = b2
symbol beep_count = b3
symbol no_beep_count = b4
symbol found_beep = b5


main:
gosub find_beep
pause 1000
if found_beep = 1 then
	gosub find_beep
endif
if found_beep = 2 then	
	gosub sound_alarm
	found_beep = 0

endif
goto main
end

find_beep:
for loop_count = 1 to 100
readadc 1, mic_value
'debug
if mic_value > trip_point then
	beep_count = beep_count + 1
else
	beep_count = 0
	goto find_beep
endif
pause 10
next loop_count
if beep_count >= 50 then 
	found_beep = found_beep + 1
endif
return

sound_alarm:
high doorbell
pause 500
low doorbell
return

meridian
 
Last edited:

lbenson

Senior Member
>Now how do I put it in a box?

If you mean your code and not your gear, put it within "[ code]" "[ /code]" tags, omitting the spaces I have inserted to keep the text from being interpreted as tags.
 

SAborn

Senior Member
VSAborn, I tried your code but it didn't work, and I wasn't able to monitor the output to see where it was failing.
Sorry i forgot to say you need to use the terminal window to view the data, you access that in PE by pressing F8 or selecting "Picaxe" in the top menu and then "Terminal"

Then select a baud rate of 4800 and data should show on screen.

Perhaps too late now but a worthwhile test to try, because nothing else you will see how to write data back to a computer screen. (very handy to problem solve a circuit)

Just because you killed a pin on a chip dont always mean you killed the chip, and often other pins work fine, but you will normally need to do a "Hard reset" to down load a new program.
 

meridian

Member
Hi boriz, SAborn and all...

I have just come back to the forum after a long absence. On the 11th March we were quite ill, and made our way to Port Carmen to recover and then for a lot of work on the boat. I tinkered with the loops, etc and got it working well in a relatively quiet environment. Yesterday we made our first excursion since March and are now in Cebu Harbour where there is a lot of constant background noise.

To answer boriz'z question (and also put by Mr Clod Hopper) I can't access the internal speaker as it is all under soldered shield casing. This is a new Furuno GP-32 which replaced the 12 year-old GP31. I had hoped that the new one would have an alarm out but no. So the only way to connect is sonically.

I am using a FutureKit FK408 VOX cct. http://www.futurekit.com/2009/manual/future/eng/PDF_FK4/fk408te-2_a3.pdf. This has a condenser mic into an LM324. There is a sensitivity pot but even on the lowest setting, it still picks up a lot of background noise. Last night it drove us mad with the constant going off, so I switched it off. With my deafness, it is up to my wife to hear the alarm going off.

It seems the only fool-proof method is to detect the 2540Hz tone emanating from the unit. I don't have any M2 parts, so can't use the COUNT command. As SAborn pointed out above, the tone is on for about 1.5 secs, off for 1 sec.

meridian
Morning all,

Well I see that its over 3 years since I raised the subject. A lot has happened in the intervening period. The anchor has now been swallowed.

We left Cebu and travelled up to Subic Bay to haul out, replace shaft bearings, etc.From there we headed north to Taiwan for a few weeks before crossing to Japan. There we suffered many typhoons, one a Cat 5 Super Typhoon which was quite trying, but no damage suffered. We wandered our way up from Okinawa to Nagasaki then Fukuoka. We spent some time there (with more typhoons) before heading into the Setonaikai (Inland Sea). Again, we took our time, travelling from island to island before getting to Hiroshima. I had been there several times, but it still is a sobering experience.

From there we finished up at Wakayama, south of Osaka to leave Meridian in the marina. Marinas in Japan are frightfully expensive, but foreigners can sometimes get generous rates. While there, we received an offer for Meridian! Unfortunately the deal fell through. We returned to Sydney for Christmas in 2014.

I had some medical issues, not too bad, but the family wasn't happy about us sailing 4000 odd nautical miles to get back to Australia. We then hired a skipper who in turn recruited crew to assist him. His price was considerably cheaper that other quotes we got. The whole experience was so traumatic I don't want to recount it but suffice to say the boat got back eventually, much later than planned with a broken engine among other things.

After getting a friend to remove the old Detroit engine and install a new Yanmar, shipwright to fix damage sustained in the typhoons, engineer to install new bearings for the shaft and a new propellor (because of the new engine) there was a lot of money spent.

Luckily we got a sale fairly quickly at reduced price of course. This allowed us to start looking for a house after renting for over a year. So I now have a study and workshop that I can re-enter the Picaxe world. I guess I'll have a fair bit of catching up with what's been released.

Cheers
Paul
 
Top