DevelopersAdd a Radio » History » Version 1
Tom Hayward, 03/27/2014 09:24 PM
1 | 1 | Tom Hayward | h1. Add a Radio |
---|---|---|---|
2 | |||
3 | You've got a radio that's not in Chirp, a little bit of software development experience, and you want to add that radio to Chirp. Here's what you'll need: |
||
4 | |||
5 | * a subscription to the "chirp_devel mailing list":http://intrepid.danplanet.com/mailman/listinfo/chirp_devel |
||
6 | * a Python + PyGTK development environment |
||
7 | * radio |
||
8 | * programming cable |
||
9 | |||
10 | h2. Setting up the development environment |
||
11 | |||
12 | Most Chirp contributors develop in Ubuntu Linux. Mainly, because we're lazy. Ubuntu comes with almost everything needed to develop for Chirp: Python, PyGTK, and a text editor. The one missing piece is Mercurial, for source code management. |
||
13 | |||
14 | To install Mercurial: |
||
15 | |||
16 | sudo apt-get install mercurial |
||
17 | |||
18 | If you've never used Mercurial before, please read [[DevelopersProcess]]. Actually, even if you have used Mercurial, that's a good document to read. It describes how to get the Chirp source code and generate a patch in the required format for inclusion in Chirp. |
||
19 | |||
20 | If you want to develop in another operating system, you're on your own. This guide isn't going to cover it. Here's a guide for Windows: [[DevelopersWin32Environment]]. |
||
21 | |||
22 | h2. Look over some existing code |
||
23 | |||
24 | Read source:chirp/template.py. The whole thing. |
||
25 | |||
26 | h2. Write the download/upload routines |
||
27 | |||
28 | h3. Sniffing the protocol used by existing software |
||
29 | |||
30 | If you have other programming software for your radio, such as the software from the manufacturer, you can sniff the programming protocol with "Portmon":http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx. Typically, radio programming software is writtne for Windows, and Portmon is a Windows utility. |
||
31 | |||
32 | Start with a read. |
||
33 | |||
34 | # Click Read in the official software |
||
35 | # Watch the output of Portmon after you click Read |
||
36 | # Look for a line that sets the BAUD RATE. Sometimes there are a few of them. |
||
37 | # Look for a WRITE line with a few data bytes. This is probably the command to tell the radio to start sending data. |
||
38 | # Look for READ lines with lots of data bytes after them. This is probably the memory contents of the radio being downloaded |
||
39 | # You're a smart developer. You should be able to figure out the protocol from here! |
||
40 | |||
41 | h3. Using existing Chirp code |
||
42 | |||
43 | If the radio you're developing for doesn't have existing programming software, you won't be able to use the above reverse engineering technique. Most radio manufacturers use a common protocol across most of their radios. Because Chirp supports so many manufacturers, there's a chance an existing radio driver has a download routine that will work with your new radio. This is especially true with Yaesu, which don't really even have a protocol. They just dump their memory. All you need to figure out is the baud rate and the memory size (and baud rate is usually 9600). |
||
44 | |||
45 | Choose a radio driver that you think might be similar. If you were going to add the VX9, you might start with the VX8 driver: |
||
46 | |||
47 | cd chirp.hg/chirp |
||
48 | sed s/VX8/VX9/g vx8.py > vx9.py |
||
49 | |||
50 | Increase the @_memsize@ variable significantly. The goal is to read more data than the radio sends. |
||
51 | |||
52 | Launch Chirp and start a download with your new radio driver. Did it work, sort of? Save the .img. |
||
53 | |||
54 | Now we're going to determine the @_memsize@. Open the .img in a hex editor: |
||
55 | |||
56 | hexdump -C VX9_oversize.img | less |
||
57 | |||
58 | Look towards the end of the file for the offset where the data becomes all zeros. This is your @_memsize@. The radio has stopped sending data, but Chirp was still "reading". Change @_memsize@ in your driver so that Chirp reads the same number of bytes the radio is sending. |
||
59 | |||
60 | h2. Map the memory blob |
||
61 | |||
62 | To map the memory layout, you're going to make a small change on the radio, do a download, then look for differences. Do this over and over until you have the whole memory layout mapped. |
||
63 | |||
64 | Here's a little helper script I use for the comparisons: |
||
65 | |||
66 | @hexdiff.sh:@ |
||
67 | <pre> |
||
68 | #!/bin/sh |
||
69 | |||
70 | A=`mktemp` |
||
71 | B=`mktemp` |
||
72 | |||
73 | hexdump -C $1 > $A |
||
74 | hexdump -C $2 > $B |
||
75 | diff $A $B | less |
||
76 | rm $A $B |
||
77 | </pre> |
||
78 | |||
79 | # Find the first channel |
||
80 | # Find the second channel |
||
81 | # The offset between the two is your memory channel struct size |
||
82 | # Find the last channel. Hopefully its offset is struct size * advertised number of channels away from the first channel! |
||
83 | |||
84 | You'll probably start off with something like this: |
||
85 | <pre> |
||
86 | MEM_FORMAT = """ |
||
87 | #seekto 0xb00; |
||
88 | struct { |
||
89 | u32 freq; |
||
90 | u8 unknown1; |
||
91 | u8 unknown2; |
||
92 | u8 unknown3; |
||
93 | char name[8]; |
||
94 | } memory[200]; |
||
95 | """ |
||
96 | </pre> |
||
97 | @0xb00@ is the location of the first memory channel. |
||
98 | @200@ is the number of channels the radio supports. |
||
99 | @unknown1@, @unknown2@, and @unknown3@ are for memory-specific settings (e.g., tone) that you haven't sussed out yet. |
||
100 | |||
101 | h2. Write @get_memory()@ |
||
102 | |||
103 | h2. Write @set_memory()@ |
||
104 | |||
105 | h2. Submit code to chirp_devel |
||
106 | |||
107 | Send a hg patch to the developer mailing list for review. We'll pick it apart and give you a list of things that can be improved before inclusion in Chirp. Don't take it personally! Our goal is to produce high quality software through peer review. |