Standing desk remote control

Control multiple desks over wifi

Similar projects worth following

The keypad that came with the desk is an angled membrane deal which is truly terrible.  This interface was fine, 8 hours a day in an office.  16 hours a day at home, it matters.  The membrane buttons don't want to stay pressed.  Any glitch entails a 1 second delay while the relays click off & on.  The desk is constantly switched between working, sitting, eating, & yoga pad heights.  It's become clear that 4 presets are essential.  Presets are a substitute for better buttons.

Uplift's cheapest keypad with tact buttons & presets is $40.  The OEM keypad is on alibaba for $25 in quantities of 100.

The lion kingdom acquired 4 desks to build out its standing desk empire & they all need upgrades.  Spending $160 to upgrade all 4 is unaffordable.  

The internet partially reverse engineered the protocol for these keypads.

But as usual, there are missing pieces & lions are amazed guys with so few skills are able to afford $4 million starter homes in Wichita.  The preset commands remane unknown.  

Custom keypad ideas range from a single IR control with a dial selector for the desk, 5 presets, 1 set button, 2 direction buttons using high quality MHPS2283V buttons.  Making a physical control for every desk would entail 32 buttons & a lot more fabrication work.  There's a compromise between quality of the buttons & number of controls.  Any upgrade would involve keeping the stock membrane controls for local use.  The custom control would be for the presets.  The IR receivers would bolt onto the membrane keypads.  A TV remote with dome buttons probably wouldn't be good enough at sustained button presses.

The lion kingdom could burn $40 on an uplift keypad to reverse engineer & use in just 1 desk.  Presets can also be simulated by reading the status bits.  There must be a better way of selecting the desk than a dial, possibly an orientation sensor or a laser.

  • Radio debugging

    lion mclionhead07/05/2023 at 07:35 0 comments

    The CC1101's proved just as unreliable as the AM system.  Most of the time, there was a long delay.  Sometimes it would never receive until pressing many times or moving to another position.  As the 1st attempt at powering a radio up with every button press, it was pretty bad. 

    The bathroom light was far more reliable for some reason.  Maybe it was being farther from other gadgets.  Maybe it was the simpler code.

    Going back to IR would make it totally worthless.  An LED went in the router to indicate CC1101 reception.

    That showed the 433Mhz radios were bulletproof & the wifi for desk 1 in particular was dying.  Pinging it to keep it alive made no difference.  The button has to be pressed multiple times to get it to go.  It shouldn't since it's UDP.  There were theories that desk 1 was flashed with broken firmware.


    The idea occurred to salvage the original transmitter's 8 button board & go back to the original form factor.  It would allow a bigger battery & more importantly spread the buttons apart while keeping the narrower caps, like a 1980's remote control.  The current buttons are too crammed for a clumsy old lion.  1 button would enable the stepping mode.  Implementing the stepping mode would be a buster.

  • Wishlist

    lion mclionhead06/07/2023 at 23:01 0 comments

    The next big desire is a way to precisely move in the minimum increments.  This was hard to do with the manufacturer's button pad.  It's impossible with the latency of the wifi remote.  There could be a button combination which made the receiver pulse an amount known to move the minimum distance.  This would entail building a new remote from scratch.  An 8th button would enable nudge mode. 

    There were ideas of using the S button, but if the desk picks up the S button, it rejects the direction buttons for several seconds.  There could be an extra delay before transmitting S.  If it picks up a simultaneous direction button during the delay, go into nudge mode.  For cases where the user really wants to press S, the extra time required to see the LED flash might be hardly noticeable on top of the wifi latency.  The user already has to wait for the LED to flash to go into S mode.

    A long press to go into S mode might improve the experience, since it's prone to accidentally being pressed & can overwrite a preset.  There's still a need for the user to not press the direction button before S.  That would always cause it to go into normal direction mode.

    Maybe it could be a 2 step process where the user presses both direction buttons simultaneously, then releases 1 before the other.  This is very complicated compared to a single step.

    It occurred to the lion kingdom that conventional IR remotes avoid glitches causing double presses by transmitting the button code once, followed by a repeating pulse.  If it drops a few packets, it knows it's not a 2nd press because it doesn't get the button code again.  The problem is if it misses the button code, there's no 2nd chance.

    The unique ID that the desk controller uses is also required for the wireless GU24 bulb & every user interface toggle.

  • RF bugs

    lion mclionhead05/26/2023 at 01:02 0 comments

    Didn't take long for the RF system to go downhill.  Flexing of the enclosure causes the dial to hit the wrong desk.  The preset bug workaround rarely works anymore.  The low packet rate makes it impossible to manually move 1/2".

    More stringers on the front panel reduced the flexing.  The hall effect screws should point towards the panel to save space.

    The mane problem is the LP2989 is extremely slow to ramp up. 

    As it dials through the 4 desks, the ADC reports a very slow voltage ramp for the 1st few seconds as VDD slowly rises to 3.3.  The original design had the brain power on the transmitter since it transmitted directly to each desk.  With the router as the only receiver, the analog translation can all go on the router which allows finer tuning of the values.

    The biggest problem is the vagaries of radio reception make precise manual control hard.  The baud rate was stepped up to 4khz & the packet rate was stepped up to 33Hz but it drops a lot more packets.  Instant on & low latency are a difficult problem.

    The leading idea is a longer debounce for preset buttons & a shorter debounce for direction buttons.  Lowered the packet rate to 20Hz to avoid flogging the network.  1 artifact of relaying everything through wifi is sometimes a packet arrives seconds after you release the button.  It's definitely not ideal.  Each desk would ideally receive 433Mhz directly.

    There could be a unique ID for each button press on the transmitter.  The algorithm would be if it times out & gets pressed again, but the ID is unchanged & it's a preset button, don't press it a 2nd time.  The set button has a long press mode for locking the panel.  Lions have never used the panel lock feature so that could be neglected.  The preset buttons would have the single press workaround while the direction buttons would continue to drop out.

    Of course, it would be a lot easier if the 8266 didn't have to use the TCP/IP standard.  It would cost $25 to get rid of wifi & just directly transmit to a CC1101 in each desk.  This would be the ultimate fix.

    In the meantime, the button press ID solved enough of the problems to make a vijeo.  Verified the problem with the height bug is the desk stopping before it ever reports the MIN & MAX height.  The firmware has no way of knowing it has reached the limit, so it never presses the button again.  Reception quality & latency remane the last problems, but are relatively more bearable than having to point an IR LED.

  • RF conversion complete

    lion mclionhead05/24/2023 at 02:21 0 comments

    The key requirement for the 8266 was rejoining the network when the router went down.  The leading theory is to poll WiFi.status() != WL_CONNECTED.  When it dies, call ESP.restart() to drop kick it.  The mane trap for young players is ESP.restart() doesn't work immediately after flashing the board.  It just goes back into the bootloader.  You need to manually reset it before ESP.restart() restarts the program.

    3 sided bathtubs with hot snot continued to be the best solution.  The LEDs managed to be press fitted, but could also be riveted.

    Production of the boards commenced.

    The router extension was loosely based on the 2nd generation starlink router.  Unfortunately, none of the starlink router designs are big enough to store everything required by the router.  They all might end up in the gadget graveyard.  The mane requirement is the antennas being vertical.

    Then it was a matter of assigning desk numbers with IP addresses in dnsmasq.

    When the PIC lag is combined with the wifi lag, the lag is very pronounced, but the convenience of not having to point the controller outweighs it.  In the worst case, the controller has to be vertical to align the antennas.  Most of the time, the controller is in 1 spot right next to the router.  The biggest problem might be manually positioning to within a 1/2".  You have to watch for the LED to turn on.

    Controller evolution.  No doubt, the old wider controller was easier to press the buttons on, but every square foot is $2000.  There's always just moving the electronicals back into the old controller if the buttons prove too painful.  Lions were inspired by the tiny buttons in vintage japanese remote controls.

    The trick is they had large gaps between the tiny buttons.  Dialing in the perfect form factor would entail many prints & a lot of money.

    Considering the latency & the complexity, this system is incredibly dysfunctional compared to transmitting from the controller to a 433Mhz receiver on each desk.  It would just be incredibly expensive to install an ISM radio & microcontroller on each desk, compared to bouncing the signal from a single 433Mhz receiver to the ESP8266's which were free.  The ESP8266's just can't use any protocol except wifi.

    There's no feature for the desks to report their status to the router.  Never had a use for such a feature.  There could be a benefit to dialing in a height on a browser, but it would be hard to achieve.  There's no low speed manual command to change height.

  • RF Remote completion

    lion mclionhead05/23/2023 at 02:33 0 comments

    Power consumption for the controller ended up at 40mA.  You can fly to the moon on that much power.  It definitely needs a removable battery.  

    It took a lot of fenegling to get the hall effect sensor in the right position, but the predicted position in CAD ended up correct.  It really needs a recessed position with PLA rivets.  It should be noted the sensor position is right in the center of the package so that's the part which needs to go on top of the fiducial.

    Then the CAD program can give an idea of where the magnets are going to line up.

    The LED showed the startup delay was caused by the PIC rather than the radio.  The PIC's startup timer didn't make any difference.

    It wasn't easy to cram everything in there.  The only battery that would fit was a 150-200mAh from a nanomister, with a tiny stub of a connector bodged on.  Most of the space was taken up by the radio.  The hall effect sensor platform could be redesigned to free up space.

    Time for more shots before scratching it up.

    It could use some adhesive feet on the bottom, but the bottom is much easier to fabricate than the top.

    The next task was creating all the ESP8266 receivers.

  • New controller

    lion mclionhead05/21/2023 at 03:14 0 comments

    Moved a CC1101 from a board marked receive only to a board marked bad & it suddenly worked in receive & transmit mode.  So there was something funky going on with the passives or the soldering on these boards.  It might be why some went bad.  The chip from the board marked bad might work on another board.

    The mane remaneing problem was a long startup time for the transmitter.  No matter how fast SPI is driven, there are delays for the AGC's & the frequency synthesizers which the AM system & IR didn't have.  The startup time is highly variable.  That's why these remote controls can't send out a short pulse & time out.  They have to transmit continuously as long as a button is pressed.  Of course, even the fastest system still has a minimum latency because the codes go at 10hz.

    Power consumption of the ESP8266 in idle mode was enough to fly to the moon. 

    Pin 15 was some kind of reset & couldn't be used for anything.  Pin 2 was the blue LED.  Every useful GPIO had to be used.

    Noted the UART from the desk sends the LSB 1st.  Lions spend most of their time debugging SPI & always  expect MSB 1st.

    Dropped the STOP button from the remote control since experience showed it was easier to remember to hit a preset button to abort a motion & there weren't enough MHPS2283V buttons. 

    The controller got a significant upgrade to a narrower form factor & of course a shiny glass bed finish.  Noted the detents require lubrication or they'll eventually jam.  Noted the large unused space tends to flex, but that space was needed for the battery. 

  • The return of the hiletgo

    lion mclionhead05/09/2023 at 05:14 0 comments

    The hiletgos returned with the transmitter running on 8V & the receiver running on 5V. This yielded acceptable range in a test.  It also worked with the motors running.  The receiver forwarded all the desk commands along with the weather station data on USB.  The big differences are the receiver not running on the desk power & the receiver not changing any voltages in the long desk wires.

    The mane problem was extreme interference with the audio amplifier.

    The next step was connecting the ESP8266 to the desk.  A quick flick of the multimeter showed the desk UART sourcing 5mA to 0V & the desk buttons sourcing 0.6mA to 0V so it would be a straight connection.

    The last ESP8266 project was an access point in 2018 which merely forwarded the UART to WIFI.  It only has 1 UART.  For a software UART, the ESP8266 has only 1 spare hardware timer, timer1timer1_attachInterrupt, timer1_enable, timer1_write access the hardware timer directly.

    To get a system time for delays, there's the millis() function, os_timer_arm, os_timer_setfn.  These share timer0

    An ESP8266 went straight into the desk connections with no buffers.  Verified the desks accept 3.3V as high.

    There was a complete mockup of a new transmitter with buttons.  Then the wheels fell off.  The radio signal integrity wasn't good enough to differentiate multiple codes.  The previous test only exercised 1 code.

    The transmitter got a 1/4 wavelength & the receiver got a full wavelength antenna.  The bitrate was 2kb.  These were the most optimum conditions.  There was no obvious benefit from 8V.  Higher bitrates were worse.

    At least the ESP8266 demonstrated the rest of the communication path was working.  It received the button codes over Wifi UDP at 10Hz.

    Another bag of CC1101's seems to be the only next step.  They have a role in many other projects.

  • 915Mhz to IOT bridge

    lion mclionhead05/08/2023 at 23:40 0 comments

    Another board with the very last Si4421 in the world was fabricated. This chip was a real buster. It wouldn't start up reliably. Clever switching of Vdd to 0, then 3.3V got it to start up but when it did, it was transmitting way up on 1087Mhz & sucking a lot more than 50mA. Changing the frequency register didn't do anything.

    Barring a layout error, the very last Si4421 in the world was dead.  There were a few routing errors manely involving GND, but the power supply didn't allow it to power up.

    It actually drifted as the crystal temperature changed.  Higher temperature pushed the frequency down.

    915Mhz wasn't very appealing because at the weather station's 8192 baud rate, it was going to be on 100% of the time, jamming the weather stations. It would entail changing everything to 100kbaud.

    With 3 dead radios, the lion kingdom seems to have run into the limits of the spare parts. Another idea began to hatch, involving running the hiletgo on 12V for better range & transmitting to the router to avoid motor noise. The market seems to have shifted to low cost AM radios for instant startup, hence the lack of any more FM radios with instant startup.

  • 433Mhz to IOT bridge

    lion mclionhead04/29/2023 at 07:12 0 comments

    The leading contender for replacing IR pivoted to a central bridge that received 433Mhz FM from the CC1101 & transmitted on Wifi to all the desks.  The CC1101 definitely starts up fast enough.  There are 4 ESP8266's which never found any use in 5 years because they're too slow.  They only support wifi.  They would have to bind with the router.  Although they could become wifi on a raspberry pi's 2nd SDIO port, this was totally impractical.  Wifi desk control is what the rest of the world would do.

    The hardest part is the 433Mhz connection to the router.  The router needs a bigger enclosure for all its radios.  The existing weather station radio needs a 433Mhz input.  It would merely translate the 433Mhz codes to legacy IR codes & forward them to the router.  The router would forward the commands through UDP.

    The trick with the ESP8266's is they only do 3.3V.  The desks output 5V, so all the existing 16F1508's would have to stay as level translators.  The ESP8266's would just output the legacy IR code at 3.3V & the 16F1508's would be unchanged.  There could be a test to see if the desk pins handle 3.3V.  Then the ESP8266's could go in through resistors.  The 16f1508's are quite valuable.

    New batch of boards begins for the 433Mhz conversion.  1 board was for a camera mount.  2 boards were for the desk control.  It's getting common for the etching process to create swiss cheese.  Not sure why this is.  It might be the age of the photoresist. 

    Of mane focus was the new router board. Once again, the lion kingdom came a gutser for not having input capacitance for the voltage regulator even though these are all low power radios in receive mode.  The LP2989 is a finicky beast.

    Note the 12Mhz crystal was referenced to 3.3V instead of GND.  This was a routing optimization unique to lions.  The router board involved an obsolete MRF49XA for 900Mhz weather station data, a CC1101 for 433Mhz desk commands.  A sane router would use single radio chip & have all the packets on 1 frequency, but these were the spare parts & simplest solutions.

    The desk control blasts continuous RF like IR. The weather displays would lose packets & show -- when the desks were being commanded on 900Mhz.  The climate recording would lose packets but the climate recording has so much unused data, it wouldn't matter.  The desk packets could go at 10Hz with the transmitter off between packets, to give the weather data a fighting chance.

      Arbitration would require a much higher bitrate & 2 way communication.  The weather radios use 1 way 8192 baud in a failed experiment with minimizing power usage.  To share the radio with the desks, they would need 100kbaud & ACKs.  The desk control would need single button state change packets & ACKs if it was to share the weather frequency.  There would be a lot of investment all the way around.

    Helas, much debugging revealed the last 2 CC101's had no transmit functionality.  They could receive from the Gu24 radio but not transmit.  They transmitted some kind of noise but not data.  Of the 6 original CC1101's, only 2 still worked & those were in the Gu24 controller.  It's not clear why they all died.  Historically, only 2 were ever used in RC cars.  2 flatlined in that role.  The power amplifiers could burn out if the antenna impedance isn't matched. 

  • Increasing Hiletgo range

    lion mclionhead04/23/2023 at 22:37 0 comments

    So the range ended up being 3ft when sending the stock IR protocol through 433Mhz AM.  It's going to take some modulation changes to get enough range.

    The IR protocol was 25ms high between codes.  Pulses are 200us high between bits, 200us low for a 0, 400us low for a 1.  The codes are 80 bits.  It averages 2000 bits/sec.  The 25ms delay was created by sampling the dial. 

    The 80 bit IR code was too long to get through AM. 

    For AM radio, the best solution ended up being resending 16 bit codes as fast as possible, at 2kbit/sec with no framing bits & straight RS232.  Smaller codes & higher bitrates create longer range.  Averaging or low pass filtering was useless.  There is a maximum bitrate imposed by bit banging.  The minimum bitrate is imposed by the AGC & happens at 100 bits/sec.

    The codes are counted so a code received a certain number of times in a certain amount of time is counted as a button press.  The codes have to be high entropy to avoid getting washed out by the AGC.  Ideally, they have an equal number of 0 & 1.

    Lowpass filtering & deglitching ended up being failures.  It was equivalent to sending more data at a higher bitrate.

    Not having line of sight between the antennas degrades the signal.  Changing any voltages in response to a received code causes a feedback loop which causes reception to oscillate.  Changing any GPIO seems to foul the AGC.  The UART seems immune though.  Further problems with AM come from the motor brushes & the receiver moving.  The motors always knocked out the direction buttons.  Preset buttons had some immunity to the motors but weren't perfect.

    There's some improvement to be had from a decoupling capacitor on Vcc, 1/4 wavelength monopole for the transmitter, full wavelength monopole for the receiver & using a longer cable to space the radio from the brain, but there's always a position in the room with a low enough signal strength to induce oscillation.  Some codes like preset buttons were more robust than others.

    After much testing, 433Mhz AM was busted for this application.  The trick is getting an FM transmitter to start fast enough.  The CC1101 might be the only thing nowadays which could do the job.

    There is a 1nF lowpass filter capacitor on the receiver. It can be replaced with up to 50nF. At 50nF, the bitrate is reduced to 500bits/sec. It's slightly more robust. Together with smarter codes, most of the oscillation goes away except oscillation caused by the motors.  The biggest problem is it increases the button latency.  In testing this method, it picked up false code matches so that was busted.  It needs more codes per second.

    Another idea which might work is creating a single centrally located AM receiver which blasts IR throughout the room.  It would still be vulnerable to IR obstructions.

    There was an idea to send the start code once, followed by a simpler code which was immune to the motors.  The problem is how long to send the start code.  Too long & there's going to be a gap after it starts the motors.  It could wait for the sustain code before starting the motors but there's going to be a 1/4 second delay.  Maybe it could retransmit  the start code but just detect part of it after the motors start.

    Increasing voltage above 4.2 would entail a level converter, voltage regulator, & still only marginally increase range.  The CC1101 would definitely work.  It starts up fast enough, but it would entail redesigning every board, throwing in voltage regulators.  It could be fully tested in parallel without tearing apart the existing boards though.

    The mane problems with IR are having to move around to command each desk & having to hold the transmitter to send a command.  The stock controllers just needed 1 finger.

View all 26 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates