AOR AR-DV3 New Memory management software 1.0.0.0.

[oz1jua]

Be aware that the new Memory management software can´t write CTCSS code to scanner.
Even when select the correct CTCSS it will not send it to scanner.
When manuel set this in scanner it will read it but if you send it to scanner it is gone.
I can se when sending to scanner it flash brite with a CTS under the display.

When setting the CTCSS on a channel it overwrite the name of the channel name.
There is lot of space under and I do not understand why this space is not use for this info.
The same goes for DMR channel it also use the channel name space to show color code ect.
But this is only when select Dig.Decode. If you do not whant to overwrite the chanel name
then set Dig.Decode unselected.

 

[pb_lonny]

That CTCSS behaviour certainly sounds like something that needs to be looked at in the memory management software.

If the scanner can store and display the CTCSS correctly when it is programmed manually, but the setting disappears when the software writes the channel back to the scanner, that would strongly suggest the software isn't actually sending the CTCSS value correctly, despite the option being selected. The brief “CTS” indication during programming is interesting too.

I also agree with your point about channel names being overwritten when CTCSS or DMR information is displayed. It seems a shame to use valuable channel-name space for technical information when there appears to be unused space available elsewhere on the display.

Hopefully the developer can take a look at both issues. The ability to properly manage CTCSS/DMR settings is one of the main reasons for using programming software in the first place, so those settings need to reliably make it from the software into the scanner.

 

[oz1jua]

**Conclusion**

The CTCSS bug in AR-DV3 Data Utility is a **software defect in `AR_DV3_DataUtility.exe`**, not a firmware issue.

Evidence:
- Manual CTCSS entry on the AR-DV3 works and is stored correctly → firmware handles CTCSS fine.
- Data Utility **reads** CTCSS from the radio correctly → the read-path is OK.
- Data Utility **fails to write** CTCSS back → the write-path is broken.
- "CTS" briefly blinks during programming → the software *tries* to communicate, but the command is wrong or missing.

Root cause (per the AR-DV3 command reference):
- Memory channels are written with `MX...`, and the MX format contains **no CTCSS fields**.
- CTCSS is controlled by **separate commands**: `CI0` (off), `CI1` (on), `CI2` (reverse), and `CNnn` (tone selection, where `nn` is the tone index — e.g. `CN14` = 100.0 Hz, `CN16` = 107.2 Hz).
- The Delphi program almost certainly tries to embed CTCSS into `MX`, or omits the `CI`/`CN` commands entirely on write. Either way, the tone is never stored.

Most likely failure modes (in order of probability):
1. `CI`/`CN` commands are never sent on write.
2. `CN` is sent with the raw frequency (e.g. `CN885` for 88.5 Hz) instead of the correct tone index.
3. Wrong command order — `CN` sent *before* `MX`, so `MX` wipes the tone.
4. `CI0` (off) sent instead of `CI1` (on).

How to confirm (fastest path):
- Run a serial port monitor between PC and AR-DV3.
- Write one memory channel with CTCSS 88.5 Hz.
- Capture the full command sequence.
- If no `CN` command appears → case 1. If `CN` appears with a wrong value → case 2. If `CN` appears before `MX` → case 3. If `CI0` appears → case 4.

Fixes:
- No setting inside Data Utility can fix this — it is a code-level bug.
- Real options: patch the EXE by report to AOR, or enter CTCSS manually on the radio until AOR releases a corrected version.