OP
OP
We have to think if this makes sense in other pwm use cases like light and wave maker . Those can involve second or even sub second pwm updates
reef-pi :: An opensource reef tank controller based on Raspberry Pi.
- Thread starter Ranjib
- Start date
-
- Tags
- controller raspberry-pi
- Tagged users Ranjib
I think it would only be good to add for dosing pumps or equipment, lights and other things that "fade" would be an issue.
OP
OP
Yes, but for that we have change Hal layer to expose some api that allows these type of fine grained software based controls. And then implement the same across drivers (pca9685 at minimum ) , jack and then exploit the same from doser module
OP
OP
Meanwhile , just put this wall art on my turn table setup . That Louis Vuitton console is hand made 
. My second year in wood working
. My second year in wood working
AquaKey
New Member
@robsworld78 would the failed i2c command be a concern using the robotank dc driver module? I'm currently using it with a couple dosing pumps.
I don't know about that, having to do tweaks in hardware might be quite the hassle, probably would have to tear the whole controller out of the cabinet rather than just sitting next to the tank with a phone and beakers
Also, having a ml <---> dosing time eventually in addition to the tracking of the pump duration that is done currently would be quite comfortable compared to basic timer functionality
I have no statistics, but i think a majority of people come to reefpi due to the aspect of cost, at least initially, and probably don't want to jump straight ahead to stepper motors, so taking away convenience functions there seems a bit counterintuitive
The safeties i have mentioned seem to work against i2c problems, a few solutions the others mentioned regarding repeating the signal or requesting the status to check the signal was actually received and implemented might fix the problem entirely, no need to throw out the baby with the bathwater
I love steppers too and am grateful that titration is coming to reef pi at some point, my procrastination on building an alk tester with the parts i ordered months ago seems to have worked out, but i don't think requiring people to use stepper dosers for everything or to use them in one interface and dc motors in an entirely different one is such a good idea
OP
OP
i hear you. whenever we plan to make such changes we'll be cognizant of the user facing impact. I dont think you have to do hardware changes. We all understand the hassle involved in it. There will be work around for those scenarios.
But i do think that reef-pi too will have backward breaking changes, its not possible for us to develop software in a future proof way, particularly against older hardware. Its not planned obsolence, its more like new shinies are not being available to older builds. Specially when those new features require newer/different hardware capabilities.
The stepper driver based doser module will bring the volume based user experience (ml instead of seconds for dosing) but retrofitting those for DC motor based setup will involve lot more risk of breaking other stuff without any guarantee that it works as expected. Currently the doser system is a glorified timer module with jack controls and poor user experience. All of its existing feature can be done the timer (scheduled on/off) + light module (fixed PWM value).
I already mentioned the pwm and i2c nuances, its not just about knowing the specifics of how to avoid the current specific issue, but also how that fix will play out for the overall software. If that's not good, we are likely to encounter more bugs and inconsistent behavior. This is the single biggesrt source of bugs (ill thought tactical patches), in my experience (reef-pi and outside). Think of it this way, if i receive a patch that solves the i2c issue for pca9685 and also do not break any other things, i am more than happy to merge that, but currently thats not the case, we have only talked about how to solve the specific issue, not how to prevent that coming in the way for all other aspects (storm simulation, wave maker etc that may require second level pwm control).
All of these are driving my current thought process. Finally, all this is still very much in ideation phase, at the end we'll have what we can come up with design wise and what we can implement in due time. All of that can be very different from what we are discussing now, and likely be more influenced by the contributors thought process. What you can expect though is that we are taking feedback and not bull dozing any honest concerns. The stepper driver is actually the second most asked feature.
Thank you for raising this concern, you gave me some food for thought. You are correct about affordability, its one of the core values of reef-pi. We'll always support dc motor based dosing setup. In fact thats my current method for dosing. I just have to think through the speed control aspect for future works.
FWIW, I expect zero impact with either proposed PCA9685 driver improvement:
- Transacting a write/read to the PCA9685 at 400kHz only costs you an extra 100 microseconds of bus time. Dimming isn't ... that time critical
- Re-writing the same value periodically only happens at idle periods, an update would simply reset the re-write timer (say, 5 second polling re-write same value timer).
#2 is probably the more durable approach, as a power loss or reset of the PCA9685 would quickly bring it back to the expected states. This is predicated on validating that the PCA9685 update does not cause a PWM-glitch, which can be easily tested.
Changes are scary, so, enumerate the impacts instead of always living in fear
OP
OP
Patches welcomeFWIW, I expect zero impact with either proposed PCA9685 driver improvement:
- Transacting a write/read to the PCA9685 at 400kHz only costs you an extra 100 microseconds of bus time. Dimming isn't ... that time critical
- Re-writing the same value periodically only happens at idle periods, an update would simply reset the re-write timer (say, 5 second polling re-write same value timer).
#2 is probably the more durable approach, as a power loss or reset of the PCA9685 would quickly bring it back to the expected states. This is predicated on validating that the PCA9685 update does not cause a PWM-glitch, which can be easily tested.
Changes are scary, so, enumerate the impacts instead of always living in fear
. That driver was broken by contribs twice, I don't think I am talking about fear here , I enumerated the risks. 100ms bus time seems tolerable to me. You are right, in that case, we can pull this straight in the driver.
Meanwhile I'm planning to setup a pca9685 based testing jig . Whatever changes land, I can at least test out the happy path scenarios
It's a concern for anything with I2C as there's no error checking built in so validation and error handling need to be added in the code. It's not so bad with sensors as you'll just get a bogus reading or nothing which can be discarded. The problem is definitely less likely when all I2C devices are on same circuit board, that's how Robo-Tank is and the traces are very short with I2C going to pH circuit being isolated. Also with the DC ports removed it's much less likely any noise gets in. I've also bumped up the 3.3v signals to 5v signals so they are even more defined.
Reliability can really come into play when external wires are used as I2C was only designed to be used on circuit boards but as it's a friendly protocol it's always being used out of spec so you end up with weak signals. Every trace, wire and connector affect things. When data is transmitted over I2C the line is being pulled to a high voltage and low voltage in a sequence, this all happens very fast and if any noise gets in those lines it'll mess up the transmission so it can't be translated.
Last edited:
That’s one thing I don’t have handy myself, though I know I have some chips available somewhere…Patches welcome
100ms bus time seems tolerable to me. You are right, in that case, we can pull this straight in the driver.
Meanwhile I'm planning to setup a pca9685 based testing jig . Whatever changes land, I can at least test out the happy path scenarios
Also, we are at 100us, not even millis, assuming we can start transactions quickly enough through the kernel and the somewhat derpy I2C master hardware in the Raspberry Pi doesn’t bite back (did they ever fix clock stretching?)
Irregardless, the volume is tiny, and focusing on one well known IC is worth testing against.
I believe clock stretching is still an issue. I'm using the ATtiny85 for my pH circuit and due to problems with Pi I have the I2C bus slowed down to 10kHz. I don't see that as bad though unless I'm wrong in assuming a slower speed makes things more reliable overall? It would appear so as you need to slow down as cable is added.
Slower is fine, but it may not help in all cases as the points various controllers sample doesn’t get any slower - they are still gated by rise and fall time. If it’s to allow a slow controller to poke out the next byte, it helps.
What commonly kills I2C is bus capacitance - too much cable and load means the rise and fall times can’t be met. You can mitigate rise time with stronger pull-ups (I tend to use 2.2k), but fall time is all up to the chips driving the bus.
Back when I was trying to solve this I could clearly see on the I2C analyzer that the time for the overall transmission was much longer than at 100kHz which on a busy bus could be a problem but the time between each byte was increased so I figured that would help the master read it in iffy conditions but yeah as it's about rise, fall and edge probably doesn't help. Since I've seen that I've always recommended a person to slow down the bus no matter if required or not thinking that would help with "lost" bytes.
This may be interesting:
Note the rise time maximums are 1000ns in standard mode - they won’t generally scale with the clock, as it’s not known to devices what the clock is.
The inductive undershoot is also relevant for systems with a lot of wire.
Simonv92
Active Member
I all! I'm thinking about using an Rpi Zero 2 (when I'll be able to find it ) to run reef-pi.
I was thinking to add an ethernet port to my Rpi (as you know, cable is always better...). I've seen several guides in which is always use an ENC25J60 module.
This is a quite old 10Mbit Ethernet module, already in production by Microchip. Do you think it'll be ok or do I need to search for something more powerful in terms of speed (even if the limit is the SPI bus)?
I really don't want to use an Rpi 3 or more to run such a lightweight software, I've done some test with an Rpi Zero 1 and it seems to work fine so I'll use a Zero in the final version...
Any advice is appreciated!
) to run reef-pi.I was thinking to add an ethernet port to my Rpi (as you know, cable is always better...). I've seen several guides in which is always use an ENC25J60 module.
This is a quite old 10Mbit Ethernet module, already in production by Microchip. Do you think it'll be ok or do I need to search for something more powerful in terms of speed (even if the limit is the SPI bus)?
I really don't want to use an Rpi 3 or more to run such a lightweight software, I've done some test with an Rpi Zero 1 and it seems to work fine so I'll use a Zero in the final version...
Any advice is appreciated!
I all! I'm thinking about using an Rpi Zero 2 (when I'll be able to find it
I was thinking to add an ethernet port to my Rpi (as you know, cable is always better...). I've seen several guides in which is always use an ENC25J60 module.
This is a quite old 10Mbit Ethernet module, already in production by Microchip. Do you think it'll be ok or do I need to search for something more powerful in terms of speed (even if the limit is the SPI bus)?
I really don't want to use an Rpi 3 or more to run such a lightweight software, I've done some test with an Rpi Zero 1 and it seems to work fine so I'll use a Zero in the final version...
Any advice is appreciated!
Attach Ethernet to the USB port.
Its how every Pi has it attached that isn't the Zero
bishoptf
Valuable Member
Eh I would just go wireless, if you really want to go wired I would go with a model that has a fixed ethernet port on it. I'm sure you can get it to work with some usb adapter but i've not had any issues with the wireless units they have been solid.I all! I'm thinking about using an Rpi Zero 2 (when I'll be able to find it
I was thinking to add an ethernet port to my Rpi (as you know, cable is always better...). I've seen several guides in which is always use an ENC25J60 module.
This is a quite old 10Mbit Ethernet module, already in production by Microchip. Do you think it'll be ok or do I need to search for something more powerful in terms of speed (even if the limit is the SPI bus)?
I really don't want to use an Rpi 3 or more to run such a lightweight software, I've done some test with an Rpi Zero 1 and it seems to work fine so I'll use a Zero in the final version...
Any advice is appreciated!
Simonv92
Active Member
Thank you very much! I'm planning to build a pcb with the Rpi Zero mounted on it. So I really want something that I could integrate on my pcb. I've seen some solution based on RTL8152 chip from Realtek but I couldn't find any official schematic...Attach Ethernet to the USB port.
Its how every Pi has it attached that isn't the Zero
In this way I can mount my Rpi without any cable connected and use pogopin to touch the usb pad under the board...
Similar threads
