I have done a similar thing in the past, but to flash firmware onto any device with a certain USB descriptor that gets plugged in. It was a mess of USB hubs and cables, but it worked.
What I did was write a udev rule that checks for the vendor and product id of a newly plugged in device and calls a script when there's a match. The script then performs the flashing and logs the output.
In your case:
dd the source USB to a file (make sure the partition you're dding is smalled than any target drive
Udev rule according to your needs (all the same product or different drives?)
Script that dds the file you created earlier back to the newly plugged in drive.
5V or 4.68V input isn't meaningful. The sensor has some input range and 4.68V most definitely falls into that. Could be a design choice that has no real implications.
On the other hand, if the device normally supplies 5V, just yours doesn't, then that's further evidence you have a faulty controller.
My money is on faulty controller at this point, but I think you'll need to find someone with electronics chops if you want to avoid just buying parts until it works again.
For what it's worth, I didn't mean take the sensor out of the wall, but just electrically unplug it from the controller to see what it does on its own when you turn on the water.
A frequency counter won't really help you here, I think. You already know to expect ~VCC/2 when water is running, and either VCC or 0V if it isn't. The speed of the square wave isn't very relevant.
With better tools, it would be easier to troubleshoot more precisely. An oscilloscope would help you understand what's going on, for example.
From what you describe, I'm actually starting to suspect the other end (the controller?) to be the problem.
One idea you could try before buying anything is to disconnect the sensor, supply it with 5V and ground (double check with data sheet!) and see what's happening on the output when there is flow. If you don't measure anything, as I would expect since the pin alternates between a floating state and ground, you then add a 10k or 50k ohms pullup resistor between 5v and output and measure again, and should get the levels you expected to see in the first place.
Don't know if you're comfortable doing this, but maybe you can find somebody to help you out?
These flow sensors are usually hall effect sensors, with two or four magnets attached to a rotor with a little water wheel. When water flows, the magnets turn and create something like a PWM signal at the output (actually it's high level when magnet is there and low level when magnet is not there or vice versa). Measuring the pin with a slow multimeter, this would indeed give you approximately half the supply voltage when water is flowing, depending on a few other factors. So- readings sound sensible to me.
To note that if the rotor stops with a magnet close to the hall effect sensor, you will read 5V (or VCC) at the output, but always VCC/2 when flowing.
Most of these sensors employ an open collector output stage, but that doesn't need to bother you with the readings you're getting, I think.
·7 months ago
·1 year ago
·1 year ago
I have done a similar thing in the past, but to flash firmware onto any device with a certain USB descriptor that gets plugged in. It was a mess of USB hubs and cables, but it worked.
What I did was write a udev rule that checks for the vendor and product id of a newly plugged in device and calls a script when there's a match. The script then performs the flashing and logs the output.
In your case:
ddthe source USB to a file (make sure the partition you're dding is smalled than any target driveEdit. Did this on a rpi3