reef-pi :: An opensource reef tank controller based on Raspberry Pi.

[Ranjib]

Correct, suggest this goes at the PCA9685 driver level, not much harm in doing a quick back and forth transaction to verify setpoints were.. set.

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

 

[robsworld78]

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

I think it would only be good to add for dosing pumps or equipment, lights and other things that "fade" would be an issue.

 

[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.

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

 

[Ranjib]

Meanwhile , just put this wall art on my turn table setup . That Louis Vuitton console is hand made . My second year in wood working

 

[AquaKey]

PSA:

If you are relying on a PCA9685 for your dosers, it might be wise to incorporate a couple safeties.

If your I2C wiring is susceptible to interference and other problems at all, the signal to start up a pump might be sent through fine, while the signal to stop it might be lost or corrupted. Resulting in the pump running non-stop until the next command is send to the PCA9685.

Had it happen 5 times so far in a couple years (that i know of). Twice it emptied my alk reservoir, once my calcium reservoir.

Steps to mitigate this:

1: Create a dummy doser in the reefpi ui that controls a pin on the PCA9685 where nothing is connected. Run that "doser" every minute for a second or so. I didn't go through the code so I don't know whether this works 100% of the time, but to me, running another doser for a second seems to help the previous lost command go through or resets the pwm or something.

2: I have my pumps connected to the PCA9685 and to power via L298N modules. Previously, i had the pins that control direction hardwired to 3.3V. What you can do instead, is connect than pin to a GPIO and only enable it in the timeframe dosing should happen. I have it set to only activate for a window of 30 seconds at each time dosing should happen. This solution relies on just a voltage or lack thereof and no complicated communications that could be subject to interference. I have the relevant direction pins of all pumps wired together to a single GPIO. Now if everything goes wrong and the first safety fails too, the motor driver is only powered for a couple seconds longer than it is programmed to run normally, instead of potentially minutes to hours until the next scheduled dose.

If the second method fails too, that means reef-pi is hung up entirely, not sure how to fix that without introducing more complexity that can fail, but this has never happened to me.

@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.

 

[elysics]

We do that already for lights. For doser I have to think of . I was thinking to remove the dc motor support from doser altogether, and just have stepper support. Dc motor control can be done by simple timer, rest everything (speed control) can be done outside reef_pi with hardware,

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

 

[Ranjib]

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

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.

 

[theatrus]

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

 

[Ranjib]

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

Patches welcome . 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

 

[robsworld78]

@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.

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.

 

[theatrus]

Patches welcome . 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

That’s one thing I don’t have handy myself, though I know I have some chips available somewhere…

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.

 

[robsworld78]

That’s one thing I don’t have handy myself, though I know I have some chips available somewhere…

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.

 

[theatrus]

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.

 

[robsworld78]

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.

 

[theatrus]

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:

https://www.ti.com/lit/an/slyt770/slyt770.pdf

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]

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!

 

[theatrus]

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!

Attach Ethernet to the USB port.

Its how every Pi has it attached that isn't the Zero

 

[bishoptf]

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!

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.

 

[GaryE]

I second What Tom said. Wireless has been flawless on the pi

 

[Simonv92]

Attach Ethernet to the USB port.

Its how every Pi has it attached that isn't the Zero

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...
In this way I can mount my Rpi without any cable connected and use pogopin to touch the usb pad under the board...