[Contribution] Extend supported hardware to IPSTube #72
Comments
|
Interesting hardware. They opted to place ESP32 and supporting components directly onto the PCB instead of the readily available module. What you need to do:
|
|
Sorry if this is a trivial question, but as mentioned I have no experience with ESP32 chips, so I don't know how to boot mine in bootloader mode. I found these instructions but I don't have the necessary hardware skills to process them. In particular, how do I control the More generally, do you happen to have more detailed instructions of all the steps you mentioned, targeted at someone still learning about ESPs ? |
|
The ESPtool software will handle all the RTS and DTR lines for you (if properly wired on the board by the Chinese guys). And it will automatically reboot the clock into the bootloader mode. |
|
I could backup the original firmware with esptool. It's 4MB. |
Every time I try to use ESPTool I get "No serial data received". According to their documentation, this means the hardware is not properly wired, hence my earlier question of whether I need to do something more to put the chip in bootloader mode ? The device has one button only (Shown on my PCB picture earlier). Pressing it for 5s resets the chip, which is the only time I'm able to read any data from the serial port (Using a basic |
|
Hello Holbormon! I assume, you get the "No serial data received" message, while you are trying to write your backuped firmware back to the clock again? So something like "esptool --port /dev/ttyUSB0 --baud 921600 write_flash --erase-all 0x0000 backup1.bin", right? And you can also try to press this little button on your PCB, while plugging-in the "power cord" to the clock and hold it for a few seconds while the device is booting. Sometimes, this brings the ESP into the bootloader mode (depends on the wiring). And like aly-fly indirectly mentioned, you need to identify the hardware used on the clock, so make pictures of the chips with labels/prints on them, so the letters can be read. Smartphone camera with zoom and different angles and light mostly will do the trick here. Most interesting for you is the ESP and the clock chip. If you are really interested, you can also try to get the wiring of the PCB by taking photos from both sides, a multi-meter, some time and interest :) Then you can identify, how the ESP is soldered and if you can/need to solder some "helper" pins to put it into bootloader mode, if needed. Bye |
|
AFAIR the button next to the usb connector has to be pressed and hold while connecting the usb cable. Then start |
Hello eku, I already wnated to ask, how you was able to work with the clock, but you was faster ;) But will still ask my questions: Do you have the same clock like Holbormon is mententing? Bye |
Thank you for the precision. This seems to indeed boot the clock in a different mode (All screens are backlit but blank). I also had to use a different USB Cable because the one shipped with the chinese clock resulted in constant pySerial I/O errors. I have finally succeeded in running I have also succesfully dumped the memory from 0x00000 to 0x400000 as previously advised, but a quick inspection of the resulting 4.0MB file shows empty regions at the beginning and start, suggesting that the actual firmware may be smaller ? Now that my dev environment is finally setup properly I will proceed with the repo's steps and report back. |
The flash is partioned. Don't know how to read the partition table back, but I guess there are at least 2 OTA and a FFS partition. |
Just did thanks to these instructions and
|
|
@Holbormon thanks for the info. Looks like we need to dump 8MB to also safe the original pictures in spiffs. Could you please provide a more sharp foto of the pcb, so we could read the component identifiers? |
Done.
Speaking of the PCB, can anyone advise whether my hardware looks susceptible to the power problem that the original Elekstube has (5V being fed to the ESP32 as described here) ? |
|
Flash is XT25F64 from XTX Technology Limited, which is 64x1024kBit = 8MB. RTC is a DS1302 replica. So far so good. It would be interesting to know which LCDs are used and how they are connected. Can you find out? |
I'm still on original firmware and waiting for more hardware details. I generally have the confidence to compile the software myself once I have all the details for the configuration. |
Again, I am much more versed in software than I am in hardware. Also, I don't have access to basic tools such as multimeters and soldering irons. Would more pictures of the other side of the PCB suffice to tell ? |
It is about the six little TFT-LCD panels, which are displaying the "digits" of the clock. |
|
It is required to get full reverse-engineering of the hardware, all the chip details, which pin of which component is connected to which pin on the other component(s). Because the clock has 8 MB flash (double of what everyone else has) there are two ways forward:
Regarding the voltage issue from the original clock - best is to measure the supply voltage of the USB chip. If it is 3.3V then it is ok. If it is 5V, you have to search for any resistors in series with the Data TX line. |
|
Got some more pics of the PCB/LCDs. Unfortunately unable to determine screen manufacturer/model by mere visual inspection. Glare on the last one shows a bit of LCD wiring. Does this help ?
|
|
Hello again Holbormon, If the link is right in your first post, the clock is from "IPSTube" and it is model "401". Which one of them do you own?
Bye |
It's a bit misleading because the case of mine looks like the bottom picture (black and gold lines), but the base is most definitely not lit up with LEDs. I'd say it's the top model, cheaper, no lights. Are you hoping to find datasheets somewhere ? The manufacturer's website looking like it does in my first link (that is, terribly bare), I'll admit I didn't hope to find any helpful tech specifications anywhere else. |
|
Ah, my bad, the first one seems to be the model 402. Your is like this one, I guess: |
Sadly, not really. It just shows us, that the LCD panels are not "plugable" and not using a socket, like it is for the most Eleksmaker IPS clock copies. And it shows also, that they "glued" some stickers with a dragon on it :) Most of these clock manufactures are just copycats, so the chance, that they are using nearly the same panels with the ST7789 driver as all the others, are high. But most of these small panels using 8 lines, so you can't be sure. The only way, is to follow the wirings to find the right pins ;) and then try and error, if the usual driver is working. If you are willing to risk to damage the device, you can "unplug" one panel and try to remove it and use an ardiuno board to communicate with it :) Or try to remove the stickers, but that will probably damage the panel and there is no gurantee that you will find any model numbers under it. So it depends, on how much time you want to invest and if you want to risk damaging the device to go on from here. Bye |
|
I'm currently setting up the development enviroment to build and test self comiled firmware with the IPS Tube. The instructions recommend the use of VSCode with plug-in for PlatformIO. As a fan of the command line, I prefer to use Makefiles. Can anyone help me with this? |
I was actually also working on this myself. For now I have succesfully followed these instructions up to the point of having to run |
Even if you don't want to use Visual Studio Code (which I can highly recommend for every OS), there is the CLI of PlatformIO (see https://docs.platformio.org/en/stable/core/index.html). It is doing all the "magic" in the backgound. You should be able to use it without any GUI (see https://docs.platformio.org/en/stable/core/installation/shell-commands.html#piocore-install-shell-commands). Bye |
|
The instructions for building the firmware yourself need a little revision. The chapter "Configure the TFT_eSPI library" comes before "Configure, Build and Upload New Firmware", although it requires files from the following step. The Pythen scripts do not contain a shebang and it is not clear whether they require version 2 or 3. I'm still fighting my way through it. To be continued... |
|
Configuring the firmware is tricky. I only see 5 circuits, ESP32, Flash, RTC, CH340 and voltage regulator. No shift register for selecting the LCDs. No control buttons. Any ideas? |
PY comes together with PlatformIO + VScode bundle. Therefore no need to know which revision is it. If you still insist on going barebones (CLI), this is up to you to figure out.
Probably everything is connected directly to the ESP32. If there are no buttons, this frees additional IO pins, so there might be enough of free pins for all displays. |
|
hi all, Yesterday I took a look at the pinouts of the IPSTube PCB and there are some differences compared to the other versions. Please keep in mind this is a best effort endeavor to map out the pins. I did my best to test the PCB connections, does not mean it will necessarily be flawless...
The displays (FP-114H03A JY) seem to have the following specs and connect with an FPC connector to the board.
DS1302Z Clock/calendar chip 25F64 8MB PSRAM The is only one button on the device. Perhaps this could be good enough as mode or power button while the rest is controller through the web interface. The RGB LEDs behind the displays are likely NeoPixel Mini 3535 RGB LEDs.
The last (6th) LED (R) DOUT chains to RGB connector under board, I suppose to add more LEDs for underneath lighting. There is also a USB serial port converter of type CH340N, which connects to U0TXD/U0RXD. Have not looked at the code in this project close enough, but it seems that some things need to be adjusted:
In the coming days/weeks I try to figure something out (unless someone can help with at least the direct drive of the CS lines). If anyone is interested in photos of this devices let me know and I'll upload to a new hardware folder of your choosing. Edit: updated display pins to correct GPIOs and changed button resistor to pull-up. |
|
FYI, reading the info of the ESP32 and backup of the flash works well (you need to have Arduino or PlatformIO installed with the ESP32 package added). COM port info can be taken from Windows device manager or otherwise. From Windows command line or powershell: Backup of the original flash image, so it can be put back if needed: |
You are on the right track. The hardware description is very good and with such da5ta it is 95% chance to get it working on the first try. |
|
Hey, thanks for the reply. I'll try some basic code first to see if I can get some text on the displays so I know all pins etc. are working as expected. Then I'll have a look to see if adding another hardware type to the code is doable for my limited C++ experience. Might take some weeks to scramble some time after work though. Yesterday the IPSTube stopped working after I verified all the pins again. The 3V3 regulator was getting very hot, so I expect a short circuit somewhere. Need to look into this further but I expect that the when the PCB is screwed securely to the aluminum milled base there is a short between 3V3 and GND. Might be why the screws were not tightened when I got the unit new. Hardware wise it is not a bad build for the cost (45 euro), the case is aluminum and the tubes are actually made of glass. The displays are replaceable without soldering if needed, but this requires some warming up of the soldered-in support PCB of the displays. The dragons look to be copper on the support PCB. To nice these up I painted the sides black. Depending on how the Elekstube features/control can be done on this hardware, I might consider some hardware changes like adding buttons, a LED strip expansion and temperature or other sensors. Assigning unused ESP32 pins is a lot harder with the ESP chip directly on PCB. The pins are so tiny that even my sharp measuring pins moving over the ESP pins caused some minuscule shorts between some pins, even without a lot of force while identifying the PCB traces. My guess is these PCBs are not ROHS compliant, as in lead being used in the solder... |
|
Hello @Foamier! You were faster and better than me :) I was stuck for some time because I am really not good at reverse engineering a PCB and was distracted in so many ways. So your description is completely right and after your post, I finally was brave enough to upload my modified code to the last working H401 model I have (I destroyed the ESP32 on one of my boards because I measured too much). For now, a lot is already working. The RTC seems to be fine, and the RGB-LEDs on the bottom of the TFTs are working fine. Sadly, the main part is not working for me: The displays are not showing anything at the moment. Not sure why :) I uploaded my modifications to a branch in my fork of this project. Including my bad quality pictures and confusing wiring diagram as KiCAD files in the H401 folder: That is a start, IMHO, but maybe @aly-fly has more knowledge on addressing the TFT-LCDs than me. I am nearly sure these are also ST7789-based panels because the JPEGs in the original firmware are also 135x240 pixels, and it is also an 8-pin layout. The modified board description for PIO is also there. After erasing once, I was able to flash the firmware image and then the filesystem image. The annoying part is having to put the chip into bootloader mode every time. And maybe it is ROHS compliant (hazardous material and so), but they are using an "unshielded" version of the ESP32, so the EMC is not ensured, I bet. Nice for learning a lot about microcontrollers for MC-noobs like me. But there is a reason why you can buy these MCs in packages and very rarely the pure ESP32 :) They also use different versions of the ESP32. Like the pictures from the original poster here, has no I-PEX connector or external antenna (so U-version and not). I also noticed that if I reflash the original firmware, there is a "firmware error" shown because the core dump partition seems to be missing. The firmware is working for me, but I never tried the original app with it. Any ideas on this? I also have a lot of unrelated code in the fork, like setting a "hard" timezone or using an emulated ESP32 from the Wokwi stuff. Just ignore that... Bye |
|
Regarding displays. I suggest that you make a code from scratch. An example from the eTFT library. Configure the example in such way that only one display is active - only one CS line. Just ignore the others - set ESP pins to High (other displays ignore the SPI bus). When you get it working, you can easily port the required knowledge into "clock" project. |
Great effort already from your side, was just about to find out how to create a json for a the board, but you already uploaded one! Excellent. Will have to check the schematic later, only so much time in a day. My method was a bit more blunt, by doing connectivity testing between the pins of the displays and the ESP32. Then some more voltage testing after power on. |
|
Brief update on getting the displays going (or better said, not going...). Using an Adafruit graphicstest example there is no response. Adafruit_ST7789 tft = Adafruit_ST7789(20, 14, 12, 13, 15); The pinout that I use is a follows: A simpler example using the TFT_eSPI library (Walking 1 write and read pixel test) also does not show anything on the display. I wonder if I'm missing anything obvious for getting these displays to work. Does anyone have any ideas for this? Maybe the CS lines of the other displays need to be defined decently (either on or off)? The next step might be to disconnect the IPS displays and connect a LED on each of the GPIO connection and use a simple blink program to make sure all connections are the ones I think they are. Btw, did not try yet to put back the backup of the original H401 v1.2 firmware. I'm not too interested in signing up to a cloud service just to be able to add clock faces or pictures to the IPSTube clock. We want more of course ;-) |
|
Hello @Foamier, my bad, I guess! I used the PIN numbers and not the GPIO numbers :( This is beeter: The above is giving at least a responds from the LCD driver. The 1 pixel write and read example from the TFT_eSPI repo has a strange behavior then. Output from serial is: I have no clue, why... I will do a more basic example with the pure adafruit library for the ST7789 now... Bye |
|
I tried the Adafruit libary and now I know for sure, which pin is which CS line ;) I created a small example Tried different SPI modes and frequencies. There is something missing here...More power from the transistor? But I am gone for the weekend, so some else must go on from here for now. Bye |
|
Hi @Martinius79 , Code for filling all screens with changing colors: //Color cycle IPSTube displays
// Used libraries:
// TFT_eSPI at version 2.5.43
// SPI at version 2.0.0 in esp32\2.0.16
// FS at version 2.0.0 in esp32\2.0.16
// SPIFFS at version 2.0.0 in esp32\2.0.16
//
// Arduino 2.3.2 with ESP32 Dev Module board.
#include <TFT_eSPI.h>
#include <SPI.h>
/* ---------------------------------------------------
IPSTube settings for ST7789 FP-114H03A in Libraries\TFT_eSPI\User_Setup.h
#define ST7789_DRIVER // Full configuration option, define additional parameters below for this display
#define TFT_SDA_READ // This option is for ESP32 ONLY, tested with ST7789 and GC9A01 display only
#define TFT_WIDTH 135
#define TFT_HEIGHT 240
#define SPI_FREQUENCY 55000000 // fastest tested to be working
#define TFT_MISO -1
#define TFT_MOSI 32 //SDA
#define TFT_SCLK 33 //SCL
#define TFT_CS 13 //CS
#define TFT_DC 25 //RS
#define TFT_RST 26
#define TOUCH_CS -1
--------------------------------------------------- */
TFT_eSPI tft = TFT_eSPI();
#define TFT_CS_1 13 //(GPIO13)
#define TFT_CS_2 12 //(GPIO12)
#define TFT_CS_3 14 //(GPIO14)
#define TFT_CS_4 27 //(GPIO27)
#define TFT_CS_5 2 //(GPIO2)
#define TFT_CS_6 15 //(GPIO15)
int cspins[] = {TFT_CS_1,TFT_CS_2,TFT_CS_3,TFT_CS_4,TFT_CS_5,TFT_CS_6};
#define BLACK 0x0000
#define BLUE 0x001F
#define RED 0xF800
#define GREEN 0x07E0
#define CYAN 0x07FF
#define MAGENTA 0xF81F
#define YELLOW 0xFFE0
#define WHITE 0xFFFF
int c=0;
void setup() {
Serial.begin(115200);
for(int i=0; i<6; i++) {pinMode(cspins[i],OUTPUT);}
Serial.println("Initialising all displays.");
//Actiavte and init all dispays
for(int i=0; i<6; i++) {digitalWrite(cspins[i], 0);}
tft.init();
Serial.println("Initialised all displays.");
}
void loop() {
tft.fillScreen(RED); delay(50);
tft.fillScreen(BLUE); delay(50);
tft.fillScreen(GREEN); delay(50);
tft.fillScreen(CYAN); delay(50);
tft.fillScreen(YELLOW); delay(50);
tft.fillScreen(MAGENTA); delay(50);
}I noticed that you need to wait at least like 5 seconds after removing power to upload to the IPSTube device with the button pressed, otherwise it will not reboot correctly. The display are actually quite fast. SPI_FREQUENCY up to 55000000 is working fine. I did notice that the program crashes after a few minutes. not sure why. The same happens around the same time at the lower SPI frequencies. |
|
does wifi work as expected? |
His test code does only use the LCDs. We are far away from complete CFW. |
You may want to decode the dump with Arduino ESP8266/ESP32 Exception Stack Trace Decoder or ESPressif's Execption Decoder. |
|
Hi all, //Test test IPSTube displays
// Used libraries:
// TFT_eSPI at version 2.5.43
// SPI at version 2.0.0 in esp32\2.0.16
// FS at version 2.0.0 in esp32\2.0.16
// SPIFFS at version 2.0.0 in esp32\2.0.16
//
// Arduino 2.3.2 with ESP32 Dev Module board.
#include <TFT_eSPI.h>
#include <SPI.h>
/* ---------------------------------------------------
IPSTube settings for ST7789 FP-114H03A in Libraries\TFT_eSPI\User_Setup.h
#define ST7789_DRIVER // Full configuration option, define additional parameters below for this display
#define TFT_SDA_READ // This option is for ESP32 ONLY, tested with ST7789 and GC9A01 display only
#define TFT_WIDTH 135
#define TFT_HEIGHT 240
#define SPI_FREQUENCY 55000000 // fastest tested to be working
#define TFT_MISO -1
#define TFT_MOSI 32 //SDA
#define TFT_SCLK 33 //SCL
#define TFT_CS -1 //CS: Don;t define a GPIO pin here
#define TFT_DC 25 //RS
#define TFT_RST 26
#define TOUCH_CS -1
--------------------------------------------------- */
TFT_eSPI tft = TFT_eSPI();
#define TFT_CS_1 13 //(GPIO13)
#define TFT_CS_2 12 //(GPIO12)
#define TFT_CS_3 14 //(GPIO14)
#define TFT_CS_4 27 //(GPIO27)
#define TFT_CS_5 2 //(GPIO2)
#define TFT_CS_6 15 //(GPIO15)
int cspins[] = {TFT_CS_1,TFT_CS_2,TFT_CS_3,TFT_CS_4,TFT_CS_5,TFT_CS_6};
#define BLACK 0x0000
#define BLUE 0x001F
#define RED 0xF800
#define GREEN 0x07E0
#define CYAN 0x07FF
#define MAGENTA 0xF81F
#define YELLOW 0xFFE0
#define WHITE 0xFFFF
void setup() {
Serial.begin(115200);
for(int i=0; i<6; i++) {pinMode(cspins[i],OUTPUT);}
Serial.println("Initialising all displays.");
//Activate and init all dispays
for(int i=0; i<6; i++) {digitalWrite(cspins[i], LOW);}
tft.init();
tft.setRotation(0);
//Deactivate CS for all dispays
for(int i=0; i<6; i++) {digitalWrite(cspins[i], HIGH);}
delay(500);
Serial.println("Initialised all displays.");
}
void loop() {
for (int i=0; i<6; i++) {
Serial.print("Display# is :");
Serial.print(i);
Serial.print(" Pin is: ");
Serial.println(cspins[i]);
digitalWrite(cspins[i], LOW);
delay(100);
tft.fillScreen(BLACK);
tft.setTextColor(WHITE,BLACK);
tft.setCursor (0, 128);
tft.print("Text test on display ");
tft.print(i);
// deselect display i
digitalWrite(cspins[i], HIGH);
delay(500);
}
}Analyzing the voltage on the pin shows it is going up and down with every display update, not just the update intended for the specific display. This kind of rules out a physical aspect I suppose (PCB short to GND or similar). EDIT: Problem was solved by defining the CS ping in the User_Setup.h with the value -1. This means the TFT_eSPI library will not control the CS pin of the display and leave this control to the programmer. FYI, this the above sketch only works with ESP32 boards of version 2.017 and below. From version 3.0.0 there are issues with GPIO pin definifitions and the TFT_eSPI library, resulting in compilation errors like : "'gpio_set_direction' was not declared in this scope" |
yes, WiFi should work as well like any other ESP32, once we get to it... |
|
Glad to see that you are making progress. |
In the mean time I've tested the WiFi with a basic ESP32 WiFi manager sketch and it seems to be working fine. The RSSI is not great, but I guess that's to be expected with the PCB printed antenna in an almost closed aluminum case. I expect it will work fine in normal environments. |
|
Hello again, I finally found the time, to implement the support for the IPSTUBE H401 clock. With my version of the clock, everthing works stable. Best way to control it in the moment is, to use MQTT messages, because usage of the menu with one button only is limited. I only have clocks without "real" buttons, so please can someone check, if the real button clocks are still working as expected? Looking forward for any comments on this. Bye |
|
I "reduced" the amount of changes to support just the IPSTUBE hardware and closed the PR mentioned above and created a new one: |
|
@Martinius79 I see a way to add more buttons. |
@Martinius79 This is a huge change list to digest and merge. In the mean time also the Main had a few updates. Should we just try and merge and debug after merging? The # 77 shows only 2 minor conflicts at the moment. If I understand correctly, you are creating a new branch on your fork with streamlined changes, so that it will be merged more easily? Will you include also #80 with it? |
|
I would suggest that we incorporate the changes into the main as soon as the new PR is set, and then address problems in subsequent issues. |
|
Actually, this PR is closed since a while ;) I worked on another and even this will be closed soon :) |
|
I created a new pull request, with the actual main merged |
@MacGyver4B: And if I flash back the original firmware to the H401, I receive an error, but the clock still works for me. I have never tried the original software/app, so I have no idea if it will be unhappy or will work... I’ll have to try it out. Bye, |
|
I flashed back my self created backup of the original FW of the H402 model. No errors was shown. I also tried to flash one of my H401 clocks with a backup of another H401. Sadly (and like expected) the FW is bound to the MAC address, so the firmware starts up with the usual "E (8879) phy_init: load_cal_data_from_nvs_handle: calibration data MAC check failed: expected e4:65:b8:cd:1f:XX, found e4:65:b8:cd:0a:XX" followed by a "Firmware error" in the serial output. So you NEED your own backup of the FW :). Bye, |
|
@Martinius79 |
Hi, and thanks for sharing your work !
I was gifted a Chinese copy of the EleksTube, and decided to see if I could reverse-engineer it. Doing some light USB probing (
lsusb+ see below) reveals that it is very probably using some kind of ESP chip behind a CH340 USB-to-serial converter. Further disassembly shows what I believe to be an ESP32 chip (circled in red), wired to a USB port and a button (circled in green).All this has me thinking that your firmware might be applicable, unfortunately I lack knowledge about the programming flow of such IOT devices. In particular, I have looked up documentation about and succesfully setup ESP-IDF and ESPtool on my linux machine, but I can't get these programs to communicate with the clock over USB (despite getting some data as shown below)
Output of
/dev/ttyUSB0when resetting the clock via button long press:Is there anyone interested in extending support to this new device and can point me in the right direction ? Thanks in advance
The text was updated successfully, but these errors were encountered: