So it was a rainy day...and just built up an ASL3 on a HP thin client. That works fins as a repeater controller. I can connec to it from another node, no problem. So decided to see about remote base. And control of my FT-1000D. I added this to the nodes section of rpt.conf:
in [nodes] I added ,Y to the end of the 2428 line, and in the other node I tried to connect to I added the same ,Y on the node 2428 line It won't connect. It did before I added the remote base lines.
On another point I wanted to see if the PC could control the FT-1000D so I also installed hamlib and it does indeed control the rig and read the rig.
Do I have the remote syntax correct? The 2428 node info was placed at the end of rpt.conf by asl-menu so I added the rest of the info in there. Kind of uncertain where the remote stuff goes in ASL3. Also, why phone_functions? I also added the mode control line 6 = remote,6 to functions-remote
Summarizing, the node works perfectly as a conventional ASL box. The PC can control the HF rig. The PC won't "answer" in remote base mode. This is the same problem I have had all along with remote base in ASL3
when in asterisk -r on 2428 I get this error: WARNING[4351][C-00000006]: app_rpt.c:6134 rpt_exec: Node 2428 is not ready yet, rejecting call on IAX2/192.168.1.225:4570-6521
George,
I would check the properties of /dev/ttyUSB0 when you are not running hamlib.
Be sure it can be opened by asterisk for r/w.
You might even 777 it for a test. First having it plugged into the rig.
on issues of dtmf assignment, until you know you are good on that, why not use the command line using remote,x so you know the command is issued.
I've made hamlib work with asterisk before though before ASL3. But I don't want to use hamlib. Cannot (easily) enter freq from the linked allstar radios. I really want to use the remote base in ASL. But beginning to realize that it isn't really working. My test with hamlib was just to see if the box can control the FT1000D. And it does. Remember I said that setting the node up as a plain old repeater or hotspot does in fact allow connections from other nodes but as soon as I add remote=, iport=, iospeed=, etc the node will not accept connections from anywhere. So somehting isn't "turning on" the remote base feature. I even did authevel=0.
So to anybody reading this...has anyone gotten remote base to work in ASL3? If so can you send along your rpt.conf file so I can maybe figure out whet I did incorrectly??
I really like the idea of doing this with the FT1000D since it drives a FL7000 amp and the 1000D controls the band switching on the amp.
just looked this up in the current app_rpt.c and it is line 6225 now, not 6134:
myrpt = NULL;
/* see if we can find our specified one */
for (i = 0; i < nrpts; i++) {
/* if name matches, assign it and exit loop */
if (!strcmp(tmp, rpt_vars[i].name)) {
myrpt = &rpt_vars[i];
if (!myrpt->ready) {
ast_log(LOG_WARNING, "Node %s is not ready yet, rejecting call on %s\n", rpt_vars[i].name, ast_channel_name(chan));
return -1;
}
break;
}
}
I did not notice the error in the listing on the first read.
George,
What exact command did you run when you got this error ?
Guessing you are connecting from some other node inside your NAT.
And that this is a connection error ?
Hope you remember that when defined as a remote base
2428=radio@108.196.236.231:4571/2428,108.196.236.231,y
That 'only one' connection is possible. And don't know what error message happens when a second is tried.
You can run it without the "Y" if that is the issue. That is all the designation really does as far as I have ever found. I think that was to prevent public connections to it when it was listed as a public node and already connected to your main node.
Band limits and commands are all specified in rpt.conf so no application by any other means.
So, outside of that, it is just another node. If there are connection issues, it just goes to node/dialplan setup.
That's not the result of any command, couldn't because the node I was connecting from, 2360, could never connect. These two nodes, 2428 (remote) and 2360 are on the same network and each had an entry in the other's [nodes] list so they could "find" each other. Yes, I'm well aware of "Y" in node statements.
I had tried to connect them without "Y" as just normal nodes, that worked fine. But changing 2428 to remote base "Y" and would not connect and got this error.
George, I just don't think this is a remote base issue, but a connectivity / setting issue.
That error is from a attempted connection it seems.
Or post more of it so we can put in context from what happened previous to it.
Perhaps test by creating a private node dahdi and check/compare.
Or comment out any RB stuff in the rpt.conf and see what area of RB changes it.
But recall that keeping everything else the same “turning off”remote base by eliminating the Y and commenting out the remote=, ioport, , etc(Standard node so to speak) and the connection works. Just when adding that necessary for remote base it fails. Been like this since version 3. Earlier versions and it works. Really would like to find someone who has rb working and see their rpt.conf file
still get connection failed. Forgot to mention earlier that that odd error message not happening any longer. That may have been a network issue here at that time.
So I dropped of the remote lines one at a time.
still no connect until I dropped the most important one:
remote=ft100
Tried other remote names, no dice. As soon as a remote= line goes in the node will no longer accept connections. even tried remote = y, pp16, ft100, ft897
But you have this, without the normal functions call, unless you combined them ?
In my old files, I used this
functions=functions
link_functions=functions-remote
But ASL3 seems to be finicky to having the normal functions stanza load, no matter what else you do.
And/or possibly combine them into one function stanza
And by the way, if you are more comfortable with the old format without -node-main-,
you can do that the old fashion way.
But I do understand the confusion when you use the new way and have separate function stanzas for each node. For me at least, it made to difficult to jump to spot and see my settings. When you have large files, you do a lot of jumping around.
Not sure if that helps.
But you can put all the commands from each function stanza into one and just load it. Perhaps that may help.
I can't see all the function stanza's you have so I am guessing at what is going on here.
And I really dislike trying to debug the new format anyway. Not to bad with a basic setup though. The more you add, the uglier it gets.
Mike, did all of the above. Still no good. As soon as I enable remote= xyz it will not accept connections. Is your remote base using ASL3? If so could you share your rpt.conf so I can see one that works?
GeorgeC
and mentally not up to the task of chasing further into the source I just assumed that maybe instead of remote= use remoterig = xyz so I tried it. Well it will connect if remoterig= is there but not remote= . This still is suggesting to me that "remote" is branching somewhere that does not work.
If you want a public node number for a remote base, it must specifically be requested in the AllStarLink Portal. You must be sure to answer yes to Is node a remote base station?, and then optionally If remote base, is it frequency agile? questions. You can, alternatively`, configure a private node.
Yeah, it is registered as a remote base but I’m right now using it as a private node having its and others on the network not needing the registration servers, node statements in each rpt.conf directing to each other. When testing I have two ssh screens open in front of me one for each do I can make needed modifications as I test. Thanks for the thought.
Not disregarding the instructions...
I fail to see what that changes for anything except a change in a downloaded config where the 'yes' is added to the remote node line.
And the only thing that seems to do is prevent more than one connection.
There was a time 15 years ago when ASL was all profile repeaters that feature was desirable.
It is still a peer based system. Connections do not traverse through asl registration center.
But perhaps something has changed ? It is the same instruction since at least asl 1.01
My old config was to connect the audio,cos,ptt to a private node.
I set all the command functions in a public node for control.
This prevents *4 commanding of the private node to control the agile remote as all the command and port are in the main public node.
And I could leave it run and just disconnect the private node when I didn't want to hear it.
It is the most convenient setup overall.
@George_Csahanin , No, I do not currently run RB 'on asl3'.
But I will attempt something to test when I have time and see if we can get to the root. I have many PC's at home and they are all doing some kind of special work. Can't shut them down.
Have to free up a Pi I guess. I will on my next rainy day.
In the meantime, try a description to a different remote, like a kenwood as I know that Icom is expecting a return from the rig (ic706mkii only) and will lock it up if it is not there. So don't use that. Never tried yaesu myself. I wrote my own icom control for asl.
But the issue may just be related to the rig in the code ?
Tell me some more about this 'HP thin client' you are using.
Shame nobody really takes advantage of the remote base agile system. Perhaps nobody understands what you can do or there is no interest in real analog radio over internet connections? I do both. They enhance each other.
Everyone now wants plug-n-play, no self initiative.
Well, I tried pp16, icom rig, kenwood, etc. As soon as remote= is in the config file connections stop being possible. If I were good at programming I'd be able to follow the source better to see what is looking at that line. I think I found where it looks for that line but cannot determine where it goes from there. The source used to be much easier to follow. Now it is split up into many different files instead of just app_rpt.c and app_rpt.h... But the how-to is written as though it is working in ASL3 so that's frustrating.
Starting to realize that I'll just go with an old ASL, DIAL or ACID to do this, thankfully I still have those distros saved since the ASL folks took away all those files/source, etc. I downloaded all the source code the day Jim died so I have that too. I usually compiled my own so I could run the morse at 30wpm. and on the remote base side I modified the default frequencies and so forth for the FT897 which I was using.
Have you tried filing a bug with app_rpt that something with remote bases for you is broken? I know one of the developers is using a remote base so he may be able to help.