Sorry for the delayed reply. From what you are describing this sounds like normal behavior for ORP version 2.0.0 thru 2.1.3. Understand that when you have 2 (or more) ports the anything above the first port will be added as a simplex port and all the ports get linked together. This would match the behavior of what you describe. Port 2 will behave differently that port 1 because port 1 is full duplex logic while port 2 is simplex/half duplex logic. In these versions it is kind of limited for options and was set for more of the common options. It is/was sort of a long term work around until other linking and logic options could be implemented pragmatically.
If you are looking for a different configuration, then you would have a few options. You could do a custom build of the 2.2.0 development versions off of GitHub. There is no downloadable IMG file for this version. Build details would be in the readme of the associated 2.2.0 branch of the build script. This has updated logic and an updated DB, but no updated UI yet. You can make it do different options, but it involves using some temporary methods of pushing settings into the database with PHP arrays, so some programming knowledge would be required. Version 3.0.0 is going to have a redesigned UI that will build upon the 2.2.0 development structure changes, but that has been in progress for a while with no set date on when it will be completed.
The other option would be to hack the PHP code to your liking on the 2.1.3 release. There are a couple files that are used to build the configuration used by the SVXLink core. The other option is to just use straight SVXLink if you have very specific need, but you would loose all features that the ORP UI provides. Hope that helps some.
Hoping your were able to have success.
This is currently a function on the SVXLink side. I’ve not found any way to connect into SVXLink to acquire this info. It would likely involve some recoding on the SVXLink side. While you can see connections on the svxlink log file, those logs eventually get cleared. I had some crude success in the past of Grepping the the log for callsigns connecting and disconnecting, but I didn’t get much farther past that. It would likely involve a parsing script to insert those into a database table for later sorting and displaying. As well as building out a front end display for it. GREPing the log is certainly not and ideal solution, so I was hoping to find another way to accomplish this.
My advice is not to set a static IP in in the Pi itself, but rather in your router which hands out the DHCP address. Leave the Pi to get it’s IP by DHCP. Then in your router, find where it currently is and map a static IP address to it. It uses the MAC address of the adapter and always hands out the same IP to the Pi. I reserves it for that MAC address.
If you must set a static IP address on the Pi, then try to run the raspi-config utility. I pretty certain you can do it under there. I don’t have access too my pi at the moment to confirm.
I am not sure what post you are referring to, but there is also this KB article as well: https://openrepeater.com/knowledgebase/topic/configuring-a-static-ip-address
I don’t know if I follow your question on a cross band option. If it is one way cross-band, then that should be no different than that a regular duplex repeater with different radio options. If you are talking two way crossband then that would likely require a two simplex transceivers on each band, each coming into separate ports on the controller and being permanently linked together. This would not be achievable in the current release image 2.1.3, but should be doable in 2.2.0 in theory. It may take a little more work to get things functioning properly with some manual configuration. Of course definitely should be possible with an SVXLink only install as well.
Bear with me as I have some family related issues I am in the middle of which may delay my replies. I’m glad you posted here in case others can assist.
As mentioned it is implement in the development branch of 2.2.x. That code base is currently being absorbed into the 3.0 redesign. So it will definitely be within 3.0 release when that is ready. It’s just slow going. If you want to help on the development side, you should join our slack group. Let me know if you need an invitation.
Looks like the rewrite ghost is back. I will have to look into that. For the time being you can certainly grab the zip files off of GitHub repos as mentioned above. Yes the Modules that are listed on ORP site are those that are considered more production ready. The extra repos on GitHub are experimental or incomplete modules. Those are not listed as it would create more support questions from users that are not coders that could be kept up with. They are on GitHub for other developers to tinker with. Should they get to a production ready state then they could be listed.
I am not sure I follow what is and is not working. If you are getting ID out of the board then that means you should be getting audio from the controller into TX. Make sure you adjust the levels if needed in the ALSA mixer for your application. Also the ICS boards have multi-turn pots to adjust input and output levels. Dan @ ICS has some videos on adjusting these over on his YouTube Channel.
I recommend isolating the radio(s) and the controller. You could make a simple breakout cable into the controller. Have an LED for your PTT line, a push button pull-down circuit to simulate COS input, feed a tone generator (could be computer/phone based) into the RX side, and hook the TX audio into powered computer speakers.
It is unclear from your original post if you are using 1 radio or 2. If you are using a single radio and operating in simplex mode, the simplex mode behave a bit differently than the repeater/full duplex mode. If you are using two radios and are using simplex mode, make sure that you have proper RF isolation. If you get stray RF into the RX radio or even the cables or Pi…weird stuff can happen. For my test rig, I have a Motorola GR1225 repeater with a tuned duplexer, but I still tend to run it into a dummy load. That not only ensures that I am not blasting the surrounding area with unneeded RF while testing, but also eliminates any RF issues.
So just to clarify some things: The ICS boards do have two logic inputs per port, a COS input and a CTCSS input which each get their own GPIO pin. The core SVXLink software doesn’t currently have support for a separate CTCSS input, so that is unsupported at this time. CTCSS should be set in the radio which will in most cases would not activate the COS/COR line out of the radio unless both a carrier is detected and the proper CTCSS tone is detected by the radio. While software CTCSS is somewhat supported by ORP, it is still recommended to set this in the radio as it is more complicated to make sure that you are getting unfiltered audio out of the radio where the controller may not be able to hear the CTCSS to do a software decode if it has been filtered out with a high pass audio filter in the radio.
For your QTY KT-8900R radio, while I am not familiar with that specifically, you may be able to hack it. One option could be pulling voltage off of the RX led, but you need to ensure that the LED behaves as desired…meaning that it doesn’t light up when a carrier is detected but the proper CTCSS tone set in the radio is not detected. There are often mods people make to cheap radios for Allstar nodes and APRS. Maybe this one would be of use: https://4x5mg.net/2017/02/12/using-qyt-kt8900-allstar-node/
There are also other cheap radios that you can get your hands on that are better for repeater use. For example the Motorola GM-300, these are older wide band radios that can had for cheap that are much superior to the Chinese radios for repeater setups. They have programable 16 pin outputs on the back that can contain a COS line, etc. Programming them is a challenge as you need a specific dos environment to do so. You may have hams in your area that know how to do this.
Hope this helps!
This is bizarre as this has been working flawlessly for a long time. Seems to be some type of encoding error. The modules files are not kept on the same server, but rather passed through the download manager for tracking stats. The files are kept on GitHub and as a work around you can grab the latest release of each of these modules here: