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

[bishoptf]

The fiberglass PCB substrate. The cheap Chinese (and US) manufacturers will give you a low temperature grade (Tg130), and let you upgrade to higher grades (Tg150, 170, etc). The Tg is roughly the sustained degrees C it will tolerate before, well, burning up.

Higher Tg is lower chance it will turn black and then stink up everything with the beautiful smell of burned epoxy (really, its an awful smell, please use some sort of fume extractor), which means its more forgiving to rework with hot air.

The cheap stuff survives going through a lead free reflow process "ok" (its pushing its limits) - it also means being careful holding hot air in one spot for too long (more than a minute it probably a bad idea).

Another learning moment, I could have upgraded that on these boards that I am having made, doh! That is good to know, would't be an issue normally I have them add the components but with me doing it might have been a good idea to upgrade that, lol. I will have to figure out which way I want to do them, good information, thanks.

 

[theatrus]

Another learning moment, I could have upgraded that on these boards that I am having made, doh! That is good to know, would't be an issue normally I have them add the components but with me doing it might have been a good idea to upgrade that, lol. I will have to figure out which way I want to do them, good information, thanks.

Try it and see. Most of the time its not worth the cost.

 

[Ranjib]

IIRC, the Reef-Pi driver only sends the PCA9685 register updates when they change state? Perhaps a simple reliability improvement is to periodically just refresh the last known software state to the hardware.

I don't remember if the PCA9685 has glitching problems, but I think it just reloads the new PWM value when the current cycle is done, not immediately reset the count when reloaded.

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,

 

[robsworld78]

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,

It is possible to read the state of a pin on a pca9685. This library shows how to do it, I've confirmed it works great. If say a second or two after a pump is stopped reef-pi can check the state of pin to verify it is off, if not try again.

GitHub - Reinbert/pca9685: This software is a devLib extension to wiringPi http://wiringpi.com/ and enables it to control the Adafruit PCA9685 16-Channel 12-bit PWM/Servo Driver http://www.adafruit.com/products/815 via I2C interface.

This software is a devLib extension to wiringPi http://wiringpi.com/ and enables it to control the Adafruit PCA9685 16-Channel 12-bit PWM/Servo Driver http://www.adafruit.com/products/815 via I2C i...

github.com

 

[theatrus]

It is possible to read the state of a pin on a pca9685. This library shows how to do it, I've confirmed it works great. If say a second or two after a pump is stopped reef-pi can check the state of pin to verify it is off, if not try again.

GitHub - Reinbert/pca9685: This software is a devLib extension to wiringPi http://wiringpi.com/ and enables it to control the Adafruit PCA9685 16-Channel 12-bit PWM/Servo Driver http://www.adafruit.com/products/815 via I2C interface.

This software is a devLib extension to wiringPi http://wiringpi.com/ and enables it to control the Adafruit PCA9685 16-Channel 12-bit PWM/Servo Driver http://www.adafruit.com/products/815 via I2C i...

github.com

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.

 

[theatrus]

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'm less opinionated on the topic here, but I think there is value in having nouns for the type of function you want, as it steers people to the functionality to solve a problem.

That said, the ATO module, for example, doesn't use the same interface for controlling the pump (a Jack), so its already a bit confusing and not isomorphic to equipment if you had a dosing pump performing that function.

 

[Ranjib]

I'm less opinionated on the topic here, but I think there is value in having nouns for the type of function you want, as it steers people to the functionality to solve a problem.

That said, the ATO module, for example, doesn't use the same interface for controlling the pump (a Jack), so its already a bit confusing and not isomorphic to equipment if you had a dosing pump performing that function.

Agree. We have a long way to go in terms of UX

 

[Ranjib]

Aquashella exhibits are almost there. Builds are complete. Have to document them next

 

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