Alexastar
As you see on the screenshots, the B comes from user‘s Repeater. Another user entered the network with his hotspot call module E, and we see XRF421 E. That is the concrete bug I observed.
Same for xlx339n (they are coupled together), and other modules (i.E. testedcE). And I tested different access protocols (dextra instead of dcs). The bug is not in interpreting things in the access protocol but in that what openspot rewrites for rf transmission.
I did another test yesterday as a normal rf user to a repeater wirth pi-star. I used module B, and repeater call G is set for rpt2. I linked to xlx-reflector and thecremote station is displayed as
user of DB0TVH B (in this case, it was my repeater I used). Same today for DB0TA.
We see, pi-star behaves other than hotspots like bluedv or openspot.
I dig a bit more into the protocol and expectations:
While talking on a hf repeater from module A to module C, the path (rpt1, rpt2) is reversable (remote user could press the RX->CS button - icom design).
Reflectors are a different story: you initiate a reflector link connect with UR-call address, change afterwards UR to CQCQCQ - and the reflector name is not in the path. Even more, with rpt1 or rpt2 you cannot control the link connection, and RX->CS button makes no sense here.
Icom does not address rpt1/rpt2 when operating on a simplex frequency. And simplex is what you use with your hotspot anyway -> Icom transmission has rpt1 and rpt2 empty.
Conclusions:
rpt1 ans rpt2 fields are not necessary and could even be empty. But they can include helpful information, when a hotspots sends the data on rf.
Or it have only rpt1 filled in, with my hotspot name DL9SAU E.
Also, rpt1 and rpt1 set to DL9SAU E would be valid and non-confusing.
rpt1:
——
I argue that rpt1 in the header should kept unchanged (by the repeater, by the reflector, by the hotspot) in order to be transparent to a remote user (in our case I as hotspot user) from which repeatercall+module the speaker comes from. As said, this is what bluedv does.
And this is what th-d75 shows during reception on the display in the first line with the repeater-tower-symbol.
You may argue you see to which reflector your hotspot is linked. But currently the info is less helpful because the shown module is wrong (bug). I know where to I‘ve linked. I‘m more interested in the real source repeater (rpt1) my counterpart comes from. Perhaps a compromise (after bugfix) could be to have a user-configurable option in the openspot.
rpt2:
——
Openspot as well as bluedv write the reflector+module in the header (rpt2). Or perhaps the reflector already did this (I dig not in the sources for investigation). The info „reflector+module“ is more useful than „repatercall G“ of the speaking hf user.
I argue it would even be better if rpt2 would be replaced to the configured call+module of my hotspot (rpt2: DL9SAU E), when the hotspot sends it on hf.
This makes clear who (hotspot user) is transmitting that, and from where the caller initially came from (rpt1: repeater+module).
„rpt2: DL9SAU E“ also makes it easier to debug problems, i.e. when two hotspots nearby use the same frequency: you see who is responsible for the hf retransmission. Currently you only see rpt2 (Gateway) ‚DCS421 N‘ in the rx history of th-d75 for the caller where can lookup the values for rpt2 and rpt1).
For the above debug case we do not need the concrete info in „rpt2“: neither if he came from a reflector (and which one), nor if the link connection was to „/remotereperater“, nor if he used „direct“ callsign-routing.
