-
-
Notifications
You must be signed in to change notification settings - Fork 254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Realtime Color tracking #1680
Comments
What do you expect from a Color track support in Artisan exactly? Typing in the resulting color value in the corresponding RoastProperties field might be faster than connecting the device via USB. What am I missing? |
Hi Marko, The unit I have is the ColortrackRT, which tracks the change in color in real time. I have it installed with its laser aimed at the sight glass. Many industry experts(Rob Hoos, Scott Rao) have been saying that the success of roast in flavor is 60-80% the finishing color, 10-20% Time to first crack, and 10-20% development time. So, I embarked on this journey to explore that specifically and hence decided to have it done in real-time instead of using a benchtop unit for post-roasted analysis. So, the first issue is logging color changes over time. They have an app, but it is crazy to run two loggers at the same time. I am attaching a picture of one of their logs for you to take a look at below. That is the first picture. The second goal is to correlate color values with other coffee roasting stages we know, like turning point, marking the dry end, 1st crack, etc. Now, just like Artisan logs turning point in temperature, there is also a turning point in color, as you can see from the color log picture. I created a button that I click to annotate the BT curve in Artisan (as you see in the 2nd picture). This turning point in color is the starting point of the Maillard reaction. Color track folks call it Blanch Point. I mark it as MLSTART. It would be great to do this in real-time. Over time, as a roaster, I would like to know and modulate MLStart to 1st crack instead of TP in just temperature. It will be great to automate the recording. Also, I only have a marker on the graph right now, but I have to write down the color reading at each point of interest and add it to my notes per roast. I will be adding more EVENT buttons in Artisan for now to log the color reading at 1st crack, etc., but it will be great to have a target color, % of target reached on an LCD on the side and log it automatically using some ALARMS. Right now, I am using the phone app with BT for convenience, but I can also use USB on the PC directly. Those were my thoughts so far, Thanks, Vikram |
I added initial ColorTrack support to Artisan. This one is completely untested as we do not have access to a ColorTrack device. A new continuous build with this should be available in a few minutes. This one communicates via USB/Serial. It might be possible to connect via Bluetooth LE (BLE). For this we would need to know the Service UUID as well as the notify Characteristic UUID of the ColorTrack. You might investigate both using one of those free BLE scanner apps for your phone like LightBlue or nRF Connect. For now, there is a new device type named "ColorTrack". Add an extra device of this type and configure its serial comm port according to your setup. |
Could you please attach another picture from the LightBlue app after clicking the entry "Laser Measurements"? This should display the corresponding notify UUID. Thanks! |
Thanks for this further image. BLE support might take some time to realize due to general difficulties of running proper BLE connections on desktop machines, but we will work on this during the next month and will ping you if there is something to test. Did the USB version work for you? |
Stalled. What a pity! |
Hi Marko, Thanks, Vikram |
Hm. So serial comm is not working. By now I added novel Bluetooth Low Energy support to Artisan and changed the ColorTrack extra device to connect via BLE. The problem is that I do not know what data in which format your device is sending. Thus for now it is not decoded and used, but instead logged into the artisan.log file. Maybe you find the time to download the current Continuous Build, configure again one extra device of type ColorTrack (you can use the Dummy device as main device), press ON and check if Artisan is connecting to the device via BLE. If it says "Connected to ColorTrack" it should start logging the received data to the artisan.log file. Turn Artisan off and click on the plus icon in the upper left corner while holding the OPTION key. An email should open with the artisan.log file attached. Please send this and I will see if I can decode that data somehow. If not, we will have to ask FreshRoast (the producer of the ColorTrack devices) for some hints. THANKS! |
Thanks Marko, I am working on this today. I also did contact FreshRoast too. I expected that they might have have proprietary data packet format. But, I will send you the logs. Incase the data is obvious. |
Excellent! Thanks a lot already for your support. |
Hi Marko, BTW, On another note. I modded my roaster to add 1 more temp. probe in the burner box at the inlet of the drum. I would like to log that too and one more post catalyst in my afterburner. How do I add more temp LCDs? I know their modbus registers. I have seen some Artisan curves with multiple temperatures but I am not able to get that setup using the Modbus dialog for multiple inputs. All the additional LCDs I add only show BT. |
Hi Marko, I can seem to select the port for the Colotrack in the window. See below, But, I am also attaching the log file. Thanks for all your help, Vikram PS: On the previous question I am guessing I should use MODBUS34 in the Extra Device setup. |
All fine. The ColorTrack connected and was sending data which got logged. You had "Debug Logging" on (hold OPTION+COMMAND while clicking on the plus icon to toggle it off) and device logging ticked (menu Config >> Devices, flag "Logging") which was flooding the log with some other messages, but I could extract some of the ColorTrack responses. Do you have an idea what number the ColorTrack showed? I assume it was static and reading about the same number during the captured period (18:07:23 -- 18:08:21), correct? |
Hi Marko, |
Don't worry. I worked it out. A moment and I will have something to test for you which should work. |
At this moment a new Continuous Build is created which adds the data decoding for the ColorTrack. There are now two device types, ColorTrack Serial and ColorTrack BT. Please make sure you selected the later. There are no serial configurations needed for this one. The correct color readings should now show up in Artisans LCDs. It would be could if you could verify this and check if the data shown is about correct. THANKS! There is one more thing (isn't there always one?): the ColorTrack seems to send out also temperature and humidity data. I am not sure how this is measured and for what it is good for (maybe it is mainly used for internal calibration?). To check on this data I added code to request this data form the device and log it to the artisan.log file. It would be cool if you could record some minutes and attach again the resulting artisan.log file here. Before you should disable Debug Logging (click the plus icon while holding the OPTION and COMMAND/Apple keys to toggle) and also disable device logging (menu Config >> Devices, "Logging flag" at the lower border. Thanks for your support on this integration! |
Hi Marko, Thank you as well, I am quite excited. Vikram |
Thanks for your feedback. BLE connection takes a moment after ON, therefore it first shows the UU. The values are currently converted such that the app shows the correct color readings between 0-100. No idea yet why the readings are off for you. I will investigate using your log files once I got them. |
Just checked again. The data you logged before does display as about 71. I just started a new build which displays the raw value received on the second LCD. Maybe you can still upgrade before roasting tomorrow. |
Any news? Could you run some tests on the weekend? |
Hi Marko,
Here are some logs, Vikram |
Hi MArko, Here is the video of the LCD flashing the reading and then going back to UU. IMG_3461.MOVThanks, Vikram |
Could you please also attach one of the recorded Artisan profile as .alog.txt file to allow me to check for the actual readings received. Thanks for connecting to FreshRoast on this. Hope they can clarify. I will try to improve the connection issue. However, it is well known that the Windows BLE implementation is, well, weak. |
Hi Marko, One more from today. Let me get you an .alog.txt too. Vikram |
Ok, no artisan.alog file. Hm. I revised the data interpretation according to the new data I see in your logs. Before Artisan interpreted only every second byte as the other bytes were all equal and regarded as sync characters. This interpretation was wrong as your new data shows that both bytes are carrying information. I also removed any extra logging output thus attaching log files is not productive any longer. Could you please test again with the latest continuous build and in the best case attach a recorded .alog file with the data? Regarding the slow Bluetooth connect: the connection is actually using the Bluetooth variant Bluetooth Low Energy (BLE) which is known to be not well supported on desktop systems, especially Windows. Some Windows 10 versions and hardware do not work at all with BLE, others work but take several minutes to disconnect. While still connected, another connection cannot be established. I guess you suffer from this. Not much I can do on this, however, I could improve the scanning process slightly. On Windows 11 things seem to work a bit smoother, but there are also reports on long disconnect (all independent of Artisan or Python). On macOS connect and disconnect is instant and connections are rock solid due to the underlying BLE implementation is directly inherited von iOS running on iPhones and the BLE hardware is somewhat standardized. I fear we can not do anything to improve the BLE connect time on Windows from the Artisan side. Sorry. Thank god that Windows 10 is scheduled for obsolete soon. THANKS! |
Hi Marko, |
Hi Marko, I've attached an updated log file from today. Vikram |
Hi Marko, From the Guatamala csv above, it looks like the column C_Raw is closer to the right values. However, the samples are bouncing a bit. I have colored some of the cells below to show possibly what the correct values should be. I don't know why the values after 11.14 start dropping. I have not dropped the coffee yet. This was the last batch on 11/1, so you should be able to see this from the last artisan log I sent. Vikram |
Hi Marko, |
As said before. I removed all extra ColorTrack log out put from the Artisan logs in these later builds. So the log files are not productive. The reason why values started dropping were that Artisan rejected all data not containing a $ as every second byte as I assumed those were sync bytes and all of your initial data was formatted that way. Your later logs showed that this assumption is not true thus I revised the implementation in the last builds to accept also data with second byte values different to $. I found that this second byte does contribute to the color value, but as lower-value data. The raw color value logged additionally (but no longer in current builds) by the first builds supporting the ColorTrack did actual show the mapped value. I had the two values (raw, translated) assigned in the wrong order. It would help if you could record one more roast with the current build and share the .alog profile again to check for the results. If those are still wrong, I see no way to work the correct data mapping out with this approach and we will need the support by the manufacture of those devices. |
Hi Marko, |
Hi Marko, PS: In this XL I created a moving average column and then a +/-15% filter to accept the sample or the MAV and curve now shows 2 potential turn around points. |
Dear Vikram, I just uploaded a new Continuous Build adding 2 configurable data filters for the ColorTrack. The first ColorTrack device channel is using a mean sliding window filter and the second a median sliding window filter. I cannot really test this as I do not have enough data from the device. The ColorTrack sends about 60-70 readings per seconds in packages of 10 readings. As the data is rather noisy as you have observed yourself (and what you saw was already averaged!) it seems some heavy filtering is needed. I tried several variants of filters from the literature, but the simple mean filter seemed to outperform the others. I added the median filter as it deals better with small rare outliers, but the data looks like it carries rather uniform noise. You can configure the two filters under Config >> Device, last tab "Networks" under "ColorTrack". The range of each window is 10-200. I set the default to 50 which might be a good starting point, but larger filter sizes might be needed up to 100 or even a bit more. To not miss readings at the begin of your recordings you could first press ON and wait until you see the ColorTrack readings in the LCDs. There is now also a message "ColorTrack connected" on successful connect. Only then press START to start the recording and start your roast only after the recording is started. CHARGE and DROP should be detected automatically. I am awaiting your report, thus I am a bit sceptic about that Blanch Point, which is not a very common concept, and the chance to be able to reliable determine this one based on online color measurements (after having worked on our Colorimeter Tonino for years). But I am always willing to learn... |
Hi Marko,
I just got a real time Colortrack system installed. For now, I am just adding a few buttons to annotate the graph. But is there a plan to add Color track support? I can help with testing. I can connect to my PC via USB or BT. Right now, it is over BT.
Regards,
Vikram
The text was updated successfully, but these errors were encountered: