The magic 299 or can we go lower?

[AnAnalogGuy]

Hi Greg,

Looking at the code, i found DANGER_MIN_HEIGHT (162 + HYSTERESIS)
where HYSTERESIS == 137 (minimum raw step width)

megadesk/code/src/megadesk.cpp

Line 143 in eada425

#define DANGER_MIN_HEIGHT (162 + HYSTERESIS)

with your notes:
// Changing these might be a really bad idea. They are sourced from
// decoding the OEM controller limits.

That leads to 299 (162 + 137 = 299) which is the minimum position the table can be moved to with megadesk.

However, when calibrating my desk, it reaches raw 96. Now, for my "low rider sitting position" i'd like to get those extra approx 2cm lower, if possible.

@gcormier from your experience, do you think it will be a problem to override the DANGER_MIN_HEIGHT? I'm just asking myself what could go wrong? My thoughts are:

• With the calibration functionality the desk already moves into this position
• These extra 299 minus 96 i consider a security margin since products from mass production might have fluctuations. So for some the extra margin is needed, for some not.
• Isn't there a protection in place anyway? I mean, doesn't the calibration function demonstrate that there obv is some sort of stop mechanism reacting on increasing power consumption (since when physical resistance occurs, the motor is staring to pull more power which then obv. triggers an electrical "shutdown")?

So if i would set my minimum height to something above 96, say 110, it still shoud have a small margin to not trigger that protection. And in case something should go wrong, it would only be once since i can change the setup again if i see it's going to be a problem.

What do you think @gcormier, is there something I'missing?

Thanks a lot!

[gcormier]

You need to account for the "coasting" or deceleration when you let go of the button.

But otherwise, in theory you could probably go lower. Two factors contributed to this,

1. The calibration function was not known when I did all the reverse engineering, nor was it implemented on megadesk until much later. I agree now, it is likely the motors should be able to protect themselves.
2. There was no way I was going to ship the pre-flashes version with something that had an element of risk for damaging the desk, hence the generous buffer.

If you decide to go for it, please report back :)

[AnAnalogGuy]

I'm fully with you and would have done the same when replacing the original pcb - no way i would have made it behave else than the original. I was just wondering if you might have had any other reasons or insights before i will give it a try. And sure, i will report back - will take a while as i first have to order a suitable AVR programmer.

[AnAnalogGuy]

Btw, one more reason to include some buffer is both legs not always having the same remaining "length" (which also is something that gets adjusted during recalibration).

[AnAnalogGuy]

Did i get it right and [env:attiny841_serial] would be the right "action" to choose for megadesk? Anything special to keep an eye on?

Has anyone used VS Code on Windows with PlatformIO to build and upload the hex to the microcontroller? It seems PlatformIO uses avrdude. Would be a very integrated and straight forward push-one-button action if it really works ootb.

[gcormier]

Yes, that's the right action. vscode + pio is what I use for all my development.

[AnAnalogGuy]

@gcormier
I'm just thinking about how to implement the lower DANGER_MIN_HEIGHT. Instead of hardcoding the value, I'm thinking if i should use the recalibration method, to set DANGER_MIN_HEIGHT to the position after the recal plus a buffer. Like this, the DANGER_MIN_HEIGHT gets validated by the desks calibration functionality which should never return an invalid value, no matter individual differences per desk or deviations over time. I could (try to :-)) add a build flag to make this "feature" controllable at compile time.

---

After going a bit deeper into the code, I guess the recal idea won't work as if I correctly understand, input processing is done single threaded in sequential order within loop(), so during the recal procedure currentHeight won't be updated and i won't be table to get the actual value before the next iteration of loop()

[AnAnalogGuy]

One more thing i wasn't able to figure out: Why is it that SCK on the megadesk board is used as TX channel in the serial communication? I'm just wondering as i would expect it's a different signal than a clock and the same port, if i get it right, is actually used as clock when connected to a an eeprom writer to do the firmware update. Or did i get this wrong?

[gcormier]

SCK is also RXD1 which is a hardware UART on the 841.

[AnAnalogGuy]

While trying to fully understand the code i came across this section:

megadesk/code/src/megadesk.cpp

Line 775 in eada425

// Turn on motors?

Shouldn't currentHeight in the red squares be targetHeight? Since, if i get it right, the goal of the second condition is to avoid driving the motors over the upper and lower limits? Checking against currentHeight would not always avoid this.

There is a second check for the limits in a different part of the code, which might be the reason why this never led to a problem.

[gcormier]

I believe the intention is that if the desk is already at one of the limits, it will avoid starting any movement commands altogether.

[AnAnalogGuy]

One more question if you a couple of minutes:

Did i get this right:

At the begining of every iteration of loop() the current desk position is read from the motors and currentHeight is updated. After this, commands (serial commands or manual buttons) are evaluated. If recal is triggered, the control flow is:

• In State STARTING_RECAL, set new State RECAL, break
• next iteration of loop, starting with evaluating current height
• In State RECAL, set new State END_RECAL, break
• next iteration of loop, starting with evaluating current height
• In State END_RECAL

So, when the program reaches END_RECAL, currentHeight has already been updated to the most recent height after calibration has been done (moved the table)? So i could automatically set DANGER_MIN_HEIGHT to the minimun heigth after calibration?

Could i use eeprom slot 14 to persist DANGER_MIN_HEIGHT (and read it back after a restart, as it's not a constant any more)?

[gcormier]

Yes you could use slot 14. And yes if you want you could just set the danger min height to the value after calibration is finished.