Fermentrack: Fermentation monitoring & BrewPi-www Replacement for Raspberry Pi
- Thread starter Thorrak
- Start date
Help Support Homebrew Talk - Beer, Wine, Mead, & Cider Brewing Discussion Forum:
Bigdaddyale
Well-Known Member
How old was the failed relay?
mothership
Active Member
About 3-4 weeks old. It was the third one to fail.
My setup is outside, so when there’s no beer in the fermenter, I have the temp set to ~40 just to keep things from getting too frosty. So the relay is cycling periodically, but nothing ridiculous like in your video
Bigdaddyale
Well-Known Member
Cut it open like in the video and see if the contacts are welded together.3-4 weeks is a premature failure.
mothership
Active Member
yeah. i think i will tonight.
That’s insane that the relay would be failing with that frequency.
Could the in-rush current be overtaxing the relay? What are you controlling with these relays?
I suppose that a simple heater that is a few hundred watts wouldn't be anywhere close, however.
I suppose that a simple heater that is a few hundred watts wouldn't be anywhere close, however.
mothership
Active Member
I’m controlling a 1500w (I think) heater and an air conditioning unit.
If the heater is 1500w I know it’s too big for the relay. Upon opening up the relay yesterday, my suspicions are confirmed: that relay was burnt to a crisp. The air conditioner relay however, has never burned out.
I’ve re-wired the whole setup to use SSR’s instead. However, when I plugged it in, both SSR’s came on even though the LCD said the system was off. A voltage meter told me 3.3v was coming from both D5 and D0 at the same time. That seemed odd to me
mothership
Active Member
Current wiring
1500 watts? Wth are you heating??
The GPIO pins used for relays are configured as "active low" in the gui, which means "inactive high". You need to "un-invert" those two control signals in Device setup so they will be "high active"...
Cheers!
The GPIO pins used for relays are configured as "active low" in the gui, which means "inactive high". You need to "un-invert" those two control signals in Device setup so they will be "high active"...
Cheers!
Well, 1500 Watts @ 120v is 12.5 amps and your initial relays were only designed for 10 amps.
Edit: Correction, as it looks like your relays were good to 15 amps at 125V. Probably a little closer than I would want to be, but not out of limits.
Edit2: Hopefully the SSR's solve your problem. I agree with Day_trippr IRT inverting the pins.
Last edited:
mothership
Active Member
Yeah. I realize it’s kind of an ‘uh duh’ on my part. Senior moment
@day_trippr : I’m heating several gallons of glycol. This whole setup is on a jacketed fermenter
I’ll try to in-invert the pins. Let ya know how it works.
Thanks for the tip
Last edited:
mothership
Active Member
Un-inverting the pins seemed to work. Thanks again for the tip.
BTW: if you guys are ever in Denver, I’m sure I owe you a beer
The fermenter setup:
Last edited:
Hi,
I just upgraded my old Arduino BrewPi to Fermentrack. Since the SD-Card switched to read only mode and new brews weren't logged anymore, I would have needed to reinstall anyway. After finishing the installation and setup process, I have to say: Best decision I could have made! Thanks a lot for the work Thorrak!
After playing around with all the settings and options, Iam left with two questions I have not found answers to by going quick through this thread:
1. Is there a way to toogle which graphs are plotted in the Dashboard chart? With the "normal" brewpi www I toogled everything exept the beer-temp and the chamber-temp off. I don't need to see the beer or fridge setting.
2. Is there a way to see the measured gravity from my iSpindel in Plato unit? Since here in Germany we normaly don't use SG but Plato, I would always have to convert with a converter to get an accurate number I can relate to. Since I've been using the iSpindel for a couple of brews now, I know that the firmware of the iSpindel itself can show the gravity either in SG or Plato.
Greetings from Germany
Stephan
I just upgraded my old Arduino BrewPi to Fermentrack. Since the SD-Card switched to read only mode and new brews weren't logged anymore, I would have needed to reinstall anyway. After finishing the installation and setup process, I have to say: Best decision I could have made! Thanks a lot for the work Thorrak!
After playing around with all the settings and options, Iam left with two questions I have not found answers to by going quick through this thread:
1. Is there a way to toogle which graphs are plotted in the Dashboard chart? With the "normal" brewpi www I toogled everything exept the beer-temp and the chamber-temp off. I don't need to see the beer or fridge setting.
2. Is there a way to see the measured gravity from my iSpindel in Plato unit? Since here in Germany we normaly don't use SG but Plato, I would always have to convert with a converter to get an accurate number I can relate to. Since I've been using the iSpindel for a couple of brews now, I know that the firmware of the iSpindel itself can show the gravity either in SG or Plato.
Greetings from Germany
Stephan
Hi,
I'm picking my build up after 4 years of stagnation (life). There's been a heck of a lot done since then! Thanks for all the hard work!
Anyway, I did a clean install of Raspbian Buster on my Pi 2. Then I went through the Fermentrack install using the single command fully automated method. The installation completed with no errors, however I'm getting the 502 bad gateway error that it looks like some folks were getting back in 2018. Appreciate any help!
I'm picking my build up after 4 years of stagnation (life). There's been a heck of a lot done since then! Thanks for all the hard work!
Anyway, I did a clean install of Raspbian Buster on my Pi 2. Then I went through the Fermentrack install using the single command fully automated method. The installation completed with no errors, however I'm getting the 502 bad gateway error that it looks like some folks were getting back in 2018. Appreciate any help!
Attachments
I got a solution for this one myself. For the unwanted lines I chenged the colorcodes in the Django Admin Panel to #FFFFFF which is white. The lines aren't invisible, but you just see them on the blue and red cooling/heating indicators and when the cross one of the visible lines. Thats good enough for me.
For the SG - Plato conversion "I still haven't found what I'm looking for" (sponsered post by U2 ;-))
There currently isn't a way to save which graphs are shown, but if you click the icon in the legend it will hide the lines and adjust the graph scaling. Or you can use the solution you found and just set them to #FFFFFF
(Took me a second to realize that was you responding to your own post -- Good way to do it!)There isn't a feature to do this at the moment, but I don't see any reason why it couldn't theoretically be added. Open up an issue on GitHub and I'll see about adding it in a future release.
That's odd... Have you tried restarting the Pi? If you have, and it still isn't working, try SSHing into your pi, changing to the fermentrack user, going to the ~/fermentrack directory, then check what the last few lines are of your logs. All said, the commands you would run should be something like this:
- sudo su fermentrack
- cd ~/fermentrack
- tail -30 upgrade.log
- tail -30 log/fermentrack-stderr.log
- Joined
- Dec 11, 2019
- Messages
- 15
- Reaction score
- 3
I was having the same issue, here is the nginx and circusd logs from my pi.
It looks like circus has been upgraded recently, https://github.com/circus-tent/circus/releases. I updated the pyzmq package to the latest and restarted my pi. Fermentrack appears to be working now.
Thanks for noticing that - sure enough that looks like the issue! I've patched both master and dev to fix this going forward.
Hi. Fermentrack is amazing. Hats off to the author. I cannot get my tilt readings to update though.
I decided to go down the TiltBridge route as an option but cannot flash the ESP32 I purchased which is a shame as it's a perfect form.
https://www.amazon.com/gp/product/B07R48W8R8/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
This is the log
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting.....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: d8:a0:1d:56:e2:94
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
A fatal error occurred: Timed out waiting for packet header
I decided to go down the TiltBridge route as an option but cannot flash the ESP32 I purchased which is a shame as it's a perfect form.
https://www.amazon.com/gp/product/B07R48W8R8/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
This is the log
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting.....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: d8:a0:1d:56:e2:94
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
A fatal error occurred: Timed out waiting for packet header
Thank you for the response. I opened an issue on GitHub.
One mor thing came up today. It seems that at 04:55:39 this morning the logging got an error with the iSpindel. Both, the gravity and the iSpindel temperature are showing zero, which is messing up the scaling of the gravity graph. The whole gravity line will now be flat, since the scale is now shown from 0 to 1.063.
It is strange, since the iSpindel sends a signal every 15 minutes and in the iSpindel dashboard the normal value is shown at 04:58:41, 3 minutes after the error occured.
My first question is, what could have happened? The second one is, if there is a way to delete the one messed up logging point, so the scaling gets normal again?
Thanks in advance
Stephan
One mor thing came up today. It seems that at 04:55:39 this morning the logging got an error with the iSpindel. Both, the gravity and the iSpindel temperature are showing zero, which is messing up the scaling of the gravity graph. The whole gravity line will now be flat, since the scale is now shown from 0 to 1.063.
It is strange, since the iSpindel sends a signal every 15 minutes and in the iSpindel dashboard the normal value is shown at 04:58:41, 3 minutes after the error occured.
My first question is, what could have happened? The second one is, if there is a way to delete the one messed up logging point, so the scaling gets normal again?
Thanks in advance
Stephan
Thank you both! I’m traveling today but will give that a try when I get home.
Edit: The patch worked. I’ve got up and running now. Thanks Thorrack!
Last edited:
Just an update. I did manage to flash the device manually. I'm not a linux guy but ended up having to sudo pip install esptool instead of just pip install esptool and I had to copy the firmware files to the pi folder but it is a nice ESP32 board.
Hi.
I've looked around and read through the posts but I can't seem to get continuous reading from my blue tile. I added a Tiltbridge to the set up in case this was the issue. The PI and the tiltbridge are maybe 3ft from the device itself. The tilt iphone app keeps updating but fermentrack only shows the gravity the same which was the reading at the start of the log. I do have the tiltbridge paired with my tempreture controller which is recording fine.
Thanks in advance if anybody can help
Neal
I've looked around and read through the posts but I can't seem to get continuous reading from my blue tile. I added a Tiltbridge to the set up in case this was the issue. The PI and the tiltbridge are maybe 3ft from the device itself. The tilt iphone app keeps updating but fermentrack only shows the gravity the same which was the reading at the start of the log. I do have the tiltbridge paired with my tempreture controller which is recording fine.
Thanks in advance if anybody can help
Neal
private4587
Active Member
- Joined
- Sep 23, 2016
- Messages
- 33
- Reaction score
- 0
i Thorrak thanks for your drawing, so if i have it right i need 2 temp sensors, 1 breakout board, 1 mainboard and some RJ45 connectors and cable. do you have a link for these boards and BOM of parts required. I do not at this moment intend using a LCD screen but may do in future. Many thanks
Fermentrack can listen to the tilts via Bluetooth or TiltBridge. If you start a log and Fermentrack is listening to the tilt via Bluetooth, and later you change the connection to TiltBridge, your log will continuously log the the last gravity number recorded via Bluetooth.
You would need to stop your log. Change how Fermentrack listens for the tilts to TiltBridge, and then start a new log.
private4587 said:
I put together a BOM for my Fermentrack build. If you think you want an LCD screen in the future, you’ll need the PCB recommended in the post below. If you never plan to use an LCD, you can use a different Thorrak designed PCB.
My Fermentrack Build
Right this second, I do not. I went through and redesigned all the PCBs over the past few weeks to attempt to align the footprints (and combine designs when possible) but am waiting on my sample PCB to arrive so I can test before I make the designs public. Given some issues I had with a similar design I don’t want to make this one public until I’m assured that it won’t - at a minimum - suffer from the same issue that design had.
As part of this effort I also pulled together BOMs that can either be uploaded directly to DigiKey or through creative searching at AliExpress for each of the PCBs. That said, you are correct - the easiest builds for an ESP8266-based BrewPi controller would need the parts you listed plus the D1 Mini, power supply, and relay.
Is the TiltBridge screen updating?
Speak of the devil...
Hi all,
Have spent several days trying to work this through, but have now hit a wall and hoping someone in here can help.
Have installed Fermentrack on a laptop that has Debian Jesse. Have got through the setup, ESP8266 flash, but can't setup the sensors & pins. Looks like a firmware issue but have tried a few different versions of firmware (.11 and .10 as recommended), reflashed a few times all to no avail.
Connection Debug looks like this :
Tests Performed
Test Parameter Pass/Fail Output
Device Status Test active Passed Device active & managed by Circus
DNS Lookup Test 192.168.0.14 Passed 192.168.0.14
Connection Test 192.168.0.14 Passed Connected
Controller Response Test 192.168.0.14 Failed
Cached IP Test 192.168.0.14 Passed Available
Connection Test 192.168.0.14 Passed Connected
Controller Response Test 192.168.0.14 Failed
I've been using the IP address because the dns resolution on the .local names doesn't appear to be working.
Log looks like this :
Jan 03 2020 03:10:55 Connection type WiFi selected. Trying TCP serial (WiFi)
Jan 03 2020 03:10:55 Connecting to BrewPi 192.168.0.14 (via 192.168.0.14) on port 23
Jan 03 2020 03:11:04 Successfully connected to controller.
Jan 03 2020 03:11:04 Notification: Script started, with no active beer being logged
Jan 03 2020 03:11:14 Checking software version on controller...
Jan 03 2020 03:11:14 Found BrewPi v0.2.4, running commit 00000000, running on an ESP 8266 on port 192.168.0.14:23
Jan 03 2020 03:11:14 BrewPi version received was 0.2.4 which this script supports in 'legacy' branch mode.
Jan 03 2020 03:11:14 Bound to TCP socket on port 2285, interface localhost
Jan 03 2020 03:11:15 Installed devices received: []
Jan 03 2020 03:11:18 Available devices received: [{"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 27.188, "a": "28124294970603B4", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 26.688, "a": "286B3D94970603B8", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 16, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 14, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 13, "x": 1}]
Jan 03 2020 03:11:31 Lost connection to controller on read. Attempting to reconnect.
Jan 03 2020 03:11:36 Lost connection to controller on write. Attempting to reconnect.
Jan 03 2020 03:11:36 Serial Error: [Errno 9] Bad file descriptor)
Jan 03 2020 03:11:39 Unable to connect to BrewPi 192.168.0.14 on port 23. Exiting.
Jan 03 2020 03:12:48 Error: controller is not responding to new data requests. Exiting.
Have spent several days trying to work this through, but have now hit a wall and hoping someone in here can help.
Have installed Fermentrack on a laptop that has Debian Jesse. Have got through the setup, ESP8266 flash, but can't setup the sensors & pins. Looks like a firmware issue but have tried a few different versions of firmware (.11 and .10 as recommended), reflashed a few times all to no avail.
Connection Debug looks like this :
Tests Performed
Test Parameter Pass/Fail Output
Device Status Test active Passed Device active & managed by Circus
DNS Lookup Test 192.168.0.14 Passed 192.168.0.14
Connection Test 192.168.0.14 Passed Connected
Controller Response Test 192.168.0.14 Failed
Cached IP Test 192.168.0.14 Passed Available
Connection Test 192.168.0.14 Passed Connected
Controller Response Test 192.168.0.14 Failed
I've been using the IP address because the dns resolution on the .local names doesn't appear to be working.
Log looks like this :
Jan 03 2020 03:10:55 Connection type WiFi selected. Trying TCP serial (WiFi)
Jan 03 2020 03:10:55 Connecting to BrewPi 192.168.0.14 (via 192.168.0.14) on port 23
Jan 03 2020 03:11:04 Successfully connected to controller.
Jan 03 2020 03:11:04 Notification: Script started, with no active beer being logged
Jan 03 2020 03:11:14 Checking software version on controller...
Jan 03 2020 03:11:14 Found BrewPi v0.2.4, running commit 00000000, running on an ESP 8266 on port 192.168.0.14:23
Jan 03 2020 03:11:14 BrewPi version received was 0.2.4 which this script supports in 'legacy' branch mode.
Jan 03 2020 03:11:14 Bound to TCP socket on port 2285, interface localhost
Jan 03 2020 03:11:15 Installed devices received: []
Jan 03 2020 03:11:18 Available devices received: [{"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 27.188, "a": "28124294970603B4", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 26.688, "a": "286B3D94970603B8", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 16, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 14, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 13, "x": 1}]
Jan 03 2020 03:11:31 Lost connection to controller on read. Attempting to reconnect.
Jan 03 2020 03:11:36 Lost connection to controller on write. Attempting to reconnect.
Jan 03 2020 03:11:36 Serial Error: [Errno 9] Bad file descriptor)
Jan 03 2020 03:11:39 Unable to connect to BrewPi 192.168.0.14 on port 23. Exiting.
Jan 03 2020 03:12:48 Error: controller is not responding to new data requests. Exiting.
Hmm. What is the behavior you are seeing? Is it connecting for awhile, then dying? Are you not able to get it to work at all?
The connection test you posted is weird, as it looks like it is connecting then dying pretty soon thereafter — which appears to be supported by the logs as well.
Do you happen to have another installation of Fermentrack running (or BrewPi remix)? Have you tried the serial firmware?
Thanks for the quick reply.
I don't think there is any other installation running although I may have tried to install BrewPi on it a while back when I was mucking around and looking at software options a few months back. This is my first crack at an auto ferm system. I've built the ESP8266 hardware. I had the latest brewpiless firmware running on it without any issues but wanted to try fermentrack.
I haven't tried the serial firmware, I could try that if it helps debug.
BPL shouldn’t create any issues. The reason I was asking is that if something else tries to connect to the controller (like a second install of Fermentrack, BrewPi Remix, the debug connection script, what have you) it will prompt the controller to disconnect the existing connection to accept the new one. The serial firmware would help debug if the issue is hardware/firmware/script related or connection related.
That said - what symptoms exactly are you experiencing here?
Sorry I missed your initial questions.
Initial connection appears to go OK. LCD output appears on the device dashboard. When I go to try and Configure sensors and pins, all the devices show up as expected but when I try to assign a device to a function I get "Failed to write the configuration to the controller"
Logs :
Jan 03 2020 03:13:11 BrewPi version received was 0.2.4 which this script supports in 'legacy' branch mode.
Jan 03 2020 03:13:11 Bound to TCP socket on port 2285, interface localhost
Jan 03 2020 03:13:12 Installed devices received: []
Jan 03 2020 03:13:14 Available devices received: [{"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 27.188, "a": "28124294970603B4", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 26.688, "a": "286B3D94970603B8", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 16, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 14, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 13, "x": 1}]
Jan 03 2020 05:41:55 Received applyDevice request, updating to: {"i": 0, "c": 1, "b": 1, "f": 9, "h": 2, "p": 12, "j": null, "a": "28124294970603B4"}
Jan 03 2020 05:41:58 Device updated to: {"i":0,"t":0,"c":-106,"b":19,"f":40,"h":0,"d":0,"p":3}
Jan 03 2020 05:41:58 Controller debug message: ERROR 8: Cannot assign device type 0 to hardware 2
Jan 03 2020 05:41:58 Installed devices received: []
Jan 03 2020 05:41:58 Controller debug message: ERROR 3: Device definition update specification is invalid
Jan 03 2020 05:41:58 Available devices received: [{"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 27.563, "a": "28124294970603B4", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 26.625, "a": "286B3D94970603B8", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 16, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 14, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 13, "x": 1}]
Jan 03 2020 05:42:01 Installed devices received: []
Jan 03 2020 05:42:01 Available devices received: [{"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 27.563, "a": "28124294970603B4", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 2, "d": 0, "p": 12, "v": 26.625, "a": "286B3D94970603B8", "j": 0.0}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 16, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 14, "x": 1}, {"i": -1, "t": 0, "c": 1, "b": 0, "f": 0, "h": 1, "d": 0, "p": 13, "x": 1}]
That sounds like the classic flash initialization issue. Have you tried hitting the “Reset EEPROM” button? Alternatively, flash the wiring test firmware and let it run to completion - it will also initialize everything for you.
I really should have read through that full page before posting, my apologies. Yes resetting the EEPROM fixed it.
Thanks so much for the great piece of work and great support.
It... helps when it’s a known bug.
There is a potential fix but it only became a possibility with a recent release of the ESP framework. It will be part of the next release - whenever I have a major feature to release.
Hey y'all, built a second controller based on the @CadiBrewer shield, and having a weird issue with the rotary encoder. Pressing the knob successfully wakes the LCD display and highlights separate fields to change values (i.e. Control Mode, temp value, etc.) However, when the knob is turned in either direction, it isn't changing values. I built another controller the same way and it works fine. Everything is controllable in the Fermentrack interface, so I can confirm all the pins and sensors are configured. Anything else I should check? Maybe just a bad encoder?
Pin configuration for encoder:
SW ——> Pin 7
DT ——> Pin 8
CLK —-> Pin 9
Pin configuration for encoder:
SW ——> Pin 7
DT ——> Pin 8
CLK —-> Pin 9
As an update to the status of the PCB refresh -
The idea behind refreshing the PCBs was to incorporate feedback learned over the course of the past two years that the current design has been out there. Namely, I was looking to:
- Break out two additional power pins to allow the relays to be driven by 5V rather than 3V3
- Swap RJ-11 for RJ-45 to eliminate the crossover vs. straight wiring issue
- Add decoupling capacitors to the 3v3 and 5v lines
- Ensure all boards can fit the same screw mounting pattern/fit the 3D printed case design
- Update the silkscreens for additional clarity
- Replace 3v3 on OneWire for 5v
For whatever reason, although the sensors should support it, when I power the OneWire with 5v rather than 3v3 two of the three sensors I have on my two test breakout boards stop responding. This is true with two separate controller PCB designs and appears (from process of elimination) to be caused by the voltage change. This makes very little sense in theory - but unfortunately I neither have the background or the equipment necessary to snoop on the bus and try to figure out exactly what (electrically) is going on. The one guess I do have is that on my sensor boards I have one probe each from one lot of sensors (2m cable) and two probes each from a second lot (1m cables). To this extent, it would suggest that some of the temp sensors out there just aren’t 5v compatible.
The question then is where to go from here. The way I see it, I can go one of three routes:
- Redesign the board back to 3v3 as that’s what I’ve had success with, and drop the 5v design
- Release the 5v board (as it theoretically should be the more stable of the two) and accept that some sensors (like mine) might not work
- Add a jumper (either pins or solder bridge) to select 3v3 vs. 5v
On a separate note, I think I am going to reconfigure the SMD board to add more space between components - while doing the test solder of the board design I posted I managed to bridge one of the pads to a via. I think they carried the same signal, but it’s embarrassing nonetheless.
