App note: Infrared (IR) Spectroscopy with the SFH 473X – Background & technology

an_osram_infrared_spectroscopy_SFH473X

Infrared spectroscopy by OSRAM and their SFH 473X broadband light emitters. Link here (PDF)

Imagine you can check if the mangos on the market are sweet – without even touching them…

Imagine you can verify if your prescribed medical tablets contain the life-saving compound – or if they are counterfeits…

Imagine you can check the calories of your favorite cheese dish – before eating…

Imagine all this is possible with one fingertip on your smartphone…

The SFH 473X series is precisely designed to support this innovation. This note covers briefly the background of spectroscopy and the case for the SFH 473X series.

App note: Ambient light sensors – General application note

an_osram_ambient_light_sensors_gen

Different ambient sensors differs on their ability to sense specific wavelength and introduce different ambient levels compared to human eye, here’s a general application note from OSRAM. Link here (PDF)

This application note introduces discusses ambient light sensing. The different types of ambient light sensors are described and related to specific applications.

ESP32 (20) – Webserver

One of the most popular projects among the ones included in my tutorial about the enc28j60 chip is fore sure WebRelay. This project allows to control an output pin of Arduino using a simple web page, designed to be accessed also using your smartphone. Today I’m going to show you how to implement a similar project with the esp32 chip; it’s also the opportunity to teach how to write a TCP server, especially a web server.

Netconn API

As you know, the esp-idf framework uses the lwip library to manage network communication. This library offers different abstraction levels: the programmer can decide to work on the raw packets or to leverage pre-build components.

To develop my TCP server, I decided to use one of those pre-build components, the Netconn API.

Using Netconn API it’s very easy to implement a server and the required steps are described below:

webrelay-01

The netconn_new() method creates a new connection and returns a a pointer to struct netconn which represents the connection:

struct netconn *conn;
conn = netconn_new(NETCONN_TCP);

The parameter defines the connection type… the most common ones are NETCONN_TCP for a connection using the TCP protocol and NETCONN_UDP for a connection using the UDP protocol.

To use the connection in server mode, you have then to associate (bind) it to a specific port… for example a webserver normally listens on port 80 (443 if HTTPS):

netconn_bind(conn, NULL, 80);

The second parameter (NULL above) allows to bind the connection to a specific IP address and may be useful if the device has more than a network interface. If you pass NULL (or the equivalent IP_ADDR_ANY) you ask the library to bind the connection to any available interfaces.

Now you can start listening on that port with:

netconn_listen(conn);

Working with a client connection

With the netconn_accept() method, your program can accept a new incoming connection:

struct netconn *newconn;
netconn_accept(conn, &newconn);

The method returns a pointer to a new struct netconn that represents the connection established with the client. This method is blocking: the program is stopped until a client makes a connection request.

Once the connection is established, you can use the netconn_recv() and netconn_write() methods to receive or send data to the client:

netconn_recv(struct netconn* aNetConn, struct netbuf** aNetBuf );
netconn_write(struct netconn* aNetConn, const void* aData, size_t aSize, u8_t aApiFlags);

To optimize RAM memory usage, the netconn_recv() method handles data using an internal buffer (zero-copy mode). To access the received data you therefore have to:

  • declare a new variable as a pointer to struct netbuf
  • pass the pointer address as the second parameter of the recv method
  • use the netbuf_data() method to obtain a pointer to the data within the netbuffer structure and its length

webrelay-02

struct netbuf *inbuf;
char *buf;
u16_t buflen;
netconn_recv(conn, &inbuf);
netbuf_data(inbuf, (void**)&buf, &buflen);

Likewise, the netconn_write() method accepts, as last parameter, a flag to indicate whether or not to copy the buffer content before sending it. To save memory you can therefore, if you’re sure that the buffer won’t be modified by other theads, use NETCONN_NOCOPY as flag:

netconn_write(conn, outbuff, sizeof(outbuff), NETCONN_NOCOPY);

When the communication with the client is complete, you can close the connection and free the buffer:

netconn_close(conn);
netbuf_delete(inbuf);

HTTP server

What you learned so far can be applied to every TCP server. If you want to communicate with an Internet browser, you have to “talk” the same language, that is the HTTP protocol.

In the example program (available on Github) I implemented a very minimal version of that protocol. When you type an address in your browser (for example www.google.com), the browser connects to Google server and sends a request with the form:

GET <resource>
[...]

The request can have different fields, but the first line always contains the name of the requested resource (html page, image…). In particular if you access the homepage of the website the request will simply be GET /.

The website published by the esp32 chip to control the relay consists of only two pages:

  • off.html, displayed when the relay is off
  • on.html, displayed when the relay is on

Each page contains a label (“Relay is ON|OFF“) and an image. The image itself is a link to the other page and when you click on it, the relay status is also changed:

webrelay-03

The program identifies the resource to be sent analyzing the first line of the request with strstr():

char *first_line = strtok(buf, "\n");
if(strstr(first_line, "GET / ")) [...]
else if(strstr(first_line, "GET /on.html ")) [...]
else if(strstr(first_line, "GET /on.png ")) [...]

An HTTP server responds to the browser by first indicating the result of the request. If ok, the return code is 200:

HTTP/1.1 200 OK

then it returns the media type of the resource and finally it sends the resource file. In this example, the possible media types are:

  • text/html for HTML pages
  • image/png for images

Static content

A webserver it normally stores the resouces for the website it publishes on an external device (memory card, hard drive…). For simple projects, you may consider to include all the content inside your program.

For example in my code HTML pages and HTTP protocol messages are defined as static arrays:

const static char http_html_hdr[] = "HTTP/1.1 200 OK\nContent-type: text/html\n\n";
const static char http_png_hdr[] = "HTTP/1.1 200 OK\nContent-type: image/png\n\n";
const static char http_off_hml[] = "";

To be able to include also the images, I used a feature of the framework (embedding binary data). You can indeed specify in the component.mk file the binary resources to be included:

webrelay-04

In your program you can access the content of the embedded files using the following pointers:

extern const uint8_t on_png_start[] asm("_binary_on_png_start");
extern const uint8_t on_png_end[]   asm("_binary_on_png_end");
extern const uint8_t off_png_start[] asm("_binary_off_png_start");
extern const uint8_t off_png_end[]   asm("_binary_off_png_end");

The syntax is _binary_filename_start|end, replace “.” with “_” in the filename. Having pointers to both the start and the end of the resource content, it’s easy to send it with the netconn_write() method:

netconn_write(conn, on_png_start, on_png_end - on_png_start, NETCONN_NOCOPY);

Demo

Bitcoin mining on a vintage Xerox Alto computer

bitcoin-finished2

Ken Shirriff writes:

I’ve been restoring a Xerox Alto minicomputer from the 1970s and figured it would be interesting to see if it could mine bitcoins. I coded up the necessary hash algorithm in BCPL (the old programming language used by the Alto) and found that although the mining algorithm ran, the Alto was so slow that it would take many times the lifetime of the universe to successfully mine bitcoins.
The Alto was a revolutionary computer designed at Xerox PARC in 1973 to investigate personal computing. It introduced high-resolution bitmapped displays, the GUI, Ethernet and laser printers to the world, among other things. In the photo above, the Alto computer is in the lower cabinet. The black box is the 2.5 megabyte disk drive. The Alto’s unusual portrait display and an early optical mouse are on top.

See the full post and more details on his blog, righto.com.

MQ gas sensor correlation function against temperature and humidity

pics-mq135_sensor_opened

Davide Gironi writes:

We have taken a look at the MQ sersor in this post here.
As I said those sensor are electro-chemical. Accuracy of those sensor is not the best. Also they will react to many gases. It means that if you are trying to measure the ppm of a certain gas with this sensor, you will have false measurement values if any of the other gas that the sensor react to, changes.
Here I will “overengeneer” on this type of sensor, trying to correlate the MQ sensor readings to temperature and humidity too, even if this correlation to me is not prominent. The correlation formula I’ve found may be wrong, so let me know if there is something to fix here.

See the full post and more details on his blog, davidegironi.blogspot.com.

Building a single pixel scanner

scanner1-600

Kerry Wong published a new build:

A flat bed scanner typically uses three rows of CCD sensors (RGB) to capture images placed directly on top of the glass bed. When the CCD array scans from one end of the image to the other, the digitized color image is formed. So with a similar approach, we could use just one photosensitive device to capture the entire image one pixel at a time via raster scanning. Now that I have an HP 7044A X-Y recorder I could use it’s X/Y servo mechanism with a suitable sensor to build a single pixel scanner.
The simplest sensor would be just a photodiode or a CdS photocell. For capturing grayscale images, either of these sensors could be used. To capture color images though, we would need a sensor that is capable of discerning the RGB components of each pixel. For that I used an inexpensive TCS34725 based color sensor module.

More details at Kerry D. Wong blog.

Check out the video after the break.

UDOO-X86 Part 2: Roaring performance // Review

In Part 1 of this video I looked at the UDOO-X86 from the electronics Maker perspective. In Part 2 I’ll be looking at the CPU and graphics performance of the board on Linux as well as RemixOS. UDOO-X86 Phoronix Tests Continue reading UDOO-X86 Part 2: Roaring performance // Review

The post UDOO-X86 Part 2: Roaring performance // Review appeared first on MickMake.

App note: USB Type C, CC Pin design considerations, high voltage design considerations for Type-C connector pins in systems supporting non-USB standard charging protocol and/or fault cases

an_fairchild_AN-5086

Another app note from Fairchild Semiconductors on USB Type C to USB legacy design considerations. Link here (PDF)

When designing hardware systems with type C connectors, a designer also has to consider all legacy, standard, and nonstandard specifications that exist in the USB connector eco system. With the introduction of the Type C connector and the Configuration channel (CC Pin) new challenges occur trying to ensure overall system robustness. This note addresses some of the concerns with the CC pin in a robust system environment.

App note: USB Type-C design considerations, USB Type-C adapters

an_fairchild_AN-6105

Type-C USB cable adapter design consideration app note from Fairchild Semiconductors. Link here (PDF)

USB is a ubiquitous connector that is used by many customers and in many different applications. With the official release of the USB Type-C connector, many companies are racing to implement this new connector and the supporting infrastructure. The early adopters of this connector will be faced with many challenges as different vendor’s release products that are either non-compliant or designed to earlier versions of the specification.

One specific challenge is with USB Type-C adapter cables and how they are implemented. The adapter cables are critical for new designs because they allow backward compatibility to the existing USB infrastructure. Vendors are making a wide range of adapter cables which can cause detection issues which need to be considered. This application note describes these considerations and possible solutions to the problems faced.