KB8ZQZ's Syntor X miscellany page

Background: In addition to being a ham, I'm a unix system administrator. A friend (KC8PUN) introduced me to the Syntor X radio. I obtained a few radios and started working to convert them to the ham band. I quickly realized that I needed software to generate code plugs. I found that there were various bugs in the packages which were freely available, and that they all wanted DOS or Windows operating environments. I set out to build a unix program to generate code plugs, leaning heavily on the work of Mike Blenderman and Paul Kasley.

What's here?
syntorxgen - A code plug generator for Unix &c.

Syntorxgen is a code plug generator, unix style. It reads an input file containing configuration directives and produces a code plug file in one of several formats. Since the format is text based, it can be easily understood by humans, readily generated by other programs or scripts, and lends itself to mass changes with a simple editor. The package also includes a plug decoder which produces syntorxgen input files, a few perl scripts for generating test ROMs, some sample input files, etc. Syntorxgen plus an eeprom programmer replace the Motorola suitcase programmer, and are more flexible.

Syntorxgen should be reasonably portable. Binaries are provided for MS-DOS, Windows, Linux (RPM, .tar.gz and .deb formats), Solaris, FreeBSD and NetBSD. Mac OS X anyone? AIX? :-)

MPL support is untested. Talkaround on 800 MHz radios is not properly tested, due to questionable hardware, but normal 800 transmit works correctly.

Changes:

Version 1.50rel: DPL parity bits are no longer looked up in a table; instead they are calculated. This should result in exactly the same bit patterns as are generated by Motorola programming tools.

Version 1.31rel: The big fix is that floating point rounding errors which were breaking certain frequency and PL calculations should be fixed. The symptom was messages like "no valid ref. frequencies for 145.38999123123" For ease of use, you can now specify "mode" without a number, and the program will assign the next one in sequence. The program incorrectly claimed that 203.3 was a standard PL; this is now corrected in code and documentation to use 203.5. Finally for those who are hacking on the hardware, v-bit splits can be set per mode, and the transmit/receive usage can be inverted; also, band upper limits are now configurable. These additions should make it easier to retune radios into different bands, and to swap VCO boards among radios of different ranges.

The binary packages below now include binaries and documentation. However, you may still want the source archive to get additional utilities and sample data files.

The current source code (v1.50rel).

A Debian package in .deb format (v1.50rel) is available. This was built under Sid.

A Linux package in RPM format (v1.50rel) is available. This was built from the .deb using the alien tool.

A OpenBSD package in .tar.gz format (v1.50rel)

A Linux binary package in .tar.gz format (v1.50rel) is available. It was built under Debian Sid.

A NetBSD binary package (v1.31rel) is available. This was built under NetBSD 1.6.

A FreeBSD binary package (v1.31rel) is available. This was built under FreeBSD 4.8.

A Solaris binary package (v1.31rel) is available. This was built under Solaris 8.

A Windows binary package (v1.31rel) is available. This was built using the Cygwin package.

A VAX/VMS binary package (v1.31rel) is available. This was built by hand using VMS ports of Bison and Flex, and the Compaq C compiler. These are not well tested; it's been a long time since my VAX days.

Are we having portability fun yet?

The documentation for syntorxgen, syntorxdecode and the syntorxgen input file format is available.

An archive of old versions of syntorxgen can be found here.

You may find Peter Miller's srecord package useful for manipulating hex files in conjunction with syntorxgen.

Experiments in DPL coding

I want syntorxgen to be as complete as possible, so included support for DPL in the program. I constructed a code plug for testing functionality of all the radio features and was working my way through it with a test radio. The only radio I own (other than the Motorola gear) which does DPL is a Yaesu VX-5R, so that's what I used to test my DPL coding. I immediately found that it didn't work.

After a couple of weeks of intermittent fiddling and a fair amount of gnashing of teeth, I discovered that, though consensus seems to be that the settings of certain bits in the code plug are irrelevant (all ones are the suggested value), in fact Motorola sets them to other values. After inquiries in various quarters failed to turn up anyone who could explain the problem I'd seen, I broke down and tried all possible bit patterns for all DPL codes supported by the VX-5R.

I constructed a table of my results. The format of the list is as follows: the first number is the DPL code. Any subsequent numbers are the integer values of any bit patterns which appeared to work with the VX-5R. That is, if the number 2 appears, it represents the bit pattern 010. If no patterns appear, I was unable to test that DPL code. If one appears, only one worked. If more than one appears, the first one listed was the best (opened squelch fastest, and was most reliable). In a few cases, there seemed to be more than one code which worked equally well.

An interesting correspondence is the fact that the pattern I identified for DPL codes 205, 271 and 606 match the patterns Motorola generated for those codes, based on my analysis of several factory generated ROMs.

Mike Blenderman suggested that having the receive radio next to the transmit radio might cause decoding problems due to stray RF. I had done exactly what he was saying I should avoid, so I enlisted help (KC8PUN; you infect someone with one of these obsessions, you gotta help them out...) and re-did a small sample. This time, the receivers were two miles away, and there were two: a Kenwood D-700, and a different Yaesu VX-5R. We found that the Kenwood is completely oblivious to which bit pattern is used. The second VX-5R, however, exhibited exactly the same behavior as mine, including wanting bit pattern 110 for DPL code 271.

I should also mention that Mike did extensive testing to arrive at the recommendation to use bit pattern 111. Thus, it would appear that the VX-5R does something very few other radios do.

At this point, I have built a table-driven way of generating the correct code. What I'd really prefer, though, is to figure out how the algorithm is supposed to work, so that I can generate the right bits for any code, and leave it to the user to determine which codes should be avoided. Therefore, if anyone knows someone who worked on the Syntor X design team, the VX-5R team, or is generally an expert in the narrow field of DPL coding, I'd love to hear from you.

Update 7-Jan-2007: Skip Hansen, one of the xcat guys, ran into problems with a Yaesu Vertex 5000 repeater using a Pacific Research controller. That system didn't like either all-ones or my empirically determined best values for the spare bits. Skip asked around, and Andy Brinkley was kind enough to fight with a suitcase programmer long enough to generate a sample ROM with DPL values of 023 through 223. In that range, the "official" Motorola values are different in five cases from the ones I listed first:

DPL code Motorola value KB8ZQZ empirical values
02626 2
07137 3
07404 0
15267 6
16267 6
Links to reference material discussed on this page
 
This page created by Dennis Boone, KB8ZQZ, jm-sxg at yagi dot h-net dot msu dot edu.