forum.pistar.uk

Backstory: I have had this setup for over a year now, so nothing on my end has changed. I use a MD-380 and piZeroW. Pi-star:4.1.5 Dashboard: 20211109

The problem: Whenever I connect to a FCS room, I get connected to a room 5 below what I wanted. Example: connect to FCS00330, actual connection to FCS00325. Connect to FCS00334, actual connection to FCS00329.

I first noticed this on Nov. 6th, so this started 4-5 days ago.

Anybody heard of this, or have a similar experience? Is this even a pistar problem, or a problem with the FCS3 server?

73,
Scott

The only things in the github commits that are relevant are these:

https://github.com/g4klx/YSFClients/com ... 6edc570a09

https://github.com/AndyTaylorTweet/Pi-S ... 3bf18312bb

They appear to affect various FCS server room numbering and overlapping FCS/YSF numbering overlaps.

I don't really know much more about it, you could see if the code changes in the first link above mean anything to you.

Thanks Brian, but I don't see anything there, and I think that is for something else. But I'm not too tech savy anyway.

Update on what I am experiencing. Seems that when trying to connect to FCS1, the room is incorrect by 1 (FCS00106=FCS00105), FCS2 is incorrect by 3 (FCS00285=FCS00282), and FCS3 is off by 5 as stated in my first comment. Now when I connect to FCS31080 I get FCS31054, that's off by 26. And FCS31184 I get FCS21157, off by 27.

The actual problem is/was the way that FCS rooms were assigned a number.

There are some static numbers that are internal to YSFGateway, YSF numbers from 1-5 are in use for things like parrot and the YSF2xxx cross-over modes.

All of the YSF rooms have assigned numbers, FCS on the other hand, have no assigned number, they only have an assigned name, this is an important thing to consider.

What was actually happening before the change in YSFGateway, is that the hard coded 5 rooms at the bottom, AND any unlucky YSF room would get replaced by an FCS as the YSFGateway software read the host files and imported all the rooms, wind back the clock far enough and that didn't matter, there were almost no YSF rooms that started under 10000, and only about 300 FCS rooms - life was simple.

Wind forwards again to today, a few things happened, firstly there has been an explosion of registered YSF rooms, partly due to XLX adding in YSF support and many of those becoming registered, and also the FCS group asked us to include their non-assigned FCS rooms as well as the assigned (labelled ones). That was all shaping up to a mess...

So what actually changed...

Now YSF rooms (these actually have assigned numbers remember) get their assigned numeric ID, exactly like they should do, FCS rooms that have no guaranteed number are interleaved into the free space between YSF room numbers, this means that FCS rooms *WILL* change number as the YSF list changes.

Yaesu radios have WiresX mode, using that will allow you to read / search the room list directly from your radio, if you search for an FCS, you will find it and be able to connect. YSF rooms can always be dialed by their ID, its an assigned number so it wont change.

Now when using cross-over modes like DMR2YSF - this is for sure a problem, because you can only interact with a room by ID from your DMR radio, because that is all DMR knows, I don't have a great answer for that (yet).

Thank you Andy, and you too Jason.

So I guess the best solution is for those on FCS servers to move over to YSF? The problem with that is getting the repeater owners to make the move.

With my FT-70 I can use the pi-star dashboard to switch, on my UV380 I just made my digital contact +5 and it did connect to the correct room. This will definitely be confusing to anyone not familiar.

This problem seems to have gotten worse overnight (12/12/21). Won't stay connected to FCS reflectors and when keying it changes the reflector # by greater than the 5 (or other increments by FCS range). Was there an update to pi-star overnight?

W1BKW wrote: ↑Sun Dec 12, 2021 3:30 pm This problem seems to have gotten worse overnight (12/12/21). Won't stay connected to FCS reflectors and when keying it changes the reflector # by greater than the 5 (or other increments by FCS range). Was there an update to pi-star overnight?

Last update was some days ago, possibly over a week in fact.

Don't think this is Pi-Star.

I am not sure how I can use Wires-X if I don't have a Yaesu radio to register for Wires-X or how that is part of Pi-star DMR2YSF config. I can understand what you are saying about the room number changing, but even without keying, it disconnects after a few minutes.

KE7FNS Wrote: Maybe you have network issues causing your disconnects. Maybe the server you are connecting to is having network issues. You really need to further investigate the cause before just blindly blaming something at random.

It ended up being problems with the FCS Servers, which is why when attempting several rooms all failed.

But to clarify, I did not blindly BLAME anything, I asked a question and described my symptoms. Sorry you took offense.

I usually run DMR Gateway on my homebrew hotspot (Pi 3B+, N5BOC simplex UHF board, Nextion screen, Pi-Star). DMR2YSF is one of 3 connections/networks typically used. I was beginning to think I was going crazy the other day. When trying to key up a Reflector in the FCS003 group (through DMR2YSF), no one could hear me... even though it has worked perfectly in the past. Like most, I first assumed it was something in my radio programming (which hasn't changed lately) or maybe my hotspot. A review of my radio programming found no issues and an Update/Upgrade of Pi-Star didn't help. I then noticed that the YSF Network box on my dashboard consistently showed a connection to the reflector 5 lower than what I was keying up.

After discovering this thread, and seeing that it wasn't a problem with my equipment, I confirmed manually dialing 5 higher than what I wanted for an FCS reflector was a viable workaround... at least in the FCS003 group. I'll be watching my dashboard closely to see if the FCS reflector "offset" changes over time as the attempts at blending 3+ networks continue. Based on the information shared here by MW0MWZ and others, it sounds like this isn't a problem likely to be solved any time soon. Such is the adventure (and frustration) of the ongoing attempts to make all digital modes/servers/systems accessible through software like Pi-Star and devices like hotspots!

Many thanks to those who continue to develop Pi-Star and the hardware to make hotspots possible. Your work is greatly appreciated!