Homemade NMEA multiplexer

Bilge Pump timers

AngusMcDoon,

I have read your posts with interest and admiration and would like to suggest another useful project to keep you busy this winter...

I have been researching simple timer circuits on the net to see if I could make a circuit to operate with a conventional bilge pump switch to control how long the pump stays on for.

This would enable the bilge to be emptied completely, reduce "cycling" as water in the pipe drains back and should help conserve battery charge.

It would enable the automatic bilge switch to be mounted higher. I'm looking for a circuit that is not "always on" and not gradually draining the batteryi.e the bilge switch turns on and then latches on for a certain time.

I'm sure there are commercial options but I'd like to take the "practical Electronics" approach.

Hope that makes sense.

Graham

I would not trust any software to run anything as critical as bilge pump on an unattended boat. No disrespect to the programmers here, but unless you have total confidence in every conceivable possibility, even the simplest software can have traps.
If you decide to do anything clever with a bilge pump, fit a second float switch higher up that is totally mechanical.
If you are into wooden boats that leak, a timer/counter circuit could be useful, to record how many minutes the bilge pump has run in your absence as the boat takes up.

A friend of mine invented a very nasty way of checking on a wooden boat. Get an old mobile phone and secure it just above the floorboards.
If you phone it and it doesn't ring, you have a problem!
 
I would not trust any software to run anything as critical as bilge pump on an unattended boat.

Ever flown on an A320?

"The Airbus series of airliners used full-authority FBW controls beginning with their A320 series"

FBW=Fly By Wire, i.e. no mechanical connection between cockpit control and flight control it is operating
 
Last edited:
It might be worth checking that nothing untoward happens with any combination of devices powered/not powered. Sometimes odd behaviour is possible as the bus tries to power one end via the clamp diodes. (Don't ask!)

My ST60/ST2000 Seatalk system has that feature built in. Instruments on with autopilot off but connected leads to much network wierdness.
 
Ever flown on an A320?

"The Airbus series of airliners used full-authority FBW controls beginning with their A320 series"

FBW=Fly By Wire, i.e. no mechanical connection between cockpit control and flight control it is operating

They've spent zillions of pounds developing their software with rigorous methods.
But allegedly, in the early test flight days, a common phrase from the voice recorder was 'what's it doing now?'!!
 
They've spent zillions of pounds developing their software with rigorous methods. But allegedly, in the early test flight days, a common phrase from the voice recorder was 'what's it doing now?'!!

Ah...that will be my muppetry at work. The R&D on the the rigorous methods was not performed using rigorous methods.

That's why after a software-controlled manipulator moving highly radioactive nuclear waste around a pond in Cumbria crashed into something it shouldn't have I got relegated to working at the local sausage factory.
 
On board computers in 'landing mode' and no way for the pilot to tell it to sod off!
Do you have any proof of this statement, that didn't reach the official investigation? FYI it was an intentional fly over on a flight show that went wrong...

http://aviation-safety.net/database/record.php?id=19880626-0

"PROBABLE CAUSES: "The Commission believes that the accident resulted from the combination of the following conditions: 1) very low flyover height, lower than surrounding obstacles; 2) speed very slow and reducing to reach maximum possible angle of attack; 3) engine speed at flight idle; 4) late application of go-around power. This combination led to impact of the aircraft with the trees. The Commission believes that if the descent below 100 feet was not deliberate, it may have resulted from failure to take proper account of the visual and aural information intended to give the height of the aircraft."
 
Last edited:
Do you have any proof of this statement, that didn't reach the official investigation? FYI it was an intentional fly over on a flight show that went wrong...

http://aviation-safety.net/database/record.php?id=19880626-0

"PROBABLE CAUSES: "The Commission believes that the accident resulted from the combination of the following conditions: 1) very low flyover height, lower than surrounding obstacles; 2) speed very slow and reducing to reach maximum possible angle of attack; 3) engine speed at flight idle; 4) late application of go-around power. This combination led to impact of the aircraft with the trees. The Commission believes that if the descent below 100 feet was not deliberate, it may have resulted from failure to take proper account of the visual and aural information intended to give the height of the aircraft."
Typical beaurocrat report, states the obvious but doesnt say categorically why.

"it may have resulted from failure to take proper account of the visual and aural information intended to give the height of the aircraft."
BUT anyone reading this could also say what nimbus said!
Stu
 
I don't agree. There is nothing at all in the report that could be interpreted as a technical fault that made the aircraft lock itself into that behaviour. Also if I recall correctly the pilot was sentenced to imprisonment.

Also it is a well known fact that had neverbeen contested that the fly over was intentional and planned for a flight show and everything went according to plan until that last moment when the aircraft hit the trees (and except that the fly over was at a lower altitude than planned). So it is in no way a couple of pilots in that aircraft that are struggling trying to get control over an aircraft during all that time the fly over took.
 
Last edited:
"PROBABLE CAUSES: "The Commission believes that the accident resulted from the combination of the following conditions: 1) very low flyover height, lower than surrounding obstacles; 2) speed very slow and reducing to reach maximum possible angle of attack; 3) engine speed at flight idle; 4) late application of go-around power; 5) failure to use a line driver on the RS232 communications link between the PIC processor running the fly-by-wire software and the actuator controlling the elevators. This combination led to impact of the aircraft with the trees. The Commission believes that if the descent below 100 feet was not deliberate, it may have resulted from failure to take proper account of the visual and aural information intended to give the height of the aircraft."

I think cause 5 is the most likely explanation for the crash.
 
Not only are you very unwilling to accept good advice on your feeble little amateur design but you are going on and on and on and on about it when the subject has passed since long.

I expect you'll be calling me ridiculous next.

Also it just jolly bad form to edit something as a quote from someone which isn't.

Who? Me?
 
I can't make out whether you two are seriously p****d with each other or not. I'd like to suggest that the optimum solution for this device would be two outputs: one "balanced" (a la rs422) for talking to NMEA 2.0 and later devices and one referenced to ground (a la rs232) for connecting to PCs. I'd like to have patented this idea but unfortunately Furuno got in first with their GP3x receivers which had just this feature on their NMEA output interface.

(That way the redundant chip would feel needed and might even serve a useful purpose :))
 
I can't make out whether you two are seriously p****d with each other or not...

Not me, I'm totally :D. I can't speak for our newly arrived Swedish friend though because we're on different voltage levels.

As for your idea, I really don't know. I just know about Cumberland sausages. I'm sure an expert will be along soon though.
 
Top