makeriot2020 - Maker and IOT Ideas

Multi-Purpose IO Card

When we are working on a prototype, we always need access to pushbuttons, encoders and even displays to test our ideas in the real world. This Multi-Purpose IO Card was designed to help me do just that…

What is on the PCB?

This PCB was designed with my particular work style in mind. I use a lot of I2C devices, IO Expanders, Displays and sensors. It would thus make sense to have I2C on the PCB, to control an OLED display, as well as a PCF8574 IO expander, that is used to drive a 4×4 Matrix Keypad. Two Rotary encoders, as well as another 4 standard push buttons completes the PCB…

The features, summarised is as follows:

1x Matrix Keypad (4×4) Controlled via an PCF8574 IO expander with selectable addressing.
1x SSD1306 OLED I2C Display
4x Momentary pushbuttons, configured to be used with internal pullups – i.e pushing the button pulls the GPIO LOW
2x Rotary Encoders, with integrated Pushbutton, also configured as Active LOW

The board has all of the connectors and jumpers on the back, making it possible to mount it to an enclosure as a control panel.

I have also provided an additional I2C header to make it possible to add additional devices to the I2C bus easily

The PCB in Detail

Starting from left to right, we have two push-buttons, an OLED display, with two rotary encoders below the display, and another two momentary push buttons. On the Right, we have a 4×4 matrix keypad, and various pin headers for connection to a microcontroller of your choice.

On the back, we have the PCF8574 IO expander for the Matric keypad, addressing Jumpers for the IO expander, as well as the two pin headers for connections to and from a microcontroller…

The Pinouts of these are as follows:
Horizontal 15 pin 2.54mm connector
SDA I2C Data
SCA I2C Clock

GND

SW4 Momentary Push Button 4
SW3 Momentary Push Button 3
SW2 Momentary Push Button 2
SW1 Momentary Push Button 1

RE2-D Rotary Encoder 2 Push Button
RE2-B Rotary Encoder 2 Pin B
RE2-A Rotary Encoder 2 Pin A

RE1-D Rotary Encoder 1 Push Button
RE1-B Rotary Encoder 1 Pin B
RE1-A Rotary Encoder 1 Pin A

GND
VCC 3.3v to 5v DC

The Expansion header extends the I2C Bus, as well as proved access to the interrupt pin on the PCF8574. VCC and GND are also provided.

The Schematic

Manufacturing the PCB

I choose PCBWay for my PCB manufacturing. Why? What makes them different from the rest?

PCBWay‘s business goal is to be the most professional PCB manufacturer for prototyping and low-volume production work in the world. With more than a decade in the business, they are committed to meeting the needs of their customers from different industries in terms of quality, delivery, cost-effectiveness and any other demanding requests. As one of the most experienced PCB manufacturers and SMT Assemblers in China, they pride themselves to be our (the Makers) best business partners, as well as good friends in every aspect of our PCB manufacturing needs. They strive to make our R&D work easy and hassle-free.

How do they do that?

PCBWay is NOT a broker. That means that they do all manufacturing and assembly themselves, cutting out all the middlemen, and saving us money.

PCBWay’s online quoting system gives a very detailed and accurate picture of all costs upfront, including components and assembly costs. This saves a lot of time and hassle.

PCBWay gives you one-on-one customer support, that answers you in 5 minutes ( from the Website chat ), or by email within a few hours ( from your personal account manager). Issues are really resolved very quickly, not that there are many anyway, but, as we are all human, it is nice to know that when a gremlin rears its head, you have someone to talk to that will do his/her best to resolve your issue as soon as possible.

Find out more here

Assembly and Testing

The assembly of this PCB was relatively easy, as it contains only a single SMD component. I do however have to alert you to a certain caveat…

On the PCB, the I2C OLED display pinout is, from left to right,

VCC GND SDC SDA

I have however come across similar displays that swap the GND and VCC pins… and some that even have SCL and SDA swapped…

It is thus quite important that you check your display BEFORE soldering it to this PCB…

Addressing the PCF8574 is also quite easy, with the jumper towards the top is a high, and towards the bottom is a low… They are marked A2 A1 A0 and thus, counting in binary, all low will be 0x20h and all high will be ox27h

Also, note that there are NO I2C Pullup resistors on the board. My microcontroller PCB’s usually have these already, and most I2C Sensors, including the OLED Display that we use, already include as well…
You should thus check what you have on your own hardware, as it is quite impossible to cater for every situation… In a future version, I may add selectable pullup resistors onto this board as well…

Coding and Firmware

The possible uses of this board is quite broad, and the code possibilities are thus also quite extensive. Since I mainly use ESPHome or the Arduino IDE with most of my projects, I wont be including any specialised code here. I think it is enough to say that almost all of the available PCF8574 Matrix Keypad libraries available for the Arduino IDE will fork with this board…

The pinouts are important, and thus :

Row 0 – P0
Row 1 – P1
Row 2 – P2
Row 4 – P3

Col 0 – P7
Col 1 – P6
Col 2 – P5
Col 3 – P4

As far as ESPHome goes, you will need to
1) Add an I2c bus for your device
2)Add a PCF8574 component
3)Add a Matrix Keypad component, and refer the rows and columns to the pins on the PCF8574 – See below for an example of how I have done that in a previous project.

#I2C bus

i2c:

sda: 4

scl: 5

scan: true

id: I2C_Bus

#
# In my case, SDA is on GPIO4 and SCL is on GPIO5
# This is similar to the standard configuration on a NodeMCU v2 Dev board
#

#
# The next step is to configure the actual IO Expander, which in my case is located 
# at address 0x27
#

#PCF8574

pcf8574:

- id: 'pcf8574_hub'

address: 0x27

pcf8575: false


#
# Now we can add the actual keypad interface to the YAML file
# Take note of the difference from the ESP32 file above.
#
#

#KEYPAD

matrix_keypad:

id: mykeypad

rows:

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 0

# In the ESP32 file, we wHereould specify a pin directly like:
#
# -pin: 17
#
# That approach will not work for us.
# The reason for that is that we have to redirect the GPIO to a 
# physical pin on the PCF8574 IO expander.
#
# That is done with the following syntax
#
# - pin:
#pcf8574: pcf8574_hub -- This is the ID of the PCF8574 device -
#number: 0 -- The actual pin number

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 1

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 2

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 3

columns:

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 7

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 6

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 5

- pin:

pcf8574: pcf8574_hub

# Use pin number 0

number: 4

keys: "123A456B789C*0#D"

has_diodes: false

The Rotary encoders and momentary push-buttons can be handled in the same manner, using standard libraries in the Arduino IDE, or a rotary encoder component in ESPHome…

The OLED display would also be handled as above, with a DISPLAY component in ESPHome…

Summary and next steps

The next steps, for me at least, would be to design and CNC cut a suitable enclosure for the IO panel/Control panel in order to make it easier to use…

The panel was designed to be a tool to aid me while designing, and part of my never-ending battle getting rid of breadboards.

It does its job well, at least so far, and works as I have intended it to.

Simple Smart Light Controller

Adding a bit of automation to a certain area of the house can definitely help with saving energy. With this Simple Smart Light Controller, I aimed to do just that… Let me give you a tiny bit of context… Houses in SE Asia are built to some “questionable” standards and designs, and electrical installations are usually even more suspect… Our house is no exception. Being a rental, I do not want to go and make changes unless things are outright dangerous… Kitchens are usually a mixture of inside/outside areas, and this is where my device fits in…

The light in the outside kitchen consists of a simple bulb that the owner has routed into the house via an electrical flex cord, at least that was standard… But, due to laziness or just whatever, that cord was never terminated into a proper switch… He just added a plug. This is thus my opportunity to make life a bit easier for myself in that area. I could have opted for a standard switch, but then, automating this can take care of another problem… We constantly forget to switch that light off, as the plug is in a “strange place” that is not usually associated with the kitchen lights…

What I have thus come up with is a simple ESP8266-based solution with a single relay ( optically isolated from the board), as well as a few additional GPIO pins, just in case I want to hang some additional sensors onto this in the future.

The device should also be powered directly from the mains, as adding another external AC to DC adapter would definitely NOT do at all!

What is on the PCB

Lets look at the empty PCB, in order to understand better what is where on the board.

Starting on the Left Side, at the bottom corner, we have our mains voltage input, 220V or 110V, depending on where you live. That goes directly into U1, which is a AC-to-DC converter, providing 3.3v at 1A to the board. Note that I did not place a fuse directly on the board. I prefer to have an inline fuse on the line, which is also accessible from the enclosure.

A series of cutouts on the PCB provides additional mains isolation and also prevents mains voltage tracking towards other tracks in the event of a fault.
The Mains area also does not have a copper pour.

In the top left corner, towards the center, is a WAKE jumper. This is connected to GPIO16 and can be used to wake the ESP8266 from “deep sleep” if configured in the firmware.

Relay K1, and its screw terminal connector is in the bottom center of the board, with the relay contacts clearly labelled.

On the right of the PCB, we have the programming header, complete with Auto Flash and Reset circuitry, as well as manual Flash and Reset Buttons below that.

A 3×3 header connector follows, with access to 3.3v, Ground as well as 3 additional GPIO pins for other applications.

Finally, we have the relay control switch, with a few options to connect external switches, either on the 2.54mm header, or via wires soldered to the pads marked SW-A and SW-B

The populated PCB will thus make more sense if we look at the picture above now since we had a detailed look at it above…

Schematic_ESP8266-Smart-light-switch_2023-07-03 Download

The Schematic is made available at the link above.

Configuration and Software

This build was designed with ESPHome in mind, so we will focus on that there.
You can however very easily use standard Arduino/ESP8266 code to control this as well…

The YAML configuration for the device will be as follows: (note that this is quite simplified, as I am still fine-tuning the actual features that I require)

esphome:
  name: smart-switch-01
  friendly_name: SMART-SWITCH-01

esp8266:
  board: nodemcuv2
  restore_from_flash: true

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "hfYNn8KSbVq26rGkPOJo4yLj/d/WY7Hk0H3TmxlWZAU="

ota:
  password: "85ed2a8afcd61d0f4c65db7b92bdacc5"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Smart-Switch-01 Fallback Hotspot"
    password: "XovAx4n1H1qT"

captive_portal:

text_sensor:
  - platform: wifi_info
    ip_address:
      name: IP Address
    ssid:
      name: SSID
    bssid:
      name: BSSID
    mac_address:
      name: Wifi MAC
    scan_results:
      name: WiFi Scan Results


sensor:
  - platform: adc
    pin: VCC
    name: "ESP8266 Chip Voltage"
    id: mcu_voltage
    unit_of_measurement: "V"
    device_class: "voltage"
    accuracy_decimals: 2
    update_interval: 60s
    entity_category: "diagnostic"
    
  - platform: wifi_signal
    name: "WiFi Signal Sensor"
    id: wifi_strength
    device_class: "signal_strength"
    unit_of_measurement: "dBm"
    update_interval: 240s
    entity_category: "diagnostic"

  - platform: copy # Reports the WiFi signal strength in %
    source_id: wifi_strength
    name: "WiFi Signal Strength"
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
    unit_of_measurement: "%"
    entity_category: "diagnostic"


light:
 # - platform: status_led
 #   pin: GPIO13
 #   id: status_indicator
 #   name: "ID Light"
    
  - platform: binary
    name: "Kitchen Outside Light"
    output: relay_01
    id: kitchen_light
    on_turn_on:
    - light.turn_on:
        id: slow_light
        effect: "Slow Pulse"
    

    on_turn_off:
    - light.turn_off: slow_light
    

  - platform: monochromatic
    id: slow_light
    output: light_status
    restore_mode: RESTORE_AND_OFF
    effects:
      - pulse:
          name: "Slow Pulse"
          # transition_length: 1s      # defaults to 1s
          update_interval: 2s

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO5
      mode:
        input: true
        pullup: true
    id: kitchen_light_toggle
    filters:
      - delayed_on: 200ms
      - delayed_off: 200ms
    on_press:
      then:
        - light.toggle: kitchen_light
  - platform: status
    name: "Kitchen Light Controller"
     
switch:
  - platform: restart
    name: "Restart Device"

# Relay output
output:
  - platform: gpio
    id: relay_01
    pin: GPIO4
    inverted: true
  - platform: esp8266_pwm
    id: light_status
    pin: GPIO12

Manufacturing the PCB

Find out more here

Assembly and Testing

This device does not need a stencil for assembly, but using one will definitely speed up things. I chose to do this build all by hand, from applying solder-paste, up to placing components.

Soldering was done on a hotplate, as usual, to reflow everything at the same time. TH components were then placed and hand-soldered.

Uploading the initial firmware, after adding the device to ESPHome was done with an external USB-to-UART converter. All further firmware changes were made via OTA.

It is important to mention here that this PCB is powered by mains voltage. I chose to use an inline fuse, BEFORE the connector on the PCB. It is also notable that the relay common is connected to the live wire, BEFORE the fuse, as the lightbulb acts as its own fuse – it blows when a fault occurs.

The Lightbulb neutral will be connected to the circuit breaker, together with the device live and neutral.

This way, the fuse only acts on the actual device, and I can use a lower-rating fuse, since I do not have to accommodate the current from the lightbulb as well…

Summary

The device works as planned, with no problems…
Below is some pictures from it in Home Assistant

LED COB Controller

COB LED lights, or Chip-on-Board LED lights, are a type of LED light that has all of the LED chips mounted on a single substrate. This makes them more efficient than traditional LED lights, which have individual LED chips mounted on a circuit board. COB LED lights also produce a more uniform light output, and they can be used in a wider variety of applications.

Here are some of the benefits of using LED COB lights:

are very efficient, and they can produce up to 100 lumens per watt. This means that they use less energy than traditional light bulbs, and they can save you money on your energy bills.
produce a more uniform light output than traditional LED lights. This means that they do not create hot spots or shadows, and they provide a more comfortable light to work under.
are very durable, and they can last for many years. They are not as susceptible to damage from heat or vibration as traditional light bulbs, and they can withstand harsh conditions.
can be used in a wide variety of applications, including indoor and outdoor lighting, commercial and residential lighting, and automotive lighting.

They can however be quite a pain to power in a traditional 110v/220v AC wired house or workshop, as some of them actually required DC current to work.
I have decided to use a pair of them to provide additional, dimmable light at my electronics workbench, a place where extra light is sometimes a very necessary commodity. The ability to dim the lights will definitely aid in many scenarios as well.

The project consists of two main parts, the first being the Variable Voltage Power Module, which I published a few days ago. The particular COB lights that I will be using, were scavenged from a battery-operated emergency light panel, which had some problems which were not economical to repair. The light modules themselves, however, looked good and were perfectly working as well.
The only issue was that they were 6v DC. So using straight 12v there was out of the question. 6V being an odd voltage in my lab, I designed the module above specifically to provide that.

LED COB Controller stacked on top of Variable Voltage Poser Module

The second part of the project consists of a simple Custom ESP-12E PCB. Why ESP12-E? Well, I have a lot of them lying in stock, and since I won’t need any advanced features, commonly found on the bigger ESP32s, I decided to design around something that I have in stock, rather than overcomplicate the design with a bigger more advanced chip. The project features a rotary encoder, to adjust light intensity, as well as push buttons to toggle the lights on or off…

All of this is of course controlled with ESPHome. This choice gives me the option of manual or fully automatic control from HomeAssistant. It also saves me a lot of coding, as everything usually just works.

What is on the PCB?

We shall focus mainly on LED COB Controller PCB.
In order to understand everything, please refer to the picture below:

The board consists of a few sections, which can be divided as follows:

ESP-12E (8266) supporting circuitry

The top area is mainly the supporting circuitry for the ESP-12E, which includes a 6-pin header to flash firmware, the classic ESP32/8266 Auto Flash/Reset circuit, and manual Flash and Reset switches. Note that the board DOES NOT contain any USB-to-Serial circuitry. I usually use those only once or twice, and update firmware OTA after that. Using an external USB-to-Serial adapter is thus sufficient for my purposes.

Power and LED Control circuitry

Power enters the board in the center, using header pins mounted on the bottom of the PCB. From left to right, these are 3.3v and then two variable voltage inputs. These all originate from the Variable voltage Power Module, mounted below the main PCB. The LED Control circuitry consists of two P-Channel Mosfets, the configuration of which was previously tested in another project, the “P-MOS MOSFET Driver Board“, also published a few weeks ago. The SI2301 P-Channel Logic Level MOSFET, used here is capable of switching up to 2.3A at 20v, and thus more than capable of handling the 300mA that the LED COB modules require.

Four cutouts are provided to access test points on the power module below, as well as the potentiometers used to set the voltage that will ultimately be sent to the LED COB Modules.

Wide copper traces connect the Mosfet’s to Screw Terminals for the LED Modules.

The Final part of the PCB is dedicated to control interfaces. A single 6-way screw terminal is provided at the bottom left corner, this is used to connect a rotary encoder, or give direct access to additional GPIO pins. On the Right hand side of the PCB, a series of header pins give access to additional 3.3v and ground connections, in addition to GPIO 4 and 5, which is usually used for I2C…

The Schematic

Configuration and Software

As mentioned above, this device was designed to be used with ESPHome. The configuration is thus a single YAML file and can be greatly customised to suit your exact needs…

With that in mind, I present here a VERY basic YAML file, that will toggle the LED lights on or off on pressing the encoder switch, as well as adjust the brightness by turning the encoder.

esphome:
  name: led-cob-controller
  friendly_name: LED_COB-Controller

esp8266:
  board: nodemcuv2
  restore_from_flash: True

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "<esphome generated>"

ota:
  password: "<esphome generated>"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Led-Cob-Controller"
    password: "<your recovery password here>"

captive_portal:

# I suggest you only copy paste from here on downwards.
# Setup the default device in ESPHome, and when it is available,
# come back and add the commands below here


    
text_sensor:
  - platform: wifi_info
    ip_address:
      name: IP Address
    ssid:
      name: SSID
    bssid:
      name: BSSID
    mac_address:
      name: Wifi MAC
    scan_results:
      name: WiFi Scan Results
     


sensor:
  - platform: adc
    pin: VCC
    name: "ESP8266 Chip Voltage"
    id: mcu_voltage
    unit_of_measurement: "V"
    device_class: "voltage"
    accuracy_decimals: 2
    update_interval: 60s
    entity_category: "diagnostic"
    
  - platform: wifi_signal
    name: "WiFi Signal Sensor"
    id: wifi_strength
    device_class: "signal_strength"
    unit_of_measurement: "dBm"
    update_interval: 240s
    entity_category: "diagnostic"

  - platform: copy # Reports the WiFi signal strength in %
    source_id: wifi_strength
    name: "WiFi Signal Strength"
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
    unit_of_measurement: "%"
    entity_category: "diagnostic"

  - platform: copy
    source_id: rcbright
    name: "LED Light Brightness"
    unit_of_measurement: "%"
    filters:
      - lambda: return (x * 100);

  - platform: rotary_encoder
    name: "Brightness Control"
    id: rcbright
    min_value: 0.00
    max_value: 100.00
    publish_initial_value: True
    restore_mode: RESTORE_DEFAULT_ZERO

    pin_a: 
      number: GPIO13
      inverted: True
      mode:
        input: True
        pullup: True
      
    pin_b: 
      number: GPIO2
      inverted: True
      mode: 
        input: True
        pullup: True

    resolution: 1
    accuracy_decimals: 2
    filters:
    - lambda: return x / 100 ;
    on_clockwise:
    - light.control:
        id: led_light1
        brightness: !lambda |-
          // output value must be in range 0 - 1.0
          return id(rcbright).state ; // /100.0;
    - light.control:
        id: led_light2
        brightness: !lambda |-
          // output value must be in range 0 - 1.0
          return id(rcbright).state ; // /100.0;
    on_anticlockwise:
    - light.control:
        id: led_light1
        brightness: !lambda |-
          return id(rcbright).state ;   
    - light.control:
        id: led_light2
        brightness: !lambda |-
          // output value must be in range 0 - 1.0
          return id(rcbright).state ; // /100.0;  

binary_sensor:
  - platform: gpio
    pin: GPIO14
    id: light_switch
    name: "Light Switch"
    device_class: light
    on_click:
      then:
        - light.toggle: led_light1
        - light.toggle: led_light2
    

light:
  - platform: monochromatic
    name: "LED1_LIGHT_TEST"
    id: led_light1
    output: output_component1
  - platform: monochromatic
    name: "LED2_LIGHT_TEST"
    id: led_light2
    output: output_component2

# Example output entry
output:
  - platform: esp8266_pwm
    id: output_component1
    pin: GPIO12
  - platform: esp8266_pwm
    id: output_component2
    pin: GPIO16

Manufacturing the PCB

Find out more here

Assembly and Testing

Uploading the initial firmware, after adding the device to ESPHome was done with an external USB-to-UART converter. All further firmware changes were made via OTA.

The board performs well, with only slight heating of the LM317G variable voltage regulators on the power module when both LED COB modules are at 100% brightness. The current draw is within limits and seems to peak at about 600mA per COB…

Conclusion

This project took quite a while to move from idea to practical reality, mainly due to being busy with other more important stuff. In the end, I am happy that I sat down and did it, because it definitely will become a valuable tool in my work area.

Variable Voltage Power Module

Powering electronics projects are always challenging. This Variable voltage Power Module was designed to solve such a problem for a specific project that I am working on.

The ESP32 and their smaller cousin the ESP8266 are pretty well known for their high power requirements. Having used quite a few of these in various projects over the years, I wanted a power module that can supply me with enough current to keep these hungry little chips satisfied. I also needed variable voltages with more modest current capabilities, to drive LED COB modules for example.

The idea thus came to me to combine two recent projects, that I have been using together on the bench with great effect. These two are the Variable Breadboard Power Module, based on the LM317G, and the DC-DC Buck Converter that I designed a short time ago. Between these two devices, I can deliver up to 3A at 3v or 5v, or a variable voltage at up to 1.5A.

Let us take a look at what exactly was done here.

What is on the PCB?

The PCB consists of 3 independent power circuits, the first of which is a DC-to-DC Buck module, based on the MP9943 from MPS. This chip can source up to 3A at a preset voltage. In my case, I chose 3.3v and 5v, as I use those the most.

The second and third parts are a mirrored section, with the humble LM317G at their hearts. These are set up as variable voltage regulators, with their outputs adjustable via R10 and R13. These two can source two independent voltages, from about 1.0v right up to about 11.5v ( if VCC is 12V) at a respectable 1.5A or current.

All of this is powered by a single 12v Power supply. Note that the 12v supply should be capable of sourcing at least 3A of its own…

The stepped-down voltages are provided via 3 2-way headers at the top of the PCB.

How do you use the board?

Using the module is easy. Power it from 12v DC ( or up to 24v if you really want to)

The 3.3v or 5v output is selected using jumper J1 ( Please switch the power off first, BEFORE you change this). The selected voltage will be available at H1

H2 and H3 provide variable voltages, that can be set using R10 for H2 and R13 for H3. Turning the potentiometer anti-clockwise will reduce the voltage, clockwise to increase.

Test points ( TP1 and TP2) can be probed with a multimeter while adjusting the voltages.

The Schematic

Manufacturing the PCB

Find out more here

Assembly

This PCB uses some very tiny components, so a stencil is highly recommended.

The Buck Converter IC is especially tiny.

Most of the other components can be soldered by hand, but I chose to do the entire assembly on a hotplate to reflow everything at the same time.

Testing

After assembly, I tested everything, measuring voltages with a multimeter, as well as adjusted H2 and H3 down to 6v, as I would be using the module on another project. I also tested the ripple on the Buck converter with an Oscilloscope, and it was well within the specs stated by the datasheet, at about +/- 100mV.

The entire module draws about 650mA at no load, and up to 3A when powering 2 6v LED COB modules and an ESP32 with I2S Audio modules connected as well.
Most of the current actually being drawn by the LM317G chips. The Buck converter is actually quite economical, drawing a modest 500mA at full load
( tested with a separate module that only contains a single buck converter module).

Conclusion

The power module works exactly as expected. It will perform well for its intended purpose, i.e powering an ESP12-E (8266) ESPHome device with two 6v LED COB modules in PWM mode, as well as an I2C display and various other sensors. In that application, I have successfully tested the entire project with a modest 12v at 1A wall-brick transformer, with no overheating or power shortage on any of the components. That is thus a win, in my books at least.

An I2C Matrix Keypad

In a previous post this month I introduced my 4×4 matrix keypad. That keypad was designed to be directly interfaced to a microcontroller’s GPIO pins or alternatively to an IO expander chip like the PCF8574. That design, while working very well had the problem of requiring 8 GPIO pins to function correctly.

GPIO pins on a microcontroller can be considered very precious resources, and it should then be logical to assume that we should find a way to use these GPIO pins in a more conservative way, to allow us to interface more peripherals.

I solved this problem by integrating the keypad with an IO Expander on the same PCB. That will allow us to get away with using only 2 GPIO pins, and also open up the option of adding more keypads to the I2C bus, in the event that we need that many keys for a particular project.

The Schematic

Looking closely at the schematic, we can see that it is exactly the same basic keypad circuit that I used in the initial design. The only difference is that in this design, I have integrated a PCF8574 directly onto the PCB.

Some additional features include selectable I2C Pullup resistors ( usually my microcontroller development boards already include those) that can be activated with a jumper when needed. There are also a set of address selection jumpers, making it possible to stack keypads together into a bigger keyboard if you require something like that. Note that, in this version of the hardware, I did not include headers for stacking.

The keypad can be powered by a DC power source of 3.3v to 5v.

The PCB

The PCB is a double-layer board of 68.8mm x 50.8mm. Male header pins provide access to the connections as well as address and pullup resistor jumpers. In my build, I have mounted these male headers on the back of the PCB. That makes it possible to mount the Keypad in an enclosure without having the jumpers “stick out” and get in the way.

Manufacturing

I choose PCBWay for my PCB manufacturing.
This month, PCBWay is also celebrating its 9th anniversary, and that means that there are quite a lot of very special offers available.

Why?
What makes them different from the rest?

PCBWay‘s business goal is to be the most professional PCB manufacturer for prototyping and low-volume production work in the world. With more than a decade in the business, they are committed to meeting the needs of their customers from different industries in terms of quality, delivery, cost-effectiveness and any other demanding requests. As one of the most experienced PCB manufacturers and SMT Assemblers in China, they pride themselves to be our (the Makers) best business partners, as well as good friends in every aspect of our PCB manufacturing needs. They strive to make our R&D work easy and hassle-free.

How do they do that?

PCBWay is NOT a broker. That means that they do all manufacturing and assembly themselves, cutting out all the middlemen, and saving us money.

PCBWay’s online quoting system gives a very detailed and accurate picture of all costs upfront, including components and assembly costs. This saves a lot of time and hassle.

Find out more here

Assembly

The assembly of this PCB was quite easy and quick. A stencil is not required. All SMD components are 0805 or bigger. It would thus be quite easy to solder them all by hand with a fine-tipped soldering iron.

I have however used soldering paste and hot air to reflow the components, as it is the fastest, in my opinion, and definitely looks neater than hand soldering.

After placing SMD components onto solder paste – ready for reflow soldering

The board is now ready to solder the switches and header pins in place. As already mentioned above, I chose to assemble the headers on the back of the PCB to prevent them from interfering with any enclosure that I may later use with the keypad.

Note that I assembled the headers onto the back of the PCB.

Testing and Coding

Testing the keypad consisted of a few steps, the first of which was ensuring that there were no short circuits, as well as that all the momentary switches worked.
This was done with a multimeter in continuity as well as diode mode, with probes alternatively on each column and row in turn, while pressing the buttons.

The next stage was testing the I2C IO Expander. This was done with a simple I2C Scanning sketch on an Arduino Uno. It did not do a lot, but, I could see that the PCF8574 is responding to its address and that the pullup resistors work when enabled. This test was repeated with my own ESP8266 and ESP32 boards, this time with pullup resistors disabled, as these boards already have them onboard.

Coding came next, and it was another case of perspectives. It seems like all commercial keypads do not have diodes. This affects the way that they work with a given library. It seems that software developers and hardware developers have different understandings of what a row and a column is.

This meant that, due to the fact that I have diodes on each switch, and the way that the library work – which pins are pulled high and which are set as inputs -, I had to swap around my rows and columns in the software to get everything to work. On a keypad with the diodes replaced with 0-ohm links, that was not needed.

A short test sketch follows below:

Note that with was run on an ESP8266-12E, therefore the Wire.begin() function was changed to Wire.begin(4,5); in order to use GPIO 4 and GPIO 5 for I2C

Another point to note is that the keypad Layout will seem strange. Remember that this is due to the diodes in series on each switch. That forces us to swap around the Rows and the Columns in the software, resulting in a mirrored and rotated left representation of the keypad. It looks funny, but believe me, it actually still works perfectly.

#include <Wire.h>
#include "Keypad.h"
#include <Keypad_I2C.h>

const byte n_rows = 4;
const byte n_cols = 4;

char keys[n_rows][n_cols] = {
    {'1', '4', '7', '*'},
    {'2', '5', '8', '0'},
    {'3', '6', '9', '#'},
    {'A', 'B', 'C', 'D'}};

byte rowPins[n_rows] = {4, 5, 6, 7};
byte colPins[n_cols] = {0, 1, 2, 3};

Keypad_I2C myKeypad = Keypad_I2C(makeKeymap(keys), rowPins, colPins, n_rows, n_cols, 0x20);

String swOnState(KeyState kpadState)
{
    switch (kpadState)
    {
    case IDLE:
        return "IDLE";
        break;
    case PRESSED:
        return "PRESSED";
        break;
    case HOLD:
        return "HOLD";
        break;
    case RELEASED:
        return "RELEASED";
        break;
    } // end switch-case
    return "";
} // end switch on state function

void setup()
{
    // This will be called by App.setup()
    Serial.begin(115200);
    while (!Serial)
    { /*wait*/
    }
    Serial.println("Press any key...");
    Wire.begin(4,5);
    myKeypad.begin(makeKeymap(keys));
}

char myKeyp = NO_KEY;
KeyState myKSp = IDLE;
auto myHold = false;

void loop()
{

    char myKey = myKeypad.getKey();
    KeyState myKS = myKeypad.getState();

    if (myKSp != myKS && myKS != IDLE)
    {
        Serial.print("myKS: ");
        Serial.println(swOnState(myKS));
        myKSp = myKS;
        if (myKey != NULL)
            myKeyp = myKey;
        String r;
        r = myKeyp;
        Serial.println("myKey: " + String(r));
        if (myKS == HOLD)
            myHold = true;
        if (myKS == RELEASED)
        {
            if (myHold)
                r = r + "+";
            Serial.println(r.c_str());
            myHold = false;
        }
        Serial.println(swOnState(myKS));
        myKey == NULL;
        myKS = IDLE;
    }
}

Conclusion

This project once again delivered what I set out to achieve. It has some quirks, but nothing serious. Everything works as expected, both in the Arduino IDE/platform IO realm, as well as in ESPHome. It is worth noting that in ESPHome, we do not need to swap the rows and columns to use the Keypad component. Do remember to leave the has_diodes flag to false though…

ESP32-S DEV Board – Rev 2.0

A few months ago, I started to work on an ESP32-S SOC module in Arduino Uno form factor. This is Revision 2.0 – the ESP32-S Dev Board – Rev 2.0

During the time since I designed, and ultimately had the Rev 1.0 PCB manufactured, It has quickly become one of my go-to development platforms, something that I hoped it would become. It also seemed to be gaining popularity online, with quite a few of them being ordered.

Problems did however arise, as the manufacturer discontinued the SOC module, the AI-Thinker ESP32-S, but, as this was based on the ESP32 WROOM32 from Espressif, which, while still old, was still in production, it was not a serious problem.

Using the Rev 1.0 device was easy enough, but I soon started to experience some irritation, as in my attempts to build a very streamlined device, I left out some add-on components, that now seemed to be a very good idea to have on board…
Let me explain:

In the initial design, I did not include a DC barrel connector, as well as no USB port with a USB-to-serial converter, my argument being that the USB port is usually only used a few times, or at most once, as I usually upload firmware to ESP32’s OTA. Power ( on the bench that is, is usually supplied via a pair of wires, so no dedicated connector seemed to be necessary.

As I proceeded to design addon shields for the device, it became clear that that power connector, at minimum, as well as the standard 2-transistor reset/flash circuit, would be a very very welcome addition to this PCB.

See the pictures below for a comparison of the two boards…

ESP32-S Dev board Rev 2.0 — ESP32-S Dev Board Rev 2.0

I have also decided to use male header pins on this build, as I sort of like to use them more than the female ones ( which seem to develop connectivity issues after a while – this could be due to the quality of the connector strips that I bought)

What changed, and how?

I made quite a few changes, most of them quite subtle.
The most obvious would be the addition of a DC Barrel connector, to allow the device to be powered easier when used as a permanent project. In addition to this, a 6-pin programming header was added, in order to make flashing the device with an external USB-to-serial adapter easier than usual. ( This means that the standard 2-transistor reset/flash circuit was also added). That meant a slight increase in the component count. Additional decoupling capacitors were also added to add voltage stability to the ESP32-S. The routing of the entire board was also changed, with more attention being paid to the heat dissipation of the ESP32-S module, which tended to get a bit hot.

Power is provided by a 3.3v LDO regulator, the same as in the Rev 1.0 hardware.
I do plan to change this to a small buck converter in the near future, as the 800mA provided by the LDO regulator can get a bit limited, especially when using I2S Audio devices, something which I am doing quite a lot over the last few months.

Manufacturing

I choose PCBWay for my PCB manufacturing.
This month, PCBWay is also celebrating its 9th anniversary, and that means that there are quite a lot of very special offers available.

Find out more here

Assembly

This PCB will definitely benefit from using a stencil, but it is not strictly necessary. I did however get one, as I prefer the uniform solder-paste application and speed that they give me.

Component placing took only about 10 minutes in total, including the time needed to place and use the stencil, apply solder paste, select components and place them in their correct positions.

After Solder paste application – Before reflow soldering

The board was then reflow soldered on a hotplate at 223 degrees Centigrade.

The board was inspected for solder bridges and bad joints, and I then proceeded with through-hole component assembly, which took about another 10 minutes.

Conclusion

This was definitely a very worthwhile revision on a very useful piece of equipment. The addition of the programming header, in particular, already saves quite a bit of time, and the DC Barrel connector opens up new possibilities for the use of the device outside of the “bench” environment.

A quick P-MOS MOSFET Driver Board

Introduction

A driver is needed to switch a P-Channel MOSFET because the gate of a P-Channel MOSFET needs to be driven to a voltage that is more negative than the source in order to turn it on. This can be difficult to do with low-voltage logic, such as 5V or 3.3V. A driver can provide the necessary voltage and current to turn on the P-Channel MOSFET, even when the logic voltage is low.

Here are some of the benefits of using a driver to switch a P-Channel MOSFET:

Increased switching speed: A driver can provide the necessary current to charge and discharge the gate capacitance of the P-Channel MOSFET quickly, which results in faster switching speeds.
Reduced power consumption: A driver can help to reduce power consumption by providing the necessary current in a short pulse, rather than a continuous stream of current.
Improved noise immunity: A driver can help to improve noise immunity by providing a clean and isolated signal to the gate of the P-Channel MOSFET.

If you are using a P-Channel MOSFET in your circuit, it is a good idea to use a driver to switch it. This will help to ensure that the MOSFET is switched quickly and efficiently and that it is protected from noise.

Here are some of the different types of drivers that can be used to switch P-Channel MOSFETs:

Logic level drivers: These drivers are designed to work with low-voltage logic, such as 5V or 3.3V. They typically have a high output voltage, which can be used to drive the gate of a P-Channel MOSFET.
High-side drivers: These drivers are designed to provide a high voltage to the gate of a P-Channel MOSFET. They are often used in circuits where the P-Channel MOSFET is used to switch a high-voltage rail.
Isolated drivers: These drivers provide an isolated signal to the gate of the P-Channel MOSFET. This is useful in circuits where it is important to prevent noise from entering the circuit.

Why did I decide to design this prototype?

The Story behind the prototype

This driver PCB is part of a solution for a project involving a set of 6v LED lights.
Each of the LED lights requires +/- 300mA @ 6v to operate efficiently.
I want to control these from a Microcontroller, either an ESP32 or even the XIAO RP2040 or similar. The current sink capability of an individual GPIO pin on these microcontrollers is limited, in the case of the RP2040 it is limited to 3mA per pin.

This prototype is an attempt to test out some basic driver ideas that might perform correctly for my particular needs, being

To stay within the limitations of the particular microcontroller GPIO current specifications
To be able to use any of the particular microcontrollers, without having to design a specific solution tailored to a specific device

The Schematic

I decided to keep things extremely simple to start with, using a very simple circuit consisting of only 4 components per channel. These are :
– an S9013 NPN BJT Transistor, capable of switching up to 500mA of current
– a SI2301 P-Channel Logic Level MOSFET, capable of switching up to 2.3A
– 10k pullup-resitor
– 1k resistor on the base of the BJT

The theory of operation is as follows:
The pullup resistor, R8, keeps the gate of the MOSFET (Q4) positive, thus ensuring that Q4 stays turned off when T4 is turned off. A HIGH signal at B4 will turn on T4, which will in turn pull the gate of Q4 to ground, turning Q4 on in the process.
That will in turn turn on the load ( connected at 4+ and 4- ).

It is important to note here that the value of R8, 10K at the moment, is not finalised, and may change to increase the performance of the circuit.

The PCB

The board was made to fit on a standard breadboard or be used as a standalone module, depending on the position of the male header pins.

Manufacturing

I choose PCBWay for my PCB manufacturing.
This month, PCBWay is also celebrating its 9th anniversary, and that means that there are quite a lot of very special offers available.

Why? What makes them different from the rest?
PCBWay‘s business goal is to be the most professional PCB manufacturer for prototyping and low-volume production work in the world. With more than a decade in the business, they are committed to meeting the needs of their customers from different industries in terms of quality, delivery, cost-effectiveness and any other demanding requests. As one of the most experienced PCB manufacturers and SMT Assemblers in China, they pride themselves to be our (the Makers) best business partners, as well as good friends in every aspect of our PCB manufacturing needs. They strive to make our R&D work easy and hassle-free.

How do they do that?

PCBWay is NOT a broker. That means that they do all manufacturing and assembly themselves, cutting out all the middlemen, and saving us money.

PCBWay’s online quoting system gives a very detailed and accurate picture of all costs upfront, including components and assembly costs. This saves a lot of time and hassle.

Find out more here

Assembly

The assembly of the PCB does not require any special tools, and can be done completely by hand if you choose. A very fine-tipped soldering iron should be perfect.

I chose to go the hot-air and solder-paste route, as it is faster, and looks neater in the end. The use of a stencil was not required.

The total assembly took about 5 minutes in total.

Testing

Testing the completed PCB module was performed with one of the LED light modules connected to each MOSFET Channel in turn, and then applying a voltage signal, or ground, to the control pin ( marked A to D on the picture above)

That was followed by connecting an Oscilloscope and Signal Generator to the control pins, as well as the outputs, and observing the waveforms during operation. A square wave output from the signal generator provided the switching signal.

Conclusion

The module works as expected, but the pullup resistor value needs to be fine-tuned to provide a better switching response on the MOSFET at high frequency.
I am however happy with the initial performance, and can now move on to improving the circuit to perform to my specifications.

A Reliable Matrix Keypad

What is a matrix keypad?

A matrix keypad is a type of keypad that uses a matrix of wires to connect the keys to the microcontroller. This allows for a smaller and more compact keypad than a traditional keypad, which uses a single row and column of wires for each key. Matrix keypads are also more reliable than conventional keypads, as they are less susceptible to damage from dirt and moisture.

How does a matrix keypad work?

A matrix keypad is made up of a number of rows and columns of keys. Each key is connected to two wires, one for the row and one for the column. When a key is pressed, it completes a circuit between the row and column wires. The microcontroller can then determine which key is pressed by checking which row and column wires are connected.

Why use a matrix keypad?

There are a number of reasons why you might want to use a matrix keypad in your project. Here are a few of the most common reasons:

Smaller size and footprint.
Reliability.
Cost savings.

What makes my design different from most others out there?

While the matrix keypad in its simplest form is constructed from only wires and switches, that simple approach can sometimes have some unwanted effects, especially when pressing multiple keys at the same time – a phenomenon called ghosting – where you get phantom keypresses. This is easily eliminated by adding a diode in series with each switch, usually on the row connection.

That single component fixes ghosting reliably but does not come without its own problems, the most important of these being that a keypad with diodes becomes “polarised” – current can only flow in a single direction through a switch. This can cause problems with some third-party libraries, as the designer of the keypad and the designer of the library very often has quite different ideas of what a row and a column mean in a keypad.

This is important, – here we go down the rabbit hole; in my understanding of the keypad scanning routine, a column runs from top to bottom, and a row from left to right. Keeping this in mind, the microcontroller will alternatively set each column HIGH, and configure each row as an input. When a key is pressed, current will flow from the specific column GPIO, through the switch, and into the Row GPIO, sending the input pin HIGH…

It is also possible to configure the columns as inputs, with internal pullups enabled, and have each Row pin as an output, configured to sink ( pull current to ground). This will cause the specific column to go low – thus identifying the pressed key…

These different ways of handling the problem of reading a key, and believe me, there are actually more variations, create a few unique problems. We may have to swap rows and columns as far as pin connections and firmware are concerned, as well as define a custom “keymap” to assign values to each key.

The Schematic

As we can see above, the schematic is very basic. 16 switches, 16 diodes and a single 8-way header pin. Pin 1 to 4 on the header is connected to Columns 1 to 4, and Pin 5 to 8 is connected to Rows 1 to 4.

The diodes prevent “ghosting currents from flowing into other keys in a row when multiple keys are pressed together. They also seem to help with other stray signals and interference.

The PCB

The PCB is a simple double-layer board. All components are mounted on the top layer.

To limit interference from stray signals, I have routed rows and columns on opposite sides of the PCB where possible.

Manufacturing

I choose PCBWay for my PCB manufacturing.
This month, PCBWay is also celebrating its 9th anniversary, and that means that there are quite a lot of very special offers available.

Why? What makes them different from the rest?
PCBWay‘s business goal is to be the most professional PCB manufacturer for prototyping and low-volume production work in the world. With more than a decade in the business, they are committed to meeting the needs of their customers from different industries in terms of quality, delivery, cost-effectiveness and any other demanding requests. As one of the most experienced PCB manufacturers and SMT Assemblers in China, they pride themselves to be our (the Makers) best business partners, as well as good friends in every aspect of our PCB manufacturing needs. They strive to make our R&D work easy and hassle-free.

How do they do that?

PCBWay is NOT a broker. That means that they do all manufacturing and assembly themselves, cutting out all the middlemen, and saving us money.

PCBWay’s online quoting system gives a very detailed and accurate picture of all costs upfront, including components and assembly costs. This saves a lot of time and hassle.

Find out more here

Assembly

This project does not require a lot of specialised equipment to assemble. The SMD diodes can easily be soldered by hand, the same with the switches and 8-way header. In my case, I chose to solder the header pins on the back of the PCB, that way, I can later use the keypad in a suitable enclosure without having wires in the way.

Testing and Coding

Testing a matric keypad can sometimes be a challenge. In my case, a multimeter with clip leads, set to diode mode, with the leads connected to each column and row in turn, while minding the polarity, and pressing each key in that row in turn, verified continuity.

With that done, it was time to put my trusted Cytron Maker Uno to work, as this Arduino Clone has the added benefit of having LEDs on each of the GPIO lines, thus making it very easy to see what is happening.

I made use of a Keypad library in the Arduino IDE, mainly to cut down on the amount of coding, but also because it is easier to use a working piece of code, and then adapt that to my keypad.

Detailed Code examples for ESPHome are available on Patreon

/* @file CustomKeypad.pde
|| @version 1.0
|| @author Alexander Brevig
|| @contact alexanderbrevig@gmail.com
||
|| @description
|| | Demonstrates changing the keypad size and key values.
|| #

Edited by MakerIoT2020, with minor changes to make it function correctly with my custom keypad.
I have also added a simple LED blinking routine to show that the Arduino is “alive” and that the Keypad code seems to be NON-blocking – which is quite important to me.

*/
#include <Keypad.h>

const byte ROWS = 4; //four rows
const byte COLS = 4; //four columns
//define the symbols on the buttons of the keypads
char hexaKeys[ROWS][COLS] = {
{‘1′,’4′,’7′,’*’},
{‘2′,’5′,’8′,’0’},
{‘3′,’6′,’9′,’#’},
{‘A’,’B’,’C’,’D’}
};
byte rowPins[ROWS] = {2,3,4,5}; //connect to the row pinouts of the keypad
byte colPins[COLS] = {6,7,8,9}; //connect to the column pinouts of the keypad
/*
* Due to libraries being written by different people, and our definitions about
* what a row and a column are, is different, note that the rows in the code
* is actually the columns on my PCB. This becomes true, due to the fact that my
* PCB has Diodes on each switch, and that thus makes current flow in only one
* direction///
*
* it also has the “side effect” that keys are layout in a strange “mirrored” and
* rotated way in the firmware.
* it does however NOT affect the correct operation of the Keypad Module at all
*
*/

const int LEDPin = LED_BUILTIN;
int ledState = LOW;
unsigned long prevmillis = 0;
const long interval = 1000;

//initialize an instance of class NewKeypad
Keypad customKeypad = Keypad( makeKeymap(hexaKeys), rowPins, colPins, ROWS, COLS);

void setup(){
Serial.begin(115200);
pinMode(LEDPin,OUTPUT);
}

void loop(){
unsigned long currentMillis = millis();
if (currentMillis – prevmillis >= interval) {
prevmillis = currentMillis;
if (ledState == LOW) {
ledState = HIGH;
} else {
ledState = LOW;
}
digitalWrite(LEDPin,ledState);
}
char customKey = customKeypad.getKey();

if (customKey){
Serial.println(customKey);
}
}

This code works very well and allowed me to verify the correct operation of the keypad.

In conclusion

Making my own Keypad Module is a project that is long overdue. I have purchased a few online over the years, and as they were mostly of the membrane type, they did not last very long – it must be something to do with the ultra-cheap flexible PCB ribbon connector, since a quality membrane keypad can be quite expensive, and usually lasts quite a long time.

Having my own module available to experiment with will allow me to do some long-delayed improvements to many of my IoT modules. That code, mostly YAML for ESPHome, will be made available on Patreon.

ATMEGA4808 with CAN Bus

In This, Part 2 of my CAN Module series( Read Part 1 here), I will look at my recent modification of a previous ATMEGA4808 Development PCB to include CAN bus hardware. The ATMEGA4804 with CAN Bus development board is part of a set of “benchtop development tools” that I designed specifically to design some CAN Bus controlled Gadgets for use in my car…

The PCB is based on a previous project, in which we experimented with alternative chips to replace the ATMEGA328P.

As I was quite happy with the performance of this particular project, I thus decided to use it as the base for the CAN Bus module as well. The Added CAN Hardware adds only a few cm. to the board, keeping it quite compact, although, it will need a complete redesign once I finally get my gadgets finalised 🙂

What is on the PCB ?

The ATMEGA4808 and its supporting components dominate the left side of the PCB, with a USB connector and a CH340N providing the possibility to upload code to the chip using the Optiboot bootloader. I would however caution you, as there seem to be quite a lot of counterfeit CH340N chips floating around, I received two bad batches already, and from reliable suppliers as well… seems there is something fishy going on in the factory?? Answers anyone?

The Right side of the PCB is dedicated to the CAN Hardware, with the MCP2515 and TJA1050 taking centerstage here. While quite old, the MCP2515 is still readily available for the time being and is also quite affordable. Since I had a few left over from previous projects, I decided to once again make use of what I had on hand.

A 120-Ohm termination resistor ( selectable with a jumper), as well as a screw terminal connector, is provided. The board Reset button, as well as a power and user LED ( on D7), is also in that area of the PCB.

All GPIOs on the ATMEGA4808 were broken out onto header pins, to allow for maximum flexibility and access to features and peripherals on the chip.

Schematic and PCB Design

The Schematic, as mentioned before, is based entirely on a previous project of mine, with the CAN Hardware added onto that. ( I remind everyone once again, that this is a “tool” that I designed for myself to help in getting a specific job done. that will mean that it may or may not be very advanced, or suited for other peoples purposes… but , as a general bench module for CAN Bus development based on the ATMEGA4808, it will be perfect – that is what it was designed to do after all )

Schematic, ATMEGA4808 and supporting components

Schematic, CAN Bus Hardware, MCP2515 and TJA1050

The PCB is a double layer approximately 8.1cm x 3.3cm rectangular module.
6 3.2mm mounting holes are provided.

Manufacturing

Find out more here

Assembly

To save myself time, and ensure that the project is assembled to a high quality standard, I once again opted to have a stencil manufactured in addition to the PCB alone. This is however not strictly required with this board, as the components can still be hand soldered, or solder paste can be manually applied using the method of your choice.

High quality Stainless Stencil — High-quality Stainless Stencil

I used my standard hotplate reflow soldering technique on this board, and it turned out very well indeed, with no solder bridges, making any reworking completely unnecessary, which can in no small part be directly attributed to the super accurate stencil that I used for solder paste application…

Testing

After assembly, I went through my standard testing ritual, while of course remembering that the ATMEGA4808 is a UPDI programmable chip, which means that you can not just use a USB cable on a brand-new chip…

I uploaded the Optiboot bootloader via that UPDI header, using my own UPDI programmer, that was also a previous project, one that I am very happy to have these days 🙂

A standard blink sketch followed, and then it was time to test the CAN hardware. For this I used Gary J Fowler’s MCP Can Libray ( the same one that I used with the ATTiny1616 a few days ago ), as well as the ATTiny1616 CAN Module that I build a few days ago…

As for the firmware, at this stage, as I am only concerned about testing actual CAN functionality, I made use of the CAN Loopback on both units, and then THe CAN Sender on the ATTiny1616 and the CAN Receiver on the 4808… These sketches are all available in the library examples… so find them there.

Pinouts for the connections to the MCP2515 from the ATMEGA4808 is as follows:

CS is on Pin D7, MISO on D5, MOSI on D4, SCK on D6 and the Interrupt on D10

The ATTiny1616, which I did not mention in part one, is as follows:
CS on D13,MISO on D15, MOSI on D14, SCK on D16 and the Interrupt on D12

Conclusion

Testing went well, with everything working as expected, with the exception of another batch of CH340N chips being suspect… This does however not really bother me, as I am quite comfortable with using UPDI to upload code, as well as using an external USB-to-serial adapter, connected directly to the UART on the ATMEGA4808.

Cosmetically, I made a labelling error on the silkscreen of the CAN Bus connector, swapping Can H and CAN L… once again, this is not a problem to me.

My thanks to PCBWay for another extremely well-made PCB.

CAN Bus support with the ATTiny1616

ATTiny1616 QFN with Can bus support on a breadboard

A short while ago, I started looking at alternatives to the ATMEGA328P ( the chip used in the standard Arduino Uno). That experiment turned out quite well,
with two of the three chips turning out to be useful, the ATTiny1616 and the Atmega 4808 – The ATTiny 202, while working great, has quite a few severe limitations, due to the size of its memory, as well as library support, limiting its actual useful use quite a bit for my purposes.

In this post, which is part of a two-part series, I will look at adding dedicated CAN Bus support to the 1616 and 8408. I am planning to add some gadgets to my car, and would like to have it controlled by a CAN bus interface, and just maybe, interfacing with the CAN bus on the car as well – at least in the future…

This experiment will thus consist of two prototypes with onboard CAN hardware, to be initially used on the bench while building and testing my gadgets – more on them later, if and when they work out the way that I imagine.

What is on the PCB

The ATTiny1616 microcontroller, in a QFN package, has been married to a MCP2515 and a TJA1050. These chips, while old, are still easy to get hold of,
and I have quite a few of them lying around from previous projects. It did thus seem to be a good starting point. The fact that their libraries also works perfectly with the ATTiny1616 and Atmega4808 also went a long way towards selecting them for the project.

The PCB is similar to the ATTiny1616 QFN breakout that I have designed before but with the addition of the CAN-related components.

ATTiny1616 QFN development board with CAN bus, after reflow soldering

Schematic and PCB Design

The schematic is a variation on the earlier breakout PBC, with the addition of the CAN-related components.

Can bus related components - for use thie the ATTiny1616 MCU

The PCB design has also not changed a lot, I have just added the CAN components to the right hand side of the PCB, and adjusted the routing.

PCB layout design for the ATMEGA1616 with CAN bus Development PCB

3D render of the PCB, with the header pins in non-breadboard configuration – with the CAN bus connector not fitted.

Manufacturing

Find out more here

Assembly

I usually can not wait to receive my creations back from the factory – I mean, how can somebody not get excited about receiving their own PCBs back from the factory, especially if you know they will be of the high quality that I have come to trust with all of my PCBWay orders?

This is especially true of the smaller PCBs, as well as those with smaller-sized QFN components, with this board definitely not being an exception.

ATTiny1616 QFN Dev board with Can Bus, in packaging - straight from the factory — PCBs in factory packaging

PCBs in protective wrapping, after opening — PCBs in protective wrapping, just after opening the package

This PCB once again requires the use of a stencil, to accurately apply just the right amount of solder paste to the pads, especially the small QFN package pads of the ATTiny 1616…

High quality stainless steel, laser cut stencil. High accuracy. Definitely worth the investment — High-quality stainless steel, laser cut stencil.

Stencils, at least from my point of view, can be a controversial subject, with some hobbyists arguing that they are not worth the additional expense… I do however believe that they actually save you a lot, in time that you don’t waste on reworking a PCB due to solder bridges, in the correct amount of solder paste that is applied, in the correct thickness, and also time not wasted on the cleanup of the mess that can result from manually applying solder paste.

After solder paste application, all the components are placed in their correct positions, ready to be reflow soldered. — PCB ready for reflow soldering, after manually placing the components in their respective places

The PCB is now reflow soldered with a hot plate, and allowed to slowly cool down afterwards, to reduce thermal shock damage to the joints, that may result from a too-quick cooldown cycle. While I do not own a dedicated reflow oven, the hotplate that I use, seems to match the reflow profile ramp-up of my solder paste, and most of the components perfectly. After achieving a complete solder melt, at about 223 degrees C, I usually switch of the hot plate, and carefully move the PCB towards the edge of the unit, that area is usually a bit cooler than the centre. leaving it there for about 5 to 8 minutes, allow the solder to slowly solidify, after which I remove it and place it on a silicone mat to cool completely.

Through-hole component soldering, and testing

The next step is soldering all the through-hole components, usually header pins and connectors into their respective places. The board is then placed onto a solderless breadboard, and various test sketches are uploaded via a homemade UPDI programmer.

These include the infamous blink sketch, to make sure the chip is alive and survived the reflow soldering. That is followed by a CAN loopback test, and then the actual CAN firmware… I make use of the excellent MCP Can library from Garry J Fowler, as well as the megaTinyCore Arduino core, from Spence Konde.

My thanks to both of these gentlemen, for their excellent and easy-to-use software. A special shoutout to Garry J Fowler, since his MCP Can library correctly releases the CE pin of the device when not in use, thus not locking up the spi bus. [ This is something that many other libraries do not bother to care about ] …

Conclusion

This was once again a fun project to design and assemble. The real testing and development can now start at full speed, as this is just meant to be a tool, with a further revision later down the line. It does of course help a whole lot that I can completely trust my PCB manufacturer, PCBWay, to deliver my PCBs to me EXACTLY as I designed them, and at extremely high quality and precision! Thank you for that!