CAN-BUS - Maker and IOT Ideas

ATTiny1616 Can Bus Controller PCB

Introduction

Over the last few months, we have been working on several prototypes, and some of our regular visitors may recognise some parts of this PCB. But let us begin by telling you what this is about.

As many of you may know, we have already designed several Can-Bus-related development boards, including one based on the ATTiny1616… So why the repeat then? Well, in some of my previous projects, I hinted at combining a buck converter, boost converter, lipo cell charger and Ideal Diode circuit into one PCB. I did at that time not tell you why.

To make a long story short, this project will eventually be used in my car, to provide more modern cabin lighting, which is quite a bit more than the standard on-or-off and on-when-open-the-door, off-when-close-the-door type of thing…

I own an old Honda City that I use mainly for a run-around to and from the farm, as well as seeing clients… Roads are bad, and this older car (actually quite old – 22 years) is the most cost-effective, in terms of being able to repair by myself, and not be worried about it if it gets a bit abused.

Unfortunately, the technology in the car is dated… a single yellowish cabin light right in the centre of the cabin – and not bright at all. Having to use the car at night, and then frequently scratching around in equipment bags when arriving at a client, becomes a pain with bad light… So I have decided to give it a bit of an upgrade and add CAN-bus-controlled NEO-Pixels to the cabin. For now, let’s say three sets, left, right and centre of the cabin. I also prefer a red light at night over white, especially if I have to drive again soon afterwards – a simple remnant from my days in the military, where it became quite clear how white light can temporarily damage your night vision.

NeoPixels can also be dimmed/brightened and seem relatively inexpensive.

Let us take a closer look at exactly what I want to do…

Powering the module

For the sake of clarity, this particular module will be installed front and centre in the cabin, just behind the rearview mirror. It will control two sets of 8 neopixels ( or up to 12 per module ) on two separate PCBs, which will cover the driver and front passenger area of the cabin.

The module will be powered by the vehicle’s 12v battery, as well as from a single 18650 Lipo cell. This means that we would need some clever tricks, in the form of a buck converter to step down the 12v to 5v, a way to monitor and recharge the lipo cell, a boost converter to boost the lipo cell voltage back up to 5v as well as a voltage “OR-ing circuit” to prevent reverse charging the lipo cell etc…

In its current state, the PCB is to be considered a test rig, since I have quite a few unknown variables that need to be thoroughly tested before actually installing this thing into a vehicle.

These are :
1) I would like to know if the ideal diode chip that I used functions well when used in a parallel setup, The reason for that is, that a single chip is capable of just about 1A of current… thus, in my reasoning, placing 3 in parallel would give me the 3A capability that I require – Let’s see if it does…
I could also not get hold of a suitable 3A capable ideal diode chip that was cost-effective, or did not have some strange MOQ or other logistics issues ( Yeah, seems like getting some stuff in SE Asia is difficult unless you are willing to pay unnecessary “special” charges and import duties etc … Element14 ( not sponsored) seems to have a limited selection of ideal diode solutions, but their pricing is good, and there are minimum hassles with shipping etc… I don’t bother with the other two big suppliers, D…. and M…. as they have too much red tape for a hobbyist to navigate to make it cost-effective to shop from them.))

2) Providing that the ideal diode solution does work as expected ( on the PCB) – having tested it on a breadboard seems to be working fine, there is the issue of monitoring the lipo cell, getting it charged, controlling the boost converter to provide power when needed etc…

All of this means that all the separate circuit modules on the PCB can be enabled or disabled by jumpers, and later, if all works as expected, maybe by another controller PCB… Who knows?

Getting back to power the PCB, I have used my standard buck converter circuit, based around the MP9943. This circuit seems to be very reliable, provides enough current, and is cost-effective.

I have also provided an auxiliary voltage output ( 5v) and some telemetry and control capability to the buck converter circuit, in the form of an enable-disable jumper, and the PG signal from the chip, to maybe be interfaced with a microcontroller later.

Charging the Lipo Cell

Once again, I made use of an existing circuit, with which I have had a lot of success in the past. This circuit, based on the MCP73832 from Microchip ( not sponsored) served me quite well in previous projects, and is once again, cost-effective and easy to implement. One negative is that they do seem to be a bit finicky, and not extremely robust – but when they work, they excel at it…

Once again, I decided to provide control logic to enable or disable this part of the circuit completely if needed.

Supply “OR-ing” circuit

This is the most experimental part of this entire circuit board, since, as mentioned above, the MAX40200 is rated at 1A maximum current. It is tiny and cheap, and also readily available… I am hoping that by using them in parallel I can achieve my goal of allowing the full 3A of current to flow from the buck converter, without releasing any “magic smoke” or other issues…

While, at the time of writing, I have not yet received the PCB, I am positive that all may just be fine, it remains to be seen how this will turn out during actual testing of the board.

Note that I have used a total of 6 of these, U8 to U11, with 3 per “voltage/current supply” channel. J3 and J4 are used to enable or disable the two supplies, with J3 being the buck converter input, in turn, powered from the vehicle 12v supply, and J4 begin the output from the boost converter, powered by the Lipo cell.

Boost converter circuit and MCU power

The boost converter is based on the MP3423, also from Microchip ( not sponsored). This circuit also performed very well in my initial test projects, with the only issue being it extremely tiny footprint, which really makes it quite difficult to use in a hobby environment, even with hot air and reflow equipment available… It is however also quite cheap, and readily available…

J5 provides enable-disable control to this part of the circuit.

With this relatively complicated power supply circuit, I thought it necessary to be able to completely isolate the ATTiny1616 and other integrated circuits from any power until I am completely sure everything works as planned…

J6A and J6B thus form a complete electrical isolation “breaker” that will prevent any voltage being provided to the microcontroller and other components on the PCB. I have doubled up on these jumpers, to allow for sufficient current flow, since I plan to use quite a few NeoPixels on this PCB… With up to 60mA of current required per pixel, that quickly adds up…

Voltage monitoring

Provision was made to monitor the output voltages of the Lipo Cell, and buck and boost converters by using the analog inputs on the ATTiny1616. These can be selected by setting the jumpers on J9, J10 and J11

Alternatively, the analog inputs can be used for other applications be leaving the jumpers off, in which case these GPIO’s will be available on H6 as PA4, PA5 and PA7

The ATTiny1616 microcontroller and UPDI programming port

The heart of this PCB is the ATTiny1616 microcontroller, (microchip, not sponsored)

I decided to use the chip once again due to its low cost, as well as the fact that I do not need a very powerful processor for this application. The only issue is that requires UPDI programming. In my case, I have had no issue with that yet, but other readers did mention that they had issues with them…

The UPDI header is at H1. This header can also be used to power the processor and other integrated circuits on the PCB independently from the Power supply, like in the case where J6A and J6B are left unconnected. This use case will provide me with more testing opportunities to test the board without possible variables from the power supply circuit(s).

Peripherals like I2C and the UART were broken out onto headers H3 for I2C, H4 for UART. These can also be used as GPIO pins ( remember to disable the I2C pullup in J1)

CAN-Bus Support

CAN-Bus support is provided by the MCP2515 (U2) and TJA1050 (U3) chips.

With access to the MCP2515 GPIO pins on H5. J2 is a 120ohm termination resistor, usually enabled at the start and end of the bus to prevent reflections.

CAN-0 is connected to the bus.
An additional 12v input/output header is provided at H7

NeoPixel Header H2

The NeoPixel strips are connected to H2. They are controlled from GPIO PA6 on the ATTiny1616. I have designed around a total of 24 of these at a maximum, with a total current requirement of 1.4A ( 24 x 60mA max per pixel / 1000 = 1.44 A) .

One important fact to know about NeoPixels is that the consume about 1mA per pixel even when in the OFF state. This is due to the internal control chip requiring power to operate. While 1mA bay be a very small amount of current, a lot of them does however quickly add up, and can thus potentially drain a battery completely over time…

To prevent this from happening, I have included a PMOS switch on the VCC pin at H2. This means that no power will be fed to the Neopixel strips unless you specifically pull GPIO PC1 low.

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 who will do his/her best to resolve your issue as soon as possible.

Find out more here

Assembly and Testing

At the time of writing, the PCBs were still being shipped to me. Once I have received and assembled them, I shall publish a follow-up article specifically focused on that.

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.

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

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.

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.