OpenSpot-1 not working with XLX reflectors!

n8lbv

Hi, I have been working on this for about a week and have not been able to get my openspot-1 to work with my own new XLXd reflector and also does not work with some other ones tested.
The Opensport "connects" to the XLX, but ignores/does not validate audio streams.
I got some help today from somebody very helpful in the XLXd community and he ran some tests when I tried to
connector and use his XLXd reflector.
He pointed out an issue, and I am hoping for some help here in how I might be able to further debug/diagnose and hopefully correct this issue.
I have put some time into this myself and have not yet been able to figure this out:
Looking for help Please and Thank you!!

by CT2HRB » 27 May 2024 18:16
XLX2024 is his system hostname.

Btw, last weekend I asked Steve (via pm) to connect to my XLX and TX a bit for testing, he reproduced the same exact problem on my XLX, his TX from Openspot was not recognized by XLX at all, but I did capture traffic from his attempts for further analysis. I did today check and made some tests with such captured packets and think I found what's happening (despite I don't know why), actually the reason why his streams from openspot are ignored by xlx is that on all his TX attempts the very first packet (header) is always missing, not being sent to xlx at all.

following are fields from decoded FICH for first 3 packets from Pi-Star stream:
DT=2 FI=0 FN=0 FT=6
DT=2 FI=1 FN=0 FT=6
DT=2 FI=1 FN=1 FT=6

and this is from first 3 packets from his Openspot (and same on 3 different TX attempts he made):
DT=2 FI=1 FN=1 FT=6
DT=2 FI=1 FN=2 FT=6
DT=2 FI=1 FN=3 FT=6

Note that FI should be 0 for header, 1 for voice, 2 for terminator, and FN is sequential frame number... you see header one with FI=0 is missing from Openspot sreams. Why? Well, not a XLX problem, Steve's Openspot is just not sending header to XLX as it should... You may then ask why it works on other YSF reflectors (non-XLX)? Because these implement a "late entry" mechanism to "recover" the header without actually requiring the initial header, XLX doesn't implement that, anyway the initial header should be sent and I think this is what you should look at... why Luc Openspot works fine and Steve's one doesn't? Firmware? What about frequency offset to get good BER, etc? (I don't know how it works on Openspot) maybe a bad offset may cause 1st packets missing? multiple modes enabled on hotspot? (again I don't know Openspot but on MMDVM enabling multiple modes may cause delay detecting mode as it will scan all them), these are just ideas for you to check, I have no idea what causes it... hope you can find it.

HA2NON

Make sure your openSPOT1 is running the latest firmware v142. This firmware version has been working fine with XLX servers in the last 4 years since it was released.

n8lbv

Hi Norbert how are you doing?
Been a while since we have talked!
I am of course on firmware v142.

Any other ideas on what I can do or try with this?
I would really love to get it working.
I have packet captures from the Openspot (not working as detailed above).
And pistar (working).
Would you be willing to help or look at them?
I may also try older firmware on the Openspot (if it can be flashed with older firmware) and see if that makes any difference.
The packet captures are small. I could zip them up and send them to the info@ email address if you would be willing to take a look.

n8lbv

I sent an email to info- asking if I could get the two previous version of firmware to try on this.
It seems the friends that have this working are on firmware that is one or two revs back.
I'd like to try it.

n8lbv

I managed to find and download the 141 firmware just by substituting the filename in the 142 download link provided on the SharkRF page.
This seems to have fixed everything regarding this issue.
It works now.

CT2HRB >>>

Concerning converter, it makes sense now, and yes it's normal the debug line is printed before the stream open line because the debug line is "early" on code that handles incoming packets.

Great that you got it fixed, just let SharkRF guys know as they apparently have some serious issue with C4FM on last firmware then... I think they actually miss 2 initial packets, the header one with FI=0 and even a voice one with FI=1 and FN=0, as it always started on the FN=1 that should be actually the 3rd one...

n8lbv

@Norbert Please take this into consideration.
I spent a week on this assuming no such problems with the V142 firmware. And chased about everything else before trying downgrading the firmware.
Thank You.

n8lbv

@HA2NON Am requesting that you would further engage in this conversation.
I spent about a week troubleshooting and ultimately found that the latest firmware release has the problem indicated above.
I also sent an email to info requesting older firmware images and was not even acknowledged there.
Found the older firmware images myself by substituting the file name on the 142 download link.
and that 141 works and does not exhibit the missing header packet problem like 142 does.
Rendering 142 unusable in my configuration using the Openspot as a YSF reflector client to any tested tested XLXd in setup as a YSF reflector.

HA2NON

We've replied to your email and sent you the link to firmware v141. Sorry, but new firmwares won't be released for the openSPOT1 anymore as it has been discontinued in 2018 and support is no longer available.