mesarcik / roastery Goto Github PK

The selection, deletion and addition dialogs should be kept consistent with the other dialog structures

The frame shown was recorded while both temperature gauges were showing a steady decline in temperature (from the white line onwards). IE both the roaster thermometer and the actual software thermometer showed temperature declining for about 60 seconds, even though the RoC graph (and the temperature graph) show positive change.

The template roast and the actual roast were performed on 24 hours apart (roughly) and the drop temps were identical as far as the Diedrich thermo reading was concerned. In fact the progression after FC was pretty much identical for both roasts, but as you can see, the graphic representation of those two roasts is significantly different.

If kernel size is > window size prevent user from inputting.

Add slider for polynomial order for sav gol smoothing.

It must be noted that the smoothing algorithms will only become active when the array size is greater than the smoothing window size for both temperature and rate of change respectively.

This issue should be rectified.

Assume there is a mathematical reason, but seemed weird that the RoR graph looked really good, but the temp was so dramatically way off. I had to abandon using the temp readings altogether.

Its too hard to see on the black background.

It is not easy to figure out that in order to commit changes to the software the dialog boxes should be closed. Therefore either add a commit changes button to the dialog boxes or make the changes take effect instantly.

In the same way that it was done for the RoC Graph.

make kernel size a ratio of the window size.

This will prevent future problems.

Gets worse and worse from TP onwards during a roast. image attached. this has happened for 3 roasts in a row, even without temp smoothing on.

Window size sliders must be in odd increments.

It seems that when importing after the roast has started the whole system responds slower.

About

I have investigated the import error and found that it is closely linked to the sluggish UI.
This bug was inherited from one of the first releases I made and requires a delicate fix.

Issue

The problem stems from the pyserial library, in particular the relationship between the buffer size,buffer refresh rate, and arduino serial sending times.

• When the arduino sends the temperature readings over serial (usb) too quickly the buffer gets too full so that on the software side the grapher ends up graphing stale readings.
  • This may lead to the BEARCLAW issue when the buffer is cleared. (i.e. when the buffer is refreshed and the "more recent" readings are received, there is a large disparity between the previous stale readings and the new readings, hence leading to a large change in temperature gradient.)
• When the arduino sends temperature readings over serial too slowly the software ends up responding too slowly. This, in turn, makes the time-stamps of the readings incorrect.
  • This may also lead to readings being dropped.
• However the problem runs deeper than just this due to the lack of foresight in the earlier versions, I made 2 different time stamping mechanisms.
  • This first deals with the real-time data being graphed, it uses a millisecond counter (i.e. 10,1013,2084 -- because the readings are not taken exactly 1 second apart there is a couple of millisecond deviation) for the x-axis.
  • The second deals with the imported data which uses the indexes of the data (i.e. 0,1,2,3,4)
• So because the x-axis indexing is not standardized, there is a time discrepancy between the real-time data and the imported data, hence the importing bug. This bug is exacerbated by the waiting between readings.
• Furthermore the sluggish UI is caused by the update thread waiting for the right number of bytes to be sent from the arduino. It will only give control back to the main UI thread IFF (if and only if) the correct number of bytes have been received.

Possible fixes

• Use the timeout() mechanism to give back control to the main UI thread.
  • This causes missed readings and readings to be dropped. Has to be used very carefully so to ensure enough time to get the new temperature readings.
• Try sync up the sending of data and the received of data, so to prevent the lock up of UI and to ensure non-stale readings have been sent
  • This is hard to implement because it requires a trial/error approach.
    • Firstly because every OS deals with the serial ports differently and delays may be incurred involuntarily.
    • Secondly because I do not have the thermocouple system at hand and that the delays incurred by getting the data from the thermocouple amplifier via SPI are undocumented.

Way forward

As mentioned, this requires a delicate fix but is very necessary. I have been trying to apply the possible solutions mentioned above, but without thorough testing on the actual system, it is very hard to say if they will work/not destabilize the system to an unusable state.

Therefore as soon as I have an opportunity I will need to come in and test the possible solutions on the system, but until then, you will have to unfortunately use the semi-stable software I left with you on Friday.

--Misha

The exporting of graphs should be attempted through the pyqtgraph api.

Focus never leaves main window when dialog boxes are open,

Sometimes on closing of the application the serial port is not closed. This results in not being able to open the application correctly when it is next run.

This bug should be fixed

The main class is too cluttered, and its structure is really shit.

More insidious than other crashes because it takes a while for me to realise that it has happened. Very uncool. Happened once yesterday afternoon, and once this morning.

the first decimal place rounding is inaccurate.

Dialog comes up showing that you havent selected a import graph even that you have selected cancel.