On this page I will document the process of creating a GUI for the HUG made by Xiomara. I ordered a bunch of hardware to get started, always a joy when new nerdy hardware arrives! 🙂

I ordered a Raspberry Pi with a LCD touchscreen (and some spare Arduino’s and ESP8266s ) to get started. After some software juggling I was happy to have the LCD up and running.

Next step is my first attempt in showing a fullscreen example based on an example from [educ8s]. This means I can now start on the actual interface front and back-end.

Before I start figuring out how to make kick-ass graphics appear on the screen I will start writing some code that allows me to interface with the available timers for the HUG and see how I can control them through some simple buttons and sliders. Which makes me think I need to figure out how to code a slider that outputs values between 0 and 254 for example. Let’s take a look…

Don’t you love google? I found that the python tkinter package has a neat little Scale widget that does exactly what I need!

Now let’s wait on those timers to see how to interface with them.

Meanwhile I have attached a USB serial to TTL adapter so I can transmit the values of the sliders to external devices. In this case I used a Arduino Pro Mini with a MicroView OLED attached to display the values.

I don’t know what format the timers expect the data to be in, but the current setup will be a good vantage point.

Update 29th of August 2016

Last week I received the box of timers and other switching & control electronics from Xiomara to sort through. I will describe each component based on what is written in the manuals (if present) and based on what I find out by means of testing.

After some quick tests I have been able to distinguish the components as follows (click on the component name to jump to the detailed test description):

1. Xiomara 1502 – A generic timer & control panel that can be used to switch an IR lamp and a fain & cabin light.
   1. Interface – push buttons and a 4-digit 7 segment LED display
2. A bluetooth control unit LDCB-B01 – To provide variable power to one output channel.
   1. Interface
      1. One push button to switch between 0%, 33%, 66% and 100% power
      2. An IR remote control with the following buttons: on, off, up, down and max power.
      3. An app (IOS and Android) to control power setting (continuously adjustable using a slider with 1/100th increments) and time untill the device turns off.
   2. Maximum power – 3000W
3. A W325 Smart Control unit with an alpha wellness sensations interface – Elaborate unit to control up to 6 heaters and 3 auxillary devices (fans, lights, vaporizers, etc), multi-color light strip and music. The unit also has a temperature and humidity sensor.
   1. Interface
      1. Color LCD display with several push buttons to control all the parameters
      2. An admin app and a user app to control the parameters
4. A timer designed by an engineer firm – Should be able to variably control two output channels.
   1. Interface
      1. One control panel with a start and stop button.
      2. One touch control panel used to control power and time

After some quick tests with all the components I have the following remarks for each component:

1. Xiomara control unit 1502 – It’s a very basic and easy to use unit to simply switch any kind of mains powered device on and off, based on time and temperature.
   1. Pro’s:
      1. Basic & simple
      2. Temperature based control
      3. Additional output for fan & light (one channel)
   2. Con’s:
      1. No variable power control
      2. Not designed to be controlled externally
2. Bluetooth control unit LDCB-B01 – A solid control unit with variable power output control which can be interfaced with using bluetooth, push button or IR remote control
   1. Pro’s:
      1. Solid and relatively small
      2. Variable power output (resolution of 1/100)
      3. IF the bluetooth commands can be reverse engineerd, the unit can be controlled by a custom app or other bluetooth enabled device
   2. Con’s:
      1. Only one power output
      2. No graphical user interface on the control unit itself (except for a bluetooth status light)
3. W325 Smart Control unit – A very elaborate and big control unit, able to control up to 6 IR lamps, 3 external devices, music and ambient lighting. The unit can be controlled using an external graphical user interface and via an app.
   1. Pro’s:
      1. Variable power control
      2. 6 variable power outputs (for IR lamps) and 3 on/off outputs (for fans, vaporizers, lights, etc)
   2. Con’s:
      1. The number of available options and settings is not user friendly
      2. Ugly, sluggish user interface
      3. Huge unit
      4. The complexity of the unit makes it difficult to connect it to a custom built interface
4. The engineer firm timer – A lot of beeps and flashing lights and not a clue how to control it. Pushing the touch buttons seems to have no effect. Sometimes it stops beeping and the unit seems to respond to my fingers from a distance of 3cm. It seems like the capacitative touch buttons are calibrated with too low of a threshold. Or maybe another front panel needs to be in place. But even if I keep my distance, the unit behaves very erratic.

All things considered I believe that the Bluetooth control box is a unit to continue with. It is both simple and versatile. The bluetooth functionality combined with the ability to continuously adjust the power provides the option to control an IR lamp with both an app and with an interface that can communicate using Bluetooth.

If I want to control the Bluetooth control box using a custom built app or via another bluetooth device I need to find out what communication protocol is used. I believe I can obtain this information using two methods:

1. Sniff the bluetooth commands between the device and the phone using a bluetooth sniffer or HCI logger
2. Decompile the APK that is used to control the device and search for the specific bluetooth commands used.

Update 22nd of September 2016

This seems to be more difficult than I initially thought. The logs of the bluetooth commands are hard to interpret and the decompiled APK has been decompiled so hard that it became unreadable. In parallel I tried to connect my BLE enabled Raspberry Pi 3 to the Bluetooth control unit, but I have not (yet) succeeded in talking to it. At this moment I am seriously doubting if I will be able to have a custom program talk to this unit via Bluetooth. It might be easier to buy or create a variable power circuit that can be controlled externally, so I can control it via the Raspberry Pi.

Update 10th of October 2016

I’ve decided that the bluetooth track is a very hard and unpleasant one to follow. So now I am focussing on interfacing with the custom built timer. It seems that this timer is able to variably control power as well, so this might be a good choice after all. I will start with sniffing the TTL serial connection and the I2C bus to learn how the touch interface communicates with the timer board. It seems that

Each 840ms a burst of data is send from the controller to the interface.

Total length of the burst is around 2.9 ms (=2900ms)

The duration of one bit is 8.8us.  2900/8.8 = 329 bits. Guessing each byte contains a stop and startbit and no parity bit, the data burst contains around 32 bytes.

10 11001010 (64+16+2+1 = 83)

10 0100 1100(32+16+2=50)

Update 26th of October

I figured it out: baudrate of the serial communication between the timer and the interface is 115.2K. In order to capture the messages to be able to interpret the communication protocal I used the Softwareserial from an Arduino to read the messages and relay them to my PC using the hardware serial port. According to the Softwareserial library manual the speed of 115.2k sohuld be possible, but after probing and comparing the signals I found out this wasn’t the case. Next step was to sniff out the messages using the hardware serial port of the Arduino, relay these messages to another Arduino using the I2C protocol and then relay the messages to my PC using the hardware serial port of the second Arduino. Now I finally received correct messages.

Now I could start to reverse the communication protocal so that I could send and receive messages to the timer with a custom built interface. I will add my interpretation of the communication protocal later, but in short I think it works like this:

When the timer and power settings are configured on the interface, a configuration message is send to the timer. When the message is correctly received, the timer transmits an acknowledgement message. If not, the timer sends an error message. I have not checked this, but it might be the interface tries to send the same message again for a limited number of times after this.

When the program is stared, the interface sends a start message.

When the power settings are changed while a program is running, a special power change message is transmitted by the interface.

While a program is running, the timer transmits a status update every second, containing at least the time left and possibly also the power settings.

When the program is finished a special status message is transmitted by the timer.

When the program is stopped or paused via the interface, a stop message is transmitted that will switch of the power to the outputs while the settings are preserved.

A configuration message contains the following info:

1. Configuration message header
2. Channel 1 enabled / disabled
3. minimum power setting channel 1
4. maximum power setting channel 1
5. Power setting channel 1
6. Minimum timer setting channel 1
7. Maximum timer setting channel 1
8. Timer setting channel 1
9. Soft on length channel 1
10. Channel 2 enabled / disabled
11. minimum power setting channel 2
12. maximum power setting channel 2
13. Power setting channel 2
14. Minimum timer setting channel 2
15. Maximum timer setting channel 2
16. Timer setting channel 2
17. Soft on length channel 2
18. Checksum byte (total of all bytes MOD 256)

Now I will be able to create my own messages using the Raspberry pi and use the touchscreen to control the timer.

Picture below show how I compared signals from the timer and from the Softwareserial of the Arduino. Last two pictures shows a second draft of an interface on the Raspberry Pi touchscreen to control the timer and read the status messages.

 

 

Based on what I know how someone will use the HUG, I came up with the following requirements for the user interface:

– a quick way to start a standard program
– options to start other presets
– a way to change presets and save them
– For a preset the user must be able to see the duration and strength of the session
– pause a session at any time
– restart a session
– change the time and power of a running session

A translation of these requirements to an interface:

Main screen with a button to start a standard session. On the main screen you will see the length of the session and the power setting. If it is a valuable feature to change the power throughout a setting, a small graph can be drawn to indicate the changing power over time.

The name of a preset could be something like: Quick recharge, Deep relaxation, Slow sedation, etc.

When a preset is selected, another screen appears that contains the details of the session, a start button and an edit button. When the start button is pressed, the same screen shows, and the total time of the session is now a countdown timer. In the graph that shows the power against the time, a vertical bar gradually moves to the right to indicate the progress of the session and the power setting of the front and the back heater.

On the main page is also a button to create a new session type and a button to shutdown the interface (and the HUG as well).

When the user defines a new session preset, he slides his finger across a bar on the display to set the duration of the session. The duration can be fine-tuned using a increase and decrease button with a 1-minute resolution.
Then the user can select the power settings of the front and back heater. If one setting is entered, that setting will be maintained throughout the session. It is also possible to vary the power setting throughout the session. To achieve this, a second power setting is entered. This will automatically insert a transition bar for which the duration of the transition can be altered. For example: the user entered an initial power setting of 80% for both heaters. For the second setting he wants the heaters to increase to 100%. The transition bar can be used to define if the transition between these two settings takes 10 seconds or 1 minute. Another bar needs to appear which is used to define when the second setting needs to be initiated. If the length of a session is set to 20 minutes, then the initiation of the second setting (the end of the transition period) can be configured at 10 minutes. When the transition period is set to 5 minutes, then the power to the heaters will start transitioning from 80% to 100% 5 minutes after the session is started and completes 10 minutes after the session start. The power to the heaters will remain at 100% for 10 minutes until the session ends at 20 minutes.

Apart from the interface, I need to implement the following aspects for the correct communication between the timer and the new interface:
– interface needs to interpret status message in order to display the remaining time
– interface needs to interpret acknowledgement messages of the timer
– interface needs to interpret error messages of the timer when a message is not received correctly.
– interface needs to send configuration messages
– interface needs to send start messages
– interface needs to send stop messages
– interface needs to send change messages

Continued at: http://www.thepsychologicaltechnologist.nl/projects-3/hug-remote-wifi-module-control-interface/