Kenwood radio tracking

RobinB's Avatar

RobinB

29 Jun, 2020 09:33 PM

I have been trying to get Kenwood radio tracking working with a SARtopo setup. I have browsed all of the topics I could find in the forum and knowledge base, but haven't got things working yet. From reading other threads on the topic, I am under the impression that I should be able to add a locator group to a map with our fleet ID, and that should be all that I need to do.

Currently, I have a Kenwood base station that is setup for connection to a laptop. The radio is connected via Serial to USB adapter to COM 7. I know the connection is working, because Kenwood KAS-10 software on the same laptop is able to read position reports from the radio.

I am not getting any error messages, just nothing happening, so no clues for how to proceed from here. So far I have tested by triggering the radio to send a position by polling it from the KAS-10 software, and assumed that would also make it show on the SARTopo map. Perhaps I need to poll it some other way for the position data to be available to SARTopo? The drivers for the COM port adapter are listed as working.

One thing I wonder is whether it makes a difference that i am running online, not offline at this point?

I am also aware of radiolog, and that is a route we are planning to go in the future, but for now, it seems like there is the possibility of an easier method that could be quickly rolled out.

  1. 1 Posted by mvbanks on 29 Jun, 2020 10:28 PM

    mvbanks's Avatar

    Robin,
    I am assuming you programmed the portables to send the GPS data? Which
    model kenwood portables are you using?
    Mark Banks
    TCSAR

  2. 2 Posted by RobinB on 29 Jun, 2020 10:35 PM

    RobinB's Avatar

    Kenwood NX-3220. The portables do send the data to the KAS-10 software when polled. Do I perhaps need to change the programming of the radio to always send the data on transmission?

  3. 3 Posted by mvbanks on 29 Jun, 2020 11:19 PM

    mvbanks's Avatar

    Robin,
    I am not familiar with the NX-3220's. I was able to successfully get
    fleetsync to send gps data to sartopo using TK-2180, TK-5210 and NX-210's.
    The TK's had GPS mics while the NX-210's had the built in GPS, which I
    suspect would be the same with your NX-3220's. I don't recall all the
    configuration items involved but there was a significant amount of backend
    programming to make them work. Obviously, each radio will have it's own
    unique config to be able to track them as separate assets. Do you have
    Nevada County's Fleetsync PDF? It's what I used as a reference to get ours
    working.
    Mark Banks
    TCSAR

  4. 4 Posted by RobinB on 30 Jun, 2020 01:16 AM

    RobinB's Avatar

    A few more details:

    Our base station radio is a Kenwood NX-700.
    We actually have NX-3220 (built in GPS) and TK-2170 (GPS mic) in the fleet. I misspoke, as I was doing my tests with the TK-2170. All radios are programmed as the same fleet (100) with unique IDs.

    Definitely transmitting GPS data. I can trigger it by polling from KAS-10, or by pressing a button on the handheld.

    I found the PDF you referenced, it is somewhat helpful. It states that SARsoft (SARTopo) "listens" to the COM port, which is what I thought, so I am guessing that maybe my radios need to be configured differently to send the right type of string.

  5. 5 Posted by caver456 on 30 Jun, 2020 02:11 AM

    caver456's Avatar

    Hello Robin and Mark - I may be having the same problem. Interesting thing
    is that just a few days ago while trying to assist with another help thread
    here regarding kenwood fleetsync (I'm just a user, not one of the caltopo
    help staff), I just now tried for the first time to do fleetsync straight
    in to the com port of the same computer that is running sartopo offline,
    and I was not able to get it to work. No moving locators, no output on the
    terminal. We've been using fleetsync for years (TK7180, TK2312, and
    others) but we use radiolog as the 'middleman', which reads the com port
    traffic on one computer, then spits it out as an http request on the local
    network which is picked up by sartopo offline running on a different
    computer, i.e. our sartopo offline instance sees an http request, it does
    not see com port traffic. Mark, would you be able to provide the details
    of your setup? Hopefully it's just a line I'm missing in sar.properties...?

  6. 6 Posted by RobinB on 30 Jun, 2020 02:26 AM

    RobinB's Avatar

    A few more details in case they are helpful.

    I misspoke, as we actually have TK-2170s (with GPS mic) in the fleet as well, and that is what I was testing with. The base radio is a NX-700.

    I have tested with KAS-10 running, and that receives the GPS data no problem, either by polling, or any time I initiate it from the hand held. Just realized that I should try it without KAS-10 running, as perhaps that is hijacking the port? A quick Google suggests that may be the problem...

    I found the PDF that Mark referenced, and that is helpful for understanding, but there is little reference to the setup I am trying to get working, except it does state that SARsoft (SARtopo now) 'listens' to com ports for any radio position activity.

    I wonder if I need to change something about the format the radios are transmitting the data in.

    Just to reiterate - I am testing this in an online SARtopo setup, not offline, but I am not sure if that is an issue.

  7. 7 Posted by JohnP on 30 Jun, 2020 07:39 AM

    JohnP's Avatar

    Hi Robin. There is an updated version of Ben's programming info. I took our command unit down to BV Communications and we tweaked our handhelds and the command radio to adjust the transmission parameters. Neil at BV has a copy of the program. It now sends Unit ID on the beginning of transmission and GPS coords and ID on the end of transmission. I am not sure how SARTopo will handle this and want to test it this week. I also want to test our config with RadioLog, but that's something I need to check with caver456. It could be that we are not sending the correct info from the radio or in the right order. Initially there were somes extras turned on that were confusing things. The radio programming is important and complex.

  8. 8 Posted by caver456 on 30 Jun, 2020 01:39 PM

    caver456's Avatar

    Back to the caltopo support folks: I'm just not getting it to work locally
    either, meaning com port traffic directly into the same computer that is
    running sartopo offline. That's still a distraction from Robin's original
    question regarding sartopo online, but guessing it might be the same root
    issue?

    I have these lines in sar.properties; as I understand it, only the first
    one is actually needed, which starts listening for data (either aprs or
    fleetsync) on local com ports:

    sarsoft.location.aprs.local.enabled=true
    log4j.logger.org.sarsoft.location=DEBUG,console

    I'm using a fleetsync data emulator and a virtual serial port bridge (
    https://freevirtualserialports.com/ - the 'limited' free version is fine),
    since I don't have a mobile radio. I can verify that the incoming com port
    traffic is picked up by radiolog and by a terminal emulator (but just one
    of those at a time since windows locks the com port to one-app-at-a-time
    even for read). I don't have KAS-10 installed. So maybe something about
    this virtual port setup is the problem, but there aren't any other
    indications of that.

    The sequence I use to get the com ports set up and then locked in the right
    sequence by the right programs:
    1. make sure that nothing is running that would try to lock a com port for
    read (radiolog, terminal emulator, sartopo offline, etc)
    2. run the virtual com port bridge program to make a bridge between com1
    and com2
    3. run the fleetsync data emulator - this tries to lock com1 by default
    4. run sartopo offline, which gives terminal output shown at the bottom;
    the com1 locked errors are expected as above, so it's just listening to com2
    5. make a minimal map (e.g. just a marker) on localhost:8080, save it, then
    Add Locator, type=Fleet, fleet=100
    6. in the emulator, send fleetsync data to com1; make sure the fleet id is
    100. For reference, I'm sending CID+GPS so the com port data looks like so:
    I11002001100200110 I11002001100200110
    I$PKLSH,3916.1355,N,12101.4407,W,123456,A,100,2001,*2D

    So, here, we would expect the locator to update, or at least to see some
    output in the terminal, but, nothing happens. Anyone have any thoughts on
    what's missing?

    PS F:\SARTopo-Offline\new> .\SARTopo-Offline.bat

    F:\SARTopo-Offline\new>java -Dsarsoft.properties=sar.properties
    -Dsarsoft.version="SARTopo Offline" -Xmx4096m -jar sar.jar --debug=1
    Welcome to SARTopo Offline version 4160, 04/28/20 02:33:06
    License Key 18620-3MA660 expires on 12/23/2020
    Temp data unpacked to C:\Users\caver\AppData\Local\Temp\winstoneEmbeddedWAR

    Server Addresses:
      http://localhost:8080/
      http://TomZen:8080/
    INFO - Monitoring local APRS devices
    INFO - Monitoring local APRS devices
    INFO - Monitoring local APRS devices
    INFO - Monitoring local APRS devices
    DEBUG - discovered serial port COM1
    DEBUG - discovered serial port COM1
    DEBUG - discovered serial port COM2
    DEBUG - discovered serial port COM2
    INFO - Adding serial port COM1 to pool
    INFO - Adding serial port COM1 to pool
    INFO - Adding serial port COM2 to pool
    INFO - Adding serial port COM2 to pool
    INFO - Connecting to APRS device COM1
    INFO - Connecting to APRS device COM1
    INFO - Connecting to APRS device COM2
    INFO - Connecting to APRS device COM2
    ERROR - Exception on APRS device COM1
    jssc.SerialPortException: Port name - COM1; Method name - openPort();
    Exception type - Port busy.
            at jssc.SerialPort.openPort(SerialPort.java:164)
            at
    org.sarsoft.location.service.APRSSerialThread.run(APRSSerialThread.java:35)
    ERROR - Exception on APRS device COM1
    jssc.SerialPortException: Port name - COM1; Method name - openPort();
    Exception type - Port busy.
            at jssc.SerialPort.openPort(SerialPort.java:164)
            at
    org.sarsoft.location.service.APRSSerialThread.run(APRSSerialThread.java:35)
    INFO - Disconnected from APRS device COM1
    INFO - Disconnected from APRS device COM1

  9. 9 Posted by caver456 on 30 Jun, 2020 02:00 PM

    caver456's Avatar

    also interesting - never thought about it before, but it may be that usage
    of the term 'fleetsync' is not appropriate: fleetsync is the data on the
    radio over the air waves. The base radio decodes that fleetsync data burst
    and spits it out to the com port as CID data, and/or GPS data in the form
    of NMEA sentences. Not sure if there's an actual term for what comes over
    the com port... just 'com port traffic'. Point being: hopefully nexedge
    radios and fleetsync radios both send identical com port data.

  10. 10 Posted by mvbanks on 30 Jun, 2020 02:44 PM

    mvbanks's Avatar

    I wish I could be more help by testing a known working configuration with the latest sar.jar but we moved away from fleetsync tracking when we last changed our radio load(s). We run the same load on all S.O. radios as Patrol etc. and re-configuring a new load, with the fleetsync option, has not been pursued. I will say, Nexedge radios were working along side the TK's, without an issue, with the caveat that we don't utilize any Nexedge, digital functionality.

  11. 11 Posted by John Pictin on 30 Jun, 2020 05:30 PM

    John Pictin's Avatar

    On the Nexedge radios you can choose to run Fleetsync 1/2 or Nexedge. From
    what I understand, the team that I belong to and Robin's team use the base
    same programming and we are currently set to Fleetsync 2. Unfortunately we
    are not on exactly on the same version as stuff gets updated one team at a
    time. Ben, our SAR radio guy, and I will be working to get the GPS stuff
    going soon so that we can roll out a new version that hopefully includes
    RadioLog support. I believe that GPS data is not being sent on transmit in
    Robin's radios. I have had this changed for my radios and KAS-10 was
    working fine with what was sent from the base radio. Unfortunately,
    RadioLog was not happy with the string sent from the base, and so I
    couldn't get to the point where RadioLog would send the info to SARTopo.

    I am going to go into our station and try a direct connection to SARTopo
    and see what happens. Thanks Tom, for your post, it helps a lot. I know
    that what we have coming from our base doesn't look like what you posted. I
    wish that I had access to the programming software and a couple of radios
    to massage our programming until it was playing nice with SARTopo and with
    RadioLog. Unfortunately the software for our radios isn't available to
    anyone but dealers, and a few others. It's a big pain in the a$$.

    J

  12. 12 Posted by RobinB on 30 Jun, 2020 07:31 PM

    RobinB's Avatar

    What I am seeing at the COM Port in my setup is similar but different to what Tom is reporting:

    $PKLDS,000642,V,3600.0000,N,13600.0000,E,783.9,180.7,250109,,00,100,1001,80,00,*11
    $PKLDS,235955,V,3600.0000,N,13600.0000,E,783.9,180.7,240109,,00,100,1002,80,00,*1E

    First line is from Unit 1, second is from Unit 2. The position is nonsense, as I am indoors and the GPS has no fix. KAS-10 interprets the lines from both Unit 1&2 as:

    80 3600.0000 N 13600.0000 E 783.9 180.7 V

  13. 13 Posted by John Pictin on 30 Jun, 2020 07:38 PM

    John Pictin's Avatar

    What are you using to capture the com port output? That looks nothing like
    the string I get. Do you know if it is an ANSI string or ASCII? I just want
    to be sure my terminal emulator is seeing the com traffic correctly.

    J

  14. 14 Posted by RobinB on 30 Jun, 2020 08:22 PM

    RobinB's Avatar

    Not sure string type. Can check later if I drop by the hall again.

    I used: ahttps://www.eltima.com/products/serial-port-monitor/ - free for 14 days so hopefully we can get this sorted out before then!

  15. Support Staff 15 Posted by mcosand on 30 Jun, 2020 08:37 PM

    mcosand's Avatar

    Hey everyone,

    There are currently two methods for sending FleetSync locations to SARTopo:
    1 - a base station connected to a serial port feeding data to SARTopo Desktop on the same machine (discussed below)
    2 - Using some intermediate program (like radiolog) to forward position reports to SARTopo (Desktop or online) over HTTP

    Positions sent to SARTopo Desktop will update any local maps that have Locators matching the incoming traffic. Those maps can then sync to SARTopo online and back down to Desktop instances in the same way that other map objects are synced back and forth. It is also possible to configure SARTopo Desktop to forward all the position reports from the serial port to another SARTopo instance (desktop or online), even if there are no local maps subscribed to those radio IDs.

    Especially on Windows, only one program can use a serial port at a time, so after verifying basic comms with the radio you should close other programs that may be using the port.

    To tell SARTopo to listen to the serial port with extra logging, make sure the following lines are in your properties file:

    sarsoft.location.aprs.local.enabled=true
    log4j.logger.org.sarsoft.location.service.APRSLocalEngine=INFO
    log4j.logger.org.sarsoft.location.service.APRSSerialThread=DEBUG
    
    If you need to set baud rate or other port parameters that can be done with:
    sarsoft.location.serial.COM7=1200,8,1,0
    

    With those properties set, you should start getting log information in your SARTopo Desktop window. I am listening to APRS instead of FleetSync, so I'm getting something like the following, showing the raw data coming off the serial port

    DEBUG - APRS data from COM7: KJ7NUK-8>APRS:!4711.60N/12215.84W[000/000/A=000000KJ7NUK Anytone 878UV
    

    Getting those log messages in your console are the major hurdle to get over in this setup. If you're not seeing them we need to work on figuring that out before trying to figure out why maps aren't updating.

  16. 16 Posted by caver456 on 30 Jun, 2020 10:33 PM

    caver456's Avatar

    Thanks Matt for jumping in with the clarification. I added all those lines
    in sar.properties but I still can't get option 1 (com port) working - maybe
    I need $PKLDS instead of $PKLSH? Interesting thing is that the ncssar
    kenwood setup doc, page 19, shows the settings to send all of $GPGGA,
    $GPRMC, $PKLDS, and $PKLSH. It was a long time ago when I wrote that, so I
    think we probably just send $PKLSH now; that's the only one that radiolog
    looks for and everything else is redundant. Is it possible that sartopo
    looks for $PKLDS but not $PKLSH?

    I just tried modifying the fleetsync emulator code to send $PKLDS instead
    of $PKLSH - made sure that the data is still bridging correctly, i.e. still
    showing up in radiolog. But, still no go in sartopo offline - no output on
    the terminal at all. If that's not it, maybe there's some leading or
    trailing characters that are missing or are extra?

    (John, this is ASCII, the NMEA sentences are semi-human-readable, like
    Robin showed)

  17. Support Staff 17 Posted by mcosand on 30 Jun, 2020 11:15 PM

    mcosand's Avatar

    With the APRSSerialThread set to DEBUG, you should see whatever sentence type the radio is sending ($GPGGA, $PKLDS, etc). Once those are showing up in the log, we can worry about picking the best one.

    Have you adjusted the COM port settings in the properties file? It looks like Kenwood radios are at 9600 baud, so you might try sarsoft.location.serial.COM2=9600,8,1,0

  18. 18 Posted by caver456 on 30 Jun, 2020 11:25 PM

    caver456's Avatar

    WIll give that a shot later - but, I'm sending on a virtual com port
    bridge, not from a real base radio, and I can confirm the data is getting
    in to the computer. Windows device manager shows the port settings are
    9600/8/N/1.

  19. 19 Posted by John Pictin on 01 Jul, 2020 12:17 AM

    John Pictin's Avatar

    Don't worry about it, it's ASCII. The port sniffer I was using was rather
    complex.

    John

  20. 20 Posted by caver456 on 01 Jul, 2020 12:25 AM

    caver456's Avatar

    Strange progress. Maybe some issue with the way windows handles the
    virtual com port with some sort of apparent buffering or locking or such
    (though radiolog processes it immediately, maybe this is a real issue to
    investigate?)

    This is all done with the virtual com port bridge in place COM1<-->COM2

    Noticed this behavior on accident. It's as if the COM2 data doesn't show
    up until COM1 is released. It behaves the same regardless of
    sarsoft.location.serial.COM2 parameters, and behaves the same even if that
    line is commented out:

    1. start fsTester (the data emulator)
    2. start sartopo offline
    3. view a saved map with the locator group added but no locators yet
    4. send some GPS data (on COM1) from fsTester. No output in the sartopo
    terminal, and no locator showing on the map.
    5. observe the subsequent sartopo port scan output (once a minute), still
    with no sign of com port data and no locator on the map.
    6. exit fsTester but leave sartopo running
    7. observe the subsequent sartopo port scan output DOES have the data that
    was sent, and the locator does show up on the map about 15 seconds after
    the com port scan.

    INFO - serial port COM1 no longer active; removing from pool
    INFO - serial port COM1 no longer active; removing from pool
    INFO - Adding serial port COM1 to pool
    INFO - Adding serial port COM1 to pool
    INFO - Connecting to APRS device COM1
    INFO - Connecting to APRS device COM1
    ERROR - Exception on APRS device COM1
    jssc.SerialPortException: Port name - COM1; Method name - openPort();
    Exception type - Port busy.
            at jssc.SerialPort.openPort(SerialPort.java:164)
            at
    org.sarsoft.location.service.APRSSerialThread.run(APRSSerialThread.java:35)
    ERROR - Exception on APRS device COM1
    jssc.SerialPortException: Port name - COM1; Method name - openPort();
    Exception type - Port busy.
            at jssc.SerialPort.openPort(SerialPort.java:164)
            at
    org.sarsoft.location.service.APRSSerialThread.run(APRSSerialThread.java:35)
    INFO - Disconnected from APRS device COM1
    INFO - Disconnected from APRS device COM1
    INFO - serial port COM1 no longer active; removing from pool
    INFO - serial port COM1 no longer active; removing from pool
    INFO - Adding serial port COM1 to pool
    INFO - Adding serial port COM1 to pool
    INFO - Connecting to APRS device COM1
    INFO - Connecting to APRS device COM1
    DEBUG - APRS data from COM2:
    $PKLDS,123456,A,3916.3368,N,12101.5763,W,,,,,00,100,2001,80,00,*05
    DEBUG - APRS data from COM2:
    $PKLDS,123456,A,3916.3368,N,12101.5763,W,,,,,00,100,2001,80,00,*05

    8. observe that after the above lines, no more com port scan lines show up
    - guessing this is because there are no other com ports in the pool,
    although it does keep trying to re-add COM1...? Does this mean that if you
    plug two radios in to two different com ports, it will only read data from
    one of them (the first one that has data present)?

  21. 21 Posted by caver456 on 01 Jul, 2020 01:10 AM

    caver456's Avatar

    some more data:
    - PKLDS or PKLSH both work for sartopo - didn't try any of the other
    sentence types
    - the start characters "\x02I" seem to prevent sartopo from recognizing
    PKLSH, but don't affect PKLDS; I can't swear to whether they really come in
    from the radio, but I'm pretty sure they do: fstester was built, by
    reverse-engineering the incoming com port data, to send those characters
    - the end character "\x03" seems to be OK; it does not prevent the locator
    from being drawn
    - the incoming com port data creates a new folder 'Callsigns' - so maybe
    the folder name is 'Locators' if by method 2 (http request) and 'Callsigns'
    if by method 1 (local com port) - does that sound correct?

    These variations do create a locator (with the
    buffering/locking/after-quitting-fstester behavior from the previous email):
    $PKLDS,123456,A,3916.3368,N,12101.5763,W,,,,,00,100,2001,80,00,*05
    $PKLDS,123456,A,3916.3368,N,12101.5763,W,,,,,00,100,2001,80,00,*05
    I$PKLDS,123456,A,3916.1047,N,12101.3905,W,,,,,00,100,2007,80,00,*05
    $PKLSH,3916.3236,N,12101.4878,W,123456,A,100,2004,*2D
    $PKLSH,3916.3236,N,12101.4878,W,123456,A,100,2004,*2D

    This variation does not create a locator:
    I$PKLSH,3916.2011,N,12101.6577,W,123456,A,100,2003,*2D

    I did not try any of the CID+GPS combos which look like this:
    I11002001100200110 I11002001100200110
    I$PKLDS,123456,A,3916.2772,N,12101.4746,W,,,,,00,100,2001,80,00,*05

  22. Support Staff 22 Posted by mcosand on 01 Jul, 2020 04:49 AM

    mcosand's Avatar

    Reading the source code, I wouldn't guess that one serial port would block another, though I'd need to confirm that we've tested that scenario. I'd guess that there's some sort of flow control when using the virtual comm port that's getting in our way and that the virtual comm port isn't quite analogous to directly connecting a base station.

    What you have written about the sentences that are processed as position updates looks correct. The parser works line by line, so the first line of the CID+GPS combo would be ignored, and the |$PKLDS would be read as it was in your earlier test.

    The callsigns folder is a list of locally heard radios that isn't map data (stored/synced with the map), but can help you identify stations that you want to use with Locators (which are stored/synced with the map). There's a decent chance the Callsigns folder will move into a data layer down the road.

  23. 23 Posted by caver456 on 01 Jul, 2020 01:25 PM

    caver456's Avatar

    Yeah that is strange behavior with the locking/buffering/whatevering.
    Obviously if everything else is working for other customers with actual
    radios, then there's no real need to address it, unless you all want to
    include a virtual serial port bridge for your internal development work.

    I tried the CID+GPS combo with PKLDS, it does make the callsign; combo with
    PKLSH does not make the callsign; this is the same behavior as GPS-only:
    PKLSH doesn't work with the prefix - it does show up in the terminal but
    doesn't make a callsign:
    DEBUG - APRS data from COM2: I11002011100201110 I11002011100201110
    I$PKLSH,3916.0618,N,12101.4042,W,123456,A,100,2011,*2D

    In all of these cases, the callsign didn't show up on the map until 15-30
    seconds after the data showed up on the terminal, which didn't happen until
    the next port-scan-time (1 minute intervals) after having exited fstester.
    Since I had to exit fstester, and can't restart it since com1 has been
    locked by sartopo during the most recent sartopo port scan, I'm not sure if
    subsequent calls would have showed up more quickly.

    Regarding Callsigns vs Locators, it sounds like fleetsync-via-http-request
    does get saved with the map, but fleetsync-via-local-com-port does not? We
    don't use APRS devices so I'm wondering if that distinction makes sense for
    APRS but not for fleetsync (Kenwood radios)? I would think Kenwood radio
    locators would want to be saved and handled the same regardless of whether
    by local com port or by http request...? The PK... sentences are kenwood
    proprietary so maybe that could be used to distinguish kenwood from other
    com port data? However it's possible to program the kenwood base radio to
    not send any of the PK... sentences and only use the standard GP...
    sentences.

    Anyway I think that clarifies things to the point where we can get back to
    Robin's initial issue:

    From Matt C's explanation, local com port traffic will only be read by
    sartopo desktop (formerly sartopo offline, sorry I keep using the old
    name), and not by sartopo.com, so that sounds like the ultimate answer to
    your question. Sorry for all the diversion and distraction and hijacking
    of your thread but hopefully it was all helpful! Hopefully with all this
    you should be seeing the callsigns on sartopo desktop using local com ports?

  24. 24 Posted by JohnP on 02 Jul, 2020 06:01 AM

    JohnP's Avatar

    Well, I took another stab at connecting it up and . . . . nothing.

    I don't get anything on the debug output. I tried running portmonitor and it sees nothing. so I tried another computer and another USB - Serial interface. I discovered some new things:

    1. The USB - Serial device I was using is no longer supported by Windows 10. It runs fine on windows 7, and apparently you can mess around and do some weird hacks to make it work. The manufacturer just decided that everyone using that flavor of the device needed to buy a new one, just because Windows now allows vendors to flip the switch on older devices and have Windows refuse to use them even though they are perfectly functional. Even installing older drivers didn't work.

    2. The Terminal monitor that I tried using refused to show me the data coming across the data port of a working USB-RS232 (made by Aten) adapter. Switching to MobaxTerm fixed that.

    3. The debug output of SARTopo showed absolutely nothing. It was seeing the com port data as gibberish, even though MobaxTerm reveals data that is human readable laced with gibberish.

    Conclusions:
    The output of my radio is somehow Fleetsync 2 compliant, because KAS-10 Kenwood's dispatch software, works flawlessly with it. That being said, it must not contain $PKLSH or $PKLDS NMEA strings as neither SARTopo nor Radiolog can read it.

    So, it's off to the radio shop for me and then I can try again.

  25. Julie closed this discussion on 16 Jul, 2020 05:32 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

20 Oct, 2020 02:39 AM
19 Oct, 2020 11:35 PM
19 Oct, 2020 07:09 PM
19 Oct, 2020 05:16 PM
19 Oct, 2020 04:51 AM