Question:
Thanks. I thought that I had lost my mind. You are speaking about one of those old style rotary displays. I’m sure that this information was all there in your original post, so please accept my apologies. That makes a pile of sense. I’ll bet that I can find an old transponder such as this to use on my system. Your system makes a ton more sense than mine. Now I can see the value of your system. One thought is to get hold of one of these transponders and then I can communicate with it one digital input and one output. Of course, I’ll need to latch the return pulse. I’ll just set it up to reset the latch when I send the pulse. Then, I’ll just pole the input line until it comes high. Too easy. Perhaps a better way would be to have an oscillator and a counter. When you send the pulse, reset the counter and start counting. When the return pulse comes back, just stop the counter. This way, there I could eliminate the polling. I really appreciate your patience. My misunderstanding had me thinking that you were using a derivative of a light saber. I thought that the force was with you. Do you have any data on these old transponders? Do you have any interest in joint development of this system? Thanks again, Tom Brown – Hide quoted text — Show quoted text – Sorry…again, to complicated. You missed a CRITICAL part of my previous post: I have a transponder! This is a device that converts a voltage to a sound pulse, and any sound pulses received, it converts to a voltage. No fancy lasers. So it’s SOUND through water I’m measuring, not light. (as in SONAR). AFAIK, all depth sounders work like this. The rotating LED is the sounder I have now. It’s at least 10 years old, no CPU, no VLSI, just descrete transistors, resistors, etc. And a whirling disk with an LED on it as a display (no LCD). when the LED is at the top, the sounder sends a voltage pulse to the transponder, which is converted to a sound "ping". That "ping" is reflected off the bottom, and returns as a small sound, which is picked up by the transponder and converted to a voltage pulse. Meanwhile, the disk is turning. The longer it takes for the signal to go down to the bottom and return, the farther the disk has spun since the ping was sent out. The LED flashes when the ping returns. There are numbers beside the spinning disk, corresponding to depth. So, if the disk spins 1/4-turn from the output to the return, the LED flashes at "3-oclock", which is marked as 15 feet. If you slow the disk down to the "slow" setting, the same mark means 15 fathoms. It’s a stupidly simple arrangement, and it works very well. Only problem is that you can’t see the LED very well in sunlight. Anyway, this is my current depth sounder. My u-processor controlled one will work basically the same way, using the same transponder, sending it a pulse, and timing the delay until it returns. As you can imagine from the above description, the delay is at least miliseconds, so even a lowly Z80 should be fast enough. (Anybody have the speed of sound in salt water handy?) Lloyd Sumpter "Far Cove" Catalina 36 You’re WAY off onto the complicated end of the spectrum. No kidding. Remember that my current depth sounder is a wheel that spins round, the pulse goes out when an LED is at the top, and it flashes again when the reflection comes. No FFT’s. No sound card. Certainly no microsecond accuracy. Similarly, I’m doing the same thing. Send a pulse by setting a number of the 8 bits to 1, thus putting 5VDC on a number of resistors. This creates a voltage between 0-5VDC on the input of an op-amp, which drives it to the power required for the transponder. ????? I appologise for my ignorance, but you are talking way over my head.
Response:
Yup – that’s why "good" depth sounders include a temp. sensor. But cheap ones don’t, and they seem to work OK. (BTW – would they be calibrated for "salt" or "fresh" water?)
Hmm, that’s a good question. As you can see from the equation, salt water vs. fresh water would change your depth reading by about 2.4% or so, depending on temperature. At shallow depths, temperature is the largest factor. At deeper depths, pressure becomes a factor because the temp becomes constant, but a recreational boater really doesn’t care all that much if their sounder is off when the depths get into the thousands of meters. Salinity is right there in the middle, and is something that might be worth calibrating for. BTW, for the software I write at work, if the operator doesn’t enter a speed of sound, the default I use is 5000 ft/sec. That’s probably a good enough approximation for a salt water depth sounder. But usually the first thing that’s always done is to get a temperature profile of the area. It’s interesting that you bring this up – a lot of folks read their sounders to the nearest 1/10-ft, as if they were really that accurate! As you pointed out, they’re maybe good 5% accuracy. Maybe. Thanks all the same, I’ll keep out of any water where my sounder reads less than 8 feet. You go ahead…
I know from experience that from the where my sounder is located on the hull, when it’s reads 3.9ft I’m ok, when it reads 3.8ft, I start to scrape. I usually set the depth alarm for 6ft. But I have been across large stretches of water where I had to lower the depth alarm to 4ft because it would stay on all the time if I left it at 6ft. Steve
Response:
Yup – that’s why "good" depth sounders include a temp. sensor. But cheap ones don’t, and they seem to work OK. (BTW – would they be calibrated for "salt" or "fresh" water?) It’s interesting that you bring this up – a lot of folks read their sounders to the nearest 1/10-ft, as if they were really that accurate! As you pointed out, they’re maybe good 5% accuracy. Maybe. Thanks all the same, I’ll keep out of any water where my sounder reads less than 8 feet. You go ahead… Lloyd Sumpter "Far Cove" Catalina 36 – Hide quoted text — Show quoted text – fast enough. (Anybody have the speed of sound in salt water handy?) The speed of sound in water is highly variable. It depends on temperature, pressure, and salinity. Here’s an approximate equation to figure it out: c = 1449.2 + 4.6T – 0.055T^2 + 0.00029T^3 + (1.34-0.01T)(S-35) + 0.016z T temperature in degrees Celsius, S salinity in parts per thousand z is depth in meters An accurate depth gauge is an interesting problem because the speed of sound changes as the sound travels down and then back up. Anyway, here’s a few examples, not from the equation above, but actually measured: depth (m) temp (C) salinity (%) speed (m/s) 0 0 0 1402 0 20 0 1482 0 20 3.5 1522 Have fun.:) Steve
Response:
(Anybody have the speed of sound in salt water handy?) Lloyd Sumpter "Far Cove" Catalina 36
1490 meters a second. — Harry Krause My assault rifle IS used for sport I hunt BATF agents
Response:
fast enough. (Anybody have the speed of sound in salt water handy?)
The speed of sound in water is highly variable. It depends on temperature, pressure, and salinity. Here’s an approximate equation to figure it out: c = 1449.2 + 4.6T – 0.055T^2 + 0.00029T^3 + (1.34-0.01T)(S-35) + 0.016z T temperature in degrees Celsius, S salinity in parts per thousand z is depth in meters An accurate depth gauge is an interesting problem because the speed of sound changes as the sound travels down and then back up. Anyway, here’s a few examples, not from the equation above, but actually measured: depth (m) temp (C) salinity (%) speed (m/s) 0 0 0 1402 0 20 0 1482 0 20 3.5 1522 Have fun.:) Steve
Response:
Jumping into this thread a little late, I liket the previous idea of using a cheap sound card for doing the sonar data aquisition. They are already set up to sample analog signals at a programmable rate, so timing won’t be an issue. The post-processing (finding the bottom return) is best done in software. The algorithm for finding the bottom may have to be ‘tweaked’ to optimize it and its easier to tweak software than re-solder hardware. In addition, with a high enough resolution (22 kHz for example) the resolution might be high enough to derive some useable information from the bottom reflection. You might even be able to deduce bottom types. — Disclaimer: This publication is the sole property of monkey #108765 and his typewriter. It does not represent the opinions of any other primate, either alive or dead, or any descendents thereof.
Response:
First of all, a "sound card" requires a PC-slot. It requires a driver, which usually requires Win95/98, which in turn requires a hard drive, display, keyboard… My system requires a $150 SBC with an 8-bit out and 8-bit in ports. Also, done my way, a Z80 is probably enough horsepower – a 68000 would be plenty. Your way, you’d need a 100MHZ Pentium. Finally, if I DO determine "some useable information from the bottom reflection", how do I display it on a 3 1/2 -digit display? Lloyd Sumpter LSumpter Consulting – KISS – Hide quoted text — Show quoted text – Jumping into this thread a little late, I liket the previous idea of using a cheap sound card for doing the sonar data aquisition. They are already set up to sample analog signals at a programmable rate, so timing won’t be an issue. The post-processing (finding the bottom return) is best done in software. The algorithm for finding the bottom may have to be ‘tweaked’ to optimize it and its easier to tweak software than re-solder hardware. In addition, with a high enough resolution (22 kHz for example) the resolution might be high enough to derive some useable information from the bottom reflection. You might even be able to deduce bottom types. — Disclaimer: This publication is the sole property of monkey #108765 and his typewriter. It does not represent the opinions of any other primate, either alive or dead, or any descendents thereof.
Response:
Sorry…again, to complicated. You missed a CRITICAL part of my previous post: I have a transponder! This is a device that converts a voltage to a sound pulse, and any sound pulses received, it converts to a voltage. No fancy lasers. So it’s SOUND through water I’m measuring, not light. (as in SONAR). AFAIK, all depth sounders work like this. The rotating LED is the sounder I have now. It’s at least 10 years old, no CPU, no VLSI, just descrete transistors, resistors, etc. And a whirling disk with an LED on it as a display (no LCD). when the LED is at the top, the sounder sends a voltage pulse to the transponder, which is converted to a sound "ping". That "ping" is reflected off the bottom, and returns as a small sound, which is picked up by the transponder and converted to a voltage pulse. Meanwhile, the disk is turning. The longer it takes for the signal to go down to the bottom and return, the farther the disk has spun since the ping was sent out. The LED flashes when the ping returns. There are numbers beside the spinning disk, corresponding to depth. So, if the disk spins 1/4-turn from the output to the return, the LED flashes at "3-oclock", which is marked as 15 feet. If you slow the disk down to the "slow" setting, the same mark means 15 fathoms. It’s a stupidly simple arrangement, and it works very well. Only problem is that you can’t see the LED very well in sunlight. Anyway, this is my current depth sounder. My u-processor controlled one will work basically the same way, using the same transponder, sending it a pulse, and timing the delay until it returns. As you can imagine from the above description, the delay is at least miliseconds, so even a lowly Z80 should be fast enough. (Anybody have the speed of sound in salt water handy?) Lloyd Sumpter "Far Cove" Catalina 36 – Hide quoted text — Show quoted text – You’re WAY off onto the complicated end of the spectrum. No kidding. Remember that my current depth sounder is a wheel that spins round, the pulse goes out when an LED is at the top, and it flashes again when the reflection comes. No FFT’s. No sound card. Certainly no microsecond accuracy. Similarly, I’m doing the same thing. Send a pulse by setting a number of the 8 bits to 1, thus putting 5VDC on a number of resistors. This creates a voltage between 0-5VDC on the input of an op-amp, which drives it to the power required for the transponder. ????? I appologise for my ignorance, but you are talking way over my head.
Response:
I played around a bit with a rig like that at Uni. If I remember correctly we got a range of about 5m in air! The resolution was about 5cm. The main problem was shaping the pulse to the transducer. You have to dump a lot of energy in at the resonant frequency and a few cycles later damp the resonance QUICKLY. Life is complicated if you are using the same transducer to receive the echoes as we were using 50V rails in the TX amp and the RX amp could NOT take the resulting power level. The TX amp was pretty bombproof as the spec called for indefinite short-circuit capability but we blew a lot of opamps in the RX amp. At one stage I considered adding a valve input stage to buffer and clamp the input levels during the TX pulse. Life was complicated by a small design flaw in the TX amp which meant that it could operate as a 50 MHz power oscillator! You are SURE to have fun just getting a echo trace on a scope. The A/D and software will be the easy bit. – Hide quoted text — Show quoted text – Well, I have an Ace in the Hole – a working transponder. The theory is this: send a pulse to the transponder, count how long before you get a ping back. I’d probably cheat on the D/A and A/D converters – just use 8 bits and some resistors. Of course, there will be some adjustment of detecting the returning ping, as well as how strong the transmitted pulse is. If I wanted to get fancy, I could to that automatically in the programming, but I’ll probably do it manually (I’m only interested in less than, say 100 ft) For calibration, I can either calculate it (using speed of sound through salt water) or take a few measured depths (remember a sounding line?) and calibrate that way. Pretty simple, really. Lloyd Sumpter "Far Cove" Catalina 36 LLoyd: May I ask you you are going to implement the depth sounder? This would be a great feature, but I can’t see how it could be done with a reasonable amount of work. Thanks, Tom Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder. My problem has been to find an inexpensive LCD display that displays two 3-digit numbers in LARGE digits (ie larger than 1/2"). I may end up going your route and using a VGA display and X just to display my two numbers! But if you find a supplier for inexpensive LCDs, let me know! Lloyd Sumpter LSumpter Consulting Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle
–
Response:
You’re WAY off onto the complicated end of the spectrum.
No kidding. Remember that my current depth sounder is a wheel that spins round, the pulse goes out when an LED is at the top, and it flashes again when the reflection comes. No FFT’s. No sound card. Certainly no microsecond accuracy. Similarly, I’m doing the same thing. Send a pulse by setting a number of the 8 bits to 1, thus putting 5VDC on a number of resistors. This creates a voltage between 0-5VDC on the input of an op-amp, which drives it to the power required for the transponder.
????? I appologise for my ignorance, but you are talking way over my head. OK, so you have an LED (laser ?) and a strobe wheel with a single hole (shutter). The wheel rotates causing a pulse of light to emitt. I think I’m with you so far. Please correct me if I’m not. The reflection will be buffered by another op-amp, and a set of comparators will determine how many bits will be set going into the port (OK, maybe I will use an A/D). Alternatively I could set the "other" side of the comparitor with an output from the SBC. The port will be scanned and "standard" debounce software used. If the signal is really noisy, I’ll add some HW debounce. No reflection? increase the output. More than one? pick the first one and decrease the output. And so on…
Reflection buffered? I’m just not following. Do you have a photo transistor, or photo resistor, or photo diode? A voltage change is fed into the op-amp. OK, a comparitor is designed to present the time to an ADC or perhaps a bunch of digital inputs. Sounds like a complicated circuit. Are there ICs to do this (I mean at a higher level than just an op-amp). It sounds fairly complicated. What blows my mind is that it sounds like you are timing a pulse of light. Are you? Are you using an infra-red diode? Are you using a laser diode? OK, so you shine a light. I can’t picture the light bouncing off of the bottom of a lake that has only a few feet of visability. OK, so you find a laser at a frequency that is not as readily absorbed by the water. What then? Will this light really bounce off of the bottom and come back bright enough to activate a photo sensitive device of some kind? Does it have to be aimed perfectly? Wow. 100 feet? Wow. I know that I can tape one channel and watch another (my device to do that has a flashing "12:00"), but I’m having a hard time with this light pulse timing technique. Does it really work? Do the optics need to be ultra-accurate? Here’s how I picture it: | | | diode – | | – | ===shaft==| - | | – | | <- shutter | | <- | <- | psd <- | | (psd = photo sensitive device) | | bottom- | | Remember I’m just looking for depth here, not type of bottom or fish. The output will be buffered, so fish, spurious signals, etc. will be ignored. Weedy bottom, etc. results in a wide, noisy return signal – I’ll just pick the middle.
I too am just looking for depth. Can I buy a transponder such as you describe that will give me an output of some kind that I can just sample with an ADC? Lloyd Sumpter "Far Cove" Catalina 36
Thank you for your patience. This technology is completely new to me. I didn’t know that light could travel through water without being absorbed in a very short distance. Tom Brown
Response:
Get a TI DSP DSK. Built in timers, A/D, D/A, can do FFT’s etc. About $99-$150 and the $150 (6211 DSK) includes a 1 day training class. No stinking MSFT operating system, no LINUX, just embedded programming. One of the Semi makers makes a SONAR chip. Looked at it a few years ago, can’t remember who. Maybe us? Bill
– Hide quoted text — Show quoted text – You’re WAY off onto the complicated end of the spectrum. Remember that my current depth sounder is a wheel that spins round, the pulse goes out when an LED is at the top, and it flashes again when the reflection comes. No FFT’s. No sound card. Certainly no microsecond accuracy. Similarly, I’m doing the same thing. Send a pulse by setting a number of the 8 bits to 1, thus putting 5VDC on a number of resistors. This creates a voltage between 0-5VDC on the input of an op-amp, which drives it to the power required for the transponder. The reflection will be buffered by another op-amp, and a set of comparators will determine how many bits will be set going into the port (OK, maybe I will use an A/D). Alternatively I could set the "other" side of the comparitor with an output from the SBC. The port will be scanned and "standard" debounce software used. If the signal is really noisy, I’ll add some HW debounce. No reflection? increase the output. More than one? pick the first one and decrease the output. And so on… Remember I’m just looking for depth here, not type of bottom or fish. The output will be buffered, so fish, spurious signals, etc. will be ignored. Weedy bottom, etc. results in a wide, noisy return signal – I’ll just pick the middle. Lloyd Sumpter "Far Cove" Catalina 36 That’s kind of what I thought. The problem I have is that I see a bunch of problems. This could be done with a sound card, but that is more complex
programming than the more – Hide quoted text — Show quoted text – simple forms of data acquisition and control. Suppose you use a sound card, find a set of libraries to create the pulse and then sample for a given time period. I would assume fast fourier transforms would be used to pick the pulse out of the noise, but what happens if the bottom is muddy? Won’t this cause some frequency shifting? What happens if you have engine noise in this range clouding the signal? How close to real time can you really get with a PC? I doubt that it would be good enough to provide any depth accuracy. OK, you could take a whole bunch of samples and average them to get something that might be close enough. What about extremely shallow water? It would be great if shallow water could be detected and the software could move the engine into a safe mode (jack plate up, tilt up a bit). How fast will the signal come back? I haven’t taken the time to calculate the propagation time for a sound pulse through water over, say, 6 feet (3 feet of water). It would have to be a pretty short time. Certainly I could deal with millisecond intervals, but
microsecond intervals would more than I would expect from an SBC. Sure, I can get beyond the 32 ms timer resolution, but Linux is a multi-tasking environment (one of the reasons I chose it), so I can’t get that much beyond it safely. What are your plans for picking the return signal out of the noise? How are you going to identify signal reflected off of weeds, fish, etc., from the actual bottom? Clearly some very sophisticated software could be developed to handle all of these things and provide a ton of information about what is down there, but you are
talking about writing – Hide quoted text — Show quoted text – this in assembler. Sorry for all of the questions. You can see from my confusion why I don’t plan on implementing a depth detection function. If you have solved the problem and would consider sharing the solution, that would be extremely interesting to me. Thanks, Tom Brown Well, I have an Ace in the Hole – a working transponder. The theory is this: send a pulse to the transponder, count how long before you get a ping back. I’d probably cheat on the D/A and A/D converters – just use 8 bits and some resistors. Of course, there will be some adjustment of detecting the returning ping, as well as how strong the transmitted pulse is. If I wanted to get fancy, I could to that automatically in the programming, but I’ll probably do it manually (I’m only interested in less than, say 100 ft) For calibration, I can either calculate it (using speed of sound through salt water) or take a few measured depths (remember a sounding line?) and calibrate that way. Pretty simple, really. Lloyd Sumpter "Far Cove" Catalina 36 LLoyd: May I ask you you are going to implement the depth sounder? This would be a great feature, but I can’t see how it could be done with a reasonable amount of work. Thanks, Tom
Response:
You’re WAY off onto the complicated end of the spectrum. Remember that my current depth sounder is a wheel that spins round, the pulse goes out when an LED is at the top, and it flashes again when the reflection comes. No FFT’s. No sound card. Certainly no microsecond accuracy. Similarly, I’m doing the same thing. Send a pulse by setting a number of the 8 bits to 1, thus putting 5VDC on a number of resistors. This creates a voltage between 0-5VDC on the input of an op-amp, which drives it to the power required for the transponder. The reflection will be buffered by another op-amp, and a set of comparators will determine how many bits will be set going into the port (OK, maybe I will use an A/D). Alternatively I could set the "other" side of the comparitor with an output from the SBC. The port will be scanned and "standard" debounce software used. If the signal is really noisy, I’ll add some HW debounce. No reflection? increase the output. More than one? pick the first one and decrease the output. And so on… Remember I’m just looking for depth here, not type of bottom or fish. The output will be buffered, so fish, spurious signals, etc. will be ignored. Weedy bottom, etc. results in a wide, noisy return signal – I’ll just pick the middle. Lloyd Sumpter "Far Cove" Catalina 36 – Hide quoted text — Show quoted text – That’s kind of what I thought. The problem I have is that I see a bunch of problems. This could be done with a sound card, but that is more complex programming than the more simple forms of data acquisition and control. Suppose you use a sound card, find a set of libraries to create the pulse and then sample for a given time period. I would assume fast fourier transforms would be used to pick the pulse out of the noise, but what happens if the bottom is muddy? Won’t this cause some frequency shifting? What happens if you have engine noise in this range clouding the signal? How close to real time can you really get with a PC? I doubt that it would be good enough to provide any depth accuracy. OK, you could take a whole bunch of samples and average them to get something that might be close enough. What about extremely shallow water? It would be great if shallow water could be detected and the software could move the engine into a safe mode (jack plate up, tilt up a bit). How fast will the signal come back? I haven’t taken the time to calculate the propagation time for a sound pulse through water over, say, 6 feet (3 feet of water). It would have to be a pretty short time. Certainly I could deal with millisecond intervals, but microsecond intervals would more than I would expect from an SBC. Sure, I can get beyond the 32 ms timer resolution, but Linux is a multi-tasking environment (one of the reasons I chose it), so I can’t get that much beyond it safely. What are your plans for picking the return signal out of the noise? How are you going to identify signal reflected off of weeds, fish, etc., from the actual bottom? Clearly some very sophisticated software could be developed to handle all of these things and provide a ton of information about what is down there, but you are talking about writing this in assembler. Sorry for all of the questions. You can see from my confusion why I don’t plan on implementing a depth detection function. If you have solved the problem and would consider sharing the solution, that would be extremely interesting to me. Thanks, Tom Brown Well, I have an Ace in the Hole – a working transponder. The theory is this: send a pulse to the transponder, count how long before you get a ping back. I’d probably cheat on the D/A and A/D converters – just use 8 bits and some resistors. Of course, there will be some adjustment of detecting the returning ping, as well as how strong the transmitted pulse is. If I wanted to get fancy, I could to that automatically in the programming, but I’ll probably do it manually (I’m only interested in less than, say 100 ft) For calibration, I can either calculate it (using speed of sound through salt water) or take a few measured depths (remember a sounding line?) and calibrate that way. Pretty simple, really. Lloyd Sumpter "Far Cove" Catalina 36 LLoyd: May I ask you you are going to implement the depth sounder? This would be a great feature, but I can’t see how it could be done with a reasonable amount of work. Thanks, Tom
Response:
That’s kind of what I thought. The problem I have is that I see a bunch of problems. This could be done with a sound card, but that is more complex programming than the more simple forms of data acquisition and control. Suppose you use a sound card, find a set of libraries to create the pulse and then sample for a given time period. I would assume fast fourier transforms would be used to pick the pulse out of the noise, but what happens if the bottom is muddy? Won’t this cause some frequency shifting? What happens if you have engine noise in this range clouding the signal? How close to real time can you really get with a PC? I doubt that it would be good enough to provide any depth accuracy. OK, you could take a whole bunch of samples and average them to get something that might be close enough. What about extremely shallow water? It would be great if shallow water could be detected and the software could move the engine into a safe mode (jack plate up, tilt up a bit). How fast will the signal come back? I haven’t taken the time to calculate the propagation time for a sound pulse through water over, say, 6 feet (3 feet of water). It would have to be a pretty short time. Certainly I could deal with millisecond intervals, but microsecond intervals would more than I would expect from an SBC. Sure, I can get beyond the 32 ms timer resolution, but Linux is a multi-tasking environment (one of the reasons I chose it), so I can’t get that much beyond it safely. What are your plans for picking the return signal out of the noise? How are you going to identify signal reflected off of weeds, fish, etc., from the actual bottom? Clearly some very sophisticated software could be developed to handle all of these things and provide a ton of information about what is down there, but you are talking about writing this in assembler. Sorry for all of the questions. You can see from my confusion why I don’t plan on implementing a depth detection function. If you have solved the problem and would consider sharing the solution, that would be extremely interesting to me. Thanks, Tom Brown – Hide quoted text — Show quoted text – Well, I have an Ace in the Hole – a working transponder. The theory is this: send a pulse to the transponder, count how long before you get a ping back. I’d probably cheat on the D/A and A/D converters – just use 8 bits and some resistors. Of course, there will be some adjustment of detecting the returning ping, as well as how strong the transmitted pulse is. If I wanted to get fancy, I could to that automatically in the programming, but I’ll probably do it manually (I’m only interested in less than, say 100 ft) For calibration, I can either calculate it (using speed of sound through salt water) or take a few measured depths (remember a sounding line?) and calibrate that way. Pretty simple, really. Lloyd Sumpter "Far Cove" Catalina 36 LLoyd: May I ask you you are going to implement the depth sounder? This would be a great feature, but I can’t see how it could be done with a reasonable amount of work. Thanks, Tom Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder. My problem has been to find an inexpensive LCD display that displays two 3-digit numbers in LARGE digits (ie larger than 1/2"). I may end up going your route and using a VGA display and X just to display my two numbers! But if you find a supplier for inexpensive LCDs, let me know! Lloyd Sumpter LSumpter Consulting Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle
Response:
LLoyd: May I ask you you are going to implement the depth sounder? This would be a great feature, but I can’t see how it could be done with a reasonable amount of work. Thanks, Tom – Hide quoted text — Show quoted text – Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder. My problem has been to find an inexpensive LCD display that displays two 3-digit numbers in LARGE digits (ie larger than 1/2"). I may end up going your route and using a VGA display and X just to display my two numbers! But if you find a supplier for inexpensive LCDs, let me know! Lloyd Sumpter LSumpter Consulting Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle
Response:
Well, I have an Ace in the Hole – a working transponder. The theory is this: send a pulse to the transponder, count how long before you get a ping back. I’d probably cheat on the D/A and A/D converters – just use 8 bits and some resistors. Of course, there will be some adjustment of detecting the returning ping, as well as how strong the transmitted pulse is. If I wanted to get fancy, I could to that automatically in the programming, but I’ll probably do it manually (I’m only interested in less than, say 100 ft) For calibration, I can either calculate it (using speed of sound through salt water) or take a few measured depths (remember a sounding line?) and calibrate that way. Pretty simple, really. Lloyd Sumpter "Far Cove" Catalina 36 – Hide quoted text — Show quoted text – LLoyd: May I ask you you are going to implement the depth sounder? This would be a great feature, but I can’t see how it could be done with a reasonable amount of work. Thanks, Tom Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder. My problem has been to find an inexpensive LCD display that displays two 3-digit numbers in LARGE digits (ie larger than 1/2"). I may end up going your route and using a VGA display and X just to display my two numbers! But if you find a supplier for inexpensive LCDs, let me know! Lloyd Sumpter LSumpter Consulting Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle
Response:
There’s a few reasons why you might want SOW rather than SOG. One is for performance – if you put on a new prop or something, you want SOW. The TWO values will tell you what your current is, so you can better calculate fuel consumption, etc. Lloyd Sumpter "Far Cove" Catalina 36 – Hide quoted text — Show quoted text – And i thought that’s what i wanted to know? Speed relative to the earth and not water? Where I’m at, the St-Lawrence river has a flow of 3 to 4 mph, so if I give it just enough throttle to not move, why would i care how fast I go relative to water since I’m going nowhere? GPS will only show speed relative to the earth, not speed through the water. A paddlewheel or piton will be required for that.
Response:
I enjoyed the hell out of writing Z80 assembler a few years back. We had the actually had 256KB of memory available, via bank selecting. We were monitoring high speed data circuts which were running at speeds of 56Kb/s. Thanks for the memories. Bert Robbins
– Hide quoted text — Show quoted text – Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder. My problem has been to find an inexpensive LCD display that displays two 3-digit numbers in LARGE digits (ie larger than 1/2"). I may end up going your route and using a VGA display and X just to display my two numbers! But if you find a supplier for inexpensive LCDs, let me know! Lloyd Sumpter LSumpter Consulting Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle
Response:
Actually this project is for Far Cove – Stinky already has a nice depthsounder/fishfinder and speedo. Far Cove has a very old but still working depth sounder, and a non-working knotmeter that still has a working sender. Lloyd Sumpter "Far Cove" Catalina 36 – Hide quoted text — Show quoted text – Hey Lloyd, that stinkpot of your’s will be well equiped by the time you’re done? :-) hehe Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder.
Response:
Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder. My problem has been to find an inexpensive LCD display that displays two 3-digit numbers in LARGE digits (ie larger than 1/2"). I may end up going your route and using a VGA display and X just to display my two numbers! But if you find a supplier for inexpensive LCDs, let me know! Lloyd Sumpter LSumpter Consulting – Hide quoted text — Show quoted text – Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle
Response:
Hey Lloyd, that stinkpot of your’s will be well equiped by the time you’re done? :-) hehe – Hide quoted text — Show quoted text – Good for you for chosing Linux! I found the Embedded Systems people much more amenable and knowledgeable about linux than the PC crowd. There’s LOTS of SBC’s that run Linux – check out PC104s, etc. Most have Flash-disk technology so you don’t need a mechanical drive at all. I’m looking at a similar project (although probably using a Z80-based SBC and "down to the metal" assembly-language programming). Mine is just for a knotmeter and depth sounder. My problem has been to find an inexpensive LCD display that displays two 3-digit numbers in LARGE digits (ie larger than 1/2"). I may end up going your route and using a VGA display and X just to display my two numbers! But if you find a supplier for inexpensive LCDs, let me know! Lloyd Sumpter LSumpter Consulting Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle
Response:
And i thought that’s what i wanted to know? Speed relative to the earth and not water? Where I’m at, the St-Lawrence river has a flow of 3 to 4 mph, so if I give it just enough throttle to not move, why would i care how fast I go relative to water since I’m going nowhere? – Hide quoted text — Show quoted text – GPS will only show speed relative to the earth, not speed through the water. A paddlewheel or piton will be required for that. Blue Skies, Dave At least for speed, your GPS will show it. Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle My thought is to use an SBC and a very small LCD display (perhaps 4" x 6" or so). I don’t want a giant display or a laptop bolted to my dash. It has to look at least a little tasteful or my girlfriend will kill me. The system would run Linux and it would have an LS120 disk drive. It would all be fairly simple and mostly off the shelf stuff. It could interface with a GPS, but I don’t want to make anything too complicated. This is just a fun project. Further to this, I am thinking that the system could manage some of these systems automatically. For instance, it could monitor speed, RPM and fuel consumption to manage the engine trim. It could collect and log fairly good quality fuel efficiency data that would allow for a pretty good analysis of different props. I’m assuming that something like this doesn’t exist. While I don’t have any plans to sell anything, I don’t want to reinvent the wheel. I’ll need to find or build transducers for some functions, but most are readily available. The one I’m worried about is speed. I would imagine that I could build something using a strain gauge to monitor pressure from the pitot tube, but it would be much easier for me if something was available that I could use directly. I’d rather stick to the electronics and software side of it. What do you guys think? Any ideas or opinions? — Tom Brown
Response:
Not to split hairs, but the poster stated he wanted "hull speed", I assumed he wanted to know how fast the hull was moving through the water. There are If you give it just enough throttle to not move, you probably still have enough water moving over the rudders to maintain steerage. However, if you are going downstream and the GPS shows you are going 3 to 4 mph you essentially have no flow over your rudders and cannot maintain steerage. I too use my GPS as the main indicator of my speed….for the same reasons as you do. I want to know how fast I am getting somewhere, but I also find that the speed through the water is useful too. I can then accurately determine the current speed. I boat in a tidal area where the water may be moving up or downstream, it is nice to know how fast the current may be pushing me before I get into a tight docking area. Blue Skies, Dave
– Hide quoted text — Show quoted text – And i thought that’s what i wanted to know? Speed relative to the earth and not water? Where I’m at, the St-Lawrence river has a flow of 3 to 4 mph, so if I give it just enough throttle to not move, why would i care how fast I go relative to water since I’m going nowhere? GPS will only show speed relative to the earth, not speed through the water. A paddlewheel or piton will be required for that. Blue Skies, Dave At least for speed, your GPS will show it. Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle My thought is to use an SBC and a very small LCD display (perhaps 4" x 6" or so). I don’t want a giant display or a laptop bolted to my dash. It has to look at least a little tasteful or my girlfriend will kill me. The system would run Linux and it would have an LS120 disk drive. It would all be fairly simple and mostly off the shelf stuff. It could interface with a GPS, but I don’t want to make anything too complicated. This is just a fun project. Further to this, I am thinking that the system could manage some of these systems automatically. For instance, it could monitor speed, RPM and fuel consumption to manage the engine trim. It could collect and log fairly good quality fuel efficiency data that would allow for a pretty good analysis of different props. I’m assuming that something like this doesn’t exist. While I don’t have any plans to sell anything, I don’t want to reinvent the wheel. I’ll need to find or build transducers for some functions, but most are readily available. The one I’m worried about is speed. I would imagine that I could build something using a strain gauge to monitor pressure from the pitot tube, but it would be much easier for me if something was available that I could use directly. I’d rather stick to the electronics and software side of it. What do you guys think? Any ideas or opinions? — Tom Brown
Response:
Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle My thought is to use an SBC and a very small LCD display (perhaps 4" x 6" or so). I don’t want a giant display or a laptop bolted to my dash. It has to look at least a little tasteful or my girlfriend will kill me. The system would run Linux and it would have an LS120 disk drive. It would all be fairly simple and mostly off the shelf stuff. It could interface with a GPS, but I don’t want to make anything too complicated. This is just a fun project. Further to this, I am thinking that the system could manage some of these systems automatically. For instance, it could monitor speed, RPM and fuel consumption to manage the engine trim. It could collect and log fairly good quality fuel efficiency data that would allow for a pretty good analysis of different props. I’m assuming that something like this doesn’t exist. While I don’t have any plans to sell anything, I don’t want to reinvent the wheel. I’ll need to find or build transducers for some functions, but most are readily available. The one I’m worried about is speed. I would imagine that I could build something using a strain gauge to monitor pressure from the pitot tube, but it would be much easier for me if something was available that I could use directly. I’d rather stick to the electronics and software side of it. What do you guys think? Any ideas or opinions? — Tom Brown
Response:
At least for speed, your GPS will show it. – Hide quoted text — Show quoted text – Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle My thought is to use an SBC and a very small LCD display (perhaps 4" x 6" or so). I don’t want a giant display or a laptop bolted to my dash. It has to look at least a little tasteful or my girlfriend will kill me. The system would run Linux and it would have an LS120 disk drive. It would all be fairly simple and mostly off the shelf stuff. It could interface with a GPS, but I don’t want to make anything too complicated. This is just a fun project. Further to this, I am thinking that the system could manage some of these systems automatically. For instance, it could monitor speed, RPM and fuel consumption to manage the engine trim. It could collect and log fairly good quality fuel efficiency data that would allow for a pretty good analysis of different props. I’m assuming that something like this doesn’t exist. While I don’t have any plans to sell anything, I don’t want to reinvent the wheel. I’ll need to find or build transducers for some functions, but most are readily available. The one I’m worried about is speed. I would imagine that I could build something using a strain gauge to monitor pressure from the pitot tube, but it would be much easier for me if something was available that I could use directly. I’d rather stick to the electronics and software side of it. What do you guys think? Any ideas or opinions? — Tom Brown
Response:
GPS will only show speed relative to the earth, not speed through the water. A paddlewheel or piton will be required for that. Blue Skies, Dave
– Hide quoted text — Show quoted text – At least for speed, your GPS will show it. Hi Again: I’m toying with the idea of building a digital boat management system this winter. The idea is to use an LCD display to monitor engine and boat telemetry. It would display stuff such as: hull speed (mph) engine speed (RPM) water temperature water pressure cylinder head temperature fuel consumption (gpm) fuel level engine trim angle My thought is to use an SBC and a very small LCD display (perhaps 4" x 6" or so). I don’t want a giant display or a laptop bolted to my dash. It has to look at least a little tasteful or my girlfriend will kill me. The system would run Linux and it would have an LS120 disk drive. It would all be fairly simple and mostly off the shelf stuff. It could interface with a GPS, but I don’t want to make anything too complicated. This is just a fun project. Further to this, I am thinking that the system could manage some of these systems automatically. For instance, it could monitor speed, RPM and fuel consumption to manage the engine trim. It could collect and log fairly good quality fuel efficiency data that would allow for a pretty good analysis of different props. I’m assuming that something like this doesn’t exist. While I don’t have any plans to sell anything, I don’t want to reinvent the wheel. I’ll need to find or build transducers for some functions, but most are readily available. The one I’m worried about is speed. I would imagine that I could build something using a strain gauge to monitor pressure from the pitot tube, but it would be much easier for me if something was available that I could use directly. I’d rather stick to the electronics and software side of it. What do you guys think? Any ideas or opinions? — Tom Brown
Response: