I've recently started using Linpac and I'm looking for a way to do KPC3 style CONVers messaging. I don't actually have a KPC3, but apparently everyone else on the local packet channel does ;) . As near as I can tell, KPC3 CONVers sends a UI frame addressed to what is set in the UNPROTO variable. Pairing this with BUDLIST filtering seems to give you a pretty simple roundtable chat.
I found the Linpac <F10> UI console and :undest parameter, which allows me to send the UI frames. I'm wondering if there is anyway to filter the monitor output to just UI frames and/or maybe a BUDLIST filter in Linpac?
Also, I found the 'conv' macro, which looks like a connected mode chat server. I wasn't able to get it to work, but I think this is different than what I'm trying to do.
Thanks
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Linpac's F10 feature indeed sends the same unconnected UI packets that the TNC2/KPC3 CONV mode sends. To send to a longer digi path, you can use commands like:
:undest "David KLPRC3 KBERRY KRDG"
The monitor view today shows all frames heard on a given AX25 interface per axlisten but if you use ax25spyd, additional filtering might be possible but it will require code support. Unfortunately, I don't think ax25spyd has a maintainer these days. Finally, yes, there is the Linpac CONV feature which is a form of a common chatroom for multiple stations connecting to your station. this is very similar to the X1J TheNet TNC "talk" feature. It does work though I've seen some instability in the past so you might have problems.. give it a try.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, David. I did find the :undest parameter, and have used it successfuly to digi my UI packets. You also answered my next question about ax25spyd :) . I did read the conv.mac macro and I'll debug that to sort out why I couldn't make it work.
If I wanted to do something like build a UI chat console bound to <F9>, that would require pretty extensive code chagnes, correct? I was going to give it a read through and see how complicated it is.
Thanks
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Mike. So you're thinking of offering a filtered UI chat on the F9 key? I'm sure it's possible but at the moment, it's unclear how this should be done. At first glance, I would think that the BUDLIST should be configured on LInpac but the ruleset should be given to something like ax25spyd to apply. What I'm not sure of is how these rules could only be applied to the F9 view and not other views.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks David. I spent some time browsing through the code, and I see what you are talking about. I also found the API and had hoped that UI frames might be reported in something like the EV_DATA_INPUT event. I extended the sample code a bit, but when I ran it I found that nearly every event the API handles is related to user interface. Still, it looks like the API might be the right way to build new functionailty. I'll have to explore it when I have some free time.
Thanks
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've recently started using Linpac and I'm looking for a way to do KPC3 style CONVers messaging. I don't actually have a KPC3, but apparently everyone else on the local packet channel does ;) . As near as I can tell, KPC3 CONVers sends a UI frame addressed to what is set in the UNPROTO variable. Pairing this with BUDLIST filtering seems to give you a pretty simple roundtable chat.
I found the Linpac <F10> UI console and :undest parameter, which allows me to send the UI frames. I'm wondering if there is anyway to filter the monitor output to just UI frames and/or maybe a BUDLIST filter in Linpac?
Also, I found the 'conv' macro, which looks like a connected mode chat server. I wasn't able to get it to work, but I think this is different than what I'm trying to do.
Linpac's F10 feature indeed sends the same unconnected UI packets that the TNC2/KPC3 CONV mode sends. To send to a longer digi path, you can use commands like:
:undest "David KLPRC3 KBERRY KRDG"
The monitor view today shows all frames heard on a given AX25 interface per axlisten but if you use ax25spyd, additional filtering might be possible but it will require code support. Unfortunately, I don't think ax25spyd has a maintainer these days. Finally, yes, there is the Linpac CONV feature which is a form of a common chatroom for multiple stations connecting to your station. this is very similar to the X1J TheNet TNC "talk" feature. It does work though I've seen some instability in the past so you might have problems.. give it a try.
Thanks, David. I did find the :undest parameter, and have used it successfuly to digi my UI packets. You also answered my next question about ax25spyd :) . I did read the conv.mac macro and I'll debug that to sort out why I couldn't make it work.
If I wanted to do something like build a UI chat console bound to <F9>, that would require pretty extensive code chagnes, correct? I was going to give it a read through and see how complicated it is.
Hello Mike. So you're thinking of offering a filtered UI chat on the F9 key? I'm sure it's possible but at the moment, it's unclear how this should be done. At first glance, I would think that the BUDLIST should be configured on LInpac but the ruleset should be given to something like ax25spyd to apply. What I'm not sure of is how these rules could only be applied to the F9 view and not other views.
Thanks David. I spent some time browsing through the code, and I see what you are talking about. I also found the API and had hoped that UI frames might be reported in something like the EV_DATA_INPUT event. I extended the sample code a bit, but when I ran it I found that nearly every event the API handles is related to user interface. Still, it looks like the API might be the right way to build new functionailty. I'll have to explore it when I have some free time.
Thanks
Mike