Forum Replies Created
The should be entirely possible with the current cofiguration without any modification of the code. This would assume that you’d be using one unit/band as the input frequency and the other unit/band as the output band. This is what I would refer to as a “one-way” cross band setup. It would function much like a regular repeater…just on two bands instead of with a offset frequency within the same band.
You can also do this on a single port and treat it as a regular repeater within ORP. You would just need to make up a DB9 splitter cable from the Pi Repeater 2x port 1 that splits out to the two radios…1 as an input and the other as an output.
I have given this some thought before but have never gotten around to testing in the real world. It would be great because you could use a diplexer for filtering and using a single dual band antenna instead of using larger duplexer cans. It would make it more portable. Then you would just set up your dual band HT to transmit on the one band and receive on the other band…very similar to how you’d communicate with a satellite on two bands. Hope that gives you a good starting point.
What would be the use case. Auto patches seem to be lesser and lesser used as time progresses. Their heyday was before cellphones became prolific. I don’t think I’ve see much talk about auto patches over on the SVXLink side of things.
SVXLink does have a variable called DTMF_MUTING. ORP enables this by default (hard coded). You could modify some PHP code to disable DTMF_MUTING and make it pass the DTMF. It would be an all or nothing approach…On or off. Once version 3 of ORP is released it will included overrides to make this easier.
As for muting this on the RX side for both the main repeater but not on a simplex link, I cannot think up how to achieve this or if it would be doable.
My test setup is down at the moment so I cannot dig in too deep at the moment. I was thinking that it might be one of the sound files. I browsed through the sound files and SVXLink doesn’t appear to be playing a “beep” sound from what I can tell looking through the sound folders for “core”, “default”, and “echolink”. If that was the case I was going to suggest you just replace the sound with a silent file. So that leads me to believe that it would be generating the beep using synthesis. So my next guess would be that it is would be in a TCL file. So probably EchoLink.tcl or ModuleEchoLink.tcl. I cannot recall the exact path to those files a the moment. However, if it is not in their then that probably means that it is in the compiled C++ code that SVXLink is written in which would involve digging that up in the code and recompiling SVXLink from scratch.
You may find an answer over at https://groups.io/g/svxlink. Let us know.
Yes…sort of. This has actually been in the works for a while. This was first added in the 2.2.x development version (non-release version) in the backend. This version is the precursor to 3.0. So it is also in the 3.0.x-DEV branch also, but it can be configured via the UI in 3.0. 3.0.x-DEV is still a development branch and there are a couple items that haven’t been ported over to 3.0 UI that are still in progress, but we are getting closer on that. Both these versions are development branches which means there is currently no IMG file offered for download to build one of these versions you need to start with a fresh install of Raspberry Pi OS (ideally the lite version) and then run our build script on it. 2.2.x is fairly stable and has the old UI, but to get the DMK-URI to work you would need to edit a little bit of PHP code once and run it which will inject the settings into the database. This is typically a one time thing. Not sure how savvy you are with that, but if you are interested, we can certainly point you in the right direction. We can even invite you into our Slack group if you would like to help with testing of the DMK-URI or 3.0 as it nears completion. But support is on it’s way for the DMK-URI as well as the Repeater Builder USB-RIM
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.