Custom PCB Design - Maker and IOT Ideas

Robotic Toy Car – Part 4

In this part of the series, Robotic Toy Car – Part 4, We will add some custom side-panels to the project. While the original toy did come with some laser cut aluminum side panels, I decided to replace them with PCB versions, with even more flashing lights (yes, this thing is turning into a “Christmas tree” , but that is what the eventual owner wanted… )

These side-panels will not be programmable. They will simply be operated from a standard 555 timer and a couple of other components, to give a flash time of about one second on and off each…

It is also an excellent project to showcase the capabilities of PCBWay, in dealing with a “rather difficult” PCB to manufacture. As you may know by now, I use PCBWay‘s services quite extensively, and I also only design my PCB’s with EasyEDA. EasyEDA is however quite limited in some aspects, and as far as myself, making panels of different designs on one PCB with complex shapes is not something that I do every day…

Let us take a look at what had to be done, and how well it was manufactured…

What we have here, is basically two mirrored side-panels ( as far as the visible “outside” is concerned anyway ) That consists of 6 led’s per side that will flash alternatively. On the “inside” we have a 555 timer chip, with some resistors and capacitors, as well as transistors that does the switching.

The difficulty of this PCB is definitely in the manufacturing. I was however pleasantly surprised with the excellent work that was done by PCBWay. Their Engineering staff did contact me early on in the order, with a suggested plan to manufacture, and once I approved that, they very quickly went on to production. My initial concern was that they suggested “mouse-bites” which we all know can sometimes come out a bit strange…

I was however extremely pleased when the above parcel arrived… They added side rails, and the “mouse-bytes” were super tiny.

The “almost completed ” Robotic Toy Car

With the completion of the side-panels, it was also time to start work on the power wiring and other essential components of the project, which will get their own detailed post in a few days.

Some details on the construction:
The toy originally came with a single 500mA 14500 cell, which unfortunately stopped working very soon after only a few uses… This was however one of the reasons why the entire project happened in the first place, so no complaints there.

I decided to replace it with a 18560 cell with a capacity of about 1900mA. This cell is much bigger however, and I had to think of where to place it. I decided to put it on the roof, sort of emulating a “spoiler”.

Some of the next parts of the project will be the remote control unit, which will basically be an ESP8266 running ESP-Now protocol, as well as a decent battery charging and power distribution circuit, that will protect the Lipo cell from over charging and discharging, as well as provide sufficient power for all the added electronics in the toy car.

“But you said it was Robotic, so why have a remote control?”

The initial plan for the project did indeed say robotic, but it is also designed to be a learning platform, especially to teach coding. With that in mind, it is definitely better to keep things simple for now, and add sensors and more capabilities later on, especially as I am actually planning to replace the main MCU board with a more powerful ESP32 in a next version anyway.

The car body is also extremely cramped, and does not have any space for mounting sensors at all. I plan to remedy that by designing and 3d-printing a whole new custom body shell later… providing that my young friend actually stays interested enough to learn the coding… If he doesn’t, he will as least have a very interesting looking custom remote controlled toy car.

Manufacturing the PCB

The PCB for this project is currently on its way from China, after having been manufactured at PCBWay.
Please consider supporting them if you would like your own copy of this PCB, or if you have any PCB of your own that you need to be manufactured.

If you would like to have PCBWAY manufacture one of your own, designs, or even this particular PCB, you need to do the following…
1) Click on this link
2) Create an account if you have not already got one of your own.
If you use the link above, you will also instantly receive a $5USD coupon, which you can use on your first or any other order later. (Disclaimer: I will earn a small referral fee from PCBWay. This referral fee will not affect the cost of your order, nor will you pay any part thereof.)
3) Once you have gone to their website, and created an account, or login with your existing account,

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

6) Click on Add Gerber File, and select your Gerber file(s) from your computer. Most of your PCB details will now be automatically selected, leaving you to only select the solder mask and silk-screen colour, as well as to remove the order number or not. You can of course fine-tune everything exactly as you want as well.

7) You can also select whether you want an SMD stencil, or have the board assembled after manufacturing. Please note that the assembly service, as well as the cost of your components, ARE NOT included in the initial quoted price. ( The quote will update depending on what options you select ).

8) When you are happy with the options that you have selected, you can click on the Save to Cart Button. From here on, you can go to the top of the screen, click on Cart, make any payment(s) or use any coupons that you have in your account.

Then just sit back and wait for your new PCB to be delivered to your door via the shipping company that you have selected during checkout.

Adding flashing lights to the Robotic Toy Car Project

In this, part 3 of the “Giving new Life to an Old Toy Car” series, we will be adding some flashing lights to the toy car project. This will ultimately serve two purposes, with the most obvious being to give some life and excitement to the project ( as the final user will be a young boy of 7, the visual aspect is important). The second purpose is more obscured, and mostly only useable to programmers and coders, or those that will debug the project… The flashing lights will function as status indicators, at startup, as well as during the normal operation of the toy. Obviously, the diagnostic nature should be well obscured so as to not distract from the visual aspects.

A short test of the display unit, disguised as a “police-style” flasher unit

The flasher unit is made up of an extremely simple circuit, with only a PCF8574 IO expander, bypass capacitors, some LED lights, and current limiting resistors.

The bottom layer of the flasher unit, shows the Io expander, bypass capacitors, and current limiting resistors.

The top layer is designed to be as clean as possible, with only LEDs and some labeling

Schematic

The schematic is straightforward, with no surprises, consisting only of a few components, like the PCB8574, bypass capacitors, current limiting resistors, and of course the LEDs. It is also important to remember that I plan to use this entire robot car to teach a young boy to program microprocessors. I believe that visual is best, thus, all the lights 🙂

Coding

As this is still a project in quite a lot of development stages, I will not publish my exact code at this moment. You can however look forward to the future conclusion post, which will contain all my code at that stage.
For now, however, we need to keep in mind that the PCF8574 is an I2C port expander, with an 8-bit IO port.

It is thus possible to do something simple like the below:

#include <Wire.h>

void setup() {
 wire.begin();
 wire.beginTransmission(0x20);
 wire.write(0b11111111); // All LEDS off
 // our circuit is sinking current into the io expander
 wire.endTransmission();
delay(1000); // delay for illustration purposes, production code will use
// non blocking code
wire.beginTransmission(0x20);
 wire.write(0b10100101); // All blue LED on
 // our circuit is sinking current into the io expander
 wire.endTransmission();
delay(1000);
}

void loop() {
}

Obviously, this is just a very quick example and is meant to just test functionality. Your own application will ultimately determine the exact code that you would need.

Manufacturing the PCB

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

Robot Toy Car – The Next steps

In our last project, we started working on repurposing an old toy car. In this part, Robot Toy Car – The next steps, we will take a look at the controller board for this project and discuss some of the problems that we have encountered up to now. Most of the various components for this project are still in the prototype stage, but It is quite important to get them tested to verify the final designs.

There are quite a few unique challenges in a project like this, which looks quite easy to solve but turn out to become quite challenging to get working just right in practice…

One of the most important, as well as the most frustrating part, turned out to be the H-Bridge Motor controller. The first prototype of this was introduced in the first part of this project. While functional on paper, as well as working quite well in real life, (when tested with an Arduino, as well as manually), It performs extremely poorly when used with the actual controller for this project, an ESP8266 12-E…

What could the reason be? How will I fix it…? The answers to that will be provided in a follow-up post. For now, let us take a look at the controller.

The unassembled ESP-8266 Controller board, straight from the factory

The Assembled ESP-8266 Controller board.

The Controller Board, details

Space inside the toy car is at a premium, so from the start, it was important to design a PCB that was small enough to fit, while also taking into consideration functionality, as well as all additional add-on components to ultimately be fitted to the project.

With this in mind, I have decided on the ESP-8266, which, while bigger than an Atmega328, does offer a few additional features, like WiFi, and ESP-Now, which will greatly help in controlling and even updating firmware OTA. The ESP-8266 does however also have a few serious flaws in this design, like limited useable GPIO pins, a 3.3v working voltage requirement, and quite high operating current requirements.

As the toy will likely not be used continuously, as well as the fact that it will run on batteries, which, can be replaced or recharged, I did not worry too much about the power issue. As far as the limited GPIO, that is where I2C comes in… It is quite easy to expand the GPIO with an IO Expander or two…

My main problem came in the form of the CH340G USB-to-UART converter chip. It seems like there must be quite a lot of counterfeit versions of these around, as none of the chips that I purchased, from many different suppliers, actually functioned, with the best one actually providing a USB port, but, when investigating with a logic analyser, the Rx and Tx lines of the UART, generating garbage…

Replacing it with a known working chip from a NodeMCU V1 board, magically solved the problem, verifying the PCB circuit as correct and working, and also proving that the purchased chips are definitely fake!

This was easily repaired by temporarily soldering jumper cables to the Rx and Tx lines on the ESP-8266, and using an external UART-to-USB converter to upload the initial sketch to the device. Future updates will be OTA, so not a problem in the long run anyway.

The controller schematic, above, is basically a rearranged stock NodeMCU v1 circuit, with the only difference being that only specific pins were broken out onto header pins. These will be used for controlling the two H-Bridges, and provide PWM as well as access to the I2C bus.

Software

Due to the fact that this controller is still definitely considered a prototype, my main focus is definitely on getting the control software sorted out first. That way, at least in my opinion, I can then focus on hardware issues responding to verified software inputs, without having to do both at the same time.

As mentioned before, I require OTA capability to upload new firmware to the device, so my starting point was the BasicOTA sketch provided with the Arduino IDE. This sketch was modified to perform some additional functionality, such as controlling the H-Bridges, PWM as well as a roof-mounted “status panel” with LED’s that also doubles as a visual display, to give a bit of colour to the project.

The “status panel” will be shown in a future post, however, with the only mention of it here being that it is I2C controlled, and based on a PCF8574.

The BasicOTA sketch is listed below.

#include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <WiFiUdp.h>
#include <ArduinoOTA.h>

#ifndef STASSID
#define STASSID "your-ssid"
#define STAPSK  "your-password"
#endif

const char* ssid = STASSID;
const char* password = STAPSK;

void setup() {
  Serial.begin(115200);
  Serial.println("Booting");
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  while (WiFi.waitForConnectResult() != WL_CONNECTED) {
    Serial.println("Connection Failed! Rebooting...");
    delay(5000);
    ESP.restart();
  }

  // Port defaults to 8266
  // ArduinoOTA.setPort(8266);

  // Hostname defaults to esp8266-[ChipID]
  // ArduinoOTA.setHostname("myesp8266");

  // No authentication by default
  // ArduinoOTA.setPassword("admin");

  // Password can be set with it's md5 value as well
  // MD5(admin) = 21232f297a57a5a743894a0e4a801fc3
  // ArduinoOTA.setPasswordHash("21232f297a57a5a743894a0e4a801fc3");

  ArduinoOTA.onStart([]() {
    String type;
    if (ArduinoOTA.getCommand() == U_FLASH) {
      type = "sketch";
    } else { // U_FS
      type = "filesystem";
    }

    // NOTE: if updating FS this would be the place to unmount FS using FS.end()
    Serial.println("Start updating " + type);
  });
  ArduinoOTA.onEnd([]() {
    Serial.println("\nEnd");
  });
  ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {
    Serial.printf("Progress: %u%%\r", (progress / (total / 100)));
  });
  ArduinoOTA.onError([](ota_error_t error) {
    Serial.printf("Error[%u]: ", error);
    if (error == OTA_AUTH_ERROR) {
      Serial.println("Auth Failed");
    } else if (error == OTA_BEGIN_ERROR) {
      Serial.println("Begin Failed");
    } else if (error == OTA_CONNECT_ERROR) {
      Serial.println("Connect Failed");
    } else if (error == OTA_RECEIVE_ERROR) {
      Serial.println("Receive Failed");
    } else if (error == OTA_END_ERROR) {
      Serial.println("End Failed");
    }
  });
  ArduinoOTA.begin();
  Serial.println("Ready");
  Serial.print("IP address: ");
  Serial.println(WiFi.localIP());
}

void loop() {
  ArduinoOTA.handle();
}

Controlling the Toy Car Robot

Controlling the Toy Car is a complicated question, with many ideas jumping into my mind, only to be pushed aside by technical issues, as well as real-world constraints on what is physically possible to be mounted on the plastic body of the toy car, space available on the inside, as well as not interfering with suspensions, springs, turning wheels etc.

As is clearly visible, there is really not a lot of space available here for sensors. Mounting sensors to the body will also provide a bit of a challenge, as well as won’t really look nice either…

I have thus decided to implement remote control for the time being, and later, maybe after 3d-printing a more suitable body, to add sensors for autonomous functionality. The ESP-Now protocol will be used extensively for the remote control, as, in my opinion, it required no additional hardware, is quite fast, as well as being extremely easy to use. It does however make it necessary to use another ESP deice in the remote control unit.

Manufacturing the PCB

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

Give an old toy car new life…

Many of us have old toys laying around the house, they belong to our children or the children of our friends. In this article, I will attempt to show you how to give an old toy car new life, as well as hopefully teach a child a few interesting things with electronics.

The inspiration for this article comes from my friend’s 7-year-old boy, who, way too clever for his age, always has a lot of very interesting questions. His mother and I have thus decided to do an experiment:
“Let us try to teach him Arduino programming, so he can start to make his own toys”

Obviously, the challenges in this venture are many…
To name a few:
The boy speaks only Thai, so English is a no-go.
Soldering is out of the question, due to his age, as well as safety issues – All teaching will have to be done on a breadboard.

My challenges apart, this is a project that many people would want to attempt, so it is important to start with a bit of theory.

Controlling a DC Motor from a microcontroller

DC motors, like those found in toy cars, are inductive loads, and that means that they induce electromagnetic fields when switched on or off. These EMF fields can damage your sensitive microcontroller quite easily. Another thing to remember is that your typical microcontroller can only source or sink in the region of 25mA to 50mA of current, not quite enough to drive a motor, let alone a toy car.

Directional control of the motor

In our toy car, we would definitely want the driving motor to be able to change direction, meaning spin forwards or backwards, thereby changing the direction that the car is travelling. This is achieved by using a circuit called an H-Bridge. In this circuit, four transistors, either BJTs or MOSFETs are arranged in a particular way to allow us to change the direction that the motor spins by changing certain logic signals.

In the picture above, we simulate the H-Bridge circuit using slide switches in order to explain the method of operation. It should be clear that the direction is changed by switching on diagonally opposite switches.

In the picture above, we implement a simple, one-directional motor control circuit using a single transistor. This circuit still has the limitation that the motor can only spin in a single direction.

In the circuit above, we combine the two motor driver circuits (with PNP and NPN transistor ) to complete one half of the H-Bridge circuit. This circuit still has the limitation that we can only spin the motor in a single direction.

In the picture above, we added another half H-Bridge to complete the circuit. We will thus have 2 PNP and 2 NPN transistors, which form the completed circuit. This circuit will give us full bi-directional control of the motor. We can also control the speed of the motor if we apply a suitable PWM signal to the bases of the NPN transistors – we do need to be careful of SHOOT THROUGH and shorts though.

My proposed Motor Driving Circuit

the inside of the toy car, without the old broken circuit-board

In the picture above, we can clearly see that there is not a lot going on inside this toy car. An On-Off switch is connected to the battery compartment, and two wires go to the drive- and steering motor.

Interfacing this car to a microcontroller is thus going to require two separate H-Bridge circuits. One for the drive motor, and the second for the steering.

I have designed the circuit above to control both motors of the toy car, the control signals are simplified to 2 per H-Bridge, and a common PWM signal to control speed.

Manufacturing the PCB

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

Compact Remote Alarm Transceiver – Part 2

In part one of this series, I took a look at some of my experiments using different voltage regulators, to design and build the Remote Alarm Transceiver prototype, and also mentioned that I will be looking at a single chip logic converter solution. In this (hopefully short) post, I will take a detailed look at that logic converter chip, as well as show you how it is used.

The Logic Level Converter Chip

I have chosen the TXS0108E Bi-Directional 8-bit Logic-Level Voltage translator from Texas Instruments for this application.

Some of the features of the device is listed below:

• AEC-Q100 Qualified for Automotive Applications
– Device Temperature Grade 1: –40°C to 125°C
– Device HBM ESD Classification Level 2
– Device CDM ESD Classification Level C6
• No direction-control signal needed
• Maximum data rates
– 110 Mbps (push pull)
– 1.2 Mbps (open drain)
• 1.4 V to 3.6 V on A port and 1.65 V to 5.5 V on B
port (VCCA ≤ VCCB)
• No power-supply sequencing required – either
VCCA or VCCB can be ramped first
• Latch-up performance exceeds 100 mA per
JESD 78, Class II
• ESD protection exceeds JESD 22 (A Port)
– 2000-V human body model (A114-B)
– 1000-V charged-device model (C101)
• IEC 61000-4-2 ESD (B port)
– ±8 kV contact discharge
– ±6 kV Air-gap discharge

Datasheet description:

This device is an 8-bit non-inverting level translator
that uses two separate configurable power-supply
rails. The A port tracks the VCCA pin supply voltage.
The VCCA pin accepts any supply voltage between 1.4
V and 3.6 V. The B port tracks the VCCB pin supply
voltage. The VCCB pin accepts any supply voltage
between 1.65 V and 5.5 V. Two input supply pins
allows for low Voltage bidirectional translation
between any of the 1.5 V, 1.8 V, 2.5 V, 3.3 V, and 5
V voltage nodes.
When the output-enable (OE) input is low, all outputs
are placed in the high-impedance (Hi-Z) state.
To ensure the Hi-Z state during power-up or power-down periods, tie OE to GND through a pull-down
resistor. The minimum value of the resistor is
determined by the current-sourcing capability of the
driver.

Typical Application:

My Thoughts:

I really like the tri-state (high impedance) mode of the chip, as it allows for isolation between the different voltage level circuits, for example, If I were to communicate on a 5v SPI bus, to another device, I can for instance put the chip in Tri-state mode, and not worry about stray signals interfering from the 3v side.

On the downside, the chip is very small, which makes it a real challenge to solder by hand. On the speed side, It is also not quite as fast as my usual MOSFET based circuitry. It does however do the job it was designed for quite well.

Updated Circuit

Integrating the chip into the existing Remote Alarm Transceiver circuit is very easy, allowing us to replace almost all of the Mosfet-based Logic level converters. We do still need a few of them, as we have only 8 bidirectional channels on the TXS0108.

Schematics

Some Notes on the schematics:

A battery level monitor is connected through a voltage divider, with a MOSFET as a switch to the A0 pin. The voltage divider is set up for a 12v DC input source. The MOSFET is controlled from the D6 Pin.

The reason that I did this is, that I found some parasitic voltage leakage through the A2D converter in a previous design, reducing battery life. My hope is that by only reading battery level when the MOSFET is on, there can be an increase in battery life ( Taking into consideration that the Voltage regulators are not very efficient, it won’t really amount to a big gain unless I switch to an SMPS in the future. )

The PCB

In the picture above, we can see the completed PCB (The relay and buzzer were not populated yet)

Manufacturing the PCB

This PCB was manufactured at PCBWAY. The Gerber files and BOM, as well as all the schematics, will soon be available as a shared project on their website. If you would like to have PCBWAY manufacture one of your own, designs, or even this particular PCB, you need to do the following…
1) Click on this link
2) Create an account if you have not already got one of your own.
If you use the link above, you will also instantly receive a $5USD coupon, which you can use on your first or any other order later. (Disclaimer: I will earn a small referral fee from PCBWay. This referral fee will not affect the cost of your order, nor will you pay any part thereof.)
3) Once you have gone to their website, and created an account, or login with your existing account,

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

Compact Remote Alarm Transceiver – Part 1

As part of my experiments with LoRa and the easy to use ATMega328P, I have recently designed quite a few LoRa based projects. In this final 2 part series, I will look at two additional projects, part of a Remote Alarm Transceiver, where I experimented with a changing a few things:

– Using LM317G adjustable voltage regulators.
– Replacing my standard N-MOS based logic level converters with a dedicated chip.

LoRa Remote Alarm Transmitter – with Onboard Relay putout and two sensor inputs

How does this differ from my other LoRa Based projects?

The PCB presented above does in fact not really differ a lot from any of my existing LoRa based projects.
However, there are a few subtle changes, mainly experimental changes, brought on by factors such as component availability and an attempt to reduce component counts and board size.

The first of these changes is using the LM317G voltage regulator, in the place of my usual LM1117 3.3 and 5.0 LDO regulators.

The LM317 is an old device, It has been on the market for a long time. It can supply up to 1.5A of current, and a single device can be configured to supply a wide range of different voltages by just changing two resistors. This seemed quite attractive to me, as it is getting quite difficult to reliably get quite a few components on time, and with decent pricing in the post-Covid-19 world.

The second major change would be moving away from my existing N-Mos based Logic converter setup, where I used the BSS138 and 10K resistors as logic converters. This setup works perfectly, but it has the drawback of requiring quite a lot of components. for example:

To provide logic conversion to an RA-02 module, with access to all the IO Lines (GPIO0-5 included) required 12 BSS138 Mosfets and 24 10k resistors. This is quite a lot of components. A dedicated logic converter chip would thus be a much more attractive solution.

Driver circuitry for sensor Inputs, consisting of a simple transistor input, and an optically isolated Relay output completes the circuit.

Using the LM317

LM317 Typical use circuit - Fixed Voltage

The output voltage of the LM317 is typically set using two resistors, with a suitable current rating, using the following Formula

V_OUT = 1.25 * ( 1 + R2/R1 )

It is also common to use a variable resistor at R2, to have fine control over the output voltage. This is due to the fact that stock resistor values do not always give you the exact voltage you require. You should also take into account that using a 5% resistor will be less accurate than a 1% resistor.

The grid below is a list of common stock resistor values for R1/R2, with the resulting voltage produced.

R1 vs R2 Grid for use in selecting fixed output voltage

R2\R1	150	180	220	240	270	330	370	390	470
68	1.82	1.72	1.64	1.60	1.56	1.51	1.48	1.47	1.43
82	1.93	1.82	1.72	1.68	1.63	1.56	1.53	1.51	1.47
100	2.08	1.94	1.82	1.77	1.71	1.63	1.59	1.57	1.52
120	2.25	2.08	1.93	1.88	1.81	1.70	1.66	1.63	1.57
150	2.50	2.29	2.10	2.03	1.94	1.82	1.76	1.73	1.65
180	2.75	2.50	2.27	2.19	2.08	1.93	1.86	1.83	1.73
220	3.08	2.78	2.50	2.40	2.27	2.08	1.99	1.96	1.84
240	3.25	2.92	2.61	2.50	2.36	2.16	2.06	2.02	1.89
270	3.50	3.13	2.78	2.66	2.50	2.27	2.16	2.12	1.97
330	4.00	3.54	3.13	2.97	2.78	2.50	2.36	2.31	2.13
370	4.33	3.82	3.35	3.18	2.96	2.65	2.50	2.44	2.23
390	4.50	3.96	3.47	3.28	3.06	2.73	2.57	2.50	2.29
470	5.17	4.51	3.92	3.70	3.43	3.03	2.84	2.76	2.50
560	5.92	5.14	4.43	4.17	3.84	3.37	3.14	3.04	2.74
680	6.92	5.97	5.11	4.79	4.40	3.83	3.55	3.43	3.06
820	8.08	6.94	5.91	5.52	5.05	4.36	4.02	3.88	3.43
1000	9.58	8.19	6.93	6.46	5.88	5.04	4.63	4.46	3.91
1200	11.25	9.58	8.07	7.50	6.81	5.80	5.30	5.10	4.44
1500	13.75	11.67	9.77	9.06	8.19	6.93	6.32	6.06	5.24
1800	16.25	13.75	11.48	10.63	9.58	8.07	7.33	7.02	6.04
2200	19.58	16.53	13.75	12.71	11.44	9.58	8.68	8.30	7.10
2700	23.75	20.00	16.59	15.31	13.75	11.48	10.37	9.90	8.43
3300	28.75	24.17	20.00	18.44	16.53	13.75	12.40	11.83	10.03

As you can see from the table above, using stock resistors, the output voltage is reasonably accurate, but it is quite obvious that you will need a potentiometer to get exact values.
Another issue will definitely be heat dissipation. In my PCB design, I have used the SOT-223 package of the component, with a PCB heatsink, built directly into the layers. With the LM1117 LDO regulators, these work extremely well.

Logic Level Conversion

In this design, I used my standard Logic Level conversion circuit, comprised of a BSS138 N-Mos with two 10 k resistors. This circuit, although a bit cumbersome with lots of components if you need many logic converters, is very stable, and functions extremely well.

Conclusion

This circuit was designed as a two-part prototype, with the goal of experimenting with different voltage regulators, and in part 2, with a single chip 8 channel logic converter. As such, I do not feel comfortable releasing the full schematics to you at this stage, do so anyway in the interest of learning. The circuit works, but there are many issues with the regulators:

– Overheating at input voltages above 8.0v
The PCB heatsink will have to be improved, or even a different package for the LM317 with the possibility to attach an external heatsink.

– The voltages do not seem stable, especially on the 3.3-volt side.

Manufacturing the PCB

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

Special Limited Offer – Get your PCB for only $1

Every once in a while, we get an opportunity to take advantage of an exceptional deal. Recently, the friendly people at PCBPartner.com reached out to me with another great deal… “Get your next PCB for only $1!”

You will get the following:
10 FR-4 PCB, 1 or 2 layers, with Green Soldermask, in dimensions not exceeding 100mmx100mm, Manufactured and delivered to your door for only 1 (one) $USD.
This promotion will be valid until 31 May 2022, with AIRMAIL shipping included.

Who is PCBPartner.com

PCBPartner.com is owned and operated by Kinji Group, established in 1997. We have over 20 years of experience in PCB manufacturing, PCB design, component manufacturing and distribution, PCB assembly and PCB CAD software development.

While Kinji Group has 3 PCB factories in China, we have also developed strategic partnerships with more than 15 other factories around Asia. We, therefore, have a large group of specialists in PCB manufacturing, quality control, technical support and part sourcing to support your innovative ideas and products.

Our over 500 employees are spread across 8 branches in Mainland China (Shenzhen, Dongguan, Shanghai, Wuxi, Chengdu, Xiamen), Hong Kong SAR, and Taiwan. And we’re still growing!

Why Should you use PCBPartner for your next PCB order?

Variety of PCB Material

Up to 54 layers during PCB manufacturing.

FR-4 with different tg (135,150,170),
CTI 600 (Halogen free) PCB material,
Aluminium base PCB,
Flexible PCB,
Rigid-Flexible PCB,
Rogers, and many more materials.
Whatever material you need, they can deliver.

Special PCB Specifications:

Regular PCB production for these special PCB specifications

● Impedance control

● Custom-layer stack up

● 1-3 oz copper thickness for outer/inner layers

● Hard gold, ENEPIG, OSP surface finish

● Two different solder mask colours on one PCB

● Edge connector plating

● Edge plating

● Via filled with aluminium/resin

● And more…

Fast Lead Time

Turnaround is quick as prototypes usually take as little as 24 hours to produce, with a direct pickup service from their warehouse. They partner with DHL and FedEx for this to make sure you get your PCB in the shortest time possible. They also offer express production options for small and medium-sized batches so that you get your boards EVEN quicker.

Competitive Pricing

Get competitive pricing on prototypes and your future mass production. For any mass production orders, contact them so that they can find the best pricing and shipping solutions to maintain your competitiveness

Ordering boards in bulk? Save more the larger your order:

US$10 off orders of 100+

US$50 off orders of 500+

US$120 off orders of 1000+

Quality Control

After 20 years, they have built a strict standard of quality – their quality control teams ensure all PCBs pass the AOI and E-test with 100%.

Technical Support

They have an experienced PCB manufacturing and engineering team to help you detect potential mistakes in your Gerber files. They also use – and have used for 15+ years – a reliable PCB testing software solution, iPCB, to detect mistakes in designs.

Excellent Customer Service Team

They have a passionate (and patient!) customer service team to help you solve any problems while ordering, handle engineering questions, or answer any after-sales service request. They will respond to you within 1 working day, that’s their customer service guarantee.

Flexible Payment Term

If you have a large amount of PCB to order every month and want to work with them for AMS 30 payment, they will be happy to sign an agreement with you.

Easy to use CAN-BUS Module with Relay, LiPo Battery Backup

Can Relay Module running on battery power

CAN-Bus allows us to add a lot of devices to a single bus (theoretically up to 127, with a practical limit of about 110). It was logical to decide to use CAN-BUS for communication between my LoRa-CAN Module and remote nodes in my ongoing farm telemetry system. In a previous project, I introduced the LoRa-CAN Gateway, which will be used to send/receive messages from the master control unit, the SX127x-RA-02-Module.

Today, I will focus on the design of the node device, an Arduino compatible CAN Relay Module PCB, with a built-in, CAN Controller and Transceiver ( MCP2515 and TJA1050 ), and the option to be powered from a LiPo battery (18650 or Single 3.7v Lipo cell), with charging provided by an MH-CD42 Module, similar to that used in the SX128x project mentioned above. The Module can also be powered directly from up to 12v DC by placing Jumper H2 in the V-REG position…

As mentioned in a previous project, the MH-CD42 module can provide up to 2A of current to charge a battery and provide 5V DC on a direct bypass circuit to power the rest of the circuit while the battery is being charged. This feature makes it ideal for my intended use, as I would only be needing battery power at night when the off-grid solar powered inverter is not actively charging the main batteries, and providing 220v AC.

The CAN Relay Module PCB was designed to be as compact as possible, with a total footprint of the standard Arduino UNO. As space was at a premium, and to ensure that there are the absolute minimum additional components that will consume power when operating from the battery, I have not included any USB-to-Serial converters onboard. Firmware can be uploaded with an AVRASp, USBASP, Arduino as ISP or even an external USB-to-Serial converter ( providing that you load a bootloader into the Atmega Chip).

All of the unused GPIO pins on the ATMEGA chip is broken out into headers, with the exception of D10 ( which is used as CE/SS on the MCP2515 CAN controller), D9 which is connected to the Interrupt from the MCP2515, and D4, which is used to control the onboard Relay.

Can Relay Module with LiPo cell and MH-CD42 Module

The MH-CD42 Module, and LiPo or 18650 Battery are completely optional, The device can function without these, by moving the H2 jumper to the VREG position as already mentioned above. This will divert the DC Voltage(Up to 12v) from the DC input adapter to the build-in 5v LDO voltage regulator to power the device.

If you place the H2 Jumper in the VBAT position, you need to install the MH-CD42 module to provide power to the rest of the PCB, as well as keep the LiPo battery or 18650 Cell charged…

Please NOTE:

When the MH-CD42 module is in use, the total DC input voltage through the DC input adapter SHOULD NOT exceed 5.5v DC! This is a limitation in the operating parameters of the MH-CD42 module. Not paying attention to this will result in damage to the MH-CD42 Module.

You could also power the module with REGULATED 5v DC, directly from any 5v header pin. Please note that in this case,

1) The battery won’t be charged.

2) The LDO regulator will not be in operation.

The Microcontroller

The CAN Relay Module can use any of the ATMEGA8a/88/168/328 AVR microcontrollers, as the pinout is identical. I believe this is an advantage, especially with the current chip prices, where my last quote for an ATMEGA328P-AU was 69$USD!!!! This is in comparison to the 4 to 5 USD each for an ATMEGA8a or ATMEGA168 ( We must also remember though that the 328p is very well known, and thus have higher demand. The 8a/88 or 168 are less well known, have much less memory and flash area, and will thus be cheaper. A word of action though, I had strange issues with I2C on the Atmega8a with Mini core, to such an extent that I2C does not work at all?

If you plan to use I2C on this board, install a 328p right from the start, and save yourself a lot of headaches!

This is the Relay driver circuit. As you can see, it is optically isolated, and active LOW. This means that you have to pull D4 LOW to energise the relay. Also note that, although the relay is optically isolated from the microcontroller, the coil is NOT galvanically ISOLATED. The load, which is magnetically switched, will be truly galvanically isolated, providing of course that you don’t do something silly like using a common ground to the PCB as a common on the relay…

This is the Processor and Power-supply schematic. The circuit is basically a standard Arduino Nano, with modifications for the CAN Controller on the next schematic page. Note that the MH-CD42 is not shown on the schematic. The VBAT net connects directly to the VIN pin on the unit, with the BAT net connecting to the positive of the battery. VOUt-5v from the module goes directly to the 5v net. All grounds are commoned.

This is the CAN Controller and Transceiver circuitry. The MCP2515 connects directly to the SPI bus on the microcontroller via D13, D12 and D11, with D10 as CE/SS and D9 as Interrupt or IRQ. It is important to note that although the MCP2515 is a 3v capable device, the TJA1050 Can transceiver is 5v only. This prevents us from running the PCB at 3v unless, of course, we change the TJA1050 out for a 3v capable device…

CODE

The board has been extensively tested with Cory J Fowler’s mcp_can Arduino Library. It works very well indeed.

As I am currently working on the final integration of the two modules, I am not yet ready to publish my final code, showing the operation between the CAN-Bus and LoRa-to-CAN Gateway device in this post. Once I am happy that all issues are definitively sorted out, I will publish my code.

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

CAN-to-LoRa gateway using RA-02, MCP2515 and ATMEGA328P

ATMEGA328P Module with integrated LoRa and CAN-BUS

INTRODUCTION

In my quest to perfect my LoRa telemetry system, I have gone through quite a few prototypes by this time. This post will focus on the next node design. Due to the fact that the area where I will deploy the system is quite large, but with roughly square boundary fence-lines, I decided to try and reduce the number of LoRa Radio nodes needed to cover the entire area. This opened up the opportunity to utilise CAN-BUS to attach sensor-only nodes to a Radio node and have them report status on exception as well as on requests from the radio node.

The device will thus function as a LoRa-to-CAN-BUS Gateway, with some local automation to control the transmission of data to the master station. This concept can also be adapted for use in other areas, such as home -automation, or an industrial setting.

At the heart of the device, I have stuck with the versatile ATMEGA328P, which, current chip shortages excluded, and current high prices excluded, are a very inexpensive chip, with lots of well-tested libraries, and a relatively low learning curve, largely due to its very wide use in the Arduino ecosystem.

The LoRa component is handled by the RA-02 or even RA-01H module, from AI-Tinker (not sponsored). This device, as we have seen in the previous prototypes, requires the use of logic level converters, due to the fact that it only accepts 3.3v logic levels. While I could get rid of those if I powered the ATMEGA328P from 3.3v, it would give rise to two problems, of which one will still force the use of level converters…

I chose to run the ATMEGA328P at 16Mhz, which basically forces me to use 5v to power the chip. The second reason is not so obvious unless you read a few datasheets very thoroughly…

The CAN-Bus component is handled by the MCP2515 Standalone SPI-to-CAN Controller, as well as the TJA1050 CAN Bus transceiver.

This is where things get interesting… The MCP2515 can operate on 3.3v, but the TJA1050 is a 5v only device. I could thus in theory use logic level converters only between the MCP2515 and the TJA1050, while running the rest of the circuit on 3.3v…

Given that I would rather run the ATMEGA328P on 16Mhz, as well as the fact that my LoRa Radio Module circuit, with its logic level converter circuitry, works extremely well, I decided not to change that, and keep the CAN Bus running at 5v all the way through, as I would still have to use a 5v regulator on the PCB anyway just for that purpose.

IO connections for LoRa and CAN BUS modules

You can order this PCB directly from PCBWay, by clicking here

Both of the two integrated components ( Lora and CAN ) are SPI devices. This means that they share common SCK, MISO and MOSI lines ( provided on the ATMEGA328P by pins D13, D12 and D11 respectively. The individual SPI device is then further selected for operation by the use of a CE pin, one unique pin per device, which is pulled low by the MCU to indicate to the device that it should pay attention to the data being transmitted on the SPI bus…

Both LoRa and CAN makes use of other pins as well, LoRa needs a Reset pin, connected to D9, a CS/CE Pin on D10 as well as a hardware interrupt pin, connected to D2. ( Note that this is for use with Sandeep Mistry’s LoRa Library. The Radiolib library would require an additional pin, usually connected to DIO1 on the LoRa module. The device does not provide access to those pins in its current layout, so you can only use it with the Sandeep Mistry library, for now at least… )

The CAN module uses a CE/CS pin at D4, with an IRQ pin on D6, which, although not a hardware interrupt pin, does have PCINT functionality.

Pins D10, D9 and D2 are not broken out for user access. although I decided to give access to D4 and D6, as well as the SPI bus, D11, D12, D13, to allow interfacing with logic analysers, or adding other SPI devices to the bus…

This brings us to a very interesting point… Does the two SPI devices actually play nice together? and what do I mean by “playing nice together”?

To answer that question, we are forced to first look at a bit of theory, as well as understand the fundamental differences between SPI and I2C…

The Difference between SPI and I2C

Most of us will be quite familiar with I2C, as it is a very common protocol used to connect sensors to a microcontroller. It consists of only two IO lines, SDA for data, and SCL for the clock. Each device on the bus has its own built-in address, like in the case of a PCF8574 IO expander, this address can be selectable between 0x20h and 0x27h. All of the devices share these common data lines, and will only respond when specifically addressed by the master controller… Unless you accidentally put two devices with the same address on the same bus, (if that would even work), there is no way that the wrong device would respond to any request for data…

SPI on the other hand, operates on a completely different principle, making it quite a few times faster than I2c, with data being simultaneously sent and received by the active device… SPI is also known as a four-wire protocol. Each device has a minimum of 4 data lines, namely SCK ( clock), MOSI ( for data transmitted FROM the Master TO the slave device ), MISO ( for data transmitted TO the master FROM the slave device) and a CE or CS ( Chip select ) pin.

SCK, MISO and MOSI are COMMON to all devices, meaning it is shared between all of them. CE/CS is a unique pin for EACH device, meaning that if you had four SPI devices on a bus, you would have to have four individual CE/CS pins!

A device will, or rather should only respond to data on the SPI-BUS IF the master pulls its respective CE/CS pin LOW. It should now very quickly become clear to you that this can become a very very complex mess, very quickly.

Let us take a very good example. the ST7789 SPI display module, has a cheap version, commonly sold on Ali-express, as we ll as other online stores. This particular module, I assume in a bid to make it easier to use, has the CE/CS pin internally pulled down to ground by default… So what about that, you may ask? What is wrong with that, as it saves you an IO pin?

It is in fact very wrong, a fact that you will very quickly discover if you ever tried using one of those displays on an SPI bus together with other SPI devices… Nothing will work, or only the display will work ( if you are lucky)

But why?

Pulling CE/CS LOW, signals to the chip that it should respond to instructions on the common SCK, MISO and MOSI lines. having the pin internally pulled LOW, thus forces that chip to always respond, even when it should not. Thus contaminating the entire SPI-BUS with garbage…

The answer to the question

After that very long-winded explanation, which is still extremely basic, it is time that we get back to our original question:

Does the Sx127x ( RA-02 ) Module and the MCP2515 Can Controller play nice on the same bus? The answer is not straightforward, as it comes down to which libraries you use…

Remember that the library must pull down the CE/CS pin of the device that it wants to communicate with. Some libraries wrongly assume that they are the only ones in use, and ignores the simple fact, that they should release the CE/CS pin AFTER EVERY transaction, to free up the bus for other devices to use it as well…

After extensive testing, I can however say that Sandeep Mistry’s LoRa Library, as well as the mcp_can library, does indeed play nice together. These two libraries do not keep the individual CE/CS pins pulled LOW, and allows the spi bus to be shared.

This is not the case with the ST7789 Module discussed above, where the hardware actually pulls the pin ow the entire time…

Taking a closer look at the PCB

Let us take a closer look at the PCB. The Ra-02 Module ( LoRa ) dominates most of the left-hand side of the PCB, with the ATMEGA328P on its right. The RA-02 is surrounded by the level converters, using the BSS138 N-Channel Mosfet, and 10k resistors (Q1 to Q6, R1, R2, R3, R4, R5, R6, R8, R9, R10, R11, R12, R13)

C1 and C2 are bypass capacitors for the Ra-02 module

In the bottom left corner, we have a hardware reset button, to reset the ATMEGA328P, with a yellow jumper (H1) next to it. This jumper controls the 120ohm ballast resistor (R17) for the CAN bus. Removing the jumper will remove the ballast. Directly below that is the CAN connecter, marked as U5, with CH as CAN-H, and CL as CAN-L ports.

U3 and U4, together with R18, R19, X2, C16, C17 make up the CAN components on the PCB. Decoupling is provided by C6, C7, C8 as well as C9 and C12 ( Includes the ATMEGA328P’s decoupling as well )

An ICSP programming header is provided above U1 ( ATMEGA328P) for use with USPASP, AVRASP or Arduino as ISP and similar.

No USB to serial converter is provided on the board, Serial upload is possible is loaded with an Arduino bootloader for the Arduino NANO ( to make use of all the analog inputs). RxD, TxD and DTR pins are broken out on opposite sides of the PCB, as well as access to 3.3v, 5v and GND pins.

A DC power socket is provided. it can accept up to 12v DC, although I would recommend not to go over 7.2 volts, to not stress the LDO regulators, at the back of the PCB ( LDO1, and LDO2) too much.

You can order this PCB directly from PCBWay, by Clicking here

in the picture above, I have connected a USB-to Serial converter, as well as CAN-BUS to the device.

Schematic Diagram

The detailed schematic diagrams are provided below:

Sheet 1 (above) takes care of the ATMEGA328p and it supporting circuitry, as well as the power supply via LDO regulators.

Sheet 2 (below) takes care of the Logic Level converters, RA-02 (Sx1278) LoRa Module, and CAN-BUS controller and transceiver circuitry.

Software and Firmware

In order to test this module, I made use of the mcp_can library by Cory J Fowler, for the CAN-Bus part,

as well as Arduino-LoRa by Sandeep Mistry

A combined example utilising both LoRa and CAN at the same time, will be released with the next part of the project, namely the CAN-Relay Module

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB

IO Shield for LoRa Base Module

INPUT And Monitor Shield for LoRa Base Module

Introduction

This is a straightforward project compared to my usual PCB projects. It is one of a series of designs towards completing my LoRa monitoring system, that I plan to use on the farm to monitor various areas, such as intrusion detection, battery levels etc.

The shield was designed to fit on top of the first LoRa Base Module. It was designed to allow easy, neat connections to Infrared Beam sensors, XYC-WB-DC Motion Detector, as well as to monitor the battery levels at the Solar power inverter (the farm is completely off-grid).

The Motion Sensor provides a +3v signal that goes high on motion detection, while the Infrared Beam Sensor provides a relay contact that can be used to provide a similar voltage signal. As I prefer to use pull-up logic on my inputs, I decided to implement a simple transistor circuit where the input will switch the base of the transistor, which in turn will pull the input to signal ground when switched on. This circuit uses the S8050 transistor, with the base pulled down to signal ground via a 10k resistor to prevent floating, and a current limiting resistor of 1k to 1k8 on the base. The collector, as well as the D7 and D8 GPIO pins on the LoRa Base Module, is pulled High to Vcc5v via a 10k resistor.

Voltage monitoring is done with the ADC on the LoRa Base Module, with each of the 4 battery levels ( 12v, 24v,36v, and 56v) being connected to the relevant ADC channel via a resister-divider network to lower the respective voltage to a level between 0 and 5v. ( This was done as the ADC on the ATMEGA328p can only handle a maximum voltage of 5.0v )

The resistors were chosen to give a slightly bigger input voltage range, to accommodate for fluctuations from the solar charger ( It can sometimes go up to 65v on a very bright sunny day ). I decided to not add any current limiting resistors directly onto the PCB, as they are definitely going to be bulky. They will instead be attached externally, to suitable heatsinks, etc…

As this PBC is still in the prototype stage, and my LoRa Monitoring device will definitely go through quite a few modifications in future, I provided access to all unused GPIO pins via separate headers on the shield. Most notably the SPI Header, used for programming the ATMEGA328P MCU, or connecting other SPI devices ( I am working on a CAN bus addon for the device, to save on the number of physical radio nodes that needs to be installed), The UART Header, as well as I2C, A6, A7 and additional Digital IO Pins (D3~, D4, D5~).

In the photo above you will notice an additional header on the UART pins, This was added to assist me with debugging on the logic analyser, as I had a slight issue with waking up the ATMEGA328P, and getting it to send events via LoRa. It would wake up, print status messages through the UART, but never do the actual LoRa part! That has now been fixed, and the header removed…

The schematic diagram for the shield is below. As you will see, it is very uncomplicated indeed.

Software and Libraries

The LoRa Base Module has been designed to use the LoRa Library from Sandeep Mistry. Further versions of this PCB will also directly support the RadioLib Library from JGromes.

A reminder :

The RA-02 Module (SX1278) connections to the ATMEGA328p is as follows:

NSS to D10 (CE)

MOSI to D11 (MOSI)

MISO to D12 (MISO)

SCK to D13 (SCK)

RESET to D9

DIO0 to D2 ( We need a hardware Interrupt pin ).

DIO1 to DIO5 was not broken out on the current version of the LoRa Base Module

There is also no direct access to pins D10, D9 and D2 either on the LoRa Base Module or on the Input and Monitor Shield.

If you do decide to hack the device and add access to any of the non broken out pins, please remember to use a logic level converter between the ATMEGA328 and the SX1278, as they operate at different voltages, and the SX1278 is not 5v tolerant on any of the IO Pins!

You can order this shield from PCBWay by clicking here

4) Click on PCB Instant Quote

5) If you do not have any very special requirements for your PCB, click on Quick-order PCB