search

ncssar / radiolog

SAR radio log program
Other
14 stars 3 forks source link

add NXDN support (Kenwood NEXEDGE) #628

Closed caver456 closed 1 year ago

caver456 commented 1 year ago

One zone on NCSSAR radios now does digital (NEXEDGE, which is Kenwood's implementation of the NXDN 'standard'). As far as we can tell from various docs and comments, Fleetsync is distinct from NXDN: FleetSync is over analog, and NXDN is over digital. Interesting that the KPG-D1N System page shows both FleetSync and NXDN on the same page, if you select NXDN as the system type. That is probably done to accommodate the ability to send GPS data on the Data Zone-Channel (where the radio changes the channel briefly to send data on a different dedicated channel, then changes back to the selected channel afterwards), which could be analog using Fleetsync. It's all pretty confusing - our understanding of it will probably improve if/when we go farther down the rabbit hole.

Fleetsync still works fine for most zones, so, this is not a top priority.

We want to add the same functionality as Fleetsync:

And some tasks to consider for interaction between FleetSync and NEXEDGE:

Logistics:

QA before merging into master:

caver456 commented 1 year ago

NXDN CID data, which is currently correctly recognized as not valid FS data:

072156:     DATA IS WAITING!!!
072156:      but not valid fleetsync data.  Scan continues...
072156:☻gI1U03001U03001♥☻gI0U03001U03001♥
caver456 commented 1 year ago

By comparison, here's what a full fleetsync sequence looks like, with CID on BOT, then CID+GPS on EOT:

073040:PARSING
073040:☻$PKLDS,153042,A,3912.3188,N,12104.5616,W,,,,,00,100,3001,80,00,*1B
$PKLSH,3912.3188,N,12104.5616,W,153042,A,100,3001,*33
$GPRMC,153042,A,3912.3188,N,12104.5616,W,,,,,*07
$GPGGA,153042,3912.3188,N,12104.5616,W,1,,,,,,,,*46
♥
073040: line:☻$PKLDS,153042,A,3912.3188,N,12104.5616,W,,,,,00,100,3001,80,00,*1B
073040: line:$PKLSH,3912.3188,N,12104.5616,W,153042,A,100,3001,*33
073040:$PKLSH detected containing CID: fleet=100  dev=3001  -->  callsign=SAR 1
073040:Valid location string:'3912.3188|N|12104.5616|W'
073040:convertCoords called: targetDatum=WGS84 targetFormat=UTM 5x5 coords=['3912.3188', 'N', '12104.5616', 'W']
073040:Formatted location string:'66124  41324'
073040:convertCoords called: targetDatum=WGS84 targetFormat=D.dList coords=['3912.3188', 'N', '12104.5616', 'W']
073040:WGS84 lat=39.205313333333336  lon=-121.07602666666666
073040: line:$GPRMC,153042,A,3912.3188,N,12104.5616,W,,,,,*07
073040: line:$GPGGA,153042,3912.3188,N,12104.5616,W,1,,,,,,,,*46
073040: line:♥
073040:updating fsLog: fleet=100 dev=3001 callsign=<None>  COM port=COM4
073040:openNewEntry called:key=fs callsign=SAR 1 formattedLocString=66124  41324 fleet=100 dev=3001 origLocString=3912.3188|N|12104.5616|W amendFlag=False amendRow=None isMostRecentForCallsign=False
caver456 commented 1 year ago

Not able to figure out just yet how to get NXDN GPS data to show up in radiolog. Just CID on both BOT and EOT.

Confirmed that the portable used for testing is sending analog Fleetsync GPS data on the digital channel if it was contacted using analog within the last ten seconds, but not if the previous transmission was digital. (Ken has details if needed). Still working on it...

johnpictin commented 1 year ago

This will be really helpful as we then could integrate Icom radios along side the Kenwoods. It would just be a matter of configuring the strings that the Icoms transmit.

John

On Thu, Feb 9, 2023, 8:41 AM Tom Grundy @.***> wrote:

Not able to figure out just yet how to get NXDN GPS data to show up in radiolog. Just CID on both BOT and EOT.

Confirmed that the portable used for testing is sending analog Fleetsync GPS data on the digital channel if it was contacted using analog within the last ten seconds, but not if the previous transmission was digital. (Ken has details if needed). Still working on it...

— Reply to this email directly, view it on GitHub https://github.com/ncssar/radiolog/issues/628#issuecomment-1424488647, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6GMSTLHZKU4WZVJOK2Y73WWUM3TANCNFSM6AAAAAAUWV3KNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

caver456 commented 1 year ago

John, can you send some of the icom strings, ideally as utf8-decoded 'text' (with the smileys and hearts) but hex or binary or whatever other format might be fine too? Since I don't have an icom radio set to test with, that would probably be a legth back-and-forth process. Adding it as a checkbox category here, since icom is different than NEXEDGE (Kenwood's implementation of NXDN).

caver456 commented 1 year ago

On second thought - probably best to make the Icom NXDN support into a separate issue, since this issue will hopefully be resolved and closed sooner than Icom.

johnpictin commented 1 year ago

Have the portable and the base both been programmed with equivelant NXDN and Fleetsync settings? I'm not exactly sure how it works, but from the reading I was doing NXDN does support Fleetsync type I AND II calls.

This is done so that a site that is already running Fleetsync mobile/handheld radios can migrate into an NXDN setup. They won't lose comms as the digital radios can run dual mode by embedding the digital signal into the analog audio until they go full digital only.

When adding radios into the table in programming. You can copy Fleetsync IDs to NXDN but not NXDN to Fleetsync. NXDN ID's have a different format.

i wish I had the software and cables to work with you on this.

John

On Thu, Feb 9, 2023, 8:41 AM Tom Grundy @.***> wrote:

Not able to figure out just yet how to get NXDN GPS data to show up in radiolog. Just CID on both BOT and EOT.

Confirmed that the portable used for testing is sending analog Fleetsync GPS data on the digital channel if it was contacted using analog within the last ten seconds, but not if the previous transmission was digital. (Ken has details if needed). Still working on it...

— Reply to this email directly, view it on GitHub https://github.com/ncssar/radiolog/issues/628#issuecomment-1424488647, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6GMSTLHZKU4WZVJOK2Y73WWUM3TANCNFSM6AAAAAAUWV3KNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

caver456 commented 1 year ago

Thanks for the leads - I thought they had been set correctly but clearly they have not. I don't have the setup here at home - am planning to spend some more quality time at the station with KPG-D1N and the docs and the mobile and portable radios sometime soon.

FS CID and GPS are getting through on the channel that has NXDN enabled, so, the FS settings are probably good, but not so much for the NXDN settings.

On Thu, Feb 9, 2023 at 7:32 PM johnpictin @.***> wrote:

Have the portable and the base both been programmed with equivelant NXDN and Fleetsync settings? I'm not exactly sure how it works, but from the reading I was doing NXDN does support Fleetsync type I AND II calls.

This is done so that a site that is already running Fleetsync mobile/handheld radios can migrate into an NXDN setup. They won't lose comms as the digital radios can run dual mode by embedding the digital signal into the analog audio until they go full digital only.

When adding radios into the table in programming. You can copy Fleetsync IDs to NXDN but not NXDN to Fleetsync. NXDN ID's have a different format.

i wish I had the software and cables to work with you on this.

John

On Thu, Feb 9, 2023, 8:41 AM Tom Grundy @.***> wrote:

Not able to figure out just yet how to get NXDN GPS data to show up in radiolog. Just CID on both BOT and EOT.

Confirmed that the portable used for testing is sending analog Fleetsync GPS data on the digital channel if it was contacted using analog within the last ten seconds, but not if the previous transmission was digital. (Ken has details if needed). Still working on it...

— Reply to this email directly, view it on GitHub https://github.com/ncssar/radiolog/issues/628#issuecomment-1424488647, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AM6GMSTLHZKU4WZVJOK2Y73WWUM3TANCNFSM6AAAAAAUWV3KNQ

. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/ncssar/radiolog/issues/628#issuecomment-1425127085, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEPCEZWAGRPKXKTYJMXQDOTWWWZEXANCNFSM6AAAAAAUWV3KNQ . You are receiving this because you authored the thread.Message ID: @.***>

caver456 commented 1 year ago

Was able to get GPS over NXDN working. We just some bad settings in the portable radio. The full transmission looks like this - note that the GPS data came in on BOT, immediately after CID - since there is no BOT/EOT distinction in the NXDN portion of the Kenwood programming software:

102917:     DATA IS WAITING!!!
102917:      but not valid fleetsync data.  Scan continues...
102917:☻gI1U03001U03001♥☻$PKNDS,182916,A,3912.3127,N,12104.5647,W,,,,,00,U03001,207,00,*59
$PKNSH,3912.3127,N,12104.5647,W,182916,A,U03001,*4C
$GPRMC,182916,A,3912.3127,N,12104.5647,W,,,,,*02
$GPGGA,182916,3912.3127,N,12104.5647,W,1,,,,,,,,*43
♥
102918:     DATA IS WAITING!!!
102918:      but not valid fleetsync data.  Scan continues...
102918:☻gI0U03001U03001♥
dBitech commented 1 year ago

This is my NXDN/Fleetsync mixed mode setup using a fairly trivial serial port reader, and modified pynmea2 to provide the GPS position decoding of the $PKNDS/$PKLDS sentence image I've also confirmed to work DMR/Fleetsync mixed mode.

caver456 commented 1 year ago

Just did the first commit and pull request. Will try to keep comments and discussion on the pull request from here on out.

caver456 commented 1 year ago

Disregard the last - re-re-re-thinking, there's too much discussion on the issue thread before the pull request even exists, so, probably best to keep the discussion on the issue page rather than the pull request page. Anyway - will expand the checkbox list at the top of the issue to include details.

caver456 commented 1 year ago

Fiddled around with radtext and realterm today, to reverse-engineer the outgoing data for poll and text, in the same manner as was done for fleetsync. Review #18 for lots of good background info on getting realterm to work with radtext or radiolog; additional notes from an email to self:

now to duplicate this flow from radtext:

Added some notes to radiolog.py with the reverse-engineered outgoing data for poll and text over nexedge, copied here. Need to test next time at the station.

Also, not quite sure yet about nexedge broadcast: might need to program each radio to have the same group id, if they are not already programmed that way.

    # Serial data format for sendText and pollGPS functions was discovered by using RADtext 
    #    https://radtext.morganized.com/radtext
    #  along with a virtual COM port bridge, and a COM port terminal emulator to watch the traffic

    # sendText - outgoing serial port data format:
    #
    # <start><length_code><fleet><device><msg><sequence><end>
    #
    # <start> - 02 hex (ascii smiley face)
    #   for NEXEDGE, insert 67 hex (lowecase g) after 02
    # <length_code> - indicates max possible message length, though the plain text message is not padded to that length
    #   46 hex (ascii F) - corresponds to 'S' (Short - 48 characters)
    #   47 hex (ascii G) - corresponds to both 'L' (Long - 1024 characters) and 'X' (Extra-long - 4096 characters)
    #   if you send COM port data with message body longer than that limit, the mobile will not transmit
    # <id>
    #   FleetSync: <fleet><dev> - plain-text three-digit fleet ID and four-digit device ID (0000000 for broadcast)
    #   NEXEDGE: U<uid> - U followed by five-digit unit ID
    # <msg> - plain-text message
    # UNUSED: <sequence> - plain-text two-digit decimal sequence identifier - increments with each send - probably not relevant
    #   NOTE: sequnce is generated by radtext, but, it shows up as part of the message body on the
    #          receiving device, which is probably not useful.  Interesting point that we could
    #          add timestamp or such to the message body if needed, but, this is not a separate token.
    # <end> - 03 hex (ascii heart)
    #
    # examples:
    # FleetSync:
    #  broadcast 'test' (short):  02 46 30 30 30 30 30 30 30 74 65 73 74 32 39 03   F0000000test28  (sequence=28)
    #  100:1002 'test' (short):  02 46 31 30 30 31 30 30 32 74 65 73 74 33 31 03   F1001002test31  (sequence=31)
    # NEXEDGE:
    #  03001 'test' (short):  02 67 46 55 30 33 30 30 31 74 65 73 74 31 31 03   gFU03001test10  (sequence=10)

    # pollGPS - outgoing serial port data format:
    #
    # <start><poll_code><fleet><device><sequence><end>
    #
    # <start> - 02 hex (ascii smiley face)
    #   for NEXEDGE, insert 67 hex (lowecase g) after 02
    # <poll_code>
    #   52 33 hex (ascii R3)
    # <id>
    #   FleetSync: <fleet><dev> - plain-text three-digit fleet ID and four-digit device ID (0000000 for broadcast)
    #   NEXEDGE: U<uid> - U followed by five-digit unit ID
    # UNUSED - see sendText notes - <sequence> - plain-text two-digit decimal sequence identifier - increments with each send - probably not relevant
    # <end> - 03 hex (ascii heart)

    # examples:
    # FleetSync:
    #  poll 100:1001:  02 52 33 31 30 30 31 30 30 31 32 35 03   R3100100120  (sequence=20)
    #  poll 100:1002:  02 52 33 31 30 30 31 30 30 32 32 37 03   R3100100221  (sequence=21)
    # NEXEDGE:
    #  poll 03001:  02 67 52 33 55 30 33 30 30 31 30 36 03   gR3U0300108  (sequence=08)
caver456 commented 1 year ago

So there are a lot of places in the code where fleet and dev are assumed to exist. Will have to figure out the best way to recode all of those.

Ultimately these pieces of code all revolve around fsLookup, which is a list of lists, each sublist having three elements: fleet, dev, callsign. This is written to / read from radiolog_fleetsync.csv in the run dir. (at the start of the session, .config/radiolog_fleetsync.csv is read to initialize the list - which can lead to long lookup list due to the new 'range' syntax - see if this impacts performance - maybe only save the non-default entries, or only the entries used during the session, in the run dir)

Probably the cleanest way to do it for nexedge is to add a sublist where the first element is blank and the second element is uid as a five-digit-string: [,01001,Team 1]. That way the list and the file are 'correct' and 'unambiguous'.

Then, other code can be put in place to deal with the interactions, e.g. what if any parts of the code should treat nexedge 01001 the same as fleetsync 100:1001.

caver456 commented 1 year ago

Ready to resume work on this feature (June 13 2023), now that 3.7.0 is released and several bug fixes are in place. Other major enhancements #598 and #391 should happen next, after this issue is finished.

caver456 commented 1 year ago

Merged 3.7.0 into this issue's branch, but need to make sure those recent fixes and enhancements still work in this issue's branch since conflicts had to be resolved in radiolog.py, especially in fsLogUpdate and getCallsign.

caver456 commented 1 year ago

Integration issues are probably best handled as comments and commits here, rather than new github issues. For starters - this, and probably others to come, are likely due to the fact that pre-merge nxdn code was using all-strings-everywhere for fleet and dev, which is probably the way to go forward since NXDN UID is a string, while 3.7.0 was using int for fleet and dev. Probably need to make some code changes to keep using str-everywhere.

105100:PARSING
105100:☻I110030011003001♥☻I010030011003001♥☻I$PKLSH,3916.1146,N,12101.5078,W,123456,A,100,3001,*2D♥
105100: line:☻I110030011003001♥☻I010030011003001♥☻I$PKLSH,3916.1146,N,12101.5078,W,123456,A,100,3001,*2D♥
105100:getCallsign called for FleetSync fleet=100 dev=3001
105100:found matching entry/entries:[[100, 3001, 'SAR 1']]
Traceback (most recent call last):
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 1923, in fsCheck
    self.fsParse()
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 2032, in fsParse
    callsign=self.getCallsign(fleet,dev)
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 2619, in getCallsign
    if len(matches)!=1 or len(matches[0][0])!=3: # no match
TypeError: object of type 'int' has no len()
caver456 commented 1 year ago

improved #614 to also raise an exception (therefore try the next bak file in sequence) if a row doesn't have enough columns, indicating possible file corruption (and this case was also easier to create a test case for)

caver456 commented 1 year ago

On incoming NXDN traffic:

073524:PARSING
073524:☻gI1U03004U03004♥☻$PKNSH,3916.3497,N,12101.3847,W,123456,A,U03004,*4C♥☻gI0U03004U03004♥
073524: line:☻gI1U03004U03004♥☻$PKNSH,3916.3497,N,12101.3847,W,123456,A,U03004,*4C♥☻gI0U03004U03004♥
073524:getCallsign called for NXDN UID=03004
Traceback (most recent call last):
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 1923, in fsCheck
    self.fsParse()
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 2050, in fsParse
    rprint("$PKNSH (NEXEDGE) detected containing CID: Unit ID = "+uid+"  -->  callsign="+callsign)
TypeError: can only concatenate str (not "NoneType") to str

Looks like getCallsign is returning None.

caver456 commented 1 year ago

This was due to an indentation problem in getCallsign, which should have been caught during cleanup from the recent merge-commit. Fixed for FS and for NXDN and committed to this branch, though initial call from KW-NXDN-... doesn't spawn CCD as it should. Need to fix the code that checks for 'first non-mic-bump call from this device' which currently only triggers for fleetsync.

caver456 commented 1 year ago

Getting closer - solved the issues above - but this looks really wacky:

214254:PARSING
214254:☻gI1U08005U08005♥☻$PKNSH,3916.1880,N,12101.4938,W,123456,A,U08005,*4C♥
214254: line:☻gI1U08005U08005♥☻$PKNSH,3916.1880,N,12101.4938,W,123456,A,U08005,*4C♥
214254:getCallsign called for NXDN UID=08005
Traceback (most recent call last):
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 1923, in fsCheck
    self.fsParse()
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 2047, in fsParse
    callsign=self.getCallsign(uid)
  File "C:\Users\caver\Documents\GitHub\radiolog\radiolog.py", line 2649, in getCallsign
    if int(entry[1])==uid:
ValueError: invalid literal for int() with base 10: 'U0800'

Two things: 1) U0800 (where's the last digit '5'?) and 2) should the U be part of the uid or not? either way it still needs to be a string, to capture any leading zero (08005).

caver456 commented 1 year ago

Did another commit to address everything above. Will need to add a full QA checklist at the top, to make sure all FS functionality is still working now / after all NXDN functionality is finished. Will need to be plugged in to radios to perform the full QA, but, it seems to be good as much as I can test with fsTester.

caver456 commented 1 year ago

At 91, here's a fresh check of progress that was made back in February:

caver456 commented 1 year ago

Yup it was pretty easy to add the NXDN-vs-FS clause to sendText. TX from the mobile happens correctly, the portable gets the text, the mobile receives the ack, and the delivery confirmation message box is shown. Need to clean up these display issues before committing, but, this does seem like the radio programming is good to go for everything other than NXDN broadcast which hasn't been tried yet. image

caver456 commented 1 year ago

Got NXDN broadcast to work. Looking at radtext, guessing from the command strings but without actually looking at the data that radtext sends: replace the U with a G, and use device ID 00000 in the same manner as for FS:

205359:message:aaa
205359:broadcasting text message to all devices
205359:com data: ☻gFG00000Jun29 20:53 aaa♥

Two portables both receive the text on dTAC1.

caver456 commented 1 year ago

did a few more cleanup commits, to make the message boxes more clear when sending text.

Next topic: how to modify the FleetSync Send Console dialog (spawned from the options dialog)? 1 - send to all: do we want to specify 'send to all fleetsync' vs 'send to all nxdn' vs 'send to all fleetsync and nxdn'? Seems like cluttering up the GUI to allow this distinction wouldn't really be useful. If the operator wants to broadcast, then they want to broadcast to all. So - just send both - first broadcast to FS then broadcast to NXDN. The code should be intelligent about deciding which com port/s to send those commands to - but - does it really matter if a digital broadcast command is sent to a radio that is set to an analog channel, or vice versa? It could be important if it results in the same text getting sent twice to any given portable... 2 - sending to individual / multiple specific devices, and gps polling: option 1) add a radio button to select FS vs NXDN, then the Fleet ID field should be grayed out for NXDN; option 2) just add a note to leave the Fleet ID field blank for NXDN

johnpictin commented 1 year ago

Hi Tom,

Just a suggestion on this. The radio operator shouldn't be bothered with asking is this an nxdn or fleetsync radio. They should either be broadcasting to all radios or selecting a radio from a team tab or a directory of radios. The software should look up the radio and decide what format to use based on the Device ID/Fleetsync ID in the lookup table.

This could be accomplished by having an editable per radio callsign where an individual's name or callsign would be entered. Right now, when you go into the fleetsync menu on a team tab, you see the Fleetsync ID. An editable user friendly call sign or individuals name would be ideal. It would be an additional field in the NED and potentially the change team screen as well as a column in the fleetsync display. But it would be nice for the operator to be able to associate a radio with an individual as well as have them grouped by team. Once the radio is assigned to an individual it's Device ID is not very important to the comms operator. It would make digital messaging and polling simpler because you could clearly understand who is who, especially when you wind up with many radios on a team assignment. It would be easy to have an alphabetical list of all members who are equipped with radios and are on the task and to be able to message them directly. Or when selecting a team you would see the names of the radio equipped users on that assignment

On our team we do not have enough radios to assign one to each member. Our SOP is to always have a minimum of 2 radios per team, usually one with the TL and a second with the member they designate to handle radio comms for the group. Those radios are dynamic and change hands as the task progresses, from one team assignment to another. So being able to modify the radio call sign as well as the team designation would be important. I hope I have explained myself clearly.

John

On Fri, Jun 30, 2023, 10:09 AM Tom Grundy @.***> wrote:

did a few more cleanup commits, to make the message boxes more clear when sending text.

Next topic: how to modify the FleetSync Send Console dialog (spawned from the options dialog)? 1 - send to all: do we want to specify 'send to all fleetsync' vs 'send to all nxdn' vs 'send to all fleetsync and nxdn'? Seems like cluttering up the GUI to allow this distinction wouldn't really be useful. If the operator wants to broadcast, then they want to broadcast to all. So - just send both

  • first broadcast to FS then broadcast to NXDN. The code should be intelligent about deciding which com port/s to send those commands to - but
  • does it really matter if a digital broadcast command is sent to a radio that is set to an analog channel, or vice versa? It could be important if it results in the same text getting sent twice to any given portable... 2 - sending to individual / multiple specific devices, and gps polling: option 1) add a radio button to select FS vs NXDN, then the Fleet ID field should be grayed out for NXDN; option 2) just add a note to leave the Fleet ID field blank for NXDN

— Reply to this email directly, view it on GitHub https://github.com/ncssar/radiolog/issues/628#issuecomment-1614938951, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6GMSQT2EQHH7PQOZ5TMI3XN4B2ZANCNFSM6AAAAAAUWV3KNQ . You are receiving this because you commented.Message ID: @.***>

caver456 commented 1 year ago

Hi John - I think we're probably talking about the same thing and mostly came to the same conclusions?

For broadcasting, yes I think it's best to leave the FS Send Console button as-is and not make the operator choose between FS and NXDN:

image

Here's the context menu for a team with multiple FS devices and multiple NXDN devices:

image

The idea about a separate sub-callsign per device makes sense, though it seems even more niche: it seems very rare to want to send a text to e.g. Joe on team 1 but not to Susan on team 1 (so I think the send-to-individual-device entries in that context menu would rarely be used - they are mostly there for completeness). It seems rare enough that if we needed to do that, we'd find a way within IC to figure out who has what device number: probably just looking on the equipment sign-out sheet (or looking up the person's SAR# if it's one of the folks that has a long-term issued radio, which we could tell by the device ID thousands digit). Granted, that's just our team and there are probably teams where that isn't an option, so I'll add an issue for it but seems like pretty low priority. Adding sub-callsigns and a way to manage them may be a fairly invasive code change adding a fair amount of GUI complexity.

Seems like it's also going to be pretty rare that the FleetSync Send Console (from the options menu) is used to send text to individual radio/s. That function would probably always be done from the team tab context menu. But, if the operator is going to know enough to be sending by ID using the FleetSync Send Console, then they would know whether they want to send to FS or to NXDN.

Let me know if I misinterpreted - did that cover your suggestions? Thanks

caver456 commented 1 year ago

Made a few commits that should address the FleetSync Send Console topic. (leaving it with that same name is probably OK due to real estate concerns - a more correct name would be 'FleetSync / NEXEDGE Send Console')

Here are some iterations of the Send Console dialog with all the recently-committed callbacks in place:

image

There are a few checkboxes remaining in the desired functionality set - it's possible those are already working correctly, so, initial QA next week at the station will tell the tale.