YSFClients
YSFClients copied to clipboard
g4klx
Room's list fault on FT-991A
Hi to all ,
we found a strange things while we trying to list all the YSFreflector on a FT-991A . The first 20 occurrences are listed correctly with NAME-number-nodes-connected . The following rooms are listed in a wrong way, without the number of nodes connected and repeated many times . This problems seems to be present only on FT-991A, not on other YAESU radio ( FT1,FT2, FTM100 etc ... ) , but it is really strange . There is someone that noticed this kind of issue ? do you think could be a fix for that ?
Attached some screenshot
Pict 1 : the rooms are listed correctly Pict 2: till 20 rooms all it's ok Pict 3: the next rooms are listed in a wrong way repeated many times . Pict 4 : If I push the TOP button, the previous 20 rooms are listed in a wrong way
this kind of problem is present only on a MMDVM repeater with YSFGateway, it works well on a YAESU nodes or repeater.
If you need some other info, as logs or some other else, let me know .
Thank you for your attention , all suggestions are welcome .
73 de IW9GRL
I confirm this strange behaviour of the FT991A when it queries a non-Yaesu Wires-X node. Another anomaly is that Preferred Rooms list feature doesn't work at all, though this is a minor issue. Both issues don't appear in my other C4FM radio, an FT2D. 73, Johnny
Just an addon
what I noticed is that, considering the string how the ysfreflector list is composed
27746;IT-CATANIA;TG22491-BM2222;91.92.128.145;42000;003;http://91.92.128.145/YSFdash
on the first 20 occurrences , the radio display on screen : IT-CATANIA 003 ( name of room and number of nodes connected )
from 21 the radio display : IT-CATANIA TG22491-BM2222 ( instead of field 6, it displays the field 3 )
but only if the next 20 rooms are present, if not for example remains only 10 rooms, the radio displays : NO DATA
thank you for you attention and suggestions
73
Are you sure you are using updated YSFGateway? I did notice this exact issue last year and fixed it on PR https://github.com/g4klx/YSFClients/pull/169
Actually there is apparently a bug on FT991 firmware, for the first ALL request it really issues an ALL command - as it should - to list all rooms, but after you scroll down to the subsequent pages of results (or then back to 1st page as you say) it will then issue SEARCH commands (instead of ALL), searching for an empty string, anyway this should work the same as for the ALL command, but... there was a bug on YSFGateway search code that listed repeated results if search match occurs multiple times along room name (and the empty string was actually "matching" every char), this caused exactly what you describe. Also if you really issue a SEARCH command from radio searching for 'AA' and there is for eg. a room named 'AABAACC', it would also list that room twice, you see what I mean... Anyway this is fixed since my PR referred above, merged 1 year ago, then I really think you are using outdated YSFGateway?
Are you sure you are using updated YSFGateway? I did notice this exact issue last year and fixed it on PR #169
Actually there is apparently a bug on FT991 firmware, for the first ALL request it really issues an ALL command - as it should - to list all rooms, but after you scroll down to the subsequent pages of results (or then back to 1st page as you say) it will then issue SEARCH commands (instead of ALL), searching for an empty string, anyway this should work the same as for the ALL command, but... there was a bug on YSFGateway search code that listed repeated results if search match occurs multiple times along room name (and the empty string was actually "matching" every char), this caused exactly what you describe. Also if you really issue a SEARCH command from radio searching for 'AA' and there is for eg. a room named 'AABAACC', it would also list that room twice, you see what I mean... Anyway this is fixed since my PR referred above, merged 1 year ago, then I really think you are using outdated YSFGateway?
HI
first of all thank you very much for your kindly answer . I updated the YSFGateway before wrote the issue. It is really strange, and I don't know why I have always the same problem.
could you suggest me something in particular to verify ? thank you in advance 73 de IW9GRL
Hi guys,
I don't have the issue mentioned above but I have another problem returning search results. If I want to connect to room "001-CQ-UK" and search with "001" this is working and I got a list of all rooms begining with "001". The problem is if search using "CQ" or "UK". In this case I got "No Data" message on the radio. I am using FT991A and latest pi-star. YSFGateway version is 20210131_Pi-Star_v4. From the log i can see that there is a difference in the data returned by YSFGateway. First picture is the output after the working search and 2nd from the non-working one. Any ideas what could be the problem!?
@iw9grl: I'm really sorry but I really don't know what to tell you :( Sorry to persist, but I really think you are doing something wrong and probably somehow still running old version of YSFGateway... try to update again and double check you are not doing some mistake, running some older binary or something...
@dimitrov-b: I did also notice a similar issue before, it seems to be triggered when specific results are returned, I did dig about it at the time but couldn't understand why it happens, I couldn't see anything wrong with such replies... but yes, when some specific search results are returned the radio ignores the reply, and I could see same issue happen with both FT-991 and FT-1 then seems not radio specific, also could reproduce it with both MMDVM_HS and DVMEGA hotspots. For example, if I try to search for "ALAB" then reply should include two rooms, Alabama-Link and IT-CALABRIA, however radios doesn't like that reply for some reason and doesn't show it... but, if I issue an ALL or just search for "A" then reply is shown ok and I can see Alabama-Link correctly listed along with others... Curiously if I enable the option to set all room names to uppercase then I can search for "ALAB" and the reply is correctly recognized by the radios - I can see the two rooms listed as it should... but not sure if the issue will then happen with some other specific results even in uppercase? I can't understand why it happens with specific results... try the uppercase setting also yourself and see what happens for you.
@narspt Thanks for your reply. Uppercase is not working for me but I would say it seems logical why it worked for you. If you take a closer look at the pictures attached, you will notice that non-working search returns a lot of empty strings/lines at the end. I guess the radio is reading the list but once those empty strings(lines) begin, the radio probably thinks that this is empy response and there is no point of receiving it anymore. At that point the receive led on the radio stops blinking and I get the "No Response" message.
Probably the uppercase doesn't do difference for your case as I think the room you are searching for is already uppercase... but if you try with the "ALAB" example I think you should get same behavior as me, I think the uppercase isn't really a solution but seems to "solve" the problem for some, just because room name "changes" and I think the issue depends on room names somehow... If I remember correctly I think I did even test to edit rooms list and changing just one character on the problematic room name will also "solve" it.
Concerning what you say, from what I did see on code when I looked at it, this is intended, the reply should be some fixed length and if there are no results to fill it, then it will be space (0x20) padded, ending with final and crc bytes, I don't think this is a problem, and if you try different searches matching other rooms, even if they also match only 1 or 2 rooms you will find that some (most of them) will work properly, only some queries returning specific results fail to be received on radio, no idea why :(
@g4klx: any idea? test to search for "ALAB" (with uppercase room names option turned off) and you will see that radio isn't able to show that specific search result (even if you try multiple times), it happens with some other specific search results.
Probably the uppercase doesn't do difference for your case as I think the room you are searching for is already uppercase... but if you try with the "ALAB" example I think you should get same behavior as me, I think the uppercase isn't really a solution but seems to "solve" the problem for some, just because room name "changes" and I think the issue depends on room names somehow... If I remember correctly I think I did even test to edit rooms list and changing just one character on the problematic room name will also "solve" it.
Concerning what you say, from what I did see on code when I looked at it, this is intended, the reply should be some fixed length and if there are no results to fill it, then it will be space (0x20) padded, ending with final and crc bytes, I don't think this is a problem, and if you try different searches matching other rooms, even if they also match only 1 or 2 rooms you will find that some (most of them) will work properly, only some queries returning specific results fail to be received on radio, no idea why :(
@g4klx: any idea? test to search for "ALAB" (with uppercase room names option turned off) and you will see that radio isn't able to show that specific search result (even if you try multiple times), it happens with some other specific search results.
Hello @narspt
sorry for my reply after several months !!!! About the dupe room listed it works, no more dupe rooms in the ALL list, but I noticed a strange behaviour always with the rooms after the 20th ( from 21st .... ) . I loose the number of repeater connected ( please see the picts below )
regarding the behaviour fo SEARCH, I have the same situation as you, if I search at leat 3 characters ( e.g. IT- ) it works well, but if I add the fourth letter ( e.g. IT-C ) I see in my log the same as yours with TON of number 20 :)
I don't know if in the meantime you found a solution !
thank you for your time ! BR 73
Hi, I don't use it for a while now (as anyway the audio on 991A while receiving the hotspot is much worst than if you listen hotspot using other C4FM radios like FT-1, FT-2, FT-3, FTM-100, I don't understand why but there is something weird on the C4FM of 991A that doesn't listen hotspots very well...) but I remember when I checked it that actually only the 1st ALL command that radio send's is actually an ALL command, after you scroll down and it fetches the 2nd, 3rd, etc... pages it will start issuing SEARCH commands instead, searching for and empty string (it still works as the search feature implemented on YSFGateway will match all rooms)... but I guess that is the reason why you don't see the count numbers... also notice on upper left corner of display that it changes from "ALL" to "SEARCH & DIRECT", visible on your photos... don't ask me why the radio does that but I guess it is a bug on the radio firmware... :(
The 0x20 chars that you see are normal, the packets have a specific size and when they are not filled with data they are padded with 0x20 char (space char).
Hi, I don't use it for a while now (as anyway the audio on 991A while receiving the hotspot is much worst than if you listen hotspot using other C4FM radios like FT-1, FT-2, FT-3, FTM-100, I don't understand why but there is something weird on the C4FM of 991A that doesn't listen hotspots very well...) but I remember when I checked it that actually only the 1st ALL command that radio send's is actually an ALL command, after you scroll down and it fetches the 2nd, 3rd, etc... pages it will start issuing SEARCH commands instead, searching for and empty string (it still works as the search feature implemented on YSFGateway will match all rooms)... but I guess that is the reason why you don't see the count numbers... also notice on upper left corner of display that it changes from "ALL" to "SEARCH & DIRECT", visible on your photos... don't ask me why the radio does that but I guess it is a bug on the radio firmware... :(
The 0x20 chars that you see are normal, the packets have a specific size and when they are not filled with data they are padded with 0x20 char (space char).
Thank you for your kindly answer yes, you're right the problem is linked to the fact the first occurrence is ALL and the next one is a SEARCH ! The FT991A have a different manage of WiresX than the other C4FM radios, if I remember well it use a software manage (DSP) instead of an hardware manage ( AMBE chip ) used for example in the FT1, FTM-100 and so on . but, used with official Yaesu rooms it doesn't have any issues ! Unfortunately I don't know in which part of code of YSFGateway I can look, my software competencies are limited :(
I hope someone much more expert than me can help for this ! Have a nice day 73 de IW9GRL