Replacement firmware for iSpindel (GravityMon)

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.
I'm pleased to say I have 6 Jeffery 2.69 iSpindels, and one CherryPhilips iSpindel up and running with v1 of you firmware. All running well and calibration was so easy using 7 tabs in a browser. So, many thanks @mper for your brilliant firmware.
I've ordered two d1 mini ESP32 boards out of curiosity now :) How does a bluetooth iSpindel report data? Is a particluar app required?
 
I'm pleased to say I have 6 Jeffery 2.69 iSpindels, and one CherryPhilips iSpindel up and running with v1 of you firmware. All running well and calibration was so easy using 7 tabs in a browser. So, many thanks @mper for your brilliant firmware.
I've ordered two d1 mini ESP32 boards out of curiosity now :) How does a bluetooth iSpindel report data? Is a particluar app required?
Great to hear that it works for you and you like it. For the bluetooth it will use the tilt format so you can use any app that supports that (even the original tilt app). The battery life is still quite bad compared to the esp8266 but im looking into optimizations. Let me know if you have any more ideas or suggestions for improvements. before you solder the esp32 make sure it fits into the tube. It was a tight fit for me and i needed to sand the edge of the esp board to make it fit.
 
mper - I prefer your replacement firmware as it is more versatile than the original, great effort. No issues setting it up to log to Fermentrack however I have been unable to successfully log to BrewBlox using MQTT. The issue is BB needs the path/uri set as well which is brewcast/history (the topic for the history service). The iSpindel firmware puts this between the port and username as the topic. Would you be open to adding this configuration as well? Cheers.
 
mper - I prefer your replacement firmware as it is more versatile than the original, great effort. No issues setting it up to log to Fermentrack however I have been unable to successfully log to BrewBlox using MQTT. The issue is BB needs the path/uri set as well which is brewcast/history (the topic for the history service). The iSpindel firmware puts this between the port and username as the topic. Would you be open to adding this configuration as well? Cheers.
I’ll have a look to see how brewblox works. Im all for supporting as many services as i can.
 
Last edited:
mper - I prefer your replacement firmware as it is more versatile than the original, great effort. No issues setting it up to log to Fermentrack however I have been unable to successfully log to BrewBlox using MQTT. The issue is BB needs the path/uri set as well which is brewcast/history (the topic for the history service). The iSpindel firmware puts this between the port and username as the topic. Would you be open to adding this configuration as well? Cheers.
It looks like brewblox wants a specific format on the mqtt topic. I'm not sure on what the topic would be, but i guess you might know better. I think this format string should do the trick, it looks like these are the params posted by the iSpindel to the mqtt topic. Replace the first text with the name of the mqtt topic/path.

topic_name:{"key":"${mdns}","data":{"Temperature": ${temp-c},"Battery":${battery},"Tilt":${angle},"Rssi":${rssi},"Gravity":${gravity-sg}}}|

This message posted to the topic should look like this:

{
"key": "gravitymon66a1b0",
"data": {
"Temperature": 27,
"Battery": 4.99,
"Tilt": 88.86,
"Rssi": -51,
"Gravity": 1.1173
}
}

Let me know if this works or what error you get. I have not setup a brewblox installation so I cant really test this part.
 
Thanks. I found the topic info here: GitHub - bdelbosc/brewblox-ispindel: DEPRECATED BrewBlox Service for the iSpindel Hydrometer and what appears to be the format for communicating with mqtt event handler in the iSpindel Sender.h library, specifically, 'server, port, topic, username, password, name'. The iSpindel firmware brewblox service setup is the same as regular mqtt with the addition of the topic after the port. As I understand it, the topic details just directs the BB event handler where to post the data so it can be accessed. It works fine with the iSpindel firmware. My initial thought was this is just an issue with a missing communication parameter and not the data format so I haven't researched this yet. I basically assumed your mqtt data format was correct for BB. I'll experiment with what you provided and will get back to you.

Thanks again.
 
Thanks. I found the topic info here: GitHub - bdelbosc/brewblox-ispindel: DEPRECATED BrewBlox Service for the iSpindel Hydrometer and what appears to be the format for communicating with mqtt event handler in the iSpindel Sender.h library, specifically, 'server, port, topic, username, password, name'. The iSpindel firmware brewblox service setup is the same as regular mqtt with the addition of the topic after the port. As I understand it, the topic details just directs the BB event handler where to post the data so it can be accessed. It works fine with the iSpindel firmware. My initial thought was this is just an issue with a missing communication parameter and not the data format so I haven't researched this yet. I basically assumed your mqtt data format was correct for BB. I'll experiment with what you provided and will get back to you.

Thanks again.
the normal mqtt option in the ispindel will just post one data point to a topic while brewblox wants a json document on one topic. The github repo you referenced gave me a few leads to how the data should look. Could not really find anything in the brewblox docs about this format So it might require a little testing to get it right. I dont think i need to change the software, we just need to find the right data format.
 
You sorted it on the first try. I had tried a few things with the data format before posting the query late last night but hadn't properly looked into the data requirements. Thanks heaps.
 
You sorted it on the first try. I had tried a few things with the data format before posting the query late last night but hadn't properly looked into the data requirements. Thanks heaps.
Great news, so if I read the repo readme correct the topic should be brewcast/history ? I will do an update of the docs and would appreciate if you could check if it’s correct
 
Yes, that is what I used, brewcast as the topic and the history service as the path in the format you show above. I'll review the docs once your update is complete.

All five data points have been reporting fine.
 
Yes, that is what I used, brewcast as the topic and the history service as the path in the format you show above. I'll review the docs once your update is complete.

All five data points have been reporting fine.
Great. You can probably add other datapoints if you want to. Let me know if you want help with updating the format template for that. I will add this to the UI in the next version so it can be accessed from the list of pre-defined formats.

I've updated the docs with this service integration here; Service Integration - GravityMon 1.0.0 documentation
 
Will do, there may be a couple additional data points I might try just to see how BB handles it. Really versatile system and I think BB will expand the available fields for a graph or metrics based on what it receives. As I am down-under, temp-c was good but am I correct that if we use just {temp} and {gravity} rather than gravity-sg in the template, whatever unit is configured in the firmware will be sent? If so, that may be a more universal starting point, or is there a benefit of designating the specific units to send?

I should mention that when I test the template, the output isn't formatted like the json message example you show, it is just the template with the variables replaced by actual data from the iSpindel. All of the other selections in the UI do produce the formatted message with the hard returns and indents. Regardless, it works perfectly and the format thing may just be my browser.

For me, the killer features you have included is the ability to enter configuration mode easily, more than one wireless point configuration, configurable data sends, and multiple push targets (currently sending to both Fermentrack and BrewBlox while testing).

Thanks again for producing this.
 
Will do, there may be a couple additional data points I might try just to see how BB handles it. Really versatile system and I think BB will expand the available fields for a graph or metrics based on what it receives. As I am down-under, temp-c was good but am I correct that if we use just {temp} and {gravity} rather than gravity-sg in the template, whatever unit is configured in the firmware will be sent? If so, that may be a more universal starting point, or is there a benefit of designating the specific units to send?

I should mention that when I test the template, the output isn't formatted like the json message example you show, it is just the template with the variables replaced by actual data from the iSpindel. All of the other selections in the UI do produce the formatted message with the hard returns and indents. Regardless, it works perfectly and the format thing may just be my browser.

For me, the killer features you have included is the ability to enter configuration mode easily, more than one wireless point configuration, configurable data sends, and multiple push targets (currently sending to both Fermentrack and BrewBlox while testing).

Thanks again for producing this.

Since the format is just part json you need to omit the mqtt parts to view if correctly, if you take my example and omit the part up to the first : and the | at the end this should render as a json, and once you are satisfied just add the mqtt specific parts.

You can use the device specific settings for temp and gravity. This is the data part and should render i the UI. You can add more parameters as the example Param below.

{"key":"${mdns}","data":{"Temperature": ${temp},"Battery":${battery},"Tilt":${angle},"Rssi":${rssi},"Param": "value", "Gravity":${gravity}}}

If I look into some of the examples for posting data to brewblox it might be possible to specify the data format by adding this to the name tag like; "Temperature[C]" or "Battery[V]". Appreciate if you would try that part and see if it works.
 
Will do and will report back to you tomorrow. It did occur to me that the topic data and the | at the end might have been the reason it didn't render like the others. Thanks for confirming. I did test adding the iSpindel id as well and that worked fine.
 
Will do, there may be a couple additional data points I might try just to see how BB handles it. Really versatile system and I think BB will expand the available fields for a graph or metrics based on what it receives. As I am down-under, temp-c was good but am I correct that if we use just {temp} and {gravity} rather than gravity-sg in the template, whatever unit is configured in the firmware will be sent? If so, that may be a more universal starting point, or is there a benefit of designating the specific units to send?

I should mention that when I test the template, the output isn't formatted like the json message example you show, it is just the template with the variables replaced by actual data from the iSpindel. All of the other selections in the UI do produce the formatted message with the hard returns and indents. Regardless, it works perfectly and the format thing may just be my browser.

For me, the killer features you have included is the ability to enter configuration mode easily, more than one wireless point configuration, configurable data sends, and multiple push targets (currently sending to both Fermentrack and BrewBlox while testing).

Thanks again for producing this.
Thanks for your kind words, really feels good that its appreciated. Thanks for helping out with testing the brewblox setup.
 
As expected, brewblox automatically populates display options for graphs and metrics widgets for every parameter it receives from the iSpindel. So I can add any of the key options you have provided and they show up as a display option. You can also add unit info in brackets as you suggested and BB will use that as part of the default field name for display purposes but this can also be changed. I also have an iSpindel with the recent 7.20 version installed and it sends Temperature[degC] to BB and it automatically named the field as Temperature °C for display when I set it up so Sam must have worked with Eelco/Bob to recognize 'deg' as meaning the degree symbol should be included. The angle field is sent as Tilt[deg] and the default name is Tilt°, cool really.

The only slight issue is BB remembers all field names for a device that has ever been sent even if no longer receiving data with that name. So the field list can be large if testing options like I have. Easy fix however, I'll just rename the device when done.

So my recommendation for what to send to BB by default, to accommodate most users, is:

brewcast/history:{"key":"${mdns}","data":{"Temperature[degC]": ${temp-c},"Temperature[degF]": ${temp-f},"Battery[V]":${battery},"Tilt[deg]":${angle},"Rssi[dBm]":${rssi},"SG":${gravity-sg},"Plato":${gravity-plato}}}|

The user would then just check the fields to display what they desire for their graph or metrics widget without having to customize the data format being sent. I've tested this (with a new mdns!) and it works great including the automatic inclusion of the degree symbol in the field name BB creates.

BB handles Tilts a little differently, as a service like the Spark controllers. The issue with Tilts is the web server (e.g., RPi) has to be close enough to receive the bluetooth signal or a BLE repeater used. They do not communicate with the Spark (no BLE presumably). And there isn't any Tiltbridge integration in BB. So the iSpindel is a better choice for many brewery configurations.

Thanks for taking the time to help sort this out. Cheers.
 
I was testing the gravity temperature correction feature and it doesn't appear to be working. While in configuration mode, corr-gravity-sg and corr-gravity-plato have been added to the data feed and, with the 'Temperature adjust gravity' feature enabled, the results when pressing test are the same values as the uncorrected readout. I did this because the equation used is for degrees F and I was checking to see if the correct temp was used in the calculation. I have the same equation in my iSpindel calibration spreadsheet but with tempC converted to tempF per the source of the equation. If Celsius is used for temp, the calculated result increases the gravity when the temp is below the calibration temp which is the opposite of what it should do.

Regardless, I don't see any adjustment in the readout, at least in configuration mode. I haven't tried sending it to BB or Fermentrack.
 
As expected, brewblox automatically populates display options for graphs and metrics widgets for every parameter it receives from the iSpindel. So I can add any of the key options you have provided and they show up as a display option. You can also add unit info in brackets as you suggested and BB will use that as part of the default field name for display purposes but this can also be changed. I also have an iSpindel with the recent 7.20 version installed and it sends Temperature[degC] to BB and it automatically named the field as Temperature °C for display when I set it up so Sam must have worked with Eelco/Bob to recognize 'deg' as meaning the degree symbol should be included. The angle field is sent as Tilt[deg] and the default name is Tilt°, cool really.

The only slight issue is BB remembers all field names for a device that has ever been sent even if no longer receiving data with that name. So the field list can be large if testing options like I have. Easy fix however, I'll just rename the device when done.

So my recommendation for what to send to BB by default, to accommodate most users, is:

brewcast/history:{"key":"${mdns}","data":{"Temperature[degC]": ${temp-c},"Temperature[degF]": ${temp-f},"Battery[V]":${battery},"Tilt[deg]":${angle},"Rssi[dBm]":${rssi},"SG":${gravity-sg},"Plato":${gravity-plato}}}|

The user would then just check the fields to display what they desire for their graph or metrics widget without having to customize the data format being sent. I've tested this (with a new mdns!) and it works great including the automatic inclusion of the degree symbol in the field name BB creates.

BB handles Tilts a little differently, as a service like the Spark controllers. The issue with Tilts is the web server (e.g., RPi) has to be close enough to receive the bluetooth signal or a BLE repeater used. They do not communicate with the Spark (no BLE presumably). And there isn't any Tiltbridge integration in BB. So the iSpindel is a better choice for many brewery configurations.

Thanks for taking the time to help sort this out. Cheers.
Glad to help, i've updated the docs with your recommendation and will add this to the User interface as a pre-defined template in the next release. Thanks for testing this.
 
I was testing the gravity temperature correction feature and it doesn't appear to be working. While in configuration mode, corr-gravity-sg and corr-gravity-plato have been added to the data feed and, with the 'Temperature adjust gravity' feature enabled, the results when pressing test are the same values as the uncorrected readout. I did this because the equation used is for degrees F and I was checking to see if the correct temp was used in the calculation. I have the same equation in my iSpindel calibration spreadsheet but with tempC converted to tempF per the source of the equation. If Celsius is used for temp, the calculated result increases the gravity when the temp is below the calibration temp which is the opposite of what it should do.

Regardless, I don't see any adjustment in the readout, at least in configuration mode. I haven't tried sending it to BB or Fermentrack.
Ok, I will check the formula and calculation. I have not tested that part very well so I might have done something wrong when implementing the formula.
 
I was testing the gravity temperature correction feature and it doesn't appear to be working. While in configuration mode, corr-gravity-sg and corr-gravity-plato have been added to the data feed and, with the 'Temperature adjust gravity' feature enabled, the results when pressing test are the same values as the uncorrected readout. I did this because the equation used is for degrees F and I was checking to see if the correct temp was used in the calculation. I have the same equation in my iSpindel calibration spreadsheet but with tempC converted to tempF per the source of the equation. If Celsius is used for temp, the calculated result increases the gravity when the temp is below the calibration temp which is the opposite of what it should do.

Regardless, I don't see any adjustment in the readout, at least in configuration mode. I haven't tried sending it to BB or Fermentrack.
I had made a misstake in using C instead of F in the formula and you are right that the correction is decreasing instead of increasing... Will fix this in the next version.
 
Last edited:
After posting I did what I should have done first and checked the code and did confirm that C was being used. However, I couldn't figure out why the correction wasn't being applied with the feature enabled. The testing was done with the iSpindel at 10C so the correction factor would have been 0.9985 and the correction minus 1.5 gravity points when at 1.050. I was monitoring both the gravity and corr-gravity parameters.

Mind you, this isn't a big deal, the impact of krausen and dry hops is much bigger. I had played with temperature correction myself in the past so was just curious how you had implemented it.

Another thing to consider, I'm using panasonic 18650 batteries and, when fully charged, they read 4.22 - 4.23V (voltmeter under a small load). This means the iSpindel will go into configuration mode and stay there until the battery drops down to 4.17V as measured by the iSpindel and voltage factor. What I have to do is log on and lower the voltage factor until it is below the cuttoff (1.53 - 1.56 works, depending on which iSpindel). I typically charge batteries outside of the iSpindel but will test the voltage when charged with the TP5060 to see if there is a difference. My boards are Jeffrey 2.1 with genuine Lolin D1 minis. Not sure if there is a practical solution and still keep the feature as I think the TP5060s charge at 4.20V. I have several and will check. Regardless, my solution works fine and I don't mind the readout being 0.05V low.

Thanks again for the great firmware.
 
After posting I did what I should have done first and checked the code and did confirm that C was being used. However, I couldn't figure out why the correction wasn't being applied with the feature enabled. The testing was done with the iSpindel at 10C so the correction factor would have been 0.9985 and the correction minus 1.5 gravity points when at 1.050. I was monitoring both the gravity and corr-gravity parameters.

Mind you, this isn't a big deal, the impact of krausen and dry hops is much bigger. I had played with temperature correction myself in the past so was just curious how you had implemented it.

Another thing to consider, I'm using panasonic 18650 batteries and, when fully charged, they read 4.22 - 4.23V (voltmeter under a small load). This means the iSpindel will go into configuration mode and stay there until the battery drops down to 4.17V as measured by the iSpindel and voltage factor. What I have to do is log on and lower the voltage factor until it is below the cuttoff (1.53 - 1.56 works, depending on which iSpindel). I typically charge batteries outside of the iSpindel but will test the voltage when charged with the TP5060 to see if there is a difference. My boards are Jeffrey 2.1 with genuine Lolin D1 minis. Not sure if there is a practical solution and still keep the feature as I think the TP5060s charge at 4.20V. I have several and will check. Regardless, my solution works fine and I don't mind the readout being 0.05V low.

Thanks again for the great firmware.
i also noticed that krausen will skew the readings as well, thats why i added the feature to skip readings below water angle to try to ignore those readings.

you have a point regarding the batteries and charge level, my batteries are fully charged at 4.15 so i will make the ”fully charged level” configurable to make it easier to define when to enter config mode. This could help to adress differences regarding different battery manufacturers so one dont need to adjust the voltage factor.
 
Another small thing I've been meaning to mention. The first time I set up the wifi, I selected the first SSID to configure from the list, configured the password, then clicked in the second SSID field and repeated. When I had difficulty accessing (the second SSID had very poor connection from where I was working), I went back in and noticed that both SSID fields are changed when you select one from the available list. Easy fix, after configuring the first, just ensure the second SSID is typed in. Not sure if it is practical to change in the firmware (e.g., only populate the selected field when clicking on a option from the available list) or just mentioning in the documentation.
 
i also noticed that krausen will skew the readings as well, thats why i added the feature to skip readings below water angle to try to ignore those readings.

you have a point regarding the batteries and charge level, my batteries are fully charged at 4.15 so i will make the ”fully charged level” configurable to make it easier to define when to enter config mode. This could help to adress differences regarding different battery manufacturers so one dont need to adjust the voltage factor.
Did some testing with the TP4056. The battery voltage reading will be whatever the battery is at as it charges and will slowly increase up to the supply voltage (~4.2V) per the charging profile of the 4056. In the situation where the battery is removed and the unit powered through the charging port, the battery readout varies every update from ~3.4 - 4.4V as the 4056 tries to set the charging voltage. So not really a useful feature in the end. Being able to enter the configuration mode by placing the iSpindel horizontal is awesome however.

I think most people would just turn the unit off when charging the battery in-situ unless they wanted to update the configuration at the same time which is easy with the unit horizontal.
 
Last edited:
Did some testing with the TP5060. The battery voltage reading will be whatever the battery is at as it charges and will slowly increase up to the supply voltage (~4.2V) per the charging profile of the 5060. In the situation where the battery is removed and the unit powered through the charging port, the battery readout varies every update from ~3.4 - 4.4V as the 5060 tries to set the charging voltage. So not really a useful feature in the end. Being able to enter the configuration mode by placing the iSpindel horizontal is awesome however.

I think most people would just turn the unit off when charging the battery in-situ unless they wanted to update the configuration at the same time which is easy with the unit horizontal.
I still think its useful not to force the device into configuration mode if the battery voltage is too high. The main trigger for configuration mode is the 90 degree position. I just added the battery voltage as an extra option. If you set the threashhold to a high value it will never trigger.

If I remove my battery I tend to connect the usb directly to the esp8266 so I dont have that issue (i have no diode to remove on my boards). Using the tp5060 and no battery is probably not a common setup anyway.
 
Another small thing I've been meaning to mention. The first time I set up the wifi, I selected the first SSID to configure from the list, configured the password, then clicked in the second SSID field and repeated. When I had difficulty accessing (the second SSID had very poor connection from where I was working), I went back in and noticed that both SSID fields are changed when you select one from the available list. Easy fix, after configuring the first, just ensure the second SSID is typed in. Not sure if it is practical to change in the firmware (e.g., only populate the selected field when clicking on a option from the available list) or just mentioning in the documentation.
Thats unfortunately the built in behaviour of the wifi library i'm using, but I might move that functionallity to the config UI in the future. I can add some more documentation.
 
I still think its useful not to force the device into configuration mode if the battery voltage is too high. The main trigger for configuration mode is the 90 degree position. I just added the battery voltage as an extra option. If you set the threashhold to a high value it will never trigger.

If I remove my battery I tend to connect the usb directly to the esp8266 so I dont have that issue (i have no diode to remove on my boards). Using the tp5060 and no battery is probably not a common setup anyway.
Agreed. What I meant is it appears the battery voltage (as detected by the firmware) will only reach the high voltage cutoff at (or near) the end of the charge cycle so being connected to a charger isn't detected by the firmware until that point is reached. If the purpose is to go into configuration mode once the battery is at the end of the charging cycle, then yes, it works and I'm quite happy to just set the threshold to a high value. Was just giving you the results of my testing in case it helped. I had the impression that what was intended is for the unit to go into configuration mode whenever the charger is attached (if the unit was left turned on) but I could have misunderstood.
 
Agreed. What I meant is it appears the battery voltage (as detected by the firmware) will only reach the high voltage cutoff at (or near) the end of the charge cycle so being connected to a charger isn't detected by the firmware until that point is reached. If the purpose is to go into configuration mode once the battery is at the end of the charging cycle, then yes, it works and I'm quite happy to just set the threshold to a high value. Was just giving you the results of my testing in case it helped. I had the impression that what was intended is for the unit to go into configuration mode whenever the charger is attached (if the unit was left turned on) but I could have misunderstood.
I really appreciate your efforts on testing various options. I'll have not really had the chance to absorb all of the information...

The intention was to force the device into config mode if there was a charger attached. I wanted another option besides the 90 degree angle in case the tilt sensor is not behaving correctly, or you might not be able to configure the device at all. If the power is attached directly to the ESP then the voltage would be 5V so that would work if using a higher level than 4.15V (unless the diode has been removed). I just selected that level since that works well on my builds. I guess I would need to do some tweaking to make this more universal but thats fine. Just glad that so many have found it useful. I really tried to make it as flexible and extensible as possible.

There has been a lot of good ideas in the iSpindel repo which just has been ignored. Could be that the structure of the software is not that easy to change....
 
It is extremely flexible with the features you have included already and I know you intend to improve it as much as you can (given the hardware limitations) which is a bonus. I can't think of anything I'd personally like you to add now the push to BrewBlox is working. The temperature corrected gravity feature is just a fun addition and something I was previously interested in.

About a year ago I did some temperature testing on 4 units to see if the variance followed the same equation you found and, while 3 were similar, one wasn't. It appeared that one gyro may have been impacted by temperature counteracting the impact of liquid density change with temperature. Regardless, it was an interesting exercise. I tested 4 calibrated units (7 points, 3 order polynomial) in the same container (5 litre jug) from 25C to 1C. The jug was placed in a fermentation fridge and set to drop to 1C over 24 hours. The iSpindels logged to Fermentrack every 30 sec and the angle and gravity readings for each temperature step (0.0625C) were averaged to generate the graph (took a bit of spreadsheet magic to make it relatively easy).

With the equation, if you set the cal temp to 25C, it predicts the gravity at 1C will read 0.003 high (i.e., 3 gravity points). I was tracking both angle and calculated gravity and the 3 units that tracked in the correct direction varied by 1.0, 2.2 and 3.7 degrees which corresponded to 1.8, 4.6 and 6.8 gravity points respectively. Mind you, this was in water so not totally representative but interesting regardless. The 4th unit dropped 0.2 degrees linearly to 15C (where it should have risen) and then bounced around 0.5 degrees for the rest of the temp change. Strange data set and I'll probably replace the gyro now that I look at it again.

The purpose of the exercise was to see if the iSpindel output varied with liquid density as expected or is the gyro also temperature sensitive and a contributing factor. I guess the answer is yes...to both...depending on the unit. Regardless, I rely on temperature probes for input to fermentation temperature controllers and use electronic hydrometers to monitor and log yeast performance and determine when to dry hop so I don't have to pull samples every day. They don't have to be super accurate but that doesn't mean we shouldn't make them as accurate as we can. Besides, its fun and rewarding.

thanks again.
 
It is extremely flexible with the features you have included already and I know you intend to improve it as much as you can (given the hardware limitations) which is a bonus. I can't think of anything I'd personally like you to add now the push to BrewBlox is working. The temperature corrected gravity feature is just a fun addition and something I was previously interested in.

About a year ago I did some temperature testing on 4 units to see if the variance followed the same equation you found and, while 3 were similar, one wasn't. It appeared that one gyro may have been impacted by temperature counteracting the impact of liquid density change with temperature. Regardless, it was an interesting exercise. I tested 4 calibrated units (7 points, 3 order polynomial) in the same container (5 litre jug) from 25C to 1C. The jug was placed in a fermentation fridge and set to drop to 1C over 24 hours. The iSpindels logged to Fermentrack every 30 sec and the angle and gravity readings for each temperature step (0.0625C) were averaged to generate the graph (took a bit of spreadsheet magic to make it relatively easy).

With the equation, if you set the cal temp to 25C, it predicts the gravity at 1C will read 0.003 high (i.e., 3 gravity points). I was tracking both angle and calculated gravity and the 3 units that tracked in the correct direction varied by 1.0, 2.2 and 3.7 degrees which corresponded to 1.8, 4.6 and 6.8 gravity points respectively. Mind you, this was in water so not totally representative but interesting regardless. The 4th unit dropped 0.2 degrees linearly to 15C (where it should have risen) and then bounced around 0.5 degrees for the rest of the temp change. Strange data set and I'll probably replace the gyro now that I look at it again.

The purpose of the exercise was to see if the iSpindel output varied with liquid density as expected or is the gyro also temperature sensitive and a contributing factor. I guess the answer is yes...to both...depending on the unit. Regardless, I rely on temperature probes for input to fermentation temperature controllers and use electronic hydrometers to monitor and log yeast performance and determine when to dry hop so I don't have to pull samples every day. They don't have to be super accurate but that doesn't mean we shouldn't make them as accurate as we can. Besides, its fun and rewarding.

thanks again.
Well, your test results are interesting. there is an option in the gyro to use the built in dmp for getting the angle which shouldnt be affected by temperature (from the discussions i found), however the example code generates an interrupt on a gpio pin when the calculation is done (dont know if this can be done by polling) or it would require a hardware modification to work. might be a thing to investigate to see if the accuracy can be improved and independent of temperature.

i guess one could build a gravity formula that also considers the temperature when doing the calculation. I have seen that beeing used….

but in the end I also use a manual reading for my initial and final gravity, krausen and yeast that build on the tube can skrew up the reading a lot. But its nice to see how the progress is and when its time for adding the dryhops.
 
I see I called the TP4056 a TP5060 above - oops. Corrected.
 
It is extremely flexible with the features you have included already and I know you intend to improve it as much as you can (given the hardware limitations) which is a bonus. I can't think of anything I'd personally like you to add now the push to BrewBlox is working. The temperature corrected gravity feature is just a fun addition and something I was previously interested in.

About a year ago I did some temperature testing on 4 units to see if the variance followed the same equation you found and, while 3 were similar, one wasn't. It appeared that one gyro may have been impacted by temperature counteracting the impact of liquid density change with temperature. Regardless, it was an interesting exercise. I tested 4 calibrated units (7 points, 3 order polynomial) in the same container (5 litre jug) from 25C to 1C. The jug was placed in a fermentation fridge and set to drop to 1C over 24 hours. The iSpindels logged to Fermentrack every 30 sec and the angle and gravity readings for each temperature step (0.0625C) were averaged to generate the graph (took a bit of spreadsheet magic to make it relatively easy).

With the equation, if you set the cal temp to 25C, it predicts the gravity at 1C will read 0.003 high (i.e., 3 gravity points). I was tracking both angle and calculated gravity and the 3 units that tracked in the correct direction varied by 1.0, 2.2 and 3.7 degrees which corresponded to 1.8, 4.6 and 6.8 gravity points respectively. Mind you, this was in water so not totally representative but interesting regardless. The 4th unit dropped 0.2 degrees linearly to 15C (where it should have risen) and then bounced around 0.5 degrees for the rest of the temp change. Strange data set and I'll probably replace the gyro now that I look at it again.

The purpose of the exercise was to see if the iSpindel output varied with liquid density as expected or is the gyro also temperature sensitive and a contributing factor. I guess the answer is yes...to both...depending on the unit. Regardless, I rely on temperature probes for input to fermentation temperature controllers and use electronic hydrometers to monitor and log yeast performance and determine when to dry hop so I don't have to pull samples every day. They don't have to be super accurate but that doesn't mean we shouldn't make them as accurate as we can. Besides, its fun and rewarding.

thanks again.
I have published a v1.1 beta1 where the temp adjustment should be fixed
 
Temperature correction appears to be working fine. I still didn't see any correction in configuration mode after adding the corrected SG and Plato fields to the format and pressing test but I do see it in BrewBlox with it in gravity monitoring mode and the result is the same as my spreadsheet version. I currently have it outside where it is 5C so the correction will be fairly substantial once it equalizes at that temp.

Thanks
 
With the temperature correction equation, if you made the 'cal' variable user configurable and added it as a setting (next to the check box with a default of 20C maybe?), the equation would work with any calibration temperature. The iSpindel instructions do say to calibrate at 20C (68F) but someone in the US might do it at 70F or 72F (or even higher if in one of the warmer areas in the summer).
 
Temperature correction appears to be working fine. I still didn't see any correction in configuration mode after adding the corrected SG and Plato fields to the format and pressing test but I do see it in BrewBlox with it in gravity monitoring mode and the result is the same as my spreadsheet version. I currently have it outside where it is 5C so the correction will be fairly substantial once it equalizes at that temp.

Thanks
Once the temp correction is activated then the "gravity" value should contain the corrected value, I just checked the value displayed on the index page but will check that the correct value is used when doing push as well.
 
With the temperature correction equation, if you made the 'cal' variable user configurable and added it as a setting (next to the check box with a default of 20C maybe?), the equation would work with any calibration temperature. The iSpindel instructions do say to calibrate at 20C (68F) but someone in the US might do it at 70F or 72F (or even higher if in one of the warmer areas in the summer).
I can add this as a configurable setting under advanced. Will add that to the next beta version
 
Once the temp correction is activated then the "gravity" value should contain the corrected value, I just checked the value displayed on the index page but will check that the correct value is used when doing push as well.
Looks like you found another bug, thanks. The corrected gravity is not applied when sending data via push only when shown on the web page.
 
I assumed the temperature corrected gravity would be sent with the key ${corr-gravity-sg} so I pushed both that and ${gravity-sg} to BrewBlox and displayed them on a graph. ${corr-gravity-sg} did supply the temperature corrected value based on the ${gravity-sg} and temp values sent. I double checked the result using the same equation in a spreadsheet (which includes the conversion of C to F) and got the same corrected value.

I didn't actually test ${gravity} to see if the corrected value is sent but I see that for the other services being pushed to, that is what is used. Presumably some services define whether it has to be in SG or Plato and I see with Brewfgather, ${gravity-unit} is also sent so either can be used. Is the logic then:

${gravity-SG} - always uncorrected SG
${corr-gravity-SG} - always temperature corrected SG
${gravity} - whatever unit (SG or Plato) is set in the configuration mode, uncorrected if the temp correction flag isn't set and corrected if it is?

Apology in advance for the query, have been quite busy so haven't had time to look at the code to confirm. It this is the case however, seems like a good approach. When I get a chance, I'll add ${gravity} to what is sent to BB and see what I get.

Cheers
 
Back
Top