Go Down

Topic: Design check for an advanced coffee grinder timer (Read 12735 times) previous topic - next topic

jazzar

#75
Jun 09, 2017, 09:12 pm Last Edit: Jun 09, 2017, 09:21 pm by jazzar
Demo Video: (German)

https://vimeo.com/220012040

Video will show the background graphics I'm talking about.

A complete Image is actually quite a bit faster than drawing many elements "by hand" so putting as much of the static stuff into the background images saves time.

The fastet I can get is ~42ms. Thats with only displaying the refresh time and nothing else in the loop (apart from reading button states).

7) Fixed. Added an option to hold the mode2button at startup to write EEPROM.

Fixed the naming conventions, put stuff into convenient arrays that eliminate all the switch case stuff. A whole lot tidier now.

x) up next.

septillion

True, but I think it's faster if you split the image in a left part and a middle part. And you you actually want the (in my opinion) clutter of an image on screen all the time? It would bother the crap out of me if an image would fill my screen all the time instead of the info being bigger...

(And ahh, you where German. I mixed you up with some American and he did not like it begin called German 0:-) But then again, he probably would call me German as well but I'm a Dutchy :p )

And great job making array's. But you can simplify it even more if you made an struct ;)

Code: [Select]

struct mode_t{
  char name[14];
  unsigned int maxGrindTime;
  unsigned int;
}


Two advantages:
1) You can put it in EEPROM with one command
2) EEPROM is organized name, value, name, value... instead of name, name, name... value, value.... So if you add an extra brew the EEPROM content is still valid :)

Both are wayyyy easier then the enormous list of EEPROM stuff you do now.

x) Easy fix ;)

1) No pressure, just asking, fixing that?
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

allanhurst

#77
Jun 11, 2017, 06:05 pm Last Edit: Jun 11, 2017, 06:09 pm by allanhurst
A colleague of mine, years ago, was an enthusiast for 'perfect coffee'.

He pointed out ( in a long discussion on the company website) , that a grinder with slow rotating serrated cutters, was much better than a fast rotating 'whizzer' type which smashed up the roasted beans with a blunt blade because it gave fragments of a more consistent size .


These slowly ground fragments  when brewed in a given time at a given temperature of hot water would  give a more consistent extract.

He was a PhD ( Cambridge )  physicist.

Was he right?

I'm not that fussy.

Allan

jazzar

True, but I think it's faster if you split the image in a left part and a middle part. And you you actually want the (in my opinion) clutter of an image on screen all the time? It would bother the crap out of me if an image would fill my screen all the time instead of the info being bigger...
I think I tried once the difference in speed between complete and partial image and found it made not a big difference.
However I found a youtube video comparing adafruit and u8glib and u8glib was both faster and smaller so I might change to u8glib.
I like the background image since it makes the mod look less out of place. The information displayed is not that relevant in day to day usage. If you find you have too much or too little coffee you have to take a closer look to adjust the time. If the grindsize is off, you will have to take a closer look as well to see how much you are changing it. But once you are settled you won't usually even look at the display.
The only thing that could be bigger is the program that is selected, but I don't know of any two coffee makers that require the same grind-size, so normally you won't be changing the programs that often anyway. So the only time when you will be changing the program regularly will probably be with a portafilter espresso machine using single, double or triple baskets.
In any case the grinding progress is displayed by a loading bar which is easy to comprehend with a single glance and should provide a good measure of visual feedback.
If you want to change the grindsize you need to empty the bean hopper anyway and thus have to 'get involved' with the timer anyway.
My main point is to divide the operation in two parts:
1.) Day to day where there should be the absolute minimal interaction necessary to operate the timer: Grindbutton starts grind and modebutton changes modes. Reducing displayed components to what is really necessary.
2.) The setup stage where interaction complexity can be higher since it is seldomly engaged. Here the variables should be easily controllable -> Turn Pot. for time. And as intuitive -> same buttons do the same things every time, as possible.


And great job making array's. But you can simplify it even more if you made an struct ;)
Never used a struct before, will look into it.

1) No pressure, just asking, fixing that?
Gradually ;-) I went with upper camelcase for my functions and lower camelcase for variables. No special treatment for const.


A colleague of mine, years ago, was an enthusiast for 'perfect coffee'.

He pointed out ( in a long discussion on the company website) , that a grinder with slow rotating serrated cutters, was much better than a fast rotating 'whizzer' type which smashed up the roasted beans with a blunt blade because it gave fragments of a more consistent size .
Burr grinders give you an easily repeatable consistent grind size since the distance of the burrs won't change. With these whizzers it is grind-time that controlles the fragment size.
Even though it is often said that burr grinders would "cut" the beans they are in reality rather crushed. Coffee beans are quite brittle and splinter rather than particles being shaved off.


These slowly ground fragments  when brewed in a given time at a given temperature of hot water would  give a more consistent extract.
Whizzer-type grinders tend to produce more "fines", which is what microscopic bean particles are referred to.
When extracting coffee, you would normally want to avoid an over-extraction since it usually does not taste very well. For example, using the same coffee to make second cup from it.
With the particle-size it is about the same thing, the smaller the particle, the more it will be extracted in a given time. Add many fine particles to otherwise coarse ones and it will be difficult to get an even extraction. The fines will be overextracted and the coarse coffee will be under-extracted.
While under-extraction is usually not a problem in taste (see ristretto) over-extraction is to be avoided.

On the subject of which grinder is 'better': Portafilter espresso machines really need an even grind if you don't want to make it extremely difficult to get a good shot. But they are special cases since you have a very high extraction: high pressure with small particles, so any errors are magnified. I think any coffee maker can benefit from an even grind although there are some methods which are a bit more forgiving in that department (Bialetti for example).
Another consideration is the hellish noise those whizzers make, so that alone would be, for me, a good reason to get a burr grinder instead ;-)

septillion

However I found a youtube video comparing adafruit and u8glib and u8glib was both faster and smaller so I might change to u8glib.
Then update to u8g2, the successor of u8glib :)

But once you are settled you won't usually even look at the display.
Then I would say a super mega ├╝ber smooth progress bar is also less critical :) ;)

Never used a struct before, will look into it.
Not that hard, just a group of variables which you can create at once :)

Gradually ;-) I went with upper camelcase for my functions and lower camelcase for variables. No special treatment for const.
Alright, structure is better then no structure. Do know you deviate from the Arduino standard (because loop() and setup() etc all don't match). Be he, I'm not complaining to much if you stick to whatever scheme you choose :p
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

Watcher

CrossRoads:

Quote
"And when you have room on the PCB, you can print the values next to them because that's what really matters when assembling"
That does not look professional tho.
I just use Reference Designators( Name, in Eagle - R1, R2, C1, C2), and give them a Value ( both accessed by right-clicking on the part's Origin +).
Sorry to intervene, but how do you turn off part names from showing on the PCB?

jazzar

@Watcher check out any cam file tutorial and use an online gerber viewer to check your results. Depending on your pcb manufacturer they will provide a cam setup file in which you can select the appropriate layers.

Well blast, the surge protector I purchased doesn't help. What is going on in that kitchen o.O

On other news, I think I fried my backup oled by applying reverse voltage for a few seconds... Confusing though since it worked afterwards for about 20min. and now it doesn't show anything. It is still seen by the i2c scanner occasionally but any attempt at displaying anything fails at the point where display.begin (or similiar) is called.

I'm usually using python which I find a lot easier to work with. Also space isn't really limited :-) So I guess that explains the messy programming :-D

jazzar

Some advice/explanation needed:

The all-metall chassis of my grinder is connected to PE.
The Signal ground of the PCB is not connected to the chassis.
When I measure AC voltage between signal ground and chassis I get ~88V

Should I do anything about this?

- millis-overroll -> fixed


septillion

That should not matter. That voltage is just capacitive couple because PE and signal GND have no reference whatsoever to each other. But you can connect signal GND to PE.
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

jazzar

Thanks for the quick reply.

Just as a test I connected Signal GND to PE. I have a USB cable exiting the grinder in the back so I just leaned the metal chassis on the connector.

Now, the board does not seem to crash anymore!

I installed a surge protector between grinder and wall plug some time ago, which didn't seem to work as I commented earlier. But now with the PE connection it didn't crash in around 4 hours which should be a few compressor restarts.

Can anyone explain why?

Well I guess the compressor is producing a voltage spike in the mains, which somehow does not get filtered by the surge protector. So somehow the spike survives throughout the PSU and shuts down the arduino.
The surge protector compares mains to PE I think in case of surges, so could it be that the spike is small enough to not trigger the MOVs, low enough in frequency to not get filtered out by the snubber in the SP and large enough to screw up the PSU which might not be able to compensate with signal ground floating independent of PE?

jazzar

I realized I made a mistake in the labeling, I had the transformer connected in reverse, with Live and Neutral switched. Could this have something to do with it?

septillion

Mm, I can't explain it. I don't see any reason why that would fix something because the Arduino isn't referenced to PE at all... (Other then your GND-PE connection now.)

Switching N and L makes no difference for the PSU (not a transformer ;)). After a filter the first thing the PSU does internally is rectifying it. And with normal European style plugs (Schuko, Europlug and even the French plug) there is no way of ensuring L is L because the plugs are non-polarized. (Or in case of the polarized French plug, there is no fixed L pin). But it may effect the filter if you placed it between N and PE instead of L and PE.
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

TomGeorge

Hi,
SMPS usually have a 0.1uF cap between output GND and Chassis Ground.

Tom.... :)
Everything runs on smoke, let the smoke out, it stops running....

Go Up