New Radios, higher duty cycle, more reliability!

With the rework underway, and additional time on my hands, I looked into dumping the conversion of commercial radios for a home brew replacement. Most repeaters I have worked on, use either a commercially purchased repeater, and you mold it into what you want, or some convert older Motorola Micor, or  Maxtrac gear. While these work, and you can certainly turn the power down for better duty cycle on the commercial gear, there are a few problems.

 Obtaining the gear. Usually you have to search out Ebay, or a reseller, matching serial numbers so you get the right band, then hunting down someone to do the conversion, or if you are lucky enough and have the test equipment, doing it yourself. I have neither readily available to me, so I decided on another route. Even my local Motorola shop has closed.......Im in the middle of a rural area, Im out of options going this route. I do have some test equipment I can borrow, but this is even limited.

 The solution:

I did some research, and while its not totally perfect, it will work, and indeed it does! It will take a little extra filtering, and a look at some preselectors later, but its been fun learning and designing the replacement.   Meet the DRA818V/U

 This module is a fully functioning UHF or VHF radio commonly found in the Baofeng and other Chinese ham radios. Yes, I know what your thinking, Chinese knock off, it sucks. I happen to own 2 Baofeng UV5RA handhelds. While these dont have all the bells and whistles of the " big 3 radio companies" radios, the general opinion is they do work, for what they are used for, short, mobile handheld communications.

The modules though are available commercially to folks that want to work with them. What others have found out is that while the T/R switch in them isnt the worlds fastest, and there are no output filters at all. They can be used if you are willing to take the extra time and work with them. I decided that one could be used strictly as  a receiver, and the other as a transmitter for the repeater. They were going to need massive amounts of filtering, and even more amplification, but at least they were cheap and easy to obtain, fully programmable with Linux, and if they blow up, who cares, for 15 bucks, get another one.

I decided to use these at full rated power. That is simply 1W RF......driven at full output has a cleaner RF output, and pulls a whopping 350ma of current. Ok I sent in an order. By the way there are vendors on amazon, and while I have no stake in Amazon, you can get them fast and if there is a problem they have a return policy....perfect.

I did more research, and a fellow ham W0ANM has already made some leaps and bound using these modules, as well as KP4TR and WA3DSP. Many have designed nano nodes for use with Allstar, and these are great starting point. Look these guys up, they have plenty to read and have done some of the work already.

I set out to design my own radio module. With a basic working knowledge of the module I was able to come up with a small easy to construct design I liked. Initial test were good, and I am still playing with the setup.

The top is the first generation board. I have since revised this to allow for even better filtering. The module is easy to use and the schematic is really straightforward. There is really not a whole lot to discuss here other than the COR( squelch) circuit.   Q1 and T1 make up the squelch circuit. When a signal is received, you will get two outputs, why? easy of use. I made it so that you can have either a HI( 5V0) output for COR, or a LO ( 0V0) output depending on your needs. This eliminates the need for further conversion if you needed one or the other type of signal. All of the signals, PTT, CORs, Audio out and MIC in are all available at the small header on the right. The other header is just for power. Power is 5V0, a diode knocks this down to 4V4 volts since the module uses 3.3-4.7Vdc. The header at the top is for connecting a 3.3V FDTI module to. This is the programming connection, and is a simple 3.3V serial connection. For programming the module all that is needed is a computer USB port, the FDTI module ( 3.3V) and the connection to TX/RX and a ground. For programming the module for your frequencies, W0ANM had a easy to use python program. Its available on his website, just goggle W0ANM.

Filtering:

The modules alone when powered up have terrible harmonics. The second harmonic usually shows up about -30dBc and the third and fourth arent far below that in power. This is totally unacceptable. At worst case, something on the order of -60dBc would be a starting point, and -70dBc would be better, heck no second or third harmonics would be great but this isnt the case.

On the web there are many great free Chebyshev low pass filter calculators. I opted for using a 5 pole Chebyshev for the first generation boards. This consisted of 2 5pf and a 11pf capacitor sandwiched with 2, 22nH coils. I chose in the first generation board to use chip (SMD) filter parts. I  used 805 SMD chip parts, the next generation will use 1206 smd chips, and Im considering just chip caps and hand wound inductors, that has yet to be determined. In any case, the low pass filter worked really well. I measured the second harmonic at -67dBc, and the third and fourth harmonics were really not even hardly noticeable on the scope. Im pretty certain that this setup will not tolerate a huge amount of usage, but the first generation board is a prototype, not a final production model.  Also note, the prototype board is designed for a 7 pole low pass filter. I added this in case I wanted more filtering or the 5 pole wasnt enough. In the end I bridge soldered the last coil pads together, and omitted the last smd cap.

There is a 1206 LED used for both power, and SQL, for visual indications only. These can also be omitted if you want to further reduce power consumption, its your choice. I like to see when things are working, and Im a big believer in smd LEDs for this purpose. You can troubleshoot a pieve of gear pretty fast simply by knowing the gear, and looking at the indicators.....its always the first place I start, that and meter readings.

Thats the transmitter for now, it will be improved. I have the receiver done, and more test on sensitivity and a preselector design are in the works. More on those, as well as the 30W amplifier design will be posted later.

In the meantime,

Happy Coding!

Behind the scenes, work continues

So life gets in the way a little, thats normal. So goes it when you are working on projects. For me it seems I get started, then have to put it away for a while, and come back, such is the life story of the Repeater Controller.

So I had the prototype working, and it was ok, the boards I designed worked, but there is always room for improvement. I petitioned the University I work for to start a Maker/Radio Club, and asked if the repeater could be located on campus. Initial indications were that it was going to move forward. They asked me questions about the installation, my network needs, and initially rejected my request for space on the old club tower. I replied with a new location on the same building, and told them I would reduce power, and monitor for interference. If any occurred, I was already prepared to deal with it. All indications were they committee was happy, and then the President retired, a new one was sought out, hired, and everything fell through. Its been 5 months now and I havent heard anything from the committee. Im thinking, my request has been scraped. Its ok, Ill move forward, I still have a couple of options, back in the town I live in, that havent been explored. The University location would have covered both cities with minimal power, and ease, but I will now have to look into other avenues to cover the area I want.

Old Board, New Clothes:

The old design hinged on the use of the main computers parallel port. While this worked I did discover that parallel ports are tricky, especially if you accidentally send it a wrong signal, or in my case cross a wire. On the old computer I was using, I did this while wiring up a header connector, hence I lost that input on the parallel port. Not really a huge thing, but got me to thinking. I was using alot, I mean a lot of header connectors. I decided since the committee, was dragging their feet, or just plan quit on me, it was time I addressed that problem. Hence the next generation of boards. What started as fixing just a connector problem, blossomed into a full blown rework.

New Main Board

Old Main Board

The old board had everything external to it. There was the radio interface board, and the computer interface and tons of just boards, and more boards. What I did was reduce the clutter, and take those boards and incorporate them into just one board, complete with its own controller, and computer interface. As you can see by the top  picture, at the top of the board,  there is a radio interface port. This takes the old radio card, and puts it on the main board, its just plug and play. I also dropped all the extra channels. There is a interface for the repeater itseld, and just one other radio, whether it be a control link, for split site operation, or just another remote base, but the two additional radio ports were dropped. If I am having trouble getting a site for just the repeater, Lord knows I am not going to get a site thats going to allow 2,3 or even 4 additional receiver/transmitters.

All of the radio headers are now reworked and use the DB9 connectors at the bottom. All of the signals are routed through here ( COS, PTT, even a 5Vdc and a Ground, should an external key signal be needed. This removed 4 multiple pin header connector from the original design. Power supplies were removed and added externally to this new design. I reused the old supplies from my car project, just ordering more boards, and parts thus saving a ton of space.

Also I switched computers I am using. The new design uses the BeagleBoneBlack Version C as the brains of the controller as opposed to a full blown PC board. This saved space, and allowed the use of USB for signalling which Ill discuss in another blog. By doing this I saved power, space and time. Also by using the BBB VerC, I was able to get rid of some of the signaling ICs, and allow the computer more control, instead of having the computer tell the Arduino what to do. I still use the arduino to control some functions, which Ill get to later, but the use of the BBB really streamlined things! With all of this, cost was also reduced. Original boards for the old system were over 30 dollars for 3, making them a little over 10 bucks a piece, the new boards were just 15 dollars for 3 and cost 5 dollars per board, a 50% savings.....not big bucks, but hey I can buy more parts now.

Thats about it for the new main board design. Its working like a charm, and has added features as well which Ill outline in another blog as well. So work is continuing, and coming along nicely.

Happy Coding!

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.