BruControl: Brewery control & automation software

Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum

Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Dumb question number 2 of 1,000 as I plan my build: for my pressure sensor mounting to the kettle, I'm considering eliminating my sight glasses and using the port for the pressure sensor. The port is 3/8", so I'd need to use a reducer to get it sized up for a 1/2" fitting to connect to a tri-clamp connector. Any problem with having a smaller port that opens up to a wider pipe before the pressure sensor?
 
Good questions. Agreed it is a bit wonky why the calibrations for PIDs and PWMs aren’t the same. Technically the PWM is an “outputted” value from BC and PID is a calculated “inputted” value to BC from the interface. Crappy explanation but it’s the best I have.

Regarding the second question... I’ll have to test it myself. The only reason I could see for doing this is if you have an active-low switched device, like the N-channel FETs mentioned a little while back.

"PID display value is calculated as an input value to BC" vs. "PWM setpoint value is calculated on Output Value from BC" are the words my brain was looking for... thank you.

The scenario is a PWM controlled valve that is cooling, vs a PWM output driving that is heating... It has a dip switch inside to reverse it, but like to leave it default... would be nice to have 100 to 0 be translated to 0 to 255, but probably not worth what I am beginning to see it might entail... 0 to 100 translated to 0 to 255 is fine...
 
Dumb question number 2 of 1,000 as I plan my build: for my pressure sensor mounting to the kettle, I'm considering eliminating my sight glasses and using the port for the pressure sensor. The port is 3/8", so I'd need to use a reducer to get it sized up for a 1/2" fitting to connect to a tri-clamp connector. Any problem with having a smaller port that opens up to a wider pipe before the pressure sensor?

Only one potential issue, and it's minor. The reducer will create a pocket that will be difficult to clean. My opinion, you'll want to disconnect it after every brew day to make sure it gets clean.

Another option, if it's available, is to get an eccentric reducer instead of the typical concentric type. Install it FOB (flat on bottom) and it'll free drain into the vessel it's connected to.
 
Dumb question number 2 of 1,000 as I plan my build: for my pressure sensor mounting to the kettle, I'm considering eliminating my sight glasses and using the port for the pressure sensor. The port is 3/8", so I'd need to use a reducer to get it sized up for a 1/2" fitting to connect to a tri-clamp connector. Any problem with having a smaller port that opens up to a wider pipe before the pressure sensor?

I agree with @TexasWine. Is there anyway that 3/8 port could be a 1/2 instead? Then screw in a 1/2 NPT sensor. Or add an elbow and bushing which creates an air gap and prevents the liquid from contacting the sensor.
 
I agree with @TexasWine. Is there anyway that 3/8 port could be a 1/2 instead? Then screw in a 1/2 NPT sensor. Or add an elbow and bushing which creates an air gap and prevents the liquid from contacting the sensor.
I actually think it might be 1/4" and not 3/8". I can get a sensor with 1/4" NPT. Would I be better off doing that? Obviously I'll figure out if it really is 1/4" first. I was thinking that the tri-clamp would make for easier cleaning, but maybe the air gap will eliminate the need for cleaning after every brew. I was planning on the elbow in either case to put the sensor in a vertical position to make it stick out less.
 
These are nice and Crydom are legit quality. I don’t see any downside other than cost. So long as you only have one or two high current SSRs in the box, and it’s metallic, it should sink enough heat to the atmosphere to transfer heat effectively.

Using these would certainly make things easier to build: cutting, mounting, sealing would be eliminated and wiring would be easier.

Edit: just looked up cost... the 30A unit is under $60. So it’s a good bit more expensive than hockey-puck SSR’s, especially the cheap-o units we normally buy. But good quality and easy installation could be justifiable.
 
Last edited:
These are nice and Crydom are legit quality. I don’t see any downside other than cost. So long as you only have one or two high current SSRs in the box, and it’s metallic, it should sink enough heat to the atmosphere to transfer heat effectively.

Using these would certainly make things easier to build: cutting, mounting, sealing would be eliminated and wiring would be easier.

Edit: just looked up cost... the 30A unit is under $60. So it’s a good bit more expensive than hockey-puck SSR’s, especially the cheap-o units we normally buy. But good quality and easy installation could be justifiable.
So these would not require any fans?
 
Reading through the few pages since last time I was here, I saw a comment on 4-20mA transmitters, but none suggested. I'm going to try out some of these:

http://rover.ebay.com/rover/1/711-5...0001&campid=5338413729&icep_item=142280471283

which take 0-5V in and spit out 4-20mA. I'm planning to use mine for proportional valves. So I'll take the PWM output, filter it (not sure if that is needed, depends on the bandwidth of the opamp circuit on the board) and feed it into this board.
 
So these would not require any fans?

I don’t think so. A metal enclosure that is large enough to house the typical plugs, contractors, breakers, terminal blocks, controller, etc. should easily have enough surface volume to transfer the internal heat to the outside. If I’m wrong or in a stupid hot environment, then maybe a fan is beneficial, but that eliminates the gain of using these.
 
Hi! I'm going to try with pressure sensor for monitoring liquid level in kettles myself. I've been searching forum and there's a lot of information about this. However, I didn't spot any direct choice for it, preferably from Aliexpress. Do you have any obvious choice that worked well for many?
 
Hi! I'm going to try with pressure sensor for monitoring liquid level in kettles myself. I've been searching forum and there's a lot of information about this. However, I didn't spot any direct choice for it, preferably from Aliexpress. Do you have any obvious choice that worked well for many?

here is where to buy it:
https://brucontrol.com/buy/sensors/

You will not find one that worked well for a few , let alone many on aliexpress...
 
If anyone is interested, I have Win10 running BC on a raspberrypi 3 b+ using a fast 32 g A1 speed sd card. There in no wireless working but ethernet connects to the internet. Boot time is 1:20 minutes and after sign in, another 20 seconds. BC comes up ready to go in another 2:30 minutes. Much much faster than running BC through android with XP at 45 minutes. I used this link:
 
Per #1824 above... we've posted FW v44J: https://brucontrol.com/download/firmware/. I know the page says 44 is beta, but I'm confident it can be used as production. Feather users should contact us as the Wiring map is different.

I installed v44j the other day but the interface and the computer would rapidly connect/disconnect for a bit and then not connect at all. I use a Mega over a Serial connection. I ended up switching back to v43 for a brew day. Any others have this experience?
 
Hey @BrunDog and others--I'm working on refining my brew day script after my first brew, specifically attempting to use my mash kettle volume sensor to detect a grainbed restriction/stuck mash situation and adjusting the proportional valve on the other side of the pump to compensate. BrunDog has this in his script in an "automash" loop that checks the mash volume and adjusts the valve if it is above or below a specified range relative to the original mash volume.

Unlike BrunDog's mash volume sensor, mine is mounted to the side of my mash tun, above the false bottom. Is there any way to use a pressure sensor located there to detect a sticking mash? I was talking it over with my friend, and he was of the opinion that if the mash starts sticking and the pump pulls a small vacuum under the false bottom, the pressure above the false bottom will remain more or less the same, thus rendering the pressure sensor, as currently located, fairly useless for detecting a stuck mash. Have any others used a pressure sensor (or flowmeter--I have one of those too) to detect mash problems and automatically adjust their recirculating pump flow in response?

Thanks!
 
Hey @BrunDog and others--I'm working on refining my brew day script after my first brew, specifically attempting to use my mash kettle volume sensor to detect a grainbed restriction/stuck mash situation and adjusting the proportional valve on the other side of the pump to compensate. BrunDog has this in his script in an "automash" loop that checks the mash volume and adjusts the valve if it is above or below a specified range relative to the original mash volume.

Unlike BrunDog's mash volume sensor, mine is mounted to the side of my mash tun, above the false bottom. Is there any way to use a pressure sensor located there to detect a sticking mash? I was talking it over with my friend, and he was of the opinion that if the mash starts sticking and the pump pulls a small vacuum under the false bottom, the pressure above the false bottom will remain more or less the same, thus rendering the pressure sensor, as currently located, fairly useless for detecting a stuck mash. Have any others used a pressure sensor (or flowmeter--I have one of those too) to detect mash problems and automatically adjust their recirculating pump flow in response?

Thanks!

I would believe that with the sensor in that location, no it would not detect a sticking mash for the reasons your friend laid out. Perhaps a flow meter could see the output flow starting to slow down and could throttle the valve that way. Just thinking out loud since I am in a similar scenario.

Joe
 
How about a vacuum sensor on the pump inlet side? If you found a sensor where its range covered a slight negative pressure up to 2 psi or so, you might be able to simply move the sensor location to the pump inlet side and let it read positive volume while it's filling/full, then ignore the reading and watch for a negative value while the pump is on. I think the problem would be sensor accuracy though. Perhaps just moving the normal measurement sensor to the pump inlet side would do the same thing... if it started sticking the mash, you should see a pressure drop.
 
I installed v44j the other day but the interface and the computer would rapidly connect/disconnect for a bit and then not connect at all. I use a Mega over a Serial connection. I ended up switching back to v43 for a brew day. Any others have this experience?

I just tested it, but powered off the computer. It survives resets and unplug/replugs.

How are you powering it? Also, please check the "ArduinoMEGA.brumc" file in your BruControl directory. At the bottom should be a line:
Code:
<PostConnectDelay>10000</PostConnectDelay>

In addition, we would need to check where the problem is happening. Once you power it/reset it, can you communicate reliably to it via the Setup/Debug (termite terminal)? If you transmit a semi-colon, you should get a response "'&23;".
 
I just tested it, but powered off the computer. It survives resets and unplug/replugs.

How are you powering it? Also, please check the "ArduinoMEGA.brumc" file in your BruControl directory. At the bottom should be a line:
Code:
<PostConnectDelay>10000</PostConnectDelay>

In addition, we would need to check where the problem is happening. Once you power it/reset it, can you communicate reliably to it via the Setup/Debug (termite terminal)? If you transmit a semi-colon, you should get a response "'&23;".

Interestingly enough, I have an 8266 that does this intermittently. It will cycle connected/disconnected for a few minutes constantly, but mine connects and is well until the next random time. I pat it no mind since it always reconnects eventually. I have not troubleshot it, at all however.
 
I just tested it, but powered off the computer. It survives resets and unplug/replugs.

How are you powering it? Also, please check the "ArduinoMEGA.brumc" file in your BruControl directory. At the bottom should be a line:
Code:
<PostConnectDelay>10000</PostConnectDelay>

In addition, we would need to check where the problem is happening. Once you power it/reset it, can you communicate reliably to it via the Setup/Debug (termite terminal)? If you transmit a semi-colon, you should get a response "'&23;".

Thank you. I’ll try it again with your suggestions and report back.

I am using a 12v 5a PSU to power the mega.
 
fwiw, using a 60 watt 12VDC power supply on the input to the linear regulator used on a Mega 2560 serves little benefit over something much more modest (eg: a 9VDC @1A wall wart).

The poor little three pin beastie (typically an MC33269D-5.0 in a SOT-23 package) is only rated for 800 milliamps maximum - so, 4 watts total. And that's only if it doesn't bounce off its internal thermal limitation due to the minimal dissipation provided in the typical Mega 2560 implementation.

Now, if you have other uses for the excess 12VDC supply capacity, that's different :)

Cheers!
 
Interestingly enough, I have an 8266 that does this intermittently. It will cycle connected/disconnected for a few minutes constantly, but mine connects and is well until the next random time. I pat it no mind since it always reconnects eventually. I have not troubleshot it, at all however.

I have seen this behavior on my 8266 as well (just polling the A/D, 1-wire, and a counter). I thought it was due to power disturbances from the USB power brick, or little ESDs when I touched it or something. Usually, when it gets into that state if I reboot the 8266 it starts behaving itself. I haven't just waited and saw if it got its brain back or not. I don't think I've observed it without me touching stuff.
 
I have seen this behavior on my 8266 as well (just polling the A/D, 1-wire, and a counter). I thought it was due to power disturbances from the USB power brick, or little ESDs when I touched it or something. Usually, when it gets into that state if I reboot the 8266 it starts behaving itself. I haven't just waited and saw if it got its brain back or not. I don't think I've observed it without me touching stuff.

I saw it on both of my 8266 tonight after a power blip. I video’d it and sent it over to Pete.
 
WiFi devices will occasionally disconnect - that's the nature of the beast and seems to occur even with decent signal strength. I will say in my own experience that upgrading the access point (wireless router) helps, and when I went to a commercial grade AP in my house (UniFi) my whole network got better with many less complaints by my kids of their WiFi being "broken".

The key is the interface reconnects and resumes operation. We made the re connection effort fairly tenacious. That said, I am concerned about any interfaces which do not reconnect or get stuck in a connect/disconnect loop.
 
fwiw, I found when using esp8266 as a network bridge I had to have a "keep alive" script running sending a packet every minute else the idle connection would eventually be dropped...

Cheers!
 
Good stuff. BC and the interfaces communicate null packet message/responses when there are no devices enabled to make sure the connection remains functional. The interfaces go through a network reset sequence if the packets stop for more than a time window of about 10 seconds.
 
Hey all... update on v1.1 Release Candidate: I know I promised to post it, but we found a memory leak that is attributed to the code which updates the cursor in scripts when they are running. That exists within a third-party library we use for the front end, so we have notified the company who developed it for a fix. We feel this is important, so did not want to release it with this. I will keep you updated.

Update on the update. The library vendor has fixed the memory leak for the script cursor. We are waiting for them to release it, then we’ll issue 1.1 RC to current users.
 
I just tested it, but powered off the computer. It survives resets and unplug/replugs.

How are you powering it? Also, please check the "ArduinoMEGA.brumc" file in your BruControl directory. At the bottom should be a line:
Code:
<PostConnectDelay>10000</PostConnectDelay>

In addition, we would need to check where the problem is happening. Once you power it/reset it, can you communicate reliably to it via the Setup/Debug (termite terminal)? If you transmit a semi-colon, you should get a response "'&23;".

Tried again no change in performance. I attached pictures.
IMG_4759.JPG
IMG_4758.JPG
 
Ahhhh, that is a different problem. You must have a lot of devices being activated simultaneously - and this is overloading the serial buffer. You can temporarily resolve this by disabling devices you don’t need right away.

Please email us your most recent log files and your config file.
 
Ahhhh, that is a different problem. You must have a lot of devices being activated simultaneously - and this is overloading the serial buffer. You can temporarily resolve this by disabling devices you don’t need right away.

Please email us your most recent log files and your config file.

Done.
 
Back
Top