[chirp_devel] Getting started with the Alinco DR-635
Hello all.
I have two Alinco DR-635T radios and am looking to CHIRP as a way to manage the memories between them. I recently purchased an interface cable and decided to test things this morning. I am aware the radio is presently not supported and have read bug 313 and the three other bugs requesting support for this radio.
I added the patch supplied by Richard Shaw in bug 313 to chirp/drivers/alinco.py with a modification to the 2 meter range changing 335000000 to 136000000. After verifying my adapter is to be found at /dev/ttyUSB0, I connected the cable to the powered off radio and then powered it back on. As my modified version of CHIRP now shows the DR-635T, I tried to download from it and received the following failure in the terminal I launched chirpw from:
ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/home/nate/git/chirp.hg/chirp/ui/clone.py", line 238, in run self.__radio.sync_in() File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 196, in sync_in self._mmap = self._download(self._memsize) File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 138, in _download data += self._download_chunk(addr) File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 116, in _download_chunk raise errors.RadioError("No response from radio") RadioError: No response from radio
ERROR: ---------------- ERROR: Clone failed: No response from radio ERROR: --- Exception Dialog: No response from radio --- ERROR: None
I also tried setting the radio into clone mode as the master while attempting to read from CHIRP and received the same error text as above.
What is my next step for trying to read the memory data?
This is new territory for me as I've been involved with the Hamlib project for some time and am used to working with (mostly) documented protocols. As I see it the radio *should* be capable of being supported by CHIRP as a proprietary program claims support.
73, Nate N0NB
Nate,
I recently went through a similar experience with the TH-7800 driver. I used Serial Port Monitor 6 to "sniff" the serial traffic while uploading and downloading the radio via the OEM software. The TYT software is really limited, but it does that part well. Once I figured out the protocol, it was easy to modify the a very similar driver to work. I'm betting Alinco has their own software you can do this with. Good luck! :)
Regards, Nathan
On Sun, Jun 12, 2016 at 7:45 AM, Nate Bargmann via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hello all.
I have two Alinco DR-635T radios and am looking to CHIRP as a way to manage the memories between them. I recently purchased an interface cable and decided to test things this morning. I am aware the radio is presently not supported and have read bug 313 and the three other bugs requesting support for this radio.
I added the patch supplied by Richard Shaw in bug 313 to chirp/drivers/alinco.py with a modification to the 2 meter range changing 335000000 to 136000000. After verifying my adapter is to be found at /dev/ttyUSB0, I connected the cable to the powered off radio and then powered it back on. As my modified version of CHIRP now shows the DR-635T, I tried to download from it and received the following failure in the terminal I launched chirpw from:
ERROR: -- Exception: -- ERROR: Traceback (most recent call last): File "/home/nate/git/chirp.hg/chirp/ui/clone.py", line 238, in run self.__radio.sync_in() File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 196, in sync_in self._mmap = self._download(self._memsize) File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 138, in _download data += self._download_chunk(addr) File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 116, in _download_chunk raise errors.RadioError("No response from radio") RadioError: No response from radio
ERROR: ---------------- ERROR: Clone failed: No response from radio ERROR: --- Exception Dialog: No response from radio --- ERROR: None
I also tried setting the radio into clone mode as the master while attempting to read from CHIRP and received the same error text as above.
What is my next step for trying to read the memory data?
This is new territory for me as I've been involved with the Hamlib project for some time and am used to working with (mostly) documented protocols. As I see it the radio *should* be capable of being supported by CHIRP as a proprietary program claims support.
73, Nate N0NB
--
"The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
* On 2016 12 Jun 11:10 -0500, Nathan Crapo wrote:
Nate,
I recently went through a similar experience with the TH-7800 driver. I used Serial Port Monitor 6 to "sniff" the serial traffic while uploading and downloading the radio via the OEM software. The TYT software is really limited, but it does that part well. Once I figured out the protocol, it was easy to modify the a very similar driver to work. I'm betting Alinco has their own software you can do this with. Good luck! :)
I see that "Serial Port Monitor 6" is for Windows. I am using Devuan (Debian) Linux so that is probably out.
Alinco shows no OEM software for the DR-635T.
73, Nate
Looks like rtsystems.com has software for $49.00. :( And it's Windows only software, too. One route would be to borrow/eval a copy of that, install it on a VM along with Serial Port Monitor and get the protocol. Then add support to Chirp and you'd give cross-platform programmability to everyone. Maybe you're willing to make a $49 sacrifice to enable everyone? I know a lot of people like CHIRP because it's a universal tool for all their radios.
Another route is to "fuzz" the radio. You could form your stimulus with the existing Alinco radio to speed things up a bunch. It looks like the protocol for most models differ pretty minimally for a given vendor.
You're right: Serial Port Monitor is Windows only. Unfortunately a lot of the OEM programming software is Windows only as well. FWIW, Serial Port Monitor did do a really nice job of documenting the protocol.
I'm not a Windows fan, either. I don't even use it for work much. I used a Windows 7 VM for the initial protocol snooping, and then carried out the remaining dev in MacOS and Linux. It's pretty easy to "pipe" your USB serial dongles from the host to guest OS with VirtualBox, for example. I'm sure other VM technology will do this as well.
Regards, Nathan
On Sun, Jun 12, 2016 at 10:36 AM, Nate Bargmann via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
- On 2016 12 Jun 11:10 -0500, Nathan Crapo wrote:
Nate,
I recently went through a similar experience with the TH-7800 driver. I used Serial Port Monitor 6 to "sniff" the serial traffic while uploading and downloading the radio via the OEM software. The TYT software is
really
limited, but it does that part well. Once I figured out the protocol, it was easy to modify the a very similar driver to work. I'm betting Alinco has their own software you can do this with. Good luck! :)
I see that "Serial Port Monitor 6" is for Windows. I am using Devuan (Debian) Linux so that is probably out.
Alinco shows no OEM software for the DR-635T.
73, Nate
--
"The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true."
Ham radio, Linux, bikes, and more: http://www.n0nb.us _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
There was a thread about this recently about using Wireshark as an alternative here:
http://intrepid.danplanet.com/pipermail/chirp_devel/2016-April/003966.html
--David KI6ZHD
On 06/12/2016 09:53 AM, Nathan Crapo via chirp_devel wrote:
Looks like rtsystems.com http://rtsystems.com has software for $49.00. :( And it's Windows only software, too. One route would be to borrow/eval a copy of that, install it on a VM along with Serial Port Monitor and get the protocol. Then add support to Chirp and you'd give cross-platform programmability to everyone. Maybe you're willing to make a $49 sacrifice to enable everyone? I know a lot of people like CHIRP because it's a universal tool for all their radios.
Another route is to "fuzz" the radio. You could form your stimulus with the existing Alinco radio to speed things up a bunch. It looks like the protocol for most models differ pretty minimally for a given vendor.
You're right: Serial Port Monitor is Windows only. Unfortunately a lot of the OEM programming software is Windows only as well. FWIW, Serial Port Monitor did do a really nice job of documenting the protocol.
I'm not a Windows fan, either. I don't even use it for work much. I used a Windows 7 VM for the initial protocol snooping, and then carried out the remaining dev in MacOS and Linux. It's pretty easy to "pipe" your USB serial dongles from the host to guest OS with VirtualBox, for example. I'm sure other VM technology will do this as well.
Now I am getting somewhere. Apparently I didn't have the plug pressed into the jack all the way. D'oh!
At least now I am seeing responses from the radio to the query. I've logged the communication using chirpc and have attached it to this message.
73, Nate
I am revisiting this after a bit of a break.
I think I have narrowed down some things. For example, it seems as though this radio simply responds with a '\n' rather than an "OK" string like the other Alinco models Here is where I am at now:
$ ./chirpc --log ./dr635.txt -r Alinco_DR635T --serial=/dev/ttyUSB0 --mmap=dr635t.img --download-mmap
Contents of dr635.txt:
[2016-07-25 22:20:42,234] chirp.logger - DEBUG: log level=10 [2016-07-25 22:20:42,235] chirp.logger - DEBUG: CHIRP 0.3.0dev on Linux - Devuan GNU/Linux 1 (Python 2.7.9) [2016-07-25 22:20:42,235] chirpc - INFO: opening /dev/ttyUSB0 at 9600 [2016-07-25 22:20:42,236] chirp.drivers.alinco - DEBUG: PC->R: ( 7) 'DR635\r\n' [2016-07-25 22:20:42,746] chirp.drivers.alinco - DEBUG: R->PC: ( 1) '\n' [2016-07-25 22:20:42,746] chirp.drivers.alinco - DEBUG: PC->R: (11) 'AL~F0000R\r\n' [2016-07-25 22:20:42,808] chirp.drivers.alinco - DEBUG: R->PC: (41) '\r\nA533553C0000000000000000000000000000000' [2016-07-25 22:20:42,808] chirpc - ERROR: Unexpected response from radio Traceback (most recent call last): File "./chirpc", line 377, in <module> radio.sync_in() File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 197, in sync_in self._mmap = self._download(self._memsize) File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 138, in _download data += self._download_chunk(addr) File "/home/nate/git/chirp.hg/chirp/drivers/alinco.py", line 118, in _download_chunk raise errors.RadioError("Unexpected response from radio") RadioError: Unexpected response from radio
The response to the AL-F0000R command seems consistent and is encouraging.
However, I am not at all up to speed on Python (I'm a C guy) and it appears as though the _identify() method in the AlincoStyleRadio() class needs to be overridden by the DR635Radio() class I'm trying to develop. I've tried various incorrect ways to do the override but am obviously missing something as I can change the tested response string in _identify() method, but then it's broken for all other models.
Is someone willing to help by writing the proper code that I can test? So far I have made it to:
@directory.register class DR635Radio(DRx35Radio): """Alinco DR635""" VENDOR = "Alinco" MODEL = "DR635T"
_model = "DR635" _memsize = 8192 _range = [(136000000, 174000000), (335000000, 480000000)] _power_levels = [chirp_common.PowerLevel("Low", watts=5.00), chirp_common.PowerLevel("Med", watts=20.00), chirp_common.PowerLevel("High", watts=50.00)]
@classmethod def match_model(cls, filedata, filename): return len(filedata) == cls._memsize and \ filedata[0x64] == chr(0x00) and filedata[0x65] == chr(0x00)
def _DRx35Radio__identify(self): for _i in range(0, 3): self._send("%s\r\n" % self._model) resp = self._read(16) if resp == '\n': return True time.sleep(1)
return False
73, Nate
participants (3)
-
David Ranch -
Nate Bargmann -
Nathan Crapo