STATE_PTY

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

STATE_PTY

Ken Koster
Has anyone modified SvxLink to publish additional information besides
sql_state?

I've added [publishStateEvent Logic:transmit "tx=$is_on" ] to Logic.tcl but
that only tells me that transmit is on/off.   I'd really like to know which of
my transmitters is on/off.  Something like  [publishStateEvent Logic:transmit
"$tx_id=$is_on"] giving me an output of [Logic:transmit Tx1=1] or something
similar.

I don't see an obvious way to do that without changing the core code.  
I'll do that if necessary but I'm as lazy as the next guy and if someone has
already done it I'll gladly follow.
--
Ken - N7IPB
Email: [hidden email]
JID: [hidden email]
PGP Sig: F42B EF90 3CD3 31C7 3056  122E 993A 7B2E 5138 C42A
“The best conversation I had was over forty million years ago…. And that was
with a coffee machine.”
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: STATE_PTY

Rob Janssen
Ken Koster wrote:

> Has anyone modified SvxLink to publish additional information besides
> sql_state?
>
> I've added [publishStateEvent Logic:transmit "tx=$is_on" ] to Logic.tcl but
> that only tells me that transmit is on/off.   I'd really like to know which of
> my transmitters is on/off.  Something like  [publishStateEvent Logic:transmit
> "$tx_id=$is_on"] giving me an output of [Logic:transmit Tx1=1] or something
> similar.
>
> I don't see an obvious way to do that without changing the core code.
> I'll do that if necessary but I'm as lazy as the next guy and if someone has
> already done it I'll gladly follow.
>

How are your multiple transmitters wired?  In our repeater all transmitters keyup simultaneously
(we use MultiTx) but you may be running different Logics in parallel?
You can access the callsign of the repeater in that statement, but when all logics are running
under the same callsign that does not bring you much.

On one of our systems we run two linked logics under a different callsign, each with their
own RepeaterLogic.tcl file, but sharing a single Logic.tcl file. Unfortunately there are two
different Logic instances that do not appear to have some "handle" to allow access to eachothers
data.  I would like to access the $sql_rx_id of the first Logic inside the proc send_rgr_sound of
the second logic, for example, but this appears to be impossible.

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: STATE_PTY

Ken Koster
On Wednesday, January 18, 2017 9:57:23 AM PST Rob Janssen wrote:

> Ken Koster wrote:
> > Has anyone modified SvxLink to publish additional information besides
> > sql_state?
> >
> > I've added [publishStateEvent Logic:transmit "tx=$is_on" ] to Logic.tcl
> > but
> > that only tells me that transmit is on/off.   I'd really like to know
> > which of my transmitters is on/off.  Something like  [publishStateEvent
> > Logic:transmit "$tx_id=$is_on"] giving me an output of [Logic:transmit
> > Tx1=1] or something similar.
> >
> > I don't see an obvious way to do that without changing the core code.
> > I'll do that if necessary but I'm as lazy as the next guy and if someone
> > has already done it I'll gladly follow.
>
> How are your multiple transmitters wired?  
I'm working on replacing the NHRC controller on our system.  It currently
consists of a single TX site with one repeater and a local rf link transceiver
that ties into an existing UHF repeater that acts as the hub for multiple
repeater sites.  While I'd love to replace everything with a Svxlink based
system I only control the one site.

My test system adds a network linked tx/rx simplex radio to the mix.  My plan
in the future is to use them to fill in holes in our coverage.  The terrain
around here is full of hills and even with the main site at 4300 feet there
are valleys and areas behind ridges that don't have great coverage.  Using the
existing UHF linked system helps a lot but it doesn't use Svxlink (yet) and
I'd like an inexpensive way to fill in coverage.

> In our repeater all transmitters
> keyup simultaneously (we use MultiTx)

I use MultiTx but only for the audio stream that feeds darkice/icecast.

> but you may be running different Logics in parallel?

Yes.  A repeater logic and multiple simplex logics.   I can't just use MultiTx
because I need the simplex link radios to only transmit when receivers detect
CTCSS not during normal repeater id, announcements and hang time.  It wouldn't
be a problem if the link radios were all by themselves, but when linking to
existing repeaters I need them to act like a user, not like the repeater TX.

> You can access the callsign of the repeater in that
> statement, but when all logics are running under the same callsign that
> does not bring you much.

As f5vmr suggested I can parse the log file but I find that not to be a very
elegant solution compared to using the pty.

As for why I want the tx information, I just think it would be nice to tag a
web display with the transmitters that are currently up.  I can derive that
from the repeater state and the log file but was hoping for a more elegant
solution.
 
> On one of our systems we run two linked logics under a different callsign,
> each with their own RepeaterLogic.tcl file, but sharing a single Logic.tcl
> file. Unfortunately there are two different Logic instances that do not
> appear to have some "handle" to allow access to eachothers data.  I would
> like to access the $sql_rx_id of the first Logic inside the proc
> send_rgr_sound of the second logic, for example, but this appears to be
> impossible.

I wonder if it would be possible to have a pty for each logic instance?  I
know the current code doesn't support that, but it might be a future solution.

Svxlink is a great package and I really love the flexibility it gives me as a
repeater builder/owner.  And the ability to run it on something like the
Raspberry Pi is amazing.  It's remarkable how compact a package can be made
from a Motorola CDM (or any other tranceiver) and an RPi.
--
Ken - N7IPB
Email: [hidden email]
JID: [hidden email]
PGP Sig: F42B EF90 3CD3 31C7 3056  122E 993A 7B2E 5138 C42A
“I never am really satisfied that I understand anything; because, understand
it well as I may, my comprehension can only be an infinitesimal fraction of
all I want to understand” -Ada Lovelace
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: STATE_PTY

Ken Koster
In reply to this post by Ken Koster
On Wednesday, January 18, 2017 10:07:57 AM PST f5vmr wrote:

> This information is available when you tail -f /var/log/svxlink.log if you
> have created a line when setting up the svxlink service via sudo svxlink
> --daemon -- logfile=/var/log/svxlink.log. (that's two taks before each of
> those commands). It displays squelch info too and if you are running
> multiple receivers the state of the voter as well as which transmitter or
> both if active. In F5ZGM-R even the state of the stream transmitter is
> declared. Why publish it? The information is need to know for the sysop.
> All the users are concerned with is if the repeater is working😃. F5ZGM-R
> sends me a mail each night, with the log of activity of the last 24 hours,
> when it saves a copy for seven days, and truncates the current log to zero.
> We don't want to fill the SD card up! Chris F5VMR G4NAB
Thanks Chris,
I know I can parse the log but that just seems to be less elegant than using a
pty.  That's probably just me,  but that's the way I look at it.

It's not terribly important,  but I was just playing with a web page to
display a system map with receiver information and thought it would be nice to
also indicate what transmitters were actually transmitting.  Deriving that
information from the log file or other system state is one way it could be
done.

Thanks for the input.
--
Ken - N7IPB
Email: [hidden email]
JID: [hidden email]
PGP Sig: F42B EF90 3CD3 31C7 3056  122E 993A 7B2E 5138 C42A
“I never am really satisfied that I understand anything; because, understand
it well as I may, my comprehension can only be an infinitesimal fraction of
all I want to understand” -Ada Lovelace
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: STATE_PTY

Rob Janssen
In reply to this post by Ken Koster
Ken Koster wrote:
>
> As for why I want the tx information, I just think it would be nice to tag a
> web display with the transmitters that are currently up.  I can derive that
> from the repeater state and the log file but was hoping for a more elegant
> solution.

The STATE_PTY was originally created for this thing, and it should certainly be possible
once you find the trick to get the into to put in the publishstateevent string...
We also use it to send a list of connected EchoLink stations and the currently transmitting
EchoLink station.

> I wonder if it would be possible to have a pty for each logic instance?  I
> know the current code doesn't support that, but it might be a future solution.

STATE_PTY is defined in RepeaterLogic.  I have zero experience with SimplexLogic so
I cannot tell you if it works there as well.

>
> Svxlink is a great package and I really love the flexibility it gives me as a
> repeater builder/owner.  And the ability to run it on something like the
> Raspberry Pi is amazing.  It's remarkable how compact a package can be made
> from a Motorola CDM (or any other tranceiver) and an RPi.

Yes it is great, we do a lot of things with it.  (also own extensions)

For example, w.r.t. coverage: we transmit from 3 high sites on the same frequency and
with synchronized audio to get a wide coverage area.  (co-channel operation)
With many receivers it is possible to access the repeater from a portable over a very
large area.
(this requires quite a lot of special equipment, like transmitters with external reference inputs,
GPS disciplined oscillator at every site which provides PPS for accurate timing, etc)

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: STATE_PTY

Ken Koster
On Wednesday, January 18, 2017 9:19:00 PM PST Rob Janssen wrote:

> Ken Koster wrote:
> > As for why I want the tx information, I just think it would be nice to tag
> > a web display with the transmitters that are currently up.  I can derive
> > that from the repeater state and the log file but was hoping for a more
> > elegant solution.
>
> The STATE_PTY was originally created for this thing, and it should certainly
> be possible once you find the trick to get the into to put in the
> publishstateevent string... We also use it to send a list of connected
> EchoLink stations and the currently transmitting EchoLink station.
>
> > I wonder if it would be possible to have a pty for each logic instance?  I
> > know the current code doesn't support that, but it might be a future
> > solution.
> STATE_PTY is defined in RepeaterLogic.  I have zero experience with
> SimplexLogic so I cannot tell you if it works there as well.
I hadn't thought of trying it there so I just ran a test with STATE_PTY=/tmp/
linkstate_pty in SimplexLogic and it works.   And at first glance it looks
like I get the Logic:transmit tx=1 for the transmitter on that particular
SimplexLogic and nothing else.  That makes sense since all the receiver
information is tied to voting.

> > Svxlink is a great package and I really love the flexibility it gives me
> > as a repeater builder/owner.  And the ability to run it on something like
> > the Raspberry Pi is amazing.  It's remarkable how compact a package can
> > be made from a Motorola CDM (or any other tranceiver) and an RPi.
>
> Yes it is great, we do a lot of things with it.  (also own extensions)

I've noticed :-)
 
> For example, w.r.t. coverage: we transmit from 3 high sites on the same
> frequency and with synchronized audio to get a wide coverage area.
> (co-channel operation) With many receivers it is possible to access the
> repeater from a portable over a very large area.
> (this requires quite a lot of special equipment, like transmitters with
> external reference inputs, GPS disciplined oscillator at every site which
> provides PPS for accurate timing, etc)

Simulcast systems are impressive but probably not the way I'll go.  My current
system is the latest after many years of building repeaters and I love the
technology I can apply to it.  My joy is in building things and making them
work,  the fact that it covers north of the border into Canada, to south of
Seattle and gets used by others is just an extra benefit.

Thanks again for the help.
--
Ken - N7IPB
Email: [hidden email]
JID: [hidden email]
PGP Sig: F42B EF90 3CD3 31C7 3056  122E 993A 7B2E 5138 C42A
“I never am really satisfied that I understand anything; because, understand
it well as I may, my comprehension can only be an infinitesimal fraction of
all I want to understand” -Ada Lovelace
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: STATE_PTY

Rob Janssen
Ken Koster wrote:
>> STATE_PTY is defined in RepeaterLogic.  I have zero experience with
>> SimplexLogic so I cannot tell you if it works there as well.
> I hadn't thought of trying it there so I just ran a test with STATE_PTY=/tmp/
> linkstate_pty in SimplexLogic and it works.   And at first glance it looks
> like I get the Logic:transmit tx=1 for the transmitter on that particular
> SimplexLogic and nothing else.  That makes sense since all the receiver
> information is tied to voting.

Great!
You can check the example in the svxlink tree to see how you can make a webpage
that displays this data very easily.

>
> Simulcast systems are impressive but probably not the way I'll go.  My current
> system is the latest after many years of building repeaters and I love the
> technology I can apply to it.  My joy is in building things and making them
> work,  the fact that it covers north of the border into Canada, to south of
> Seattle and gets used by others is just an extra benefit.
>

Ok that is good, the simulcasting also introduces problems of course.
We cover most of the Netherlands, and into part of Belgium, Germany and the UK.
(there are receivers over the border in Belgium and Germany and one beaming to the UK)
However, our country is very very flat.

And of course, there is the installation on Curacao that also covers Bonaire.

Rob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Svxlink-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/svxlink-devel
Loading...