Project Logs

Collapse

• New transmitter & fine precision mode

  lion mclionhead • 10/06/2023 at 07:07 • 0 comments

  The decision was made to go back to the wide enclosure with 8 buttons.  The preset button would be M to match the OEM panel.  A new F button would enable a fine precision mode to work around the latency.  Latency is definitely a combination of starting the transmitter radio & the network hops.  It was also a pain to make fine adjustments with the OEM button panel.
  

  The presets would have numbers like the OEM panel. Lions actually have never read the lettering on the buttons.  It's purely based on a childhood memory of wondering how cartoon characters knew what all the buttons did without any labels.
  

  Manely, the buttons would be smaller buttons, spaced out to match the vintage layouts.  The current buttons are as narrow as possible while having enough layer adhesion.
  

  Those vintage interfaces had tiny buttons, but anyone with a remote controlled TV was special in those days.  Going narrower would entail some kind of annealing or a much deeper enclosure where the buttons don't overlap the caps.  It's already a hassle to tweak the caps to grip the buttons.

  Decided to keep the original nano mister battery since it wasn't completely dead after a certain time with a lot of button presses.  The dial parts also got reused to skip realigning the hall effect sensor.
  

  Right away, RA0 on the micro was dead.  It wouldn't pull up or read, the hazards of scavenging chips.  Fortunately, there was a debug pin suitable for the job.
  

  The seal of quality. That's how you know it's something special, almost japanese-like.

  For high precision, the ESP8266 was configured with a 20Hz tick.  The desk responds to button presses down to 1/20 sec at which point it moves 1/8", not a useful amount.  The movement is proportional to the press time.  At 1/2 sec, it moves 1/2" - 3/4".  At 1/4 sec, it moves 1/4 - 3/8".  The movement is very imprecise.  Presets seem to max out at 1/4"-3/8" precision so it simulates a 1/4 sec button press for now.  Most of the time, a 1/4 sec press is enough to get it to move back to a preset.  Shorter button presses don't make it return to the preset.
  

  This introduced a new problem of the desk not picking up sequential button presses in fine mode.  It needs a recycle time after a button press, after which it responds to the next button press.  Normally, rapid button presses are immune to the recycle time because the buttons stay down but with the button presses timed, successive button presses don't get picked up at all without waiting for the recycle time.  It would take knowledge of when the desk has begun moving to press the button for exactly the recycle time + the fine press time.  
  

  Another way is to read the height reports & time the button presses based on that, but this seems much less precise than the 1/4 sec movement.  Desks 1,2,4 got a firmware update.
  

• Radio debugging

  lion mclionhead • 07/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.

  Managed to observe it responding to pings while not taking UDP desk commands, so the problem narrowed down to the desk firmware.

  It finally ended up being the 0xff of the ADC being confused for the 0xff start code.  It was a use case for byte stuffing.
  

  --------------------------------------------------------------------

  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 mclionhead • 06/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 mclionhead • 05/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 mclionhead • 05/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 mclionhead • 05/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 mclionhead • 05/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 mclionhead • 05/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, timer1.  timer1_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 mclionhead • 05/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 mclionhead • 04/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. 
  

View all 27 project logs