Just number of revolutions with some sort binned time stamps. Approximate time is perfectly fine. I was thinking of binning the revolutions into 5-15 groups. I am not interested in speed, acceleration, or anything else. Peer reviewers will only be interested in total amount of time on the wheel and distance traveled.
No, but ESPNOW is "ready to wear" and extensible without needing to balance comm cables.
So you need elapsed time while the wheel is turning, and the number of revolutions during that time. What would be the maximum number of revolutions (just ballpark) you would need to be able to record? Is it possible that all 48 wheels could be active at the same time?
Would each of the 48 sensors need to have its own I2C address?
I'm just thinking out loud about how this might be done. It's the "48" that makes it complicated.
You would need a little section of "low level" code to simultaneously "shift out" a 48-bit word of sensor states. Nothing "c lang" level which can read quickly, but only one sensor at a time.
Does that mean the wires need to be the same length?
Did some ballparking the other day and we came up with about 240 RPM max, but now I am thinking it may be closer to 300 RPM or 5/s. I just edited my post, I will only need 24 sensors, but they will all need to be active all the time.
I know. That is basically the crux of the problem.
@xfpd suggested using a small board for each sensor and passing that to a receiver board. That is at the upper edge of both my budget and current capability. I really need someone to explain how to do that in a way that I can understand. Like tell me which boards to use what protocol I should use and how and how many transmitter boards I can use on a single receiver board.
It is in the realm of engineering.
Each I2C device needs to connect to the I2C bus through a resistor on each of two wires. I do not know if slightly different resistances cause any negative effect. Maximum devices per bus is 127... unless inter-electrode capacitance causes issues.
A not-so-informative intro: https://www.analog.com/media/en/technical-documentation/product-selector-card/i2cb.pdf
Maybe an accumulator of data (non-real-time, but close) that gets a time slot to send.
The "crux" is simultaneous RPM... that could happen with two sensors on one mcu board.
ESP32/ESP8266 are US$5.00/US$3.00 from Amazon. US$250.00 (plus power supplies), so US$500.00 for an ESPNOW network for "realtime" counts... 20 nodes per network, 48 = 3 networks.
From Espressif:
How far will the farthest sensor be from the arduino?
Any idea how long the HIGH and LOW pulses from the IR sensors will be? Using SPI to input 48 bits from parallel to serial shift registers would be fairly rapid, but you would need to input the data and process it fast enough that a pulse does not occur between samples.
Nice... lengthen the pulse.
Sounds really high. Still waiting for a photo of the wheel..
Wouldn't the MCP23017 / MCP23S17 configured to generate interrupts overcome that?
I was wondering if this could be done with a bunch of cheap popcorn chips. Suppose each of the 24 wheels had a detector and an HC590 counter chip. The wheel would be set up to produce only one tick per revolution, and that would clock the 590. The eight outputs of all the 590s would be connected together on a bus that leads back to the Arduino's GPIO pins.
So then you would set up three HC4017s, which when clocked by the Arduino would bring one and only one output line high. Those outputs would feed into four HC14 hex inverters, and their ouputs would feed to the /OE inputs of the 24 590s.
Then on each clock signal from the Arduino, one and only one of the 590 outputs would become active, and the Arduino would read its current count on the 8 input pins. This would need to be done rapidly because the 590 only counts up to 255.
Well of course the 8 count lines and the 24 /OE lines could be a wiring nightmare, but maybe you could string a ribbon cable from one wheel to the next in sequence. The lines' run lengths could be a problem.
It would be up to the Arduino to keep track of the time, and also keep track of the counts on each wheel.
Actually, if you had three Arduino Nanos, each would have barely enough pins to let you do away with the 4017s and 14s, and just drive the /OE lines directly.
Have a look at how crankshaft sensors work
- typically a 36 toothed wheel with a single missing tooth and sensor - simplier solution
And very accurate positioning accuracy ( deg or so )
Only works for moving wheel and in one direction . See “ Speeduino” project
A Mega2560 would certainly work.
Observations, with ref. to @xfpd's photo.
- There is no shaft on which to mount a sensor, magnet, or other detectable feature
- There is, however, a crossbar that would pass an appropriate sensor twice per revolution
Question for @lab_dad - is that photo an accurate depiction of your apparatus?
Comment as regards to dynamics. 300 RPM is 5 revs per second. If the wheel had any form of detectable feature, that could be translated to 5, or perhaps 10 pulses per second. Times 48(24?) means one will be able to reliably detect changes on any wheel with a scanning routine that takes no more than a millisecond.
Reporting should be a separate discussion, here in this thread. You want to report frequently enough to provide usable data, but not so frequently that the reporting can interfere with the scanning. That probably means high baud rates, and terse messaging.
Digital inputs - this can be done with MCP23017 expanders, 3 of them, and optical sensing. Or, yes, a Mega could do the whole job. But, we need to know distance to sensors, physical distribution, etc.; those details may well indicate a distributed solution makes more sense, perhaps 8 sensors each on 3 processing nodes.
@lab_dad What we need is a reliable 'signal' to detect. Since you've ruled out physical modifications (although I question that, as a 'flag' at 90, 120, 0r 180 would be balanced), how about simply sensing that crossbar, which will give you two short pulses per revolution?
Discussion?
Looking at the photo, if that's the type involved, a little experimenting and ingenuity, it should be possible to find something to sense the rotation. Take it from me, it's no worse a challenge than a waste water works.
You describe it as gross and icky. I hope you clean them now and again.
Surface mount Hall sensors are very small and relatively easy to encapsulate.
I would attach the sensor to the frame and a very small strong magnet on the plate shown in the photo.
Counterbalance it with either a dummy magnet on the opposite side or a second magnet.
You might need to try all sorts of things to get that bit to work.
'twas me, I'd be looking at an emitter-detector pair mounted on either support post, aimed so that the rotating crossarm gave two pulses per revolution. That would be what I would test first, anyway. Would be minimum disruption to the existing arrangement. This does not change the physical characteristics of the wheel itself, at all.
But, answers to post #37 first... @lab_dad ??
Post #15.
Source: I fed and watered about 100 rats every day after school at my mother's laboratory.