New cases for the 9.7″ parallel displays and proposal for CLB Club

This might be a continuation from the Cinwrite DEXA epaper controller that we designed just after partnering with Freddie from
The idea is to prepare an open source Firmware that is ready to be used with different examples and two target controllers:

1 – DEXA-C097 from Good-Display needs additionally my Cinwrite ESP32-S3 SPI controller
Optionally any ESP32 board with an RTC connected via I2C

2 – EPDiy V5 codenamed “Inkster” that you can find in Tindie

Option 1: Fast update and proprietary Waveform

With this option we designed already some panels for stores but also a very fancy ebook reader with an extra SPI SD card from Adafruit.

We also sent proposals to make a Temperature / Humidity / CO2 level weather panel to Macba, CLB fight club Barcelona and others.
Sadly we hit the generic info email in Macba so no-one will reply to that when the proposal falls in the wrong hands.

Customizing of this Panels can be done with various sensors:

  • Environamental like SCD40 / 41 Temperature, humidity
  • Dust sensors
  • Many others you can find in Sensirion catalog

Basically anything that can be plugged per I2C or SPI can be read. And the data results retrieved and converted in a format you like, using the fonts you desire, and any PNG icons or images of your choice. The possibilities are endless!

For the CLB club we are using RTC at it’s best. The fight club has an schedule that we converted to Vectors using C++. Then having the great possibility to be aware of time with our on board RTC we can just display the current activity as you can see in the photos.
So it’s not only a weather panel. It’s also showing what class is being instructed in the Gym.

Challenges: You need 2 boards the Cinread board and our own Cinwrite SPI master controller. They can be used together as a HAT (No cables around) But if you need a flat design like the ePub reader you need to wire 4 SPI cables together plus VCC and GND.
Contraindications: VCOM is slow to regulate to your desired voltage. Probably some mistake by that is the factory for this controllers that are resold by GoodDisplay.

Our Cinwrite ESP32S3 PCB generates 5 Volts from the battery power (3.7 to 4.2 Volts when fully charged) so you have this issue already resolved if you use our controller and you also have RTC.

Option 2: EPDiy

EPDiy is our one board controller of choice since we discovered it 2 years ago. We collaborated in the repository adding “software Rotation” that is what Lilygo lacks in their own EPD47 repository since they are lazy enough not to use latest version of EPDiy.

We understand that because hardware sellers focus primarily in Harware but not specially in bringing dedicated Software support or answering every Issue in their repositories. But we are still very thankful that they got parallel communication working in ESP32S3 and that opens the path to EPDiy V7 with 16 data lines for more modern epaper displays.

We made already nice panels using EPDiy V5 called Inkster. Martin is a very cool maker from Czechia and he is also a very cool and handsome man ;)

Contraindications: The VCOM in this controllers needs to be regulated by hand using a Multimeter until you match the epaper Vcom voltage (If it’s somewhere on the display usually there is a small adhesive). This controller uses ESP32 and an open source Waveform and does not update as fast as Option 1.
Challenges: There are not more than 4 GPIOs available. You can’t just connect another SPI device if you use 1 for a button. You can connect an RTC killing 2 buttons and using them as I2C lines.

Grab the STL and Blender file to print this 1200*825 epaper case

Dust sensor data representation

The idea of using a HM3301 Laser dust sensor was to make a data representation that instead of boring numbers show a more visual appealing image representing particles and their size.
For that we though about making a read each 2 minutes and use a bi-stable display with 4 grays.
Components used:

The build work!
First you should measure the ESP32 board that you are going to use. Same we did with the HM3301 sensor 3D Model and we also uploaded it to Thingiverse.

That way it’s easier to place in the 3D design and move the small holders with 2mm holes (for the screws) to secure your board. You know, when you start using hot glue everywhere, is when it starts lookin’ bad :)
For that reason we provided the Blender file so you can use a free 3D modeling program to move things around as you like. Then you can simply switch to Wireframe view with key Z select with B (Bounding box) all what you want to export and export to STL.

This small article is focused on the build and Blender itself is a tool that is not for the faint of the heart, but is a nice and powerful 3D program, that in my case made sense to spend days learning how to tinker with it.

After 3D printing the bottom case you can start placing the parts. But it makes a lot of sense to test all this outside the box first, so first we need to connect the sensor that is easy since it’s 2 wire I2C (Plus power and SET pin, that on low makes the sensor sleep)

# Default I2C (No need for pull-ups are already in the sensor)
# Note we use 14 but could be any output PIN

With those in place we should be able to already flash a program and check the measurements. Please note that SET pin should be on HIGH in order for the sensor to be powered on (Bring the small fan close to your ear, you should hear it!)
For that we created our HM3301 component since there was no ESP32 IDF component, you can find it here:

You can already link this as a submodule in the components folder or for an easier test, just download our epaper-weather-station project and their linked components using the develop branch:

git clone –branch develop –recursive

–recursive will also pull linked submodules making it really easy to have everything available at once.
Updating the main/CMakeLists.txt you can point the build process to the file you want to build as your main entry point. And in the main/tests directory we left an hm3301 test program.

If that goes as expected then doing a: flash monitor
You should see sensor readings in the Serial output.
Congratulations, your Dust sensor seems to be measuring particles.

Now let’s go ahead and connect the epaper display!
Make sure that you connect the SPI adapter DESPI-CO3 and secure it to the epaper with some nice tape. I’ve used also here 2 small spots of hot glue but is not recommended, you might damage that nice display (Although I didn’t since I wait some seconds until is not super hot and I apply 2 small spots)
The idea is just to avoid making force over the sensible FPC flexible cable.
Once that is done you can start the SPI + power wiring to the ESP32 board:


That are IOs we used. For MOSI and CLOCK we usually use the ESP32 defaults. But you could of course use the GPIO matrix to route this signals to any output pins.
If all that is good connected and also the 3.3V and GND pins are perfectly connected, and tested with the multimeter that in fact are powering the epaper…then this should display something!
Just try our next example program:

With particle-draw.cpp you can test a program that reads from HM3301 and displays some random circles showing how many PM1, PM2.5 and PM10 particles are there.

Compiling an ARM Linux kernel with EBC eink interface

First of all the essentials which are clearly explained here:

Build your first Linux kernel and make sure you have at least 8 GB free disk space .
Please be aware that building your own Linux kernel needs to be done with care and it’s a risky operation where you might need to wipe everything if done incorrectly. This was done on a fresh installation of Manjaro in my PINE64 Model A board.
Since writing for the web they say you need to start with the solution, after building my kernel in the board, I forked Smaeul and updated my changes:

Branch: rk356x-ebc-compiled
Don’t use that yet: I took the wrong branch when doing this and used master. The right one is: rk356x-ebc-dev

Regulator kernel module needed for the high voltages
EBC module made by Samuel Holland

This is already compiled now and I’m currently checking that it works before pushing it again to the repository

If you choose to use this you can go directly to Step 2 since the make is already done.

Step1. Download the kernel and build it

I’ve used the link to the Linux kernel from Smaeul fork that is linked on the Pinebook Wiki page. Please note that our target PC is a Quartz model A board from Pine64

ZIP or compressed is highly recommended because it’s almost 4 GB

Build it using:

make -j$(nproc)

That will take a long while specially if your PC is slow

2. Backup and install the new kernel

sudo make modules_install
sudo make install

That will actually install the compiled modules in your /lib/modules directory and the kernel file and the

INSTALL /lib/modules/5.19.0-MANJARO-ARM-RC+

The make install will build a vmlinux file that is your new kernel. In my case it is 30 MB.

Now this is an important step:
Before installing our new kernel, let’s backup the /boot directory, just in case everything stops working, and you want to come back to the old stable kernel.

cp -r /boot/* /run/media/user/your_USB_SSD_name/old_boot/

3. Generate the intra RAM filesystem

Now we will need to generate initramfs

initramfs is a root filesystem that is embedded into the kernel and loaded at an early stage of the boot process. It is the successor of initrd. It provides early userspace which can do things the kernel can’t easily do by itself during the boot process. Using initramfs is optional.

So that is an essential part (I think) since Arch based distros use mkinitcpio which is a bash script to automate the generation of the initramfs.

Running: sudo mkinitcpio -p linux-rc

Now if you execute a: uname -a

And it returns the date where you compiled the kernel then congrats! You just build your own Linux kernel. What a monumenal work, all coded in beautiful .c, with Linus Torvalds and his long wipe correcting development mistakes and merging. You just made it.

fasani-pc 6.1.0-rc1-2-MANJARO-ARM-RC #1 SMP PREEMPT Mon Oct 17 16:43:21 UTC 2022 aarch64 GNU/Linux

4. Cross your fingers and reboot your PC

If nothing happens, you’ve been warned at the beginning, not my fault!

Now if you do a: modprobe -c | less
To display the comprehensive configuration of all the modules and you find something like:

alias of:N*T*Crockchip,rk3566_vop rockchipdrm probably we are fine. I’m really not sure of this point, of course the real test is to send a frame to the EBC, check if the high voltages are there and see the epaper refresh.
Mind that you have to also explore a second repository of Samuel: who did the reverse engineering of the EBC part since the original one came with the Eink drivers compiled (Thanks Eink .com to make our lives easier)

RK3566_Module from the Quartz A Schematics showing the DRM to the 16 data plus control lines for the epaper and PMIC

Making our own ESP32S3 BLE receive JPEG image Firmware

Since long I’ve been interested in using another means to receive binary data that are more low-consumption oriented than WiFi.
And there is a protocol for that, which should be the standard, when sending and receiving BLE files. It’s called L2CAP: Logical Link Control and Adaptation Protocol:

L2CAP permits higher-level protocols (such as GATT and SM) and applications to transmit and receive upper layer data packets

Texas Instruments BLE stack

What is the L2CAP status in ESP32 framework?
There is code and documentation to implement L2CAP in Classic Bluetooth:
This examples, Server and Client, can be built and flashed in ESP32. It allows to send and receive data using L2CAP. But you cannot just connect to the ESP32 and send a file.
Need to research more, but it seems something more needs to be implemented to act as a “Receive file” BT- server.
Note that this examples are not buildable in ESP32S3. Newer models of ESP32 like S3 have BLE on board, but not Bluetooth-classic.
I asked Espressif both per Twitter and also per email to see if there is any timeline to add L2CAP support in BLE. To the date of writing this line I still didn’t got any reply.

Will L2CAP be supported also in BLE, an hence, in newer MCU’s like ESP32S3 ?

UPDATE: When I wrote this article I was being focused in only one of the BLE stack: Bluedroid. But I researched more and discovered there is also NimBLE which has an existing L2CAP example that I still didn’t tried. Maybe is worth some tests and also NimBLE seems to be the recommended way if you just need BLE (Less code, less RAM usage)

So how do developers send data or images using BLE using Espressif MCU’s ?

Basically everyone implements their own protocol and App to send their data.
Since I didn’t want to be less of a fool than the others, I decided to implement my own example, that I will detail here below. If there is any interest, then I will add it some repository, so someone can benefit from it.
My example grown based on the GATT server. So it’s important to read and understand correctly the GATT server walk-through.

To start with first we kickstart a BLE service_id and publish it’s characteristics. The char_id’s are the “abilities” this services is offering. Like for example Receive file, Notifications etc.
So we start by publishing a service and one characteristic on our ESP32BLE Server instance.
In the Client side, using mainly Javascript and Chrome, we will connect to this BLE Service and grab it’s charasteristic, to be able to WRITE to it.
Note that both parts of this project are fully open-source

And then we need to add some additional hooks, since in my case I would like to know how long is the file we are going to receive (The old know content-length HTTP header, that we don’t have in BLE, so we will invent it)
And I also would like to receive an “end of file” signal or EOF, that will come after the byte-stream ends, and will be also the Firmware signal to say: Hey the JPG just finished to arrive, just decompress the receive buffer, and send it to the display.

This is what I though to be appropriate to implement those

  • 0x01 -> uint32 content length so the server will receive a 5 bytes message
    0x01 byte1 byte2 byte3 byte4 (MSB on the left) which can be decoded in the Firmware like: uint32_t received_length = param->write.value[1] + (param->write.value[2] << 8) +(param->write.value[3] << 16) + (param->write.value[4] << 24);
  • Byte stream. This is not prepended by any special command. Is just a continuous byte streams in chunks of about 448 bytes from the beginning till the end of our file
  • 0x09 end of file signal. Only 1 byte. Just decompress the JPEG using JPEGDEC from Larry bank, at the same time this will be our validation that it’s a valid JPEG.
    Render it to the epaper display.
First idea on how to implement this
BLE receive at work

As a resume this is doable. Is not a perfect way to receive a binary. It’s just not great to use Chrome since you force your users to use this browser which also needs a special “Bluetooth permission”. Probably would be better suited to make an Android app that is far away from the scope of this experiment.
And it’s just a very RAW sending that does not implement any way to recover lost packages. Walk away with your receiving client and your JPEG will never arrive in one piece.

Sending this using Chrome browser

The way we are currently sending this, is to open and read the JPG with any server backend language, we use PHP in

$jpg = file_get_contents($jpgUrl);

// Convert that bytes to HEXA
$hexStr = bin2hex($jpg);
// str_split — Convert a string to an array
foreach (str_split($hexStr,2) as $byte) {
            if ($count%16 === 0) {
          // Add newline every 16 bytes so is easy to compare
                $image_array[] = $byte."\n";
            } else {
                $image_array[] = $byte;
// Output image_array in your textarea

// Like this JS reads and converts to byte again
// A bit awkward but is easy to compare if the same bytes arrive
// to the ESP32 end. One wrong byte and JPG won't decompress

Probably there is an easier and cleaner way to do it. My way to show this is just a developer proof-of-concept example, but of course you could do it nicer. Or just pack all this in an Android App, which will be much more friendlier to use, just needs to open an image from your phone and resize it to your display width / height so you avoid sending a huge JPEG.
Other than this notes and some failed sendings, since Chrome BLE is also not enabled by default and considered to be experimental beta, this is a valid example and it’s working 99% of the time to receive images. In my Linux I often had to restart bluetooth since I’m getting some GATT is busy error messages in Chrome, that I don’t know where they come from and how to get rid of them.

If you feel that this can be helpful for you in an independent repository just let me know and I will tidy it up a bit.

Testing Pine64 Quartz model A board

The Quartz64 Model A is powered by a Rockchip RK3566 quad-core ARM Cortex A55 64-Bit Processor with a Mali G-52 GPU. It comes equipped with 2GB, 4GB or 8GB LPDDR4 system memory, and a 128Mb SPI boot flash. There is also an optional eMMC module (up to 128GB) and a microSD slot for booting.

Top side of the Quartz model A board. The SD card holder, that I broke accidentally, is on the bottom side of the PCB

So far I tried the following and worked out without issues:
– Installed Balena etcher in Ubuntu, a nice software to make bootable SD’s or eMMC
Downloaded last version of Manjaro-arm for this board (at this moment: 0220606 release)
– Connected an external monitor using HDMI, an external wireless logitech Keyboard/Mouse, all recognized automatically by Manjaro

Additionally I wrote a post in Pine64 forum, since I want to know how to go further and test the Eink interface.

This is the result:

Curious to connect a LAN cable afterwards since this does not have WiFi and also trying out a WLAN USB to see if I can also use external WiFi.

Moved to Barcelona

Well it was hard, frustrating and a very tiring experience to say the least. But after finally signing a one year Contract for the apartment, and many “Nos” for other’s we’d liked, but we didn’t qualify since we do not have any spanish work…we are settling down nicely and already got high speed internet installed.
Now is time to keep on developing working for future electronic projects and contributing to the open source community.

EPDiy developer updates is being posted regularly on my twitter timeline

EPDiy S2 PCB is still on development

High voltages are running already but there are still some minimal updates that are waiting for my interaction.

Goodisplay Tinypico ESP32 HAT

Is ready to be tested and results will be posted here soon.

Please follow @martinfasani to stay in touch.

LVGL to design UX interfaces on epaper

lv_port_esp32-epaper is the latest successful attempt to design UX in C using Espressif ESP32.
If you like the idea please hit the ★ in my repository fork.
What is LVGL?

LVGL stands for “Light and Versatile Graphics Library” and allows you to design an object oriented user interface in supported devices. So far it supports mostly TFT screens and only some slow SPI epapers where supported. My idea is to add driver support so it works also in fast parallel epapers.

That is Lilygo EPD47. Parallel epaper with ESP32 WROVER and I2C touch interface that can be found in Aliexpress

The main idea is to use a bridge driver that pushes the pixels to EPDiy component using the set_px_cb and the flush callbacks in order to render the layouts on the supported epapers. This will have a performance hit but it will also allow us to draw UX interfaces in parallel epapers that are quite fast flushing partial refresh.
The development took about one month of research and many iterations until it became usable. I started with an easy choice since Lilygo sent me an parallel epaper as a gift once and I bough the rest in their official store. The idea is that this acts as proof-of-concept to demostrate that is possible and that it’s working as expected. It’s possible to design an UX directly in C and then using a controller like ESP32 you can directly interact with Home appliances such as lights or other devices, to control them or to read information such as sensors that can respond with short JSON messages to inform your epaper control board about temperature or other matters that you choose.

LILYGO EPD47 T5-4.7 inch E-Paper (Link goes to Lilygo official store)
LILYGO T5-4.7 inch E-paper ESP32 V3 version Capacitive touch (IC driver is called L58)

More demos and videos

Recommended reads hits first 100 users

After almost one year on the run, my service to deliver images for epapers and TFT displays finally is starting to get some adoption. The idea was starting at the beginning of 2020 when the epapers and many great projects like EPDiy in hackaday started to be early adopted.

Our ESP32 Firmware does 3 things at the moment and is very easy to set up:

  1. It connects to and downloads a Screen bitmap.
  2. In “Streaming mode” it pushes the pixels to Adafruit GFX buffer and at the end renders it in your Epaper.
  3. It goes to sleep the amount of minutes you define

But then I needed to research more and a bigger idea was triggered: It was not enough to make an Arduino-esp32 firmware using GxEPD as a library. I wanted to learn more how epapers work and also to get out of Arduino-esp32 and get more into Espressif IDF framework. It was hard, I had some weeks where I achieved nothing, but after about one entire month of coding I finally saw the first small epaper refresh.
Soon there where 5 models more.

Today they are at least 20 models, including color ones, and getting back to EPDiy I added also support for parallel epapers being the new LILYGO T5S 960*540 the first fast paralell eink supported. And then come the touch part. First with Goodisplay FocalTech controller and last week with Chinese L58 controller for this new parallel epaper.

It was a long journey and time taking. But I think it was worth it and I see that at least 20% of the users are having their screens connected and enjoying a very low consumption calendars and photo-frames at home.
Very happy to make this possible and to bring something alternative to the usual arduino-esp32 Firmware. Something that you can hack, that is more understandable, and uses Espressif’s own framework. It might be not very well known for makers but is undoubtedly used in professional industry and it’s a very good alternative, with lots of examples and very well documented.

Next missions are to start making developer tools and examples to introduce uGFX interface design into ESP32 using epapers. There is a long journey ahead and we are very thankful for all the good feedback received so far.

Analysis of the YouHodler user interface and their default risk assessment

Since about 4 months I’ve been using this site to keep my Crypto assets and I really like the User experience (UX) and also the design, both of the website and their Android / Iphone application. YouHodler is a DeFi platform where you can store your Crypto assets and get a yearly percentage interest, just as other known websites BlockFi and Nexus. With the particularity, that YouHodler let’s you bet on UP / Down price changes and increase your assets (To be clear: That if your technical analysis is good and it goes in the direction you estimate)
It flows, uses very modern web techniques, that are not perfect since many times you need to refresh the whole thing until it works but it’s visually appealing and also simple to use. But there is something that called my attention and I wanted to write about it here, with some thoughts, because I’m sure that I’m not the only one that detected this.
This is not a critic to the site, but more my personal view, about how the UX and interaction design can influence risk and sometimes put the user in an undesired position just because he wanted to take a fast action to increase his assets.

Here is an enumeration of the defaults I’m talking about:

1. MultiHodl price bets take always your full amount of the Crypto choosed

Let’s say I have 48.5 UNI and I choose to make an UP bet this is what happens as default

MultiHodl UP bet as default full amount of the coin you choose, and a 11X risk (Price Down level 7%)

Only on Ipad / Iphone when you click over the amount to bet it offers a quick 20% or 50% selection.
That’s fine and much better than Android or the Web version that come with the full amount and you have to update it by hand. Are you in a rush since you loose momentum and click fast, well it’s your risk, you ‘ve just put all your Crypto at stake:

Now what happens if the default Price Down Limit (PDL) is hit?
As default is 11x or 13x that gives you about 7 or 8% PDL: If it suddenly goes down that amount you have 0 left. Is all gone. That’s what is a margin call about. When the down margin call is hit, in case of an UP bet, the amount you use as collateral is used to repay the Loan.

This is a real operation happening, and YouHodler is buying or selling assets, in a chain of loans so this is what is all about.

2. Longer term loans called Turbocharged

With another option called Turbocharged loans happens something similar, let’s say I choose to Turbocharge my 0.010045 Bitcoin:

Very similar situation. As default full amount is selected. As default the highest risk level is selected.
A -5% price down limit can “maybe” work after a very low moment, like in March 2020, or even in whole period till November 2020 since it was mostly in a bullish scheme going up all the time. But it’s not the normal situation, and everything that growths has pullbacks. This pullbacks are usually much higher than 5% and it maybe go 15 or even 20% down in a single day. That happens with everything if you see the stock marketing, but specially with Crypto. Now let’s check what happened in Black Friday as a first example:

Black Friday has seen some years a pullback for Cryptocurrency, no idea why. That is a 12 % pullback in 24 hrs.

Now that is a 12% pullback in less than 24 hrs. So imagine that even if we start a Turbocharged loan on the green arrow, we will be very happy since it goes up in the next hours, only to wake up the next day with the Price Down Limit call (PDL).
And what happens with a Turbocharged loan when the PDL is hit?
Basically you get part of the money back in EUR (If you choose EUR as borrowed ticker) but the rest of your crypto is gone forever. So be aware that when choosing a -5% PDL you are taking an unusually high risk that can backfire in any moment, even if at the beginning is going up. To make a more visual example with my own bad technical analysis and failure, this was done with 2.5 ETH in January 22 aprox. in a moment where all Crypto was going down at least 10%:

5% PDL was hit, got back 956 EUR, and my 2.5 ETH is gone. So I loosed aprox. 1.5 ETH

Please notice that this is my fault since I forgot to change the plan to a 2 Month -25% PDL. But is also partly the unusual YouHodler settings, that take the full amounts and the more risky options as their default choice.
Now the question is: Is this deliberately made? Or is just because the UX was designed like this?

Ultimately it is the user choice to select how much risk he is going to take. That is clear and I’m not complaining about it. In many cases I won, other I loosed, is all risk investment money that I can afford to loose and I won’t cry about it, not even a minute. But in this case, I think having such a great UX designer on board they could have done much better.
If you are DeFi company that is willing to make your users HODL their assets, then you don’t select the full amounts with the higher risiko as default. At least make this an user choice (More on that later)

3. Not transparent reporting options for MultiHodl bets

If you use MultiHODL for doing bets regularly, there is not any option to download a full report of your wins/looses. You have to make it yourself, this is for example my own online Excel for this:

214 € won on January alone.

As you can see, if you do a good technical analysis, and you are strong enough to hold and get out only in a win position there is some money to be made. And I could recover my 1.5 ETH in 2 months if I wanted to.
But that’s not the point. My idea to make this platform better is to add in the settings a Risk profile option:

◎ High risk, as default -5% PDL, x11 MultiHodl risk. Full crypto amount
◎ Low risk profile, as default -25% PDL, x6 MultiHodl risk. Uses 20% of your selected crypto

But as you see is not preselected the High risk option how YouHodler is doing it now is like this:

🔘 High risk
◎ Low risk

What I really expect as a user is that there is a setting or similar to select the default risk I’m going to take. Maybe not preselected, just let the user decide.
There is a reason there are laws in place at least in the EU, so you cannot preselect the join newsletter when a user registers:

☑ Join our newsletter

You won’t see something alike in a website. At least not in an European website since the protection laws clearly forbid this and there is high fine to pay if you do it.
I know that the decentralized finance is a different situation and I’m not saying that what YouHodler is doing is inherently bad or wrong. It’s just my opinion that it should be a better option to do it.
Or at least like I mentioned before, to let the user select his risk profile in settings so the defaults are treated differently for each personal setting.

This will be a very smart choice to make the users more secure about using the platform and also a way to make the YouHodlr users hold more assets instead of loosing them in wild rides with the highest risk in a volatile market where you should be better a good technical analyst instead of a wild cowboy.
I hold only a part of my assets in YouHodler and others are in my private wallet. Part of them are also in my girlfriend BlockFi account, I think is a good idea, not to put all eggs in one basket since in this game is all about risk.

That said I’m fond of using YouHodler even with the issues I mentioned. I think it has a lot of potential and is very well designed in many aspects, their UI is consistent and the user experience well designed, something that being a backend website developer I can confirm.
Any reaction or explanation for my claims here will be also published, and of course ideas or comments, are always welcome.

MultiHodl bets and the psychology of risk in crypto

I wanted to start writing a post about how to get out of bad bets. But instead I read some articles about risk psychology and I think that’s the best way to explain why we end up loosing many not only on betting, but in investing on general.
The best advice I can give on YouHodler Multi HODL up bets on crypto like Bitcoin or Ethereum is that you need to be patient. And unless you made a very bad choice, like at the top before there is price correction, you should always wait and get out in the winning side. Now if you are not patient enough is better you don’t use Multi HODL because you can loose a lot of money with fear of losing or FOMO bets (Fear of missing out)
Make a technical analysis and a plan. Stick to it and be patient.
Crypto mostly goes up except on special days where it can have big correction

In my personal opinion what plays mostly against a good bet or investment is impatience, fear to loose, and being too emotional. Actually if you want to be a good player when making a bet, you need to learn to use that feelings on your side, but naturally this forces play against you. You could wait some minutes more and get out of the bet 10% higher, but you could not stand the first two red candles and got out before time, and like this multiple different variations that are in the history of my bad bets.
Risk-taking behavior refers to situations in which a decision is made whose consequences depend on the outcomes of future events. Events that we study previously and are quite sure that go in one direction. But even the most perfect analyst can make a bad guess and the top of that the prices of Cryptocurrency are influenced by so many things with many big players and institutions buying and selling millions that the most bully upwards run can end up in a scary downfall at any moment of the day. Unpredictable.
To resume it in a few words the fact is that most of the time our knowledge of probabilities is far from exact. We can study the last movement days, draw on the chart and make prediction lines, even read analysis of experts that are years studying this markets and still with all this information we can fail. Because behind the visualization of a stock price chart there is a billion dollars market, with humans taking decisions all over the world, updating that price movements. It’s not humanly possible to predict what will be the direction for the next days, not to say hours. We can estimate it, but then the prices can give us a cold bath of reality when the outcome is much different from our prediction.

The experimentalist’s view

Psychologists Kahneman and Tversky in 1979 asked subjects questions similar to this:
Which would you rather have, $3,000 for sure or an 80% chance of winning $4,000?
Most subjects prefer the $3,000 for sure even though the expected value of the gamble is higher:
0.80 x $4,000 = $3,200.

This kind of preferences are conventionally labeled “risk aversion” as are preferences favoring a 90% chance of winning $3000 over a 45% chance of winning $6000.
In my personal case I would for sure prefer the 3K since I have sometimes such a luck that I will fall in the 20% and get out with my empty hands.
There are many different theories among experimentalist’s about this. The portfolio theory is based on the premise that choices among risks reflect a compromise between maximizing expected value and achieving an individually determined ideal level of risk.
In the utility theory, subjects are assumed to “compute” something similar to an expected value, but instead of using the objective cryptocurrency amounts, they operate on subjective amounts. One that used this concept wisely was Daniel Bernoulli who said that the value of money is not absolute, but depends on how much one has already:

Any increase in wealth, no matter how insignificant, will always result in an increase in utility which is inversely proportionate to the quantity of goods already possessed

Bernoulli (1967)

An alternative explanation for risk aversion can be found in the idea that decision makers pay differential attention to the best and worst outcomes in gambles.

A Two-Factor Theory for Risky Choice
Behavior has both inner and outer sources. We are disposed by our unique constitutions and histories to behave in certain ways, and each person has an unique approach when it comes to making a bet or investment. Two-factor theory uses both a dispositional factor and a situational factor to explain risky choice. The dispositional factor describes the underlying motives that dispose people to be generally oriented to achieving security (i.e., risk averse in conventional terminology) or to exploiting potential (i.e., risk seeking in conventional terminology). These factors are sometimes in conflict and sometimes in concert, producing complex patterns of behavior in which risk averse choices and risk seeking choices exist side by side in the same individual’s behavior [Lola Popes, see references at the end of this post]

How to get the most of MultiHodl bets

I wrote already about the MultiHodl bets in my last blog post. Multi HODL is an innovative tool to bet on price changes on Crypto assets invented by
My theory is many failed bets have something in common:
That we were not patient enough to wait until is in the winning side.

You may say, yeah! Right, but I was losing 20% of my bet… Sure I completely understand that and I also losed more than 20% on my own bets for that same reason.
Talking frankly there is two ways of getting out of a bad bet. Let’s say that you analyze the past days, have the bottom and top of the mountain tracked, and you think that it effectively is going up.
So you place a 300 € bet that is going UP, risk level X8, so there is some place for failure (As more X risk level the margin call is reduced) Well it starts go in the direction you think, but after 3 minutes, it starts going down.

After studying the past this was the logical curse of the price. Slide the image below to see what happened

This is an example of a real bet. Is not a simulation. Because of the fear that the never ending going down red line for 2 hours and not getting out to cut out looses short, you end up getting out in the worst place of all!

60 € lost just because lost hope and fear that all will be lost

This fear is just not grounded! It’s just fabricated since after seeing this long red candles down after such a long time, you just loose all hope. This is not the way to do a right bet.
In case your prediction does not go as expected you have 2 options:

  1. Cut your losses short, so if the curve does not go as you expected, you cut loose at 5% max very closely to the start.
  2. Do not loose the hope, stay cold as a rock, and wait until the price goes up again and you can get out in the winning side.

But staying in the middle of this two is not a sane option and the way you can loose a lot of money.
Cut your looses short and keep your winnings at large!

To end up the story, I recovered that 60€ doing another 8 bets of about 9€ gain each. It can take many bets to recover from a very bad bet.
Another good option is to make a “seed bet” of minimum amount, like 60 €, with low risk and only after seeing your theory is like expected then you make the bigger bet. Remember that the starting point is the key for a good bet. The ideal kickoff is a MultiHodl UP bet in the base from the mountain after analyzing the past days lowest points.
But even like that things can get tricky so have an escape plan ready. If things drift from your prediction an unacceptable % you either cut your looses very short and assume the loss or you are patient and strong enough not to loose the hope and get out in the gain side. Believe me, most of the bets, could have gone right if the holding was long enough but instead I freaked out and got out in the bet in the worst moment.
But either 1 or 2 you don’t stay in the middle way. Because that’s the worst decision of all and you get out in the worst moment probably with a big loss.
Please note that this is only for the cases where you studied the margins and it’s not a crazy bet like going up at the top of the price or going down at the bottom of the mountain. This extreme cases do not count, if you do that I guess it was just a fail, and getting out as fast as you can is the rule!

Keep in mind that any money source that you use in this bets should be preferable Stablecoins and investment money that you can afford to loose!
I recommend to use Stablecoins or FIAT since loosing Crypto is always painful. The best is just use money and if you afford to win then you can buy more Crypto or just transfer it back to your local bank. Risky choices are choices that have an element of danger. They are risky and may come to a bad end in case the direction changes abruptly and you are not in control. Losses may be sustained, hopes may be shattered, or opportunities wasted. That said, keep your winnings at large, and cut your looses short!
Do not use a small screen like your mobile, half awaken, to place a bet after. Open TradingView or any similar stock market chart analyzer in a big screen and make a seasoned and thoughtful decision.

If you want to try YouHodler you can open an account here. Their app has great usability and feels secure, the withdrawals are fast, and their support answers within the hour. So far I had a very good impression of their Finance platform.
However I would never recommend to hold all your assets in one platform. We have half of our assets in YouHodler and the other half in another DeFi platform called BlockFi which also has very good recommendations.
BlockFi is launching very soon world’s first Bitcoin rewards Credit Card. This is great since enables you to use this card to get cash in any automatic terminal or also to buy things just like any other VISA card and earn 1.5% back in bitcoin on every purchase. We joined the waiting list.

The psychology of risk – Lola Popes ( PDF )
Definition of Multi HODL