Feature #11857
openDR-735 Memory Range
0%
Description
The DR-735 system works well, except for the range is a bit off.
Alinco uses 0-1413.
0-999 is normal channels.
1000-1099 is Left only channels (they won't show on the right side of radio) - label L## (## being the last two digits of number)
1100-1199 is right only channels (Same as left, but for right - I use them for packet/data channels) - label r## (## being the last two digits of number)
1200-1209 is P#A/P#B channels - programmable scan pairs - I don't know how they work. - Label P#A and P#b (1200 is P1A, 1201 is P1b, etc)
1210-1211 is Auto Program Scan L and Auto Program Scan H - Again, don't know how they work. - Label APL, APH
1212 - Call Channel VHF (2M) - Label CAV
1213 - Call Channel UHF (440) - Label CAU
1214-1413 - d00-d99 pairs (1214/1215 is label d00, etc) - for dual Memory channels - don't know how they work.
Can we get the range expanded? so I can have at least 1000-1199 + 1212 and 1213? the ranges on this line act the same as 0-999 - accept data just like normal channels.
Bonus if we could get them labeled correctly
Thanks
Files
| alinco_dr735t.py (15.7 KB) alinco_dr735t.py | |||
| alinco_dr735t.py (15.9 KB) alinco_dr735t.py | |||
| config.txt (703 Bytes) config.txt | |||
| Alinco_DR735T_20250227.img (64.2 KB) Alinco_DR735T_20250227.img | |||
| win_system_info.txt (70 KB) win_system_info.txt | |||
| debug_log.txt (129 KB) debug_log.txt | |||
| Untitled.png (38.3 KB) Untitled.png | |||
| Untitled.png (38.3 KB) Untitled.png | Menu | ||
| AL-Read (223 KB) AL-Read | Full Read cycle | ||
| AL-Write (404 KB) AL-Write | Full Write cycle |
Updated by Dan Smith about 1 month ago
- File alinco_dr735t.py alinco_dr735t.py added
Can you try the attached with LoadingTestModules ?
If it works like I hope, you'll just get the extra channels numbered as you have them above. If so (and you can edit them as expected) then I can make them properly special.
Updated by Brendan Keyport about 1 month ago
Around 1023 it popped this error:
[2025-02-27 09:47:53,088] chirp.logger - DEBUG: CHIRP next-20250221 on Win32 (Unknown 10.0:26100) (Python 3.10.8)
[2025-02-27 09:47:53,545] chirp.wxui - DEBUG: Using locale: en_US (276)
[2025-02-27 09:47:53,547] chirp.wxui - DEBUG: Translation loaded=True for CHIRP: en_US (bg_BG,de,el,en_US,es,fr,hu,it,ja_JP,nl,pl,pt_BR,ru,tr_TR,uk_UA,zh_CN) from C:\Program Files (x86)\CHIRP\chirp\locale
[2025-02-27 09:47:53,550] chirp.wxui - DEBUG: Translation loaded=False for wxstd: en_US (af,an,ar,ca,ca@valencia,co,cs,da,de,el,es,eu,fa_IR,fi,fr,gl_ES,hi,hr,hu,id,it,ja,ka,ko_KR,lt,lv,ms,nb,ne,nl,pl,pt,pt_BR,ro,ru,sk,sl,sq,sv,ta,tr,uk,vi,zh_CN,zh_TW)
[2025-02-27 09:47:54,012] main - INFO: Python/3.10.8 // Windows/Windows-10-10.0.26100-SP0 // CHIRP/next-20250221 // wx/4.2.0 msw (phoenix) wxWidgets 3.2.0
[2025-02-27 09:47:54,159] chirp.wxui.main - DEBUG: Recent is now ['C:\Users\brend\OneDrive\Documents\Baofeng_UV-5R_20250218.img']
[2025-02-27 09:47:54,338] chirp.wxui.main - INFO: Server reports next-20250221 is latest
[2025-02-27 09:48:16,933] chirp.wxui.developer - DEBUG: Fetched attachments for issue 11857 (status 200)
[2025-02-27 09:48:16,933] chirp.wxui.developer - DEBUG: Found 1 valid module attachments from issue 11857
[2025-02-27 09:48:19,685] chirp.wxui.developer - DEBUG: Fetched info for user 3 (status 200)
[2025-02-27 09:48:19,685] chirp.wxui.developer - DEBUG: User chose attachment {'id': 12597, 'filename': 'alinco_dr735t.py', 'filesize': 16095, 'content_type': 'text/x-python-script', 'description': '', 'content_url': 'https://chirpmyradio.com/attachments/download/12597/alinco_dr735t.py', 'author': {'id': 3, 'name': 'Dan Smith'}, 'created_on': '2025-02-27T00:14:23Z'}
[2025-02-27 09:48:19,685] chirp.wxui.developer - DEBUG: Fetching attachment URL https://chirpmyradio.com/attachments/download/12597/alinco_dr735t.py
[2025-02-27 09:48:19,853] chirp.wxui.developer - DEBUG: Wrote attachment to C:\Users\brend\AppData\Local\Temp\loaded-12597-e7ia4tip.py
[2025-02-27 09:48:19,854] chirp.directory - INFO: driver re-registration enabled
[2025-02-27 09:48:19,866] chirp.wxui.main - INFO: Loading module C:\Users\brend\AppData\Local\Temp\loaded-12597-e7ia4tip.py SHA256 2d7f96033dbef4dc22c1515acf68cd8581f72e684c787d0b5d516a21041cc5dd
[2025-02-27 09:48:19,869] chirp.directory - WARNING: Replacing existing driver id `Alinco_DR735T'
[2025-02-27 09:48:41,974] chirp.wxui.clone - DEBUG: All system ports: [{'device': 'COM1', 'name': 'COM1', 'description': 'Communications Port (COM1)', 'hwid': 'ACPI\PNP0501\0', 'vid': None, 'pid': None, 'serial_number': None, 'location': None, 'manufacturer': '(Standard port types)', 'product': None, 'interface': None}, {'device': 'COM4', 'name': 'COM4', 'description': 'USB Serial Port (COM4)', 'hwid': 'USB VID:PID=0403:6001 SER=6', 'vid': 1027, 'pid': 24577, 'serial_number': '6', 'location': None, 'manufacturer': 'FTDI', 'product': None, 'interface': None}]
[2025-02-27 09:48:42,084] chirp.wxui.clone - DEBUG: Automatically chose port COM4 as it is last-used for Alinco:DR735T
[2025-02-27 09:48:44,165] chirp.wxui.clone - DEBUG: Using port 'COM4'
[2025-02-27 09:48:44,165] chirp.wxui.clone - DEBUG: Selected
[2025-02-27 09:48:44,179] chirp.wxui.clone - DEBUG: Serial opened: Serial
[2025-02-27 09:48:44,180] chirp.wxui.clone - DEBUG: Recorded last-used port COM4 for Alinco:DR735T
[2025-02-27 09:48:44,194] chirp.loaded.loaded-12597-e7ia4tip - DEBUG: Model string is 000: 44 52 37 33 35 54 4e DR735TN.
[2025-02-27 09:49:39,440] chirp.wxui.clone - ERROR: Failed to clone: Failed to download from radio: name 'exit' is not defined
Traceback (most recent call last):
File "C:\Users\brend\AppData\Local\Temp\loaded-12597-e7ia4tip.py", line 201, in sync_in
self._mmap = self.do_download()
File "C:\Users\brend\AppData\Local\Temp\loaded-12597-e7ia4tip.py", line 150, in do_download
exit(1)
NameError: name 'exit' is not defined
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "chirp\wxui\clone.py", line 94, in run
File "C:\Users\brend\AppData\Local\Temp\loaded-12597-e7ia4tip.py", line 203, in sync_in
raise errors.RadioError(f"Failed to download from radio: {exc}")
chirp.errors.RadioError: Failed to download from radio: name 'exit' is not defined
[2025-02-27 09:50:19,144] chirp.wxui.clone - WARNING: Stopping clone thread
Updated by Dan Smith about 1 month ago
- File alinco_dr735t.py alinco_dr735t.py added
Okay the reason it fails at 1023 is because at 1024 the memory address rolls over to another digit. I'm guessing the radio has a different command to ask for high addresses, but without someone sniffing the OEM protocol, I won't be able to help with that.
Attached is a version that logs more information, which might be worth running. If you do, it's most helpful if you use the inbuilt reporting tool to send a debug log to this issue as it includes more information and is more consumable for me. See How_To_Report_Issues.
Updated by Brendan Keyport about 1 month ago
- File config.txt config.txt added
- File Alinco_DR735T_20250227.img Alinco_DR735T_20250227.img added
- File win_system_info.txt win_system_info.txt added
- File debug_log.txt debug_log.txt added
[Uploaded from CHIRP next-20250221]
Here's the log on the new version - it doesn't appear to do anything above 1000.
All numbers above 1000 are !#### and in red and stops at 1198.
Also, this one passed 1023, but slowed WAY down. Missed where it stopped.
If you have a way to sniff the OEM protocol, I'd be happy to catch it for you.
Updated by Dan Smith about 1 month ago
Yeah, that is exactly what I expected, after 1023 it just gets no response from the radio because the command was invalid. Hits the timeout, which is why it's slow.
I don't have any way to capture the OEM software that I can give you other than serial proxies, cables, etc. It's pretty rough on 64-bit windows.
Updated by Brendan Keyport about 1 month ago
- File Untitled.png Untitled.png added
I have a piece of software called Device Monitoring Studio that is able to grab the data stream. here's a list of what streams it can grab - I've got a few logs already - they're hex dumps. Would this help?
Updated by Brendan Keyport about 1 month ago
- File Untitled.png Untitled.png added
Just in case it's completely unreadable.
Updated by Dan Smith about 1 month ago
None of those match what CHIRP is actually doing. There's a serial stream emulated on top of the underlying USB packets. Hex dumps of the USB packets would be a lot of work to turn into the stream we're actually operating at. Other people have used wireshark to sniff the USB communication (probably similar to you're going to get) and I've never seen anything useful out of them. But, feel free to attach some things and I can have a look. I probably won't be able to spend much time on it if it's not obvious though.
Updated by Brendan Keyport 26 days ago
I think I might have what you need - A snippet of a read run:
AL~
AL~
OK
AL~WHO
AL~WHO
DR735TN
AL~EEPEL0000R
AL~EEPEL0000R
55000000C0B7BB08000000000000000000000100800000004F583C3A454500000000000000000000000000000000000000000000000000000000000000000000
AL~EEPEL0040R
AL~EEPEL0040R
55000000A04BC008C027090001010D0000000100800000004437453E3D0000000000000000000000000000000000000000000000000000000000000000000000
AL~EEPEL0080R
AL~EEPEL0080R
A snippet of a write run
AL~WHO
AL~WHO
DR735TN
AL~DR735J
AL~DR735J
OK
AL~EEPEL0000W55000000C0B7BB08000000000000000000000100800000004F583C3A454500000000000000000000000000000000000000000000000000000000000000000000
AL~EEPEL0000W55000000C0B7BB08000000000000000000000100800000004F583C3A454500000000000000000000000000000000000000000000000000000000000000000000
OK
--- are these the actual com data? If so I can upload the files fully.
Updated by Brendan Keyport 26 days ago
here's the files - I have things programmed into rXX - Packet stations and the like "APRS" and "P-XXXX" are the channel names.