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.
No comments:
Post a Comment