Hellas-Node Network. Διαχείριση ραδιοερασιτεχνικών ψηφιακών και αναλογικών δικτύων. This website refers to digital and analog networks of amateur radio applications and is in the process of continuous updating and upgrading, after being renamed to hellas-node.net. The hellas-frn network and all its pre-existing structure is included in this website as one of the supported analog communication systems, with revised management of communication rooms and in other analog networks. Recent Visits

Follow the procedures as described in the videos for each individual subject or program. Watch out for typographical errors. These are the main reason something goes wrong with the installation. Pay attention to detail. You do not move forward unless you achieve the individual result shown in the video. Don't question the instructions. All procedures have already been followed and normally produce the result described in the videos. Patience and good luck.

Click on the image to proceed AllStarLink is a network of Amateur Radio repeaters, remote base stations and hot spots accessible to each other via Voice over Internet Protocol. AllStarLink runs on a dedicated computer (including the Rasperry Pi) that you host at your home, radio site or computer center. It is based on the open source Asterisk PBX running our app_rpt application. App_rpt makes Asterisk a powerful system capable of controlling one or more radios. It provides linking of these radio "nodes" to other systems of similar construction anywhere in the world via VoIP. AllStarLink's primary use is as a dedicated computer node wired to your repeater or radio. Connections from Echolink, other VoIP clients and telephone calls are supported. Χρήστες ALL STAR LINK στον κόσμο

When you visit our website, our own web server automatically records the name of your Internet service provider, your IP address, the web page from which you came to our website, the current web pages you visit on our website, and the date and the duration of your visit. Our website logs may be used for the purpose of technically managing and protecting the availability, integrity and security of our website. Your visit to our website does not involve us processing your name or contact details, unless you choose to submit this type of information to us, for example through the contact form or the registration form for access to the communication rooms with RF. For information, useful suggestions, requests or complaints regarding the processing of your personal data or the use of our cookies, please contact us through the contact details. Cookies are small text files that can be stored or accessed by the web browser software of your Internet-enabled device (such as a computer, smartphone or tablet). Hellas-Node.net may use cookies and similar technologies to store the preferences of our visitors and optimize our website accordingly. For the sake of simplicity, similar technologies such as trackers, pixels, web bugs and others are also referred to as cookies. If you do not consent to the use of cookies, you can set your web browser so that it does not store cookies. Please note that some areas on most websites may not work properly if you generally reject all cookies. You can also use your browser settings to send a “do not track,” request along with your browsing data. Please note that our website is not currently configured to accommodate do not track requests, which your browser may send. By choosing to continue browsing our website from our home page, you consent to our website’s use of cookies. The information available on our website constitutes selfless offer of Amateur Radio service and is not a substitute for personal advice. Despite the careful acquisition and disposal of information, we do not assume any responsibility and do not guarantee the correctness, completeness and timeliness of the information listed on our website, whether it is information from third parties on the Internet, or from personal experience in theory or in practice of our members. Any liability claims against Hellas-Node.net regarding material or moral damages caused by the use or non-use of the available information, or respectively by the use of inaccurate or incomplete information, if on the part of Hellas-Node.net, are excluded. Net there is no evidence of intent or gross negligence. Also, Hellas-Node.net is not responsible for any kind of damages that could arise from the access or use of this website, since its design is based on international corporate website design standards with assistance and support for its correct operation, in combination with the online security barriers to access provided by the specific professional website design company. In the event that parts or individual wording of this text are not, or are no longer, or are not fully legally correct according to the applicable legislation, the remaining parts thereof remain intact in terms of their content and validity. Hellas-Node.net expressly reserves the right to change, supplement, delete or disable temporarily or permanently, parts or the whole of its website, without particular notice.

Click on the image to see the dashboard TGIF Means (Thank God It's Friday). TGIF net started on a analog repeater in west central Florida. It was handed down to robert around the year 2015 and grew to over 50 check ins. A small group of them went to D-Star after the repeater was taken down and then moved over to DMR where we started the TGIF net again. It then moved to the Brandmeister system and has now found its final home as the mothership of the TGIF Network. TGIF Network was started in October, 2018 by Robert (K4WZV) and Mitch (EA7KDO). They started the TGIF Network with just one talkgroup which became 31665, and about 5 Amateur Radio Operators joined the Network, at this time the system was running on a Raspberry pi. Later on, Ty (KG5RKI) came on board to help improve the hblink code it was currently running on and move it to a cloud server, then later rewrote the backend to make what was called Callmgr. Michael (K5MRE) and Andy (G7LRR) also joined the team and created many of the features we enjoy on the website and plenty more behind the scene. Over the course of the next year, the network quickly grew from just a few hundred users to just under 5,500. The network now is home to around 776 active talkgroups available for all to use. The main/original talkgroup is original 31665, and is sometimes referred to as the 'Mothership' by many. All Amateur Radio Operators are welcome to join and try out what the network offers. The Network is still growing rapidly. Recently, Pi-Star and Shark RF Openspot added the TGIF Network to their list of networks. But this tale has not ended. Around the end of 2019, Ty (KG5RKI) could see limitations to how far Legacy would be able to scale with the growing number of clients. So, Ty took it upon himself to once again use his coding skills and knowledge of digital networking and in his spare time rewrite and design a network from the roots up which was codenamed 'Prime' and was open do beta testers during development. With Andy (G7LRR) as his partner in crime against the code, and Rob (K4WZV) having his back, the team is making fast progress at creating a great solution for ham radio operators around the world.

Click on the image to proceed HBlink represents a server-side implementation of the Home-Brew Repeater protocol as defined by DMR+, MMDVM and Brandmeister. One can speak as a "peer/client" (ie a repeater or hotspot), or as a "server/master" (ie as any of the DMR networks an MMDVM device connects to). It has tools for selectively routing calls between groups of one or more devices. It can do this statically or dynamically. The number of "systems" (groups of devices or connections to other servers) and the number of devices connected to those systems are limited by the speed and size of available CPU and RAM respectively. HBlink is remarkably efficient for a Python program, and its upgrade to HBLink3 is about the corresponding use of the Python3 program. HBlink does not implement protocol translation to analog, or YSF, or D-Star or anything else.

Click on the image to proceed

Press on the image to see the dashboard C4FM C4FM stands for Continuous Four Level Frequency Modulation and is a FDMA (Frequency Division Multiple Access) modulation method. C4FM is a digital modulation technology. What your radio uses over the air to talk digitally to other digital radios and repeaters. Fusion This is the name that Yaesu has given their implementation of C4FM. The full name is really System Fusion. It is not a new technology but a marketing term created by Yaesu for referring to their C4FM. You can learn about System Fusion on the Yaesu website here: http://systemfusion.yaesu.com/what-is-system-fusion/ Wires-X Wires-X is a technology that runs on top of System Fusion. It provides a network of repeaters. Wires-X has a concept called rooms where multiple repeaters and nodes can connect and talk to each other. A room is similar to a reflector in D-Star, a Talk Group in DMR and a conference in Echolink. Wires-X provides a directory of connected rooms and manages the connections from Nodes/Repeaters to each room. In addition, Wires-X provides a way from the radio to change to a different room, search rooms and more. Some radios have more features than others because of touch screens, etc. There is also the ability to send messages and pictures, put them in a common message store on each node or room for others to read (think of news). Without Wires-X, System Fusion is just a communication protocol. YSF YSF short for Yaesu System Fusion really is not a Yaesu technology when looking at the YSF servers. It is another method of creating a room where other System Fusion users can connect together. Unlike Wires-X, there is no central management of the rooms that are up and available. There are directories of YSF servers (for example: https://register.ysfreflector.de/ and many of the digital softwares you run on your computer also maintain lists for easy selection. The important thing to note is that System Fusion repeaters cannot directly access these servers. To get from Wires-X on Yaesu System Fusion to a YSF server, you need a bridge (more on that in a bit). You can find YSF rooms connected on some repeaters that are running the MMDVM software as their repeater controller. Some of you may also know it as Pi-Star which is a pretty interface over the MMDVM software. Bridge A bridge is a way of connecting 2 different protocols or technology together. It is similar in concept to a cross band repeater that for example takes in a signal on 2 Meters and transmits it back out on 70cm. Since YSF cannot directly talk to Wires-X, there is a bridge that can talk to both YSF and Wires-X. When it hears something on Wires-X it sends it to YSF and the opposite happens when it hears something on YSF. There are multiple ways you can bridge between the networks. One method is simply setting up a Wires-X node with a radio and setting up a YSF/FCS node with a radio on the same frequency. Very similar to what cross band repeat does. There are some that may be able to make the translation using software. For example, a our XLX reflector translates from Brandmeister DMR TG 20222 to XLX165 Module B all in software digitally. It never decodes the audio. That is possible because both use the AMBE2 format. For example, if you wanted to take the same DMR and put it on D-Star you would need to drop it to audio first and back because D-Star uses the older AMBE protocol. Since Fusion, YSF and FCS are all using AMBE2, it can be done easily in software. It is possible that there is a bridge between Wires-X and YSF and then one between YSF and FCS with no bridge between FCS and Wires-X. This would mean that when someone keys up on A Wires-X repeater, it would connect to YSF via a Bridge and then YSF would connect with FCS through a bridge. It can get very complicated and it is important to remember that every bridge adds delay. Too much delay and people are talking over each other.

Command to transmit via COM port (RS 232) The following photos show how a simple adapter (interface) can be made between a radio and a PC. A 9 pin connector has DTR on pin 4 and pin 5 is GROUND. (GND) Accessories These are the components used in the circuit: R1 = 330 Ω (Orange, Orange, Brown) (Resistor) R2 = 12 Ω (Brown, Red, Black) (Resistor) R3 = 1 kiloΩ (Brown, Black, Red) (Resistor) R4 = 1.5 kΩ (Brown, Green, Red) (Resistor) C1 = 4.7 microfarads (capacitor) D1 = 1N4148 (diode) T1 = BC549 (transistor) Plugs 2 stereo plugs for connecting to the sound card. 1 sub-d connector female for the COM port. 1 or 2 plugs for the P/D, depending on its model. Settings for the FRN Client The photo shows how to set up the FRN program to send the command through a COM port. Don't forget to disable VOX on the R/D. Select "Settings-->Adapter" (interface) to open the interface menu. Alternative circuits for adapting transceivers with a computer (interfaces). 1. Simple interface for handheld wireless. 2. Simple interface for mobile or base wireless 3. Interface without common grounding (galvanic isolation) for mobile or base wireless.

Free projects are only for private use and not for commercial use. U-Ham Group have all the rights on all these free projects and could make changes at any time without any prior notice, so be updated frequently. User can use the projects at his own risk. Temperature dependent fan speed controller Schematic Features fan controller Adjustable start point Voltage operating range: 9v-15v Maximum temperature sensor cable length 1 meter LED indicator light for fan operation -------------------------------------------------- ------- It concerns a simple circuit to control the speed of a cooling fan based on the temperature measured by a temperature sensor (thermistor) placed at a suitable point on the P/D to "read" as closely as possible the output temperature of the machine. It is of course recommended to use a quality thermal paste for more reliable results. The whole circuit is designed on the property of the thermistor to change its internal resistance depending on the temperature change in its body. This one is of negative temperature coefficient -Negative Temperature Coefficient or otherwise NTC, which reduces its resistance as the temperature rises. This causes the mosfet Q1 to trig proportionally to its gate and by extension to affect the voltage of the fan and make it increase revolutions proportionally. There is a voltage threshold above which the fan starts to spin and in which the setting of VR1 plays a decisive role which creates a voltage divider and beyond that the revolutions depend proportionally on the temperature affecting the thermistor. The reverse also applies in case of a decrease in temperature. How to adjust the temperature sensor. Locate the VR1 regulator. Connect the voltage 13.8VDC and the fan as in the photo. Press the sensor with two fingers and with a screwdriver adjust VR1 until the fan is ready to start and the LED just starts to light up. Normally, this setting causes the fan to start slowly as the temperature reaches about 36°C and then increase the fan speed as the temperature rises. The opposite happens when the temperature drops and below 36°C the fan slows down until the falling voltage level cannot keep it spinning. Turn VR1 until the fan is at such a speed that it keeps the temperature at the level you want and if you want to change it from the set 36°C. Place the fan far enough away from the P/W heatsink that it will be effective, but not so close that it touches, as the reflected airflow comes back through the fan body and cancels the flow itself. Linkage (Applies to off-the-shelf device) Watch out for any mistakes especially in the position and polarity of the 13.8VDC wiring. The subpoenas can be seen in the photo. PCB The board was designed to match the specific plastic box