2 MCUs, they need to know who is doing what.........

Since I decided to palm off the networking stuff, the MQTT and the LCD messages to a small Atmega328, it will be necessary to have one MCU tell the other what it is doing. The 1284 will be switching the radios off and on, but the 328 will need to know what its doing, so it can display on the LCD the proper messages.


The are several ways to get one arduino to talk to the other. Some are basic, others complicated. In my home automation all of the arduinos ( 37 now in all) talk to each other over the network using MQTT broker. The broker keeps the messages and the arduinos subscribe to the topics they are told to....its a great system, easy fast, but would be over kill in this application. You can serially talk between arduinos, you can also use I2C or TWI. I went an even more basic route.

The simplest way to "talk" between arduinos is simply using a few digital signals. In my case to alert the 328 that the 1284 is doing something, I added  "bits" to the sketch. Each "bit" is turned high when the 1284 is doing something.

The " bits" are self explanatory. When the repeater COR goes HIGH ( receives a signal) then the corresponding "bit" is set HIGH. This digital line is then tied to the other arduino ( through a pulldown resistor) When the bit is driven HIGH, then the 328 knows the COR is HIGH, and executes the appropriate code. This was the simplest way to tell one arduino what the other one was doing and keeping it basic.

Sketch thoughts

With the prototype boards back from the fabricators, it was time to finalize the firmware that I was going to use. For me, the term finalize is written in jello, as Im constantly tweaking until I get to the point that I have to say enough, and go with what I have.

Planning for the firmware is the hardest part for me. Im not a programmer by trade, but by hobby. I can look at code and figure out whats going on, I can visit forums and see what people are doing, or even track down a snippet, and work with it to get what I want. Most of the time its not pretty, I have to do a lot of revisions, but then again this is for me, so who cares....but me....

The barebones sketch easily fits on a Arduino Uno and runs about 6K for memory. This is the basic part that does the switching. If it senses a signal, then it acts on that based on whats programmed to turn things off and on, as well as run the front panel. Most would say that if this is a repeater, and located in a building, say on the top floor in a obscure closet, why bother with a front panel at all, and this is a valid argument. My point of spending the extra time and money comes when you need to go back to the site to do maintenance, or there is a problem. So many repeaters I have worked on have a COR LED (maybe) and maybe a power light.....not much help when you approach a system cold and want to fix it. I like to take the extra time to provide the tech with something he can go on. I also provide a means to turn it all off. That is, when the tech leaves the site, he can kill the front panel, and turn it on when he returns.....its a visual aid, and one I think is well worth the time.

I ran into a problem, of sorts...I dropped the MCU down to a Atmega1284 to reduced the physical number of pins needed to solder on the TQFP package. It has 23 digital I/Os for use. With all the front panel indications I had, that was 13 digital pins used. Now when you add in the LCD screen, that removes 2 digital pins ( SCL, and SDA) if you are using I2C, a total of 6 if you use the parallel option for the LCD, and 1 if you use the serial option. Also there are digital sensing lines for PTT and COR for the repeater, the Control Link, and any additional remote bases, and you see that we quickly run out of digital pins on the 1284. Its true that you can use the Analog pins as digital inputs and that gives us an additional 8 pins to use, but also remember that I wanted to do some environmental monitoring, and analog pins would be needed for that. Finally throw in the need for either wireless networking or Ethernet, the MCU would need at the very least SPI to run say even a small Ethernet based shield like the ENC28J60.

 Basically it came down to, with expansion in mind, front panel indications, and the future need for networking, the 1284 just ran out of pins.....so on to solution number 2. I decided to pawn off all of the networking, the MQTT monitoring, power supply monitoring to a small Atmega328P-AU. This is the reason I designed the smd version of the 328. Yes I know, why have 2 MCUs when you have a computer and the availability of larger MCUs like the Atmega2560 family...and it came down to ease of maintenance, and reliability. Remember too.......this is a prototype, if it doesnt work out, then look at the design and find a solution. If that happens and the solution forces me to go with an Atmega2560, then I can design a board and go that route. Right now though, I have all the MCUs I want, and the boards were easy to design and low cost, so for now Im going this route....remember..again this is for fun, Im not building a governmental radar outpost in Alaska.....

Ok so I have a direction. The 1284 will handle the switching and the front panel, the 328 will do the network stuff, the MQTT stuff and run the LCD screen, sounds complicated but really it basic.

So now to the basic building block of the sketch that switches the signals and the front panel indications.

This is the basic routine for the repeater and even the link and remote bases. Basically we are are checking the state of the COR line. If that state is HIGH ( receiving a signal) then we jump into the loop, turn on the front panel indications, and print to the LCD screen and remain in this state for as long as the COR remains in this condition. The reason for this is the "while" statement. This keeps the sketch from leaving the loop and going on, thus causing all kinds of hate, and discontent by blinking the front panel LEDs each time it comes back to this part of the sketch, and messing with the LCD screen. Its true, some will look at this and say, you can write less code using SWITCH CASE, but Im old fashioned, I still like my if/then statements from my old BASIC days, and well old habits die hard for us old guys....Also note, and I havent gotten to this part, that the Node computer is also switching radios on and off because it also receives the same signals, but the node and the MCUs are isolated, so if the node sends a HIGH out on the repeater PTT line, and the MCU does the same, the PTT line simply goes HIGH, which we want. Youll also notice that in this first revision, I told the MCU not to switch on the repeater PTT Line when the COR goes HIGH ( RPTpttOUT). This was for testing allowing the node computer to have full control of the repeater so that the courtesy tones would be present, later versions I told the MCU to switch on this line too.

The following video shows what Im talking about. Here the node computer is receiving a signal, and the MCU is switching the ( what will be) front panel LEDs on and off. You can also hear the courtesy tone as well. All the PTT LEDs are green.

Time to Roll your own..........

I love circuit design. I can do it all day and enjoy the reward of having a functional design that looks good too. Its sorta like making an art project, except mine are usually never seen, unless you lift the lid........

I realized that I was using my arduino commercially purchased board as a test bed. While this works, really makes no sense to use it in the final prototype as it just ties up a board I can really use some place else for testing, hence time to roll my own.

I had been using the Atmega Arduino 2560 board as a test bed. While I love this board, it used for playing and testing not for final projects. I did a little digging and really designing a arduino compatible board is pretty simply, and there are so many different types and sizes to choose from. I had been using a breadboard version of the Atmega644, primarily because I had it, it has 23+ I/Os and 64K of memory to use. I have used virtually every MCU out there from the atmega2313, to the Atmega2560. I looked around and decided the Atmega2560 was good but with all the 100 pins to solder, and they only came in TQFP flat packs I looked at perhaps going a little smaller. In all reality the 644 is a good chip, but its kinda funky. I use it and just ignore the funky stuff...by funky stuff I mean it was originally used in 3D printing in the early days....and quite frankly it was passed over rather quickly when the Atmega1280s came out, which was in the same package but had double the memory (128K).....I decided to stick with the ATMega1284. It is available in both the TQFP package and as a 40DIP. I have both.

Most that I have found dont come with a bootloader either, which in reality doesnt bother me as the 644 didnt have one either, I just used ICSP. I have gotten so used to using In Circuit Programming that I really dont care about the bootloader and it gives me an additional 2K of memory that the bootloader would have taken anyway......

Generation 1 of the 644/1284 arduino compatible

The board works nicely. Its just 2.4inches long and 1 inch wide. There are again no USB ports but a hardwired ICSP port. You just need RESET, MISO, MOSI and SCK to program this chip. Its 12Vdc power in is knocked down with the use of a very nice and more robust 5V LDO regulator. This VR has about twice the required heat sink area since I used both the top and bottom layers on the board and the plated through holes allow heat to travel between the layer and air to pass through the holes....I wished I had thought of this, but I didnt....but it works really really well for very little space needed on the board. You can still feed 8V in which I probably will, but this board will take the full 12V if desired.

I went ahead and designed the 328 board as well. I did one in DIP and one with SMD. I did this because there is a need for it in the project that you will see later, but Ill show the two designs here

The top one is obviously the smd version and the bottom the DIP. Again with the larger heat sinks and the plated holes both of these will take 12 volts. Also to note all of these are wired for power indication, the smd versions are all one .8inch header centers, and Digital Pin13 is hard wired with a LED for checking things....if I have a problem, to eliminate the possibility that the MCU is bad I always load the "blink" sketch......this will cause D13 to go high and low, and the PGM LED will then blink....saves time and heartache.

So there you have it the roll your own versions of the MCU for the controller. Now we can get to the firmware.........

Repeater Controller Prototype 1

After prototyping the older versions is was increasing evident that the whole thing needed to expand a little more. After finding out that to add some additional circuits, version 10 sprang to life. This was the first real prototype that started taking all my considerations into account.

New for this version was radio modules that had 2 radios per module. The reason I did that was it was easier to build the little larger module, using the designs I had tried before, and expansion was always in the consideration. This way I could simply leave off all the remote base(s) and just have one module installed which did the repeater control and the link radio for over the air control as well. If I wished to add a remote base, then just add a module. Here is the expanded radio module

In the earlier design I had the modules plug into the main board, I dropped that idea due to space considerations. The board, and the modules were simply getting too tall for a 2RU enclosure, which was the biggest I wanted to use for this first prototype.

I also stuck with the use of robotic headers. The reason I liked these was one, they were easy to obtain in bulk, I can remove and replace wires at will, and the were easy to cut. If I needed only 7 wires in a connector, I could use two 4 pin connectors and simply cut off one of the wire positions on one, sand it a little and it looked good. I bought these at Pololu in Las Vegas. They were fast shippers and had a wide variety to choose from, but there are lots of vendors out there for these headers, and I have no stake in Pololu, they were just the best for me.

So version 10 main board......

Version 10 incorporated for the first time both the computer port and the MCU port. I had started using the Arduino 328 ( UNO R3) in version 5 but switched to the Arduino Mega for version 10. I simply needed more input and outputs and the Mega fit the bill. As you can see in the design this version not only included the ability of the MCU to take over for the computer in the event of a computer failure, and keep the repeater going, but it also keyed all of the radios when asked to. This design also was the first time I decided to use a IPS ( or intermediate power supply). I dont like feeding the arduino 12VDC, as the SMD voltage regulator, can handle the step down  in voltage, but I found it ran hotter than I like. I really dont want to be changing out voltage regulators. Im also looking longevity. I took the 12Vdc, fed an 8V LDO VR and then fed that to the 5V LDO VR. This gave me 5V for logic gates, and I fed the Arduino the 8V for its operation. Since it has a on board voltage regulator, 8V knocked down to 5V allowed the voltage regulator on the Mega to run all day and never get hot...problem solved

Version 10 also has the MCU and the node computer running basically in tandem. If the computer fails for whatever reason, the MCU could care less since its already switching signals as the computer does. I used diodes to isolate the computer and the MCU signals from back feeding each other. Also I sent out 5V and a additional ground to the actual radios. I did this in case in the the future a relay was needed, or monitoring circuits needs voltage, then the 5V regulated power was already there and could be used.

The board design were sent off and came back looking nice. Here is the final layout of the design board for the main board

With the modules not piggybacked on the main board the use of the additional ports was needed. This is where the headers really aided in the mock up of the design.  Here I was working on the firmware and just needed to check out the time it took to loop through the sketch. But, it works and the headers make it fast and easy to throw something together and test

I had also started looking at what I was going to do as far as the face plate and the indicator lights and statuses was concerned. Here I have the LEDs mocked up for the COR and PTT lines from each radio. With all of the initial testing done it was finally time to think about what the MCU was going to do, so time to look at the arduino sketches and the microcontroller

Initial version and ideas

So I had the concept for this project. It had a goal, it had a way of achieving that goal, all that was needed was everything to get to that goal......so the planning begins

Amateur repeaters are really cool. Basically I have been using them for some 30 years. The concept is simple. A repeater does what the name implies, it repeats. Basically its two radios, one receiving on a fixed frequency, the other transmitting on another fixed frequency. When the receiver receives a signal, it tells the transmitter to turn on thus taking a signal on one frequency, and repeating it on another frequency. Repeaters can be in band ( working on 2 different frequencies in the same band) they can be cross band ( listening on one frequency in one band, and transmitting that audio on another frequency in a completely different band) they can be connected to a remote base radio, they can do lots of fun things.

I am building an in band repeater, with plans to attach a remote base. All of this needs to be figured in the design considerations. WAY easier to design with expansion in mind, than to try and add on later. For a few extra bucks in parts and pcb board area, its just easier to consider it now than to add it later.

The first design was with expansion in mind and built off the circuit designed by Kyle Yoksh, K0KN. His design was to use the parallel port on the node computer as the interface. I liked this idea for several reasons. One, if anything were to happen to the port, you can always add a new port and tell the computer to use the new one, so, if it blows up, its not a lost cause. Second his design was simple and easy to understand and use. Im not totally against using other folks designs, but I like to use their concepts and build my own ( the basis of open source hardware, anyway, right?) So I looked at what he had come up with and decided to embellish, but I give credit where its due, hence Kyles mention here!

This was the first adaptation for the controller. I decided to make everything modular, so I could plug in and take out what I wanted. The is one of the earlier examples of the radio module. Except for the addition of the 74LS00N, for inverting signals for later use, this is Kyles basic COR and PTT circuit. I did add a really simple power supply, and a connector. I tested this and it worked well on the parallel port. I used this design then as a basic building block.

The other part of this is what I call the " Main Board". This board I am going to use to route signals between the various modules. The early version of this also worked well, in the initial test.

This is version 2 of the main board. Basically the radio modules plug into the respective connectors marked for each radio ( RPT, CNTRL, AUX2 and AUX3) each port than control its respective radio or in the case of the RPT module, it received COR signals is sent that to the node computer, which in turn sends out a PTT signal to the repeater transmitter and keys it. While this design also worked, I discovered a flaw. One of the design points was if the node computer went off line, then the controller would keep the repeater going. In this design, somehow I got lost, and that feature wasnt added, but again these were early designs, and by no means a finished product......so off to revision 3....

Repeater Controller..........the beginning

So its been quite a while since I posted. The Home Automation project isnt dead, in fact its on version 4 and works nicely. I finally was able to mock up the engineering network and everything worked as it should. The light controls function as they should, along with the heating and cooling controls. What I have done is placed the project on hold, until I can purchase the land and get the house construction going.

So...I turned to another project that I had been mulling around for a while. I have always been interested in the digital mode of my other hobby, Amateur radio. I especially like the UHF and the higher bands. Since there seems to be little in the way of activity in my area, I thought I would see about building a repeater and linking it to the rest of the world through VOIP, voice over IP. I made some observations and settled on using the Allstar Link network.

The first part of the project I obtained a node number and got a local node working. This was a computer only node, no radios were used. Just using my android phone, I was able to talk to people all over the world on the network, this had possibilities. I thought if I could incorporate this into a repeater and use the network to get local amateurs to use the network, then I could increase interest in the bands...........so the planning began.

The repeater need not be powerful. Something on the order of 20 to 30 watts, in a decent location with either piped in internet ( Ill get to that) or internet service at the site will work, I can do both. It was to be a local repeater, not something that covered 50 miles in every direction, but something manageable, something that didnt bust the bank, and something that one person could design, build in stages, have ease of maintenance, and be micro controller(MCU) controlled.......

I already have the computer node working. The node in fact is located on the Allstar Network, as Node 41144. Currently there is no RF attached. I wanted to test out the node, and make sure in fact that it was reliable. In the last 9 months, its basically been off twice, both of these were power outages at my house, and it required human intervention to bring the node back online. Ill correct that problem once the controller is built.

Most Allstar repeaters dont have a controller at all, or they use the node computer in conjunction with the existing repeater controller to make the system work. Some Allstar repeaters dont even have Allstar node located at the repeater site, some are linked to Allstar via a link node. I wanted everything together, which brought up an interesting point. With the Allstar node, you can use the node itself as a repeater controller, and they work well. I wanted to incorporate the node and a repeater controller in one, and make the brains of the system using an Arduino. The reason I wanted to do this, is several fold........

    1. If the Allstar node were to fail, the repeater would still function without the VOIP link
 
    2. I could remotely control the repeater over the network using MQTT

    3. I could monitor almost anything using MQTT, like power supply voltages, temperature, radio     heat sink temperature, outside weather conditions and alike

    4. Anything arduino controlled is just plain fun to mess with........

With all of these points in mind I sat down to design what I wanted and to see where the potential bottlenecks are, design issues, and firmware problems would be. All of these issues had to be worked out, so the fun begins.