Serial Control

[dbrgn]

It would be great if there would be a serial interface for controlling the desk lift from the computer!

I have started a similar project for an Actiforce desk lift: https://github.com/dbrgn/desklift/ It's not done yet, but the serial protocol used is the following:

- Baudrate 115'200
- Every command is a single signed byte
- Positive values move up, negative values move down
- The value must be multiplied by 0.1s to get the move duration

So for example when sending 0x13, the desk would move up for 1.9 seconds.

This should be quite simple to implement I in the firmware. The issue would probably be available pins.

It looks like the ATtiny841 has two USART. If I read your schematics correctly, USART0 is used by the LIN transceiver. USART1 is available at PA4/PA5, but those pins are shared with SCK/MISO from the programming header... But maybe this could be solved somehow, e.g. by automatically disconnecting the serial pins if there's power on the programming header?

[dbrgn]

(By the way, this could simplify #11 since a BLE controller could be implemented externally with a separate uC that communicates over serial with the controller board. There are also ARM uCs available with integrated BLE, e.g. from Nordic.)

[dbrgn]

Oh, and as an addendum 2: Does the Bekant table allow going to absolute positions? If yes, then of course the time based protocol doesn't make much sense and should be replaced by absolute positions. I used that protocol for the Actiforce desklift because it does not support absolute positions.

[gcormier]

Yes, the commands specify the actual absolute position that the motors should go to.

It should be possible to simply use two of the programming pins with SoftwareSerial to accept commands. You can put resistors in line with both those lines. That would allow the programmer to still function if needed. Some creative work might be needed to access the header properly as the space is quite small in there! :)

[dbrgn]

Ah, I forgot about SoftwareSerial 🙂

[MrFaul]

I have currently the option to buy some "new" Linak DL15 from a warehouse closing and I'm planning to upgrade my 2m² desk-monster.
However I would need to build a custom controller for that thing, so how far are you with reverse engineering the protocol?

[gcormier]

@MrFaul , if this is in reference to @dbrgn reverse engineering the Actiforce desk, probably best done on his repository.

[dbrgn]

I don't think it was in reference to the Actiforce desk, since those use a very different system for moving the table up and down.

Does Ikea use the Linak DL15?

[gcormier]

IKEA uses Bosch motors.

Megadesk is a working product that can move the desk up/down.. the reverse engineering is done.

[MrFaul]

Well Linak uses Bosch in this to supply IKEA, but I doubt they would change the interface.
As usual the Swede is trying to save every penny...
The bekant is basically a in-house bootleg version specially made for IKEA

Edit: scrap that the new idasen is the Linak product not the bekant

[drcursor]

Would really love to have either this or the Bluetooth option.
Any chance of a connected version of the board?

[legomind]

I would love serial commands to hookup a esp32 and add wifi control. Because why not?

[nutinshell]

Wi-Fi control is a lot more fun, please consider adding it :)

[gcormier]

ESP32 will not fit inside the case which is not in-scope of this project, see #7

[legomind]

I was thinking more as an external microcontroller

[dbrgn]

If serial control is supported, you can easily add WiFi yourself using an external microcontroller.

[gcormier]

TX1/RX1 can be accessed via MISO/SCK which are on the programming header. All that's needed is the code :) Notice the "help wanted" tag :)

[lwestenberg]

This would be great (the bluetooth option and/or the external microcontroller option). Is there anybody who already started working on this?

[tagno25]

I have created code that I think will work, but I do not have a controller I can test it on yet. After it is tested and working, I will submit a pull request.

https://github.com/tagno25/megadesk

[gcormier]

Very cool! You should receive it shortly.

[martingem]

I discussed it with @gcormier but would also like to have other people's input! It's about adding to the design (for extra cost as option) a USB module + wire.

From my perspective: USB would be the easiest way to get going since a good solid connection could be running through a single cable under the desk to the computer (no pairing required). Of course, it would limit us to being connected to a computer. But my assumption is that people have computers on their desks and just like the OP suggested, I'd want to program it through my computer.

What about my phone one could say? I'd argue against it, not only for pairing but also: say we want a timer, do you want to run the app in the background all day long? Or rather have your computer - on the desk when you work - have plugged in USB, that way the presets could start working the moment you start working? Also, anyone volunteers for said phone apps? I think going wifi would be beneficial mostly - and only - for smartphones, in my view.

For me at least, a better first step would be to get USB and I'd volunteer to make a desktop app - unsure yet but I'd want a Task Tray app for its access/simplicity but am open to feedback - to control it. I just don't like the perspective of needing to pair the device. Also, if the argument is because of extra cost I would absolutely buy the extra cost to assure a good connection (but that's me). Also, if you have a desktop computer, you may not have wifi, what do you do then?

I'm really interested in people's feedback on my view.

[fotiDim]

Personally I would like to have it independent of my desk computer. It is not always turned on. I would like to integrate it on Home Assistant and Alexa. My Home Assistant PC is far and out of Bluetooth range, let alone USB cable connection.

I could add another RPI to act as the control unit of the desk but it seems like an overkill. My ideal solution would be wifi based with something like ESP8266, So interfacing with the ESP8266 over the serial pins seems to be the way to go for me.

[gcormier]

My initial thoughts for hardware are that a 2nd module can be designed with the appropriate microcontroller (either USB or WiFi connectivity), and another LIN bus module. For someone with an existing megadesk, they would put the module in between the megadesk and the motor. It would communicate to the megadesk over the same 3 wires as the rest as well as receive power. The addon/companion would ask the main megadesk for current height, as well as send commands to raise or lower.

This means existing megadesk people can just add on a 2nd module if they want remote control.

The other option would be a serial interface, but it means potential soldering of the 6-pin header or serial wires to megadesk, and cutting of the plastic case to make room for a 2nd serial cable.

Of concern though as always is the ability for a desk to move with no human nearby. The companion could also have a physical on/off switch if desired. Or, another means could be confirming automated movements with the down arrow button. eg.

• Application requests companion to move to standing
• Companion requests move to this height to megadesk
• Megadesk beeps for 5 seconds indicating a move is about to occur
• User pushes the down button, which would either confirm permission to move (preferred), or to cancel the move. It could be up to the software to determine which mode to use so users can accept their own risk tolerance (ie. children/pets in the house)

[lwestenberg]

I like both ideas but for me serial to my MacBook won't work as I connect/disconnect it all the time and also would like to work on the desk without a computer on it.

As hardware I would prefer a simple ESP devboard like a Wemos D1 Mini Pro communication over USB serial or the serial communication pins and running ESPHome so I can directly integrate it in Home Assistant. All the interaction like confirming motion, beeping can then be done whatever way the user likes it from the ESP. You can even confirm motion via actionable push notifications with the Home Assistant companion app for example.

Drilling a hole in the case of the Bekant controller isn't that big of a deal but it would be nice if I can order a megadesk controller that already has a connector installed so I don't have to modify or solder on the board.

[martingem]

@Westenberg
I wish I knew more about controllers and so on.. I'm "only" a high level dev.. For me USB would be ideal in terms of programming although someone would need to provide an SDK for it. If you guys rather like the Wifi route and can provide a sdk I would investigate testing the SDK later as well.

For the use cases described by @gcormier, they could be integrated to the micro-controller, but it'd be great to also have the option to let complete control (a dev-mode like feature) where I can experiment without limitations.

[lwestenberg]

@Westenberg

I wish I knew more about controllers and so on.. I'm "only" a high level dev.. For me USB would be ideal in terms of programming although someone would need to provide an SDK for it. If you guys rather like the Wifi route and can provide a sdk I would investigate testing the SDK later as well.

For the use cases described by @gcormier, they could be integrated to the micro-controller, but it'd be great to also have the option to let complete control (a dev-mode like feature) where I can experiment without limitations.

It depends on the protocol what devboard you can use. For example a Wemos D1 Mini has SPI, UART, i2C. So as long as a standard protocol is used and (for me preferable) one of the above then it will work. Connection can be with a usb connector on the Megadesk but pin headers are also fine.

[dbrgn]

The reason why I proposed serial control is that it's really simple to use from another microcontroller. So people could create WiFi remote-control boards, USB remote control boards, Bluetooth remote control boards, etc.

USB on the other hand is quite complex. And the current ATtiny most probably won't support it.

[tagno25]

I was trying to run it at 9600. I just tried 19200 with the board just printing out "Start" in the setup function and I am still getting some noise. I will check with a different serial adapter when I get off of work.

It also seems I2C would take too much space to fit on the flash.

[tagno25]

It seems that the serial adapter, or the wires for it, was having problems. I tried a different adapter and everything seems to be fine.

The newest code, that I have committed to my fork, has most of the serial functions working. The EEPROM related commands need more work and are currently commented out.

The serial port is set to run at 19200bps.

[martingem]

@tagno25
The newest code, that I have committed to my fork, has most of the serial functions working. The EEPROM related commands need more work and are currently commented out.

this is amazing! Do you think you could document the needed tools and how to flash?

With @dbrgn 's options (although ttl USB gives lots and lots of results... if I could get guidance.. 👍), I'd want to make sure I get the things needed and instructions to test, if possible!

[gcormier]

@tagno25
The newest code, that I have committed to my fork, has most of the serial functions working. The EEPROM related commands need more work and are currently commented out.

this is amazing! Do you think you could document the needed tools and how to flash?

With @dbrgn 's options (although ttl USB gives lots and lots of results... if I could get guidance.. 👍), I'd want to make sure I get the things needed and instructions to test, if possible!

This is already covered - https://github.com/gcormier/megadesk#hacking-and-contributing

[martingem]

@gcormier
This is already covered

Maybe I should start a different ticket for the following, let me know: I think I'm far from understanding what's needed, looking only from that place. I agree that you documented parts of it, but I only see the programmer (with 10 pin) and the 6 pin connector listed (that would exclude the serial/usb part of it). I'm willing to learn, but I'm far from knowing where to start, knowing only Visual Studio Code out of all in this repo... I appreciate the tutorial included as well, I just believe it'd help people to have more information than just the environment used (VSCode) and part of the flashing chain (AVR programmer). Also, introducing a new feature - serial logging - would mean more docs, so I'd suggest documenting it (hence me asking..). That being said, if it's as simple as plugging each other (portion of 10 pin-6pin) great, I just don't see these instructions. Maybe I should ask - instead - to tagno the signal chain, if that's a better question? Hopefully it makes sense :) Thanks

[gcormier]

Compiling/flashing is rather straight forward and covered in many places. The docs link to this tutorial which is still relevant https://circuitdigest.com/microcontroller-projects/programming-arduino-using-platform-io-to-blink-an-led You could start by using the blink sketch, but beeping the built in buzzer instead of blinking a LED.

Serial itself is covered as well;

• https://www.ladyada.net/learn/arduino/lesson4.html
• https://www.allaboutcircuits.com/technical-articles/csharp-windows-application-for-arduino/

As for the specific serial code implementation, yes, that will definitely need more discussion :)

[tagno25]

The serial commands are 5 bytes long.

1. The first byte is the data start byte
2. The second byte is the command to execute
3. The third and fourth bytes are the height as a 16 bit number (int)
5. The fifth byte is the button press number as a 8 bit number to save/retrieve heights

---

The data start byte/character is currently "<"

The command can currently be one of the following:
"+" increase height by amount
"-" decrease height by amount
"=" set height to value
"C" Ask for current location
"W" Write height to EEPROM location
"R" Read height from EEPROM location
"L" Load height from EEPROM location

• If the command is "+" or "-", then the 3/4 bytes are relative to the the current height and the 5th byte is ignored.
• If the command is "=", then the 3/4 bytes are the absolute height value and the 5th byte is ignored.
• If the command is "C" then the 3/4/5 bytes are ignored. The current height is printed out as a "=" command.
• If the command is "W", then the 3/4 bytes are the absolute height value or can be set to 0 to save the current height. The 5th byte is the the number of presses to save/retrieve.
• If the command is "R", then the 3/4 bytes ignored. The 5th byte is the the number of presses to save/retrieve. The data returned will be a "R" command with the 3/4 bytes being the saved height.
• If the command is "L", then the 3/4 bytes are ignored. The 5th byte is the the number of presses to save/retrieve.

---

• When pressing the up and down buttons the change is reported "+" or "-" commands.
• When loading via the buttons or command then the value is reported as an "L" command, with the 3/4 bytes being the height and the 5th byte being the saved location
• When saving via the buttons or command then the value is reported as a "W" command, with the 3/4 bytes being the height and the 5th byte being the saved location

[gcormier]

Was hoping to have a nice code session - unfortunately has turned into wrangling the Pololu AVR programmer and begging it to program directly from PlatformIO, with no luck so far. I can admit defeat and dig up another AVR programmer, program it from a command line each time, or keep banging my head against it :) I'll go for a walk and decide later.

[gcormier]

@tagno25 Do you want me to try and free up some memory in the base megadesk code? I've already found 80 bytes of Flash I can save and I can keep looking if that would be useful for you.

[tagno25]

The way that the load command is implemented, the controller thinks that you have pressed the button repeatedly. This implementation makes values 0, 1, and 16 unable to be used for memory locations.

[gcormier]

I've merged into the serial branch. I"ve just applied some memory tweaks (mainly int's to byte's).

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.3% (used 232 bytes from 512 bytes)
Flash: [==========]  97.5% (used 7984 bytes from 8192 bytes)

We can save another 28 bytes of memory by changing pushCount from int to byte, but it has some effect on your serial code, mainly push_addr in some functions that do bit shifting.

[tagno25]

I have converted pushCount, push_addr, and memorySlot to from int to uint8_t. As well as changing recvInProgress from bool to uint8_t.
I have also changed all the byte to uint8_t to maintain a standard.

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.1% (used 231 bytes from 512 bytes)
Flash: [==========]  96.9% (used 7936 bytes from 8192 bytes)

LIN_MOTOR_IDLE could also be changed to uint8_t which would save 42 bytes.

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.1% (used 231 bytes from 512 bytes)
Flash: [==========]  96.4% (used 7894 bytes from 8192 bytes)

[gcormier]

Okay I've changed LIN_MOTOR_IDLE

:) I actually change all the uint8_t to byte. All the same I guess :)

My plan is to let the serial branch "soak" for a bit and hopefully have people run it to comment. I'd like to run it for a month having it stable before merging to master.

I also need to consider if serial should be added with compile-time options. If the code base for other options grows based on some of the other features (motor recalibrate), that would explode our memory consumption and would mean we'd need to choose the features at compile time to fit on the attiny841. I can see if there any other avr's that have a similar price point but more memory.

[gcormier]

The new AVR 1624 looks great - 16kb of program memory, 2kb RAM and 2 hardware UARTs. It's delay and not available yet, will be probably the summer until they're obtainable in a reliable qty, but maybe late spring I can get one to start a prototype.

[dbrgn]

Oh wow, they still make new 8-bit AVR models? Nice, I thought those were deprecated in favor of the 32 bit SAMD series 🙂

[gcormier]

Okay I've got the serial branch flashed on my desk, I'll run it for a few weeks before merging to master. Even then it may be disabled by default as I think 99% of folks won't use the serial function. Those who want to use it will need to open up the board and solder on a header anyways and get their hands dirty.

[tagno25]

It seems that the output from holding the up and down buttons is incorrect. The write commands are being called faster than the desk is able to move to the next position. I am thinking that the only easy way to fix it, is to change the output to be a "=" command with the target height.

[gcormier]

This is now in the newly made dev branch. I think I'll close this issue and if there's more work needed we can open another one or re-open this one if it makes more sense.

[tagno25]

With the new ability to use both buttons for memory, should the load function be modified to work with the down button?

I can think of the following two options:

• new command (lowercase L?) to load the down button memory positions (+26 bytes)
• if the memory position is above DOWN_SLOT_START, and bothmode is enabled, then act like the down button was pressed (+24 bytes)

[gcormier]

That works for me!

[philwmcdonald]

Another view.
I've just been L(oading)/S(toring) 32+down_slot value. The other end of the serial link has to be programmed too, the translation might be easier on whatever communicates with megadesk. Chances are it's less resource constrained than this attiny.

[philwmcdonald]

I've been working on a plain-ascii human-interfacing serial mode, no need to talk/read raw-serial bytes.
It appears to be robust provided you don't paste more than 16character at a time.
accepts the same commands but in plain ascii like:

<T2000,255
<=3000,. 
<C0.0.  
<+200,0.  
<L.2. 
<C.. 
<R,0
<R.34

(the 2 numeric fields are terminated by any non-numeric character like a newline or .) Note the use of the small L command below.

<T2000,255
<C0,0
>=1545,0
<l0,2
>L1683,34
>+21,0
>=1629,0
>+9,0
>=1638,0
>+12,0
>=1650,0

This mode pushes the flash usage extremely close to the maximum. So with this on, there's little space for new features.

see #70