On Mar 7, 2021, at 9:25 AM, Marty Boroff via groups.io <m_boroff@...> wrote:


Once you get hooked on them, like radios, you can’t have enough pi’s.

Wow - amazing work folks. Thanks so much

I need to buy some more hardware to test this out! Could I get away with using a Pi-Zero for this to keep costs down?

Cheers
Steve

On Mar 6, 2021, at 11:58 PM, Tom Schaefer NY4I <thomasmschaefer@...> wrote:

?Makes sense. I never mentioned anything about GPIO pins though. Perhaps it was someone else.

I guess that would be needed to cut off the keying line to the radio. I didn’t address the client side Pi.

I was just testing out a theory about the software control flow. So this was not intended to be complete. It’s a community effort so my flow was just to generate some ideas. And poke holes in it—always encouraged during design.

Tom NY4I


Principal Solutions Architect
Better Software Solutions, Inc.
727-437-2771

On Mar 6, 2021, at 10:42 PM, David De Coons wo2x <RocketNJ@...> wrote:

?He meant GPIO pins on the PIs

Dave wo2x

Sent from my waxed string and tin cans.

On Mar 6, 2021, at 10:36 PM, Tom Schaefer NY4I <thomasmschaefer@...> wrote:

?Grip pins? I assume a typo but don’t understand. If not a typo, I really don’t understand.

Tom

Principal Solutions Architect
Better Software Solutions, Inc.
727-437-2771

On Mar 6, 2021, at 10:42 PM, David De Coons wo2x <RocketNJ@...> wrote:

?He meant GPIO pins on the PIs

Dave wo2x

Sent from my waxed string and tin cans.

On Mar 6, 2021, at 10:36 PM, Tom Schaefer NY4I <thomasmschaefer@...> wrote:

?Grip pins? I assume a typo but don’t understand. If not a typo, I really don’t understand.

Tom

Principal Solutions Architect
Better Software Solutions, Inc.
727-437-2771

He meant GPIO pins on the PIs

Dave wo2x

Sent from my waxed string and tin cans.

> On Mar 6, 2021, at 10:36 PM, Tom Schaefer NY4I <thomasmschaefer@...> wrote:
>
> ?Grip pins? I assume a typo but don’t understand. If not a typo, I really don’t understand.
>
> Tom
>
> Principal Solutions Architect
> Better Software Solutions, Inc.
> 727-437-2771
>
>
>
>

On Mar 6, 2021, at 10:36 PM, Tom Schaefer NY4I <thomasmschaefer@...> wrote:

?Grip pins? I assume a typo but don’t understand. If not a typo, I really don’t understand.

Tom

Principal Solutions Architect
Better Software Solutions, Inc.
727-437-2771

[Edited Message Follows]

Here is a simple interlock using http-in. It makes it easy to test the concept with a web browser rather than setup multiple node-red servers. Easily changed once the concept is worked out. Perhaps it gives us a place to start.?

I built this before I read Robert's post so I have to read that to see what would need to change. Specifically, the idea of sending a message to each node upon any one node getting the token requires more exploration. I can see the case for that so the nodes do not need to ask versus my flow which is more of a poll type system.

I put a comment in the flow that describes it a bit.?

NY4I-Interlock.json

This is my first self-created flow versus copying and modifying others found here so no doubt there are much better ways to do this.

Tom NY4I
Tom

On Mar 6, 2021, at 12:40 PM, Tom Schaefer NY4I <thomasmschaefer@...> wrote:

The more I think about it the less I like doing it this way. If I have 4 stations, the transmission time to grab the token will be a bit slow since Iw old need to hear back from all the other stating they do not have it. I do not like the idea of a central server but it would make interlock procurement faster.

Essentially, clients send a message to a central node to request permission to transmit. If no one else has XMIT rights, the central server sends a message back to the requestor granting transmit privileges. A timeout mechanism has to be incorporated too. MQTT might be too much here so a simple message on the wire between nodes.

Anyway, still thinking it through for speed.

Tom NY4I

On Mar 5, 2021, at 6:01 PM, David De Coons wo2x <RocketNJ@...> wrote:

That is how MultiFlex works.

?

Dave wo2x

?

?

From:?[email protected]?<[email protected]>?On Behalf Of?Tom Schaefer NY4I
Sent:?Friday, March 5, 2021 5:24 PM
To:?[email protected]
Subject:?Re: [nodered-hamradio] Interlocking

?

Not too complicate this too much but if this is going to go to network separated stations, wouldn’t it need the idea of a token request and a token confirmation? That way a station requests the baton and then waits to make sure it has the baton (by the other stations stating they do not have it).

?

Tom NY4I

On Mar 5, 2021, at 5:10 PM, Alan Blind, WA9WUD <a.alan.blind@...> wrote:

?

Steve

I went ahead and built a four-operator / PTT control flow. ?We can figure out the transceiver interface later. ?For now, I used a simulated "TX-True" or "TX-False" input. ?I also built a test panel with swithes to simulate the inputs.

Hoping others can jump in with their ideas.

The .json file is attached to this message.

The flow will operate a GPIO based relay to operate either a PTT circuit or the "TX Inhibit" RCA connection to the Flex. ?We can replace the relay with a TCP-based inhibit later.

If an operator has "TX-True", all other operators cannot TX. ?The dashboard, on each flow, will show the TX status of all four stations.

There are four flows, one for each operator. ?All the flows are connected via a mosquito MQTT broker, so each station can be remote from the others. ?You will need to install Mosequetto on a single device and reconfigure the MQTT ?in and out Nodes to the IP address of the device.

Each operator can see the status of all four stations on their Dashboard. ?

The flow can be run on either Windows or Raspberry Pi. ?You can use a Pi 3 with no problems to save on costs.

Here is the main part of the flow:


<Screen Shot 2021-03-05 at 4.51.07 PM.png>

And here is the dashboard:

<Screen Shot 2021-03-05 at 4.50.42 PM.png>

Alan
WA9WUD

"

<Multi Station TX Flow.json>

?

On Mar 5, 2021, at 6:01 PM, David De Coons wo2x <RocketNJ@...> wrote:

That is how MultiFlex works.

?

Dave wo2x

?

?

From:?[email protected]?<[email protected]>?On Behalf Of?Tom Schaefer NY4I
Sent:?Friday, March 5, 2021 5:24 PM
To:?[email protected]
Subject:?Re: [nodered-hamradio] Interlocking

?

Not too complicate this too much but if this is going to go to network separated stations, wouldn’t it need the idea of a token request and a token confirmation? That way a station requests the baton and then waits to make sure it has the baton (by the other stations stating they do not have it).

?

Tom NY4I

On Mar 5, 2021, at 5:10 PM, Alan Blind, WA9WUD <a.alan.blind@...> wrote:

?

Steve

I went ahead and built a four-operator / PTT control flow. ?We can figure out the transceiver interface later. ?For now, I used a simulated "TX-True" or "TX-False" input. ?I also built a test panel with swithes to simulate the inputs.

Hoping others can jump in with their ideas.

The .json file is attached to this message.

The flow will operate a GPIO based relay to operate either a PTT circuit or the "TX Inhibit" RCA connection to the Flex. ?We can replace the relay with a TCP-based inhibit later.

If an operator has "TX-True", all other operators cannot TX. ?The dashboard, on each flow, will show the TX status of all four stations.

There are four flows, one for each operator. ?All the flows are connected via a mosquito MQTT broker, so each station can be remote from the others. ?You will need to install Mosequetto on a single device and reconfigure the MQTT ?in and out Nodes to the IP address of the device.

Each operator can see the status of all four stations on their Dashboard. ?

The flow can be run on either Windows or Raspberry Pi. ?You can use a Pi 3 with no problems to save on costs.

Here is the main part of the flow:


<Screen Shot 2021-03-05 at 4.51.07 PM.png>

And here is the dashboard:

<Screen Shot 2021-03-05 at 4.50.42 PM.png>

Alan
WA9WUD

"

<Multi Station TX Flow.json>

?

On Mar 5, 2021, at 8:21 PM, Charlie Rubenstein <charlier@...> wrote:

?Sure, really anytime works for me Alan. It?looked like it installed ok, but then didn't run. I tried checking the status of the service and this is what I got:

pi@SDRPlay:~ $ sudo systemctl status FRStackWebApi

● FRStackWebApi.service - FRStack Web APIs

?? Loaded: loaded (/lib/systemd/system/FRStackWebApi.service; enabled; vendor preset: enabled)

?? Active: failed (Result: exit-code) since Fri 2021-03-05 20:15:52 EST; 2min 5s ago

? Process: 5412 ExecStart=/usr/bin/dotnet FRStackWebApi.dll --urls http://*:5025 (code=exited, status=150)

?Main PID: 5412 (code=exited, status=150)

?

Mar 05 20:15:51 SDRPlay systemd[1]: FRStackWebApi.service: Failed with result 'exit-code'.

Mar 05 20:15:51 SDRPlay systemd[1]: Failed to start FRStack Web APIs.

Mar 05 20:15:52 SDRPlay systemd[1]: FRStackWebApi.service: Service RestartSec=100ms expired, scheduling restart.

Mar 05 20:15:52 SDRPlay systemd[1]: FRStackWebApi.service: Scheduled restart job, restart counter is at 5.

Mar 05 20:15:52 SDRPlay systemd[1]: Stopped FRStack Web APIs.

Mar 05 20:15:52 SDRPlay systemd[1]: FRStackWebApi.service: Start request repeated too quickly.

Mar 05 20:15:52 SDRPlay systemd[1]: FRStackWebApi.service: Failed with result 'exit-code'.

Mar 05 20:15:52 SDRPlay systemd[1]: Failed to start FRStack Web APIs.

pi@SDRPlay:~ $?


Charlie

So, what ever time works for you, I'm fine.