Kerry Wong did a teardown of a Philips dimmable LED bulb:
One of the first things you will notice about this light bulb is that the compact construction. Most noticeably the lack of the telltale heatsink fins. As a result however, the heat dissipation capability is greatly sacrificed. During normal operation when mounted pointing downwards without any airflow obstruction, the case temperature raised to above 60°C within a few minutes. I could only imagine what the temperature would be like when the light bulb is mounted facing upwards in a semi-enclosed light fixture.
So I decided to take it apart to see the what the construction looks like inside.
This week’s Weekly Roundup is pretty special, because it’s episode number 42! It also has FPGAs, SBCs, even more FPGAs and something that goes up to 11. Kickstarter There’s not a heck of a lot happening on Kickstarter at the moment. Nixie Tube Driver but, here’s another simple Kickstarter campaign Continue reading Weekly Roundup #42 – New Maker Products→
Application notes from NIDEC COPAL Electronics Corp. about digital potentiometer’s temperature dependence. Link here (PDF)
The digital potentiometers (DP) has two temperature dependent parameters, the TC of the end-to-end resistance Rpot and the ratiometric TC. The temperature dependence of the parameters of an analog circuit using a digital potentiometers is reduced if the performance of the circuit is shifted from the TC of the end-to-end resistance of the pot to the ratiometric TC.
App note from Vishay on variable resistors primer. Link here (PDF)
A potentiometer is a mechanically actuated variable resistor with three terminals. Two of the terminals are linked to the ends of the resistive element and the third is connected to a mobile contact moving over the resistive track. The output voltage becomes a function of the position of this contact. Potentiometer is advised to be used as a voltage divider.
Ken Shirriff writes, “A die photo of a vintage 64-bit TTL RAM chip came up on Twitter recently, but the more I examined the photo the more puzzled I became. The chip didn’t look at all like a RAM chip or even a TTL chip, and in fact appeared partially analog. By studying the chip’s circuitry closely, I discovered that this RAM chip was counterfeit and had an entirely different die inside. In this article, I explain how I analyzed the die photos and figured out what it really was.”
After having published my post about how to implement a webserver on the esp32 chip, some readers correctly warned me that everyone, once connected to the wifi network, could control the relay and asked me how to limit access to the webpage.
A classic solution (that I also used in this previous tutorial) is to ask the user to enter a password. It’s very easy to implement, but has a negative aspect, that is you have to type the password everytime you need to switch the relay.
You can avoid asking the password everytime the user access the page if you implement a login page and keep the user logged in using a session cookie as I’ll explain in a future tutorial!
Today I’ll show you how to protect your website using a feature of the SSL/TLS protocol: the mutual authentication.
Everytime you connect to a website using the https protocol, the server which hosts the site sends to your browser the SSL certificate of the site. Thanks to this certificate, you can verify the identity of the server and establish a protected connection to it:
The TLS protocol also offers the possibility for the server to require a certificate from the client: this means a two-way authentication, that is server and client authenticates each other using SSL certificates:
With this authentication method, a user has only to install on his device the client certificate (and the corresponding private key) and choose which certificate to send to the server if more than one is present:
The authentication with SSL certificates is therefore based on the principle of something I own (for example, a key) and not of something I know (for example, a password).
Generally speaking, SSL certificates can be:
signed by a Certification Authority
The first ones are perfect for internal use or for testing, while the second ones, normally signed by trusted CAs, are widely used in production environments or on the Internet. Sometimes you probably received this warning message when surfing on the Internet:
that means that your browser doesn’t trust the certificate sent by the server because it’s self-signed or signed by a non trusted CA.
For this tutorial, I’m going to use OpenSSL as a certification authority to create the certificates we need. If you’re using the toolchain provided by Espressif, you don’t need to install anything else because OpenSSL is included.
First create a folder that will contains all the files required by OpenSSL to operate as a CA in your home directory:
Now move into that folder and create some empty files:
mkdir csr certs crl newcerts private
echo 1000> serial
Copy the certification authority‘sconfiguration file (openssl.cnf) from my Github repository into the myCA folder. Open the file and change the main path accordingly to your system:
Now you have to generate the private key and the certificate for the CA. Let’s start with the key (its length will be 2048bit, enough to ensure good security):
You have to enter some informations… the only mandatory is the common name which is the name of the CA, that will be included in all the certificates the CA will sign. At the end of the process you can open the file (ca.cer) and verify name and duration:
Let’s now generate the server and client certificates. The steps are the same for both:
generate a new private key – openssl genrsa
generate the CSR (Certificate Signing Request) file – openssl req
sign the CSR file with the CA to obtain the final certificate – openssl ca
The way you install the P12 file on your device depends on the specific operating system it runs: on Windows you only need to double-click the file and follow the import wizard.
The source code for the program running on the esp32 devboard is available in my Github repository.
First you have to copy in the prioject folder the certificates (CA and server ones) and the private key for the server certificate and include them – as text data – in the program (I’ve already explained how to include binary files in my previous post):
To implement the SSL protocol I’m using the mbedTLS library, included in the esp framework.
After having configured other elements of the library (the random number generator and the debug function) you can bind it to the standard TCP port for the https protocol (443) and accept new incoming connections:
After having accepted a connection, you only have to call the function:
during the handshake process the library sends to the client its own certificate and require the one from the client, verifying that this is signed by the specified CA: the mutual authentication is implemented!
After the handshake, the program is similar to the previous example, you only have to use mbedTLS specific send/receive functions (mbedtls_ssl_read e mbedtls_ssl_write).
Early in the year, one of my colleagues, Damian, showed me one of these strain-gauge solid-state joysticks that they were using as part of the undergraduate engineering curriculum.
Their goal was to teach the students how to read strain-gauges. But I immediately saw the applicability for making a no-moving-parts super-robust joystick for the MEGA65 and all other retro computer users.