Projects from the grapevine: Bárány chair repair

Note: this blog post has been produced with permission from the client.

Update (2020-12-31): After receiving and installing the replacement parts, we have another successful repair! Here’s a video of the result:

Recently, a repair job came across my plate for some exotic test equipment: a “Bárány chair” used for testing pilots. This is one of those odd projects that comes through a friend-of-a-friend-of-a-friend. No electricians or repair technicians in the city were willing to touch this niche equipment – and I can’t blame them! I couldn’t find any information on this machine whatsoever.

Like most of you, I don’t specialize in exotic chairs – so what is a Bárány chair? From Wikipedia:

The Barany chair or Bárány chair, named for Hungarian physiologist Robert Bárány, is a device used for aerospace physiology training, particularly for student pilots.

Via Wikipedia

Here’s what the unit looks like:

The chair is motorized, with a wireless control to operate it:

The control allows the operator to adjust the rate and direction of rotation. The chair had stopped spinning, and the manufacturer was unresponsive and/or unwilling to repair the unit. It was clear from dead-end google searches that this unit is from a very limited run of a very niche product – there wasn’t an operator’s manual or service diagram to be found. Note the use of 3D printing for the remote control enclosure. If I had to guess, this probably came out of an R&D lab.

Upon arriving, the remote complained that it had no power to the base unit (“Dashes” observed). The only troubleshooting info available was listed on the side of the controller:

A quick investigation revealed that the power supply was plugged into a switched outlet, which had been turned off. Moving to a regular outlet caused the power supply to come online, and the controller sprang to life! No error code – just “00” on the two-digit readout. The chair was still not responding to the rotation settings – but when I manually spun the chair, it displayed the sensed rotation speed on its LED display. I concluded that the logic power supply and wireless communications were working. At this point, I suspected that the problem was in the motor, motor power supply, or the motor controller.

I investigated the power supply for the motor and found it to be outputting a steady 5V – which seemed unusual for a giant motorized chair. I would expect 12V or 24V for a large DC motor. I entertained the idea of adjusting the power supply to a higher voltage – could the power supply have degraded in its ten years of operation? The motor controller datasheet suggested that 6V was the minimum supply voltage, after all. Luckily I noticed that the motor controller had been modified for this application: it passes the motor power directly to the control logic. You can see a jumper wire that bypasses the 5V regulator in the image below. I expect that the 6V minimum is to accommodate the voltage drop incurred by the 5V regulator. Note, modifying off-the-shelf parts for out-of-spec operation is not a design technique that I recommend.

With this knowledge, I was reasonably confident that the entire system was designed to run at 5V, unintuitive as it may be. Good thing I didn’t adjust the power supply! I attached my scope to the control signal from the control logic to the motor controller to see what signs of life existed.

The control signal pictured above appeared to be a servo-style control signal – a carefully timed pulse controls the motor’s speed and direction. When I adjusted the speed control on the wireless remote, this control signal was unchanging. This suggested to me that the wireless receiver, control logic, and motor controller were likely all working – but receiving a “don’t spin” input signal. I turned my attention to the remote control:

And there it is – the rotary encoder for the speed control knob was split in two! One half was bolted to the plastic housing, but disconnected from the rest of the encoder. It still had an actuating “click” feel, without being electrically connected.

With the remote still disassembled, I pushed the rotary encoder back together to make a temporary connection – and the chair started spinning. If I had to guess, someone was a little too rough with this remote.

The replacement parts are ordered – with some careful soldering, I expect a successful repair and many dizzy pilots.

Evaluating PCBA Service: Custom Gameboy Cartridge Part 1

Earlier this year, I decided to design a project to evaluate Seeed Studio’s Fusion PCBA service. I didn’t have any immediate need for a PCBA, and so I found myself in the classic hobbyist situation: a solution in search of a problem.

The project needed a low parts count, a small PCB, and it had to be fun to design. I settled on a programmable Gameboy cartridge to meet my hobbyist needs. So, with Seeed Studio’s fusion PCBA parts library in hand, I fired up KiCAD and began my design journey! I began with some handy footprints from Gekkio’s awesome Gameboy footprints library, available on their GitHub: https://github.com/Gekkio/gb-hardware

Unfortunately, I had chosen the wrong footprint for the selected Flash chip, but Seeed Studio caught the issue and was able to help me correct it easily. Overall, their service was very good! I happily received my PCBA’s in a number of weeks.

Silkscreens: never miss an opportunity for a good pun.

Upon receiving the boards, I soon discovered that I did not place the mounting holes in the standard locations for a Gameboy shell. No worries though – that’s where FreeCAD and a set of calipers come in handy. Exporting a 3d rendering of the PCB from KiCAD took any guessing out of the equation:

The final result looks pretty good – I will note that a Gameboy PCB should be 0.6mm, but in my excitement, I must have accidentally selected 1.6mm. Therefore, the cartridge shell is very thin at the back, but the PCB gives it rigidity.

My development cartridge – fits like a glove

Setting up a project in STM32 Cube IDE is trivial work, however – I discovered that I had used a slightly incompatible footprint for the MCU. One of the pins is no longer available for GPIO:

Oops!

I double-checked all of the library components and indeed found that it was my mistake. That’s the price you pay for feverish hobbyist development, I suppose! Fortunately, I have GPIO to spare (At the top of the PCB), so I can do a hardware patch without any issues.

In bringing the board up, however, I have found that I am unable to get the MCU running at the intended 84 MHz – anything above 48MHz triggers hard faults in the CPU. Luckily, STM32 Cube IDE makes it trivial to configure global clock settings. I am not yet sure if this will be fast enough to meet the timing requirements of the Gameboy – I was unsure about 84MHz being fast enough. But, we will soon enough find out.

Stay tuned for hardware patching and new revisions!

Packet Loss, Python Scripts, and the Dreaded Technicolor DPC3848V

Are Youtube videos pausing more often than they used to? Do websites speed up after restarting your modem? You might be suffering from cable modem packet loss!

After switching to a popular Canadian ISP, I experienced all of the above. Packet loss is a common network problem. It can be due to poor WiFi coverage, bad cabling, and umpteen other things. But, if you are one of the unlucky souls to receive a Technicolor DPC3848V, the problem might be your cable modem itself!

Technicolor modem spotted in its natural habitat. Snail photo: Zdeněk Macháček

Searching this model number reveals many forum users reporting the same issues. Here’s the frustrating part – the problem is a function of runtime. Tech support will ask you to restart your modem, but this only fixes the problem long enough to get you off of the phone. Then it’s back to slow, laggy internet!

The main tool I used to troubleshoot this problem was an installation of smokeping, which will happily run on any raspberry pi or Linux machine on your network – it is even available in most repositories. Smokeping will constantly ping whatever hosts or IP’s you configure, and graph the results. This is important – when problems are intermittent or take hours to develop, you cant reasonably sit at a PC running the ping command all day. Let smokeping do that for you.

Once you get smokeping configured, it will give you easy to read graphs in a web interface. Here’s how a smokeping graph looks when things are running well:

…and when things aren’t running so well:

While troubleshooting this issue, I had multiple technicians come by. Important note: none of them cared one lick about my graphs. They have their company tools, and that is all that they will trust. One of them even claimed to not know what packet loss was…?! Perhaps they are asked to play dumb, for the sake of unloading these terrible modems. Who knows.

Anyways, when technicians don’t understand “packet loss”, well, things don’t progress smoothly. It took 4 separate visits to correct the issue. While this lengthy troubleshooting dragged on, I couldn’t sit idly by. I fired up my code editor, opened the developer console in firefox, loaded up the admin page for the modem, and got to work reverse-engineering the admin webpage traffic. My first goal was to automate a reboot from my PC, and I was able to get this working in a python script without too much hassle – you can see the code here. With this simple script, I used cron to reboot the machine every morning. I managed to get some basic configuration working as well – you could use it to automate changing your wireless network name & password as often as you like. See docsis.py for details.

Obviously, automating reboots is a very hacky fix – the only thing that fixed the issue permanently was insisting on a new brand of modem. Once the new modem was installed, the difference was night and day:

With my internet now working, I was able to stop reverse-engineering junky products and get back to what matters most: mindless internet consumption. Hopefully, this article helps someone – and, with any luck – that technician figured out what “packet loss” is!